ヘルスチェックの作成

Google Cloud Platform(GCP)にはヘルスチェックのメカニズムがあり、VM インスタンスがトラフィックに適切に反応しているかどうかが判定されます。このドキュメントでは、ロードバランサのヘルスチェックの作成と使用の方法について説明します。

このページでは、読者がヘルスチェックのコンセプトと GCP のファイアウォール ルールについて理解していることを前提としています。

ヘルスチェックのカテゴリ、プロトコル、ポート

GCP では、ヘルスチェックがカテゴリとプロトコル別にまとめられています。

ヘルスチェックには、ヘルスチェックレガシー ヘルスチェックの 2 つのカテゴリがあります。それぞれのカテゴリで、対応するプロトコル セットと、ヘルスチェックに使用するポートの指定方法が異なります。

ロードバランサの大半で非レガシー ヘルスチェックが使用されますが、ネットワーク負荷分散ではレガシー ヘルスチェックの使用が要求されます。適切なカテゴリ、プロトコル、ポートの指定方法の決定については、ヘルスチェックのコンセプトのページのヘルスチェックを選択するをご覧ください。

ヘルスチェックに選択したプロトコルをロードバランサで使用されるプロトコルと一致させる必要はありません。また、一致させることが不可能な場合もあります。詳細は、プロトコルとロードバランサをご覧ください。

「ヘルスチェック」という用語は、レガシー ヘルスチェックを指すものではありません。このドキュメントでレガシー ヘルスチェックを指す場合は、はっきり「レガシー ヘルスチェック」と表記します。

ヘルスチェックの作成

GCP では、GCP Console でロードバランサのバックエンド構成の完了時にヘルスチェックを作成または選択できます。

また、ヘルスチェックは GCP Console でロードバランサの構成とは別個に作成することもできます。これは、最初にヘルスチェックを作成する必要がある場合や、複数のロードバランサで同じヘルスチェックを使用する必要がある場合に実用的です。ヘルスチェックの作成には、GCP Console、gcloud コマンドライン ツール、REST API を使用できます。このセクションの背景情報を確認したら、ヘルスチェックの作成と変更に進みます。

ネットワーク ロードバランサでは、レガシー ヘルスチェックを使用する必要があります。これは、GCP Console でネットワーク ロードバランサのバックエンド構成の完了後に作成または選択できます。レガシー ヘルスチェックを個別に作成するには、gcloud コマンドライン ツールまたは REST API を使用する必要があります。詳細は、レガシー ヘルスチェックをご覧ください。

すべてのヘルスチェックで使用されるフラグ

次に示すフラグは、プロトコルに関係なくすべてのヘルスチェックに共通で使用されます。

gcloud compute health-checks create PROTOCOL HEALTH_CHECK_NAME \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    ...additional flags

ここで

  • PROTOCOL には、ヘルスチェックに使用されるプロトコルを指定します。有効なオプションは、httphttpshttp2ssl、および tcp です。
  • HEALTH_CHECK_NAME は、ヘルスチェックの名前です。1 つのプロジェクト内では、ヘルスチェックのそれぞれに一意の名前を付ける必要があります。
  • DESCRIPTION は省略可能な説明です。
  • CHECK_INTERVAL は、1 回のヘルスチェック プローブ システムの接続の開始からその次の回の開始までの時間です。単位は秒です。省略した場合、GCP では 5s(5 秒)の値が使用されます。
  • TIMEOUT は、GCP でプローブに対するレスポンスを待ち受ける時間です。TIMEOUT の値は、CHECK_INTERVAL 以下に設定する必要があります。単位は秒です。省略した場合、GCP では 5s(5 秒)の値が使用されます。
  • HEALTHY_THRESHOLDUNHEALTHY_THRESHOLD はそれぞれ、VM インスタンスが正常であるか、正常でないかを判定する際に要求されるプローブの成功または失敗の連続回数を示します。いずれのしきい値も省略されている場合は、デフォルトの 2 が使用されます。
  • 追加フラグは、ポートとオプションを指定するフラグで、PROTOCOL に固有です。これらのフラグについては、以降のセクションで説明します。

ポート指定フラグ

プロトコルに加えて、ヘルスチェック用のポートを指定する必要があります。ポートの指定方法は、ロードバランサの種類とバックエンド サービスで使用されるバックエンドの種類によって異なります。次の表は、有効なロードバランサとバックエンドの組み合わせに対するポート指定オプションです。表で使用される「インスタンス グループ」という用語は、アンマネージド インスタンス グループ、ゾーンのマネージド インスタンス グループ、リージョンのマネージド インスタンス グループを指します。

ヘルスチェックで使用できるポート指定は 1 種類のみです。

ロードバランサ バックエンド タイプ ポートの指定
内部 TCP / UDP 負荷分散 インスタンス グループ 次のいずれかを使用します 1
--port: 1 から 65535 までの番号でポートを指定します。
--port-name: インスタンス グループによってエクスポートされた任意の名前付きポートを指定します。
内部ロードバランサのバックエンド サービスにはどのような形でもポートの指定がないため、内部ロードバランサと関連付けられたヘルスチェックに --use-serving-port フラグは使用できません。
内部 HTTP(S) 負荷分散
TCP プロキシ負荷分散
SSL プロキシ負荷分散
HTTP(S) 負荷分散
ネットワーク エンドポイント グループ 次のいずれかを使用します 1
--port: 1 から 65535 までの番号でポートを指定します。
--use-serving-port2 : ネットワーク エンドポイント グループの各エンドポイントで指定されたポートを使用します。
インスタンス グループ 次のいずれかを使用します 1
--port: 1 から 65535 までの番号でポートを指定します。
--port-name: インスタンス グループによってエクスポートされた任意の名前付きポートを指定します。
--use-serving-port2 : インスタンス グループの名前付きポートで、バックエンド サービスで使用されるように構成されているものと同じものを使用します。

1 ポート指定の組み合わせは次のように解決されます。

  • --use-serving-port が指定された場合、--port--port-nameいずれも指定できません。
  • --port--port-name の両方が指定されている場合、--port が優先されます。
  • これらいずれの指定もない場合のデフォルトは --port=80 です。

2 ベータ版: --use-serving-port が必要な場合は、次のベータ版の gcloud コマンドを使用する必要があります。

HTTP、HTTPS、HTTP/2 ヘルスチェックのオプション フラグ

HTTP、HTTPS、HTTP/2 のヘルスチェックには、共通のフラグとポートの指定に加えて、次のオプションのフラグも使用できます。次の例では、間隔、タイムアウト値、正常性しきい値基準にデフォルト値を使用し、ポート 80 を使用する hc-http-port-80 という名前の HTTP ヘルスチェックを作成します。

gcloud compute health-checks create http hc-http-port-80 \
    --description="Simple HTTP port 80 health check" \
    --check-interval=5s \
    --timeout=5s \
    --healthy-threshold=2 \
    --unhealthy-threshold=2 \
    --port=80 \
    --host=HOST \
    --proxy-header=PROXY_HEADER \
    --request-path=REQUEST_PATH \
    --response=RESPONSE
  • プロトコルには、http(この例)、https、または http2 を使用できます。
  • HOST を使用すると、ホストの HTTP ヘッダーを指定できます。省略した場合は、ロードバランサの転送ルールの IP アドレスが使用されます。
  • PROXY_HEADER は、NONEPROXY_V1 のいずれかにする必要があります。この値を省略した場合は、GCP では NONE が使用されます。PROXY_V1 の値にはヘッダー PROXY UNKNOWN\r\n が追加されます。
  • REQUEST_PATH では、ヘルスチェック リクエストの送信時に GCP が使用する URL パスを指定します。省略した場合、ヘルスチェック リクエストは / に送信されます。
  • RESPONSE では、想定される任意のレスポンスを指定します。レスポンスの文字列は次のルールに従って表します。
    • レスポンス文字列は、ASCII 文字、数字、スペースで構成する必要があります。
    • レスポンス文字列は最長 1,024 文字です。
    • ワイルドカード マッチングはサポートされていません
    • コンテンツ ベースのチェックでは、反転法はサポートされません。たとえば、! などの演算子は HAProxy ではサポートされません。

受信されたレスポンス本文の最初の 1,024 バイトのうちの「どこかで」待ち受けるレスポンス文字列を検出すると同時に、HTTP ステータスが 200(OK)の場合にプローブは正常終了と見なされます。

ヘルスチェック プローブの正常完了条件は、--request-path フラグと --response フラグによって変更されます。

SSL と TCP ヘルスチェックのオプションのフラグ

SSL と TCP のヘルスチェックには、共通のフラグとポートの指定に加えて、次のオプションのフラグを使用できます。次の例では、間隔、タイムアウト値、正常性しきい値基準にデフォルト値を使用し、ポート 3268 を使用する、hc-tcp-3268 という名前の TCP ヘルスチェックを作成します。

gcloud compute health-checks create tcp hc-tcp-3268 \
    --description="Health check: TCP 3268" \
    --check-interval=5s \
    --timeout=5s \
    --healthy-threshold=2 \
    --unhealthy-threshold=2 \
    --port=3268 \
    --proxy-header=PROXY_HEADER \
    --request=REQUEST_STRING \
    --response=RESPONSE_STRING
  • プロトコルには、tcp(この例)または ssl を使用できます。
  • PROXY_HEADER は、NONEPROXY_V1 のいずれかにする必要があります。この値を省略した場合は、GCP では NONE が使用されます。PROXY_V1 の値にはヘッダー PROXY UNKNOWN\r\n が追加されます。
  • REQUEST_STRING: TCP または SSL セッションが確立されると送信される最長 1024 文字の ASCII 文字を指定できます。
  • RESPONSE_STRING: レスポンスとして想定される最長 1,024 文字の ASCII 文字列を指定できます。

ヘルスチェック プローブの正常完了条件は、--request フラグと --response フラグによって変更されます。--response フラグを単独で、あるいは --request フラグとともに使用する場合は、返されるレスポンスがレスポンスの想定文字列と完全に一致する必要があります。

ヘルスチェックの作成と変更

ヘルスチェックを変更しても、レガシー ヘルスチェックには変換できません。逆方向の変換も同様です。

Console

GCP Console には、ヘルスチェックとレガシー ヘルスチェックの両方がリストされます。既存のヘルスチェックやレガシー ヘルスチェックを編集することはできます。ただし、GCP Console のヘルスチェック ページではレガシー ヘルスチェックを作成できません。

ヘルスチェックを作成するには、次の手順を行います。

  1. Google Cloud Platform Console の [ヘルスチェック] ページに移動します。
    [ヘルスチェック] ページに移動
  2. [ヘルスチェックを作成] をクリックします。
  3. ヘルスチェックの作成ページに、次の情報を入力します。
    • 名前: ヘルスチェックの名前を指定します。
    • 説明: 必要に応じて、説明を入力します。
    • プロトコル: ヘルスチェック プロトコルを選択します。
    • ポート: ポート番号を指定します。
    • プロキシ プロトコル: 必要に応じてヘルスチェック プローブ システムから送信されたリクエストにプロキシ ヘッダーを追加できます。
    • リクエストパスとレスポンス: HTTP、HTTPS、HTTP2 のプロトコルの場合は、必要に応じてヘルスチェック プローブ システムが接続する URL パスを指定できます。詳しくは、HTTP、HTTPS、HTTP/2 ヘルスチェックのオプション フラグをご覧ください。
    • リクエストレスポンス: TCP および SSL プロトコルでは、送信する ASCII テキスト文字列とレスポンスの想定文字列を指定できます。詳しくは、SSL および TCP ヘルスチェックのオプション フラグをご覧ください。
    • チェック間隔: 1 回のプローブの開始から次の回のブローブ開始までの時間を指定します。
    • タイムアウト: GCP でプローブに対するレスポンスを待ち受ける時間を定義します。この値は、チェック間隔の値以下にする必要があります。
    • 正常しきい値: インスタンスが正常であると判定する際に要求されるプローブ成功の連続回数を定義します。
    • 異常しきい値: インスタンスが正常でないと判定する際に要求されるプローブ失敗の連続回数を定義します。
  4. [作成] をクリックします。

ヘルスチェックを編集するには、次の手順を行います。

  1. Google Cloud Platform Console の [ヘルスチェック] ページに移動します。
    [ヘルスチェック] ページに移動
  2. ヘルスチェックをクリックすると詳細が表示されます。
  3. ヘルスチェックを変更する必要がある場合は、[編集] をクリックして次の操作を行います。
    • 必要に応じてパラメータを変更します。
    • [保存] をクリックします。

gcloud

  1. 次の gcloud コマンドを使用して、ヘルスチェックを一覧表示します。

    gcloud compute health-checks list
    
  2. ヘルスチェックを特定し、適切な gcloud コマンドを使用して describe を実行します。HEALTH_CHECK_NAME はヘルスチェックの名前に置き換えてください。

    gcloud compute health-checks describe HEALTH_CHECK_NAME
    
  3. ヘルスチェックを変更するには、適切な gcloud コマンドを使用します。HEALTH_CHECK_NAME はヘルスチェックの名前に置き換えてください。ヘルスチェックの名前とプロトコル以外は、共通フラグポート指定フラグオプションのフラグのいずれも変更可能です。gcloud compute health-checks update コマンドを使用して既存のヘルスチェックを変更すると、省略したフラグの事前構成された設定は保持されます。次のコマンドは、チェック間隔、タイムアウト、リクエストパスを変更してヘルスチェックのサンプルを変更します。

    gcloud compute health-checks update http hc-http-port-80 \
        --check-interval=20s \
        --timeout=15s \
        --request-path="/health"
    

API

  1. healthChecks.list API 呼び出しを使用すると、ヘルスチェックを一覧表示できます。

  2. ヘルスチェックの名前がわかっている場合は、healthChecks.get API 呼び出しで構成の詳細を取得できます。

  3. ヘルスチェックを変更する必要がある場合は、次の API 呼び出しを使用します。

レガシー ヘルスチェック

レガシー ヘルスチェックの作成

このセクションでは、ネットワーク ロードバランサに必要なレガシー ヘルスチェックを作成する方法について説明します。

Console

GCP Console のヘルスチェックのページには、ヘルスチェックとレガシー ヘルスチェックの両方が表示されます。しかし、GCP Console でレガシー ヘルスチェックを作成することはできません。レガシー ヘルスチェックは、GCP Console のネットワーク ロードバランサのページでのみ作成できます。

gcloud

ネットワーク ロードバランサのレガシー ヘルスチェックを作成するには、次の gcloud コマンドを使用します。

gcloud compute LEGACY_CHECK_TYPE create LEGACY_HEALTH_CHECK_NAME \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    --host=HOST \
    --port=PORT \
    --request-path=REQUEST_PATH

ここで

  • LEGACY_CHECK_TYPE は、レガシーの HTTP ヘルスチェックの場合は http-health-checks、レガシーの HTTPS ヘルスチェックの場合は https-health-checks です。ネットワーク ロードバランサのレガシー ヘルスチェックを作成する場合は、http-health-checks を使用する必要があります。
  • LEGACY_HEALTH_CHECK_NAME は、レガシー ヘルスチェックの名前です。各レガシー ヘルスチェックにはプロジェクト内で一意の名前を付ける必要があります。
  • DESCRIPTION は省略可能な説明です。
  • CHECK_INTERVAL は、1 回のプローブの開始から次の回のブローブ開始までの時間です。単位は秒です。省略した場合、GCP では 5s(5 秒)の値が使用されます。
  • TIMEOUT は、GCP でプローブに対するレスポンスを待ち受ける時間です。TIMEOUT の値は、CHECK_INTERVAL 以下に設定する必要があります。単位は秒です。省略した場合、GCP では 5s(5 秒)の値が使用されます。
  • HEALTHY_THRESHOLDUNHEALTHY_THRESHOLD はそれぞれ、VM インスタンスが正常であるか、正常でないかを判定する際に要求されるプローブの成功または失敗の連続回数を示します。いずれのしきい値も省略されている場合は、デフォルトの 2 が使用されます。
  • HOST を使用すると、ホストの HTTP ヘッダーを指定できます。省略した場合は、ロードバランサの転送ルールの IP アドレスが使用されます。
  • PORT には、ポート番号を指定できます。省略した場合、GCP では 80 が使用されます。
  • REQUEST_PATH では、ヘルスチェック リクエストの送信時に GCP が使用する URL パスを指定します。省略した場合、ヘルスチェック リクエストは / に送信されます。

API

ネットワーク ロードバランサに対して次の API 呼び出しを使用すると、レガシー ヘルスチェックを作成できます。

レガシー ヘルスチェックの表示と変更

Console

GCP Console には、ヘルスチェックとレガシー ヘルスチェックの両方がヘルスチェック ページにリストされます。既存のレガシー ヘルスチェックを編集するには、次の手順を行います。

  1. Google Cloud Platform Console の [ヘルスチェック] ページに移動します。
    [ヘルスチェック] ページに移動
  2. ヘルスチェックをクリックすると詳細が表示されます。
  3. ヘルスチェックを変更する必要がある場合は、[編集] をクリックして次の操作を行います。
    • 必要に応じてパラメータを変更します。
    • [保存] をクリックします。

gcloud

  1. 次の gcloud コマンドを使用して、ネットワーク ロードバランサのレガシー ヘルスチェックを一覧表示します。

    gcloud compute http-health-checks list
    
  2. レガシー ヘルスチェックを特定し、適切な gcloud コマンドを使用して describe を実行します。LEGACY_HEALTH_CHECK_NAME はレガシー ヘルスチェックの名前に置き換えてください。

    gcloud compute http-health-checks describe LEGACY_HEALTH_CHECK_NAME
    
  3. レガシー ヘルスチェックを変更する必要がある場合は、適切な gcloud コマンドを使用します。LEGACY_HEALTH_CHECK_NAME はレガシー ヘルスチェックの名前に置き換えてください。gcloud を使用してヘルスチェックを変更した場合、省略したフラグの既存の設定は保持されます。

    gcloud compute http-health-checks update LEGACY_HEALTH_CHECK_NAME \
        ...other options
    

    ここで、...other options は、レガシー ヘルスチェックを作成するためのオプションです。

API

  1. ネットワーク ロードバランサのレガシー ヘルスチェックを一覧表示するには、次の API 呼び出しを使用します。

  2. レガシー ヘルスチェックの名前がわかっている場合は、次の API 呼び出しで構成の詳細を取得できます。

  3. レガシー ヘルスチェックを変更する必要がある場合は、次の API 呼び出しを使用します。

ファイアウォール ルール

ヘルスチェック プローバーの IP 範囲からのトラフィックを許可するには、負荷分散対象のすべての VM に適用される上りファイアウォール ルールを作成する必要があります。次の例では、ターゲットタグによって VM インスタンスに適用されるファイアウォール ルールを作成します。ファイアウォール ルールのターゲットの指定の詳細については、「ファイアウォール ルールの概要」ターゲットの説明ネットワーク タグの構成をご覧ください。

次の各例では、GCP ヘルスチェック システムから VM インスタンスへのすべての TCP トラフィックが許可されます。この TCP トラフィックには SSL、HTTP、HTTPS、HTTP/2 のトラフィックが含まれます。必要に応じて、ポートを TCP プロトコルとともに指定することもできます。ただし、ポートを指定すると、ファイアウォール ルールが特定のヘルスチェックに限定される場合があります。プロトコルとポートに tcp:80 を使用すると、ポート 80 で TCP トラフィックが許可されます。このため GCP は VM に HTTP を使用してポート 80 で接続できますが、HTTPS を使用したポート 443 での接続はできないことになります。

ヘルスチェックのルール

次の例では、以下のロードバランサの上りファイアウォール ルールを作成します。

  • 内部 TCP / UDP 負荷分散(ヘルスチェック)
  • 内部 HTTP(S) 負荷分散(ヘルスチェック)
  • TCP プロキシ負荷分散(ヘルスチェック)
  • SSL プロキシ負荷分散(ヘルスチェック)
  • HTTP(S) 負荷分散(ヘルスチェックおよびレガシー ヘルスチェック)

これらのロードバランサの場合、ヘルスチェックのソース IP 範囲は次のようになります(HTTP(S) 負荷分散に使用する場合はレガシー ヘルスチェックを含む)。

  • 35.191.0.0/16
  • 130.211.0.0/22

内部 HTTP(S) 負荷分散の場合のみ、ソース IP 範囲はプロキシ専用サブネット内のすべての IP アドレスになります。

ネットワーク負荷分散のためのルールを作成する必要がある場合は、次のセクションのネットワーク負荷分散のためのルールをご覧ください。

Console

  1. Google Cloud Platform Console で [ファイアウォール ルール] ページに移動します。
    [ファイアウォール ルール] ページに移動
  2. [ファイアウォール ルールを作成] をクリックします。
  3. ファイアウォール ルールの作成ページで、次の情報を入力します。
    • 名前: ルールの名前を指定します。この例では、fw-allow-health-checks を使用します。
    • ネットワーク: VPC ネットワークを選択します。
    • 優先度: 優先度の数値を入力します。数字が小さいほど優先度が高くなります。このファイアウォール ルールには、上りトラフィックを拒否する可能性があるその他のルールよりも高い優先度を設定してください。
    • トラフィックの方向: [上り] を選択します。
    • 一致したときのアクション: [許可] を選択します。
    • ターゲット: [指定されたターゲットタグ] を選択し、[ターゲットタグ] テキスト ボックスにタグを入力します。この例では allow-health-checks を使用します。
    • ソースフィルタ: [IP 範囲] を選択します。
    • ソース IP の範囲: 35.191.0.0/16,130.211.0.0/22
    • 許可対象プロトコル / ポート: tcp を使用します。TCP は、すべてのヘルスチェック プロトコルの基礎となるプロトコルです。
    • [作成] をクリックします。
  4. 負荷分散対象の各インスタンスで、ネットワーク タグを追加して、新しい上りファイアウォール ルールが適用されるようにします。この例では、ネットワーク タグに allow-health-checks を使用します。

gcloud

  1. 次の gcloud コマンドを使用して、fw-allow-health-checks という名前のファイアウォール ルールを作成します。このルールは allow-health-checks タグを使用してネットワーク内のインスタンスに対する受信接続を許可します。NETWORK_NAME はネットワーク名に置き換えてください。

    gcloud compute firewall-rules create fw-allow-health-checks \
        --network NETWORK_NAME \
        --action ALLOW \
        --direction INGRESS \
        --source-ranges 35.191.0.0/16,130.211.0.0/22 \
        --target-tags allow-health-checks \
        --rules tcp
  2. 負荷分散対象の各インスタンスで、ネットワーク タグを追加して、新しい上りファイアウォール ルールが適用されるようにします。この例では、ネットワーク タグに allow-health-checks を使用します。

詳細は、gcloud ファイアウォール ルールのドキュメントAPI ドキュメントをご覧ください。

ネットワーク負荷分散のルール

次の例では、レガシー ヘルスチェックを必要とするネットワーク負荷分散の上りファイアウォール ルールを作成します。ネットワーク負荷分散のレガシー ヘルスチェックのソース IP 範囲は次のとおりです。

  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22

Console

  1. Google Cloud Platform Console で [ファイアウォール ルール] ページに移動します。
    [ファイアウォール ルール] ページに移動
  2. [ファイアウォール ルールを作成] をクリックします。
  3. ファイアウォール ルールの作成ページで、次の情報を入力します。
    • 名前: ルールの名前を指定します。この例では fw-allow-network-lb-health-checks を使用しています。
    • ネットワーク: VPC ネットワークを選択します。
    • 優先度: 優先度の数値を入力します。数字が小さいほど優先度が高くなります。このファイアウォール ルールには、上りトラフィックを拒否する可能性があるその他のルールよりも高い優先度を設定してください。
    • トラフィックの方向: [上り] を選択します。
    • 一致したときのアクション: [許可] を選択します。
    • ターゲット: [指定されたターゲットタグ] を選択し、[ターゲットタグ] テキスト ボックスにタグを入力します。この例では allow-network-lb-health-checks を使用しています。
    • ソースフィルタ: [IP 範囲] を選択します。
    • ソース IP の範囲: 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22
    • 許可対象プロトコル / ポート: tcp を使用します。TCP は、HTTP と HTTPS の基礎となるプロトコルです。
    • [作成] をクリックします。
  4. 負荷分散対象の各インスタンスで、ネットワーク タグを追加して、新しい上りファイアウォール ルールが適用されるようにします。この例では、ネットワーク タグの allow-network-lb-health-checks を使用します。

gcloud

  1. 次の gcloud コマンドを使用して、fw-allow-network-lb-health-checks という名前のファイアウォール ルールを作成します。このルールは allow-network-lb-health-checks タグを使用してネットワーク内のインスタンスに対する受信接続を許可します。NETWORK_NAME はネットワーク名に置き換えてください。

    gcloud compute firewall-rules create fw-allow-network-lb-health-checks \
        --network NETWORK_NAME \
        --action ALLOW \
        --direction INGRESS \
        --source-ranges 35.191.0.0/16,209.85.152.0/22,209.85.204.0/22 \
        --target-tags allow-network-lb-health-checks \
        --rules tcp
  2. 負荷分散対象の各インスタンスで、ネットワーク タグを追加して、新しい上りファイアウォール ルールが適用されるようにします。この例では、ネットワーク タグの allow-network-lb-health-checks を使用します。

詳細は、gcloud ファイアウォール ルールのドキュメントAPI ドキュメントをご覧ください。

ロードバランサへの関連付け

プロトコルとロードバランサ

ロードバランサのバックエンド サービスまたはターゲット プールで使用されるプロトコルとプロトコルが一致するヘルスチェック(またはレガシー ヘルスチェック)を使用するのがおすすめの方法です。ただし、ヘルスチェック プロトコルとロードバランサ プロトコルは同じである必要はありません。次のような例が挙げられます。

  • 内部 TCP / UDP 負荷分散でバックエンド サービスのプロトコルに使用できるのは TCP または UDP だけです。内部ロードバランサの背後で VM からの HTTP トラフィックを処理する場合、HTTP プロトコルを使用したヘルスチェックの採用が有益です。

  • レガシー ヘルスチェックは、HTTP プロトコルに限定されています。TCP トラフィックの負荷分散にネットワーク ロードバランサを使用する場合は、負荷分散対象の VM で HTTP サービスを実行して、ヘルスチェック プローブへのレスポンスを可能にする必要があります。

バックエンド サービスのヘルスチェック

このセクションでは、次の種類のロードバランサで、ヘルスチェックをバックエンド サービスに関連付ける方法を説明します。

  • 内部 TCP / UDP 負荷分散
  • 内部 HTTP(S) 負荷分散
  • TCP プロキシ負荷分散
  • SSL プロキシ負荷分散
  • HTTP(S) 負荷分散

このセクションは、すでに以下の処理が行われていることを前提としています。

ヘルスチェックを新しい内部 TCP プロキシ、内部 SSL プロキシ、または内部 HTTP(S) ロードバランサに関連付けるには、それぞれのロードバランサの設定ガイドをご覧ください。

Console

ヘルスチェックを既存の内部、TCP プロキシ、SSL プロキシ、または HTTP(S) のロードバランサに関連付けるには次の手順を行います。

  1. Google Cloud Platform Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. いずれかのロードバランサをクリックして、その詳細を表示します。
  3. [編集] をクリックし、[バックエンドの設定] をクリックします。
  4. [ヘルスチェック] メニューからいずれかのヘルスチェックを選択します。
  5. [更新] をクリックします。

gcloud

ヘルスチェックを既存の内部、TCP プロキシ、SSL プロキシ、または HTTP(S) のロードバランサに関連付けるには次の手順を行います。

  1. ロードバランサで使用されているバックエンド サービスを特定します。内部、TCP プロキシ、SSL プロキシのロードバランサでは、ロードバランサ全体に対して存在するバックエンド サービスは 1 つのみです。HTTP(S) ロードバランサの場合は、URL マップに 1 つ以上のバックエンド サービスが関連付けられています。

    • 内部 TCP / UDP ロードバランサのバックエンド サービスを一覧表示するには、次のコマンドを実行します。バックエンド サービスの名前とリージョンを確認します。

      gcloud compute backend-services list \
          --filter="loadBalancingScheme=INTERNAL"
      
    • 内部 HTTP(S) ロードバランサのバックエンド サービスを一覧表示するには、次のコマンドを実行します。バックエンド サービスの名前とリージョンを確認します。

      gcloud compute backend-services list \
          --filter="loadBalancingScheme=INTERNAL_MANAGED"
      
    • TCP プロキシ ロードバランサのバックエンド サービスを一覧表示するには、次のコマンドを実行します。

      gcloud compute backend-services list \
          --filter="loadBalancingScheme=EXTERNAL" \
          --filter="protocol=TCP"
      
    • SSL プロキシ ロードバランサのバックエンド サービスを一覧表示するには、次のコマンドを実行します。

      gcloud compute backend-services list \
          --filter="loadBalancingScheme=EXTERNAL" \
          --filter="protocol=SSL"
      
    • HTTP(S) 負荷分散のバックエンド サービスを特定するには、URL マップを確認し、それに対して describe を実行します。URL_MAP_NAME は URL マップの名前に置き換えてください。使用されているバックエンド サービスは、レスポンスの pathMatchers セクションにリストされます。

      gcloud compute url-maps list
      gcloud compute url-maps describe URL_MAP_NAME
      
  2. ヘルスチェックを特定します。必要に応じて、ヘルスチェックを表示します。

  3. ヘルスチェックとバックエンド サービスを関連付けます。次のコマンドの BACKEND_SERVICE_NAME をバックエンド サービスの名前に、HEALTH_CHECK_NAME をヘルスチェックの名前にそれぞれ置き換えます。これらのコマンドは、バックエンド サービスに関連付けられたすべてのヘルスチェックを置き換えます。ほとんどの場合、バックエンド サービスに関連付けられるヘルスチェックは 1 つだけです。

    • 内部ロードバランサのバックエンド サービスのヘルスチェックを変更するには、次のコマンドを使用します。内部ロードバランサのバックエンド サービスはリージョンを対象とするため、その名前だけではなく REGION も指定する必要があります。

      gcloud compute backend-services update BACKEND_SERVICE_NAME \
          --region REGION \
          --health-checks HEALTH_CHECK_NAME
      
    • TCP プロキシ、SSL プロキシ、および HTTP(S) のロードバランサのバックエンド サービスのヘルスチェックを変更するには、次のコマンドを実行します。

      gcloud compute backend-services update BACKEND_SERVICE_NAME \
          --global \
          --health-checks HEALTH_CHECK_NAME
      

API

  1. バックエンド サービスを一覧表示するには、backendServices.list API 呼び出しを使用します。

  2. ヘルスチェックを表示します。

  3. ヘルスチェックをバックエンド サービスに関連付けるには、次のいずれかの API 呼び出しを使用します。

ネットワーク負荷分散のレガシー ヘルスチェック

このセクションでは、ネットワーク負荷分散のレガシー ヘルスチェックをターゲット プールに関連付ける方法について説明します。このセクションは、すでに以下の処理が行われていることを前提としています。

レガシー ヘルスチェックを新しいネットワーク ロードバランサに関連付けるには、ネットワーク負荷分散の設定をご覧ください。新しいネットワーク ロードバランサを作成するときは、レガシー ヘルスチェックをターゲット プールに関連付ける必要があります。

Console

ヘルスチェックを既存のネットワーク ロードバランサに関連付けるには、次の手順を行います。

  1. Google Cloud Platform Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. いずれかのネットワーク ロードバランサをクリックして、その詳細を表示します。
  3. [編集] をクリックし、[バックエンドの設定] をクリックします。
  4. [ヘルスチェック] メニューからいずれかのレガシー ヘルスチェックを選択します(有効なレガシー ヘルスチェックのみが表示されています)。
  5. [更新] をクリックします。

gcloud

ヘルスチェックを既存のネットワーク ロードバランサに関連付けるには、次の手順を行います。

  1. ターゲット プールを特定します。ネットワーク ロードバランサには少なくとも 1 つのターゲット プールがあり、場合によってはセカンダリ バックアップ プールもあります。

    gcloud compute target-pools list
    
  2. HTTP プロトコルを使用して、レガシー ヘルスチェックを特定します。必要に応じて、レガシー ヘルスチェックを表示します。

  3. レガシー ヘルスチェックとターゲット プールを関連付けます。次のコマンドの TARGET_POOL_NAME をターゲット プールの名前に、REGION をリージョンに、LEGACY_HEALTH_CHECK_NAME をレガシー ヘルスチェックの名前にそれぞれ置き換えます。レガシー ヘルスチェックでは、HTTP プロトコルを使用する必要があります。

    • ターゲット プールからレガシー HTTP ヘルスチェックを削除するには、次のコマンドを実行します。

      gcloud compute target-pools remove-health-checks TARGET_POOL_NAME \
          --region REGION \
          --http-health-check LEGACY_HEALTH_CHECK_NAME
      
    • レガシー HTTP ヘルスチェックをターゲット プールに追加するには、次のコマンドを実行します。

      gcloud compute target-pools add-health-checks TARGET_POOL_NAME \
          --region REGION \
          --http-health-check LEGACY_HEALTH_CHECK_NAME
      

API

  1. ターゲット プールを一覧表示するには、targetPools.list API 呼び出しを使用します。

  2. レガシー ヘルスチェックを表示して、レガシー HTTP ヘルスチェックを確認します。

  3. レガシー HTTP ヘルスチェックをターゲット プールに関連付けるには、targetPools.addHealthCheck API 呼び出しを使用します。

IP アドレス範囲をブロックしてヘルスチェックのトラブルシューティングを行う

ヘルスチェックを意図的に失敗させることが便利な状況があります。トラブルシューティングのアクティビティの一環として特定の VM のヘルスチェックを強制的に失敗させたり、シャットダウン手順の一部としてヘルスチェックを失敗させたりすることが必要になる場合があります。

ヘルスチェックの IP 範囲へのアクセスを一時的にブロックすることで、ヘルスチェックやレガシー ヘルスチェックを強制的に失敗させることができます。この例では、Linux VM で実行されている iptables ファイアウォール ソフトウェアを使用してヘルスチェックを失敗させる例を紹介します。

VM がヘルスチェックとレガシー ヘルスチェックのプローブに失敗するようにするには、次の例のように iptables コマンドを実行します。HEALTH_CHECK_PORT は適切な TCP ポート番号に置き換えてください。VM のシャットダウンの際に意図的にプローブを失敗させる場合は、シャットダウン スクリプトiptables コマンドを次のように追加して、その後にヘルスチェックのチェック間隔と異常しきい値に基づいて適切な遅延を設定します。

$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 35.191.0.0/16 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 130.211.0.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 209.85.152.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 209.85.204.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset

iptables ルールを削除するには、次のコマンドを実行します。HEALTH_CHECK_PORT はヘルスチェックの TCP ポートに置き換えてください。

$ sudo iptables -D INPUT -m state --state NEW \
-s 35.191.0.0/16 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -D INPUT -m state --state NEW \
-s 130.211.0.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -D INPUT -m state --state NEW \
-s 209.85.152.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -D INPUT -m state --state NEW \
-s 209.85.204.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...