何らかの理由で、ipvsadm は、wlc または lc スケジューラを使用しているときに、実サーバー間の接続を均等に分散していないようです。1 つの実サーバーは要求で非常に混雑しますが、他の実サーバーは比較的少ない接続しか受信しません。
私の ldirectord.cf ファイルは次のようになります:
quiescent = yes
autoreload = yes
checktimeout = 10
checkinterval = 10
# *.example.com http
virtual = 192.0.2.111:http
real = 10.10.10.1:http ipip 10
real = 10.10.10.2:http ipip 10
real = 10.10.10.3:http ipip 10
real = 10.10.10.4:http ipip 10
real = 10.10.10.5:http ipip 10
scheduler = lc
protocol = tcp
service = http
checktype = negotiate
request = "/lb"
receive = "Up and running"
virtualhost = "site.com"
fallback = 127.0.0.1:http
問題の原因と思われる奇妙なこと(しかし、本当に確信はありません)は、ipvsadmがアクティブな接続を適切に追跡していないようで、すべてが非アクティブな接続として表示されることです。
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.0.2.111:http lc
-> 10.10.10.1:http Tunnel 10 0 10
-> 10.10.10.2:http Tunnel 10 0 18
-> 10.10.10.3:http Tunnel 10 0 3
-> 10.10.10.4:http Tunnel 10 0 10
-> 10.10.10.5:http Tunnel 10 0 5
そうするとipvsadm -Lnc
、多くの接続が表示されますが、常に ESTABLISHED および FIN_WAIT 状態になります。
以前は Gentoo ベースのロード バランサーで ldirectord を使用していましたが、activeconn は正確でした。しかし、Ubuntu 10.4 LTS に移行してからは何かが変わったようです。
# ipvsadm -v
ipvsadm v1.25 2008/5/15 (compiled with popt and IPVS v1.2.1)
では、ipvsadm はアクティブな接続を適切に追跡していないため、負荷分散が正しく機能しないのでしょうか。もしそうなら、どうすれば再び適切に機能するようになるのでしょうか。
編集:さらに奇妙になりますが、cat /proc/net/ip_vs
正しい activeconn が存在しているように見えます。
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP C000026F:0050 rr
-> 0AB42453:0050 Tunnel 10 1 24
-> 0AB4321D:0050 Tunnel 10 0 23
-> 0AB426B2:0050 Tunnel 10 2 25
-> 0AB4244C:0050 Tunnel 10 2 22
-> 0AB42024:0050 Tunnel 10 2 23
答え1
lc (最小接続) では、すべてのサーバーの接続数が同じ場合、常にリストの最初のサーバーに新しい接続が与えられます。つまり、使用率が非常に低く、接続がたまにしか行われない場合、その接続は常にリストの最初のホストに渡されることになります。
答え2
私のお気に入りは wrr (重み付けラウンドロビン) です。DR アプローチ (ダイレクト ルーティング) を使用していると考えてよろしいでしょうか?
その場合、RS (実サーバー) からの応答は LB を経由せずにクライアントに直接送信されるため、ipvsadm は接続をそのようには認識しません。
答え3
接続数から判断すると、おそらく問題にはならないと思いますが、実サーバーの 1 つが他のサーバーよりも応答が遅い場合、接続数が最小で分散が不均等になる可能性があります。その場合、接続がより早く蓄積されるため、他のサーバーよりも 1 回あたりの新しい接続数が少なくなります。
答え4
David のコマンド出力は、彼がトンネル モード (IPIP) を使用していることを示しています。これは通常、DR のバリエーションとして設定されます。彼の設定をよりよく理解するには、ルーティング テーブルまたは図をいくつか確認する必要があります。
しかし、TCP FIN パケットが認識されないため、LVS の接続追跡が混乱している可能性もあることに同意します。
ipvsadm には、期限切れの接続をより早くタイムアウトするための設定がいくつかあります。たとえば、次のコマンドは、非アクティブな接続を 1 時間後にタイムアウトします。
/sbin/ipvsadm --set 3600 120 300
クライアントのソースは二重にチェックする必要があります。LVS のデフォルトの動作は、クライアント IP による永続的な接続を行うことです。したがって、同じテスト クライアント IP から wget または ab を使用してストレス テストを実行すると、すべての接続が同じ実サーバーに送信されます。
ハプロキシよりインテリジェントなロード バランサですが、完全に透過的に動作するためにパケットの戻りパスに配置する必要があります。