永続化のための負荷分散のベストプラクティス

ますます多くのクライアントにWeb APIを提供するWebアプリケーションを実行しています。はじめに、クライアントは通常、家庭、オフィス、またはその他のワイヤレスネットワークであり、チャンクされたhttpアップロードをAPIに送信しました。これで、より多くのモバイルクライアントの処理に分岐しました。数kから数ギグの範囲のファイルは、小さなチャンクに分割され、APIで再構成されます。

現在の負荷分散は2つの層で実行されます。最初にラウンドロビンDNSを使用して、api.company.comアドレスの複数のAレコードをアドバタイズします。各IPでは、Linux LVS：http : //www.linuxvirtualserver.org/をホストします。ロードバランサーは、リクエストのソースIPアドレスを確認して、接続をどのAPIサーバーに渡すかを決定します。このLVSボックスは、外部VIPと内部ゲートウェイIPを相互に引き継ぐようにハートビートで構成されています。

最近、2つの新しいエラー状態が発生しました。

最初のエラーは、クライアントが1つのLVSから別のLVSにアップロード途中で発振または移行している場合です。これにより、ロードバランサーは永続的な接続を追跡できなくなり、トラフィックを新しいAPIサーバーに送信するため、2つ以上のサーバー間でチャンクされたアップロードが中断されます。私たちの意図は、api.company.comのラウンドロビンDNS TTL値（1時間に設定）が、ダウンストリームキャッシングネームサーバー、OSキャッシングレイヤー、およびクライアントアプリケーションレイヤーで尊重されることです。このエラーは、アップロードの約15％で発生します。

あまり一般的ではない2番目のエラー。クライアントはLVSボックスへのトラフィックを開始し、その背後にある実サーバーAにルーティングされます。その後、クライアントは、LVSボックスが認識しない新しいソースIPアドレスを介して着信します。これにより、進行中のトラフィックがそのLVSの背後にある実サーバーBにルーティングされます。

上記で説明したアーキテクチャを前提として、上記の各エラーケースをより適切に処理できるようにする、より良いアプローチを使用した人々の経験を教えてください。

2010年5月3日を編集：

これは私たちが必要としているもののように見えます。送信元IPアドレスの重み付けされたGSLBハッシュ。

http://www.brocade.com/support/Product_Manuals/ServerIron_ADXGlobalServer_LoadBalancingGuide/gslb.2.11.html#271674

これに対する標準的な解決策は、エンドユーザーのIPアドレスに依存せず、代わりに、レイヤー7（HTTP / HTTPS）ロードバランサーとCookieを介した「スティッキーセッション」を使用することです。

スティッキーセッションとは、ロードバランサーが常に特定のクライアントを同じバックエンドサーバーに転送することを意味します。Cookie経由とは、ロードバランサー（それ自体が完全に機能するHTTPデバイス）がCookie（ロードバランサーが自動的に作成および管理する）を挿入して、特定のHTTP接続で使用するバックエンドサーバーを記憶することを意味します。

スティッキーセッションの主な欠点は、ベンドサーバーの負荷が多少不均一になる可能性があることです。ロードバランサーは、新しい接続が確立されたときにのみ負荷を均等に分散できますが、既存の接続がシナリオで長持ちする可能性がある場合、一部の期間では、負荷が完全に均等に分散されません。

ほぼすべてのレイヤー7ロードバランサーがこれを実行できます。Unix / Linuxでは、nginx、HAProxy、Apsis Pound、Apache 2.2とmod_proxyなどの一般的な例がいくつかあります。Windows 2008以降には、Microsoft Application Request Routingがあります。アプライアンスとして、Coyote Point、loadbalancer.org、Kemp、Barracudaがローエンドスペースで一般的です。F5、Citrix NetScalerなどのハイエンド製品。

HAProxyの作者であるWilly Tarreauは、ここで負荷分散技術の概要を説明しています。

DNSラウンドロビンについて：

私たちの意図は、api.company.comのラウンドロビンDNS TTL値（1時間に設定）が、ダウンストリームキャッシングネームサーバー、OSキャッシングレイヤー、およびクライアントアプリケーションレイヤーで尊重されることです。

それはありません。また、DNSラウンドロビンはロードバランシングには適していません。そして、他に何も納得できない場合は、最新のクライアントが最長のプレフィックス一致のピン留めのために他のすべてのホストよりも1つのホストを優先する可能性があることを覚えておいてください。

基本的に、アクティブ/パッシブまたはアクティブ/アクティブHAの実際のロードバランサーによって処理される高可用性IPアドレスに2つ以上のRRレコードをポイントすることにより、粗粒度の負荷分散としてDNSラウンドロビンを使用しても問題ありません。そして、それがあなたがやっていることなら、関連するIPアドレスはすでに高可用性であるため、長い存続時間の値を持つDNS RRレコードを提供することもできます。

代替案に関する質問に答えるには：HAProxyを介して確実なレイヤー7ロードバランシングを取得できます。

LVSの親和性の問題を修正する限り、私は確かな考えに少しドライです。タイムアウトやオーバーフローのように単純な場合もあります。一部のモバイルクライアントは、ネットワークに接続しているときにIPアドレスを切り替えます。おそらくこれがあなたの悩みの原因かもしれませんか？少なくとも、アフィニティの粒度を少なくともクラスCに広げることをお勧めします。