Nginx http ヘルスチェック構成プロセス分析

パッシブチェック

パッシブ ヘルス チェックでは、NGINX と NGINX Plus はイベントの発生を監視し、失敗した接続の回復を試みます。それでも回復できない場合は、NGINX Open Source と NGINX Plus はサーバーを使用不可としてマークし、再度アクティブとしてマークされるまで一時的にリクエストの送信を停止します。

アップストリーム サーバーが利用不可としてマークされる条件は、include ブロック内の server ディレクティブのアップストリーム パラメータを使用して、各アップストリーム サーバーに対して定義されます。

• fail_timeout - サーバーが利用不可とマークされるまでに発生する必要のある失敗の試行回数と、サーバーが利用不可とマークされるまでにかかる時間を設定します (デフォルトは 10 秒)。
• max_fails - サーバーが利用不可とマークされるまでの fail_timeout 期間中に発生する必要がある失敗した試行回数を設定します (デフォルトは 1 回)。 次の例では、NGINX がサーバーにリクエストを送信できなかった場合、または 30 秒以内に 3 回応答を受信しなかった場合、サーバーは 30 秒間使用できないと見なされます。

アップストリームバックエンド{
  サーバー backend1.example.com;
  サーバー backend2.example.com max_fails=3 fail_timeout=30s;
}

グループ内にサーバーが 1 つしかない場合、fail_timeout および max_fails パラメーターは無視され、サーバーが使用不可としてマークされることはありません。

サーバーの起動が遅い

最近復元されたサーバーは接続で簡単に圧倒され、サーバーが再び利用不可とマークされる可能性があります。スロースタートにより、アップストリーム サーバーは回復または使用可能になった後、重みを 0 から公称値まで徐々に復元できます。これは、アップストリーム サーバー モジュールの slow_start パラメータを指定することで実行できます。

アップストリームバックエンド{
  サーバー backend1.example.com slow_start=30s;
  サーバー backend2.example.com;
  サーバー 192.0.0.1 バックアップ;
}

注: グループ内にサーバーが 1 つしかない場合、slow_start パラメータは無視され、サーバーが使用不可としてマークされることはありません。スロースタートは、NGINX Plus 専用の機能です。

NGINX Plus のアクティブ チェック

NGINX Plus は、各サーバーに特別なヘルス チェック要求を送信し、正しい応答を確認することで、アップストリーム サーバーのヘルスを定期的にチェックできます。

アクティブヘルスチェックを有効にするには:

1. リクエスト (proxy_pass) をアップストリーム グループに渡すロケーション ブロックに health_check ディレクティブを含めます。

サーバー{
 位置 / {
   proxy_pass http://backend;
   ヘルスチェック;
 }
}

このスニペットは、 location / に一致するすべてのリクエストを backend と呼ばれるアップストリーム グループに渡すサーバーを定義します。また、health_check ディレクティブを使用した高度なヘルス モニタリングも有効になります。デフォルトでは、NGINX Plus は 5 秒ごとに「/」バックエンドのグループ内の各サーバーにリクエストを送信します。

通信エラーまたはタイムアウトが発生した場合 (サーバーが 200 ～ 399 の範囲外のステータス コードを返す場合)、ヘルス チェックは失敗します。サーバーは異常とマークされ、ヘルスチェックに再度合格するまで、NGINX Plus はクライアント要求をサーバーに送信しません。

オプション: たとえば、同じホスト上の多数のサービスのヘルスを監視するために、ヘルス チェックに使用する別のポートを指定できます。 health_check ディレクティブの port パラメータを使用して新しいポートを指定します。

サーバー{
 位置 / {
   proxy_pass http://backend;
   ヘルスチェックポート=8080;
 }
}

2. アップストリーム サーバー グループで、zone ディレクティブを使用して共有メモリ ゾーンを定義します。

http {
 アップストリームバックエンド{
   ゾーンバックエンド64k;
   サーバー backend1.example.com;
   サーバー backend2.example.com;
   サーバー backend3.example.com;
   サーバー backend4.example.com;
 }
}

この領域はすべてのワーカー プロセス間で共有され、アップストリーム グループの構成が格納されます。これにより、ワーカー プロセスは同じカウンター セットを使用して、グループ内のサーバーからの応答を追跡できるようになります。

アクティブヘルスチェックのデフォルト値は、health_check ディレクティブのパラメータを使用して上書きできます。

位置 / {
  proxy_pass http://backend;
  health_check 間隔=10 失敗=3 合格=2;
}

ここで、間隔パラメータはヘルスチェック間の遅延をデフォルトの 5 秒から 10 秒に増やします。 fails パラメータでは、サーバーが 3 回のヘルス チェックに失敗すると、サーバーが異常であるとマークされます (デフォルト値から)。最後に、passes パラメータは、デフォルト値ではなく、サーバーが再び正常とマークされる前に 2 つの連続したチェックに合格する必要があることを意味します。

要求されたURLを指定してください

ヘルスチェック要求のルートを設定するには、health_check ディレクティブで uri パラメータを指定します。

位置 / {
  proxy_pass http://backend;
  health_check uri=/some/path;
}

指定された URI は、アップストリーム ブロック内のサーバーに設定されたサーバー ドメイン名または IP アドレスに追加されます。上記で宣言したサンプル バックエンド グループの最初のサーバーの場合、ヘルス チェックは URI http://backend1.example.com/some/path を要求します。

カスタム条件の定義

サーバーがヘルスチェックに合格するために応答が満たす必要があるカスタム条件を設定できます。条件は、health_check ディレクティブの match パラメータで参照される match ブロックで定義されます。

1. http {} レベルで、match {} ブロックを指定して名前を付けます。例: 'server_ok'

http {
 #... 
 server_okに一致{
   # テストはここにあります     
 }
}

2. ブロックの一致パラメータと一致パラメータブロックの名前を指定して health_check を実行します。

http {
 #... 
 server_okに一致{
   ステータス200-399;
   body !~ "メンテナンスモード";
 }
 サーバー{
   #...     
   位置 / {
     proxy_pass http://backend;
     health_check 一致 = server_ok;
   }
 }
}

レスポンスのステータスコードが200～399の範囲にあり、レスポンス本文に「メンテナンスモード」という文字列が含まれていない場合、ヘルスチェックは合格となります。

match ディレクティブにより、NGINX Plus はステータス コード、ヘッダー フィールド、および応答本文を検査できるようになります。このディレクティブを使用して、ステータスが指定された範囲内にあること、応答にヘッダーが含まれていること、またはヘッダーまたは本文が正規表現と一致していることを確認します。一致ディレクティブには、ステータス条件、本文条件、および複数のタイトル条件を含めることができます。サーバーがヘルス チェックに合格するには、応答が一致ブロックで定義されたすべての条件を満たす必要があります。

たとえば、次の一致ディレクティブは、ステータス コード 200、正確な値 text/html を持つ Content-Type ヘッダー、およびページ内のテキスト「Welcome to nginx!」を含む応答と一致します。

マッチ歓迎{
  ステータス 200;
  ヘッダー Content-Type = text/html;
  body ~ "nginx へようこそ！";
}

次の例では、感嘆符 (!) を使用して、ヘルス チェックに合格してはならない応答の特性を定義します。この場合、ヘルス チェックは 301、302、303、または 307 以外のステータス コードで、Refresh ヘッダーなしで合格します。

一致しないリダイレクト{
  ステータス! 301-303 307;
  ヘッダー! 更新;
}

ヘルス チェックは、FastCGI、memcached、SCGI、uwsgi、さらには TCP や UDP などの HTTP 以外のプロトコルでも有効にできます。

多くの優れた機能を使用するには、Nginx Plus が必要です。

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