IPv4SADM が WLC スケジューラ上で均等に分散されない

IPv4SADM が WLC スケジューラ上で均等に分散されない

何らかの理由で、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 を使用してストレス テストを実行すると、すべての接続が同じ実サーバーに送信されます。

ハプロキシよりインテリジェントなロード バランサですが、完全に透過的に動作するためにパケットの戻りパスに配置する必要があります。

関連情報