Gateway Load Balancer (GWLB) は、ヘルスチェックを実行してバックエンドサーバーの可用性を判断します。 ヘルスチェック機能を有効にした後、GWLBがバックエンドサーバーに異常があると判断した場合、GWLBはバックエンドサーバーへのリクエストの転送を停止し、後続のリクエストを他のバックエンドサーバーに配信します。 GWLBがバックエンドサーバーが再び正常になったと判断した場合、GWLBはトラフィックをそのバックエンドサーバーに再び転送します。
ヘルスチェックステータス
次の表に、バックエンドサーバーのヘルスチェックのさまざまな状態を示します。
ヘルスチェックの状態 | 説明 |
初期化中 | GWLBインスタンスにヘルスチェックが設定され、バックエンドサーバーリストが初期化されています。 |
正常 | バックエンドサーバーが期待どおりに実行されています。 |
異常 | バックエンドサーバーがヘルスチェックに応答しなかったか、失敗しました。 |
待機 | バックエンドサーバーが使用されていません。 |
ヘルスチェックが無効 | ヘルスチェックは無効です。 |
制御ポリシー機能の動作
GWLBによって実行されるヘルスチェック中、リクエストメッセージはGeneveプロトコルを使用してカプセル化されません。
TCPヘルスチェック
次の図に示すように、TCPヘルスチェックの効率を向上させるために、GWLBはカスタマイズされたTCPプローブを送信してバックエンドサーバーの可用性をテストします。
GWLBがTCPヘルスチェックを実行する方法:
GWLBは、リスナーのヘルスチェック設定に基づいて、バックエンドサーバーの内部IPアドレスとヘルスチェックポートにTCP-SYNパケットを送信します。
バックエンドサーバーポートが稼働している場合、バックエンドサーバーはTCP-SYNパケットを受信した後にSYN-ACKパケットを返します。
応答タイムアウト期間が終了する前に、GWLBがバックエンドサーバーからSYN-ACKパケットを受信しない場合、バックエンドサーバーは異常であると宣言されます。 次に、GWLBはRSTパケットをバックエンドサーバーに送信してTCP接続を閉じます。
応答タイムアウト期間が終了する前に、GWLBがバックエンドサーバーからSYN-ACKパケットを受信した場合、バックエンドサーバーはヘルスチェックに合格します。 GWLBはACKパケットを送信し、すぐにRSTパケットを送信してTCP接続を閉じます。
HTTPヘルスチェック
次の図に示すように、HTTPヘルスチェックはGETプローブを介してステータス情報を取得します。
HTTPヘルスチェックのメカニズムは次のとおりです。
GWLBクラスター内のサーバーは、設定されたヘルスチェック設定に基づいて、HTTP GETリクエスト (設定された [ドメイン名] を含む) をバックエンドサーバーのプライベートネットワークIP + [ヘルスチェックポート] + [チェックパス] に送信します。
リクエストを受信した後、バックエンドサーバーは、対応するサービスの動作ステータスに基づいてHTTPステータスコードを返します。
GWLBクラスター内のサーバーが [応答タイムアウト期間] 内にバックエンドサーバーから情報を受信しない場合、サービスは応答しないと見なされ、ヘルスチェックは失敗したと見なされます。
GWLBクラスター内のサーバーが [応答タイムアウト期間] 内にバックエンドサーバーから情報を正常に受信した場合、返された情報は設定されたステータスコードと比較されます。 一致する場合、ヘルスチェックは成功と見なされ、一致しない場合は失敗と見なされます。
ヘルスチェックタイムウィンドウ
ヘルスチェック機能により、サービスの可用性が向上します。 ただし、異常なバックエンドサーバーによって頻繁に発生するフェイルオーバーは、システムの可用性に影響を与える可能性があります。 ヘルスチェックタイムウィンドウは、フェイルオーバーを制御するために導入されます。 フェイルオーバーは、バックエンドサーバーが時間枠内に特定の数のヘルスチェックに連続して合格または失敗した場合にのみ実行されます。 ヘルスチェックの時間枠は、次の要因によって決まります。
ヘルスチェック間隔: 2つのヘルスチェック間の時間。
応答タイムアウト: バックエンドサーバーが応答するのにかかる時間。
ヘルスチェックしきい値: バックエンドサーバーがヘルスチェックに合格または不合格になった連続回数。
ヘルスチェック時間ウィンドウは、次の式に基づいて計算されます。
ヘルスチェック失敗のタイムウィンドウ=応答タイムアウト × 異常しきい値 + ヘルスチェック間隔 × (異常しきい値-1)
ヘルスチェック成功のタイムウィンドウ=ヘルスチェック成功の応答時間 × 健康しきい値 + ヘルスチェック間隔 × (健康しきい値-1)
説明ヘルスチェックが成功した場合の応答時間は、ヘルスチェック要求が送信されてから応答が受信されるまでの時間です。 TCPヘルスチェックが設定されている場合、応答時間は短く、ほとんど無視できます。 HTTPヘルスチェックを設定する場合、応答時間はアプリケーションサーバーのパフォーマンスと負荷によって異なりますが、通常は数秒以内です。
ヘルスチェックの結果は、リクエスト転送に次の影響を与えます。
バックエンドサーバーがヘルスチェックに失敗した場合、新しいリクエストは他のバックエンドサーバーに配信されます。 GWLBはクライアントから引き続きアクセス可能です。
バックエンドサーバーがヘルスチェックに合格すると、新しいリクエストがバックエンドサーバーに配信されます。 GWLBはクライアントから引き続きアクセス可能です。
バックエンドサーバーでエラーが発生し、ヘルスチェックに失敗したが、ヘルスチェックによって異常と判断されなかった場合、リクエストはバックエンドサーバーに配信されます。 ただし、バックエンドサーバーにはリクエストにアクセスできません。 デフォルトでは、3回連続してヘルスチェックに失敗した場合、バックエンドサーバーは異常と宣言されます。
ヘルスチェック応答のタイムアウトとヘルスチェック間隔の例
この例では、次のヘルスチェック設定が使用されています。
応答タイムアウト時間: 5秒
ヘルスチェック間隔: 2秒
健康しきい値: 3回
不健康なしきい値: 3回
ヘルスチェック失敗のタイムウィンドウ=応答タイムアウト × 異常しきい値 + ヘルスチェック間隔 × (異常しきい値-1) 。 この例では、時間窓は式5 × 3 + 2 × (3 − 1) に基づいて19秒である。 バックエンドサーバーが19秒間応答しない場合、バックエンドサーバーは異常であると宣言されます。
次の図は、健康状態から不健康状態までの時間枠を示しています。
ヘルスチェック成功のタイムウィンドウ=ヘルスチェック成功の応答時間 × 健康しきい値 + 健康チェック間隔 × (健康しきい値 − 1) 。 この例では、式 (1 × 3) + 2 × (3 − 1) に基づいて、時間窓は7秒である。 バックエンドサーバーが7秒以内に応答する場合、バックエンドサーバーは正常であると宣言されます。
ヘルスチェックが成功した場合の応答時間は、ヘルスチェック要求が送信されてから応答が受信されるまでの時間です。 TCPヘルスチェックが設定されている場合、応答時間は短く、ほとんど無視できます。 HTTPヘルスチェックを設定する場合、応答時間はアプリケーションサーバーのパフォーマンスと負荷によって異なりますが、通常は数秒以内です。
次の図は、異常状態から正常状態までの時間枠を示しています。 次の図では、サーバがヘルスチェック要求に応答するまでの所要时间は1秒です。
HTTPヘルスチェックのドメイン名
HTTPヘルスチェックのドメイン名を指定できます。 This setting is optional. 一部のアプリケーションサーバーは、アプリケーションサーバーが要求を受け入れる前に、要求のホストヘッダーを確認する必要があります。 この場合、リクエストはHostヘッダーを運ぶ必要があります。 ドメイン名がヘルスチェック用に設定されている場合、GWLBはドメイン名をHostヘッダーに挿入します。 それ以外の場合、ヘルスチェック要求にはホストヘッダーが含まれません。 この場合、ヘルスチェック要求はサーバーによって拒否され、異常と宣言される可能性があります。
アプリケーションサーバーがリクエストのHostヘッダーを検証する場合、ヘルスチェック機能が期待どおりに機能するように、ヘルスチェック用のドメイン名を設定する必要があります。
関連ドキュメント
詳細については、「Configure and manage GWLB health checks」をご参照ください。