Azure Load Balancer のバックエンド トラフィック応答に関するトラブルシューティング
このページには、Azure Load Balancer に関する質問のトラブルシューティング情報が記載されています。
ロードバランサーの背後にある仮想マシンで受信するトラフィックが不均等に分散している
バックエンド プールのメンバーがトラフィックを受信している疑いがある場合は、次の原因が考えられます。 Azure Load Balancer は、接続に基づいてトラフィックを分散します。 パケットごとではなく、接続ごとのトラフィック分散を確認してください。 構成済みの Load Balancer の [分析情報] ダッシュボードの [フローの分布] タブを使用して確認します。
Azure Load Balancer は、実際のラウンド ロビン負荷分散をサポートしていませんが、ハッシュベースの分散モードをサポートしています。
原因 1: セッションの永続化が構成されている
ソース永続化分散モードを使用すると、トラフィックの分散が不均等になる可能性があります。 配布が望ましくない場合は、セッションの永続性を None に更新して、トラフィックがバックエンド プール内のすべての正常なインスタンスに分散されるようにします。 Azure Load Balancer の分散モードについては、こちらを参照してください。
原因 2: プロキシが構成されている
プロキシの背後で実行しているクライアントは、ロード バランサーの観点から 1 つの固有のクライアント アプリケーションと見なすことができます。
ロード バランサー の背後にある VM が構成済みデータ ポートのトラフィックに応答しません
バックエンド プール VM が正常として表示され、正常性プローブに応答するにもかかわらず、負荷分散に参加していない、またはデータ トラフィックに応答していない場合は、次のいずれかが原因である可能性があります。
ロード バランサー バックエンド プール VM がデータ ポートでリッスンしていません
ネットワーク セキュリティ グループがロード バランサー バックエンド プール VM 上のポートをブロックしています
同じ VM と NIC からロード バランサーにアクセスしている
参加しているロード バランサー バックエンド プール VM からインターネット ロード バランサー フロントエンドにアクセスしている
原因 1: ロード バランサー バックエンド プール VM がデータ ポートでリッスンしていません
VM がデータ トラフィックに応答しない場合、その原因としては、参加している VM でターゲット ポートが開いていない、または VM がそのポートでリッスンしていないことが考えられます。
検証と解決策
バックエンド VM にログインします。
コマンド プロンプトを開き、次のコマンドを実行して、データ ポートでリッスンしているアプリケーションが存在しているかどうかを検証します。
netstat -anそのポートが LISTENING 状態で表示されていない場合は、適切なリスナー ポートを構成します
ポートが LISTENING としてマークされている場合は、そのポートのターゲット アプリケーションに問題がないかどうかを確認します。
原因 2: ネットワーク セキュリティ グループがロード バランサー バックエンド プール VM 上のポートをブロックしている
サブネットまたは VM で構成されている 1 つ以上のネットワーク セキュリティ グループが、発信元 IP またはポートをブロックしている場合、VM は応答できません。
パブリック ロード バランサーの場合、クライアントとロード バランサーのバックエンド VM の間の通信には、インターネット クライアントの IP アドレスが使用されます。 クライアントの IP アドレスがバックエンド VM のネットワーク セキュリティ グループで許可されていることを確認してください。
バックエンド VM で構成されているネットワーク セキュリティ グループを一覧表示します。 詳しくは、ネットワーク セキュリティ グループの管理に関する記事をご覧ください。
ネットワーク セキュリティ グループの一覧で、次を確認します。
データ ポートの受信または送信トラフィックで干渉が発生しています。
サブネットまたは VM の NIC で、すべて拒否ネットワーク セキュリティ グループ規則の優先順位が、ロード バランサー プローブとトラフィックを許可する既定の規則よりも高くなっていないかどうか (ネットワーク セキュリティ グループでは、プローブ ポートであるロード バランサー IP アドレス 168.63.129.16 が許可されている必要があります)
ルールのいずれかがトラフィックをブロックしている場合は、そのルールを削除し、データ トラフィックを許可するように再構成します。
VM が正常性プローブに応答するようになったかどうかをテストします。
原因 3: 同じ VM とネットワーク インターフェイスから内部ロード バランサーにアクセスしている
内部ロード バランサーのバックエンド VM でホストされているアプリケーションが、同じネットワーク インターフェイスを介して同じバックエンド VM でホストされている別のアプリケーションにアクセスしようとすると、失敗します。このシナリオはサポートされていません。
解像度
この問題を解決するには、次のいずれかの方法を使用します。
アプリケーションごとに個別のバックエンド プール VM を構成する。
各アプリケーションが独自のネットワーク インターフェイスと IP アドレスを使用していたように、デュアル NIC VM でアプリケーションを構成します。
原因4: 参加しているロード バランサー バックエンド プール VM から内部 ロード バランサー フロントエンドにアクセスしている
内部ロード バランサーが仮想ネットワーク内で構成され、参加しているバックエンド VM の 1 つが内部ロード バランサーフロントエンドにアクセスしようとしている場合は、エラーが発生し、アクセス元の VM にフローがマップされます。 このシナリオはサポートされていません。
解像度
このシナリオをブロック解除するには、プロキシの使用などいくつかの方法があります。 Application Gateway または他のサードパーティのプロキシ (nginx や haproxy など) を評価してください。 Application Gateway の詳細については、「Application Gateway の概要」を参照してください
詳細
内部ロード バランサーは、アウトバウンド発信接続を内部ロード バランサーのフロントエンドに変換しません。これは、両方ともプライベート IP アドレス空間にあるためです。 パブリック ロード バランサーは、仮想ネットワーク内のプライベート IP アドレスからパブリック IP アドレスへのアウトバウンド接続を提供します。 内部ロード バランサーの場合、この方法を使用すると、変換が必要ない固有内部 IP アドレス空間内で SNAT ポートの枯渇が発生する可能性が回避されます。
副作用として、バックエンド プール内の VM からの送信フローが、そのプール内の内部ロード バランサーのフロントエンドへのフローを試み、"かつ"、それ自体にマップバックされている場合、フローの 2 つのレッグは一致しません。 これらは一致しないため、フローは失敗します。 フローが、フロントエンドへのフローを作成したバックエンド プール内の同じ VM にマップバックしなかった場合、フローは成功します。
フローがそれ自体にマップバックする場合、送信フローは VM からフロントエンドに発信されるように見え、対応する受信フローは VM からそれ自体に発信されるように見えます。 ゲスト オペレーティング システムの観点からは、同じフローの受信部分と送信部分は、仮想マシン内と一致しません。 TCP スタックは、同じフローのこれらの半分を、同じフローの一部と認識しません。 送信元と送信先が一致しないためです。 フローがバックエンド プール内の他の VM にマップする場合、フローの半分は一致し、VM はフローに応答できます。
このシナリオの症状は、フローがその発生元と同じバックエンドに返されるときに発生する断続的な接続のタイムアウトです。 一般的な回避策としては、内部ロード バランサーの背後にプロキシ レイヤーを挿入し、Direct Server Return (DSR) スタイル ルールを使用することなどが挙げられます。 詳細については、「Azure Load Balancer の複数のフロントエンド」を参照してください。
内部ロード バランサーを任意のサード パーティのプロキシと組み合わせるか、HTTP/HTTPS を使用したプロキシ シナリオに内部の Application Gateway を使用することができます。 この問題はパブリック ロード バランサーを使って軽減できますが、結果として得られるシナリオでは SNAT の枯渇が発生しやすくなります。 慎重に管理しない限り、この 2 番目のアプローチは避けてください。
次のステップ
前の手順で問題を解決できない場合は、サポート チケットを開きます。