内部 TCP / UDP 負荷分散のトラブルシューティング

このガイドでは、Google Cloud の内部 TCP / UDP ロードバランサの構成に関する問題のトラブルシューティングについて説明します。

概要

このガイドで説明する問題の種類は次のとおりです。

  • ロードバランサの設定の問題
  • 一般的な接続に関する問題
  • バックエンドのフェイルオーバーに関する問題
  • ネクストホップの問題としてのロードバランサ

始める前に

問題を調べる前に、次のページをよくお読みください。

一般的な接続について:

フェイルオーバーについて:

ネクストホップについて:

バックエンドの負荷分散モードに互換性がない

ロードバランサを作成するときに、次のエラーが表示される場合があります。

Validation failed for instance group INSTANCE_GROUP:

backend services 1 and 2 point to the same instance group
but the backends have incompatible balancing_mode. Values should be the same.

これは、2 つの異なるロードバランサで同じバックエンドを使用しようとしたが、互換性のある負荷分散モードがバックエンドにない場合に発生します。

詳しくは以下をご覧ください。

接続に関する一般的な問題のトラブルシューティング

内部 TCP / UDP ロードバランサに接続できない場合は、次の一般的な問題を確認してください。

  • ファイアウォール ルールを確認します。

    • 上り（内向き）許可のファイアウォール ルールを調べて、バックエンド VM へのヘルスチェックを許可するよう定義されていることを確認します。
    • 上り（内向き）許可のファイアウォール ルールで、クライアントからバックエンド VM へのトラフィックが許可されていることを確認します。
    • ロードバランサが使用するポートでバックエンド VM へのトラフィックを許可するための、関連するファイアウォール ルールが存在することを確認します。
    • ファイアウォール ルールのターゲットタグを使用している場合は、ロードバランサのバックエンド VM が適切にタグ付けされていることを確認してください。

    内部 TCP / UDP ロードバランサに必要なファイアウォール ルールの構成方法については、ファイアウォール ルールの構成をご覧ください。

  • バックエンド VM でゲスト環境が実行されていることを確認します。正常なバックエンド VM に接続できてもロードバランサに接続できない場合は、VM のゲスト環境（以前の Windows のゲスト環境、または Linux のゲスト環境）が稼働していないか、メタデータ サーバー（metadata.google.internal、169.254.169.254）と通信できません。

    次の点を確認してください。

    • ゲスト環境がバックエンド VM にインストールされ、実行されていることを確認します。
    • バックエンド VM のゲスト オペレーティング システム内のファイアウォール ルール（iptables または Windows ファイアウォール）が、メタデータ サーバーへのアクセスをブロックしていないことを確認します。

  • バックエンド VM がロードバランサに送信されたパケットを受信していることを確認します。各バックエンド VM は、ロードバランサに送信されたパケットを受信するように構成する必要があります。つまり、バックエンド VM に配信されるパケットの宛先は、ロードバランサの IP アドレスにします。ほとんどの場合、これはローカルルートで暗黙的に指定されます。

    Google Cloud イメージから作成された VM の場合、ゲスト エージェントによって、ロードバランサの IP アドレスのローカルルートがインストールされます。Container-Optimized OS をベースとした Google Kubernetes Engine インスタンスは、代わりに iptables を使用してこれを実装します。

    Linux バックエンド VM で次のコマンドを実行すると、ローカルルートの存在を確認できます。LOAD_BALANCER_IP は、ロードバランサの IP アドレスに置き換えます。

    sudo ip route list table local | grep LOAD_BALANCER_IP

  • バックエンド VM でサービス IP アドレスとポート バインディングを確認します。内部 TCP / UDP ロードバランサに送信されたパケットは、ロードバランサ自体の宛先 IP アドレスを持つバックエンド VM に到達します。このタイプのロードバランサはプロキシではありません。これは想定された動作です。

    バックエンド VM で実行されるソフトウェアでは次の処理が行われている必要があります。

    • ロードバランサの IP アドレスまたは任意の IP アドレス（0.0.0.0 または ::）でのリッスン（バインド）
    • ロードバランサの転送ルールに含まれるポートでのリッスン（バインド）

    これをテストするには、SSH または RDP を使用してバックエンド VM に接続します。次に、curl、telnet または同様のツールを使用して、次のテストを行います。

    • バックエンド VM 自体の内部 IP アドレス、127.0.0.1 または localhost を使用してサービスに接続し、サービスに移動してみます。
    • ロードバランサの転送ルールの IP アドレスを使用してサービスに接続し、サービスに移動してみます。

  • クライアント VM がロードバランサと同じリージョンにあるかどうかを確認します。ロードバランサに接続しているクライアントが別のリージョンにある場合は、グローバル アクセスが有効になっていることを確認します。

  • ヘルスチェック トラフィックがバックエンド VM に到達できることを確認します。ヘルスチェック トラフィックがバックエンド VM に到達したことを確認するには、ヘルスチェック ロギングを有効にし、成功したログエントリを検索します。

共有 VPC に関する問題のトラブルシューティング

共有 VPC を使用していて、特定のサブネットで新しい内部 TCP / UDP ロードバランサを作成できない場合は、組織ポリシーが原因である可能性があります。組織ポリシーで、許可されたサブネットのリストに、ロードバランサを作成したいサブネットを追加するか、組織管理者にお問い合わせください。詳細については、constraints/compute.restrictSharedVpcSubnetworks の制約をご覧ください。

フェイルオーバーに関する問題のトラブルシューティング

このセクションでは、内部 TCP / UDP ロードバランサのフェイルオーバーを構成した場合に発生する可能性がある問題について説明します。

接続性

  • フェイルオーバー バックエンドが 1 つ以上指定されていることを確認します。
  • フェイルオーバー ポリシーの設定を確認します。
    • フェイルオーバー率
    • すべてのバックエンド VM が正常でない場合のトラフィックの廃棄
    • フェイルオーバー時の接続ドレインの無効化

マネージド インスタンス グループとフェイルオーバーに関する問題

  • 症状: アクティブ プールがプライマリ バックエンドとフェイルオーバー バックエンドの間で行き来する（フラッピング）。
  • 考えられる理由: 自動スケーリングとフェイルオーバーでマネージド インスタンス グループを使用したことで、アクティブ プールがプライマリ バックエンドとフェイルオーバー バックエンドの間でフェイルオーバーとフェイルバックを繰り返している可能性があります。Google Cloud では、マネージド インスタンス グループによるフェイルオーバー構成を禁じていません。貴社でのデプロイがこの構成から恩恵を受けている可能性があるためです。

フェイルオーバー グループのコネクション ドレイン制限を無効にする

バックエンド サービスがプロトコル TCP で設定されている場合のみ、接続ドレインを無効にしてフェイルオーバー問題を解決できます。

UDP 構成でバックエンド サービスが作成されている場合、コネクション ドレインを無効にすると次のエラー メッセージが表示されます。

gcloud compute backend-services create my-failover-bs
  --global-health-checks \
  --load-balancing-scheme internal
  --health-checks my-tcp-health-check
  --region us-central1
  --no-connection-drain-on-failover
  --drop-traffic-if-unhealthy
  --failover-ratio 0.5
  --protocol UDP
ERROR: (gcloud.compute.backend-services.create) Invalid value for
[--protocol]: can only specify --connection-drain-on-failover if the protocol is
TCP.

トラフィックが予期したとおりにバックエンド VM に送信されない

まず、次のことを確認します。クライアント VM がロードバランサのバックエンド VM でもある場合、ロードバランサの転送ルールの IP アドレスに送信される接続には、常にバックエンド VM 自体が応答します。これは予想どおりの動作です。詳しくは、1 つのクライアントからの接続のテストと負荷分散された VM からのリクエストの送信をご覧ください。

クライアント VM がロードバランサのバックエンド VM でない場合は、次の手順を行います。

  • 単一のクライアントからのリクエトの場合、単一のクライアントからの接続のテストを参照してこの方法の制限があることを理解します。

  • 上り（内向き）許可のファイアウォール ルールを調べて、ヘルスチェックを許可するよう構成されていることを確認します。

  • フェイルオーバー構成では、アクティブ プールのメンバーシップの仕組みや、Google Cloud がフェイルオーバーとフェイルバックを実行するタイミングを理解します。ロードバランサの構成を確認します。

    • Cloud Console を使用して、各バックエンド インスタンス グループ内の正常なバックエンド VM の数を確認します。Cloud Console には、アクティブ プール内の VM も表示されます。

    • ロードバランサのフェイルオーバー率が適切に設定されていることを確認します。たとえば、プライマリ VM が 10 個存在し、フェイルオーバー率が 0.2 に設定されている場合、Google Cloud は、正常なプライマリ VM の数が 2（10 × 0.2 = 2）未満になればフェイルオーバーを実行します。フェイルオーバー率 0.0 には、正常なプライマリ VM が 1 つもなければ、Google Cloud がフェイルオーバーを実行するという特別な意味があります。

既存の接続がフェイルオーバーまたはフェイルバック中に中断される

バックエンド サービスのフェイルオーバー ポリシーを編集します。フェイルオーバー時の接続ドレインが有効になっていることを確認します。

ネクストホップとしてのロードバランサのトラブルシューティング

内部 TCP / UDP ロードバランサをカスタム静的ルートのネクストホップに設定すると、次の問題が発生することがあります。

接続

  • ネクストホップが内部 TCP / UDP ロードバランサの転送ルールであるルートの宛先範囲内の IP アドレスに対して ping を実行できない場合、このタイプのネクストホップを使用するルートは、ルートが作成されたタイミングによっては、ICMP トラフィックを処理しなかった可能性があるので注意してください。ルートが 2021 年 5 月 15 日より前に作成されていた場合、2021 年 8 月 16 日までは TCP トラフィックと UDP トラフィックのみが処理されます。2021 年 8 月 16 日以降は、ルートが作成されたタイミングにかかわらず、すべてのルートがすべてのプロトコル トラフィック（TCP、UDP、ICMP）を自動的に転送します。その時点まで待つことを回避する場合は、新しいルートを作成して古いルートを削除することで、今すぐ ping 機能を有効にできます。

  • 内部 TCP / UDP ロードバランサをカスタム静的ルートのネクストホップとして使用すると、ロードバランサの内部バックエンド サービスに構成されているプロトコルと、ロードバランサの内部転送ルールで構成されたポートに関わりなく、ロードバランサの正常なバックエンド VM にすべてのトラフィックが送られます。

  • 上り（内向き）許可のファイアウォール ルールを調べて、カスタム静的ルートのネクストホップ経由でバックエンド VM に送られるトラフィックのソースを正しく識別していることを確認してください。バックエンド VM に到着したパケットは、カスタム静的ルートを介して送られた場合でも、送信元 IP アドレスを保持します。

宛先の範囲の値が無効

カスタム静的ルートの宛先範囲は、VPC ネットワーク内のサブネット ルートより狭い範囲に指定できません。カスタム静的ルートの作成時に次のエラー メッセージが表示された場合:

Invalid value for field 'resource.destRange': [ROUTE_DESTINATION].
[ROUTE_DESTINATION] hides the address space of the network .... Cannot change
the routing of packets destined for the network.

  • サブネット ルートと完全に一致する宛先か、それよりも限定された範囲の（長いマスクを使用する）宛先を持つカスタム静的ルートは作成できません。詳しくは、適用範囲と順序をご覧ください。

  • 予期しない宛先にパケットが移動した場合は、VPC ネットワーク内でより限定された範囲の宛先を持つ他のルートを削除します。ルーティング順序を参照して、Google Cloud ルートの選択を理解してください。

次のステップ