負荷分散の問題のトラブルシューティング
Azure には、さまざまな負荷分散ソリューションが用意されています。 Traffic Manager は、DNS を使用して、任意のプロトコルの最適なエンドポイントにクライアント要求をリダイレクトすることにより、高可用性と迅速な応答時間を実現します。 Front Door は、HTTP 要求にプロキシを使用して、高可用性と迅速な応答時間を実現します。 Traffic Manager と Front Door はネットワーク層とトランスポート層で負荷分散を行います。
Application Gateway は、ネットワーク層とトランスポート層ではなく、アプリケーション層で負荷分散を行います。 つまり、着信 URL に基づいてトラフィックをルーティングできます。 たとえば、/media を含む URL のトラフィックを特定のサーバー セットにルーティングできます。
Load Balancer は、ネットワーク層とトランスポート層で動作し、任意のプロトコルを使用する受信と送信の両方のトラフィックに対して内部および外部の負荷分散を実現します。
それぞれの負荷分散ソリューションには、異なるトラブルシューティングのステップが必要です。
Azure Traffic Manager の状態を確認する
Traffic Manager の設定が正しいかどうかをテストするには、複数のクライアントを複数の場所に配置する必要があります。 その後、次のステップに従って、フェールオーバーの DNS 解決を確認できます。
ipconfig /flushdns を実行して、DNS キャッシュをフラッシュします。
会社のドメインに対して nslookup を実行し、それがプライマリ エンドポイントに解決されることを確認します。
プライマリ エンドポイントを停止し、Traffic Manager プロファイルの有効期限 (TTL) の時間からさらに 2 分間待機します。
ipconfig /flushdns を実行して、DNS キャッシュをフラッシュします。
nslookup 要求を繰り返し、それがセカンダリ エンドポイントに解決されることを確認します。
エンドポイントごとにこれらのステップを繰り返します。
また、すべてのエンドポイントをアップのままにしてキャッシュを繰り返しフラッシュし、nslookup を実行してトラフィックが各エンドポイントを循環していることを確認することで、重み付けされたトラフィック ルーティングをテストすることもできます。
さまざまな地理的場所から接続し、適切なエンドポイントが nslookup によって返されるかどうかをテストすることで、パフォーマンスのルーティングをテストすることができます。
詳細については、「Traffic Manager について」を参照してください。
負荷分散クラスター内の仮想マシンが正常であるかどうかを判断する
Azure Load Balancer は正常性プローブを使用して、インスタンスが正常かどうかを検出します。 正常性プローブが接続を確立できない場合、ロード バランサーはそのインスタンスへの接続の送信を停止します。
ロードバ ランサー セット内の仮想マシン (VM) が正常性プローブに応答していない場合はどうなるでしょうか? 考えられる理由は多数あります。
バックエンド プール VM が正常な状態ではありません。
- これをテストするには、プール内の別の VM から ping 要求を送信してみてください。 この VM は、プールに含まれる要求に応答できるはずです。
バックエンド プール VM が、プローブ ポートからの接続を許可していません。
- バックエンド VM から netstat-an を実行し、正しいポートがリッスン中と表示されていることを確認します。 バックエンド VM またはロード バランサーが同じポートを使用するように構成する必要があります。
ファイアウォールまたは NSG では、プローブ ポートからの接続は許可されません。
- バックエンド VM とロードバランサーが同じポートを使用している場合は、これがファイアウォールまたは NSG によってブロックされていないことを確認します。
ロード バランサーの構成が正しくありません。
- 前のテストがすべて成功した場合は、ロード バランサー セット内の複数の VM からの受信と送信のパケットのネットワークを分析して、問題を特定します。
詳細については、「Azure Load Balancer の正常性プローブの状態に関するトラブルシューティング」を参照してください。
ロード バランサーの規則を確認する
ロード バランサーの規則により、ロード バランサー セットにトラフィックを分散する方法が定義されます。 これは、たとえば特定の VM がその受信 IP アドレスに基づいて特定のトラフィックのみを受信することを意味する可能性があります。
トラフィックが想定どおりに動作しない場合は、ロード バランサーの規則を確認してください。
詳細については、「Azure portal を使用して Azure Load Balancer のルールを管理する」を参照してください。
ロード バランサーの構成に基づいてリソースがどのように割り当てられているかを判断する
ロード バランサーは通常、トラフィックを均等に分散するために使用されます。 ロード バランサーからのトラフィックの分散が均等でない理由は 2 つあります。
セッションの永続化が有効になっています。
- セッションの永続化によって各クライアントとサーバーのペアが永続化されるため、負荷分散が想定どおりに実行されません。
クライアントがプロキシ サーバーの内側にあります。
- プロキシ サーバーにより、複数のクライアントが 1 つのクライアントとして表示される可能性があるため、負荷分散が想定どおりに実行されません。
負荷分散されたプール内の VM が正常に見えても、要求に応答していない場合、いくつかの理由が考えられます。
バックエンド VM が正しいポートでリッスンしていないか、ポートが開いていない可能性があります。
ネットワーク セキュリティ グループがポートをブロックしている可能性があります。
バックエンド VM 上のアプリケーションが、同じネットワーク インターフェイス上の別のアプリケーションにアクセスしようとしています。 これはサポートされていません。
バックエンド VM が、ロード バランサーを介してリソースにアクセスしようとしています。 これはサポートされていません。
詳細については、「Azure Load Balancer のバックエンド トラフィック応答に関するトラブルシューティング」を参照してください。
ポートの枯渇問題のトラブルシューティング
外部接続にロード バランサーが使用される場合は、ポートの枯渇に注意する必要があります。 使用可能なポートは 64,000 ありますが、ロード バランサーが使用されている場合、各接続で 8 つのポートが使用されます。 そのため、バックエンド インスタンスが多数ある場合は、使用可能なポートが枯渇する可能性があります。
詳細については、「アウトバウンド接続エラーのトラブルシューティング」を参照してください。
Azure Front Door のトラブルシューティング
負荷分散に Azure Front Door を使用していて、一般的なルーティングの問題のトラブルシューティングを行いたい場合は、まず Front Door に追加のデバッグ HTTP 応答ヘッダーを返すように要求する必要があります。
詳細については、「Azure Front Door での HTTP ヘッダー プロトコルのサポート」を参照してください。
HTTP グループ応答ヘッダーがある場合、デバッグに使用できる Azure Front Door からの応答がいくつかあります。
数秒後に 503 応答が返された場合、通常の要求は Azure Front Door を介さずにバックエンドに送信されることになります。 この問題を解決するには、エンドポイントに配信元応答のタイムアウトを構成し、既定のタイムアウトを延長します。
Azure Front Door から 503 応答を受信していますが、HTTPS 要求の場合のみです。 これには、次のような理由が考えられます。
バックエンド プールが IP アドレスです。
バックエンド サーバーが、Azure Front Door バックエンド プールの完全修飾ドメイン名と完全には一致しない証明書を返しています。
バックエンド プールが Azure Web アプリ サーバーです。
要求がカスタム ドメインに送信されたときに、400 状態コードを受信しています。
- この問題は、カスタム ドメインがフロントエンド ホストとして追加されたときに、それに対するルーティング規則を作成していないことが原因で発生します。
フロントエンド ホストから 411 状態コードを受信しています。
- これらの状態コードは、HTTP 要求が完全に RFC に準拠していない場合に生成されます。
詳細については、「Azure Front Door の一般的な問題のトラブルシューティング」を参照してください。
Azure Application Gateway のトラブルシューティング
Application Gateway は、バックエンド サーバーをプローブして、正常性状態を確認します。 これらのサーバーが正常に応答しなかった場合、Application Gateway は応答不能としてマークし、要求の送信を停止します。 サーバーの応答が正常に開始されると、Application Gateway は要求の送信を再開します。
詳細については、「Application Gateway のバックエンドの正常性に関する問題のトラブルシューティング」を参照してください。
Azure Load Balancer のトラブルシューティング
Azure Load Balancer を使用する場合は、次のようないくつかのトラブルシューティングのステップを考慮する必要があります。
既定では、標準の内部ロード バランサーはセキュリティで保護されていますが、基本的な内部ロード バランサーは、非表示の IP アドレスを介してインターネットに接続できます。 これは運用環境のワークロードには推奨されません。送信トラフィックにはネットワーク ゲートウェイのソリューションが推奨されます。
正常性プローブを使用している場合、バックエンド ポートを負荷分散用に変更することはできません。 この問題を解決するには、正常性プローブを削除し、ポートを再構成してから、正常性プローブをもう一度追加します。
VM がバックエンド プールから削除されても、まだネットワーク トラフィックを受信している場合は、ストレージ、DNS、またはその他の Azure の機能が原因である可能性があります。
詳細については、Azure Load Balancer のトラブルシューティングに関する記事を参照してください。
Traffic Manager プロファイルに関する問題のトラブルシューティング
Azure Traffic Manager は 6 つのトラフィック ルーティング方法を使用します。 優先順位、重み付け、パフォーマンス、地理的、複数値、およびサブネットです。 間違ったトラフィック ルーティング方法を選択した場合、想定される動作が実行されない可能性があります。 優先順位を使用しているのに (たとえば、パフォーマンスを使用して) 最も近いエンドポイントに移動しようとすると、トラフィックはすべてのトラフィックでプライマリ サービス エンドポイントに向かう可能性があります。
詳細については、「Traffic Manager のルーティング方法」を参照してください。
待機時間に関する問題のトラブルシューティング
負荷分散されたネットワークで待ち時間の問題がある場合、仮想マシンのネットワーク待機時間と同じ方法でテストする必要があります。 ping などの一般的な接続ツールを使用できますが、他の専門的なサードパーティ製ツールを使用すると、より多くの情報が提供されます。 待ち時間の問題をテストするには、2 つの仮想マシン (1 つは送信者、もう 1 つは受信側) を使用する方が良い方法です。 これにより、仮想マシン間とロード バランサーによる双方向通信をテストできます。
詳細については、「VM ネットワークの待ち時間のテスト」を参照してください。