web-dev-qa-db-ja.com

nginxを使用したアクティブ/パッシブリバースプロキシ

ZookeeperとCuratorをアクティブ/パッシブとして使用する2つのWebsocketサーバーがあり、1つのサーバーに障害が発生すると、2番目のバックエンドが稼働します。

次のように構成しました。

upstream backend  {
  server 172.31.9.1:8080 max_fails=1 fail_timeout=5s;
  server 172.31.9.0:8080 max_fails=1 fail_timeout=5s;
}

server {
    listen 443;

    # Host name to respond to
    server_name xxxxxx.compute.amazonaws.com;

    ssl on;
    ssl_certificate /etc/ssl/certs/wildcard.dev.xxxx.net.crt;
    ssl_certificate_key /etc/ssl/certs/wildcard.dev.xxxx.net.key;

    location / {
        # switch off logging
        access_log off;

        proxy_pass http://backend;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $Host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # WebSocket support (nginx 1.4)
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

私が期待しているのは、アクティブサーバーとパッシブサーバーが場所を切り替えると、Nginxが障害を認識してすべてのトラフィックをアクティブサーバーにリダイレクトするのに5秒かかることです。

実際には、アクティブなサーバーを認識してすべてのトラフィックを切り替えるのに最大25秒かかります。

実際のシナリオでは、リダイレクト間の最大10秒のダウンタイムを処理できます。

何が足りないのですか？

nginxload-balancingreverse-proxyhigh-availability
2
danny.lesnik

fail_timeout NGINXドキュメントから：

セット：

  • サーバーとの通信に指定された回数の失敗した試行が発生して、サーバーが使用不可であると見なされる時間。
  • サーバーが使用不可と見なされる期間。

したがって、5に設定すると、合計10秒になります（5回のタイムアウト、5回の待機で再度連絡する）

ちなみに、max_failsのデフォルトはすでに1なので、設定する必要はありません。

実際にアクティブ/パッシブセットアップが必要な場合は、代わりに次の構成を使用する必要があります。

upstream backend  {
  server 172.31.9.1:8080;
  server 172.31.9.0:8080 backup;
}
2
Vasili Syrakis