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

このガイドでは、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.internal169.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 に接続します。次に、curltelnet または同様のツールを使用して、次のテストを行います。

  • バックエンド 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 でパケット キャプチャを実行する方法は次のとおりです。

  1. サーバーに tcpdump をインストールします。
  2. サーバーで tcpdump のキャプチャを開始します。
  3. クライアントから、次のようなサンプル リクエストを発行します。

    curl URL
    
  4. tcpdump の出力を分析して、問題を特定します。

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

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

  1. 1 つのクライアントと 1 台のサーバー(ロード バランシングなし)。
  2. 1 つのクライアントと 1 台のサーバー(ロード バランシングあり)。

    結果: テスト [1] と [2] の結果の組み合わせで、ロードバランサが問題の原因かどうかを確認できます。

  3. 1 つのクライアントと複数のサーバー(ロード バランシングあり)。

    結果: 1 つのクライアントのパフォーマンス上限を確認します。

  4. 複数のクライアントと 1 台のサーバー(ロード バランシングあり)。

    結果: 1 台のサーバーのパフォーマンス上限を特定します。

  5. 複数のクライアントと複数のサーバー(ロード バランシングなし)。

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

複数のクライアントまたはサーバーでストレステストを実行すると、クライアントまたはサーバーのリソース(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 です。

次のステップ