web-dev-qa-db-ja.com

haproxyロードバランサーのバックエンド接続エラーを解決するにはどうすればよいですか？

haproxy統計ページ

以下は私のhaproxy設定です

global
    log /dev/log    local0 notice
    log /dev/log    local0 debug
    log 127.0.0.1 local0
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon
    maxconn 5000
defaults
    log     global
    mode    tcp
    option  tcplog
    option  tcpka
    timeout connect 60s
    timeout client 1000s
    timeout server 1000s

frontend aviator-app
    option tcplog
    log /dev/log local0 debug
    bind *:4433 ssl crt /etc/haproxy/certs/{domain_name}.pem
    mode tcp
    option clitcpka
    option http-server-close
    maxconn 5000
    default_backend aviator-app-pool
    # Table definition
    stick-table type ip size 2000k expire 30s store conn_cur
    # Allow clean known IPs to bypass the filter
    tcp-request connection accept if { src -f /etc/haproxy/whitelist.lst }
    # Shut the new connection as long as the client has already 100 opened
    # tcp-request connection reject if { src_conn_cur ge 500 }
    tcp-request connection track-sc1 src

backend aviator-app-pool
    option tcplog
    log /dev/log local0 debug
    balance roundrobin
    mode tcp
    option srvtcpka
    option http-server-close
    maxconn 50
    # list each server
            server appserver1 10.0.1.205 maxconn 12
            server appserver2 10.0.1.183 maxconn 12
            server appserver3 10.0.1.75 maxconn 12
            server appserver4 10.0.1.22 maxconn 12
            # end of list

listen  stats
    bind            *:8000
    mode            http
    log             global

    maxconn 10

    clitimeout      100s
    srvtimeout      100s
    contimeout      100s
    timeout queue   100s

    stats enable
    stats hide-version
    stats refresh 30s
    stats show-node
    stats auth username:password
    stats uri  /haproxy?stats

1秒あたり約12〜13のHTTPリクエストで負荷テストを実行すると、テストの最初の約1時間はエラーが表示されません。しかし、テスト開始から約90分で、多数のリクエストが失敗し始めます。 jmeterからのエラーメッセージには、通常、「接続がタイムアウトしました：接続」または「domain_name：4433」が応答しませんでした。以下は、haproxy.logからのいくつかのログメッセージです。また、上の画像で強調表示されているように、多数の「connエラー」といくつかの「応答エラー」が表示されます。

May  7 19:15:00 ip-10-0-0-206 haproxy[30349]: 64.112.179.79:55894 
[07/May/2018:19:14:00.488] aviator-app~ aviator-app-pool/<NOSRV> 
60123/-1/60122 0 sQ 719/718/717/0/0 0/672
May  7 19:15:00 ip-10-0-0-206 haproxy[30349]: 64.112.179.79:49905 
[07/May/2018:19:12:53.483] aviator-app~ aviator-app-pool/appserver2 
60022/1/127171 2283568 -- 719/718/716/11/0 0/666

バックエンドサーバーにエラーやスタックトレースが表示されません。ロードバランサーのCPU使用率は、ロードバランサーのテスト中は低く（10％未満）、各バックエンドサーバーで約30％です。この問題をデバッグするための助けがありがたいです。

load-balancinghttpshaproxy
1
sushrut619

バックエンドにはmaxconn 50があるため、HAProxyはオーバーフローをキューに入れ、既存の50のいずれかが終了するのを待ちます。各接続が切断されると、別の接続がバックエンドへの通過を許可されますが、バックエンドは十分に高速ではありません。リクエストはプロキシでバックアップされており、最終的に、プロキシはtimeout connect 60sのプロキシキューに配置された後、リクエストを破棄します。

ログエントリのsQがこれを説明しています。

s：サーバーがデータを送受信するのを待機しているときに、サーバー側のタイムアウトが期限切れになりました。

Q：プロキシはキューで接続スロットを待機していました。これは、サーバーに「maxconn」パラメーターが設定されている場合にのみ発生する可能性があります。

HAProxy構成ガイドの 切断時のセッション状態 を参照してください。

1
Michael - sqlbot