web-dev-qa-db-ja.com

HAProxyランダムHTTP503エラー

3つのサーバーをセットアップしました。

  • 負荷分散を実行するためのNginx + HAproxyを備えたサーバーA
  • バックエンドサーバーB
  • バックエンドサーバーC

これが私たちの/etc/haproxy/haproxy.cfg：

global
        log /dev/log   local0
        log 127.0.0.1   local1 notice
        maxconn 40096
        user haproxy
        group haproxy
        daemon

defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        retries 3
        option redispatch
        maxconn 2000
        contimeout      50000
        clitimeout      50000
        srvtimeout      50000
                stats enable
                stats uri /lb?stats
                stats realm Haproxy\ Statistics
                stats auth admin:admin
listen statslb :5054 # choose different names for the 2 nodes
        mode http
        stats enable
        stats hide-version
        stats realm Haproxy\ Statistics
        stats uri /
        stats auth admin:admin

listen  Server-A 0.0.0.0:80    
        mode http
        balance roundrobin
        cookie JSESSIONID prefix
        option httpchk HEAD /check.txt HTTP/1.0
        server  Server-B <server.ip>:80 cookie app1inst2 check inter 1000 rise 2 fall 2
        server  Server-C <server.ip>:80 cookie app1inst2 check inter 1000 rise 2 fall 3

3つのサーバーすべてに、要求を処理するための十分な量のRAMとCPUコアがあります

閲覧時にランダムなHTTP503エラーが表示されます：503 Service Unavailable - No server is available to handle this request.

また、サーバーのコンソール上：

Message from syslogd@server-a at Dec 21 18:27:20 ...
 haproxy[1650]: proxy Server-A has no server available!

90％の確率でエラーが発生しないことに注意してください。これらのエラーはランダムに発生します。

haproxy
15
BnW

私も同じ問題を抱えていました。何日も髪を抜いた後、私は問題を見つけました。

2つのHAProxyインスタンスを実行していました。 1つはゾンビで、更新中やhaproxyの再起動中にどういうわけか殺されることはありませんでした。/haproxy statsページを更新すると、PIDが2つの異なる番号の間で変化することに気づきました。番号の1つが付いているページには、ばかげた接続統計がありました。私がしたことを確認するために

netstat -tulpn | grep 80

そして、2つのhaproxyプロセスがポート80をリッスンしているのを見ました。

この問題を修正するために、「kill xxxx」を実行しました。ここで、xxxxは疑わしい統計を含むpidです。

26
Matthew Jones

これとまったく同じ問題に遭遇したが、上記の解決策のいずれも適用できない他の人のために、ここに私の答えを追加します。私の答えは、上記の元のコードには適用されないことに注意してください。

この問題が発生している可能性のある他の人は、構成を確認して、構成の複数のセクションに同じ「バインド」行を誤って配置していないかどうかを確認してください。 Haproxyは起動時にこれをチェックしません。私は、これを推奨される検証チェックとして開発者に提出する予定です。私の場合、構成の3つの異なるセクションがあり、誤って同じIPバインディングを2つの異なる場所に配置しました。正しいセクションが使用されるか、間違ったセクションが使用されるかについては、約50/50ショットでした。正しいセクションが使用された場合でも、リクエストの約半分は依然として503を取得しました。

6
CyberInferno

Linuxボックスで2つのHAProxyサービスが実行されているため、同じ問題が発生しましたが、名前/ pid/resourcesが異なります。不要なものを停止しない限り、必要なインスタンスは503エラーをランダムにスローします（たとえば、5回に1回）。

複数のURLルーティングに単一のLinuxボックスを使用しようとしましたが、haproxyまたは定義したhaproxyの構成ファイルに制限があるようです。

1
Srini Ragavan

サーバーが、おそらく特定の時間にタイムアウトしている共通のリソースを共有し、ヘルスチェック要求が同時に行われている（したがって、バックエンドサーバーを同時に引き出している）可能性があります。

HAProxyオプションを使用してみることができますspread-checksヘルスチェックをランダム化します。

1
Matt Beckman

バックエンドにoption http-server-closeを追加することで、HAProxyを使用して断続的な503を解決しました。 uWSGI（アップストリーム）がキープアライブでうまく機能していないようです。問題の背後にあるものが本当にわからないが、このオプションを追加した後、それ以来、単一の503を見ていません。

0
vvucetic

詳細なしで言うのは難しいですが、各バックエンドに構成されたmaxconnを超えている可能性はありますか？統計UIには、フロントエンドと個々のバックエンドの両方でこれらの統計が表示されます。

0
Ilan Rabinovitch