━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ケーススタディ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
VMware NSX の運用、トラブルシューティング
今回のテーマは VMware NSX for vSphere の運用とトラブルシューティングです。
VMware NSX for vSphere (NSX) は、スイッチ、ルータ、ファイアウォール、ロードバランサ、VPN などのネットワークコンポーネントを抽象化し、vSphere 環境においてネットワーク仮想化を実現します。ネットワーク仮想化環境では物理レイヤだけでなく仮想レイヤを考慮した運用やトラブルシューティングが有効なケースがあります。今回は NSX において最も基本的な機能でもある論理スイッチ (VXLAN) に関して、運用の基本とトラブルシューティングの簡単なテクニックをご紹介します。
なお、今回ご案内する機能やコマンドは NSX 6.3.5 および vSphere 6.5 を想定したものです。バージョンによっては一部の機能に差異がありますのでご注意ください。
1. 運用中のステータス確認
NSX では様々なコンポーネントの健全性を図1のように Networking & Security > ダッシュボードのページから確認することが可能です。NSX に関するトラブルの発生時には、運用の担当者が最初に確認するべき重要な情報が記載されています。今回は論理スイッチに関連するポイントをご紹介いたします。
図1の System Overview パネルで確認出来る Controller Nodes のステータスは、各 NSX コントローラの健全性ステータスを表しています。コントローラ上のサービスがダウンしたり、ネットワーク障害やディスクレイテンシ増加により制御プレーンに影響する恐れがある場合、このステータスが黄もしくは赤に変化します。
また Logical Switch Status パネルは論理スイッチの健全性ステータスを表しており、論理スイッチを構成する分散ポートグループが vCenter Server 上に存在しない場合などにエラーが表示されます。
さらに Host Preparation Status パネルでは、NSX クラスタとして構成されたホストのステータスを確認出来ます。NSX カーネルモジュールのインストールや、VTEP の構成に問題が発生した場合にエラーが表示されます。このパネルにエラーが表示された場合、図2のように Networking & Security > インストール手順 > ホストの準備タブから詳細を確認することができます。
図1. Networking & Security > ダッシュボード
図2の画面では、クラスタとホストの一覧から確認したいクラスタまたはホストを選択し、操作 > 通信チャネルの健全性を選択することで、さらに図3のようにホスト上のサービスの健全性を個別に確認することが可能です。この結果から障害が発生したコンポーネントの特定や復旧に繋がるアクションを明確にすることが出来るため、通信チャネルの健全性のチェックはトラブルシューティングの定石となっています。
図2. Networking & Security > インストール手順 > ホストの準備
NSX Manager から制御プレーンエージェントが切断になっている場合は、ホスト上の制御プレーンエージェントが正常に動作していない可能性があります。復旧策として制御プレーンエージェントの再起動やホストの再起動が有効です。
また NSX Manager から制御プレーンエージェントが接続中になっているが制御プレーンエージェントからコントローラが不明になっている場合は、コントローラのステータスや物理ネットワークに問題が発生している可能性があります。復旧策としてコントローラ上のサービス再起動やコントローラの再デプロイが有効なことがあります。
図3. 通信チャネルの健全性
更なる詳細な切り分け手順や制御プレーンエージェントの再起動などの具体的なコマンドについては、以下のドキュメントをご参照ください。
NSX トラブルシューティング ガイド
NSX Controller クラスタの障害
制御プレーン エージェント (netcpa) の問題
2. トラブルシューティングのテクニック
パケットキャプチャ
ネットワークのトラブルシューティングとして一般的なパケットキャプチャですが、VXLAN を利用している場合は注意が必要です。ここではNSX 環境における基本的なパケット処理の流れと共に、 ESXi 上でのパケットキャプチャの採取手順をご紹介します。
仮想マシン上で送信されたパケットは、 ESXi 上では対応する仮想 NIC から送信されたパケットとして処理されます。 VXLAN に接続された仮想 NIC であれば、このパケットは ESXi のカーネルにおいて VXLAN パケットとしてカプセル化され、物理ネットワーク上では UDP パケットとして処理されます。図4は同じ VXLAN に接続されている異なるホスト上の仮想マシンについて、このパケット処理の流れを示したものです。
図4. NSX 環境における ESXi 上の VXLAN パケット処理のイメージ
VXLAN 環境でのトラブルシューティングにおいては、上記の一連の処理の中でどこに問題が発生しているかを切り分けるためにパケットキャプチャが有効なことがあります。例えば VXLAN パケットとしてカプセル化された後のパケットをキャプチャすることで、仮想ネットワークあるいは物理ネットワークのどちらで問題が発生しているのか明確に切り分けることが可能です。このように VXLAN カプセル化など特定の処理が行われる直前/直後のパケットを採取する場合は、 pktcap-uw コマンドのオプションでキャプチャポイント等を指定する必要があります。
VXLAN に接続された仮想 NIC から送信された直後のパケットをキャプチャする場合は、対応する分散スイッチのスイッチポートと共にキャプチャポイントとして VnicTx を指定します。また仮想 NIC で受信する直前のパケットをキャプチャする場合は、 VnicRx を指定します。これらのオプションで指定したキャプチャポイントはそれぞれ図4中の1, 6に相当します。このキャプチャポイントでは仮想マシン内で発生した問題を切り分けるために有効です。
また VXLAN でカプセル化される前後のパケットを比較することで、論理スイッチと物理ネットワークの問題を切り分けることが可能です。VXLAN パケットでカプセル化されていない場合や、VXLAN パケットの宛先や VNI が間違っている場合は論理スイッチに問題が発生している可能性があります。
VXLAN でカプセル化される前のパケットをキャプチャしたい場合は、対応するアップリンクと共にトラフィック方向のオプションを利用します。これらのオプションで指定したキャプチャポイントはそれぞれ図4中の2, 5に相当し、VXLAN カプセル化前/カプセル化解除後のパケットをキャプチャします。
ESXi の物理 NIC から送信される VXLAN パケットをキャプチャする場合は、対応するアップリンクと共にキャプチャポイントとして UplinkSndKernel を指定します。また物理 NIC で受信した VXLAN パケットをキャプチャする場合は、キャプチャポイントとして UplinkRcvKernel を指定します。このオプションで指定したキャプチャポイントはそれぞれ図4中の3, 4に相当し、VXLAN パケットをキャプチャします。
pktcap-uw コマンドの更なる詳細については、以下のドキュメントをご参照ください。
vSphere ネットワークについて
物理アダプタに達するパケットのキャプチャ
pktcap-uw ユーティリティのポイントのキャプチャ
ネットワークの疎通確認
NSX 環境でネットワークにトラブルが発生した場合、障害が発生したレイヤに応じた切り分けを行うことが重要です。ここでは論理スイッチ上の仮想マシンのネットワーク接続性を確認するテクニックをご紹介します。
A) 同じホスト上の仮想マシン間のネットワーク接続性
ある論理スイッチに接続した2つの仮想マシンを同じホスト上に配置した状態で、仮想マシン間の ping 疎通を確認します。同じホスト上に配置しても疎通がない場合、論理スイッチではなく分散スイッチや仮想マシン内において問題が発生している可能性があります。
B) 異なるホスト上の仮想マシン間のネットワーク接続性
ある論理スイッチに接続した2つの仮想マシンを異なるホスト上に配置した状態で、仮想マシン間の ping 疎通を確認します。同じホスト上に配置したときは疎通があるものの異なるホスト上に配置すると疎通が失われる場合、 MTU やマルチキャストグループ、 ESXi の物理 NIC などホスト間の物理ネットワークに起因して論理スイッチに問題が発生している可能性があります。
C) 仮想マシンがホストを移動した場合のネットワーク接続性
ある論理スイッチに接続した2つの仮想マシンの一方を別のホストへ vMotion したとき、仮想マシン間の ping 疎通が維持されるか確認します。 vMotion の前は疎通があるものの vMotion の後で疎通が失われる場合、制御プレーンに障害が発生しデータプレーンの制御が失われているため論理スイッチに問題が発生している可能性があります。
3. CDOモードの利用
NSX 6.3.2 以降では CDO (Controller Disconnected Operation) モードが追加されました。CDO モードが有効なトランスポートゾーンでは、一時的にホストとコントローラの接続が失われた状態でもデータプレーンが正常に動作するため、運用への影響を軽減することが可能です。
CDO モードの詳細については、以下のドキュメントをご参照ください。
Controller Disconnected Operation (CDO) モード
4. 運用上の推奨
NSX 環境の運用では、トラブルに備え NSX マネージャの定期的なバックアップの取得を強く推奨いたします。NSX における全てのコンポーネントの設定内容はNSX マネージャ上に保持されているため、NSX マネージャをリストアした後コンポーネント毎に同期をとることでシステム全体のリストアが可能です。
バックアップの詳細については、以下のドキュメントをご参照ください。
NSX Manager データのバックアップ
重要なシステムでは事前に切り分け手順を確立しておくことが重要になります。 NSX の障害として対応したものの、実際には物理レイヤやアプリケーションレイヤで問題が発生していたというケースも少なくありません。事前に切り分け手順を確立しておくことで、復旧までの時間を短縮しトラブルの影響を最小限に抑えることが可能です。その際には、今回ご紹介した内容をご参照頂ければ幸いです。
|
