LVSでの1つのパケットスケジューリングと発信パケットの送信元アドレス
NATモードでLVS（ipvsadm）を使用して、多数の「実サーバー」のUDPトラフィックの負荷を分散しています。1つのパケットスケジューリングを使用して、単一の送信元ポートから発信されるトラフィックがクライアントはさまざまな実サーバーに分散されます。
しかし、私が見ているのは、実サーバーで発生してクライアントに返送されるUDPデータグラムのソースIP /ポートが実サーバーの1つに設定されていることです。これは、クライアントを混乱させるものです。元のデータグラムを送信したものと一致するソースIP /ポート。
LVSは仮想IP /ポートの背後にある実サーバーを「隠す」ことになっているため、これは確かに非常に奇妙です。
One-packet-schedulingをオフにすると、送信データグラムの送信元IP /ポートareがLVSによって正しく書き換えられたようです。
誰かがこれに遭遇しましたか？もしそうなら、これを回避する方法は何ですか？
それでも興味がある場合：
1パケットのスケジューリングでは、スケジュールしたばかりのパケットからの応答は期待されないため、接続情報は格納されないと思います。その後、応答が返されると、LVSはその接続を見つけることができないため、使用するソースIP /ポートがわかりません。
これは仕様によるもののようです。ここで「OPSは元のパケットに対する応答がないセットアップに実装されています」を検索すると、いくつかの説明が表示されます。
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.UDP.html
解決策は、UDP接続の永続性タイムアウトを設定して（迅速な応答が必要な場合は低く設定できます）、接続時間を明示的に設定することです。これを実行できるため、OPSが接続を記憶する意味はありません。