F5Big-IPデバイスのクラスタリング。出来ますか？
Webアプリケーションを開発しました。 5台のIISサーバーのファームで実行されます。ファーム内のサーバーとのセッションが確立されると、そのセッション内のそれ以降のHTTP要求が同じサーバーに送信されることが絶対に必要です。セッションの残りの部分。
今日、私はF5のWebサイトを発見し、「スティッキーセッション」について学びました。ほとんどのユーザーはモバイル（iPhoneなど）であるため、1回のセッションの途中でIPアドレスが変更される可能性があります。これは、送信元IPを使用して一意のセッションを識別することができないことを意味します。ホワイトペーパーでは、F5 LTMデバイスがこれに対するソリューションを提供し、HTTPリクエスト自体[またはCookie]内のコンテンツを使用してセッションIDを判別できるようにすることを提案しています。
ここまでは順調ですね。しかし、それから私は考え始めました…そのF5デバイスは単一障害点です。さらに、容量を大幅に増やしてF5デバイスを追加したい場合はどうなりますか？それらのクラスターを設定することは理にかなっています。しかし、できる限りグーグルを実行しているにもかかわらず、クラスターが「内部」でどのように機能するかについての基本的な概念を説明しているホワイトペーパーは見つかりません。
考えてみてください…2台のF5デバイスを購入したとしましょう。それらは、私のネットワークの外部（インターネットに面した）インターフェース上で共通の「仮想」IPを共有します。 HTTP接続が着信し、どういうわけか2つのデバイスがF5＃1が呼び出しに応答する必要があると判断します。 F5＃1には、そのセッションのIDを[Cookieを介して]内部Webサーバー＃4に関連付けるメモリ内マップがあります。 2分後、同じ顧客が同じセッションの一部として新しいHTTP接続を開始します。宛先の「仮想」IPは同じですが、送信元IPアドレスが変更されています。 F5＃2ではなくF5＃1がその接続を受信することをどのように保証できますか？前者がそれを受け取った場合、セッションを識別するためのメモリ内マップがあるため、良好な状態です。しかし、後者がそれを受信した場合、セッションがWebサーバー＃4に関連付けられていることに気づきません。
これを機能させるために、2つのF5デバイスは何らかの方法で互いに情報を共有していますか？それとも、私が説明している構成は、物事を行うための実用的/一般的な方法ではありませんか？
Newbの質問でごめんなさい…これは私にとってまったく新しいものです。
F5のほとんどはHAペアで提供されるため、これらはクラスター化されます。一方のF5がダウンするとすぐに、IPはペアのもう一方のF5によって引き継がれるため、ダウンタイムは発生しません。あなたの質問では、各IPは一度に1つのF5にのみ割り当てられ、両方で実際にアクティブ/アクティブではありません。
これが解決策です。次に質問する必要があるのは、両方のF5がホストされているサイト全体がダウンした場合にどうなるかです（次に、グローバルな負荷分散を調べます）。
2つのF5コンテンツスイッチを本当に「クラスター化」できるとは思いませんが、機能に取り組んでいると思いますが、間違っている可能性があります。ロードバランサーのクラスタリングは、エンジニアリング上の大きな課題です。レイヤー4またはレイヤー7で情報を共有する方法、レイヤー2またはレイヤー3で通信する方法、ロードバランサーの動作に影響を与えることなくクラスタリングと情報共有を有効にする方法本質的にワイヤスピードで。
昔のファイアウォールについて考えてみてください。プロキシベースのファイアウォールは、レイヤー7で多くのことを行い、パフォーマンスを低下させずにノード間でこの情報を共有することは本質的に不可能であったため、常にスタンドアロンノードでしたが、ステートフルパケットフィルターはレイヤー4を転送するだけで済みました。情報、そしてそれでさえオーバーヘッドでした。ロードバランサーは通常、VIPの場合のように、エンドポイントとして機能する構成の多くでデプロイされるため、TCPセッション全体が書き換えられ、ロードバランサーがクライアントになります。サーバー（つまり、基本的に2つのフローがあり、これが実際のクライアントがバックエンドサーバーに直接httpパイプラインを実行できない理由の1つです）。
HAを使用すると、必要なスケールアウトが達成されないため、負荷などを処理するためにロードバランサーをスケールアップする必要があります。スケールアップと同様に、そのようなベンダーは一般的に（常にそうとは限りません）ライセンスのアップグレードで追加のCPUを有効にできる）は、明らかに、新しい、より大きなボックスHAが復元力と信頼性を提供することを意味します。 HAを使用すると、通常、コマンドの伝達、構成の同期、およびセッション交換のいくつかの要素（負荷が発生する可能性があるため、ある程度構成できます）があります。
ロードバランサーの負荷分散（つまり、LB-> LB-> Webファーム）によってスケーリングを確認できますが、それは素晴らしいことではなく、遅延が発生する可能性があり、（非常に）コストがかかり、インフラストラクチャには別の障害点があります。正常に実装されました。
ほぼ準クラスターのようなVRRPのようなものを使用できます。この実装では、Webファームの前に2セットのHAペアのロードバランサーを配置し、それらをHA1およびHA2と呼びます。 VRRPを使用すると、VRRP優先度の構成が高いため、2つのVIPを作成できます。1つはHA1（vip1）でライブで、もう1つはHA2（vip2）でライブです。 vip1とvip2はどちらも、VRRPを介して、自動（モニターなどに基づく）またはVRRP優先度を下げることにより手動で、他のHAペアにフェイルオーバーできます。
ほとんどのベンダーは、上記の構成に関するKB記事を持っています。彼らの製品に真のクラスタリングを持っているベンダーが1つあると思いますが、それについてはグーグルで説明します。
すべてのロードバランサーにはさまざまな形式の永続性があり、これをバックエンドサーバーの関連付けに適用します。今日人気のあるフォームは、Cookieとハッシュです（4タプルと他の1つまたは2つに基づく）。ロードバランサーがシナリオのようにエンドポイントとして機能する場合、TCP接続が完全に確立されると、接続に関する情報を含むプロトコル制御バッファーが基本的に作成されます（基本的に4-タプルと他のいくつかのこと）このようなバッファは2つあり、1つは接続の両側を表し、このバッファはセッションが終了するまでロードバランサのメモリに残り、セッションがクリアされて解放されます。再び使用するためのメモリ。
Citrix NetScalerは、特にクラスタリングの分野で最も高度な負荷分散ソリューションのようです。 HAペアをインストールする必要はありません。2ボックスクラスターを使用するだけです。次に、成長させたいときに、クラスターにボックスを追加するだけです。また、VMで実行されているロードバランサーをクラスター化することもできます。
F5プラットフォームでは、構成しているVIP）のタイプに応じて、基本的に2つのオプションがあります。レイヤー4ではVIP（事実上NAT）接続ミラーリングを構成できます。これにより、HAイベント中にTCPセッションが中断されないようになります。これはレイヤー7では不可能ですVIP-あります状態が多すぎてリアルタイムでスタンバイに「バックアップ」できませんが、Cookieの永続性レコードをミラーリングできます。これにより、HAフェイルオーバー後、クライアントが再接続したときに、同じバックエンドサーバーにリダイレクトされます。
直接の知識はありませんが、Netscalerにも同様の機能があると思います。
とはいえ、このタイプの永続性に完全に依存しているスキームでは、特にVIPローテーションを定期的に行ったり来たりするバックエンドサーバーがある場合は、問題が発生します。 。サーバープールの任意のメンバーが受信リクエストのCookieを検証するためにクエリできる共有キャッシュ（memcachedはこれに最適です）を立ち上げることを調査することをお勧めします。思ったより簡単です:)
すべてのロードバランサーで、HAペアを設定して単一障害点を防ぐことができます。これは常に当てはまります。ビッグIPは高価です。 CitrixNetScalerを検討しましたか。非常に安価な仮想マシンバージョンがあります。実際、本番環境で制限されたスループットで使用できる無料バージョンがあります。それだけでなく、必要に応じて、アプリケーションと同じサーバーにNetScalerVPXを展開できます。ちょっとした考え。詳細が必要な場合は私にメールしてください。