nginxのアップストリーム設定と機能の詳細な説明

設定例

アップストリームバックエンド{
  サーバー backend1.example.com 重み=5;
  サーバー backend2.example.com:8080;
  サーバー unix:/tmp/backend3;

  サーバーbackup1.example.com:8080バックアップ;
  サーバーbackup2.example.com:8080バックアップ;
}

サーバー{
  位置 / {
    proxy_pass http://backend;
  }
}

命令

サーバーのグループを定義します。 これらのサーバーは異なるポートでリッスンできます。 さらに、TCP と UNIX ドメイン ソケットをリッスンするサーバーを混在させることもできます。

例：

アップストリームバックエンド{
  サーバー backend1.example.com 重み=5;
  サーバー 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
  サーバー unix:/tmp/backend3;
}

デフォルトでは、nginx は重み付けされたラウンドロビン方式でサーバーにリクエストを分散します。 上記の例では、7 件のリクエストごとに、backend1.example.com へのリクエスト 5 件、2 番目のサーバーへのリクエスト 1 件、3 番目のサーバーへのリクエスト 1 件のように分散されます。 サーバーとの通信中にエラーが発生すると、利用可能なすべてのサーバーが試行されるまで、要求は次のサーバーに渡されます。 すべてのサーバーが失敗を返した場合、クライアントは最後に通信したサーバーの (失敗) 応答結果を取得します。

サーバー アドレス アドレスとその他のパラメータ パラメータを定義します。 アドレスはドメイン名または IP アドレスにすることができ、ポートはオプション、または「unix:」プレフィックスで指定された UNIX ドメイン ソケットへのパスになります。ポートが指定されていない場合は、ポート 80 が使用されます。 ドメイン名が複数の IP アドレスに解決される場合、基本的に複数のサーバーが定義されます。

次のパラメータを定義できます: weight=number はサーバーの重みを設定し、デフォルトは 1 です。 max_fails=number は、Nginx がサーバーと通信する際に失敗する試行回数を設定します。 fail_timeout パラメータで定義された期間内に失敗回数がこの値に達すると、Nginx はサーバーが使用不可であると見なします。次の fail_timeout 期間中、サーバーは再試行されません。 デフォルトの失敗回数は 1 です。 0 に設定すると、試行のカウントが停止され、サーバーが常に利用可能であると想定されます。 proxy_next_upstream、fastcgi_next_upstream、および memcached_next_upstream ディレクティブを使用して、失敗した試行としてカウントするものを設定できます。 デフォルトでは、http_404 ステータスは失敗した試行とは見なされません。 fail_timeout=時間設定

• 失敗した試行をカウントする期間。この時間内にサーバーが指定された回数の試行に失敗した場合、サーバーは使用不可とみなされます。
• サーバーが利用できないと見なされる期間。

デフォルトでは、タイムアウトは 10 秒です。バックアップはサーバーをバックアップ サーバーとしてマークします。プライマリ サーバーが利用できない場合、リクエストはこれらのサーバーに転送されます。 down はサーバーを永続的に利用不可としてマークし、ip_hash ディレクティブと一緒に使用できます。

例：

アップストリームバックエンド{
  サーバー backend1.example.com 重み=5;
  サーバー 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
  サーバー unix:/tmp/backend3;

  サーバーbackup1.example.com:8080バックアップ;
}

サーバー グループの負荷分散方法を指定します。要求は、クライアントの IP アドレスに基づいてサーバー間で分散されます。 IPv4 アドレスの最初の 3 バイト、または IPv6 の場合はアドレス全体がハッシュ キーとして使用されます。 この方法により、同じクライアントからのリクエストが同じサーバーに送信されるようになります。サーバーが利用できないと判断された場合を除き、これらのクライアント要求は他のサーバー、おそらく同じサーバーに転送されます。

IPv6 アドレスはバージョン 1.3.2 および 1.2.2 以降でサポートされます。

サーバーの 1 つを一時的に削除する場合は、down パラメータを追加する必要があります。これにより、現在のクライアント IP アドレスのハッシュ分布が保持されます。

例：

アップストリームバックエンド{
  ip_ハッシュ;

  サーバー backend1.example.com;
  サーバー backend2.example.com;
  サーバー backend3.example.com がダウンしています。
  サーバー backend4.example.com;
}

バージョン 1.3.1 および 1.2.2 以降では、ip_hash 負荷分散方法でサーバーの重み値の設定がサポートされています。

このディレクティブはバージョン 1.1.4 で登場しました。

アップストリーム サーバーへの接続のキャッシュを有効にします。

接続パラメータは、各ワーカー プロセスがバックエンド サーバーと維持する接続の最大数を設定します。これらの維持された接続はキャッシュされます。 接続数がこの値より大きい場合、最も長く使用されていない接続が閉じられます。

keepalive ディレクティブは、Nginx プロセスがアップストリーム サーバーに対して確立できる接続の総数を制限しないことに注意してください。 必要に応じて常に新しい接続が作成されます。アップストリーム サーバーが追加の着信接続を処理できるように、接続パラメータを少し低く設定する必要があります。

memcached アップストリーム サーバー接続キープアライブを構成する例:

アップストリーム memcached_backend {
  サーバー 127.0.0.1:11211;
  サーバー 10.0.0.2:11211;

  キープアライブ32;
}

サーバー{
  ...

  場所 /memcached/ {
    $memcached_key $uri を設定します。
    memcached_pa​​ss memcached_backend;
  }

}

HTTP プロキシの場合、proxy_http_version ディレクティブを「1.1」に設定し、「Connection」ヘッダーの値をクリアする必要があります。

アップストリーム http_backend {
  サーバー 127.0.0.1:8080;

  キープアライブ 16;
}

サーバー{
  ...

  場所 /http/ {
    proxy_pass http://http_backend;
    プロキシ_http_バージョン 1.1;
    proxy_set_header 接続 "";
    ...
  }
}

あるいは、「Connection: Keep-Alive」ヘッダーを送信することで、HTTP/1.0 プロトコルの永続的な接続を実現することもできます。ただし、これはお勧めできません。

FastCGI サーバーの場合、接続キープアライブを機能させるには fastcgi_keep_conn ディレクティブを設定する必要があります。

アップストリーム fastcgi_backend {
  サーバー 127.0.0.1:9000;

  キープアライブ8;
}

サーバー{
  ...

  場所 /fastcgi/ {
    fastcgi_pass fastcgi_backend;
    fastcgi_keep_conn をオンにします。
    ...
  }
}

デフォルトのラウンドロビン方式以外の負荷分散方式を使用する場合は、keepalive ディレクティブの前に設定する必要があります。

SCGI および uwsgi プロトコルのキープアライブ接続を実装する予定はありません。

このディレクティブはバージョン 1.3.1 および 1.2.2 で登場しました。

サーバー グループの負荷分散方法を指定します。要求は、重み値に応じて、最もアクティブな接続が少ないサーバーに送信されます。 このようなサーバーが複数ある場合は、加重ラウンドロビン方式を使用してみてください。

埋め込み変数

ngx_http_upstream_module モジュールは、次の埋め込み変数をサポートしています。

$upstream_addr には、サーバーの IP アドレスとポート、または UNIX ドメイン ソケットへのパスが保持されます。 リクエスト処理中に複数のサーバーが試行される場合、それらのアドレスは連結され、コンマで区切られます。例: "192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock"。 「X-Accel-Redirect」ヘッダーまたは error_page を介してサーバー間で内部リダイレクトがある場合、これらのサーバー グループはコロンで区切られます。例: 「192.168.1.1:80、192.168.1.2:80、unix:/tmp/sock : 192.168.10.1:80、192.168.10.2:80」。 $upstream_response_time は、ミリ秒の精度でサーバー応答時間 (出力) を秒単位で保持します。 複数の応答が表示される場合も、カンマとコロンで区切られます。 $upstream_status はサーバーの応答コードを保持します。 複数の応答が表示される場合も、カンマとコロンで区切られます。 $upstream_http_... はサーバーの応答ヘッダーの値を保持します。たとえば、「Server」応答ヘッダーの値は、$upstream_http_server 変数を通じて取得できます。 最後の応答のヘッダーのみが保持されることに注意してください。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。