Home > Blogs > Japan Cloud Infrastructure Blog > 月別アーカイブ: 2015年6月

月別アーカイブ: 2015年6月

ネットワーク仮想化をネットワークの基本から理解する 〜第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 の世界(本稿)

vSphere 問題解決までのヒント!- 第2回 サポートリクエスト(SR)と情報採取

テクニカルサポートエンジニアのMarieです。

前回はトラブル発生時に役に立つリソースを紹介しました。
今回はサポートリクエスト(SR)と、調査に必要な情報採取についてお話していきます。

第1回 トラブル発生時に役立つ 4 つのリソース
第2回 サポートリクエスト(SR)と情報採取 ←This Post
第3回 実践編

VMware vSphereは、単なるサーバー仮想化ソフトではありません。
仮想化環境の包括的な管理・運用に対応した仮想化基盤であり、いわば仮想的なデータセンターです。
ストレージ、ネットワーク、ハードウェア、OS… 全てと関わりがありますのでトラブルシューティングが難しく感じるかもしれません。
しかし、状況をすばやく切り分け・整理して、必要な情報を揃えることができれば、調査はスムーズに進みます。
今回はそのために押さえていただきたいポイントをお話します。

1. 事象の伝え方

まず「どのような事象を問題だと考えているのか」をサポートエンジニアに伝える必要があります。
これが基本にしてとても難しい…のですが、いくつかのポイントを意識するだけでぐっとわかりやすい説明になります。

例えば以下の説明、とてもぼんやりしていますね。
私がこのSRを担当するとしたら、調査にとりかかる前にかなりのヒアリングが必要だと感じます。

サーバにハングが発生したようです。不具合の事例などありますでしょうか。

これをもう少しわかりやすく、状況が伝わりやすい説明に変えてみたいと思います。
サポートリクエスト発行ガイドという資料の中でテンプレートの使用をおすすめしておりますので、これも活用します。

VMware サポートリクエスト発行ガイド
http://campaign.vmware.com/imgs/apac/jp_dwn/PDF/support-SR_guide.pdf

– [1. ご担当者名]

ヴイエムウェア株式会社 Saito

– [2. サイト・システム名]

検証環境

– [3. 問い合わせ概要]

特定の仮想マシンがハングしました。

– [4. 業務影響]

すでに復旧しているため影響ありません。

– [5. 利用環境]

vCenter Server 5.5U2 Build 2183111
ESXi 5.5U2 Build 1892794 ×1
仮想マシン:Windows Server 2008R2×2, RHEL 6.3×2

– [6. 発生契機/日時/頻度]

6月10日 14:30から14:35頃

– [7. 貴社での切り分け調査内容]

特定の仮想マシン(win1,rh1)がハングしました。※1

6月10日14:30頃、RDP で GuestOS に接続して作業を行っていたのですが画面が動かなくなりました。
監視ツールからの ping にも応答が無かったようで、アラートもあがっていました。※2

事象が発生した仮想マシンの GuestOS は Windows Server と RHEL 各1台ずつで同じデータストア上で稼動しています。
他のデータストアで稼動している仮想マシンについては RDP 接続しておりませんが、監視ツールからのアラートはありませんでした。※3

詳細は不明ですが正午から15時頃までネットワーク機器のメンテナンスが行われていました。※4

14:35頃には自然に復旧し、現在は問題なく動作しております。※5

– [8. サポート調査依頼内容]

メンテナンスの影響と考えておりますが、念のため確認をお願いします。
それ以外に不具合の事例などありましたらお知らせ下さい。

– [9. 送付資料]

vcsupport,vmsupport(VMware-vCenter-support-2015-06-09@19-23-44.zip)
イベントログ(ExportEventsLog_user.csv,ExportEventsLog_system.csv)

※ポイント1
「サーバ」だと ESXi なのか vCenter Server なのか仮想マシンなのかはっきりしませんね。
仮想マシン名も特定できているので具体的に明記しました。

※ポイント2
どのような事象を「ハング」だと言っているのか、どのように確認したのかを説明しました。
今回の場合は「 RDP している時に画面が動かなくなった」ということと「監視ツールからの ping に応答が無かった」ということを「ハング」だと言っています。

※ポイント3
事象が発生している対象と、発生していない対象の違いについてわかることを説明しました。
この情報だけで「GuestOS 依存の問題ではなさそう」「ESXi-データストア間の接続に問題がありそう」ということが推測できます。

※ポイント4
詳細はわからないながらも、トリガーと考えられる情報を共有しました。
データストアが NFS や iSCSI 接続のストレージで構成されていればこのメンテナンスの影響があるかもしれませんね。

※ポイント5
現在の状況を説明しました。
何をしたら直ったのかという情報が、問題箇所を絞り込むヒントになることがあります。
今回は何もしなくても復旧したので「設定や構成の問題というよりは一時的な問題ではないか」ということが推測できますね。

いかがでしょうか。
元々の説明よりも、調査のヒントになる情報が増えたと思います。
文章だと書きづらいという場合は箇条書きでもかまいませんので、なるべくポイントを押さえて整理してみて下さい。

・事象の概要
・事象をどのように確認したか
・事象が発生/復旧したタイミング、事象発生のトリガー
・事象が発生している対象と発生していない対象の違い
・ESXi名、仮想マシン名など
・時系列や作業手順

時系列や作業手順については、説明に加えて時間の見えるスクリーンショットも送付いただけると、とてもわかりやすくて助かります。

2. ログの採取方法

事象を整理することができたら、調査に必要なログを採取します。
情報採取を依頼されてからログを取得したらすでにローテートされていた…ということもありますので、なるべく早めに取得しておくことをおすすめします。
vSphereのトラブルでは基本的に以下のログを取得していただいています。

・ESXiのログバンドル(vmsupport)
・vCenter Server のログバンドル(vcsupport)
・vCenter Serverのイベントログ

色々な採取方法があるのですが、今回は以下の方法について説明します。
ログをエクスポートし、操作している端末のデスクトップに持ってくることがゴールです。

・ESXi、vCenter Serverのログバンドルの採取方法(Web Client経由)
・vCenter Serverのイベントログの採取方法(Web Client経由)
・ESXiのログバンドルの採取方法(SSHクライアント経由)

ESXi、vCenter Serverのログバンドルの採取方法(Web Client経由)

vCenter Server にログインします。

supportblog2_1a

ホーム画面から [vCenter Server] を選択します。
[vCenter Serverホーム] 画面に遷移します。

supportblog2_1b

[インベントリリスト] から [vCenter Server] を選択します。

supportblog2_1c

[該当のvCenter Server] を選択します。
今回は vc55.mylab.local というvCenter Server からログを取得します。

supportblog2_1d

[該当のvCenter Server] 画面に遷移したら、[監視]タブ – [システムログ] を選択し、[システムログのエクスポート] を押下して下さい。
ここからログバンドルをエクスポートすることができます。

supportblog2_1e

[ログのエクスポート] 画面がポップアップされます。
[フィルタ] タブにはこのvCenter Server が管理しているESXiが表示されますのでログが必要なESXiにチェックを入れて下さい。
今回は、vCenter Server、このvCenter Serverが管理しているの192.168.1.3というESXi、Web Clientのログを取得する設定になっています。
チェックができたら [次へ] で先に進みます。

supportblog2_1f

[ログバンドルの生成] を選択します。

supportblog2_1g

生成中…少し待ちます。

supportblog2_1h

ログが生成されました。
[ログバンドルのダウンロード] を選択して端末にダウンロードします。

supportblog2_1i

あとはブラウザで、お好きな場所に保存すれば完了です。
今回はデスクトップに置くことにします。

supportblog2_1j

できました!

supportblog2_1k

vCenter Serverのイベントログの採取方法(Web Client経由)

続けてイベントログを取得してみます。
ログバンドルを取得した [該当のvCenter Server]画面 – [監視]タブで、今度は [イベント] を選択します。
[ホーム]画面 – [イベントコンソール] からでも同じことができます。
画面右下のマークを押下して下さい。

supportblog2_2a

[イベントのエクスポート]画面がポップアップします。
[タイプ:] は [システム] に設定していますが、同じ手順で [ユーザー] でも取得して下さいね。
[開始時間] [終了時間] は事象が発生した時間帯を含まれるように設定します。
[CSVレポートの生成] を押下します。

supportblog2_2b

生成できました。
[保存] で先に進みます。

supportblog2_2c

あとはブラウザで、お好きな場所に保存しましょう。

supportblog2_2d

できました!

supportblog2_2e

ESXiのログバンドルの採取方法(SSHクライアント経由)

ESXiに直接ログインしてESXiのログバンドルを取得する方法を説明します。
ESXiのログだけ取得したい時や、vCenter Serverから管理できない状態になっている時などはこの方法がよいと思います。

今回はESXiにSSHでログインしてログを取得します。

ESXiにSSHで接続しログインし、vm-supportコマンドを実行します。

supportblog2_3a

ログバンドルの生成が完了しました。

supportblog2_3b

var/tmp 以下にファイルが作成されています。

supportblog2_3c

今回はSSHクライアントのSCP機能を使用して端末のデスクトップに送りました。
完了です!

supportblog2_3d

「1.事象の伝え方」の内容と重複しますがログと一緒に必ず送っていただきたいのが、「ログを調査するための情報」です。
「ログがあれば何でもわかるでしょ!」と思われるかもしれませんが、vSphereのログは膨大ですのでこれを全て精査するのは人間には難しい作業です。
時間帯やコンポーネントを絞って確認する必要がありますので、是非ご協力をお願いします。

・作業手順(文章による説明やスクリーンショットで)
・時刻、時系列(文章による説明やスクリーンショットで)
・事象が発生しているESXiや仮想マシンの名前

■参考になるKB

* VMware KB: Collecting diagnostic information for VMware vCenter Server 4.x, 5.x and 6.0 (1011641)
http://kb.vmware.com/kb/1011641
vCenter Serverのログの取得方法がまとめられています。

* VMware KB: Collecting diagnostic information for ESX/ESXi hosts and vCenter Server using the vSphere Web Client (2032892)
http://kb.vmware.com/kb/2032892
Web Clientを使用してログを取得する方法が説明されています。

* Collecting diagnostic information using the vm-support command in VMware ESX/ESXi (1010705)
http://kb.vmware.com/kb/1010705
ESXiからコマンドでログを取得する方法が説明されています。

長くなりましたが、ひとつひとつの作業はそれほど難しくないと感じていただけたのではないかと思います。
ここまできちんと揃えていただければ、スムーズに調査が進むはずですので、お問い合わせの際ご活用下さい。

弊社サポートセンターへはMyVMwareからお問い合わせいただけます。

MyVMware
https://my.vmware.com/web/vmware/login

SRの発行方法やデータのアップロード方法については、以下のガイドが公開されております。

VMware サポートリクエスト発行ガイド
http://campaign.vmware.com/imgs/apac/jp_dwn/PDF/support-SR_guide.pdf

「なるべく早く、正確に、問題を解決したい」という気持ちは、お客様もサポートエンジニアも同じです。
うまくコミュニケーションを取って問題を解決しましょう!

第1回 トラブル発生時に役立つ 4 つのリソース
第2回 サポートリクエスト(SR)と情報採取
第3回 実践編

第1回ではトラブル発生時に確認しておきたい情報と、確認の方法についてお話しました。
お客様自身で解決できる問題もあったかと思いますし、解決まではたどりつけなくても問題がどこにあるのかの切り分けや状況の整理ができたかと思います。
第2回、今回はお問い合わせいただくときに意識していただきたいポイントや情報採取についてお話しました。
ここまでで、トラブル発生~お客様自身でのトラブルシューティング~お問い合わせ の基本的な流れをイメージしていただけましたでしょうか。
次回は具体例を上げながら、実際問題が発生した時にはまりやすいポイントについてお話します。

Virtual Volumesに国内最速対応 NEC iStorage 御紹介

みなさま、こんにちは。
NEC iStorage により、国内最速でVMware vSphere Virtual Volumesにご対応頂きました。今回は、Virtual VolumesとiStorageによる対応機能及びメリットについて  日本電気株式会社  ITプラットフォーム事業部  猪鹿倉 知広様  にご執筆頂きましたので御紹介させて頂きます。

VMware vSphere Virtual Volumesで変わる仮想化環境

< はじめに >

現在の仮想化環境が抱えるさまざまな問題を解決する、画期的な技術として注目されているVMware vSphere Virtual Volumes(以下、Virtual Volumes)。
2015年2月3日にVMware vSphere 6.0の新機能として正式発表され、仮想マシンとサーバ・ストレージのより緊密な連携によるパフォーマンス上昇、効率的な運用の実現が期待されています。NECはVMwareのパートナーとして、Virtual Volumesの実装に向けて早期から協調し、対応ストレージをいち早くお届けすることができました。

Virtual Volumesの概念自体は非常にシンプルです。仮想マシンが使用するデータ領域を、新たな共通単位『仮想ボリューム(VVOL)』として、ストレージ側とサーバ側で共通認識させようという試みです。

仮想マシンとVVOLが1対1の対応になるので、サービスレベルに従い、ポリシーを選択して仮想マシンが利用するストレージを決めることができます。さらに、ストレージ製品で提供している多様な機能が仮想マシン単位で利用可能になることで、簡単運用が実現されます。

今回の記事では、Virtual VolumesとNEC iStorageによって実現するソリューションを簡単にご紹介します。

< Virtual Volumesを利用している環境でのNEC iStorageソリューション >

NEC ストレージ iStorage Mシリーズ ではVirtual VolumesとしてVMwareが提唱する機能だけでなく、Virtual Volumesを利用している環境をより効果的に利用するためのソリューションを準備しております。“NECならでは”と言えるVirtual Volumes連携機能の一部をご紹介いたします。

vVOL02

ストレージポリシーによる仮想マシンの簡単運用

Virtual Volumesを利用している環境におけるストレージが、仮想マシンごとに設けられた仮想ボリューム(VVOL)を個別に認識できることにより、仮想マシン単位で仮想ボリュームの運用・管理を行うことができます。サーバ管理者は新規仮想マシンを作成する際に、『ストレージポリシー』を選択するだけで、簡単にVVOLを生成することができます。このストレージポリシーとは、「GOLD」、「SILVER」などの名称で、ストレージの性能、重要度、各種機能の使用有無などの情報を設定し、あらかじめ数種類用意しておくテンプレートです。

vVOL03

この、「GOLD」や「SILVER」などのストレージポリシーとして、ストレージの持つ様々なVirtual Volumes連携機能を紐付けることができます。

1)    仮想マシン単位での「I/O流量制御」機能   iStorage IO Load Manager

サーバ仮想化、ストレージ仮想化を進めていくことにより、1つのストレージに複数の仮想マシンがアクセスすることになります。このような環境において、高負荷をかけた仮想マシンの影響で、重要度の高い業務レベルの仮想マシンの処理を滞らせるようなことを防ぐために、一定以上の性能を担保する機能が「I/O流量制御機能」です。一般的なI/O流量制御は、I/O流量の“上限値”を設定します。そして上限以上の負荷がかけられた場合に、その過剰負荷をかけた仮想マシンのI/O流量を制限することで、他の仮想マシンへの影響が出ないようにします。さらにNECのI/O流量制御では、“下限値”を設定することができます。重要度の高い仮想マシンのI/O流量が一定値以下にならないように、他のマシンのI/O流量を制御し、重要度の高いマシンの性能を担保します。こうしてシステム全体を安定稼働させるために、重要度に応じた、より一層きめ細かい対応を採ることができます。

vVOL04

2)   仮想マシン単位でデータの自動最適配置  iStorage PerforOptimizer

ストレージは、SSD、SAS HDD、ニアラインSAS HDDなどのように、いくつかの性能の異なる物理ディスクから構成されています。頻繁にアクセスされるデータと、まれにアクセスされるデータが、同じ高性能・高価格のデバイスに格納されていては非効率です。そこで、アクセス頻度に応じてデータを最適なディスク領域に自動配置するのが、「データ自動最適配置」機能です。各データファイルは、単純なアクセス回数だけでなく、転送量やアプリケーション特有のアクセスパターン(ランダム/シーケンシャル、リード/ライト)を時間単位で分析し、NEC独自のアルゴリズムにより自動的に再配置される仕組みです。ここにもNECならではのノウハウが生かされています。

vVOL05

I/O流量制御機能の上限値/下限値や自動最適配置の物理ディスクの容量比を、「GOLD」や「SILVER」などのストレージポリシーとしてあらかじめ登録しておくことができます。VVOL領域作成時には、お客様はストレージポリシーを選択するだけで、同一のストレージプールから用途に応じた最適なデータ領域を割り当てることができます。そして、お客様は特に意識しなくても、ストレージ性能の最大化の追求と、ストレージコストの最適化が、自動的に実現できるのです。

バックアップ/リストア機能の活用

1)   DirectDataShadow(DDS)

DDSは、iStorage HSシリーズとiStorage Mシリーズを直接接続し、サーバレスでの多世代バックアップを可能にする技術です。

仮想化環境では高速なバックアップが求められるうえ、多世代のバックアップを保存しておく必要もあります。それには、iStorage HSシリーズのように、バックアップに特化した安価・大容量のストレージを活用することが効果的です。しかし、通常のバックアップシステム構成では、バックアップサーバとバックアップソフトが必要なため、その導入/運用コストがかかってしまいます。このDDSソリューションではそれを解決するため、バックアップサーバ/ソフト不要のシンプルな構成でのバックアップ環境を実現しました。データ圧縮のための重複削除機能も備えており、クローン作成時などではバックアップ容量を削減できるほか、差分バックアップも可能です。バックアップ用のiStorage HSシリーズは、近接地にも遠隔地にも設置可能なので、低価格で簡便に災害対策用のバックアップシステムを構築できるうえ、運用管理コスト、通信コストを削減することができます。

vVOL06


もっと詳しくという方は

詳しくはNECのサイトでホワイトペーパーを公開しておりますので、こちらにも是非お越しください。
http://jpn.nec.com/istorage/whitepaper/index.html

NECの仮想化への取り組み

最後に、NECの仮想化への取り組みをご紹介します。
vVOL07
NECは、2002年より他社に先駆けて業界最大手であるVMwareとパートナーシップを結び、仮想化に最適なPCサーバ製品Express5800シリーズやストレージ製品iStorage Mシリーズなどの製品・ソリューション開発をしてきました。世界で最も広く導入されているサーバ仮想化ソフトウェアVMware vSphereとの親和性を高める連携機能開発にも注力し、2009年以降、Storage Replication Adapter、VMware vSphere APIs-Array Integration機能などを提供しております。今回リリースされたVMware vSphere 6.0での新機能Virtual Volumesも、開発中のβ(ベータ)版より先行評価を開始1し、VMware社のVMware vSphere 6.0リリースに併せて対応ストレージとして認証を取得しました。2

※1. vSphere Virtual Volumesのβ認証テストを取得した企業は、グローバルでNECを含めた6社のみ。
※2. 2015年3月12日、NECは国内最速でVMware vSphere Virtual Volumes認証を取得。

ESXi 6.0 パッチ適応に関して

はじめに

VMware vSphere 6.0 がリリースされて3ヶ月ほど経ちますが、2015年6月11日現在、ESXi 6.0 に対して2つのパッチが出ています。このパッチ適応に関して、いくつかトラブルが報告されているようですので、今回の Blog では安全なパッチ適用方法をご案内します。なお、このパッチ適応方法は恒久的な物ではなく、あくまで現存する問題を回避するための手法を示す物ですのでご了承下さい。

https://my.vmware.com/group/vmware/patch#search

 

確認している問題

 HP 社の Gen9 サーバに、HP 社の提供する Custom イメージでESXi 6.0をインストールした後、VMware 提供のパッチ(ESXi600-201505001 / 04001)を当てるとリブート後ローカルディスクが見えなくなる。

 ローカルディスクが見えなくなる現象が確認されているのは、現在HP 社の Gen9 サーバですが、影響の差はあれ、他のOEMのカスタムイメージでも何かしらの不具合が発生する可能性があります。不意に VMwareのドライバに置き換わってしまう可能性があるためです。

 OEM カスタムイメージ一例はこちら(VMware のサイトで提供分)

 ※各 OEM サイトにて提供されているカスタムイメージも同様です。

  元々 VMware 提供のバイナリでインストールを実行し、ドライバを変更していない場合はこの限りではありません。

 

詳細

コマンドラインにてパッチ適応を行う場合、通常以下のコマンドを利用しますがこの場合発生します。

 esxcli software profile update -d <path>/ESXi600-xxxx.zip -p <profile-name>

本来パッチ適応には利用すべきでなはいコマンドですが、以下のコマンドでも発生します。

 esxcli software vib update -d <path>/ESXi600-xxxx.zip

関連KB

http://kb.vmware.com/kb/2110557

 

原因

 ESXi 6.0 で各 OEM が提供するESXi 6.0のカスタムイメージの中には、VMware 提供のパッチに含まれるドライバより “バージョンが古いと認識される物” が含まれます。例えば、HP 社のカスタムイメージに対し、上記コマンドで VMware 提供のパッチを適応すると、以下のドライバがVMware の物と置き換わります。

  ・scsi-hpsa 5.5.0.84-1OEM.550.0.0.1331820 —–> 6.0.0.44-4vmw.600.0.0.2494585

  ・qlnativefc 1.1.39.0-1OEM.550.0.0.1331820 —–> 2.0.12.0-5vmw.600.0.0.2494585

  ・scsi-mpt2sas 15.10.06.00.1vmw-1OEM.550.0.0.1198610 —–> 19.00.00.00-1vmw.600.0.0.2494585

 scsi-hpsaのドライバが置き換わる影響で、Gen9サーバでは、リブート後ローカルディスクが見えなくなります。

 

 HP社推奨のドライバリストはこちらです。

http://vibsdepot.hp.com/hpq/recipes/HP-VMware-Recipe.pdf

※通常、OEMのカスタムイメージに含まれるドライバ群は、VMware提供のパッチよりドライババージョンが新しいため、update オプションを指定してコマンドを実行すれば置き換わってしまうことはないのですが、今回のESXi 6.0 のOEMカスタムイメージ場合はドライババージョンが古い物が含まれているためこの様な問題が起こります。

回避方法

 パッチの中から、必要なモジュールのみインストールします。今回の、ESXi600-201504001 及び、 ESXi600-201505001 の場合は、esx-base のみ更新されていますので、以下のコマンドで、esx-base のみ更新してください。

 

 esxcli software vib install -d <path>/ESXi600-201504001.zip -n esx-base

 

パッチにてアップデートされたモジュールに関しては、こちらを参照いただき、必要なモジュールのアップデートをお願いできれば幸いです。


VMware ESXi Patch Tracker

https://esxi-patches.v-front.de/

ご迷惑おかけして誠に申し訳ありませんが、上記ご認識のほどよろしくお願いします。

 

 

電源投入から15分で仮想マシンを立ち上げ! EVO:RAIL 最新情報         6/18には大阪でセミナー開催!

昨年のVMworld 2014で発表した、VMware 初のHyper Converged Infrastructure Appliance (HCIA) EVO:RAIL 。発表から約10ヶ月が経ち、日本でも多くのお客様に、ご興味を持っていただくようになりました。また、お寄せいただいた様々なお客様の声を踏まえ、EVO:RAIL 自体も機能拡張を行い、進化してきました。この記事では今一度EVO:RAIL の特徴をお伝えするとともに、EVO:RAIL 発表から現在までのアップデートをまとめて紹介したいと思います。

ところで、EVO:RAIL 等のConverged Infrastructure は、なぜ今注目されているのでしょうか? 読者のみなさまの中には、企業のIT部門でITインフラを担当されている方も多いかと思いますが、限られたIT予算の下、管理者不足、遠隔地の管理者不在などで、できるだけサーバーやストレージなどIT インフラのコストを削減し、運用管理を簡単したいと思われている方も多いのではないでしょうか? また、今まで以上にシステムの構築にかけられる時間を短縮する必要性に直面されていませんか? これらは、まさにEVO:RAIL が解決できる課題です。 こちらに、Converged Infrastructure を選択した場合のベネフィットについて、お客様の声が紹介されています。上位から3つ取り上げると、以下のようになります。

  1. プロビジョニング時間の短縮
  2. サービス、サポートの向上
  3. 管理が容易

Converged Infrastructure を選択いただくことにより、このようなベネフィットを享受いただくことはできますが、EVO:RAIL はこれらをさらに高いレベルで提供できます。たとえば、初期構築作業は電源を投入してからたった15分間で完了し、すぐに仮想環境をご利用いただく事ができるようになります。仮想スイッチや、ストレージの設定、vCenter Server のインストール等、通常仮想環境を構築する際に必要な作業も、お客様は初期段階で、いくつかの必要なパラメータを入力いただければ、後は全自動でEVO:RAIL エンジンが最適なvSphere 環境を構築してくれます。これは時間短縮だけではなく、仮想環境構築の手間を大幅に削減できるとともに、あまりノウハウをお持ちでない方でも簡単に環境構築ができるようになります。

EVO:RAIL は複数のEVO:RAIL 認定パートナー様から提供されますが、サポートに関しても提供元の認定パートナー様からハード、ソフト一括して提供されます。障害原因がどこにあるかわからないような複雑なケースでも、コンポーネントごとに、複数の問い合わせ窓口とやり取りする必要は無く、仮想環境からハードウェアまで、一本の窓口で解決するまで対応できます。障害の切り分け作業などやっかいな事柄も、お客様は気にしていただく必要はありません。  また、運用管理は仮想環境からハードウェアまで、EVO:RAIL エンジンが用意するシンプルなUIから行う事ができるため、日々の運用管理も容易になります。

ご紹介しましたように、EVO:RAIL は、構築時間を短縮し、日々の運用管理を容易にし、サポートレベルの向上させるというベネフィットを高いレベルで提供できます。実際いままでに、EVO:RAIL をご採用いただいた、またはご検討いただいているお客様の多くは、TCO削減とともに、これらのポイントに課題をお持ちの方が多いようです。こういった課題を感じていらっしゃるお客様は、是非一度EVO:RAIL をご検討いただければと思います。

では、主なアップデートをご紹介します。

EVO:RAIL 機能拡張、ライセンスアップデート

  • vSphere Loyalty Program の開始
  • EVO:RAIL をご検討いただいている多くのお客様から、既にお持ちのvSphere ライセンスをEVO:RAIL で利用したいという声を頂きました。この度、既にvSphere のライセンスをお持ちのお客様は、そのライセンスをEVO:RAIL でご利用いただける購入方法の提供を開始しました。お持ちのvSphere Enterprise Plus のライセンス8本を、新規購入するEVO:RAIL でご利用いただくことができ、EVO:RAIL はその分お安く購入いただけます。本家の紹介blogはこちらです。

    スクリーンショット 2015-05-26 14.37.46

  •  最大8アプライアンスまで拡張可能
  • 当初4アプライアンス、16ノードまで同一クラスター、同一vCenter Server 下に配置する事ができましたが、ソフトウェアアップデートにより、最大8アプライアンス、32ノードまで拡張可能になりました。多くのユースケースにおいては充分大規模な構成を組む事ができるようになりました。
  • 異なるCPUタイプのアプライアンスを同一のクラスターに配置可能
  • Intel Ivy Bridge CPUを搭載するアプライアンスと、Haswell CPUを搭載するアプライアンスが同じクラスターに共存できるようになりました。
  • 簡単なノード交換の手順
  • 障害などでノードを交換する際の手順が簡単になります。どれくらい簡単か、一度ご体験いただく事をお勧めします。後述のEVO:RAIL ハンズオンラボでご体験いただけます。

EVO:RAIL ハンズオンラボ

ところで、EVO:RAIL を実際に試してみたい、どれくらい簡単に操作できるか体感してみたいと感じでいる方も多いと思います。EVO:RAIL の実物を試していただく事が一番良いのですが、より手軽にEVO:RAIL の操作をVMware がオンラインで提供する、ハンズオンラボで体験していただく事ができます。こちらをご利用いただくと、アプライアンスの初期導入だけではなく、アプライアンスの追加、ノード交換も試していただく事ができるようになっています。さらに、このハンズオンラボは実際のEVO:RAIL エンジンが動作していますので、ハンズオンラボのラボガイドに載っていない事でも、ハードウェアに依存しない事に関しては手軽に試していただく事が可能です。ご興味のある方は、是非ご利用ください。ドキュメントは既に日本語翻訳済みですし、UIもラボ内のブラウザーの設定を日本語に設定するか、EVO:RAIL のUIで日本語設定にする事により、日本語表示可能になります。ハンズオンラボは http://labs.hol.vmware.com/HOL/catalogs/ こちらからログインいただき、HOL-SDC-1428 Introduction to EVO:RAIL を選択ください。もしくは、http://labs.hol.vmware.com/HOL/catalogs/lab/1724 をアクセスする事により、EVO:RAIL のラボに直接接続できます。ハンズオンラボの実施手順はこちらから参照できます。

EVO:RAIL Day Osaka 6月18日開催

最後にEVO:RAIL に特化したイベントをご紹介します。来る6月18日に、大阪で国内2度目となるEVO:RAIL Dayを開催します。国内で展開するEVO:RAIL 認定パートナー様とともに、EVO:RAIL の最新情報、事例、各認定パートナー様のEVO:RAIL のご紹介やデモンストレーションなどをご覧頂けますので、お近くの方は是非お越し下さい。お申し込み、イベントの詳細はこちらからどうぞ。

本日、EVO:RAIL の特徴と現状のアップデートを簡単にご紹介いたしましたが、さらに詳細のご紹介も当blogで行っていく予定です。またEVO:RAIL は引き続きさまざまなエンハンスを予定しておりますので、是非ご期待ください。

ネットワーク仮想化をネットワークの基本から理解する 第3回:分散ルーティング – Layer3 の世界

■はじめに

こんにちは、パートナーSEの川崎です。本シリーズでは、前回に引き続きネットワーク仮想化をネットワークの基本から理解するという姿勢で、物理環境と比較しながら進めます。第3回となる今回はレイヤ3のルーティングに関して見ていきます。

■  はじめに
■  物理ネットワーク環境におけるルーティング
■  ネットワーク仮想化環境における分散ルーティング
■  物理ネットワーク環境とネットワーク仮想化環境の比較
■  補足情報

 

■はじめに

データセンターにおけるネットワークでは、East-West トラフィックと呼ばれるサーバ間の水平方向の通信が、トラフィック量全体の約7 割を占めていると言われています。分散ルーティングは、ハイパーバイザ内でルーティングの処理を行うことで、この East-West トラフィックを最適化します。

従来のルーティングテーブル(左)と分散ルーティング(右)

従来のルーティングテーブル(左)と分散ルーティング(右)

分散ルーティングの設定は、VMware NSX の管理画面から行います。物理サーバや物理ネットワーク機器数十台にまたがるような分散ルーティング環境を構成する際も、個々の物理コンポーネントに設定を行う必要はありません。

分散ルーティング環境を構成するためには、論理ルータコントロールVMと呼ばれるコンポーネントを作成します。論理ルータコントロールVM は、 NSX Edge の構成ウィザードから、インストールタイプを「論理(分散)ルータ」として構成します。

論理ルータコントロールVM の作成

論理ルータコントロールVM の作成

論理ルータコントロールVM に設定したインターフェイスやルーティングの情報は、各 VMware ESXi ホストに展開されます。例えば論理ルータコントロールVM にルーティング設定を追加すると、その情報が各 ESXi ホスト内の論理ルータカーネルモジュールに展開されることになります。

 

ルーティング情報の展開

ルーティング情報の展開

上述の通り分散ルーティングに関する設定はGUI から簡単に行うことができますが、APIを介した設定も可能であり、CMP(クラウドマネジメントプラットフォーム)と連携することで設定作業を自動化できます。

■物理ネットワーク環境におけるルーティング

分散ルーティングの説明に入る前に、物理ネットワーク環境でのルーティングの説明を行います。

 

物理ネットワーク環境におけるルーティング

物理ネットワーク環境におけるルーティング

ネットワーク環境において、異なるネットワークセグメント内に存在する端末間で通信を行なう場合を考えます。端末A と端末C はそれぞれ、172.16.10.0/24, 172.16.20.0/24のネットワークに存在し、物理ルータ(L3SW)に接続されています。異なるネットワークセグメント間の通信では、ルータによるルーティング処理が行なわれます。

ルーティングを行うのは、ネットワーク機器だけではありません。端末A(172.16.10.11/24) が端末C(172.16.20.11/24) と通信を行うとき、最初に端末A は端末C が異なるサブネットにいることを認識します。端末A は、自身のルーティングテーブルを参照し、デフォルトGW であるルータにトラフィックを転送します。

ルータはそれぞれのネットワークセグメントにインターフェイスF0, F1 を持ち、受信した通信を、別のインターフェイスから送信します。送信するインターフェイスを決定する際にルーティングテーブルを参照します。実際にルータのルーティングテーブルを確かめてみましょう。

> show ip route
C 172.16.10.0/24 is directly connected, F0
C 172.16.20.0/24 is directly connected, F1
S 0.0.0.0/0 via <外部ルータIP>

 

端末C(172.16.20.11)の所属する172.16.20.0/24 は、ルータのインターフェイス F1 に直接接続していることが確認できます。ルータは、インターフェイス F1 から端末C にパケットを転送します。

物理ネットワーク環境では、物理ルータがルーティングテーブルを持ち、単一のポイントでルーティング処理を実施します。また、複数の物理デバイスがある場合は、個々のデバイスに対して設定作業を行うことになります。

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

 

■ネットワーク仮想化環境における分散ルーティング

ネットワーク仮想化環境でのルーティングを見ていきます。サーバ仮想化環境であっても通常の構成であれば、ルーティング処理は外部のルータで行われることになります。これに対し、分散ルーティングが有効な環境では、各 ESXi ホスト内に論理ルータカーネルモジュールが配置され、ホスト内でルーティング処理を行うことが可能になります。

 

ネットワーク仮想化環境における分散ルーティング

ネットワーク仮想化環境における分散ルーティング

上記は、2台の ESXi ホストが存在し、ネットワーク仮想化と分散ルーティングが有効となった環境を表しています。各 ESXi ホスト内に論理ルータカーネルモジュールが構成され、2つのネットワークが接続されています。論理ルータカーネルモジュールはルーティングテーブルを持ち、異なるL2ネットワーク間の通信が行なわれる際にルーティング処理を行ないます。

分散ルーティングの動作

分散ルーティングの動作

実際に分散ルーティングが行なわれる状況を見てみましょう。上記は同一の ESXi ホスト上に存在する2つの仮想マシン VM-A、VM-C が通信を行なう様子を示しています。VM-A は VXLAN 5001 (172.16.10.0/24) に接続、VM-C はVXLAN 5002 (172.16.20.0/24) に接続しているため、2つの仮想マシン間で通信するためにはルーティングが必要です。VM-A から送信されるパケットは ESXi ホスト内の論理インターフェイス(LIF)を宛先とする L2 ヘッダがつけられて送信され、論理ルータカーネルモジュールに届きます。論理ルータカーネルモジュールは受け取ったパケットをルーティング処理し VM-C  に届けます。

では、実際に分散ルーティング環境のルーティングテーブルを確認しましょう。ここではテーブルの情報がどこから共有されてくるか、という点を確認するために、論理ルータコントロールVM、NSX コントローラ、各 ESXi ホスト内の論理ルータカーネルモジュールそれぞれについてルーティングテーブルを確認します。

論理ルータカーネルモジュールの持つルーティング情報は、論理ルータコントロールVM に設定した論理インターフェイス(LIF)情報、静的に設定されたルーティング情報、動的に得られたルーティング情報が基になっています。論理ルータコントロールVM の論理インターフェイスと静的なルーティングは vSphere Web Client から設定することができ、この情報は NSX Manager を介して論理ルータコントロールVM に伝えられます。動的ルーティングについては、論理ルータコントロールVM が外部のルータとダイナミックルーティングプロトコル(OSPF, BGP)を介して情報を交換します。

分散ルーティング環境でのルーティング情報の伝達

分散ルーティング環境でのルーティング情報の伝達

このようにして得られた論理ルータコントロールVM の持つルーティングテーブルを示します。

 

> show ip route
S      0.0.0.0/0      [1/1]  via <外部ルータIP>
C      172.16.10.0/24 [0/0]  via 172.16.10.254
C      172.16.20.0/24 [0/0]  via 172.16.20.254

ルーティングテーブル(論理ルータコントロールVM)

 

論理ルータコントロールVM が得たルーティングテーブル情報は、NSX コントローラクラスタを介して各 ESXi ホストに伝えられます。コントローラクラスタは役割を分担しており、ある論理ルータコントロールVM のルーティングテーブルはその管理を担う NSX コントローラ のみが持ちます。該当 の NSX コントローラ から、ルーティングテーブル情報を確認できます。

 

# show control-cluster logical-routers routes 0x570d4554
LR -Id      Destination      Next-Hop[]      Preference
0x570d4554  0.0.0.0/0        <外部ルータIP>   1

ルーティングテーブル(NSX コントローラ)

 

# show control-cluster logical-routers interface-summary 0x570d4554
Interface                        Type   Id           IP[]
570d455400000002                 vxlan  0x1388       172.16.10.254/24
570d45540000000a                 vxlan  0x138d       172.16.20.254/24

論理インターフェイス(NSX コントローラ)

 NSX コントローラが持つルーティング情報が各 ESXi ホスト内に存在する論理ルータカーネルモジュールに配信されます。

 

# net-vdr --route default+edge-2 -l
Destination      GenMask         Gateway        Flags   Ref Origin  Uptime     Interface
-----------      -------         -------        -----   --- ------  ------     ---------
0.0.0.0          0.0.0.0         外部ルータIP    UG      1   AUTO    1960358    570d455400000002
172.16.10.0      255.255.255.0   0.0.0.0        UCI     9   MANUAL  1971591    570d45540000000a
172.16.20.0      255.255.255.0   0.0.0.0        UCI     1   MANUAL  1971560    570d45540000000b

ルーティングテーブル(ESXi ホスト)

(補足)上図「分散ルーティング環境でのルーティング情報の伝達」の構成では、論理ルータコントロールVM が、外部ルータに対し、OSPF 経由で内部ネットワーク情報(172.16.10.0/24 及び172.16.20.0/24)を通知しています。これにより、外部ネットワークと内部ネットワーク間の通信が可能になります。

 

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

物理ネットワーク環境とネットワーク仮想化環境について、ルーティングの面で比較します。

 

物理と仮想の比較

物理と仮想の比較

物理ネットワーク環境では、ルーティングテーブルは物理ルータが持ち、単一のポイントでルーティング処理を実施していました(集中処理)。また、複数の物理ルータがあるような構成では個々のハードウェアに対して設定作業を行うことになります(分散管理)。

一方でネットワーク仮想化環の分散ルーティングは、ハイパーバイザ内でルーティングテーブルを分散して持つことで、複数のポイントでルーティング処理を実施します。

ポイント1 ハイパーバイザでルーティング情報を持ち、同一 ESXi ホスト上の仮想マシン間のルーティングはホスト内で処理することができるため、East-West トラフィックを最適化できる(データプレーンにおける分散処理)

各ハイパーバイザの持つルーティングテーブルの制御は、論理ルータコントロールVM 及び NSX コントローラクラスタで集約して行います。

ポイント2 論理ルータコントロールVM 及び NSX コントローラクラスタでルーティング情報を集中して制御することにより、複数のハイパーバイザ間でルーティングテーブルを共有することができる(コントロールプレーンにおける集中制御)

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

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

ネットワーク仮想化環境における分散ルーティングは、分散処理、集中制御、集中管理のアプローチをとることで、運用管理性を維持しつつ、効率よく East-West トラフィックを処理することを可能にしています。

 

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

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

 

 NSX を構成するコンポーネントの役割

NSX を構成するコンポーネントの役割

・NSX Manager(マネジメントプレーン)

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

・NSX コントローラクラスタ(コントロールプレーン)

NSX コントローラクラスタは、現時点で3台の仮想アプライアンスで構成することを推奨しており、分散ルーティング環境において、各種情報(論理インターフェイス、ルーティングテーブル)を集中管理するポイントになります。後述の論理ルータコントロールVM 毎に担当するコントローラが決められ、例えば2つのテナントがある場合、論理ルータコントロールVM (テナントA)はコントローラ1番、(テナントB)はコントローラ2番というように役割が割り当てられます。テーブル情報は、担当するコントローラのみが保持します。

 

マルチテナント環境でのルーティングテーブルの扱い

マルチテナント環境でのルーティングテーブルの扱い

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

# show control-cluster logical-routers instance all
LR-Id      LR-Name            Hosts[]         Edge-Connection Service-Controller
0x570d4554 default+edge-2     192.168.210.51                  192.168.110.201
192.168.110.52
192.168.110.51
192.168.210.52
192.168.210.56
0x570d4553 default+edge-3                                     192.168.110.202

この出力結果から、論理ルータコントロールVM のインスタンスが2つあることが分かります。default+edge-2(0x0x570d4554)は、192.168.110.201 が管理し、default+edge-3(0x570d4553)は、192.168.110.202 のコントローラが管理していることが分かります。論理ルータの情報を見るためには該当のコントローラにログインする必要があります。(192.168.110.201 のコントローラで情報を出力しているため、自身の担当しているインスタンス default+edge-2 に関連する ESXi ホストの IP 情報が出力されています)

論理ルータ default+edge-2(0x0x570d4554)の管理するルーティングテーブルの確認

# show control-cluster logical-routers routes 0x570d4554
LR-Id       Destination        Next-Hop[]         Preference
0x570d4554  0.0.0.0/0          192.168.10.1       1

論理ルータdefault+edge-2(0x0x570d4554)の管理する論理インターフェイスの確認

# show control-cluster logical-routers interface-summary 0x570d4554
Interface                        Type   Id           IP[]
570d455400000002                 vxlan  0x1388       192.168.10.5/29
570d45540000000a                 vxlan  0x138d       1.1.1.254/24

 

・論理ルータコントロールVM(コントロールプレーン)

論理ルータコントロールVMは分散ルーティング環境において、ルーティングの処理を集中して行うための仮想アプライアンスです。設定したスタティックルーティング情報や、ダイナミックルーティングプロトコル(OSPF, BGP)経由で外部のネットワーク機器から学習したルーティング情報を、コントローラクラスタ経由でESXi ホストに配信します。

 

論理ルータdefault+edge-2(0x0x570d4554)の管理するルーティングテーブルの確認

> show ip route
S      0.0.0.0/0        [1/1]    via 192.168.10.1
C      192.168.10.0/29  [0/0]    via 192.168.10.5
C      1.1.1.0/24       [0/0]    via 1.1.1.254

 

論理ルータコントロールVM はテナント単位(ルーティングテーブルの管理単位)で複数たてることができます。

 

・論理ルータカーネルモジュール(データプレーン)

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

 

論理ルータ default+edge-2(0x0x570d4554)の管理するルーティングテーブルの確認

# net-vdr -l --route default+edge-2
VDR default+edge-2 Route Table
Legend: [U: Up], [G: Gateway], [C: Connected], [I: Interface]
Legend: [H: Host], [F: Soft Flush] [!: Reject] [E: ECMP]

Destination      GenMask          Gateway          Flags    Ref Origin   UpTime     Interface
-----------      -------          -------          -----    --- ------   ------     ---------
0.0.0.0          0.0.0.0          192.168.10.1     UG       1   AUTO     1724       570d455400000002
1.1.1.0          255.255.255.0    0.0.0.0          UCI      1   MANUAL   1832038    570d45540000000a
192.168.10.0     255.255.255.248  0.0.0.0          UCI      1   MANUAL   2701981    570d455400000002

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

ハイパーバイザと NSX コンポーネント間のコネクション

ハイパーバイザと NSX コンポーネント間のコネクション

コントローラクラスタとの接続確認

# 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

 

上記出力より、ESXi ホストの管理用 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

 

上記出力より、ESXi ホストの管理用IP アドレスから NSX Manager に、vsfwd を介して接続していることが確認できます。NSX Manager からはコントローラのIP アドレス情報を取得します。

なお、論理ルータコントロールVM をホストしているESXi は、VMCI (Virtual Machine Communication Interface) と呼ばれる仮想マシン-ハイパーバイザ間専用のパスを使用し、ルーティング情報を論理ルータコントロールVM から取得、ESXi が取得した情報をコントローラに netcpa 経由で通知します。コントロールプレーンの通信に論理ルータコントロールVM の管理インターフェイスは使用しません。

ルーティング情報の取得と配布

ルーティング情報の取得と配布

・NSX Edge (データプレーン)

仮想アプライアンスとして提供され、単体で各種ネットワークサービス機能(ロードバランサ、ルーティング、NAT、ファイアウォール、VPN、 DHCP 等)を提供する「スイスのアーミーナイフ」のようなコンポーネントです。従来の物理のネットワーク機器が仮想アプライアンスとして置き換わったイメージです。外部ネットワーク機器として論理ルータコントロールVM とダイナミックルーティングプロトコルを使用しルーティング情報を交換する場合がありますが、論理ルータの提供する分散ルーティングの機能そのものには直接関与しません。

 

■コラム

新卒から見たネットワーク仮想化

当初ネットワーク仮想化と聞いて非常に難しそうに感じました。サーバ仮想化もまだ勉強中であり、ネットワークについてはさらに知っていることが少ない状態です。しかしながら、いざ勉強を進めていくと、中心となる L2、L3 の通信はテーブルを参照してパケットが流れていくという点では物理環境とほとんど変わりませんでした。実際、物理ネットワークと比較して抑えていくことで、ネットワーク仮想化が物理ネットワークの再現であり、仮想マシンや流れるパケットからすれば同様に動作できる環境が作られていることがわかってきました。NSX には Manager やコントローラ、論理ルータコントロールVM など複数のコンポーネントがありますが、それぞれの持つ役割を把握することで、スムーズに理解していけるように感じます。皆様もぜひご一緒にネットワーク仮想化を学んでいきましょう。

 

■関連リンク

今回ご紹介した内容をオンラインのハンズオン環境上で確認することができます。コマンドラインの出力はハンズオン環境をベースに作成しています。

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 の世界