Home > Blogs > Japan Cloud Infrastructure Blog > 作成者別アーカイブ: Tomohiro Iwafuchi

作成者別アーカイブ: Tomohiro Iwafuchi

ネットワーク仮想化をネットワークの基本から理解する 〜第4回:分散ファイアウォール -Layer4 の世界

「ネットワーク仮想化」をセールスやマーケティングではなく、エンジニアとしてアーキテクチャを正しく理解することが、今回のブログシリーズ「ネットワーク仮想化をネットワークの基本から理解する」のテーマです。最終回「第4回:分散ファイアウォール -Layer4 の世界」では、ネットワーク仮想化環境でのセキュリティを見ていきます。

■ 目次
・はじめに
・物理ネットワーク環境におけるセキュリティ
・ネットワーク仮想化環境におけるセキュリティ
・物理ネットワーク環境とネットワーク仮想化環境の比較
・補足情報

 

■ はじめに
仮想化環境でのセキュリティを検討するとき、適用するポイントには、仮想マシン、ハイパーバイザ、物理ネットワークと3つのポイントが考えられます。この中で管理性とセキュリティの粒度を考えたとき、最も適したポイントはどこになるでしょうか。

NWV04-01

図:セキュリティを適用するポイント

一般的に、よりサービスに近い方が粒度の細かいセキュリティポリシーの適用が可能になります。仮想マシンは最もサービスに近いポイントとなりますが、個々の仮想マシンにセキュリティを適用していくのは運用管理上のオーバヘッドが大きいことに加え、ゲストOSが乗っ取られた場合はセキュリティ機能そのものを停止されてしまう可能性があります。

一方で物理ネットワークではどうでしょうか。物理ネットワークでのセキュリティは、L2 のネットワークセグメント境界を通るトラフィックにかけることになります。この方式では、セキュリティの適用ポイントが仮想マシンから離れることで、同一L2 ネットワークセグメント内における仮想マシン間の通信制御は困難です。

パイパーバイザでセキュリティを適用することで、従来のL2 ネットワークセグメント境界にとらわれない柔軟なセキュリティの実装が可能になります。しかしながら個々のハイパーバイザにセキュリティを適用することで運用管理上のオーバヘッドが大きくなってしまっては意味がありません。

VMware NSX の提供する分散ファイアウォール(FW)は、ハイパーバイザ上でセキュリティを提供します。分散FW の設定はNSX Manager から行うことができます。従来のFW と同じように送信元、宛先、サービスと、アクションを指定することができます。各項目は、vCenter のオブジェクト単位(仮想マシン、クラスタ、リソースプール等)で指定することが可能で、従来のIPアドレス単位の管理と比べた際に運用管理の負担を大きく軽減することができます。

NWV04-02

図:分散FW の設定

また、GUIからだけではなくAPIを介した設定が可能となり、クラウドマネジメントプラットフォームと連携させることで設定作業そのものの自動化が可能になります。例えば、仮想マシンを展開すると同時にセキュリティポリシーを適用するといった運用が可能になります。

分散FW は、第2回の論理スイッチ(VXLAN)、第3回の分散ルーティングと同様にハイパーバイザを活用することで、仮想化環境に最適なセキュリティを提供します。前回と同様に、物理の世界との比較を「テーブル」の観点から見ていきたいと思います。

 

■ 物理ネットワーク環境におけるセキュリティ
物理ネットワーク環境でのセキュリティは、FW やL3スイッチ(ルータ) といった物理ネットワーク機器に実装します。FW は外部ネットワークとの境界に設置され、フィルタリングのルールを記載したフィルタリングテーブルを持っています。また、L3スイッチやルータの セキュリティ機能として、ACL(Access Control List)があります。

NWV04-03

図:物理ネットワーク環境におけるセキュリティ

L3スイッチでは、専用のコマンドラインからACL の設定を行い、設定の確認もコマンドラインから実施します。例えばL3スイッチのACL を確認するには、以下のコマンドを実施します。

# show access-list
 permit ip	host “送信元IPアドレス”	host “宛先IPアドレス”
 permit tcp	host “送信元IPアドレス”	host “宛先IPアドレス”	eq “ポート番号”
 permit udp	host “送信元IPアドレス”	“宛先ネットワークアドレス”	eq “ポート番号”
 permit icmp 	any any

出力から送信元、送信先のアドレス、及びプロトコルタイプを指定したテーブルを確認できます。このフィルタリングテーブルにより、L3 スイッチを経由するトラフィックに対してセキュリティをかけることが可能になります。ACL はステート情報を管理しない、ステートレスなセキュリティ機能となるため、フィルタリング情報は双方向の通信に対して明記します。

一方、FW の提供するステートフルなセキュリティ機能では、フィルタリングテーブルとは別に、通信のフロー情報を管理するためのステートテーブルを持ちます。通信が発生した際にステートテーブルがダイナミックに作成されます。

例えばTCP ステートテーブルでは、送信元IPアドレス、ポート番号、宛先IPアドレス、ポート番号、TCPステート情報、タイムアウト値等が含まれます。この情報を基に、対応する戻り方向の通信を自動的に許可し、適合しない不正な通信をブロックすることができます。

フィルタリング及びステート管理の考え方 はネットワーク仮想化環境になっても変わりませんが、ネットワーク仮想化環境では物理ネットワーク機器の持つセキュリティ機能を、分散FW としてハイパーバイザに実装することができます。分散FW のアーキテクチャについて、「テーブル」に注目する形でこの後見ていきます。

 

■ ネットワーク仮想化環境におけるセキュリティ
分散FW は、L2 – L4レベルのステートフルなFW 機能をハイパーバイザで提供します。個々のハイパーバイザ内でセキュリティ機能を提供することで、処理を分散して行うことのできるスケールアウト型のアーキテクチャになります。

NWV04-04

図:ネットワーク仮想化環境におけるセキュリティ

分散FW も、従来の物理環境のセキュリティ製品と同様に内部にフィルタリングテーブル(ルールテーブル)を持っています。フィルタは、仮想マシンの仮想NICとハイパーバイザの間にあるdvfilterと呼ばれるポイントに適用されます。これにより、L2 ネットワーク境界にとらわれない粒度の細かいセキュリティの実装(マイクロセグメンテーション)が可能になります。

NWV04-05

図:セキュリティを適用するポイント

ハイパーバイザ上で、dvfilterに適用されているフィルタリングテーブルを確認することが出来ます。ESXi ホストにログインし、仮想マシン(web-sv-01a)に適用されているフィルタリング情報を確認します。

# summarize-dvfilter

# summarize-dvfilter
world 145244 vmm0:web-sv-01a vcUuid:'50 26 c7 cd b6 f3 f4 bc-e5 33 3d 4b 25 5c 62 77'
 port 50331662 web-sv-01a.eth0
  vNic slot 2
   name: nic-145244-eth0-vmware-sfw.2
   agentName: vmware-sfw
   state: IOChain Attached
   vmState: Detached
   failurePolicy: failClosed
   slowPathID: none
   filter source: Dynamic Filter Creation
  vNic slot 1
   name: nic-145244-eth0-dvfilter-generic-vmware-swsec.1
   agentName: dvfilter-generic-vmware-swsec
   state: IOChain Attached
   vmState: Detached
   failurePolicy: failClosed
   slowPathID: none
   filter source: Alternate Opaque Channel

上記出力から、仮想マシン(web-sv-01a)に対応したフィルタ(nic-145244-eth0-vmware-sfw.2)を確認し、仮想マシンに適用されているフィルタリングテーブル(ルールテーブル)を下記コマンドで確認します。

# vsipioctl getrules -f フィルタ名

# vsipioctl getrules -f nic-145244-eth0-vmware-sfw.2
ruleset domain-c25 {
  # Filter rules
  rule 1006 at 1 inout protocol tcp from addrset ip-vm-33 to addrset ip-vm-36 port 22 accept with log;
  rule 1005 at 2 inout protocol any from any to addrset ip-ipset-2 accept;
  rule 1004 at 3 inout protocol ipv6-icmp icmptype 135 from any to any accept;
  rule 1004 at 4 inout protocol ipv6-icmp icmptype 136 from any to any accept;
  rule 1003 at 5 inout protocol udp from any to any port 67 accept;
  rule 1003 at 6 inout protocol udp from any to any port 68 accept;
  rule 1002 at 7 inout protocol any from any to any reject with log;
}

ruleset domain-c25_L2 {
  # Filter rules
  rule 1001 at 1 inout ethertype any from any to any accept;
}

分散FW は、vCenter のオブジェクト単位(仮想マシン、クラスタ、リソースプール等)で設定することができます。オブジェクトに含まれる仮想マシンは、仮想マシンにインストールされたVMware Tools によりIP アドレスに変換して適用されます。オブジェクトとIPアドレスの対応は下記で確認ができます。なお、オブジェクト名(ip-vm-33 等)はvCenter のMoRef(Managed Object Reference)に対応しています。

# vsipioctl getaddrsets -f フィルタ名

# vsipioctl getaddrsets -f nic-145244-eth0-vmware-sfw.2
addrset ip-ipset-2 {
ip 192.168.110.10,
}
addrset ip-vm-33 {
ip 172.16.10.12,
}
addrset ip-vm-36 {
ip 172.16.10.11,
}

また、分散FW はフロー情報を管理するステートフルなファイアウォール機能を提供します。ステート情報は、ステートテーブル(コネクショントラッカーテーブル)で管理されています。コネクショントラッカーテーブルを表示させる際はFlow Monitoring を有効にします。下記の例では、SSHを許可するルールに対応したステート情報が管理されていることが分かります。

# vsipioctl getflows -f フィルタ名

# vsipioctl getflows -f nic-145244-eth0-vmware-sfw.2
Count retrieved from kernel active(L3,L4)=3, active(L2)+inactive(L3,L4)=0, drop(L2,L3,L4)=0
558a796d00000000 Active tcp 0800 1 1006 0 0  172.16.10.12:Unknown(44194) 172.16.10.11:ssh(22) 2413 EST 3017 2957 19 18

テーブル情報は、仮想マシンがvMotion で異なるESXi ホスト上に移動した際も仮想マシンに追従して適用されます。これによりvMotion 後もサービスを継続することが可能です。

 

■ 物理ネットワーク環境とネットワーク仮想化環境の比較
物理ネットワーク環境では、フィルタリングテーブルは物理ネットワーク機器が持ち、単一のポイントでフィルタリングの処理を実施します(集中処理)。また、複数のポイントでセキュリティを適用するような構成では、個々の物理ネットワーク機器に対して設定作業を行うことになります(分散管理)。

NWV04-06

図: 物理ネットワーク環境とネットワーク仮想化環境の比較

分散FW は仮想化環境のセキュリティを、適切なポイントで、運用管理性を損なわずに実現しています。各テーブルの情報を確認してみると、従来の物理ネットワーク環境で物理ネットワーク機器が持っているのと同等の情報をハイパーバイザの中で管理していることが分かります。


ポイント1 ハイパーバイザでテーブル情報を持つことで、ネットワークセグメント境界にとらわれない粒度の細かいセキュリティを実装できる(マイクロセグメンテーションの実装)

また、サーバが増えるのに比例して処理するポイントも増えるスケールアウト型のアーキテクチャになります。


ポイント2 ホストの増加に比例して処理するポイントが増える、拡張性のあるスケールアウト型のアーキテクチャを取ることができる(データプレーンにおける分散処理)

分散FW 環境のセットアップは、NSX Manager を介して、GUI もしくはAPI 経由で簡単に行うことが出来ます。


ポイント3 NSX Manager から一括して設定管理を行うことで、運用管理性を損なうことなく容易に実装できる(マネジメントプレーンにおける集中管理)

ネットワーク仮想化環境における分散FW は、分散処理、集中管理のアプローチをとることで、運用管理性を維持しつつ、ネットワークセグメント境界にとらわれない粒度の細かいセキュリティ(マイクロセグメンテーション)を実装することを可能にしています。

ネットワークサービスは、トラフィックのフローと、フローを制御する「テーブル」から成り立ちます。この「テーブル」にフォーカスして見ていくと、物理ネットワーク環境で管理していたテーブルと同じ情報が、ネットワーク仮想化環境では異なるレイヤー(ハイパーバイザ)で管理されていることが分かります。ハイパーバイザを活用するアプローチは、今までの物理ネットワーク環境でユーザが得られなかった利便性を提供することを可能にします。

シリーズを通して、「ネットワーク仮想化」は既存のテクノロジーと断絶したものではなく、従来の仮想化及びネットワークテクノロジーの延長線上にあることを説明してきました。「ネットワークエンジニア」も「仮想化エンジニア」も、それぞれのバックグラウンドを活かしつつ、「ネットワーク仮想化」を通して新しい分野のスキルを身につけることができます。従来の役割分担にとらわれない、新しい世界に入る一つのきっかけとして本シリーズを活用いただけますと幸いです。

 

■ 補足情報 分散FW を提供するVMware NSX のコンポーネント

分散FW 環境で、NSX を構成する各コンポーネントがどういった役割を果たしているのか解説を行います。

NWV04-07

・NSX Manager(マネジメントプレーン)
NSX を構築する際に最初に展開するコンポーネントで、仮想アプライアンスとして提供されています。NSX Manager は初期構築時に ESXi ホストへのカーネルモジュールのインストールを担います。また、NSX Manager はAPI のエントリポイントとなり、GUI だけでなくAPI 経由でNSX 環境の設定を可能にします。

・NSX コントローラクラスタ(コントロールプレーン)
NSX コントローラクラスタは分散FW に関与しません。分散FW はコントロールプレーンのコンポーネントを使用しません。

・論理ルータコントロールVM(コントロールプレーン)
論理ルータコントロールVM は分散FW に関与しません。分散FW はコントロールプレーンのコンポーネントを使用しません。

・ハイパーバイザ カーネルモジュール(データプレーン)
NSX 環境を構築する際、ホストの準備のステップで各ESXi にインストールされるカーネルモジュールとなります。VIB(vSphere Installation Bundle)ファイルとしてインストールされ、分散FW ではカーネルモジュール(vsip)としてロードされます。カーネルモジュールは、ハイパーバイザ内で分散FW のテーブルの管理とフィルタリング処理を行います。

NWV04-08

ハイパーバイザからは、NSX Manager にコネクションを張り、NSX Manager からフィルタリングテーブル(ルールテーブル)を受け取ります。 NSX Manager へのコネクションはUWA vsfwd(TCP/5671)を介して確立します。

# esxcli network ip connection list | grep 5671
Proto	Local Address		Foreign Address		State		World Name
-----	--------------------	--------------------	-----------	----------
tcp	192.168.210.51:23251	192.168.110.42:5671	ESTABLISHED	vsfwd

上記出力より、ESXi ホストの管理用IP アドレスからNSX Manager に、vsfwd を介して接続していることが確認できます。NSX Manager からは分散FW の設定情報(ルールテーブル)を取得します。

ルールテーブルは、仮想マシンがvMotion で異なるESXi ホスト上に移動した際も仮想マシンに追従して適用されます。これによりvMotion 後もサービスを継続することが可能です。


補足情報:NSX 6.1.2 以前のバージョンで、vMotion 実行後にコネクションが切断される事象が報告されています。オンラインのハンズオン環境(バージョン6.1.1)で動作確認される場合この不具合が該当します。詳細は下記KBを参照ください。

Performing VMware vMotion migration when using VMware NSX for VMware vSphere 6.1.2 and earlier Distributed Firewall causes virtual machines to lose network connectivity for 30 seconds (2096529)

・NSX Edge(データプレーン)
仮想アプライアンスとして提供され、単体で各種ネットワークサービス機能(ロードバランサ、ルーティング、NAT、ファイアウォール、VPN、 DHCP 等)を提供する「スイスのアーミーナイフ」のようなコンポーネントです。従来の物理のネットワーク機器が仮想アプライアンスとして置き換わったイメージです。分散FW 機能には関与せず、アプライアンス単体でFW 機能を提供します。

 

■関連リンク
今回ご紹介した内容をオンラインのハンズオン環境上で確認することができます。コマンドラインの出力はハンズオン環境をベースに作成しています。
http://labs.hol.vmware.com/HOL/
VMware HOL Online
HOL-SDC-1403 – VMware NSX Introduction

NSX の機能全般及び、ネットワーク仮想化環境の設計に興味のあるかたは下記テックペーパーを参照ください。
http://www.vmware.com/files/pdf/products/nsx/vmw-nsx-network-virtualization-design-guide.pdf
VMware® NSX for vSphere (NSX-V) Network Virtualization Design Guide

ネットワーク仮想化をネットワークの基本から理解する
第1回:理解するために必要なことを整理する
第2回:論理スイッチ(VXLAN)–Layer2 の世界
第3回:分散ルーティング –Layer3 の世界
第4回:分散ファイアウォール -Layer4 の世界(本稿)

ネットワーク仮想化をネットワークの基本から理解する 〜 第2回:論理スイッチ(VXLAN) –Layer2 の世界

■はじめに
「ネットワーク仮想化」をセールスやマーケティングではなく、エンジニアとしてアーキテクチャを正しく理解することが、今回のブログシリーズ「ネットワーク仮想化をネットワークの基本から理解する」のテーマです。「第2回 論理スイッチ(VXLAN) –Layer2 の世界」では、ネットワーク仮想化環境のL2 ネットワークサービスを見ていきます。

論理スイッチは、VMware NSX の提供するL2 ネットワークサービスです。オリジナルのイーサネットフレームにハイパーバイザでVXLAN ヘッダを付加することで、物理ネットワーク上にオーバレイのL2 ネットワークサービスを提供します。論理スイッチを使用することで、物理ネットワークに手を加えることなくL2 ネットワークを追加できます。

NWV02-01-02

論理スイッチの設定はNSX の管理画面から行います。物理サーバや物理ネットワーク機器数十台にまたがるようなL2 ネットワークを構成する際も、個々の物理コンポーネントに設定を行う必要はありません。

NWV02-02

上記の通りGUI から簡単に設定を行うことができますが、APIを介した設定も可能となり、クラウドコントローラと連携することで設定作業を自動化できます。

 

■物理ネットワークにおけるL2スイッチのアーキテクチャ
論理スイッチのアーキテクチャの説明に入る前に、物理ネットワーク環境の説明を行います。物理ネットワーク環境において、端末間での通信を制御するテーブルは2種類あります。端末側で管理するARPテーブルと、物理スイッチ側で管理するMAC アドレステーブルです。

NWV02-03-02

図 物理ネットワーク環境で管理するテーブル

ARP テーブルは、IPアドレスとMAC アドレスを対応させたテーブルとなり、各エンドの端末が保持しています。端末は、ARP テーブルを参照し、通信を行いたい宛先IP アドレスに対応したMAC アドレス宛てにパケットを送信します。

> arp –a(端末Aで実施)
  インターネット アドレス			物理アドレス     			種類
  172.16.10.2(端末BのIP)	BB-BB-BB-BB-BB-BB(端末BのMAC)	動的

MAC アドレステーブルは、端末のMAC アドレスと物理スイッチのポート番号を対応させたテーブルとなっており、物理スイッチが管理しています。物理スイッチは、受信したフレームの送信元MAC アドレス情報を学習することで、テーブルをダイナミックに作成していきます。MAC アドレステーブルはVLAN 毎に管理されており、物理スイッチは受信したパケットの宛先MAC アドレスに対応したポートにパケットを転送します。

> show mac address-table(物理スイッチ上で実施)
Vlan	Mac Address			Type		Ports
----	-----------			--------	-----
10	AAAA.AAAA.AAAA	(端末AのMAC)	DYNAMIC		Gi1(ポート1番)
10	BBBB.BBBB.BBBB	(端末BのMAC)	DYNAMIC		Gi2(ポート2番)

このテーブルにエントリがない宛先MAC アドレスのフレームを受信した場合、物理スイッチは対応するVLAN に所属する全てのポートにフレームを転送します。MAC アドレステーブルのエントリを管理することで、トラフィックを抑制することが可能になります。物理スイッチが提供しているL2 ネットワークサービスを、ネットワーク仮想化環境では論理スイッチとして実装しています。論理スイッチのアーキテクチャについて、「テーブル」に注目する形でこの後見ていきます。

 

■ネットワーク仮想化環境における論理スイッチのアーキテクチャ
ネットワーク仮想化環境において、端末の送信したフレームをカプセル化(VXLAN ヘッダを付加すること)するポイントを、VTEP(VXLAN Tunnel Endpoint)と呼んでいます。VTEP の理解が論理スイッチ理解の第1歩です。

VTEP の実態は、vSphere の視点で見ると、ハイパーバイザの中にある仮想スイッチ(分散スイッチ VDS)上に作成されるVMkernel ポートになります。VMkernel ポートはIP アドレスを持ち、このIP アドレス間でVXLAN のオーバレイ通信を行います。VTEP は分散スイッチ上にVMkernel ポートとして展開されるため、論理スイッチの実装には分散スイッチが必須となります。


ポイント1:VTEPの実態は、ハイパーバイザ上に作成される仮想スイッチのVMkernel ポート

NWV02-04

VTEP 間をVXLAN でオーバレイすることにより構成される論理スイッチの実態は、vSphere の視点で見ると、仮想スイッチ上に作成されるポートグループになります。サーバ仮想化環境では、物理ネットワークのVLAN ID に対応する形でポートグループ作成をするケースがありますが、ネットワーク仮想化環境では論理スイッチのVNI(VXLAN Network Identifier物理環境のVLAN IDに相当)に対応したポートグループが自動的に作成されます。


ポイント2:論理スイッチの実態は、ハイパーバイザ上に作成される仮想スイッチのポートグループ

NWV02-05

仮想マシンから論理スイッチは単にポートグループとして見えています。仮想マシンを論理スイッチに対応したポートグループに接続することで、VXLAN でオーバレイしたネットワーク経由で通信を行うことが可能になります。

この後は、論理スイッチに接続された仮想マシン間で、通信がどのように成立するのかを見ていきます。ネットワーク仮想化環境で通信を成立させるために、3つのテーブルがでてきます。これらのテーブルがどのようなメカニズムで通信を成立させるか確認していきます。

VTEP テーブル:VNI(VXLAN Network Identifier)とVTEP を対応させたテーブル
MAC テーブル :VNI、VTEP、仮想マシンのMAC アドレスを対応させたテーブル
ARP テーブル :仮想マシンのIP アドレスとMAC アドレスを対応させたテーブル

補足情報:論理スイッチを構成する際、VTEP間の通信にマルチキャストを使用するモード(マルチキャストモード)と、使用しないモード(ユニキャストモード)、及び併用するモード(ハイブリッドモード)を選択できます。この後の説明は、ユニキャストモードを前提に進めています。ユニキャストモードでは、コントローラでVTEP テーブルを集約して管理することで、物理ネットワークでマルチキャストを運用する必要がありません。
———-
STEP0: ネットワーク仮想化環境は、ハイパーバイザとコントローラ間で各種テーブル情報を交換するコントロールプレーンと、VTEP 間で仮想マシントラフィックを転送するデータプレーンから構成されています。2台のESXi ホスト上でVNI(VXLAN Network Identifier 物理環境のVLAN IDに相当)5001 に接続している端末間の通信を確認してみます。端末A,B は、論理スイッチ VNI 5001 に対応するポートグループに接続し、電源がOFF の状態になっています。

NWV02-06

図:コントロールプレーンの構成


補足情報:ハイパーバイザとコントローラ間のコネクション(コントロールプレーン)は、下記で確認できます。ハイパーバイザの管理用IP アドレスからコントローラ(192.168.110.201, 192.168.110.202, 192.168.110.203)に接続していることが確認できます。

コントローラクラスタとの接続確認
# esxcli network ip connection list | grep 1234
Proto	Local Address		Foreign Address		State		World Name
-----	--------------------	--------------------	-----------	----------
tcp	192.168.210.51:59453	192.168.110.201:1234	ESTABLISHED	netcpa-worker
tcp	192.168.210.51:61471	192.168.110.202:1234	ESTABLISHED 	netcpa-worker
tcp	192.168.210.51:61397	192.168.110.203:1234	ESTABLISHED 	netcpa-worker

仮想マシン間のデータの転送は、データプレーンを使用します。データプレーンには VTEP(VMkernel ポート)が存在し、VXLAN のオーバレイ通信を行います。

NWV02-07

図:データプレーンの構成


補足情報:データプレーンのVTEP(VMkernel ポート)はESXi ホストにおいて他の管理系ネットワークから独立したTCP/IP スタック(メモリ領域、ルーティングテーブル、ARPテーブル)を持ちます。

ルーティングテーブル確認方法(VXLAN TCP/IP スタック)
# esxcli network ip route ipv4 list -N vxlan
Network        Netmask        Gateway        Interface  Source
-------------  -------------  -------------  ---------  ------
default        0.0.0.0        192.168.250.2  vmk3       MANUAL
192.168.250.0  255.255.255.0  0.0.0.0        vmk3       MANUAL
ARP テーブル確認方法(VXLAN TCP/IP スタック)
# esxcli network ip neighbor list -N vxlan
Neighbor       Mac Address        Vmknic  Expiry    State  Type
-------------  -----------------  ------  --------  -----  -----------
192.168.250.2  00:50:56:01:1e:3d  vmk3    1194 sec         Autorefresh
VTEP 間の疎通確認方法(VXLAN TCP/IP スタック)
# ping ++netstack=vxlan -I vmk3 -d -s 1572 192.168.150.51
PING 192.168.150.51 (192.168.150.51): 1572 data bytes
1580 bytes from 192.168.150.51: icmp_seq=0 ttl=63 time=1.745 ms

———-
STEP1: 仮想マシンの電源をON にすると、ハイパーバイザ内にVTEP テーブル情報が作成されます。VTEP テーブルは、VNI と、対応するVTEP のIP アドレスで構成され、VTEP テーブル情報はコントローラに送付されます。コントローラは、収集したVTEP テーブル情報を、各ハイパーバイザに通知します。この動作により、各ハイパーバイザでVNI に対応するVTEP のIP アドレスを学習することができます。


ポイント3:ハイパーバイザでVTEP テーブルを管理することにより、VNI に対応したブロードキャスト、宛先不明のユニキャスト、及びマルチキャストを転送するVTEP を把握できる

NWV02-08

図:STEP1 VTEP テーブルの作成(コントロールプレーン)


補足情報:ブロードキャスト、宛先不明のユニキャスト、マルチキャストを略してBUM トラフィックと呼びます。宛先不明のユニキャストとは、ハイパーバイザ内に後述のMAC テーブル情報のないトラフィックのことです。

コントローラでの確認方法
# show control-cluster logical-switches vtep-table 5001
VNI	IP(VTEPのIP)		Segment			MAC(VTEPのMAC)
5001	192.168.250.51(ESXi01)	192.168.250.0		01:01:01:01:01:01
5001	192.168.250.52(ESXi02)	192.168.250.0		02:02:02:02:02:02

上記よりコントローラではESXi01、ESXi02 のVTEP を認識していることが分かります。

ハイパーバイザでの確認方法
ESXi01 # esxcli network vswitch dvs vmware vxlan network vtep list --vds-name=Compute_VDS --vxlan-id=5001
IP(VTEPのIP)			Segmant ID		Is MTEP
--------------			-------------		-------
192.168.250.52(ESXi02)		192.168.250.0		false

上記よりESXi01 が、VXLAN5001 の転送先としてESXi02のVTEP を認識していることが分かります。
———-
STEP2: 仮想マシンから通信が発生した際、カーネルモジュールが通信の送信元MAC アドレスから、仮想マシンのMAC アドレスを認識します。認識した仮想マシンのMAC アドレス情報をコントローラクラスタに通知します。

NWV02-09

図:STEP2 MAC テーブルの作成(コントロールプレーン)
コントローラでの確認方法
# show control-cluster logical-switches mac-table 5001
VNI	MAC(端末のMAC)			VTEP-IP			
5001	AA:AA:AA:AA:AA:AA(端末A)	172.16.250.51(ESXi01)
5001	BB:BB:BB:BB:BB:BB(端末B)	172.16.250.52(ESXi02)

上記よりコントローラでは端末A,BのMACアドレスと、対応するVTEP を認識していることが分かります。
———-
STEP3: 仮想マシンのIP アドレス情報を含む特定の通信(ARP Response Request, GARP もしくはDHCP ACK (2016/10/7 修正))から、カーネルモジュールが仮想マシンのIP アドレスとMAC アドレスを認識します。認識した情報をコントローラクラスタに通知します。ARP 抑制(ARP Suppression)が有効な場合、このステップが実施されます。

baiboard_2016-10-31_16-40-53

図:STEP3 ARP テーブルの作成(コントロールプレーン)

ARP 抑制はデフォルトで有効となり、論理スイッチの設定画面「IP検出の有効化」のチェックボックスで有効化、無効化を行います。以降の説明はARP 抑制が有効化されている前提で進めていきます。

コントローラでの確認方法
# show control-cluster logical-switches arp-table 5001
VNI	IP(端末のIP)		MAC(端末のMAC)
5001	172.16.10.11(端末A)	AA:AA:AA:AA:AA:AA(端末A)
5001	172.16.10.12(端末B)	BB:BB:BB:BB:BB:BB(端末B)

上記よりコントローラでは端末A,B のARP テーブル情報を認識していることが分かります。
———-
STEP4: 端末A が端末B に対しARP リクエストを送信します。端末A からのARP リクエストをESXi01 のカーネルモジュール が受け取ります。ESXi01 は、リクエストをコントローラに問合せ、端末B のARP テーブル情報をコントローラから受け取ります。ESXi01 は端末A にARP リプライを返します。


ポイント4:ハイパーバイザでARP テーブルを管理することにより、仮想マシンからのARP リクエストに代理応答し、物理ネットワークを流れるトラフィック(ARPブロードキャスト)を削減できる

NWV02-12

図:STEP4 ARP テーブルの取得(コントロールプレーン)
ハイパーバイザでの確認方法
ESXi01 # esxcli network vswitch dvs vmware vxlan network arp list --vds-name=Compute_VDS --vxlan-id=5001
IP(端末のIP)		MAC(端末のMAC)	
------------		-----------------		
172.16.10.12(端末B)	BB:BB:BB:BB:BB:BB(端末B)

上記よりESXi01 がARP テーブル情報(端末BのIP アドレスとMAC アドレスの対応)を認識していることが分かります。


補足情報:コントローラで端末B に対応するARP テーブルを保持していない場合、ESXi ホストはARP リクエストを通常のブロードキャストトラフィックとして処理します。VTEP テーブルを参照しVNI 5001 に対応するESXi ホストに送信します。

———-
STEP5: ESXi01 は、端末B に対応するMACテーブルをコントローラクラスタに問合せ、端末B のMAC テーブル情報を取得します。

NWV02-13

図:STEP5 MAC テーブルの取得(コントロールプレーン)
ハイパーバイザでの確認方法
ESXi01 # esxcli network vswitch dvs vmware vxlan network mac list --vds-name=Compute_VDS --vxlan-id=5001
Inner MAC(端末のMAC)		Outer MAC(VTEPのMAC)		Outer IP(VTEPのIP)
-----------------		-----------------		-------------	
BB:BB:BB:BB:BB:BB(端末B)	02:02:02:02:02:02(ESXi02)	172.16.250.52(ESXi02)

上記よりESXi01 は、ESXi02 上に端末B が存在することを認識していることが分かります。
———-
STEP6: ESXi01 からのARP 応答(STEP4 で実施)により端末A は端末B のMAC アドレス情報を取得し、端末B に対する通信を開始します。ESXi01 はMAC テーブル(STEP5 で取得)を参照し、VXLAN でカプセル化したパケットを、ESXi02 のVTEP へ送信します。ESXi02 では、パケットを受信した際に端末A に対応するMAC テーブルを作成します。その後VXLAN ヘッダを取り除き、端末B にオリジナルのフレームを転送します。


ポイント5:ハイパーバイザでMAC テーブルを管理することにより、宛先の仮想マシンが動作しているホストのVTEP を把握し、物理ネットワークを流れるトラフィック(宛先不明のユニキャスト)を削減できる

NWV02-14

図:STEP6 端末A-B間通信の開始(データプレーン)


補足情報:STEP5 において、コントローラで端末B に対応するMAC テーブルがなく、ハイパーバイザ内にもMAC テーブルがない場合、ESXi01 は端末B に対する通信を宛先不明のユニキャストとして処理します。VTEP テーブルを参照しVNI 5001 に対応するESXi ホストに送信します。

 

■物理ネットワーク環境とネットワーク仮想化環境の比較
ポイント1-5を再掲します。


ポイント1:VTEPの実態は、ハイパーバイザ上に作成される仮想スイッチのVMkernelポート


ポイント2:論理スイッチの実態は、ハイパーバイザ上に作成される仮想スイッチのポートグループ

上記2つのポイントはサーバ仮想化エンジニアの方はイメージしやすいのではないでしょうか。


ポイント3:ハイパーバイザでVTEP テーブルを管理することにより、VNI に対応したブロードキャスト、宛先不明のユニキャスト、及びマルチキャストを転送するVTEP を把握できる


ポイント4:ハイパーバイザでARP テーブルを管理することにより、仮想マシンからのARP リクエストに代理応答し、物理ネットワークを流れるトラフィック(ARPブロードキャスト)を削減できる


ポイント5:ハイパーバイザでMAC テーブルを管理することにより、宛先の仮想マシンが動作しているホストのVTEP を把握し、物理ネットワークを流れるトラフィック(宛先不明のユニキャスト)を削減できる

上記3つのポイントについて「テーブル」の観点から、物理ネットワーク環境とネットワーク仮想化環境を比較してみます。

NWV02-15

ARP テーブルの役割は物理ネットワーク環境と全く同じです。テーブル情報を、端末だけではなく、コントローラで集約して管理を行い、端末からのARP リクエストにハイパーバイザが代理応答することで、物理ネットワークを流れるトラフィックを削減しているのがネットワーク仮想化環境の特徴となります。

MAC テーブルは、物理ネットワーク環境のMAC アドレステーブルと同等の役割を果たしています。ハイパーバイザは、MAC テーブルを参照することで、VTEPの先にある端末のMAC アドレスを把握し、物理ネットワークを流れるトラフィックを削減することができます。

VTEP テーブルは、物理スイッチにおけるポートのVLAN 設定に対応します。VTEP テーブルを参照することでブロードキャスト、宛先不明のユニキャスト、及びマルチキャスト(BUM トラフィック)を転送する先を判断することができます。ユニキャストモードではVTEP テーブルをコントローラが集約して管理することで、マルチキャストに依存しないVXLAN の運用を可能にしています。

NWV02-16

論理スイッチの管理するVTEP テーブルとMAC テーブルを合わせ、VTEP を物理スイッチのポートに置き換えて考えると、論理スイッチはネットワーク仮想化環境において、物理スイッチと同等の機能を提供していることが分かります。

ネットワーク仮想化環境では、L2ネットワークを管理するための各種テーブルを物理ネットワーク機器から切り離し、ハイパーバイザで管理することにより、物理ネットワークと同等のサービスを、物理ネットワークに依存しない形で柔軟に展開することを可能にします。さらにコントロールプレーンを実装し、コントローラで各種テーブル情報を集約することで、マルチキャストに依存しない論理スイッチ(VXLAN)の展開や、物理ネットワークを流れるトラフィックを削減する運用を可能にしています。

 

■補足情報 論理スイッチ(VXLAN)を提供するVMware NSX のコンポーネント

NWV02-17

・NSX Manager(マネジメントプレーン)
NSX を構築する際に最初に展開するコンポーネントで、仮想アプライアンスとして提供されています。NSX Manager は初期構築時の ESXi ホストへのカーネルモジュールのインストールや、論理ルータコントロールVM やNSX Edge といった仮想アプライアンスの払い出しを担います。また、NSX Manager はAPI のエントリポイントとなり、GUI だけでなくAPI 経由でNSX 環境の設定を可能にします。

・NSX コントローラクラスタ(コントロールプレーン)
NSX コントローラクラスタは、現時点で3台の仮想アプライアンスで構成することを推奨しており、論理スイッチにおいて、各種情報(VTEP テーブル、MAC テーブル、ARP テーブル)を集中管理するポイントになります。VXLAN のVNI 毎に担当するコントローラが決められ、例えばVNI 5000はコントローラ1番、VNI 5001 はコントローラ2番というように役割が割り当てられます。テーブル情報は、担当するコントローラのみが保持します。なお、論理スイッチ(VXLAN) をマルチキャストモードで実装する場合は、コントローラクラスタは必要ありません。

3台のコントローラ(192.168.110.201, 192.168.110.202, 192.168.110.203)で構成されている環境で、VNI 5001 の情報を確認する手順は下記のとおりです。

VXLAN VNI 5001 を管理するコントローラの確認
# show control-cluster logical-switches vni 5001
VNI	Controller		BUM-Replication		ARP-Proxy
5001	192.168.110.202		Enabled			Enabled

この出力結果から、192.168.110.202 のコントローラがVNI 5001 の情報を管理していることが分かります。VNI 5001 の各種テーブル情報を見るためには、該当のコントローラ(192.168.110.202)にログインする必要があります。

VXLAN VNI 5001 のVTEP テーブルの確認
# show control-cluster logical-switches vtep-table 5001
VNI	IP(VTEPのIP)		Segment			MAC(VTEPのMAC)
5001	192.168.250.51(ESXi01)	192.168.250.0		01:01:01:01:01:01
5001	192.168.250.52(ESXi02)	192.168.250.0		02:02:02:02:02:02
VXLAN VNI 5001 のMAC テーブルの確認
# show control-cluster logical-switches mac-table 5001
VNI	MAC(端末のMAC)			VTEP-IP			
5001	AA:AA:AA:AA:AA:AA(端末A)	172.16.250.51(ESXi01)
5001	BB:BB:BB:BB:BB:BB(端末B)	172.16.250.52(ESXi02)
VXLAN VNI 5001 のARP テーブルの確認
# show control-cluster logical-switches arp-table 5001
VNI	IP(端末のIP)		MAC(端末のMAC)
5001	172.16.10.11(端末A)	AA:AA:AA:AA:AA:AA(端末A)
5001	172.16.10.12(端末B)	BB:BB:BB:BB:BB:BB(端末B)

・論理ルータコントロールVM(コントロールプレーン)
論理ルータコントロールVM は論理スイッチに関与しません。(第3回分散ルーティングで解説を行います)

・ハイパーバイザ カーネルモジュール(データプレーン)
NSX 環境を構築する際、ホストの準備のステップで各ESXi にインストールされるカーネルモジュールとなります。VIB(vSphere Installation Bundle)ファイルとしてインストールされ、論理スイッチの機能はカーネルモジュール(vdl2)としてロードされます。 カーネルモジュールは、ハイパーバイザ内で論理スイッチ(VXLAN)のテーブル情報を管理します。

ハイパーバイザからは、NSX コントローラクラスタと、NSX Manager にコネクションを張り、各種情報のアップデートを行います。NSX コントローラクラスタへのコネクションはハイパーバイザ内のUWA(User World Agent)netcpa(TCP/1234)を介して確立し、NSX Manager へのコネクションはUWA vsfwd(TCP/5671)を介して確立します。

NWV02-18-02

コントローラクラスタとの接続確認
# esxcli network ip connection list | grep 1234
Proto	Local Address		Foreign Address		State		World Name
-----	--------------------	--------------------	-----------	----------
tcp	192.168.210.51:59453	192.168.110.201:1234	ESTABLISHED	netcpa-worker
tcp	192.168.210.51:61471	192.168.110.202:1234	ESTABLISHED 	netcpa-worker
tcp	192.168.210.51:61397	192.168.110.203:1234	ESTABLISHED 	netcpa-worker

上記出力より、ハイパーバイザの管理用IP アドレスから3台のコントローラ(192.168.110.201, 192.168.110.202, 192.168.110.203)に、netcpa を介して接続していることが確認できます。

NSX Manager との接続確認
# esxcli network ip connection list | grep 5671
Proto	Local Address		Foreign Address		State		World Name
-----	--------------------	--------------------	-----------	----------
tcp	192.168.210.51:23251	192.168.110.42:5671	ESTABLISHED	vsfwd

上記出力より、ハイパーバイザの管理用IP アドレスからNSX Manager に、vsfwd を介して接続していることが確認できます。

論理スイッチのカーネルモジュールは、ハイパーバイザ内でVTEP, MAC, ARP テーブルを管理します。

VXLAN VNI 5001 のVTEP テーブルの確認
ESXi01 # esxcli network vswitch dvs vmware vxlan network vtep list --vds-name=Compute_VDS --vxlan-id=5001
IP(VTEPのIP)			Segmant ID		Is MTEP
--------------			-------------		-------
192.168.250.52(ESXi02)		192.168.250.0		false
VXLAN VNI 5001 のMAC テーブルの確認
ESXi01 # esxcli network vswitch dvs vmware vxlan network mac list --vds-name=Compute_VDS --vxlan-id=5001
Inner MAC(端末のMAC)		Outer MAC(VTEPのMAC)		Outer IP(VTEPのIP)
-----------------		-----------------		-------------	
BB:BB:BB:BB:BB:BB(端末B)	02:02:02:02:02:02(ESXi02)	172.16.250.52(ESXi02)
VXLAN VNI 5001 のARP テーブルの確認
ESXi01 # esxcli network vswitch dvs vmware vxlan network arp list --vds-name=Compute_VDS --vxlan-id=5001
IP(端末のIP)			MAC(端末のMAC)	
------------			-----------------		
172.16.10.12(端末B)		BB:BB:BB:BB:BB:BB(端末B)	

・NSX Edge(データプレーン)
NSX Edge のインターフェイスを、論理スイッチに接続することでNSX Edge の持つ各種ネットワークサービス(ロードバランサ、ルーティング、NAT、ファイアウォール、VPN、 DHCP 等)を論理スイッチに接続した仮想マシンに対して提供します。論理スイッチの提供するL2ネットワークサービスには直接関与しません。

 

■関連リンク
今回ご紹介した内容をオンラインのハンズオン環境上で確認いただくことができます。コマンドラインの出力はハンズオン環境をベースに作成しています。
VMware HOL Online
HOL-SDC-1403 – VMware NSX Introduction

NSX の機能全般及び、ネットワーク仮想化環境の設計に興味のあるかたは下記テックペーパーを参照ください。
VMware® NSX for vSphere (NSX-V) Network Virtualization Design Guide

ネットワーク仮想化をネットワークの基本から理解する
第1回:理解するために必要なことを整理する
第2回:論理スイッチ(VXLAN)–Layer2 の世界(本稿)
第3回:分散ルーティング –Layer3 の世界
第4回:分散ファイアウォール -Layer4 の世界

ネットワーク仮想化をネットワークの基本から理解する 〜 第1回:理解するために必要なことを整理する

■ はじめに
「ネットワーク仮想化」をセールスやマーケティングではなく、エンジニアとしてアーキテクチャを正しく理解することが、今回のブログシリーズ「ネットワーク仮想化をネットワークの基本から理解する」のテーマです。このシリーズは、VMware 社内でネットワークのバックグラウンドを持ったエンジニアが行った小さなワークショップがベースになっています。ワークショップ中ではホワイトボードを使用して通信の仕組みを理解し、実際のネットワーク仮想化環境でコマンドラインを使用し出力される情報と比較しながら、ネットワーク仮想化環境の特徴的な機能を1つ1つ確認していきました。

「第1回 理解するために必要なことを整理する」では、エンジニアがネットワーク仮想化を理解するために必要となる技術スタックを明確にし、第2回以降で各技術スタックの具体的な解説を行っていきます。

 

■ ネットワーク仮想化の出てきた背景
VMware の提唱する「ネットワーク仮想化」は、データセンタネットワークのオペレーションを劇的に改善する革新的なテクノロジーです。ネットワーク仮想化環境では、ネットワークサービスを物理インフラストラクチャから切り離すことで、サーバ仮想化環境の仮想マシンと同じように、各種ネットワークサービスを迅速に展開できるようになります。

NWV01-01

図:データセンタ内の仮想ポート数

上のグラフはデータセンタのサーバが、物理スイッチもしくは仮想スイッチどちらのポートに接続されているかを示したものです。2012 年の時点で、仮想スイッチのポート数が物理スイッチのポート数を超えていることから、各種ネットワークサービスやセキュリティポリシーを適用する最適なポイントが、物理スイッチから、ハイパーバイザの中で動作する仮想スイッチに移ってきていることが分かります。このような背景の中、VMware はネットワーク仮想化環境を提供するVMware NSX の提供を開始しました。

 

■ 理解するために必要なことを整理する
ネットワーク仮想化のセミナーに参加いただくのは、当初サーバ仮想化に関わるエンジニアが多かったのですが、最近の傾向としていわゆるネットワークエンジニアに参加いただくことが多くなってきているように思います。「ネットワーク仮想化」を理解するためには、サーバ仮想化と、従来のネットワークと両者にまたがった知識が必要となります。

NWV01-02

図:スキルセット

両者の交差する領域には具体的にどういったものがあるでしょうか。仮想化環境で提供されている機能を考えたときに、ハイパーバイザの提供するvMotion、HA、FT などの機能は従来通りサーバ仮想化エンジニアが担当し、ロードバランサ、VPN といった各種ネットワークサービスに関してはネットワークエンジニアが担当することで、従来の役割分担と大きく変わるところはないと考えています。

NWV01-03

図:スキルセットに対応した技術スタック

中心にある3つのスタックは、両方のエンジニアの交差する領域となり、ハイパーバイザの中で各種ネットワークサービスが提供される部分になります。この中で論理スイッチ(L2) の部分はネットワーク仮想化環境を理解するための重要なベースになると考えています。加えて分散ルーティング(L3)及び、分散ファイアオール(L4)は、ネットワーク仮想化環境の特徴的な機能で、既存のデータセンタネットワークの課題を解決します。

ネットワーク仮想化のセミナーを行う中でいただく質問を通して、バックグラウンドによって分かりにくいポイントが異なっていることが分かります。サーバ仮想化エンジニアの方は、遠回りに見えるかもしれませんが、物理ネットワーク環境の端末間で通信が成立する基本的なメカニズムを理解したほうが、結果的にネットワーク仮想化環境の理解が早まります。例えば、下図のようなL2SWに端末を2台接続した環境において、端末間A – B 間で通信が成立するメカニズムをきちんと説明できる方は意外に少ないように思います(決して難しいことではなく、IT 関連の新入社員研修にこの説明は必ず含まれていますと思います)。

NWV01-04

図:L2スイッチに接続された端末A-B間の通信

端末間の通信を成立させるためには、各種「テーブル」が深く関わってきており、それはネットワーク仮想化環境になっても全く同じです。ネットワークエンジニアは前述の物理ネットワークでの通信については良く理解していますが、サーバ仮想化環境のオペレーションに慣れている方はまだ少ないように思います。そのため、特にハイパーバイザの中がブラックボックスになってしまい、管理されている情報が不明確になってしまいます。

1. 物理ネットワーク環境で管理されている各種「テーブル」
2. ネットワーク仮想化環境で管理されている各種「テーブル」

上記2つの基本的なポイントをおさえることで、サーバ仮想化エンジニア、ネットワークエンジニア共に、ハイパーバイザでネットワークサービスを提供するメリットと、実現するためのアーキテクチャを明確にすることができます。

ネットワーク仮想化は、データセンタネットワークのオペレーションを劇的に改善しますが、決して既存のテクノロジーと断絶したものではありません。既にあるサーバ仮想化とネットワークアーキテクチャの延長線上にあり、既存の物理インフラストラクチャの上で動作します。第2回からは、既存の物理ネットワーク環境と対比し、特にネットワークを制御する各種「テーブル」に注目することで、物理ネットワーク環境との共通点と差異を明確にしていきます。

 

■ 今後の展開
ハイパーバイザの中をブラックボックスにしないために、何が行われているかを文章だけではなくコマンドラインを中心とした実環境での確認方法と合わせて解説していきます。

第2回 論理スイッチ(VXLAN)ではNSX の提供するL2 ネットワークサービスの説明をします。物理環境でL2 スイッチが持っている「MAC アドレステーブル」が、ネットワーク仮想化環境でどう変わるかに注目します。

NWV01-05

図:第2回 論理スイッチ(VXLAN)物理と仮想の比較

第3回 分散ルーティングでは、NSX の提供するL3 ルーティングサービスの説明をします。物理環境でルータや、L3 スイッチが持っている「ルーティングテーブル」が、ネットワーク仮想化環境でどう変わるかに注目します。

NWV01-06

図:第3回 分散ルーティング 物理と仮想の比較

第4回 分散ファイアウォールでは、NSX ので供するL4 ファイアウォールサービスの説明をします。物理環境でネットワーク機器が持っている「ルールテーブル」が、ネットワーク仮想化環境でどう変わるかに注目します。

NWV01-07

図:第4回 分散ファイアウォール 物理と仮想の比較

 

■ 補足情報 ネットワーク仮想化を提供するVMware NSX を構成するコンポーネント

各機能で使用するコンポーネントが異なるため、各回でどのコンポーネントがどういった役割を果たしているのか補足情報として解説を行います。今回は各コンポーネントの概要を説明します。

NWV01-09

図:VMware NSX を構成するコンポーネント

・NSX Manager(マネジメントプレーン)
NSX を構築する際に最初に展開するコンポーネントで、仮想アプライアンスとして提供されています。NSX Manager は初期構築時の ESXi ホストへのカーネルモジュールのインストールや、論理ルータコントロールVM やNSX Edge といった仮想アプライアンスの払い出しを担います。また、NSX Manager はAPI のエントリポイントとなり、GUI だけでなくAPI 経由でNSX 環境の設定を可能にします。

・NSX コントローラクラスタ(コントロールプレーン)
NSX コントローラクラスタは、現時点で3台の仮想アプライアンスで構成することを推奨しており、論理スイッチ(第2回)と分散ルータ(第3回)において、各種テーブルを集中管理するコンポーネントになります。なお、分散FW(第4回)はコントローラクラスタを使用しません。

・論理ルータコントロールVM(コントロールプレーン)
論理ルータコントロールVM は、仮想アプライアンスとして提供され、分散ルーティング環境において、ルーティングの処理を集中して行います。テナント単位でスタティックルーティング情報や、ダイナミックルーティングプロトコル(OSPF, BGP)経由で学習したルーティング情報を管理し、コントローラクラスタ経由でESXi ホストに配信します。

・ハイパーバイザ カーネルモジュール(データプレーン)
NSX 環境を構築する際、ホストの準備のステップで各ESXi ホストにインストールされるカーネルモジュールとなります。今回のシリーズで解説する各機能を担い、ハイパーバイザの中で下記のネットワークサービスを提供します。
a.論理スイッチ(vdl2)
第2回で解説する論理スイッチの機能を担います。
b.分散ルータ(vdrb)
第3回で解説する分散ルーティングの機能を担います
c.分散FW(vsip)
第4回で解説する分散ファイアウォールの機能を担います。

・NSX Edge(データプレーン)
仮想アプライアンスとして提供され、単体で各種ネットワークサービス機能(ロードバランサ、ルーティング、NAT、ファイアウォール、VPN、 DHCP 等)を提供する「スイスのアーミーナイフ」のようなコンポーネントです。従来の物理のネットワーク機器が仮想アプライアンスとして置き換わったイメージです。機能スタックのネットワークサービスに該当し、今回のシリーズでは解説を行いません。

 

■関連リンク
ネットワーク仮想化をネットワークの基本から理解する
第1回:理解するために必要なことを整理する(本稿)
第2回:論理スイッチ(VXLAN)–Layer2 の世界
第3回:分散ルーティング –Layer3 の世界
第4回:分散ファイアウォール -Layer4 の世界

V2C (Virtual to Cloud) – VMware vSphere 環境から vCloud Air への移行

VMwareは、2014年11月にパブリッククラウド vCloud Air のサービスを日本で開始しました。本シリーズのエントリでは、物理から仮想化環境への移行P2V(Physical to Virtual) について記載してきましたが、今回はP2V で移行したオンプレミスの仮想マシンを、vCloud Air に移行するV2C(Virtual to Cloud) をご紹介します。

20141226-v2c-01-2

V2C を実施する際にはVMware vCloud Connector(vCC)を使用することで、プライベートクラウドとパブリッククラウド間での仮想マシンの移行をスムーズに行うことができるようになります(vCC は無償で提供されています)。vCC の導入とオペレーションについて、詳細は下記リンクで公開されているドキュメントをご参照ください。

vCloud Connector構築ガイド(Step by Step の構築ガイドで簡単に環境が構築できます)

 

■ アーキテクチャ
オンプレミス環境 – vCloud Air 間をvCC で接続し、ネットワーク経由で仮想マシンのイメージを移行します。vCC はConnector Server と、Connector Node で構成されており、オンプレミスのvSphere 環境にデプロイします。vCloud Air 側は、あらかじめデプロイされているマルチテナント型のConnector Nodeを使用します。

20141226-v2c-02-2

Connector Server(オンプレミス) – Connector Node(Air) 間の通信にはTCP ポート8443 を使用するため、FWで通信を許可する必要があります。データ転送はNode 間で実施します。デフォルトの設定ではデータ転送にTCP ポート8443 を使用しますが、UDT(UDP-based Data Transfer Protocol)を使用する場合はUDP ポート8190 をFW で許可します。

 

■ 構築手順
オンプレミスのvSphere 環境に、Connector Server とConnector Node を展開します。各コンポーネントはOVF 形式で提供されており、vCenter サーバから簡単にデプロイできます。

1. vCloud Connector Node の展開
vCenter Server から「OVF テンプレートのデプロイ」を選択し、OVF 形式で提供されているConnector Node を展開します。展開時にIPアドレスの設定を行います。

2. vCloud Connector Node の設定
展開後にWeb ブラウザから「https://Connector_Node_IP:5480」にアクセスし、vCenter Server を登録します。データ転送にUDT プロトコルを使用する場合は、Connector Node で設定を行います。

3. vCloud Connector Server の展開
vCenter Server から「OVF テンプレートのデプロイ」を選択し、OVF 形式で提供されているConnector Server を展開します。展開時にIP アドレスの設定を行います。

4. vCloud Connector Server の設定
展開後にWeb ブラウザから「https://Connector_Server_IP:5480」にアクセスし、vCenter Server を登録します。オンプレミス側及びAir 側のConnector Node の登録を実施します。

 

■ 移行手順
各コンポーネントの展開及び設定後、vSphere Client の「ホーム」画面からvCloud Connector の管理画面にアクセスできるようになります。Connector のオペレーションは、今後vSphere Web Client でも実装予定ですが、現在はvSphere Clientから実施します。オンプレミス及びAir 側のvCC Node を登録することでセットアップは完了です。移行対象の仮想マシンを選択し、vCloud Air へ「Copy」することで、簡単に移行ができます。

20141226-v2c-05-2

 

■ まとめ
vCloud Connector を使用いただくことで、オンプレミスの仮想マシンを簡単にvCloud Air 上に移行することができます。オンプレミスのvSphere 環境と同様に幅広いゲストOSがvCloud Air 上で動作しますので、P2V を行った古いゲストOSをvCloud Air 上で稼働させることが可能になります。また、vSphere 環境と同じアーキテクチャで動作しますので、仮想マシンのイメージの変換等、異なるアーキテクチャのパブリッククラウドへの移行時に発生する煩雑なオペレーションがありません。

20141226-v2c-04-2

オンプレミス環境とvCloud Air 間のワークロード移行にはvCloud Connector をご活用ください。

vCloud Connector構築ガイド(Step by Step の構築ガイドで簡単に環境が構築できます)

 

[仮想化への移行]シリーズ
・はじめに
-移行計画、準備段階でのポイント
・V2V (Virtual to Virtual)
- VMware vCenter Converter Standaloneを利用した他の仮想化製品フォーマットから VMware vSphere 環境への移行
・P2V (Physical to Virtual)
- VMware vCenter Converter Standalone を利用した物理サーバ (Linux) から VMware vSphere 環境への移行
・I2V (3rd Party Image/Backup Tool to Virtual)
- 3rd Party Image/Backup Tool から VMware vSphere 環境への移行
・V2C (Virtual to Cloud)
- VMware vSphere 環境から VMware vCloud Air への移行 ← 本エントリ

Interop Tokyo 2014 Automation 02 – 負荷に応じたWeb サーバの自動展開(オートスケール)

Written by: Noritaka Kuroiwa, Tomohiro Iwafuchi

Interop Tokyo 2014 VMware ブースのAutomation コーナーでは、SDDC(Software-Defined Data Center)全体の最適化をテーマに、vCAC(VMware vCloud Automation Center)の展示を行いました。vCAC は、IaaS、PaaS を提供するプラットフォーム基盤としての特徴に加え、エンタープライズIT 環境を自動化していくという側面を強く持った製品です。

vCAC の提供するサービスカタログ

vCAC の提供するサービスカタログ

会場ではネットワークに関連した自動化ソリューションをデモンストレーションしています。第2回目では、「負荷に応じたWeb サーバの自動展開(オートスケール)」のデモンストレーションとして、vCAC(vCloud Automation Center) – vCO(vCenter Orchestrator) – vC Ops(vCenter Operations Manager) – F5 BIG-IP LTM の連携をご紹介します。

コンポーネント間の連携

コンポーネント間の連携

サービスに対する負荷が急増した場合、サービスを提供するサーバを追加/起動(スケールアウト)することで安定したサービスを提供することが可能になります。逆に負荷が軽減した際にはサーバを停止/削除(スケールイン)することで、リソースの有効活用が可能になります。サーバーの追加/起動、停止/削除を人手を介さずに、自動で行うことでオートスケール環境を実現します。

エンドユーザーは、ロードバランサーを経由してWeb サーバにアクセスする構成となります。仮想化環境の運用管理を行うvC Ops でWeb サーバのワークロードをモニターし、CPU 使用率を閾値に、vCO にSNMP-Trap を送付します。vCO では、SNMP-Trap の中身を精査し、定義したワークフローを基に、スケールアウト、スケールインを実行します。

 vCenter Operations Manager (vC Ops)によるワークロードのモニター

vC Ops(vCenter Operations Manager)によるワークロードのモニター

スケールアウトする際にはサーバを追加するのと同時に、追加したサーバのIPアドレスをロードバランサーのプールメンバーに追加するワークフローを実行します。逆にスケールインした際にはサーバを削除し、削除したサーバのIPアドレスをロードバランサーのプールメンバーから削除します。

BIG-IP LTM のプールメンバー設定画面

BIG-IP LTM のプールメンバー設定画面

下記はスケールアウトする際に実行するvCO ワークフローの例です。この中では仮想マシンを追加/起動し、起動した仮想マシンのIPアドレスを取得し、取得したIPアドレスをロードバランサーのプールに追加しています。

vCO ワークフロー(Scale-OUT)

vCO ワークフロー(Scale-OUT)

下記はスケールインする際に実行するvCO ワークフローの例です。ロードバランサーのプールメンバーからサーバのIPを削除し、対応する仮想マシンを停止/削除しています。

vCO ワークフロー(Scale-IN)

vCO ワークフロー(Scale-IN)

負荷に応じたWEBサーバの自動展開(オートスケール)のデモンストレーション(動画)は下記リンクからご覧いただけます。VMwareは、仮想マシン及びネットワークサービスの展開から設定までを自動化し、SDDC 全体を最適化するソリューションを提供します。

動画リンク 「負荷に応じたWeb サーバの自動展開(オートスケール)」

vCAC サービスカタログからAuto Scale サービスを申請

vCAC サービスカタログからAuto Scale サービスを申請 以降は動画を参照ください

Interop 2014 関連リンク

Interop Tokyo 2014 VMware SDDC におけるネットワーク&ストレージ仮想化、マネージメント 〜Best of Show Award への挑戦〜
Interop Tokyo 2014 自宅でNSX VMware Hands On LABS のご紹介
Interop Tokyo 2014 ブースの舞台裏
Interop Tokyo 2014 Software Defined Storage コーナー デモ環境構 築TIPS
Interop Tokyo 2014 Automation 01 – ネットワークサービスの展開及び設定の自動化
Interop Tokyo 2014 Automation 02 – 負荷に応じたWeb サーバの自動展開(オートスケール)
Interop Tokyo 2014 マネージメントコーナー紹介

Interop Tokyo 2014 Automation 01 – ネットワークサービスの展開及び設定の自動化

Interop Tokyo 2014 VMware ブースのAutomation コーナーでは、SDDC(Software-Defined Data Center)全体の最適化をテーマに、vCAC(VMware vCloud Automation Center)の展示を行いました。vCAC は、IaaS、PaaS を提供するプラットフォーム基盤としての特徴に加え、エンタープライズIT 環境を自動化していくという側面を強く持った製品です。

vCAC の提供するサービスカタログ

vCAC の提供するサービスカタログ

会場ではネットワークに関連した自動化ソリューションをデモンストレーションしています。第1回目では、「ネットワークサービスの展開及び設定の自動化」のデモンストレーションとして、vCAC とNSX の連携をご紹介します。

Web、AP、DB サーバによる 3-Tier システムの構成

Web、AP、DB サーバで構成された 3-Tier システムの展開

仮想マシンを展開した後にユーザが最終的にサービスを利用できるようになるまでには、付随するいくつかの作業を実施する必要があります。その中で、特にボトルネックとなりやすいポイントの1つにネットワーク関連のサービスがあります。

ネットワーク環境を仮想化し、リソースをプール化することで、柔軟なサービス提供が可能になりますが、ポイントはもう1つあります。例えネットワーク環境が仮想化されていても、仮想化されたネットワークサービスを手動で設定するのであれば、そこにはいままで物理環境でかかっていたのと同じだけの労力と時間がかかることになります。

vCAC のサービスカタログ(ブループリント)には、仮想マシンだけではなく、ネットワーク構成情報を定義することができます。ネットワーク仮想化環境を提供するVMware NSX と連携することで、仮想マシンを展開すると同時に、ネットワークサービスを展開し、展開したネットワークサービスに適切な設定を行い、仮想マシンに適用することが可能になります。

vCAC のブループリント設定画面 仮想マシンを接続するネットワークプロファイルと、仮想マシンが所属するセキュリティグループを定義

vCAC のブループリント設定画面 仮想マシンを接続するネットワークと、仮想マシンが所属するセキュリティグループを定義

サービスに必要なリソースを仮想化環境でプール化することで、仮想マシンの展開時にダイナミックにプロビジョニングし、役割を終えた仮想マシンを破棄する際にはリソースが解放されます。仮想マシンの展開と同時に、展開した仮想マシンに適用できるネットワークサービスには下記が含まれます。

・NSX Edge(ルーティング、ロードバランス、ファイアウォール、NAT 機能を提供)
・論理スイッチ(VXLAN L2 ネットワークを提供)
・セキュリティグループ(分散ファイアウォール、アンチウィルスサービス等を提供)

NSX のセキュリティグループ

NSX のセキュリティグループ “Service Web”, “Service AP”, “Service DB”はvCAC ブループリント設定に対応

ネットワークサービスを含む3階層アプリケーションを展開するデモンストレーション(動画)は下記リンクからご覧いただけます。VMwareは、仮想マシン及びネットワークサービスの展開から設定までを自動化し、SDDC 全体を最適化するソリューションを提供します。

動画リンク 「ネットワークサービスの展開及び設定の自動化」

vCAC カタログからWebサービス(3-Tier システム)を申請

vCAC サービスカタログからWebサービス(3-Tier システム)を申請 以降は動画を参照ください

Interop 2014 関連リンク

Interop Tokyo 2014 VMware SDDC におけるネットワーク&ストレージ仮想化、マネージメント 〜Best of Show Award への挑戦〜
Interop Tokyo 2014 自宅でNSX VMware Hands On LABS のご紹介
Interop Tokyo 2014 ブースの舞台裏
Interop Tokyo 2014 Software Defined Storage コーナー デモ環境構 築TIPS
Interop Tokyo 2014 Automation 01 – ネットワークサービスの展開及び設定の自動化
Interop Tokyo 2014 Automation 02 – 負荷に応じたWeb サーバの自動展開(オートスケール)
Interop Tokyo 2014 マネージメントコーナー紹介

押さえておきたいvSphere の基本~ネットワーク編 第2回~

「押さえておきたいvSphere の基本」のネットワーク編として、仮想化環境におけるネットワークの基本を3回に分けてご紹介していきます。第2回は、vSphere Enterprise Plus エディションに対応した分散スイッチ(vSphere Distributed Switch 以下vDS と記載)固有の機能のなかから、標準スイッチ(vSphere Standard Switch 以下vSS と記載)にはない下記3つのポイントについて解説を行います。

・複数のホストで使用するネットワークを効率的に管理する
・広帯域ネットワークに各種トラフィックを集約して使用する
・VXLAN を使用しネットワーク仮想化を実装する

■ 複数のホストで使用するネットワークを効率的に管理する
単一のホスト上に構成される標準スイッチ(vSS)に対し、分散スイッチ(vDS)は、複数のESXi ホストにまたがって構成することができます。

vsphere-nw-part2-01

トラフィックの処理を行うデータプレーンは、標準スイッチと同様にプロキシスイッチとして各ホストに配置されますが、管理プレーンをvCenter に配置することでネットワーク構成の一元管理を実現しています。例えば仮想マシン用ポートグループを作成する際、標準スイッチ(vSS)では各ESXi ホスト上で個々に設定を実施することになるのに対し、分散スイッチ(vDS)では、1回設定をするだけで構成が完了します。また、仮想マシンがvMotion によって異なるホストに移行した後も、分散仮想スイッチ(vDS)上では同じポートに接続されていることになり、統計情報やステート情報を引き継ぐことができます。

■ 広帯域ネットワークに各種トラフィックを集約して使用する
10Gbps のNIC を搭載したサーバが普及してきており、vSphere 5.5 からは40Gbps のNIC がサポートされてきています。こうした背景から、ESXi ホストのネットワークを構成する際に、トラフィックのタイプごとに個別の物理リンク(1Gbps)を使用する構成ではなく、1本の物理リンク(10Gbps)のなかに複数の種類のトラフィックを通す構成をとるケースがあるのではないでしょうか。このような構成では、異なる特性を持つトラフィックが単一の物理ネットワークを共有することになるため、トラフィックの特性に合わせた帯域の制御を考慮する必要があります。ESXi ホスト内でトラフィックを制御するための方法として、分散スイッチ(vDS)ではネットワークI/O コントロール(以下NIOC と記載)を提供します。

NIOC は、トラフィックの重要度に応じて使用帯域を制御します。例えば10Gbps の帯域を、NFS, FT, vMotion, 仮想マシンのトラフィックで共有する構成を考えてみましょう。NIOC が無効な環境では、vMotion 実施時に、vMotion のトラフィック(グラフ中の赤線)が他のトラフィックを圧迫します。これにより仮想マシンの提供するサービスに影響が発生し、FT 等遅延に敏感な機能にも影響がでます。

vsphere-nw-part2-02

一方、NIOC が有効な環境では、シェア値に基づいて各トラフィックが制御されるため、vMotion 時にも、FT, NFSといったトラフィックは圧迫されることなく、健全なパフォーマンスを維持します。

vsphere-nw-part2-03

分散スイッチ(vDS)を活用することで、このように広帯域ネットワークを使用する際に必須となるトラフィック管理の機能を実装することができます。NIOC の詳細については、「VMware® Network I/O Control: Architecture, Performance and Best Practices」を合わせてご参照ください。

■ VXLAN を使用しネットワーク仮想化を実装する
VXLAN を使用し、論理ネットワークを展開する際にも、分散スイッチ(vDS)は必須のコンポーネントとなります。VXLAN の論理ネットワーク(vCNS ではVirtual Wire, NSX for vSphere では論理スイッチと呼ばれる)は、分散スイッチ(vDS)上に仮想マシン用ポートグループとして実装されます。また、VXLAN のトンネルを終端するVTEP(VXLAN Tunnel End Point)は、分散スイッチ(vDS)上にVMkernel ポートとして実装されます。

なお、VXLAN の実装のためには分散スイッチ(vDS) の他に、vCNS(vCloud Networking and Security)もしくは、NSX for vSphere が必要となります。下記はNSX for vSphere の論理スイッチを構成する画面となります。

vsphere-nw-part2-06

これらのコンポーネント上で構成をおこなったVXLAN 論理ネットワークが、分散スイッチ(vDS)上に仮想マシン用ポートグループとして動的に展開されます。VXLAN の実装については、ネットワーク仮想化 – VXLAN の設定を合わせてご参照ください。

vsphere-nw-part2-04

さらに、vCloud Automation Center といったCMP(Cloud Management Platform)と連携を行うことで、仮想マシンの展開と同時に必要となる論理ネットワークを動的に作成し、分散スイッチ(vDS)上にポートグループを展開することが可能になります。 ネットワークの仮想化及び、SDDC(Software Defined Data-Center)環境において、分散スイッチ(vDS)は必須のコンポーネントとなります。

次回「押さえておきたいvSphereの基本」ネットワーク編第3回目は、仮想化環境でL3-L7 サービスを提供する 〜vCloud Network and Security編〜 という題目で、vCloud Suiteのコンポーネントとして、ネットワークの上位レイヤーのサービスを提供するvCloud Networking and Security(vCNS)についてご紹介します。

「押さえておきたいvSphereの基本」
~ストレージ編~
1.マニュアル操作でストレージ環境を最適化
2.ストレージと連携してパフォーマンスを最大化
3.優先度の定義付けと自動化

~ネットワーク編~
1.ホスト単位でネットワークを構築する 〜標準スイッチ編〜
2.スケーラブルで高機能なネットワークを構築する 〜分散スイッチ編〜
3.仮想化環境でL3-L7 サービスを提供する 〜vCloud Networking and Security〜

~可用性編~
・物理リソースの有効活用と仮想マシンの最適配置~DRSとリソースプール編~
・システム障害に備える仕組み~vSphere HAとFT編~

押さえておきたいvSphere の基本~ネットワーク編 第1回~

押さえておきたいvSphere の基本」のネットワーク編として、仮想化環境におけるネットワークの基本を3回に分けてご紹介していきます。第一回は一般的な仮想スイッチの役割と機能及び、vSphere Standardエディションで使用できる標準スイッチ(vSphere Standard Switch 以下vSS と表記)について、分散スイッチ(vSphere Distributed Switch 以下vDS と表記)との差異を中心に解説します。

仮想スイッチは、仮想マシンと物理ネットワークを接続するためハイパーバイザ内に作成されたL2 スイッチとして、サーバ仮想化環境での導入が進んでいます。サーバの仮想化に比例して、仮想スイッチの導入も進んでおり、下記のグラフから既に2012 年の時点でデータセンターにおけるアクセスポート(サーバが接続されるスイッチのポート)数で、仮想スイッチの提供するポート数が、物理スイッチの提供するポート数を上回っていることが分かります。

vsphere-nw-part1-01

また、仮想化環境において仮想スイッチは、仮想マシンを最初に接続するネットワーク機器となり、仮想マシンのトラフィックを集約する最初のポイントとなります。このことから、仮想スイッチは単に物理的なネットワークインターフェイスを共有させるだけではなく、下記ネットワーク関連機能の実装に、物理スイッチ以上に最適なポイントということができます。

・ネットワークポリシー(セキュリティ及び帯域制御)の適用
・ネットワーク統計情報の収集
・ネットワークトラフィックのモニタリング

このような背景から、今まで物理スイッチで実装してきた機能の多くを仮想スイッチでも実装してきています。また、パイパーバイザーと同様に集中管理可能であり、x86 ベースの豊富な機能といった仮想化環境特有の特徴を持っています。仮想スッチのアーキテクチャを表したのが下記の図となります。仮想マシンと物理ネットワーク機器の間に入り、ネットワーク機能を提供します。

vsphere-nw-part1-03

仮想マシンは仮想NIC を持ち、IP 及びMAC アドレスは仮想NIC に割り当てられます。この仮想NIC が接続されるのが、仮想スイッチ上にある仮想マシン用ポートグループとなります。物理スイッチと接続されるホスト上の物理NIC は、固有のIP アドレスを持たず トラフィックをバイパスするケーブルと同等の役割となります。この他に、ホスト管理、vMotion、iSCSI、NFS、FCoE、Fault Tolerance、VSAN、などのESXi サービスのトラフィックを処理するためにホスト固有のIP を持つVMkernel ポートがあります。

vsphere-nw-part1-04

なお、ネットワーク仮想化環境で提供されるVXLAN 論理ネットワーク(NSX では論理スイッチ、vCNS ではVirtual Wire と呼ばれる)は、仮想スイッチ上に仮想マシン用ポートグループとして作成されます。また、VXLAN トンネルを終端するVTEP(VXLAN Tunnel End Point)の実態はVMkernel ポートであり、VXLAN 構成時にVMkernel ポートが自動的にホスト上に作成されます。

VMware vSphere の実装では2種類の仮想スイッチがあります。vSphere Standard エディションで使用可能なホスト単位のネットワークを提供する標準スイッチ(vSS)、vSphere Enterprise Plus エディションで使用可能なデータセンター単位のネットワークを提供する分散スイッチ(vDS)です。ホスト単位でネットワークを構成し、分散スイッチ(vDS) が有する機能を使用する要件がない場合は標準スイッチ(vSS)のみで構成をとることが一般的です。L2 スイッチに求められる基本的なVLAN 機能や、標準的なチーミングを標準スイッチ(vSS)を用いて実装することが可能となります。

VLAN 構成及び設定については、「VLAN configuration on virtual switches, physical switches, and virtual machines (1003806)」、チーミング構成及び設定については、「NIC teaming in ESXi and ESX (1004088)」に解説があります。標準スイッチ(vSS)、分散スイッチ(vDS)の機能については下記表を参照ください。

vsphere-nw-part1-05

表の中で、(5.1)等の括弧内に書いてある番号が、新機能として実装されたvSphere のバージョンとなり、水色のセル部分が分散スイッチ(vDS)固有の機能となります。特に管理、トラフィック制御、及びネットワーク仮想化に伴い必要とされる各種機能が分散スイッチ(vDS)に実装されており、下記のような要件がある場合には分散スイッチ(vDS)の実装が適していると言えます。

・複数のホストで使用するネットワークを効率的に管理する
・広帯域ネットワーク(10G 以上)に各種トラフィックを集約して使用する
・ネットワーク仮想化(VXLAN ネットワーク)の展開を予定している

次回「押さえておきたいvSphereの基本」ネットワーク編第2回目は、スケーラブルで高機能なネットワークを構築する 〜分散スイッチ編〜 という題目で、上記ポイントを中心にお送りします。

「押さえておきたいvSphereの基本」
~ストレージ編~
1.マニュアル操作でストレージ環境を最適化
2.ストレージと連携してパフォーマンスを最大化
3.優先度の定義付けと自動化

~ネットワーク編~
1.ホスト単位でネットワークを構築する 〜標準スイッチ編〜
2.スケーラブルで高機能なネットワークを構築する 〜分散スイッチ編〜
3.仮想化環境でL3-L7 サービスを提供する 〜vCloud Networking and Security〜

~可用性編~
・物理リソースの有効活用と仮想マシンの最適配置~DRSとリソースプール編~
・システム障害に備える仕組み~vSphere HAとFT編~

vSphere 5.5 の新機能紹介 ネットワーク2 (トラフィックのフィルタリングとマーキング)

このBlogは、製品出荷前バイナリ及びマニュアルをベースに記載しています。出来る限り正確な情報をお伝えするよう努めておりますが、実際に製品に搭載される機能や表示と異なる可能性があります。あらかじめご了承の上ご利用下さい。

今回は先日発表されましたVMware vSphere 5.5 で追加されたネットワークの新機能のなかから、トラフィックのフィルタリングとマーキングの概要をご紹介します。vSphere 5.5 では、分散仮想スイッチ(vDS)のポートグループレベルでトラフィックのフィルタリングとマーキング機能を実装します。フィルタリング機能は、物理スイッチのアクセスコントロールリスト(ACL)に相当するものとなり、パケットヘッダに基づいてトラフィックをコントロールしセキュリティを確保します。マーキング機能は、重要なトラフィックにタグ付けを行い、付与されたタグをもとに物理ネットワーク上でトラフィックを優先制御することで、End-to-End でサービス品質を確保します。

 

■特徴
・分散仮想スイッチ(vDS)のポートグループ単位で設定を行います。
・対象となるトラフィックを、MACアドレス、IPアドレス/プロトコルタイプ/ポート番号 、システムトラフィックから指定します。
・入力または出力、あるいはその両方をフィルタリング対象として選択します。
・マーキングでは、Differentiated Service Code Point (DSCP)、及び802.1p Class of Service (CoS)で定義されたタグを付与できます。
・仮想マシンにより近いポイントとなる分散仮想スイッチでフィルタリング及びマーキングを行うことで、End-to-End でのセキュリティとサービス品質を確保します。


なお、VXLAN 環境で付与されたDSCP タグは、オリジナルのIPヘッダからVXLAN でカプセル化した際に付加されるIPヘッダにコピーされるため、物理ネットワーク上でタグを認識し優先制御を実施することが可能です。


下記のキャプチャから、両方のIPヘッダ内にDSCP タグがセットされていることが確認できます。


■設定
「ネットワーク」で適用する「ポートグループ」を選択し、「管理」-「設定」-「ポリシー」画面で、「編集」を選択します。ポートグループの設定画面で、「トラフィックのフィルタリングとマーキング」を選択します。ステータスを有効にし、ルールを追加します。


フィルタリングを実施する場合は、「許可」もしくは「ドロップ」を選択します。マーキングを行う場合は、「タグ」を選択します。


タグを選択した場合、CoS もしくは、DSCP の値をセットします。


フィルタリングもしくはマーキングの対象となるトラフィックを指定します。


システムトラフィック、MACアドレス、IPアドレスの詳細を定義します。システムトラフィックでは、あらかじめ定義されたトラフィックを選択します。


以上、vSphere 5.5 のトラフィックのフィルタリングとマーキングの概要をご紹介いたしました。

vSphere 5.5 の新機能紹介 ネットワーク1 (ホストレベルのパケットキャプチャ)

このBlogは、製品出荷前バイナリ及びマニュアルをベースに記載しています。出来る限り正確な情報をお伝えするよう努めておりますが、実際に製品に搭載される機能や表示と異なる可能性があります。あらかじめご了承の上ご利用下さい。

今回は先日発表されましたVMware vSphere 5.5 で追加されたネットワークの新機能のなかから、ホストレベルのパケットキャプチャの概要をご紹介します。vSphere 5.5 では、ホストレベルのパケットキャプチャ機能を新たに実装します。この機能によりトラブルシューティング時に必要となるパケットキャプチャにより詳細なオプションが提供されます。

 

■特徴
・ESXi ホスト上で、CLI からpktcap-uw コマンドでパケットキャプチャを実施します。vSphere Client、Web Client からは使用できません。
・標準仮想スイッチ(vSS) 及び分散仮想スイッチ(vDS)上のトラフィックをキャプチャすることが可能です。
・Uplink, 仮想スイッチポート, vmk NIC で発生するトラフィックに対し、キャプチャするポイントを指定することが可能です。

 

■オペレーション
・ヘルプを表示
# pktcap-uw –help

・各種オプション
-p, –port <Socket PORT>  Specify the port number of vsocket server.
-o, –outfile <FILE>  Specify the file name to dump the packets. If unset, output to console by default
-P, –ng (only working with ‘-o’) Using the pcapng format to dump into the file.
–console (by default if without ‘-o’) Output the captured packet info to console.
-s, –snaplen <length> Only capture the first <length> packet buffer.
-c, –count <NUMBER> How many count packets to capture.
-h Print this help.
-A, –availpoints List all capture points supported.
-F List all dynamic capture point functions supported.
–capture <capture point> Specify the capture point. Use ‘-A’ to get the list. If not specified, will select the capture point by –dir and –stage setting

・ポートオプション
–switchport <port ID> (Specify the switch port by ID)
–lifID <lif ID> (Specify the logical interface id of VDR port)
–vmk <vmk NIC> (Specify the switch port by vmk NIC)
–uplink <vmnic> (Specify the switch port by vmnic)

–switchportを使用する場合、esxtopの n オプションで対象のポートIDを確認します。


・キャプチャポイント
pktcap-uw –A コマンドで、サポートされるキャプチャポイントを表示します。キャプチャポイントは、–capture で指定することができます。キャプチャポイントの中にはポートオプションの指定やキャプチャポイントオプションの指定が必須のものがあります。なお、Dropを指定することで、ESXi でドロップしたパケットを収集することが可能です。
# pktcap-uw -A
Supported capture points:
1: Dynamic — The dynamic inserted runtime capture point.
2: UplinkRcv — The function that receives packets from uplink dev
3: UplinkSnd — Function to Tx packets on uplink
4: Vmxnet3Tx — Function in vnic backend to Tx packets from guest
5: Vmxnet3Rx — Function in vnic backend to Rx packets to guest
6: PortInput — Port_Input function of any given port
7: IOChain — The virtual switch port iochain capture point.
8: EtherswitchDispath — Function that receives packets for switch
9: EtherswitchOutput — Function that sends out packets, from switch
10: PortOutput — Port_Output function of any given port
11: TcpipDispatch — Tcpip Dispatch function
12: PreDVFilter — The DVFIlter capture point
13: PostDVFilter — The DVFilter capture point
14: Drop — Dropped Packets capture point
15: VdrRxLeaf — The Leaf Rx IOChain for VDR
16: VdrTxLeaf — The Leaf Tx IOChain for VDR
17: VdrRxTerminal — Terminal Rx IOChain for VDR
18: VdrTxTerminal — Terminal Tx IOChain for VDR
19: PktFree — Packets freeing point

・キャプチャポイントオプション
Dynamic, IOChain, TcpipDispatch といったキャプチャポイントでは、パラメータを追加し対象を指定します。
-f [module name.]<function name> The function name. The Default module name is ‘vmkernel’. (for ‘Dynamic’, ‘IOChain’ and ‘TcpipDispatch’ capture points)
–dvfilter <filter name> Specify the dvfilter name for DVFilter related points

・キャプチャポイントの簡易選択
–capture でキャプチャポイントを指定しない場合、トラフィックの方向(送信もしくは受信)を–dirで指定し、キャプチャするポイントを–stage で指定することができます。これらのオプションは、–switchport, –vmk, –uplink といったポートオプションと合わせて使用します。なお1つのモニタセッションで、送受信両方向のトラフィックの取得はできません。
–dir <0|1> (for –switchport, –vmk, –uplink) The direction of flow: 0- Rx (Default), 1- Tx
–stage <0|1> (for –switchport, –vmk, –uplink, –dvfilter) The stage at which to capture: 0- Pre: before, 1- Post:After

–dir で指定する際、トラフィックは仮想スイッチを基点とした方向となります。そのため–dir 1 でTx(送信)を指定した場合でも、ポートオプションによってキャプチャできる通信の方向が異なります。例えばポートオプションで、–uplink を指定した場合はホストの外部に向かって出て行くトラフィックとなり、–switchport 及び–vmk を指定した場合は、外部から入ってくるトラフィックをキャプチャすることになります。



・フィルターオプション
フィルターを適用することで特定のトラフィックを収集できます。
–srcmac <xx:xx:xx:xx:xx> (The Ethernet source MAC address)
–dstmac <xx:xx:xx:xx:xx> (The Ethernet destination MAC address)
–mac <xx:xx:xx:xx:xx> (The Ethernet MAC address(src or dst))
–ethtype 0x<ETHTYPE> (The Ethernet type. HEX format)
–vlan <VLANID> (The Ethernet VLAN ID)
–srcip <x.x.x.x[/<range>]> (The source IP address)
–dstip <x.x.x.x[/<range>]> (The destination IP address)
–ip <x.x.x.x> (The IP address(src or dst))
–proto 0x<IPPROTYPE> (The IP protocol)
–srcport <SRCPORT> (The TCP source port)
–dstport <DSTPORT> (The TCP destination port)
–tcpport <PORT> (The TCP port(src or dst))
–vxlan <vxlan id> (The vxlan id of flow)

 

■実行例
それぞれ、vmk NIC、仮想スイッチのポート、Uplink で取得する例を以下に記載します。

1. vmk NICで取得
vmk1 から外部に送信(仮想スイッチから見ると受信)する60個のパケットをキャプチャしファイルに保存する例
# pktcap-uw –vmk vmk1 –dir 0 -c 60 -o test01.pcap

2. 仮想スイッチのポートで取得
仮想スイッチのポートで受信する宛先172.16.161.234のパケットをキャプチャしファイルに保存する例(Port ID XXXXXXXX は、esxtop のn オプションで確認を行います)
# pktcap-uw –switchport XXXXXXXX –dir 0 –dstip 172.16.161.234 -o test02.pcap

3. Uplink で取得
vmnic1 から外部に送信するVXLAN カプセル化前のパケットをキャプチャしファイルに保存する例
# pktcap-uw –uplink vmnic1 –dir 1 –stage 0 -o test03.pcap

4. Uplink で取得
vmnic1 から外部に送信するVXLAN カプセル化後のパケットをキャプチャしファイルに保存する例
# pktcap-uw –uplink vmnic1 –dir 1 –stage 1 -o test04.pcap

 

■キャプチャしたパケットの確認
キャプチャしたパケットをローカルにダウンロードし、WireShark 等のネットワークプロトコルアナライザで中身の確認を行うことができます。SCP 等でESXi からキャプチャしたファイルをダウンロードします。


ダウンロードしたファイルをWireShark で開きます。下記のケースでは、実行例3(Uplink で取得)でキャプチャしたICMP パケットが確認できます。


下記のケースでは、実行例4(Uplink で取得)でキャプチャした、VXLAN でカプセル化されたパケットが確認できます。VXLAN でカプセル化されたパケットの中身を確認する際は、WireShark で「Decode As」を選択し、UDP Destination port 8472 をVXLAN でデコードします。(vSphere 5.5 のVXLAN 実装では、デフォルトでUDP port 8472 を使用します)


VXLAN ヘッダーを認識し、カプセル化されたオリジナルのパケット(ICMP)を確認できるようになります。


以上、vSphere 5.5 のホストレベルのパケットキャプチャの概要をご紹介いたしました。