サーバが「DOWN」とマークされる一般的な理由は次のとおりです。

ARP が未解決

サービス エンジンがサーバの IP アドレスの MAC アドレスを解決できない場合（同じレイヤー 2 ドメイン内にある場合)、または TCP 接続を開始できない場合（サーバがレイヤー 3 ホップ離れている場合)。

ペイロードの不一致

健全性モニターは、応答（HTTP または TCP）の本文で特定のコンテンツが返されることを想定しています。この例には、サーバの応答の抜粋が示されています。多くの場合、このタイプのエラーは、サーバの最初の応答がクライアントにリダイレクトを送信することである場合に発生します。想定されるコンテンツがクライアント ブラウザに表示されますが、NSX Advanced Load Balancer 側から見ると、クライアントはリダイレクトを受け取ります。

応答コードの不一致

HTTP 健全性チェックは、2xx などの特定の応答コードを想定するように構成できます。一方、サーバは 404 などの別のコードを返送することができます。

しきい値違反による応答タイムアウト

健全性モニターは応答のタイムアウト期間を待機し、すべての健全性モニターをしきい値とタイムアウト期間に割り当てることができます。有効な応答が、しきい値として設定された N 回連続でタイムアウト期間内に受信されない場合、サーバは DOWN とマークされます。

NSX Advanced Load Balancer は簡単なトラブルシューティングのために設計されていますが、より高度なツールが必要になります。したがって、[操作] > [トラフィック キャプチャ] の順に移動することで、SE とサーバ間の会話のトレースをキャプチャできます。

トラフィック キャプチャの詳細については、『VMware NSX Advanced Load Balancer 管理ガイド』の「パケット キャプチャ」を参照してください。

クライアント マシンからサーバへの起動中に ping や curl などのツールを使用できます。ただし、SE から管理者によってツールが実行される場合、これらのツールは信頼できません。これは、データ プレーンと管理に使用されるデュアル ネットワーク スタックが原因です。たとえば、ping などのツールは、SE 管理 IP アドレスとネットワークを使用して Linux から実行されます。結果は、データ NIC およびネットワークを介して健全性チェックを報告している SE とは異なる場合があります。たとえば、ping -1 を使用して、使用されているインターフェイスを検証します。