永続化のための負荷分散のベストプラクティス
ますます多くのクライアントに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つ以上のサーバー間でチャンクされたアップロードが中断されます。私たちの意図は、ラウンドロビンDNS TTL値（1時間に設定））がダウンストリームキャッシングネームサーバー、OSキャッシングレイヤー、およびクライアントアプリケーションレイヤーこのエラーは、アップロードの約15％で発生します。
あまり一般的ではない2番目のエラー。クライアントはLVSボックスへのトラフィックを開始し、その背後にある実サーバーAにルーティングされます。その後、クライアントは、LVSボックスが認識しない新しいソースIPアドレスを介して受信し、進行中のトラフィックをそのLVSの背後にある実サーバーBにルーティングします。
上記で説明したアーキテクチャを前提として、上記の各エラーケースをより適切に処理できる、より優れたアプローチでの人々の経験を教えてください。
2010年5月3日を編集：
これは私たちが必要としているもののように見えます。送信元IPアドレスの重み付きGSLBハッシュ。
これに対する標準的な解決策は、エンドユーザーのIPアドレスに依存せず、代わりにCookieを介して「スティッキーセッション」でレイヤー7（HTTP/HTTPS）ロードバランサーを使用することです。
スティッキーセッションとは、ロードバランサーが常に特定のクライアントを同じバックエンドサーバーに転送することを意味します。 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ラウンドロビンについて：
私たちの意図は、ラウンドロビンDNS TTL値（1時間に設定））がダウンストリームキャッシングネームサーバー、OSキャッシングレイヤー、およびクライアントアプリケーション層。
されません 。そして DNSラウンドロビンはロードバランシングには適していません 。そして、他に何もあなたを納得させない場合は、 現代のクライアントは最長のプレフィックスの一致により他のすべてのホストよりも1つのホストを優先する可能性がある ピン留めするため、モバイルクライアントがIPアドレスを変更した場合、別のホストに切り替えることを選択できますRRホスト。
基本的に、アクティブ/パッシブまたはアクティブ/アクティブHAの実際のロードバランサーによって処理される高可用性IPアドレスに2つ以上のRRレコードをポイントすることにより、粗粒度の負荷分散としてDNSラウンドロビンを使用しても問題ありません。そして、それがあなたがやっていることなら、関連するIPアドレスはすでに高可用性であるため、長い存続時間の値を持つDNS RRレコードを提供することもできます。
代替案に関する質問に答えるには、 HAProxy を使用して、レイヤー7の負荷分散を実現できます。
LVSのアフィニティの問題を修正する限り、私はしっかりしたアイデアに少しドライです。タイムアウトやオーバーフローと同じくらい簡単かもしれません。一部のモバイルクライアントは、ネットワークに接続している間にIPアドレスを切り替えます。おそらくこれがあなたの悩みの原因かもしれませんか？少なくとも、アフィニティの粒度を少なくともクラスCに広げることをお勧めします。