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

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

概要

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

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

始める前に

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

一般的な接続について:

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

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

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

  • 症状: VM クライアントが内部 TCP / UDP ロードバランサと別のリージョンにある場合、クライアントからロードバランサに接続できない。
  • 理由: グローバル アクセスが有効になっていません。

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

  • 上り許可のファイアウォール ルールを調べて、バックエンド VM へのヘルスチェックを許可するよう定義されていることを確認します。
  • 上り許可のファイアウォール ルールで、クライアントからバックエンド VM へのトラフィックが許可されていることを確認します。
  • ロードバランサに接続しているクライアントが、ロードバランサと同じリージョンにあることを確認します。 クライアントが別のリージョンにある場合は、グローバル アクセスが有効になっていることを確認します。

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

  • 症状: 内部 TCP / UDP ロードバランサでサービスに接続できないが、バックエンド VM に直接接続できる。

  • 理由: ゲスト環境が稼働していないか、メタデータ サーバー（metadata.google.internal、169.254.169.254）と通信できません。

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

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

共有 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 ロードバランサをカスタム静的ルートのネクストホップに設定すると、次の問題が発生することがあります。

接続

  • バックエンドに ping できない場合、内部 TCP / UDP ロードバランサをネクストホップに設定したルートがサポートできるのは、TCP トラフィックと UDP トラフィックのみである点に注意してください。ICMP などの他のプロトコルのパケットは、ロードバランサによって無視されます。詳細については、TCP、UDP、その他のプロトコルのトラフィックをご覧ください。

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

  • 上り許可のファイアウォール ルールを調べて、カスタム静的ルートのネクストホップ経由でバックエンド 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 ルートの選択を理解してください。

ネットワーク タグがサポートされない

ネクストホップが内部 TCP / UDP ロードバランサの場合、カスタム静的ルートにネットワーク タグを割り当てることはできません。たとえば、次の gcloud コマンドを実行すると、その下に示すエラー メッセージが表示されます。

$ gcloud compute routes create example-route \
--destination-range=0.0.0.0/0 \
--next-hop-ilb=internal-lb-forwarding-rule \
--tags='my_tag'

ERROR: (gcloud.compute.routes.create) Could not fetch resource:
 - Invalid value for field 'resource.tags': ''. Tag is not supported for routes
 with next hop ilb.

次のステップ