VMware NSX トラブルシューティングまとめ

VMware

VMware NSX トラブルシューティングまとめ

はじめに(免責事項)

本記事の目的は、本記事作成時点ではVMware NSX for vSphere向けのトラブルシューティング関連情報のまとめを目的としております。レアケースを始めとした、特定環境に依存する情報ではなく、汎用的に使えるテクニックや知識を集約するページとして活用いただくことを目的とします。また、トラブルの解消を約束するものではないことも合わせてご理解の上本ページをご活用ください。

本記事内での画面キャプチャはVMware Hands on LABからの抜粋となります。
一部のツールは、本記事投稿段階にてvSphere Web Client限定での提供のものが存在します。
最新の情報確認に付きましては、以下のページを参照ください。
VMware NSX for vSphere の機能の更新 – vSphere Client のユーザー インターフェイス プラグイン

なお、将来的にはVMware NSX-Tの情報掲示も含めていく予定です。

トラブルシュート開始時点で行うべき確認

vSphereやvSANと比べ、VMware NSXは特定のサービスを利用するために、複数のアプライアンスを使い分けます。そのため、トラブルシュートのアプローチがこれらの製品とは大きく異なります。

これを踏まえ、トラブルシュートを行うためには、次の点を確認しておくことを強くオススメします。

一般的なヒアリング情報

  • 発生している問題(エラーメッセージなのか、特定のトラフィックが通らないなど、具体的なもの)
  • 問題発生日時(ログ分析時に、発生時刻を確認するため)
  • トラフィックの影響を受けている仮想マシンの台数や影響範囲の特定
  • 再現性の有無、ワークアラウンド
    • 例:vMotionでホスト間移動をするとトラフィックが解消する
  • 問題発生きっかけとして考えうる操作
    • 例:ファイアウォールのルール変更後から特定のトラフィックが通らない
  • 新規構築中の環境であるか、稼働実績が一定期間あるか

NSX固有のヒアリング情報

  • VMware NSXのバージョン(バージョン毎に使える機能が増減します)
  • VMware NSX Managerのバックアップ取得の有無(リストア可否の確認)
  • 利用しているNSXの機能(機能毎に登場する仮想マシンやモジュールが異なります)
  • 展開しているNSXの仮想アプライアンスの種類と台数及び稼働状況(例:NSX Manager 1台/NSX Controller Cluster ノード 3台/分散論理ルーター 1台、すべて正常に稼働している)
  • VMware NSXと連携するソフトウェアの利用有無

もちろんトラブルの種類やこれらの情報から更に追加の情報が必要となる場合もありえます。

仮想マシンベースのルーターが物理ルーターとピアリングをしているような場合は、物理ルーター側のサポートなどを受けなければ行けないケースもあります。この点についてはお客様サイドで必要に応じて問い合わせください。

VMware 公式情報(随時更新)

VMware DocsやKBを中心に、豊富な情報が提供されています。

ページタイトル リンク
Troubleshooting VMware NSX for vSphere 6.x (2122691) Link
NSX トラブルシューティング ガイド Link
VMware Support Insider – Top 20 KBs Link
VMware Network Virtualization Blogs Link
VMware NSX Channe – YouTube Link
VMware NSX for vSphere Network Virtualization Design Guide Link
   
   
   

NSX Managerの障害影響と対策

NSX Managerの停止や接続性のロストは、即座にトラフィック停止にはなりません。この点については分散スイッチを展開している環境で、vCenter Serverが停止しても即座に影響が出ないことと同じです。しかしながら、NSX Manager停止中はNSX環境の監視不可や構成変更などが出来ません。

私個人としての強い思いもありますが、必ずNSX Managerのバックアップを取得するようにしましょう。

VMware Docs – NSX Managerのバックアップとリストア
Backup and restore of VMware NSX for vSphere 6.x components (2144087)

VMware NSXの環境では、いくつかのNSX用仮想アプライアンスを利用しますが、これらの構成情報も、NSX Managerのバックアップに含まれます。

つまり、NSX Managerを失う=NSX環境の再構築を意味します。これは大変クリティカルです。

一方で、例えば次のような仮想マシンは個別にバックアップを取る必要はありません。
NSX Controller クラスターノード / 分散論理ルーターコントロール仮想マシン / Edge Service Gateway / ゲストイントロスペクション仮想マシン
これら自体は仮想マシンのトラフィック制御を行う、またはそのためのテーブル情報を保持することが目的です。

VMware側の技術ソースにはっきりした記述はありませんが、技術的な面から考えると、例えばこれらの仮想マシンをイメージバックアップやスナップショットから復元してしまうと、古いテーブル情報がリストアされてしまい、結果的にネットワークの接続不可などを発生させる可能性が想定されます。

NSX Controller クラスターノードの障害影響と対策

NSX Controllerは、OSI参照モデルで言う所の第2層と第3層の接続性に対して、制御層を提供します。

特にわかりやすい点で言えば、MACテーブル、ARPテーブル、ルーティングテーブルに代表されるようなテーブル情報の保持と配信を行う仮想マシン群です。

これらの仮想マシンの喪失=テーブル情報の欠損となりますから、当然のことながらNSX環境でのネットワーク通信問題が発生することが予想されます。VMware NSX では、こうしたトラブルに対応すべくテーブルの管理を3台の仮想マシンで持ち合いとしており、1台のクラスターノード障害では障害が自動収束するようになっています。

仮想マシンの役割がテーブル情報の管理ですので、本仮想マシンはバックアップやリストアを必要としません。(理由は、バックアップから復元をしてしまうと古いテーブル情報が復元されてしまうため)

以上のこともあり、VMware Docs内でも、当該仮想マシンの起動障害の場合にはバックアップからの復元ではなく、再デプロイを行うよう次のナレッジに記述があります。

VMware Docs – NSX Controller クラスタの障害

VMware Docs – NSX Controller の再デプロイ

なお、クラスターノードの再デプロイの際には、障害発生したクラスターノードの削除が必要となります。
原因追求を含んでトラブルシュートを行う場合は、クラスターノードのログ取得を行うことをオススメします。

VMware Docs – NSX Controllerのテクニカルサポート ログのダウンロード

なお、クラスターノードのログ取得の条件としては、取得対象のクラスターノード仮想マシンが起動出来ている必要があります。下図では、疑似障害としてController クラスターノードの電源を停止した状態でログを取得した結果、ファイルサイズが0KBのログが生成されました。

つまり、そもそもNSX Controller クラスターノードが正常に起動していない状況においてのログ取得は、有効な情報が取れない可能性があります。これを防ぐためにはクラスターノードにSyslog設定をしておく必要があります。

VMware Docs – NSX ControllerクラスタのDNS、NTP、Syslogの設定

NSX Edgeの障害影響と対策(Edge Service Gateway仮想マシン及び分散論理ルーター制御仮想マシン)

NSX Edgeとは、通常2種類の機能のどちらかのために展開されます。1つ目の用途は分散論理ルーター制御仮想マシンとして、2つ目の用途はNSX Edge Service Gatewayとしてです。

これらの仮想マシンは、次のような機能を提供します。(一部紹介)

  • ルーティング(North-South及びEast-West方向通信向け)
  • ファイアウォール
  • ロードバランサー
  • VPN

特に後者のEdge Service Gatewaは、それ自身がIOパスを提供するため、本仮想マシンの停止は直接的にIOの停止に至ります。(サービス提供停止などにいたり、大変クリティカルです)

復旧優先の際は、NSX Controller クラスターノードと同様に仮想マシンの再展開という方法があります。それ以外に強制同期という方法もあり、この方法であれば既存のNSX Edgeに対して構成情報を強制プッシュすることが可能です。

VMware Docs – NSX Edge と NSX Manager の強制同期

VMware Docs – NSX Edgeの再デプロイ

強制同期の場合は上記のページ内にも記述がありますが、一部のトラフィックを除き無停止でこの作業を行えます。

一方で強制同期で改善が見込めない場合は、再デプロイにて新規の仮想マシンを構成し直します。

NSX Controller クラスターノードと同様に、問題の原因追求を行うためのログ取得はNSX Edge仮想マシン単位で可能です。

VMware Docs – NSX Edge のテクニカル サポート ログのダウンロード

本仮想マシンについても、ログ取得の時点で仮想マシン自体が正常に動作している必要があります。

障害の際にもログ取得が必要だという場合については、Syslogの設定が必要です。

VMware Docs – NSX Edge の Syslog サーバの設定

トラブルシュートに活用出来るツール、手法

  1. フローモニタリング(NSX 6.2以降/一部vSphere Web Client限定)
    VMware Docs – フローモニタリング
    NSX環境上での仮想マシン間のトラフィック詳細確認には、本機能が利用可能です。
    下図”Dashboard”では、トラフィックの送信量が多い仮想マシンを、多い順から表示しています。
    (子タブを利用すれば、送信元、送信先、サービスのカテゴリでフィルターを変更可能です)

    ”Details By Service”では、プロトコルの種別ごとに送受信仮想マシンや日時、本画面からファイアウォールの構成が可能です。

    “Live Flow”では、特定の仮想マシンのvNICを選択することで、そこで行われる通信を一定間隔でモニターする機能です。仮想マシンの外からWiresharkでキャプチャをしているイメージです。

    本ツールの特徴は、Wiresharkのようなトラフィックキャプチャツールと違い、キャプチャ+分析を終えた、その結果が表示されているという点です。
    これにより、これまでですと”Wiresharkのインストール”、”どこでキャプチャを行うか”などから考えなくてはならなかった所が、常時キャプチャと分析がなされるため、よりスピーディーにトラフィック傾向を掴めると言えます。

    なお、キャプチャを行う上では、監視対象の仮想マシンをホストするESXi内部の”vsfwd”が動作している必要があります。(下図では、vsfwdを停止した際にキャプチャが停止した様子です)


  2. Comming soon
  3. Comming soon
  4. Comming soon
  5. Comming soon
  6. Comming soon

コメント