ロードバランサの分析情報

このページでは、ロードバランサに関するネットワーク アナライザの分析情報について説明します。すべての分析情報の種類の詳細については、分析情報のグループと種類をご覧ください。

Recommender API で分析情報を表示する

これらの分析情報を gcloud CLI または Recommender API で表示するには、次の分析情報の種類を使用します。

• google.networkanalyzer.networkservices.loadBalancerInsight

次の権限が必要です。

• recommender.networkAnalyzerLoadBalancerInsights.list
• recommender.networkAnalyzerLoadBalancerInsights.get

ネットワーク アナライザの分析情報に Recommender API を使用する方法の詳細については、Recommender CLI と API の使用をご覧ください。

ヘルスチェックのファイアウォールが構成されていない

この分析情報は、ロードバランサが使用している VPC ネットワークでヘルスチェック ファイアウォールが構成されていないことを示しています。この分析情報には次の情報が含まれます。

• ロードバランサ: ロードバランサの名前。
• 転送ルール: 特定の転送ルールの名前。
• ネットワーク: ロードバランサが構成されているネットワークの名前。
• ブロックしているファイアウォール: ヘルスチェックの IP アドレス範囲をブロックしているファイアウォールの名前。
• 正しく構成されていないバックエンド: ヘルスチェックの IP アドレス範囲の許可ファイアウォール ルールが含まれていないロードバランサのバックエンド。

推奨事項

ヘルスチェックの IP アドレス範囲がロードバランサのバックエンドに明示的にアクセスできるように、ヘルスチェック ファイアウォール ルールを構成します。詳細については、ロードバランサのファイアウォール ルールをご覧ください。

ヘルスチェックの IP アドレス範囲がブロックされている

ユーザーが構成したファイアウォール ルールがヘルスチェックの IP アドレス範囲をブロックしていることを示します。分析情報の詳細から、ヘルスチェックのアドレス範囲をブロックするファイアウォール ルールを特定できます。

推奨事項

ロードバランサ タイプのヘルスチェックのアドレス範囲を確認するには、ロードバランサのファイアウォール ルールをご覧ください。

• ブロックしているファイアウォール ルールの IP アドレス範囲が広い場合は、ヘルスチェック IP アドレス範囲に高い優先度を設定して許可ルールを作成します。
• ブロックしているファイアウォール ルールの IP アドレス範囲が、ヘルスチェック IP アドレス範囲と同じか、下回っている場合は、ブロックしているファイアウォール ルールを削除します。

ファイアウォール構成に整合性がない

バックエンド VM 間でファイアウォール構成が一貫していないことを示します。ヘルスチェックの IP アドレス範囲は、一部のバックエンド VM で許可されますが、それ以外の VM で拒否されます。この問題は、一部のバックエンド VM でネットワーク タグまたはサービス アカウントが誤って変更された場合に発生します。この分析情報には次の情報が含まれます。

• ロードバランサ: ロードバランサの名前
• 転送ルール: 特定の転送ルールの名前
• ネットワーク: ロードバランサが構成されているネットワークの名前
• ブロックしているファイアウォール: ヘルスチェック範囲をブロックしているファイアウォールの名前
• ファイアウォールを部分的に許可: 適切に構成されたバックエンド VM でヘルスチェック トラフィックを許可するファイアウォールの名前
• 正しく構成されていないバックエンド: この問題が発生しているバックエンド。ヘルスチェック IP アドレス範囲のファイアウォール構成が正しく機能していません。

関連トピック

• サービス アカウントによるフィルタリングとネットワーク タグによるフィルタリング
• ロードバランサのファイアウォール ルール

推奨事項

正しく構成されていないバックエンド VM に構成されたタグと、部分的に許可されるファイアウォール ルールに構成されたタグを比較して、正しく構成されていないタグを見つけます。正しく構成されていないバックエンド VM のタグとサービス アカウントを変更して、機能しているバックエンド VM のタグとサービス アカウントと同じ値にします。

ヘルスチェックの IP アドレス範囲が部分的にブロックされている

ヘルスチェック範囲で、すべてのバックエンドがトラフィックを部分的にブロックしていることを示します。ヘルスチェック トラフィックは、一部のヘルスチェック IP アドレス範囲で許可され、他のヘルスチェック IP アドレス範囲で拒否されます。この分析情報には次の情報が含まれます。

• ロードバランサ: ロードバランサの名前
• 転送ルール: 特定の転送ルールの名前
• ネットワーク: ロードバランサが構成されているネットワークの名前
• ブロックしているファイアウォール: ヘルスチェック範囲をブロックしているファイアウォールの名前
• ファイアウォールを部分的に許可: 適切に構成されたバックエンド VM でヘルスチェック トラフィックを許可するファイアウォールの名前
• 正しく構成されていないバックエンド: この問題が発生しているバックエンド。ヘルスチェック範囲のファイアウォール構成が正しく機能していません。
• ブロックされているヘルスチェック範囲: ヘルスチェック トラフィックがブロックされている IP アドレス範囲

関連トピック

• ロードバランサのファイアウォール ルール

推奨事項

部分的に許可するファイアウォール ルールの IP アドレス範囲と、ロードバランサのタイプのヘルスチェックの IP アドレス範囲を比較します。IP アドレス範囲がない場合は、許可するファイアウォール ルールに追加します。分析情報がある場合は、部分的に許可するファイアウォール ルールの優先度が、拒否するファイアウォール ルールの優先度よりも高いことを確認します。

バックエンド サービスの負荷分散モードでセッション アフィニティが中断される

この分析情報は、プロキシベースのロードバランサのバックエンド サービスに NONE 以外のセッション アフィニティがあり、UTILIZATION 分散モードを使用する 1 つ以上のインスタンス グループ バックエンドがある場合にトリガーされます。ロードバランサへのトラフィックが少ないと、セッション アフィニティが失われる可能性があります。また、ロードバランサがバックエンドの追加または削除を行うときに、ロードバランサがバックエンドの量を変化させた場合（たとえば、ヘルスチェックに失敗した場合や、成功した場合）、ロードバランサはセッションの一部をドロップします。ドロップされるセッションの量は、変化するバックエンドの数に比例します。このような変更によって、それらのセッションのセッション アフィニティも損なわれます。

この分析情報には次の情報が含まれます。

• バックエンド サービス: 影響を受けるバックエンド サービス。
• 転送ルール: このバックエンド サービスにトラフィックを転送する転送ルール。
• セッション アフィニティ: バックエンド サービスで使用されるセッション アフィニティ。
• 影響を受けるバックエンド: UTILIZATION 分散モードを使用するバックエンド。

関連トピック

• 使用率分散モードでのセッション アフィニティの喪失
• ロードバランサのタイプでサポートされる分散モード

推奨事項

NONE 以外のセッション アフィニティを使用するには、RATE または CONNECTION 分散モードを使用する必要があります。このオペレーションは、Google Cloud CLI または Compute Engine API でのみ行うことができます。Google Cloud コンソールで行うことはできません。

HTTP、HTTPS、または HTTP/2 プロトコルを使用するプロキシ ロードバランサのバックエンド サービスの場合は、gcloud compute backend-services update-backend コマンドを使用して分散モードを RATE に切り替え、レート分散モードを使用します。

次のコードサンプルは、このコマンドを使用してモードを RATE に切り替える方法を示しています。

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
    BACKEND_SERVICE_SCOPE \
    --instance-group=INSTANCE_GROUP_NAME \
    INSTANCE_GROUP_SCOPE \
    --balancing-mode=RATE \
    TARGET_CAPACITY

TCP や SSL などの HTTP 以外のプロトコルを使用するプロキシ ロードバランサのバックエンド サービスの場合は、gcloud compute backend-services update-backend コマンドを使用して接続分散モードを選択し、分散モードを CONNECTION に切り替えます。

次のコードサンプルは、このコマンドを使用してモードを CONNECTION に切り替える方法を示しています。

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
    BACKEND_SERVICE_SCOPE \
    --instance-group=INSTANCE_GROUP_NAME \
    INSTANCE_GROUP_SCOPE \
    --balancing-mode=CONNECTION \
    TARGET_CAPACITY

どちらの例でも、次のように置き換えます。

• BACKEND_SERVICE_NAME: バックエンド サービスの名前。
• BACKEND_SERVICE_SCOPE: バックエンド サービスのスコープ。グローバル バックエンド サービスの場合は、--global を使用します。リージョン バックエンド サービスの場合は、--region=REGION を使用し、REGION をリージョンに置き換えます。
• INSTANCE_GROUP_NAME: バックエンド インスタンス グループの名前。
• INSTANCE_GROUP_SCOPE: インスタンス グループのロケーション。リージョン マネージド インスタンス グループの場合は、--region=REGION を使用します。REGION は、リージョンに置き換えます。ゾーン インスタンス グループの場合は、--zone=ZONE を使用して、ZONE をゾーンに置き換えます。
• TARGET_CAPACITY: ターゲット レートまたはターゲット接続の仕様。レート分散モードの場合は、--max-rate= フラグまたは --max-rate-per-instance= フラグを使用します。バックエンド サービスの概要のレート分散モードをご覧ください。ドロップ接続分散モードの場合は、--max-connections= フラグまたは --max-connections-per-instance= フラグを使用します。バックエンド サービスの概要の接続分散モードをご覧ください。

バックエンド サービスがヘルスチェックとトラフィックに異なるポートを使用している

ロードバランサは、トラフィックの処理にロードバランサが使用している名前付きポートではなく、別のポートで一部のバックエンドに対してヘルスチェックを実行します。この構成では、別のポートが意図的に使用されるようにロードバランサを構成していないと、問題が発生する可能性があります。

この分析情報には次の情報が含まれます。

• バックエンド サービス: 影響を受けるバックエンド サービス。
• 転送ルール: トラフィックをバックエンド サービスに転送する転送ルール。
• 処理中のポート名: バックエンド サービスがサービス トラフィックに使用するポート名。
• ヘルスチェック: バックエンド サービスが使用するヘルスチェック。
• ヘルスチェックのポート番号: ヘルスチェックで使用されるポート。
• 影響を受けるバックエンド: サービス提供ポートがヘルスチェック ポートと異なるインスタンス グループ。

関連トピック

カテゴリとポートの仕様をご覧ください。

推奨事項

バックエンド サービスと同じポートをヘルスチェックで使用するように、サービスポートの指定でヘルスチェックを構成します。次のコードサンプルは、Google Cloud CLI コマンドを使用してヘルスチェックを更新して、サービス提供ポートを使用するように更新する方法を示しています。

gcloud compute health-checks update PROTOCOL HEALTH_CHECK_NAME \
      HEALTH_CHECK_SCOPE \
      --use-serving-port

次のように置き換えます。

• PROTOCOL: ヘルスチェックで使用されるプロトコル。
• HEALTH_CHECK_NAME: ヘルスチェックの名前。
• HEALTH_CHECK_SCOPE: ヘルスチェックのスコープ。グローバル ヘルスチェックの場合は、--global を使用します。リージョン ヘルスチェックの場合は、--region=REGION を使用します。REGION は、リージョンに置き換えます。

SSL 証明書がロードバランサに関連付けられていない

これは、SSL または HTTPS トラフィックを処理するロードバランサに関連付けられていない Google マネージド SSL 証明書がプロジェクトにあることを示します。Google マネージド SSL 証明書は、証明書がロードバランサに接続されるまで使用できません。接続されていない証明書のリストは、分析情報の詳細で確認できます。

関連トピック

• Google マネージド SSL 証明書を使用する
• Google マネージド SSL 証明書のトラブルシューティング

推奨事項

ロードバランサの作成前、作成中、作成後に、Google が管理する SSL 証明書を作成できます。ACTIVE にするには、Google マネージド SSL 証明書をロードバランサ、特にロードバランサのターゲット プロキシに関連付ける必要があります。

SSL 証明書を作成して PROVISIONING 状態になったら、ロードバランサの作成中に使用したり、既存のロードバランサを更新するために使用できます。Google マネージド証明書の詳細については、Google マネージド SSL 証明書のトラブルシューティングをご覧ください。

ロードバランサに関連付けられた SSL 証明書でポート 443 が公開されていない

これは、関連付けられた転送ルールでポート 443 が公開されていないために Google マネージド SSL 証明書が正しく機能していないことを示しています。これらの証明書の一覧は、分析情報の詳細で確認できます。

関連トピック

• 転送ルールを作成する
• Google マネージド証明書のトラブルシューティング

推奨事項

ロードバランサを作成または更新するときに、ポート 443 を使用して転送ルールを作成します。