web-dev-qa-db-ja.com

IPvsadmがwlcスケジューラで均等にバランスをとっていない

何らかの理由で、wlcまたはlcスケジューラーを使用している場合、ipvsadmは実サーバー間の接続のバランスを均等に取っていないようです。 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を使用していましたが、Ubuntu 10.4 LTSに移行すると何かが違うように見えるため、activeconnは以前は正確でした。

# ipvsadm -v
ipvsadm v1.25 2008/5/15 (compiled with popt and IPVS v1.2.1)

それで、ipvsadmはアクティブな接続を適切に追跡しておらず、したがって負荷分散が正しく機能していませんか？もしそうなら、どうすればそれを再び適切に機能させることができますか？

編集：私がcat /proc/net/ip_vsすると、正しいactiveconnsが存在するように見えます。

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
linuxubuntu-10.04lvsldirectord
5
davidsmalley

Lc（最小接続）では、すべてのサーバーの接続数が同じである場合、リストの最初のサーバーに常に新しい接続が提供されます。これは、使用率が非常に低く、時々接続しかない場合、その接続は常にリストの最初のホストに移動することを意味します。

1
Patrick

接続数から判断すると、おそらく問題ではありませんが、実サーバーの1つが他のサーバーよりも応答が遅い場合、最小の接続で不均一な分散が発生する可能性があります。接続上でより迅速にスタックします。

0
ZaphodB

私のお気に入りはwrr（weigthed round robin）です。 DRアプローチ（直接ルーティング）を使用していると仮定するのは正しいですか？

その場合、RS（実サーバー）からの応答はLBを経由せずにクライアントに直接送信されるため、ipvsadmは接続自体を認識しません。

0
Nils

Davidのコマンド出力は、彼がトンネルモード（IPIP）を使用していることを示しています。これは、通常、DRのバリアントとして設定されています。彼の設定をよりよく理解するには、いくつかのルーティングテーブルまたは図を見る必要があります。

しかし、LVSでの接続追跡はTCP FINパケットを認識しないため、おそらく混乱していることに同意します。

ipvsadmには、期限切れの接続をより早くタイムアウトするためのいくつかの設定があります。たとえば、次のコマンドは、1時間後に非アクティブな接続をタイムアウトします。

/sbin/ipvsadm --set 3600 120 300

クライアントのソースを再確認する必要があります。 LVSのデフォルトの動作は、クライアントIPによる持続的接続を行うことです。したがって、同じテストクライアントIPからwgetまたはabを使用してストレステストを行うと、すべての接続が同じ実サーバーに送信されます。

Haproxy はよりインテリジェントなロードバランサーですが、完全に透過的に機能するには、パケットのリターンパスに配置する必要があります。

0
Wim Kerkhoff