リソース正常性と受信の可用性に関する問題をトラブルシューティングする

  • [アーティクル]

この記事は、ロードバランサーのフロントエンド IP とバックエンド リソースの可用性に影響を与える問題を調査するためのガイドです。

ロード バランサーのリソース正常性チェック (RHC) は、ロード バランサーの正常性を判定するために使用されます。 データ パスの可用性メトリックを 2 分の間隔で分析して、負荷分散エンドポイント、フロントエンド IP、フロントエンド ポートの負荷分散規則との組み合わせが使用可能かどうかを判定します。

注: Basic SKU Load Balancer では RHC はサポートされていません

次の表では、ロード バランサーの正常性状態を判定するために使用される RHC ロジックについて説明します。

リソースの正常性状態 説明
利用可能 ご利用の Standard Load Balancer リソースは正常であり、使用可能です。
低下しています Standard Load Balancer のプラットフォームやユーザーが開始したイベントのパフォーマンスが影響を受けます。 データパスの可用性メトリックで、少なくとも 2 分間、90% より低く 25% より高い正常性が報告されました。 中程度から深刻なパフォーマンス低下が発生します。
利用不可 ご利用の Standard Load Balancer リソースは正常ではありません。 データパスの可用性メトリックで、少なくとも 2 分間、25% より低い正常性が報告されました。 パフォーマンスが大幅に低下したり、インバウンド接続を利用できなくなったりします。 ユーザーまたはプラットフォームのイベントが使用できなくなる可能性があります。
Unknown Standard Load Balancer リソースのリソース正常性状態が更新されていないか、データ パス可用性情報を過去 10 分間受信していません。 この状態は一時的なものであり、データが受信されれば、すぐに正しい状態が反映されます。

使用するメトリックについて

使用する 2 つのメトリックは、"データ パスの可用性" と "正常性プローブの状態" で、適切な洞察を得るためにはこれらの意味を理解しておくことが重要です。

データ パスの可用性

データ パスの可用性メトリックは、負荷分散規則とインバウンド NAT 規則が構成されているすべてのフロントエンド ポートで 25 秒ごとに TCP ping によって生成されます。 この TCP ping は、正常な (プローブされた) バックエンド インスタンスのいずれかにルーティングされます。 サービスが ping に対する応答を受信した場合は、正常な応答であり、メトリックの合計が 1 回反復処理されます。 応答がない場合、反復処理は行われません。 このメトリックのカウントは、サンプル期間あたりの TCP ping 総数の 1/100 です。 そのため、平均を考慮する必要があり、これはその期間における合計とカウントの平均です。 データでは平均で集計されたパスの可用性メトリックが示され、したがって、各負荷分散規則とインバウンド NAT 規則についてのフロントエンドの IP:ポートでの TCP ping の成功率のパーセントがわかります。

正常性プローブの状態

正常性プローブの状態メトリックは、正常性プローブで定義されたプロトコルの ping によって生成されます。 この ping は、正常性プローブで定義されているバックエンド プールとポートの各インスタンスに送信されます。 HTTP および HTTPS プローブの場合、ping を成功させるには HTTP 200 OK の応答が必要ですが、TCP プローブでは、すべての応答が成功と見なされます。 各プローブが連続成功するか失敗するかによって、バックエンド インスタンスの正常性と、割り当てられたバックエンド プールがトラフィックを受信できるかどうかが判断されます。 データ パスの可用性と同様に、平均集計を使用します。これにより、サンプリング間隔中の合計 ping に占める成功の平均が示されます。 この正常性プローブの状態の値は、フロントエンド経由でトラフィックを送信することなくバックエンド インスタンスを調査することにより、ロード バランサーとは無関係のバックエンドの正常性を示します。

重要

正常性プローブの状態は、1 分ごとにサンプリングされます。 これにより、通常だと安定した値なのに軽微な変動が生じることがあります。 たとえば、2 つのバックエンド インスタンスがあり、1 つがプローブ対象、もう 1 つがプローブ対象外の場合、正常性プローブ サービスは正常なインスタンスのサンプルを 7 個、異常なインスタンスを 6 個キャプチャすることがあります。 これにより、1 分間の間隔で、以前の安定した値 50 が 46.15 として表示されます。

機能低下および使用できないロード バランサーを診断する

リソースの正常性に関する記事で説明されているように、機能低下したロード バランサーは、データ パスの可用性が 25% から 90% のものです。 使用できないロード バランサーは、2 分間にわたり、データ パスの可用性が 25% 未満のものです。 同じ手順を使って、構成した正常性プローブの状態またはデータ パスの可用性に関するアラートで示される障害を調べることができます。 ここでは、リソースの正常性をチェックして、データ パスの可用性が 0% でロード バランサーを利用できない (サービスが停止している) ことがわかった場合について調べます。

まず、Azure portal のロード バランサーの分析情報ページの詳細なメトリック ビューに移動します。 ロード バランサー リソースのページまたはリソース正常性メッセージ内のリンクから、ビューにアクセスします。 次に、[Frontend and Backend availability](フロントエンドとバックエンドの可用性) タブに移動し、機能低下または使用できない状態が発生した 30 分間の時間ウィンドウを確認します。 データ パスの可用性が 0% であることが判明した場合、すべての負荷分散規則とインバウンド NAT 規則についてトラフィックを妨げている問題があることがわかり、この問題が続いている期間を確認できます。

次に調べる必要があるのは正常性プローブの状態メトリックです。これにより、データ パスが使用できない理由が、トラフィックを処理する正常なバックエンド インスタンスがないことであるかどうかを判断します。 すべての負荷分散規則とインバウンド規則に対して正常なバックエンド インスタンスが少なくとも 1 つある場合、構成が原因でデータ パスが使用できなくなっているわけではないことがわかります。 このシナリオは、Azure プラットフォームの問題を示しています。 プラットフォームの問題はまれですが、すべてのプラットフォームの問題を迅速に解決するために、自動アラートが Microsoft のチームに送信されます。

正常性プローブの失敗を診断する

たとえば、正常性プローブの状態を確認し、すべてのインスタンスが異常と表示されているとします。 ここでは、データ パスが使用できないのは、トラフィックの行き場がないためであることが説明されています。 次に、次のチェックリストを参照して、一般的な構成エラーを除外します。

  • リソースの CPU 使用率を調べて、負荷が高いかどうかを判断します。
  • HTTP または HTTPS プローブを使用している場合、アプリケーションが正常で応答性があるかどうかを確認します。
    • アプリケーションが機能していることを確認するには、バックエンド インスタンスに関連付けられているプライベート IP アドレスまたはインスタンスレベルのパブリック IP アドレスを使用して、アプリケーションに直接アクセスします。
  • バックエンド リソースに適用されているネットワーク セキュリティ グループを確認します。 正常性プローブをブロックしている AllowAzureLoadBalancerInBound より優先順位の高い規則がないことを確認します。
    • バックエンド VM または Virtual Machine Scale Sets の [ネットワーク] の設定で、これを行うことができます。
    • この NSG の問題が見つかった場合は、既存の許可規則を移動するか、優先度の高い新しい規則を作成して AzureLoadBalancer トラフィックを許可します。
  • OS を確認します。 VM がプローブ ポートでリッスンしていることを確認し、OS のファイアウォール規則を確認して、IP アドレス 168.63.129.16 から送信されるプローブ トラフィックをブロックしていないことを確認します。
    • Windows コマンド プロンプトで netstat -a を実行するか、Linux ターミナルで netstat -l を実行することで、リスニング ポートを確認できます。
  • 確実に適切なプロトコルを使用してください。 たとえば、HTTP を使用して HTTP 以外のアプリケーションをリッスンしているポートをプローブするプローブは失敗します。
  • Azure Firewall をロード バランサーのバックエンド プールに配置しないでください。 Azure Firewall とロード バランサーの適切な統合については、「Azure Firewall と Azure Standard Load Balancer を統合する」をご覧ください。

このチェックリストのとおりにしても正常性プローブの障害がまだ検出される場合は、お客様のインスタンスのプローブ サービスに影響を与える珍しいプラットフォームの問題が発生している可能性があります。 この場合では Azure のサポートを受けられ、すべてのプラットフォームの問題を迅速に解決するための自動アラートが Microsoft のチームに送信されます。

次のステップ