みなさんこんにちは。ヴイエムウェアの進藤です。
おかげさまで今日までに大変多くのお客様でNSXを導入していただいていますが、それに伴ってNSXをしっかりと運用していくための機能に関するリクエストをいただくことも多くなってきました。NSX 6.2は、このようないわゆる “Day 2 オペレーション” 機能にも力を入れたリリースになっています。今回はNSX 6.2で追加された新機能のうち、運用まわりやトラブルシューティングに関わる機能などをご紹介したいと思います。
集中管理CLIでNSX Managerから一括管理可能に!
NSXはNSX Manager、vCenter Server、NSXコントローラ クラスタ、分散論理ルータ制御VM、ハイパーバイザ、NSX Edge、などたくさんの要素から構成されています。万一、NSXが期待した動作をしていない場合には、これらの構成要素のいずれかにログインし、CLIを使って問題の切り分けを行いながら、必要があれば別の構成要素にログインをして問題箇所の特定をしていく必要があります。NSXには多くの構成要素があるため、一般的にはこのような切り分け作業は時間と手間のかかるものでした。
この問題に対処するため、NSX6.2では「集中管理CLI」機能が追加されました。この集中管理CLI機能を使えば、NSX Managerにログインするだけで、そこから他の構成要素に関する情報を取得することができます。この集中管理CLIは皆さんが普段から慣れ親しんでいるCLIインターフェースを踏襲しており、タブキーでの補完、?キーでの選択肢表示、ページング、ヒストリ機能などを備えていますので直感的にお使いいただけると思います。なお、現在この集中管理CLIでサポートされているのは「show系」コマンドのみとなっています。設定系のコマンドは使用できません。
それではこの集中管理CLIを使った例を見てみましょう。
1 2 3 4 5 6 7 |
nsxmgr-01a> <strong>show logical-switch list all</strong> NAME UUID VNI Trans Zone Name Trans Zone ID Transit-Network-01 7ad8bc71-5857-475c-af2a-a9e5337b0944 5000 Local-Transport-Zone-A vdnscope-1 Web-Tier-01 be6871fb-cefb-4488-9b16-3e77cf0a3482 5001 Local-Transport-Zone-A vdnscope-1 App-Tier-01 33fec704-41f5-4f58-b41d-65d78c2439b5 5002 Local-Transport-Zone-A vdnscope-1 DB-Tier-01 80e964af-5a77-4b18-a5aa-d479c1447b1b 5003 Local-Transport-Zone-A vdnscope-1 |
この例では論理スイッチの一覧を取得しています。
次に、コントローラが保持しているVXLAN Network Identifier (VNI) 5001の論理スイッチに関するVTEP、MACアドレス、ARPテーブルをそれぞれ確認してみましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
nsxmgr-01a> <strong>show logical-switch controller master vni 5001 vtep</strong> VNI IP Segment MAC Connection-ID 5001 192.168.130.51 192.168.130.0 00:50:56:6a:e8:3f 11 5001 192.168.130.52 192.168.130.0 00:50:56:60:2d:44 10 5001 192.168.120.52 192.168.120.0 00:50:56:60:47:af 12 masterControllerIp=192.168.110.32 nsxmgr-01a> <strong>show logical-switch controller master vni 5001 mac</strong> VNI MAC VTEP-IP Connection-ID 5001 00:50:56:ae:ab:9f 192.168.120.52 12 5001 00:50:56:ae:3e:3d 192.168.130.51 11 5001 00:50:56:ae:f8:6b 192.168.130.52 10 masterControllerIp=192.168.110.32 nsxmgr-01a> <strong>show logical-switch controller master vni 5001 arp</strong> VNI IP MAC Connection-ID 5001 172.16.10.12 00:50:56:ae:f8:6b 10 5001 172.16.10.10 00:50:56:ae:ab:9f 12 5001 172.16.10.11 00:50:56:ae:3e:3d 11 masterControllerIp=192.168.110.32 |
ここでコマンドラインに “master” と言うパラメータが指定されていることに注意ください。NSXのコントローラは通常3台のノードから構成されるクラスタで、VNI単位に処理が複数のコントローラノードに分散されるようになっています。特定のVNIがどのコントローラノードに割り当てられているか(どのコントローラノードがmasterになっているのか)を簡単に知る方法はないため、今まではコントローラノードに一台ずつログインして当該のVNI情報を保持しているかを確認する必要がありました。しかし、集中管理CLIのコントローラ関連コマンドではこのように “master” と言うキーワードを指定することで、指定したVNIに関するmasterコントローラノードに自動的に問い合わせてくれるようになっています。これはとても便利な機能です。
次はNSX Edge関係のCLIの例を見てみましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
nsxmgr-01a> <strong>show edge all</strong> NOTE: CLI commands for Edge ServiceGateway(ESG) start with 'show edge' CLI commands for Distributed Logical Router(DLR) Control VM start with 'show edge' CLI commands for Distributed Logical Router(DLR) start with 'show logical-router' Edges with version >= 6.2 support Central CLI and are listed here Legend: Edge Size: Compact - C, Large - L, X-Large - X, Quad-Large - Q Edge ID Name Size Version Status edge-2 Local-Distributed-Router C 6.2.0 GREEN edge-3 Perimeter-Gateway-01 C 6.2.0 GREEN edge-4 OneArm-LoadBalancer-01 C 6.2.0 GREEN edge-5 Perimeter-Gateway-02 C 6.2.0 GREEN edge-6 OneArm-LoadBalancer-02 C 6.2.0 GREEN nsxmgr-01a> <strong>show edge edge-3 ip route</strong> haIndex: 0 Codes: O - OSPF derived, i - IS-IS derived, B - BGP derived, C - connected, S - static, L1 - IS-IS level-1, L2 - IS-IS level-2, IA - OSPF inter area, E1 - OSPF external type 1, E2 - OSPF external type 2, N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 Total number of routes: 6 B 0.0.0.0/0 [20/0] via 192.168.100.1 O E2 172.16.10.0/24 [110/1] via 192.168.5.2 O E2 172.16.20.0/24 [110/1] via 192.168.5.2 O E2 172.16.30.0/24 [110/1] via 192.168.5.2 C 192.168.5.0/29 [0/0] via 192.168.5.1 C 192.168.100.0/24 [0/0] via 192.168.100.3 |
このように各々のNSX Edgeにログインすることなく指定したNSX Edgeの情報を取得できることがわかると思います。この例ではIP経路情報を取得しましたが、その他の情報を取ることもできます。例えば、以下はロードバランサの情報を取得している例です。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
nsxmgr-01a> <strong>show edge edge-4 service loadbalancer</strong> haIndex: 0 ----------------------------------------------------------------------- Loadbalancer Services Status: L7 Loadbalancer : running ----------------------------------------------------------------------- L7 Loadbalancer Status Information: STATUS PID MAX_MEM_MB MAX_SOCK MAX_CONN MAX_PIPE CUR_CONN CONN_RATE CONN_RATE_LIMIT MAX_CONN_RATE running 1490 0 2081 1024 0 0 0 0 0 ----------------------------------------------------------------------- L4 Loadbalancer Statistics: Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn |
ロードバランサ情報の他にもDHCP、DNS、冗長構成、IPsec、モニタ関連情報も取得できます。
NSX 6.2の集中管理CLIには、今回紹介した “show logical-switch”、”show edge” 以外にも
- show logical-router
- show dfw
- show dlb
- show vm
- show vnic
- show cluster
- show host
- show controller
などのコマンドがサポートされています。
トレースフロー機能でエンド〜エンド間のトラフィックパスを可視化
NSX 6.2で追加されたもう一つの大きな管理系機能に「トレースフロー機能」があります。この機能は、指定した2つの仮想マシン間のトラフィックパスを視覚的に表示し、パケットが正常に到達するか、到達しない場合はどこでパケットが落ちているのか、といった情報を知ることができる大変便利なものです。
トレースフローの使い方はとても簡単です。まず、トラフィックのタイプとして「ユニキャスト」、「L2マルチキャスト」、「L2ブロードキャスト」のいずれかを選択します。次に、「ソース」としてパケットの送信元となる仮想マシンのインターフェースを選びます。次に「ターゲット」(送信先)を指定しますが、ターゲットとしてMAC/IPアドレスをあらわに指定する方法と仮想マシンのインターフェースを指定する方法と2種類用意されています。
また、詳細オプションとして、タイムアウト時間、フレームサイズ、TTLやプロトコル(TCP、UDP、ICMP)、またそれぞれのプロトコルに固有のパラメータ(ポート番号、TCPフラグ、ICMP Echo ID/シーケンス番号、など)も指定することができます。
それではトレーフローを使った例を見てみましょう。以下は仮想マシン「web-01a」の仮想インターフェース「Network adapter 1」から仮想マシン「app-01a」の仮想インターフェース「Network adapter 1」にトレースフローした場合の実行例です。詳細オプションは指定していませんので、デフォルトでICMP Echoパケットが出ます。
トレース結果が「配信済み」となっていることから、パケットがソースの仮想マシンからターゲットの仮想マシンに無事届いたことが分かります。また、その下にパケットが経由したパスが表示されています。これを見ると分かる通り、パケットは仮想インターフェース(vNIC)、ファイアウォール、論理スイッチ(Web-Tier-01)、論理分散ルータ、論理スイッチ(App-Tier-01)、ハイパーバイザ、ファイアウォールを経由してターゲットの仮想インターフェース(vNIC)まで届いていることがわかります。
次にパケットがドロップされる例を見てみましょう。今度は仮想マシンweb-01aから別の仮想マシンweb-02aにトレースフローしてみます。今回の例では、Web用論理スイッチに接続された仮想マシン間のトラフィックはブロックするようなファイアウォールルールを適用していますので(いわゆる「マイクロセグメンテーション」を実現していることになります)、トレースフローでそのようなパケットを送信してもパケットはドロップされるはずです。
HTTPトラフィックを模擬するために、詳細オプションでTCPを指定し、接続先ポートに80番、TCPフラグとしてSYNを指定してみることにします。
今回はトレース結果が「ドロップ済み」になっていますので、トレースフローのパケットがターゲットまで届かなかったことがわかります。また、その下の画面を見ると、パケットがドロップした箇所はファイアウォールで、そのルールIDは1008であったこともわかります。このようにトレースフローを使えばどこでパケットが落ちているのか、また、その原因も一目瞭然です。
なお、トレースフロー機能は実際にパケットを仮想ネットワークに送り出して、そのパケットが通るパスを調べることによりトラフィックパスを表示するようになっていますが、仮想マシンに届く直前のところでトレーフフローのためのパケットは捨てられるようになっていますので、仮想マシン自身にトレースフロー用のパケットが届くことはありません(従って仮想マシンのインターフェースのカウンタが上がることもありません)。
トレースフロー機能はNSXのAPI経由で呼び出すこともできるので、他のツールとインテグレーションすることも可能です。
まとめ
今回はNSX 6.2で追加された運用・トラブルシューティング関連機能として集中管理CLIとトレースフローの機能を紹介しました。NSX 6.2には今回紹介した機能の他にも、NSX内部プロセスの通信状態監視や、IPFIX機能、syslog機能の改善など、多くの運用関連機能に関するエンハンスが盛り込まれています。
仮想ネットワークをたとえ導入したとしても、実際に運用できなければ結局宝の持ち腐れです。製品選定時には目先の機能に目を奪われがちですが、日々のオペレーションをまわしていくためには、今回ご紹介したような運用関連機能に目を向けることも大切です。
次回はNSX 6.2で実験的に実装された「分散論理ロードバランサー」機能についてご紹介をする予定です。ご期待ください!
Comments
0 Comments have been added so far