UDPサーバーの負荷分散
私はudpサーバーを持っています。それは私のビジネスプロセスの中心的な部分です。運用環境で期待している負荷を処理するために、サーバーのインスタンスが2つまたは3つ必要になるでしょう。サーバーはほぼ完全にステートレスであり、ほとんどの場合データを収集します。その上の層は、複数のサーバーインスタンスから発生する可能性のある最小限の古くなったデータを処理する方法を認識しています。
私の質問は、サーバー間で負荷分散を実装するにはどうすればよいですか？サーバー間でリクエストをできるだけ均等に分散したいと思います。また、忠実に再現したいと思います。つまり、クライアントXがサーバーyにルーティングされた場合、それ以降のXのすべての要求はサーバーYに送られるようにします。
ちなみに、それは.NETシステムです...何をお勧めしますか？
状態はサーバー内の内部であり、何らかのトランザクションではありません。状態とは、サーバーが受信したデータからサーバーが集約するいくつかのデータであり、単純なWCF WebServiceでクエリ可能です。アプリケーションはUDPに基づいており、決定には同意しませんが、その「給与水準より上」
私は現在、MSのNLBを試していますが、問題なく動作します。箱から出して忠実に動作しますが、ネットワーク全体でノイズが発生します...
DNSもありません...ああ、それは完全にコスチュームプロトコルです。
私はudpサーバーを持っています。[...]サーバーはほぼ完全にステートレスです[..]忠実度があります。つまり、クライアントXがサーバーyにルーティングされた場合、Xの後続のすべてのリクエストがサーバーYに送られるようにします。それが賢明であり、Yをオーバーロードしない限り。
それでは、いくつかのアプリケーションの状態を保持し、UDPの上で実行する非公開のアプリケーションプロトコルを使用していますか？あなたは一種の難しい方向に進んでいます。 UDPは信頼できるデータトランスポートではありません。それがポイントです。信頼できるデータトランスポートについては、人気のあるTCPを参照してください。 「忠実度」を得る唯一の方法は、アプリケーションレイヤープロトコルを理解し、現在のアプリケーションの状態を知っており、それに応じて動作できる負荷分散プロキシを用意することです。
私はあなたが求めるものを提供することに近い3つのアプローチを見ます：
source（エンドユーザー）IPアドレスに基づいて、3つのIPアドレスに着信接続を静的に分散します。このようにして、特定のユーザーは常に同じサーバーに転送されます。ほとんどのプロのファイアウォールはこれを行うことができます。ほとんどのファイアウォールはバックエンドのヘルスチェックを行わないため、3つのサーバーを高可用性にする必要があります。
Matt Simmonsがすでに提案しているように、DNSを使用し、DNSラウンドロビンを使用します。
Windowsの組み込み ネットワーク負荷分散（NLB） を使用します。正直なところ、NLBとセミステートフルUDPベースのサービスでフェールオーバーシナリオがどのように機能するかはわかりません。アプリケーションが状態を処理する方法に基づいて、自分で調査する必要があります。プラス面として、NLBは非常に簡単にセットアップでき、Windowsライセンスで無料で提供され、成熟しており、パフォーマンスも優れています。
Linux仮想サーバー は、実サーバーのクラスター上に構築された、スケーラビリティと可用性の高いサーバーです。 LVSは、UDPプロトコルとソースハッシュアルゴリズムをサポートしています（これは、クライアントを常に同じ実サーバーに表示する場合に使用されます）。
LVMを使用してDNS（rr）、SIP（sh）のバランスをとっています。
面白い。私が見たプロキシソフトウェアのほとんどは確かにTCPベースです。
わずかな経験で見たUDP固有の負荷分散のほとんどはDNSベースです（タイムサーバー、DNSサーバーなど）。複数のAレコードを提供する方法はありますか？それが機能する場合、通常のDNSラウンドロビンは要求の公平な分散を保証し（おそらく、とにかく十分に公平である）、クライアントキャッシングは忠実性が維持されることを保証します（クライアント側でキャッシュベースのプラットフォームを使用している場合）。
オープンソースのNGINXおよびアプリケーション配信プラットフォームであるNGINX Plusは、UDPロードバランシングをサポートするようになりました。新しい機能は、既存のTCPおよびHTTP機能に基づいて構築されているため、NGINXは強力で使いやすく、さらに幅広いインターネットアプリケーションおよびデバイス向けの一貫したフロントエンドになります。
リリースnginx-1.9.13で利用可能
これを実行するには、ハードウェアまたはソフトウェアのいずれの種類のロードバランサーも使用できます。必要に応じて、さまざまなロードバランサーから選択できます。
レベル3ロードバランサー：着信IPと使用可能なバックエンドIPを確認するだけでロードバランスを実行します。この種のロードバランサーは、常に同じ着信IPアドレスを同じバックエンドに送信することでスティッキ性を保証します。この種類の戦略は、多くのクライアントが同じIP（プロキシであれ、企業のゲートウェイであれ）から来る場合、バックエンドの1つに過負荷をかける可能性があります。
レベル7ロードバランサー：レベル7ロードバランサーは、レベル3バランサーとしてバランスを取るだけでなく、パッケージの内容も確認するため、バランスをより柔軟に設定できます。ポリシー。
UDPを使用していることを考慮すると、両方のバランサーは良好なパフォーマンスを提供するはずです。また、UDPでの詳細なパケット検査は、TCP（プロトコルの理由により）よりも）少し制限されています。
予算に応じて、ソフトウェアロードバランサー（linux + IPVSなど）を使用して開始し、CiscoまたはNetappが提供するようなハードウェアロードバランサーに移行できます。