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

このガイドでは、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 が適切にタグ付けされていることを確認してください。
外部パススルーネットワークロードバランサに必要なファイアウォールルールを構成する方法については、ファイアウォールルールの構成をご覧ください。
Google ゲストエージェントがバックエンド VM で実行されていることを確認します。正常なバックエンド VM に接続できてもロードバランサに接続できない場合は、VM の Google ゲスト環境（以前の Windows のゲスト環境、または Linux のゲスト環境）が稼働していないか、メタデータサーバー（metadata.google.internal、169.254.169.254）と通信できません。

次の点を確認してください。
- Google ゲストエージェントがバックエンド 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 に到達します。このタイプのロードバランサはプロキシではありません。これは想定された動作です。

ポートでリッスンしているサービスを表示するには、次のコマンドを実行します。
```
netstat -nl | grep ':PORT'
```
バックエンド VM で実行されるソフトウェアでは次の処理が行われている必要があります。
- ロードバランサの IP アドレスまたは任意の IP アドレス（0.0.0.0 または ::）でのリッスン（バインド）
- ロードバランサの転送ルールに含まれるポートでのリッスン（バインド）
これをテストするには、SSH または RDP を使用してバックエンド VM に接続します。次に、curl、telnet または同様のツールを使用して、次のテストを行います。
- バックエンド VM 自体の内部 IP アドレス、127.0.0.1 または localhost を使用してサービスに接続し、サービスに移動してみます。
- ロードバランサの転送ルールの IP アドレスを使用してサービスに接続し、サービスに移動してみます。
ヘルスチェックトラフィックがバックエンド VM に到達できることを確認します。ヘルスチェックトラフィックがバックエンド VM に到達したことを確認するには、ヘルスチェックロギングを有効にし、成功したログエントリを検索します。

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

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

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

外部パススルーネットワークロードバランサのフェイルオーバーを構成している場合は、次の手順で構成を確認します。

フェイルオーバーバックエンドが 1 つ以上指定されていることを確認します。
フェイルオーバーポリシーの設定を確認します。
アクティブプールのメンバーシップの仕組みや、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 がフェイルオーバーを実行するという特別な意味があります。

他にも、次のような問題が発生する可能性があります。

アクティブプールがプライマリバックエンドとフェイルオーバーバックエンドの間で行き来する（フラッピング）。

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

コネクションドレインを無効にしても機能しません。

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

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

gcloud compute backend-services create my-failover-bs
  --load-balancing-scheme external \
  --health-checks-region us-central1 \
  --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.

既存の接続がフェイルオーバーまたはフェイルバック中に中断します。

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

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

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

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

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

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