NSX CLI を使用すると、詳細なログ情報やパケットを収集し、ロード バランサのトラブルシューティングに役立つメトリックを確認できます。

問題

ロード バランシングを期待とおりに機能しない

解決方法

  1. 仮想アプライアンスで SSH を有効にできるかどうかを確認します。Edge Services Gateway は、デプロイ時に SSH を有効にするオプションを備えた仮想アプライアンスです。SSH を有効にする必要がある場合は、必要なアプライアンスを選択し、[アクション (Actions)] メニューで [CLI 認証情報の変更 (Change CLI Credentials)] をクリックします。
    イメージは、周囲のテキストで説明されています。
  2. Edge Services Gateway には、実行時の状態や設定状態を確認するための show コマンドが複数あります。設定情報や統計情報を表示するには、これらのコマンドを使用します。 
    nsxedge> show configuration loadbalancer 
nsxedge> show configuration loadbalancer virtual [virtual-server-name] 
nsxedge> show configuration loadbalancer pool [pool-name] 
nsxedge> show configuration loadbalancer monitor [monitor-name] 
nsxedge> show configuration loadbalancer profile [profile-name] 
nsxedge> show configuration loadbalancer rule [rule-name]
  3. ロード バランシングと NAT を正しく機能させるには、ファイアウォールを有効にする必要があります。#show firewall コマンドを使用してください。このコマンドを使用しても期待する情報が得られない場合は「ロード バランサ設定の確認とユーザー インターフェイスを使用したトラブルシューティング」セクションを参照してください。
    Edge CLI コマンド show firewall の出力例。
  4. ロード バランサを正しく機能させるには NAT が必要です。show nat コマンドを使用してください。このコマンドを使用しても期待する情報が得られない場合は「ロード バランサ設定の確認とユーザー インターフェイスを使用したトラブルシューティング」セクションを参照してください。
    Edge CLI コマンド show nat の出力例。
  5. ファイアウォールを有効にし、ロード バランサに NAT ルールを適用するほか、ロード バランシング プロセスを有効にする必要もあります。ロード バランサ エンジンのステータス (L4/L7) を確認するには、show service loadbalancer コマンドを使用します。 
    nsxedge> show service loadbalancer
haIndex:              0
-----------------------------------------------------------------------
Loadbalancer Services Status:

L7 Loadbalancer     : running
-----------------------------------------------------------------------
L7 Loadbalancer Statistics:
STATUS     PID        MAX_MEM_MB MAX_SOCK   MAX_CONN   MAX_PIPE   CUR_CONN   CONN_RATE  CONN_RATE_LIMIT MAX_CONN_RATE
running    1580       0          2081       1024       0          0          0          0               0
-----------------------------------------------------------------------
L4 Loadbalancer Statistics:
MAX_CONN   ACT_CONN   INACT_CONN TOTAL_CONN
0          0          0          0

Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
    1. show service loadbalancer session コマンドを使用して、ロード バランサのセッション テーブルを表示します。システムにトラフィックがある場合はセッションが表示されます。 
      nsxedge> show service loadbalancer session
-----------------------------------------------------------------------
L7 Loadbalancer Statistics:
STATUS     PID        MAX_MEM_MB MAX_SOCK   MAX_CONN   MAX_PIPE   CUR_CONN   CONN_RATE  CONN_RATE_LIMIT MAX_CONN_RATE
running    1580       0          2081       1024       0          0          0          0               0

-----------------L7 Loadbalancer Current Sessions:

0x2192df1f300: proto=unix_stream src=unix:1 fe=GLOBAL be=<NONE> srv=<none> ts=09 age=0s calls=2 rq[f=c08200h,
i=0,an=00h,rx=20s,wx=,ax=] rp[f=008000h,i=0,an=00h,rx=,wx=,ax=] s0=[7,8h,fd=1,ex=] s1=[7,0h,fd=-1,ex=] exp=19s


-----------------------------------------------------------------------
L4 Loadbalancer Statistics:
MAX_CONN   ACT_CONN   INACT_CONN TOTAL_CONN
0          0          0          0

L4 Loadbalancer Current Sessions:

pro expire state       source       virtual    destination
    2. show service loadbalancer コマンドを使用して、ロード バランサのレイヤー 7 スティッキー テーブルのステータスを確認します。このテーブルにはアクセラレーション対応の仮想サーバの情報が表示されないことを注意してください。 
      nsxedge> show service loadbalancer table
-----------------------------------------------------------------------
L7 Loadbalancer Sticky Table Status:

TABLE    TYPE    SIZE(BYTE)   USED(BYTE)
  6. 必要なすべてのサービスが正しく実行されたら、ルーティング テーブルで、クライアント向けとサーバ向けのルートが必要であることを確認します。ルートをインターフェイスにマッピングする show ip route コマンドと show ip forwarding コマンドを使用します。
    Edge CLI コマンド show ip route および show ip forwarding の出力例。
  7. show arp コマンドを使用して、システム（ゲートウェイやネクスト ホップなど）およびバックエンド サーバの ARP エントリがあることを確認します。
    show arp コマンドの出力例。
  8. ログは、問題の診断につながる可能性のあるトラフィックを特定するのに役立つ情報を提供します。トラフィックの特定に役立つテール ログを作成するには、show log コマンドまたは show log follow コマンドを使用します。ロード バランサは、[ログ (Logging)] を有効にして [情報 (Info)] または [デバッグ (Debug)] を設定した状態で実行する必要があります。 
    nsxedge> show log
2016-04-20T20:15:36+00:00 vShieldEdge kernel: Initializing cgroup subsys cpuset
2016-04-20T20:15:36+00:00 vShieldEdge kernel: Initializing cgroup subsys cpu
2016-04-20T20:15:36+00:00 vShieldEdge kernel: Initializing cgroup subsys cpuacct
...
  9. クライアントへの正しいパスを指定した状態で、基本サービスが実行中であることを確認したら、アプリケーション層の状況を確認します。ロード バランサ エンジンのステータス (L4/L7) を確認するには、show service loadbalancer pool コマンドを使用します。コンテンツの提供に必要なプール メンバーは 1 つのみですが、通常は要求が単一ワークロードで対処できるキャパシティを超えるため、複数のメンバーが必要になります。組み込みの健全性チェックが健全性監視機能を提供する場合、健全性チェックに失敗すると、出力に ステータスの最終変更時間 と 失敗した理由が表示されます。監視サービスが健全性監視を備えている場合は、上述の 2 つの出力に加え、最終チェック時間 も表示されます。 
    nsxedge> show service loadbalancer pool
-----------------------------------------------------------------------
Loadbalancer Pool Statistics:

POOL Web-Tier-Pool-01
|  LB METHOD round-robin
|  LB PROTOCOL L7
|  Transparent disabled
|  SESSION (cur, max, total) = (0, 0, 0)
|  BYTES in = (0), out = (0)
   +->POOL MEMBER: Web-Tier-Pool-01/web-01a, STATUS: UP
   |  |  HEALTH MONITOR = BUILT-IN, default_https_monitor:L7OK
   |  |  |  LAST STATE CHANGE: 2016-05-16 07:02:00
   |  |  SESSION (cur, max, total) = (0, 0, 0)
   |  |  BYTES in = (0), out = (0)
   +->POOL MEMBER: Web-Tier-Pool-01/web-02a, STATUS: UP
   |  |  HEALTH MONITOR = BUILT-IN, default_https_monitor:L7OK
   |  |  |  LAST STATE CHANGE: 2016-05-16 07:02:01
   |  |  SESSION (cur, max, total) = (0, 0, 0)
   |  |  BYTES in = (0), out = (0)
  10. サービス モニターのステータス（OK、警告、重大）を確認し、構成済みのすべてのバックエンド サーバの健全性を確認します。 
    nsxedge> show service loadbalancer monitor
-----------------------------------------------------------------------
Loadbalancer Health Check Statistics:

MONITOR PROVIDER   POOL               MEMBER     HEALTH STATUS
built-in           Web-Tier-Pool-01   web-01a    default_https_monitor:L7OK
built-in           Web-Tier-Pool-01   web-02a    default_https_monitor:L7OK
    show service load balancer monitor コマンドの場合、CLI 出力に次の 3 種類の健全性監視の値が表示されます。
    • Built-in：健全性チェックは有効で、L7 エンジン (HA プロキシ) によって実行されます。
    • Monitor Service：健全性チェックは有効で、監視サービス エンジン (NAGIOS) によって実行されます。監視サービスの実行ステータスは、show service monitor と show service monitor service CLI コマンドで確認できます。[ステータス (Status)] フィールドには、OK、警告または重大が表示されます。
    • Not Defined：健全性チェックは無効です。
    このコマンドの出力で最後に表示される列は、プール メンバーの健全性ステータスです。次のステータスが表示されます。
    表 1. 健全性ステータスとその説明
    健全性ステータス 説明
    組み込み
    • UNK：不明
    • INI：初期化中
    • SOCKERR：ソケット エラー
    • L4OK：レイヤー 4 でチェックに合格（上位レイヤーのテストなし）
    • L4TOUT：レイヤー 1 ～ 4 のタイムアウト
    • L4CON：レイヤー 1 ～ 4 の接続の問題。たとえば、接続が拒否された (tcp rst)、ホストへのルートがない (icmp) など
    • L6OK：レイヤー 6 でチェックに合格
    • L6TOUT：レイヤー 6 (SSL) のタイムアウト
    • L6RSP：レイヤー 6 無効な応答 - プロトコル エラー。可能性のある原因：
      • バックエンド サーバが「SSLv3」または「TLSv1.0」のみをサポートしている、
      • バックエンド サーバの証明書が無効である、
      • 暗号のネゴシエーションに失敗した、など。
    • L7OK:：レイヤー 7 でチェックに合格
    • L7OKC：レイヤー 7 で条件付きでチェックに合格たとえば、「disable-on-404」を返す 404。
    • L7TOUT：レイヤー 7 (HTTP/SMTP) のタイムアウト
    • L7RSP：レイヤー 7 で無効な応答 - プロトコル エラー
    • L7STS：レイヤー 7 の応答エラー。たとえば、HTTP 5xx。
    重大
    • SSL プロトコル バージョン 2 が SSL ライブラリでサポートされていない
    • サポート対象外の SSL プロトコル バージョン
    • SSL コンテキストを作成できない
    • SSL 接続を確立できない
    • SSL ハンドシェイクを開始できない
    • サーバ証明書を取得できない
    • 証明書のサブジェクトを取得できない
    • 証明書の時刻形式が間違っている
    • 証明書「<cn>」が <証明書の期限> に期限切れ
    • 証明書「<cn>」が今日の <証明書の期限> に期限切れ
    警告/重大

    証明書「<cn>」が <証明書の残り日数/期限> で期限切れ

    ICMP
    • ネットワークに接続できない
    • ホストに接続できない
    • プロトコルに接続できない
    • ポートに接続できない
    • 送信元のルートに失敗した
    • 送信元のホストが隔離された
    • 不明なネットワーク
    • 不明なホスト
    • ネットワークが拒否された
    • ホストが拒否された
    • ネットワークのサービス タイプ (ToS) が不正
    • ホストのサービス タイプ (ToS) が不正
    • フィルタで禁止されている
    • ホストの優先順位の違反
    • 優先順位による遮断。処理に必要な最低限の優先順位
    • 無効なコード
    UDP/TCP
    • ソケットの作成に失敗
    • アドレス xxxx、ポート xxx に接続：[Linux エラー コードを参照]
    • ホストからデータを受信していない
    • ホスト/ソケットからの予期しない応答を受信
    HTTP/HTTPS
    • HTTP UNKNOWN：　メモリ割り当てエラー
    • HTTP CRITICAL：　TCP ソケットを開くことができない（ソケットの作成またはサーバへの接続に失敗）
    • HTTP CRITICAL：　データの受信中にエラーが発生
    • HTTP CRITICAL：　ホストから受信したデータがない
    • HTTP CRITICAL：　ホストから無効な HTTP 応答を受信：　<ステータス行>（ステータス行の形式が正しくない）
    • HTTP CRITICAL：　無効なステータス行 <ステータス行>（ステータス コードが 3 桁 XXX でない）
    • HTTP CRITICAL：　無効なステータス<ステータス行>（ステータス コード >= 600 または < 100）
    • HTTP CRITICAL：　文字列が見つからない
    • HTTP CRITICAL：　パターンが見つからない
    • HTTP WARNING：　ページ サイズ <page_length> が大きすぎる
    • HTTP WARNING：　ページ サイズ <page_length> が小さすぎる
  11. エラー コードが L4TOUT/L4CON の場合、通常は、基盤となるネットワークで接続の問題が発生しています。これらの問題の根本原因の多くは Duplicate IP です。このエラーが発生した場合は、次のようにトラブルシューティングを行ってください。
    1. 高可用性 (HA) が有効になっている場合は、Edge の高可用性ステータスを確認します。これは、両方の Edge で show service highavailability コマンドを使用することで行います。高可用性リンクが DOWN になっているかどうか、およびすべての Edge が Active かどうかを確認して、ネットワーク上で Edge IP アドレスが重複していないことを確認します。
    2. show arp コマンドを使用して Edge の ARP テーブルを確認し、バックエンド サーバの ARP エントリが 2 つの MAC アドレスの間で変更されていないかどうかを確認します。
    3. バックエンド サーバの ARP テーブルを確認するか、arp-ping コマンドを使用して、他のマシンが Edge IP アドレスと同じ IP アドレスを使用していないかどうかを確認します。
  12. ロード バランサ オブジェクトの統計情報（仮想 IP アドレス、プール、メンバー）を確認します。特定のプールに注目し、そのメンバーが実行中であることを確認します。透過モードが有効になっているかどうかを確認します。有効な場合、クライアントとサーバ間に　Edge Services Gateway を配置する必要があります。サーバがセッション カウンタの増分を示しているかどうかを確認します。 
    nsxedge> show service loadbalancer pool Web-Tier-VIP-01
TIMESTAMP            	SESSIONS   	BYTESIN    	BYTESOUT   	SESSIONRATE	HTTPREQS
2016-04-27 19:56:40  	00         	00         	00         	00         	00
2016-04-27 19:55:00  	00         	32         	100        	00         	00

    nsxedge> show service loadbalancer pool Web-Tier-VIP-01 | MEMBER
+—> POOL MEMBER: TENANT-1-TCP-POOL-80/SERVER-1, STATUS:  UP
+—> POOL MEMBER: TENANT-1-TCP-POOL-80/SERVER-2, STATUS:  UP
  13. 次に、仮想サーバにデフォルト プールがあるかどうかを確認し、そのプールもバインドされていることを確認します。アプリケーション ルールを介してプールを使用している場合は、#show service loadbalancer pool コマンドで表示される特定のプールに注意する必要があります。仮想サーバの名前を指定します。 
    nsxedge> show service loadbalancer virtual Web-Tier-VIP-01

-----------------------------------------------------------------------
Loadbalancer VirtualServer Statistics:

VIRTUAL Web-Tier-VIP-01
|  ADDRESS [172.16.10.10]:443
|  SESSION (cur, max, total) = (0, 0, 0)
|  RATE (cur, max, limit) = (0, 0, 0)
|  BYTES in = (0), out = (0)
   +->POOL Web-Tier-Pool-01
   |  LB METHOD round-robin
   |  LB PROTOCOL L7
   |  Transparent disabled
   |  SESSION (cur, max, total) = (0, 0, 0)
   |  BYTES in = (0), out = (0)
      +->POOL MEMBER: Web-Tier-Pool-01/web-01a, STATUS: UP
      |  |  HEALTH MONITOR = BUILT-IN, default_https_monitor:L7OK
      |  |  |  LAST STATE CHANGE: 2016-05-16 07:02:00
      |  |  SESSION (cur, max, total) = (0, 0, 0)
      |  |  BYTES in = (0), out = (0)
      +->POOL MEMBER: Web-Tier-Pool-01/web-02a, STATUS: UP
      |  |  HEALTH MONITOR = BUILT-IN, default_https_monitor:L7OK
      |  |  |  LAST STATE CHANGE: 2016-05-16 07:02:01
      |  |  SESSION (cur, max, total) = (0, 0, 0)
      |  |  BYTES in = (0), out = (0)
  14. すべてが正しく設定されているように見えてもまだエラーが発生する場合は、トラフィックをキャプチャして何が起きているかを理解する必要があります。クライアントから仮想サーバへの接続、および Edge Services Gateway からバックエンド プール（プール レベルの透過設定は有効または無効）への 2 種類の接続があります。#show ip forwarding コマンドで vNIC インターフェイスをリスト表示し、そのデータを使用します。
    たとえば、クライアント コンピュータが vNic_0 にあり、サーバが vNic_1 にあるとします。クライアント IP アドレスの 192.168.1.2 と、仮想 IP アドレスの 192.168.2.2（ポート 80 で実行）を使用します。ロード バランサのインターフェイス IP アドレスは 192.168.3.1、バックエンド サーバの IP アドレスは 192.168.3.3 です。パケット キャプチャ コマンドには、パケットを表示するコマンドと、パケットをダウンロード用にファイルにキャプチャするコマンドの 2 種類があります。パケットをキャプチャしてロード バランサの障害を検出します。パケットは次の 2 つの方向でキャプチャできます。
    • クライアントからのパケットをキャプチャする。
    • バックエンド サーバに送信されたパケットをキャプチャする。 
    #debug packet capture interface interface-name [filter using _ for space]- creates a packet capture file that you can download
#debug packet display interface interface-name [filter using _ for space]- outputs packet data to the console
#debug show files - to see a list of packet capture
#debug copy scp user@url:path file-name/all - to download the packet capture
    次はその例です。
    • vNIC_0 でキャプチャ：debug packet display interface vNic_0
    • すべてのインターフェイスでキャプチャ：debug packet display interface any
    • フィルタを指定して vNIC_0 でキャプチャ：debug packet display interface vNic_0 host_192.168.11.3_and_host_192.168.11.41
    • クライアントから仮想サーバへのトラフィックでのパケット キャプチャ：#debug packet display|capture interface vNic_0 host_192.168.1.2_and_host_192.168.2.2_and_port_80
    • Edge Services Gateway とサーバ間でのパケット キャプチャ（プールが透過モードの場合）：#debug packet display|capture interface vNic_1 host 192.168.1.2_and_host_192.168.3.3_and_port_80
    • Edge Services Gateway とサーバ間でのパケット キャプチャ（プールが透過モードでない場合）：#debug packet display|capture interface vNic_1 host 192.168.3.1_and_host_192.168.3.3_and_port_80