内部 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.

次のステップ

基礎知識については、内部 TCP / UDP 負荷分散のコンセプトをご覧ください。
フェイルオーバーに関する重要な情報については、内部 TCP / UDP 負荷分散のフェイルオーバーのコンセプトをご覧ください。
ロードバランサで使用できる DNS 名のオプションについては、内部負荷分散と DNS 名をご覧ください。
内部 TCP / UDP ロードバランサの構成例については、内部 TCP / UDP 負荷分散の設定をご覧ください。
内部 TCP / UDP 負荷分散の構成の手順と例について詳しくは、内部 TCP / UDP ロードバランサのフェイルオーバー構成をご覧ください。
内部 TCP / UDP 負荷分散に関する Stackdriver のロギングとモニタリングの構成については、内部 TCP / UDP 負荷分散のロギングとモニタリングをご覧ください。
VPC ネットワークに接続されたピアネットワークから内部 TCP / UDP ロードバランサにアクセスする方法については、内部 TCP / UDP 負荷分散と接続ネットワークをご覧ください。

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

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

最終更新日: 10月 25, 2019