web-dev-qa-db-ja.com

バックエンドに障害が発生したときにHaproxyスティッキーセッションが別のサーバーにリダイレクトされない

HaproxyLBには次の設定があります。

global
    daemon
    maxconn 2048

    # SSL
    ca-base /etc/ssl/certs
    crt-base /etc/ssl/private
    ssl-default-bind-ciphers ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM;

defaults
    log global
    mode    http
    option forwardfor

# handle incoming requests to port 80 (http)
frontend www-http
    bind 1.2.3.4:80
    reqadd X-Forwarded-Proto:\ http
    default_backend www-backend

# handle incoming requests to port 443 (https)
frontend www-https
    bind 1.2.3.4:443 ssl crt /etc/ssl/private/example.com.pem
    reqadd X-Forwarded-Proto:\ https
    default_backend www-backend

backend www-backend
   # always use https
   redirect scheme https if !{ ssl_fc }

   # RR algorithm for load balancing
   balance roundrobin
   option httpclose

   # tracke which backend served specific user
   cookie _Rails_srv insert

   # sticky sessions
   appsession _Rails_session len 64 timeout 24h
   server s1 4.5.6.7:80 check cookie s1
   server s2 7.8.9.0:80 check cookie s2

これは、バックエンドの2 Railsアプリケーションサーバーに関連付けられており、セッションの粘着性のためにRails（_Rails_session）によって提供されるセッションCookieを使用しています。

サーバーの1つがダウンし、そのサーバーにアクセスしようとしている障害が発生したサーバーへの既存のセッションを持つクライアントが、機能している他のバックエンドにリダイレクトされるのではなく、500のサーバーエラー応答を受け取るまではうまく機能します。

障害を検出すると、Haproxyがトラフィックを他のサーバーに自動的にリダイレクトすると思いました。構成に問題がありますか？ありがとう。

load-balancinghaproxysticky-sessions
1
sa125

どうやら、redispatchオプションがありません。

ドキュメント から：

オプションの再ディスパッチ/オプションの再ディスパッチなし：接続に失敗した場合のセッションの再配布を有効または無効にします

HTTPモードでは、Cookieで指定されたサーバーがダウンしている場合、クライアントはCookieをフラッシュできないため、確実にサーバーに固執する可能性があります。そのため、クライアントはサービスにアクセスできなくなります。

「optionredispatch」を指定すると、プロキシは永続性を破り、稼働中のサーバーに再配布できます。

1
Felix Frank