プール内のサーバのステータスには、「稼動中」、「停止」、または「無効」（管理者によって管理上無効にされる）があります。状態は、サーバ プールに適用される、関連付けられた健全性モニターによって決まります。 

NSX Advanced Load Balancer は、いくつかの理由でサーバを停止としてマークする場合があり、これには、3 つの異なる方法でアクセスできます。すべての方法でほぼ同じ情報が表示されます。

  • [停止の健全性スコア アイコン]：ユーザー インターフェイスでサーバの赤い状態アイコンの上にマウスを置きます。



  • [停止イベント]：サーバ、プール、および仮想サービスのイベントに移動します。イベントを展開して、完全な詳細を表示します。この情報を使用してアラートを自動的に生成し、場合によってはシステムをさらに変更します。詳細については、アラートの概要を参照してください。

  • [サーバ ページ]：[アプリケーション] > [プール] > [プール名] > [サーバ] > [サーバ名] の順に移動します。サーバの分析ページが表示されます。



この例では、[Down-HTTP] モニターがサーバを停止とマークしているのに対し、「System-HTTP」モニターはサーバを「稼動中」と報告しています。

注：

パッシブ モニターは特殊なタイプです。パッシブ モニターは、サーバを「停止」とマークしません。代わりに、パッシブ モニターがサーバからクライアントへの不正な応答を検出すると、モニターはそのサーバに対してロード バランシングされたトラフィックの割合を減らします。健全性モニターの横にある [+] 記号をクリックして、サーバの健全性状態に関する追加情報を表示します。

サーバを停止としてマークする一般的な理由

  • [ARP が未解決]：SE がサーバの IP アドレスの MAC アドレスを解決できなかった（同じレイヤー 2 ドメイン内にある場合）、または TCP 接続の開始に失敗しました（サーバがレイヤー 3 ホップ離れている場合）。

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

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

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

NSX Advanced Load Balancer は簡単なトラブルシューティングができるように設計されていますが、より高度なツールが必要になる場合があります。このような場合、SE とサーバ間のやり取りのトレースをキャプチャすると便利な場合があります。（[運用] > [トラフィック キャプチャ] の順に移動します。詳細については、「トラフィック キャプチャ」を参照してください）。

ping や curl などのツールは、クライアント マシンからサーバに起動するときに役立つ場合があります。ただし、SE から管理者が実行した場合、これらのツールは信頼できない場合があります。これは、データ プレーンと管理に使用されるデュアル ネットワーク スタックが原因です。

たとえば、ping などのツールは、SE の管理 IP アドレスとネットワークを使用して Linux から実行されます。結果は、SE がデータ NIC とネットワークを介して健全性チェックを行うときに報告する内容とは異なる場合があります。ping の例では、ping -l を使用して、使用されているインターフェイスを確認します。