内部パススルーネットワークロードバランサのトラブルシューティング

このガイドでは、Google Cloud 内部パススルーネットワークロードバランサの構成に関する問題のトラブルシューティングについて説明します。問題を調べる前に、次のページをよくお読みください。

ネットワークアナライザに関する一般的な問題のトラブルシューティング

ネットワークアナライザは、VPC ネットワーク構成を自動的にモニタリングし、最適ではない構成と構成ミスの両方を検出します。ネットワーク障害を特定し、根本原因の情報と考えられる解決策を提供します。ネットワークアナライザによって自動的に検出されるさまざまな構成ミスについては、ネットワークアナライザのドキュメントでロードバランサの分析情報をご覧ください。

ネットワークアナライザは、Network Intelligence Center の一部として Google Cloud コンソールでご利用いただけます。

ネットワークアナライザに移動

バックエンドのバランシングモードに互換性がない

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

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 つの異なるロードバランサで同じバックエンドを使用しようとしたが、互換性のある負荷分散モードがバックエンドにない場合に発生します。

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

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

内部パススルーネットワークロードバランサに接続できない場合は、次の一般的な問題を確認してください。

ファイアウォールルールを確認する

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

内部パススルーネットワークロードバランサに必要なファイアウォールルールを構成する方法については、ファイアウォールルールの構成をご覧ください。

バックエンド 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 アドレスとポートバインディングを確認する

内部パススルーネットワークロードバランサに送信されたパケットは、ロードバランサ自体の宛先 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 に到達したことを確認するには、ヘルスチェックロギングを有効にし、成功したログエントリを検索します。

バックエンドの健全性を確認して、ロードバランサの機能が正常であることを確認することもできます。

バックエンドに正常なインスタンスがない場合は、適切なヘルスチェックが構成され、バックエンドの各 VM が構成済みのヘルスチェックポートをリッスンしていることを確認します。

同じ VPC ネットワーク内のクライアントから次のコマンドを実行して、バックエンド VM が特定の TCP ポートをリッスンしていることを確認します。

telnet SERVER_IP_ADDRESS PORT

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

SERVER_IP_ADDRESS: バックエンド VM の IP アドレス。
PORT: ヘルスチェック用に構成したポート。デフォルトでは、ヘルスチェックポートは 80 です。

SSH を使用してバックエンド VM に接続し、次のコマンドを実行することもできます。

curl localhost:PORT

PORT は、ヘルスチェック用に構成したポートに置き換えます。

また、このテストを次のコマンドで行うこともできます。

netstat -npal | grep LISTEN

出力で次のことを確認します。

<var>LB_IP_ADDRESS</var>:<var>PORT</var>
0.0.0.0:<var>PORT</var>
:::<var>PORT</var>

ロードバランサの IP アドレスに応答するようにルーティングが正しく設定されているかどうかはわかりません。この場合も、同様の問題が発生します。ルーティングについては、バックエンド VM がロードバランサに送信されたパケットを受け入れることを確認するの説明に従い、ip route list table local コマンドを実行してロードバランサの IP アドレスが返されていることを確認します。

パフォーマンスに関する問題のトラブルシューティング

パフォーマンスの問題やレイテンシの増加が発生している場合は、次の一般的な問題を確認してください。

サーバー機能を確認する

すべてのバックエンドサーバーがヘルスチェックに応答している場合は、サーバーから直接発行されたときに、クライアントからのリクエストが正しく動作していることを確認します。たとえば、クライアントがロードバランサ経由でサーバーに HTTP リクエストを送信していて、レスポンスがない場合や、レスポンスが通常より著しく遅い場合は、各バックエンドサーバーで同じ HTTP リクエストを発行して、動作を確認します。

リクエストがサーバー内から発行されたときに、バックエンドサーバーのいずれかが正しく動作していなければ、サーバーアプリケーションスタックが正常に機能していないと判断できます。この場合、アプリケーション自体のトラブルシューティングを行います。すべてのサーバーが正常に動作している場合は、クライアント側とネットワークの確認を行います。

ネットワーク接続とレイテンシを確認する

すべてのバックエンドサーバーがリクエストに正しく応答している場合は、ネットワークレイテンシを確認します。次のように、クライアント VM から各サーバーに同じ ping コマンドを発行します。

ping SERVER_IP_ADDRESS

このテストでは、組み込みのネットワークレイテンシと、ネットワークがパケットをドロップしているかどうかを確認できます。ICMP トラフィックがファイアウォールルールによってブロックされていることもあります。この場合、テスト結果は生成されません。これに該当するかどうかは、ファイアウォールルールの管理者に確認してください。

ping コマンドのレイテンシが通常よりも著しく長いか、パケットロスが著しく多い場合は、Google Cloud サポートケースを作成して詳しい調査を依頼してください。

問題のあるクライアントサーバーの組み合わせを特定する

ネットワークの ping テストでレイテンシが低く、パケットロスがないことが示された場合は、問題のあるクライアントとサーバーの組み合わせ（存在する場合）を特定します。これを行うには、サーバーの数が 1 になるまでバックエンドサーバーの数を減らし、同時に問題のある動作（レイテンシが高い、レスポンスがないなど）を再現します。

問題のあるクライアントサーバーの組み合わせを特定したら、トラフィックのキャプチャと分析を行います。

問題のあるクライアントとサーバーの組み合わせがない場合は、パフォーマンステストに進みます。

トラフィックのキャプチャと分析を実行する

クライアントサーバーの特定の組み合わせに問題がある場合は、パケットキャプチャを使用して、遅延や破損の原因となっている通信部分を特定します。tcpdump でパケットキャプチャを実行する方法は次のとおりです。

サーバーに tcpdump をインストールします。
サーバーで tcpdump のキャプチャを開始します。
クライアントから、次のようなサンプルリクエストを発行します。
```
curl URL
```
tcpdump の出力を分析して、問題を特定します。

パフォーマンステストを行う

問題のあるクライアントとサーバーの組み合わせがなく、すべてのクライアントとサーバーの組み合わせのパフォーマンスが想定よりも低い場合は、以下のテストを行います。

1 つのクライアントと 1 台のサーバー（ロードバランシングなし）。
1 つのクライアントと 1 台のサーバー（ロードバランシングあり）。

結果: テスト [1] と [2] の結果の組み合わせで、ロードバランサが問題の原因かどうかを確認できます。
1 つのクライアントと複数のサーバー（ロードバランシングあり）。

結果: 1 つのクライアントのパフォーマンス上限を確認します。
複数のクライアントと 1 台のサーバー（ロードバランシングあり）。

結果: 1 台のサーバーのパフォーマンス上限を特定します。
複数のクライアントと複数のサーバー（ロードバランシングなし）。

結果: ネットワークのパフォーマンス上限を確認します。

複数のクライアントまたはサーバーでストレステストを実行すると、クライアントまたはサーバーのリソース（CPU、メモリ、I/O）がボトルネックになり、集計結果が少なくなります。各クライアントとサーバーが正しく動作している場合でも、集計結果が劣化する可能性があります。

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

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

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

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

接続

フェイルオーバーバックエンドが 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 がフェイルオーバーとフェイルバックを実行するタイミングを理解します。ロードバランサの構成を確認します。
- Google Cloud コンソールを使用して、各バックエンドインスタンスグループ内の正常なバックエンド VM の数を確認します。Google Cloud コンソールには、アクティブプール内の VM も表示されます。
- ロードバランサのフェイルオーバー率が適切に設定されていることを確認します。たとえば、プライマリ VM が 10 個存在し、フェイルオーバー率が 0.2 に設定されている場合、Google Cloud は、正常なプライマリ VM の数が 2（10 × 0.2 = 2）未満になればフェイルオーバーを実行します。フェイルオーバー率 0.0 には、正常なプライマリ VM が 1 つもなければ、Google Cloud がフェイルオーバーを実行するという特別な意味があります。

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

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

ロードバランサのネクストホップに関する問題のトラブルシューティング

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

接続に関する問題

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

ロギングの問題のトラブルシューティング

内部パススルーネットワークロードバランサのロギングを構成すると、次の問題が発生する場合があります。

RTT をキャプチャするのに十分なパケットがサンプリングされない場合、バイト値などの RTT 測定値が一部のログで欠落することがあります。この現象は、接続が少量である場合に発生する可能性が高くなります。
RTT 値は TCP フローでのみ使用できます。
一部のパケットはペイロードなしで送信されます。ヘッダーのみのパケットがサンプリングされる場合、バイト値は 0 です。

次のステップ

内部パススルーネットワークロードバランサのロギングとモニタリングの構成については、内部パススルーネットワークロードバランサのロギングとモニタリングをご覧ください。
VPC ネットワークに接続されたピアネットワークから内部パススルーネットワークロードバランサにアクセスする方法については、内部パススルーネットワークロードバランサと接続ネットワークをご覧ください。

内部パススルー ネットワーク ロードバランサのトラブルシューティング

ネットワーク アナライザに関する一般的な問題のトラブルシューティング

バックエンドのバランシング モードに互換性がない