私は、多数の「リアルサーバー」の UDP トラフィックの負荷を分散するために、NAT モードで LVS (ipvsadm) を使用しています。クライアントの単一のソース ポートから発信されたトラフィックが異なるリアルサーバーに分散されるように、1 パケット スケジューリングを使用しています。
しかし、私が確認したところ、実サーバーで生成され、クライアントに送り返される UDP データグラムの送信元 IP/ポートは実サーバーのものに設定されているため、クライアントは元のデータグラムを送信したものと一致する送信元 IP/ポートを持つ応答を受信することを期待するため、混乱します。
これは実に奇妙なことです。なぜなら、LVS は実サーバーを仮想 IP / ポートの背後に「隠す」ことになっているからです。
どうやら、1パケットスケジューリングをオフにすると、送信データグラムの送信元IP /ポートがはLVS によって正しく書き換えられました。
これに遭遇した人はいますか? もしそうなら、これを回避する方法は何ですか?
答え1
まだご興味がおありでしたら:
1 パケット スケジューリングでは、スケジュールしたばかりのパケットからの応答は期待されないため、接続情報は保存されないと考えられます。その後、応答が返されると、LVS は接続を見つけることができず、使用するソース IP/ポートがわかりません。
これは設計上のようです。ここで「OPS は、元のパケットに対する応答がない設定に対して実装されています」を検索すると、説明が表示されます。
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.UDP.html
解決策は、UDP 接続の持続タイムアウトを設定し (迅速な応答が期待される場合は、この値を低く設定できます)、接続時間を明示的に設定することです。これを行うことができるため、OPS が接続を記憶する必要がなくなります。