リソースの正常性と受信の可用性に関する問題のトラブルシューティング
この記事は、ロード バランサーのフロントエンド IP とバックエンド リソースの可用性に影響する問題を調査するのに役立ちます。
Azure Load Balancer の "リソース正常性" 機能を使って、ロード バランサーの正常性を確認できます。 それは、データ パス可用性メトリックを分析して、負荷分散規則のある負荷分散エンドポイント、フロントエンド IP、フロントエンド ポートの組み合わせが使用可能かどうかを判断します。
Note
Basic Load Balancer では、リソース正常性機能はサポートされていません。
次の表では、ロード バランサーの正常性状態を判断するためのロジックについて説明します。
| リソースの正常性状態 | 説明 |
|---|---|
| 利用可能 | ロード バランサー リソースは正常であり、使用可能です。 |
| Degraded | ロード バランサーには、プラットフォームまたはユーザーによって開始される、パフォーマンスに影響を与えるイベントがあります。 データ パス可用性メトリックは、少なくとも 2 分間、90% より低く 25% より高い正常性を報告しました。 中程度から重大なパフォーマンス低下が発生している可能性があります。 |
| 利用不可 | ロード バランサーのリソースが正常ではありません。 データ パスの可用性メトリックでは、少なくとも 2 分間、正常性が 25% より低いと報告されました。 大幅なパフォーマンスの低下や、受信接続を利用できない状態が発生している可能性があります。 ユーザーまたはプラットフォームのイベントが原因で、可用性が失われている可能性があります。 |
| 不明 | 過去 10 分間、ロード バランサー リソースのリソース正常性状態が更新されていないか、データ パスの可用性情報を受信していません。 この状態は一時的なものである可能性、またはロード バランサーがリソース正常性機能をサポートしていない可能性があります。 |
ロード バランサーの可用性を監視する
Azure Load Balancer がリソース正常性のチェックに使う 2 つのメトリックは、"データ パス可用性" と "正常性プローブ状態" です。 正しい分析情報を得るには、それらの意味を理解することが重要です。
データパスの可用性
TCP ping は、ユーザーが負荷分散規則を構成したすべてのフロントエンド ポートで、25 秒ごとにデータ パス可用性メトリックを生成します。 この TCP ping は、正常な (プローブされた) バックエンド インスタンスのいずれかにルーティングされます。 このメトリックは、サンプル期間について、負荷分散規則ごとに、フロントエンド IP とポートの各組み合わせでの TCP ping の成功率を集計したものです。
正常性プローブの状態
正常性プローブ状態メトリックは、正常性プローブで定義されているプロトコルの ping によって生成されます。 この ping は、正常性プローブで定義されているバックエンド プールとポートの各インスタンスに送信されます。 HTTP と HTTPS プローブの場合は、ping が成功するには HTTP 200 OK 応答が必要です。 TCP プローブでは、すべての応答が成功と見なされます。
Azure Load Balancer は、ユーザーがプローブしきい値プロパティに対して構成した、連続する成功または失敗の数にプローブが達した時点で、各バックエンド インスタンスの正常性を決定します。 各バックエンド インスタンスの正常性状態によって、バックエンド インスタンスがトラフィックの受信を許可されるかどうかが決まります。
データ パス可用性メトリックと同様に、正常性プローブ状態メトリックは、サンプリング間隔について、ping の平均成功数と合計数を集計したものです。 この正常性プローブの状態の値は、フロントエンド経由でトラフィックを送信することなくバックエンド インスタンスを調査することにより、ロード バランサーから切り離したバックエンドの正常性を示します。
重要
正常性プローブ状態は、1 分ごとにサンプリングされます。 そのため、このようなサンプリングを行わなければ安定している値であっても、わずかな変動が生じることがあります。
たとえば、2 つのバックエンド インスタンス (1 つはプローブ結果がアップ、1 つはプローブ結果がダウン) があるアクティブ/パッシブ シナリオについて考えます。 正常性プローブ サービスは、正常なインスタンスで 7 個のサンプル、異常なインスタンスで 6 個をキャプチャすることがあります。 このような状況では、それまで 50 で安定していた値が、ある 1 分間については 46.15 になります。
機能低下および使用できないロード バランサーを診断する
リソースの正常性に関するこちらの記事で説明されているように、機能が低下したロード バランサーでは 25% から 90% の間のデータ パス可用性が示されます。 利用できないロード バランサーは、2 分間にわたり、データ パス可用性が 25% 未満のものです。
同じ手順を実行して、構成した正常性プローブ状態またはデータ パス可用性のアラートで示される障害を調べることができます。 次の手順では、リソースの正常性を調べて、データ パス可用性の値が 0% でロード バランサーを使用できないことがわかった場合の対処方法について説明します。 サービスがダウンしています。
Azure portal で、ロード バランサー分析情報ページの詳細メトリック ビューに移動します。 ロード バランサー リソースのページまたはリソース正常性メッセージのリンクから、ビューにアクセスします。
フロントエンドとバックエンドの可用性のタブに移動し、機能低下または利用不可の状態が発生した期間の 30 分枠を調べます。 データ パス可用性の値が 0% の場合、すべての負荷分散規則について何かがトラフィックを妨げていることがわかります。 この問題がどのくらい続いたかも確認できます。
正常性プローブ状態メトリックを調べて、トラフィックを処理する正常なバックエンド インスタンスがないためにデータ パスを使用できないかどうかを判断します。 すべての負荷分散規則と受信規則について正常なバックエンド インスタンスが少なくとも 1 つある場合、データ パスを利用できない原因が構成ではないことがわかります。 このシナリオは、Azure プラットフォームの問題を示しています。 プラットフォームの問題はまれですが、迅速な解決のためにチームに自動アラートがトリガーされます。
正常性プローブの失敗を診断する
バックエンド インスタンスが異常であることが正常性プローブ状態メトリックで示されている場合は、以下のチェックリストを使って一般的な構成エラーを除外することをお勧めします。
リソースの CPU 使用率を調べて、負荷が高いかどうかを判断します。
[メトリクス] ページでリソースの CPU 使用率メトリックを表示して調べることができます。 詳しくは、「Azure Windows 仮想マシンでの CPU 使用率の高い問題のトラブルシューティング」をご覧ください。
HTTP または HTTPS プローブを使っている場合は、アプリケーションが正常で応答しているかどうかを調べます。
バックエンド インスタンスに関連付けられたプライベート IP アドレスまたはインスタンス レベルのパブリック IP アドレスを通してアプリケーションに直接アクセスし、機能していることを検証します。
バックエンド リソースに適用されているネットワーク セキュリティ グループ (NSG) を確認します。 正常性プローブをブロックしている
AllowAzureLoadBalancerInBoundより優先順位の高い規則がないことを確認します。このタスクは、バックエンド VM または仮想マシン スケール セットのネットワークの設定に移動して行うことができます。 この NSG の問題が原因であることがわかった場合は、既存の
Allow規則を移動するか、優先度の高い新しい規則を作成して、Azure Load Balancer のトラフィックを許可します。OS を確認します。 VM がプローブ ポートでリッスンしていることを確認します。 また、VM の OS ファイアウォール規則を調べて、IP アドレス
168.63.129.16から送信されるプローブ トラフィックをブロックしていないことを確認します。Windows コマンド プロンプトで
netstat -aを実行するか、Linux ターミナルでnetstat -lを実行することで、リスニング ポートを確認できます。適切なプロトコルを使っていることを確認します。 たとえば、HTTP ではないアプリケーションをリッスンしているポートをプローブするために HTTP を使うプローブは失敗します。
ロード バランサーのバックエンド プールに Azure Firewall を置かないでください。 詳しくは、「Azure Firewall と Azure Standard Load Balancer を統合する」をご覧ください。