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

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

概要

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

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

始める前に

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

一般的な接続について:

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

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

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

  • 症状: VM クライアントが内部 TCP / UDP ロードバランサと別のリージョンにある場合、クライアントからロードバランサに接続できない。
  • 理由: 内部 TCP / UDP ロードバランサはリージョン単位であるため、同じリージョン内になければアクセスできません。

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

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

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

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

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

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

接続性

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

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

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

フェイルオーバー グループの接続ドレイン制限を無効にする

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

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

gcloud beta compute backend-services create my-failover-bs
  --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.beta.compute.backend-services.create) Invalid value for
[--protocol]: can only specify --connection-drain-on-failover if the protocol is
TCP.

フェイルオーバー バックエンド用の API バージョン

現在のところ、フェイルオーバーのオプションはベータ版 API でのみ使用できます。バックエンド サービスの作成に失敗し、「failover options は有効なフィールドではありません」というエラーが返された場合は、正しい API を使用してバックエンド サービスを作成していることを確認してください(gcloud beta compute backend-services...)。

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

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

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

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

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

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

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

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

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

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

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

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

接続性

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

  • 内部 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 ネットワーク内でより限定された範囲の宛先を持つ他のルートを削除します。ルーティング順序を参照して、GCP ルートの選択を理解してください。

ネクストホップの API バージョン

現在、ネクストホップとしての内部 TCP / UDP ロードバランサ(--next-hop-ilb)は、ベータ版 API でのみ使用できます。静的ルートの作成に失敗した場合は、正しい API を使用してルートを作成していることを確認してください(gcloud beta compute routes create...)。

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

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

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

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

次のステップ

このページは役立ちましたか?評価をお願いいたします。

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