Azure Load Balancer の正常性プローブの状態に関するトラブルシューティング

  • [アーティクル]

このページには、Azure Load Balancer の正常性プローブについてよく寄せられる質問のトラブルシューティング情報が記載されています。

症状: Load Balancer の背後にある VM が正常性プローブに応答しない

バックエンド サーバーがロード バランサ― セットに参加するには、プローブ チェックを渡す必要があります。 正常性プローブの詳細については、Load Balancer のプローブに関するページをご覧ください。 

Load Balancer バックエンド プール VM は、次のいずれかの理由によりプローブに応答しない可能性があります。

  • Load Balancer バックエンド プール VM が正常でない
  • Load Balancer バックエンド プール VM がプローブ ポートでリッスンしていない
  • ファイアウォール、またはネットワーク セキュリティ グループが Load Balancer バックエンド プール VM 上のポートをブロックしている
  • Load Balancer の他の構成ミス

原因 1:Load Balancer バックエンド プール VM が正常でない

検証と解決策

この問題を解決するには、参加している VM にサインインし、VM の状態が正常かどうか、また、その VM が、プール内の他の VM からの PsPing または TCPing に応答できるかどうかを確認します。 VM が正常でない場合、またはプローブに応答できない場合、その VM を負荷分散に参加させるには、問題を解決してから、VM を正常な状態に戻す必要があります。

原因 2: Load Balancer バックエンド プール VM がプローブ ポートでリッスンしていない

VM の状態が正常であるにもかかわらず、プローブに応答していない場合、参加している VM のプローブ ポートが開いていないか、そのポート上で VM がリッスンしていないことが原因の 1 つとして考えられます。

検証と解決策

  1. バックエンド VM にサインインします。
  2. コマンド プロンプトを開き、コマンド netstat -an を実行して、プローブ ポートでリッスンしているアプリケーションが存在かどうかを検証します。
  3. ポートの状態が "リッスン中" になっていない場合は、適切なポートを構成します。
  4. または、"リッスン中" として表示されている別のポートを選択し、ロード バランサ―の構成を適宜更新します。

原因 3:ファイアウォール、またはネットワーク セキュリティ グループが Load Balancer バックエンド プール VM 上のポートをブロックしている

VM 上のファイアウォールがプローブ ポートをブロックしているか、サブネットまたは VM 上に構成された 1 つ以上のネットワーク セキュリティ グループが、ポートへのプローブのアクセスを許可していない場合、VM は正常性プローブに応答できません。

検証と解決策

  1. ファイアウォールが有効になっている場合は、プローブ ポートを許可するように構成されているかどうかを確認します。 許可する構成になっていない場合は、プローブ ポートのトラフィックを許可するように構成し、再度テストします。
  • IP アドレス 168.63.129.16 から送信されたプローブ トラフィックが VM のファイアウォールによってブロックされていないことを確認します
  • netstat -aWindows のコマンドプロンプトまたは Linux ターミナルからを実行して、リスニングポートを確認できます。 netstat -l
  • ファイアウォール プロファイルを照会し、Windows コマンド プロンプトで netsh advfirewall show allprofiles | more を実行するか、Linux ターミナルから sudo iptables -L を実行して、構成されているすべてのファイアウォール規則を表示することで、ポリシーによって受信トラフィックがブロックされているかどうかを確認できます。
  • Azure VM のファイアウォールに関する問題のトラブルシューティングについて詳しくは、「Azure VM のゲスト OS のファイアウォールがインバウンド トラフィックをブロックしている」をご覧ください。
  1. ネットワーク セキュリティ グループの一覧で、プローブ ポートの受信または送信トラフィックで干渉が発生していないかどうかを確認します。
  2. また、サブネットまたは VM の NIC で、すべて拒否ネットワーク セキュリティ グループ ルールの優先順位が、LB プローブとトラフィックを許可する既定のルールよりも高くなっていないかどうかを確認します (ネットワーク セキュリティ グループでは、Load Balancer IP アドレス 168.63.129.16 が許可されている必要があります)。
  3. ルールのいずれかがプローブのトラフィックをブロックしている場合は、そのルールを削除し、プローブ トラフィックを許可するように再構成します。 
  4. VM が正常性プローブに応答するようになったかどうかをテストします。

原因 4:Load Balancer の他の構成ミス

上記の原因すべてを検証し、正しく解決したにもかかわらず、バックエンド VM が正常性プローブに応答しない場合は、手動で接続をテストし、トレースをいくつか収集して、接続状況を把握します。

検証と解決策

  1. VNet 内にある他の VM から Psping でプローブ ポートの応答をテストし (.\psping.exe-t 10.0.0.4:3389 など)、結果を記録します。
  2. VNet 内にある他の VM から TCPing でプローブ ポートの応答をテストし (.\tcping.exe 10.0.0.4 3389 など)、結果を記録します。
  3. この ping テストで応答がない場合は、次の操作を行います
    • 同じ VNet のターゲット バックエンド プール VM と他のテスト VM で同時 Netsh トレースを実行します。 ここで、しばらくの間 PsPing テストを実行し、ネットワーク トレースをいくつか収集して、テストを停止します。
    • ネットワーク キャプチャを分析し、ping クエリに関連する受信パケットと送信パケットの両方があるかどうかを確認します。
      • バックエンド プール VM に受信パケットがない場合は、トラフィックをブロックしているネットワーク セキュリティ グループまたは UDR の構成ミスが存在する可能性があります。
      • バックエンド プール VM に送信パケットがない場合は、関連のない問題 (アプリケーションがプローブ ポートをブロックしている、など) が VM にないかどうかを確認する必要があります。
    • プローブが、ロード バランサーに到達する前に、他の場所に (おそらく UDR 設定によって) 強制的に転送されていないかどうかを確認します。 この場合、トラフィックは、バックエンド VM に到達しません。
  4. プローブの種類を (たとえば、HTTP から TCP に) 変更し、ネットワーク セキュリティ グループ ACL とファイアウォールの対応するポートを、プローブ応答の構成に問題があるかどうかを検証するように構成します。 正常性プローブ構成の詳細については、正常性プローブ構成のエンドポイント負荷分散に関するページをご覧ください。

次のステップ

前の手順で問題を解決できない場合は、サポート チケットを開きます。