永続化のための負荷分散のベストプラクティス
ますます多くのクライアントに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