web-dev-qa-db-ja.com

nginx-ロードバランサー-アップストリームノードがオフライン/ダウンしている場合のかなりの遅延

CentOS 6.5でnginx1.0.15を実行しています。 3つのアップストリームサーバーがあり、すべてが正常に機能しますが、停止をシミュレートし、アップストリームサーバーの1つを停止すると、応答時間にかなりの遅れが見られます（さらに5〜7秒）。ダウンしたサーバーをオンラインに戻すと、ラグがなくなります。また、私が気付いたもう1つの奇妙なことは、シミュレートされた停止サーバーでhttpdサービスを停止した場合、応答時間は正常であり、サーバーが完全にダウンしている場合にのみラグが発生します。

これが私のconfです：

_upstream prod_example_com {

    server app-a-1:51000;

    server app-a-2:51000;

    server app-a-3:51000;

}


server {

    # link:  http://wiki.nginx.org/MailCoreModule#server_name
    server_name example.com www.example.com *.example.com;

    #-----
    # Upstream logic
    #-----


    set $upstream_type prod_example_com;


    #-----

    include include.d/common.conf;

    # Configure logging
    access_log  /var/log/nginx/example/access/access.log access;
    error_log   /var/log/nginx/example/error.log error;

    location / {

        # link: http://wiki.nginx.org/HttpProxyModule#proxy_pass
        proxy_pass  http://$upstream_type$request_uri;

        # link: http://wiki.nginx.org/HttpProxyModule#proxy_set_header
        proxy_set_header    Host    $Host;
        proxy_set_header    X-Real-IP   $remote_addr;
        proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
    }

    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {

        # link: http://wiki.nginx.org/HttpProxyModule#proxy_pass
        proxy_pass  http://$upstream_type$request_uri;

        # link: http://wiki.nginx.org/HttpProxyModule#proxy_set_header
        proxy_set_header    Host    $Host;
        proxy_set_header    X-Real-IP   $remote_addr;
        proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;

        proxy_hide_header expires;
        proxy_hide_header Cache-Control

         # Even tho this reads like the older syntax, it is handled internally by nginx to set max age to now + 1 year
         expires max;

        # Allow intermediary caches the ability to cache the asset
        add_header Cache-Control "public";
    }
}
_

this のような同様の投稿で提案を試しました。そして、どうやら私のバージョンのnginxは、nginx docs で概説されているように、health_checksをサポートするには古すぎます。また、_max_fails=2_アップストリーム定義に_fail_timeout=120_と_app-a-3_を明示的に設定しようとしましたが、_app-a-3_はオフラインです。

-更新-

リクエストごとに、_app-a-3_が完全にダウンした場合の単一のリクエストの output を示します。私が異常に見ることができた唯一のことは、最初のイベントと次のイベントの間の3秒の遅れです。

-アップデート＃2-

数年前のように見えますが、Nginxはアクティブなヘルスチェックを追加するNginx Plusを作成することを決定しましたが、年間サポート契約が必要です。私が読んだいくつかの記事に基づいて、Nginxは会社を何百万ドルも稼ぐことにうんざりし、見返りは何も得られませんでした。

コメントで述べたように、私たちはブートストラップを行っており、$ 1,350の契約で投げる$$がありません。私はこれを見つけました repo これは機能を提供します。誰かがそれを使った経験があるかどうか疑問に思いますか？安定していますか？パフォーマー？

最悪のシナリオ私は弾丸を噛み、NginxPlusに基づいていると確信しているLinode「ノードバランサー」に月額$ 20の追加料金を支払う必要があります。唯一の問題は、いくつかの一般的なオプション以外に構成を制御できないため、1つのバランサーを介して複数の仮想ホストファイルをサポートする方法がなく、すべてのノードが同じデータセンターにある必要があることです。

-アップデート＃3-

ここにいくつか 包囲の結果 があります。 1番目と3番目のノードが処理しているリクエストの約75％しか処理できないため、2番目のノードが正しく構成されていないようです。また、2番目のノードをオフラインにしたときに、3番目の（パフォーマンスの高い）ノードをオフラインにした場合と同じくらいパフォーマンスが悪かったのも奇妙だと思いました。ロジックは、弱いリンク（2番目のノード）を削除すると、残りの2つのノードのパフォーマンスが弱いリンクよりも個別に向上するため、パフォーマンスが向上することを示します。

要するに：

_node 1, 2, 3 + my nginx = 2037 requests

node 1, 2 + my nginx  = 733 requests

node 1, 3 + my nginx = 639 requests (huh? these two perform better individually so together should be somewhere around ~1500 requests, based on 2000 requests when all nodes are up)

node 1, 3 + Linode Load Balancer = 790 requests

node 1, 2, 3 + Linode Load Balancer = 1,988 requests
_
centosnginxload-balancing
7
Mike Purcell

過去数週間、サポート契約を購入する前に、NGINXのセールス前エンジニアリングチームと協力して問題の解決を試みてきました。多くの調整とコラボレーションの後、単一のノードが完全に暗くなるとラグが増加すると推測できる唯一の結論は、問題のサーバーがすべてはるかに古いApache2.2を実行していたということです。

NGINXエンジニアはApache2.4.xを使用して問題を再現できなかったため、他の誰かが同じ状況に遭遇した場合は、それを修正することをお勧めします。ただし、私たちのプロジェクトでは、Apacheから完全に移行し、php-fpmを使用してNGINXを実装することに取り組んでいます。

最後に、アップストリームノードにヘルスチェックを発行し、ラウンドロビンを介してNGINX（FOSS）を実行しているアップストリームノードにリクエストを発行できるため、ロードバランサーとしてNGINX +（サポートコントラクトが必要）を使用する環境になります。

1
Mike Purcell

Nginxが機能するIPスタックを備えたサーバーの閉じたポートにリクエストを送信すると、すぐに否定的な確認応答が返されます。応答するサーバーがそこにない場合（またはファイアウォールで着信パケットをドロップした場合）、接続がタイムアウトするのを待つ必要があります。

ほとんどのロードバランサーには、ダウンしたサーバーをプリエンプティブにチェックするためのポーリングメカニズムやハートビートがあります。これらのオプションを調べることをお勧めします。ポーリングは通常、1分に1〜2回以上Webサーバーに対して実行されることはありませんが、サーバーのダウン状況のハートビートチェックは1秒ごとに行われる場合があります。

Nginxは最も洗練されたロードバランサーではありません。この種の問題が発生している場合は、他のオプションを検討することをお勧めします。

編集：多分このような何か？ http://www.howtoforge.com/setting-up-a-high-availability-load-balancer-with-haproxy-heartbeat-on-debian-lenny 。小規模なインストールの場合、個別のサーバーは必要ありません。Webサーバーボックスに配置するだけです。これにより、ロードバランシングが提供されますが、キャッシュは提供されません。心拍に応じてイカやワニスを制御するHAソリューションもあります。

5
mc0e

あなたが試すことができるいくつかのこと

  1. 公式リポジトリからnginxの最新バージョンに更新します http://nginx.org/en/linux_packages.html#stable
  2. Proxy_connect_timeout設定を減らして、テスト用に1秒などの非常に低い値に設定してみてください。 http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_connect_timeout
2
Rwky