web-dev-qa-db-ja.com

HAProxyのデバッグ

私はサーバークラスターをローカルでかなり長い間テスト/テストしてきましたが、問題はありませんでした。最近、サーバークラスターをライブテスト用にセットアップしましたが、問題に気づき、クラスター内のHAProxyで問題が発生している可能性があると考えています。

まず、クラスターの構造について少し説明します。セットアップ方法に問題がある可能性があります。複数のプロキシが必要になる可能性があります。

HAProxyがバランスを取っている2つのサーバークラスターがあります。それらをSC1およびSC2と呼びます。メインクラスターはSC1で、HAProxyのポート80にあるものはすべてSC1に送信されます。 SC1はリクエストを処理し、ポート8080のプロキシを介してSC2に別のリクエストを送信します。これは問題ではないと思いますが、サーバーのログにSC1がSC2に接続できないと表示されることがよくあります。 HAProxyが過負荷になっているためです。

HAProxyが過負荷になっていると思う理由は、統計ページを見ると、応答するのに1秒以上かかることが多いためです。このため、HAProxyログを確認することにしました。ログに異常があり、自分の問題に関係しているのではないかと思います。毎分かそこら(時にはもっと時々もっと少ない)、私は次のメッセージを受け取ります:

Oct  8 15:58:52 haproxy rsyslogd-2177: imuxsock begins to drop messages from pid 3922 due to rate-limiting
Oct  8 15:58:52 haproxy kernel: [66958.500434] net_ratelimit: 2997 callbacks suppressed
Oct  8 15:58:52 haproxy kernel: [66958.500436] nf_conntrack: table full, dropping packet

私はこれの影響が何であるか疑問に思いました。これは単にパケットのドロップを引き起こすのでしょうか、それとも遅延を引き起こすのでしょうか?この問題を解決するにはどうすればよいですか? Ubuntu12.04LTSサーバーで実行しています。

これが私のsysctlの変更です:

fs.file-max = 1000000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

これが私の設定ファイルです:

global
   log /dev/log   local0 info
   log /dev/log   local0 notice
   maxconn 50000
   user u1
   group g1
   #debug

defaults
   log     global
   mode    http
   option  httplog
   option  dontlognull
   option  forwardfor
   retries 3
   option redispatch
   option http-server-close
   maxconn 50000
   contimeout      10000
   clitimeout      50000
   srvtimeout      50000
   balance roundrobin

listen  sc1 255.255.255.1:80
    maxconn 20000
    server  sc1-1 10.101.13.68:80 maxconn 10000
    server  sc1-2 10.101.13.66:80 maxconn 10000
listen  sc1-1_Update  255.255.255.1:8181
    maxconn 20000
    server  sc1-1 10.101.13.66:80 maxconn 20000
listen  sc1-2_Update  255.255.255.1:8282
    maxconn 20000
    server  sc1-2 10.101.13.68:80 maxconn 20000
listen  sc2 255.255.255.1:8080
    maxconn 30000
    server  sc2-1 10.101.13.74:80 maxconn 10000
    server  sc2-2 10.101.13.78:80 maxconn 10000
    server  sc2-3 10.101.13.82:80 maxconn 10000
listen  sc2-1_Update 255.255.255.1:8383
    maxconn 30000
    server  sc2-2 10.101.13.78:80 maxconn 15000
    server  sc2-3 10.101.13.82:80 maxconn 15000
listen  sc2-2_Update 255.255.255.1:8484
    maxconn 30000
    server  sc2-1 10.101.13.74:80 maxconn 15000
    server  sc2-3 10.101.13.82:80 maxconn 15000
listen  sc2-3_Update 255.255.255.1:8585
    maxconn 30000
    server  sc2-1 10.101.13.74:80 maxconn 15000
    server  sc2-2 10.101.13.78:80 maxconn 15000
listen  stats :8888
    mode http
    stats enable
    stats hide-version
    stats uri /
    stats auth user:pass

Sc1とsc2がメインクラスターです。サーバーを更新する必要があるときに使用する他のすべてのもの(たとえば、サーバーsc1-1を更新するためにhaproxyのポート80を8181に転送します)。

この問題についての助けをいただければ幸いです。

ありがとうございました

1
Eumcoz

接続追跡テーブルがいっぱいになっているようです。接続追跡を使用するiptablesルールを削除すると、問題が解決します。

それがオプションではなく、RAMが利用可能である場合は、テーブルサイズを増やすことができます。

cat /proc/sys/net/netfilter/nf_conntrack_max
echo 131072 > /proc/sys/net/netfilter/nf_conntrack_max

おそらくハッシュサイズも増やす必要があります。

cat /sys/module/nf_conntrack/parameters/hashsize
echo 32768 > /sys/module/nf_conntrack/parameters/hashsize

これらの数値は、デスクトップのデフォルト設定の2倍であり、正確に何が必要かわかりません。また、それをsysctl.confに追加することもできます。

net.ipv4.tcp_tw_recycleを使用すると、NATで深刻な問題が発生する可能性があるので注意が必要です。

2
JHill