3つのサーバーをセットアップしました。
これが私たちの/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%の確率でエラーが発生しないことに注意してください。これらのエラーはランダムに発生します。
私も同じ問題を抱えていました。何日も髪を抜いた後、私は問題を見つけました。
2つのHAProxyインスタンスを実行していました。 1つはゾンビで、更新中やhaproxyの再起動中にどういうわけか殺されることはありませんでした。/haproxy statsページを更新すると、PIDが2つの異なる番号の間で変化することに気づきました。番号の1つが付いているページには、ばかげた接続統計がありました。私がしたことを確認するために
netstat -tulpn | grep 80
そして、2つのhaproxyプロセスがポート80をリッスンしているのを見ました。
この問題を修正するために、「kill xxxx」を実行しました。ここで、xxxxは疑わしい統計を含むpidです。
これとまったく同じ問題に遭遇したが、上記の解決策のいずれも適用できない他の人のために、ここに私の答えを追加します。私の答えは、上記の元のコードには適用されないことに注意してください。
この問題が発生している可能性のある他の人は、構成を確認して、構成の複数のセクションに同じ「バインド」行を誤って配置していないかどうかを確認してください。 Haproxyは起動時にこれをチェックしません。私は、これを推奨される検証チェックとして開発者に提出する予定です。私の場合、構成の3つの異なるセクションがあり、誤って同じIPバインディングを2つの異なる場所に配置しました。正しいセクションが使用されるか、間違ったセクションが使用されるかについては、約50/50ショットでした。正しいセクションが使用された場合でも、リクエストの約半分は依然として503を取得しました。
Linuxボックスで2つのHAProxyサービスが実行されているため、同じ問題が発生しましたが、名前/ pid/resourcesが異なります。不要なものを停止しない限り、必要なインスタンスは503エラーをランダムにスローします(たとえば、5回に1回)。
複数のURLルーティングに単一のLinuxボックスを使用しようとしましたが、haproxyまたは定義したhaproxyの構成ファイルに制限があるようです。
サーバーが、おそらく特定の時間にタイムアウトしている共通のリソースを共有し、ヘルスチェック要求が同時に行われている(したがって、バックエンドサーバーを同時に引き出している)可能性があります。
HAProxyオプションを使用してみることができますspread-checks
ヘルスチェックをランダム化します。
バックエンドにoption http-server-close
を追加することで、HAProxyを使用して断続的な503を解決しました。 uWSGI(アップストリーム)がキープアライブでうまく機能していないようです。問題の背後にあるものが本当にわからないが、このオプションを追加した後、それ以来、単一の503を見ていません。
詳細なしで言うのは難しいですが、各バックエンドに構成されたmaxconnを超えている可能性はありますか?統計UIには、フロントエンドと個々のバックエンドの両方でこれらの統計が表示されます。