Home > Blogs > Japan Cloud Infrastructure Blog

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

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

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

 

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

NWV04-01

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

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

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

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

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

NWV04-02

また、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 の世界

VMware vSphere Virtual Volumes に対するHP 3PAR StoreServの実装

はじめに

vSphere 6.0 で実装されたVMware vSphere Virtual Volumes (VVol) は、対応するストレージと連携することにより初めて利用可能となる機能です。VVolの全体的な話はこちらでご紹介させていただきましたが、今回は、主にストレージ側から見たVVol の実装とそのメリットについて、日本HPの3PAR担当プリセールスの伊東様に執筆いただきましたのでご紹介いたします。

VVol 概要とメリット

vSphere 6.0 から新たに実装されたVVol はストレージベンダーにとっては2015年で最も重大なニュースであり非常に大きなインパクトを与えています。特にSANストレージがVVol に対応することでこれまでのLUN + VMFSでは不可能であったり不便であったりしたことが大幅に改善されます。

どのように改善、変化したかということを下図で示します。SANストレージとNASストレージでは同じ利用目的のデバイスでありながら管理の方法やその特性が全く違っていました。

 

VVol を利用すると、vCenter Server からSANもNASも同じVVol Datastoreの定義をすることができ、見え方、使い方の違いを無くすことができます。

 

SANストレージにとっては、今まではほぼ不可能に近かった仮想マシン毎にボリュームを分け、サービスレベルを個別に設定することが可能になり、様々なメリットが生じてきます。

VVol の対応により、SANストレージは今までと同様の高いパフォーマンスを提供しながらストレージリソースのシンプルな管理、きめ細かなSLA定義、効率の良いストレージ機能の提供が可能となります。

3PAR とVVol の関係について

HP 3PARとVVol には長い歴史があります。まだ3PAR がHP にマージされる前の4年以上前からVVol との関係がスタートしています。その後、3PAR はHP の主力ストレージとなりましたが、HP がVVol のオリジナル開発パートナー5社のうち1社となり、更に3PAR がFCストレージのリファレンスプラットフォームに選ばれました。開発の途中経過はHPのブログやエキシビションで発表しており、2014年半ばにはVVol のベータプログラム開始時に準備が整っていた3製品のうちの1つとなりました。最終的にVVol がGAとなった2015年3月時点でもVVol が提供する機能を全てカバーしています。

では、HP 3PAR がVVol の機能をどのように実装し、実際にどのように動作するかということを解説していきます。

VVol をサポートするための実装

・VASA 2.0プロバイダ

 vCenter Server / ESXとやり取りするストレージ管理サービスでvCenter Serverからのリクエストを受け取り、ストレージの機能や制御の伝達・翻訳する役目を果たします。

・プロトコルエンドポイント

 FCファブリックのアクセスをシングルポイントにする仮想デバイスで通常のLUN 検出コマンドで検出されます。ストレージ管理ツールに触る必要が無く、ストレージ管理者が介在しなくてもvCenter Serverからストレージの切り出しが可能です。各仮想マシンにはVMDK, Config, Swap, Memory, Snapshotなど複数個の3PAR VV*(Virtual Volume)が作成されることになるため、従来よりも多数の3PAR VVが作成されることになりますが、3PAR はもともと多数のボリューム構成をサポートしており、その範囲内であれば全く問題なく利用可能です。

 *3PAR VV(Virtual Volume)とは:3PAR内では、ホストに提供するLUに相当するボリューム のことを従来よりVirtual Volumeと呼んでいます。
  vSphere VVol環境ではVVol = 3PAR VVとなります。なおvSphere VVolはVirtual Volumesとも呼びますので、混同しないようご注意ください。

・VVol Datastore(ストレージコンテナ)

 3PAR ではオプション機能のVirtual Domainを利用すると1台の3PAR を仮想的に複数のストレージとして管理単位を分割出来るためストレージコンテナを複数に分割することが可能です。Virtual Domainを利用しない場合は3PAR が丸ごと1台がストレージコンテナとなります。

3PARのVASAプロバイダはビルトインで、3PARのコントローラノード上のサービスとして動作します。インストールなど不要でコマンドによりサービスを起動するだけで即座に利用可能となります。

VASAプロバイダがストレージコントローラ上に組み込まれていることによって得られる見過ごすことのできないメリットがあります。

・インストール不要で追加のセットアップや構成が不要

・高可用性、自動フェイルオーバ

・個別のバージョン管理、アップデートが不要

ストレージ装置によっては仮想アプライアンスなどの形でVASAプロバイダが提供されているケースもあり、構築にそれなりの手間が生じますが、3PARのVASAプロバイダは上記の通り極めて簡単に構築可能で、かつ、可用性に優れる実装となっています。

また、3PARがサポートするVV(ボリューム) 数は下記の通り、非常に多数を作成することが出来るため、VVol で懸念となるボリューム数の増大は3PAR では全く気にする必要がありません。

モデル

7200/7400

7440/7450

10000

最大VV数

16000

32000

32000

 

VVol + 3PARで何が出来るか?

VVol 環境で利用可能となる3PAR の独自機能を下記に挙げます。

・ベンダーニュートラルな機能として提供(VVol 必須の機能)

  Thin / Thick Provisioning

・ベンダー固有の機能として提供

  Common Provisioning Group :ボリューム構成テンプレート

              プライマリ用とスナップショット用を別々に選択可能

  Thin Persistence(Zero Detect):ゼロデータ検知・リクラメーション

  Thin Dedupe:重複排除機能

・その他vCenter Serverから行えるストレージ機能

 スナップショットの作成

  Virtual Copy(スナップショット機能)との連携:

   仮想マシンの操作メニューからスナップショット作成を行うと、3PAR側でVirtual Copyを作成

・現時点で3PAR 管理ツールにより設定すれば使える3PAR 機能

  ストレージQoS:Priority Optimization

  フラッシュキャッシュ:Adaptive Flash Cache

  将来的にはVVolに対応した機能として提供する予定です。

Storage Policy-based Management(SPBM)のサポート

仮想マシンのストレージに対するビジネスニーズを満たすためのフレームワークです。

  • SPBM によって、仮想マシンをストレージ上でプロビジョニングする際にアプリケーションの要件にマッチしたボリュームを提供するための仕組みになります。
    • ストレージがサポートしている機能をvSphereのPolicy-base Provisioning エンジンに対して公開
    • 仮想マシンが作成される際、ビジネスニーズにマッチした機能をアサインする
      • 仮想マシン毎、必要な機能がボリュームに対してアサインされる(スナップショットも仮想マシン毎)
    • SPBMエンジンは、要件を満たし互換性を持ったデータストア(ローカルディスク、LUN、vSAN、VVol )がどれかというのを認識
    • 仮想マシンは適切なESXホストおよびストレージでプロビジョニングされる
    • SPBM は各ボリュームのコンプライアンスを監視
    • 仮想マシンに紐づけたストレージが機能要件を十分に満たしているかを監視していく役割も担っている

3PARでVVolを利用するための環境

  • vSphere 6
  • 3PAR OS :3.2.1MU2 Patch 12
  • 3PARソフトウェアライセンス類
    • OS Suite        :必須
    • Virtual Copy         :必須
    • Virtual Domain        :オプション
    • Priority Optimization    :オプション
  • FC HBA, FCoE アダプタ

3PARでVVol を利用するために最初に実施すること

下記の手順でVVol利用の準備を行います。

  1. VASA プロバイダ サービスの起動: 3PAR CLI にて、"startvasa" コマンドを実行
  2. <オプション>VVol 用のドメイン、ユーザの作成
  3. CPGの作成 :全てのCPG が機能プロファイルとしてvSphere に提供されます
  4. VASA プロバイダの登録:vCenter Server から VASA プロバイダをスキャン
  5. ESXi ホストを 3PAR に登録:通常の手順で登録。ESXからプロトコルエンドポイントを確認
  6. VVol データストア(Storage Container)をマウント:通常のデータストアと同じ手順。
  7. ストレージポリシーを作成

手順のイメージをいくつか紹介します。

  1. VASAプロバイダの準備はサービスの確認と開始のコマンドを実行するだけで完了です。

④VASA プロバイダの登録はvCenter Server の新しいストレージプロバイダの追加を実行します。

⑤ESXi ホストの登録を実施しますが、3PAR では通常行っているホストの登録コマンドを実行するだけで完了です。またホスト登録の実施を行うだけでプロトコルエンドポイントとなるLUが有効になります。

 ホスト登録のための3PAR コマンド:cli# createhost –persona 11 <host name> <WWN> 

 ESXi 側では通常のデバイスのスキャンを行い、ストレージデバイスにLU が確認できることと、そのデバイスがプロトコルエンドポイントとして認識されていることを確認します。

 

プロトコルエンドポイントはESXi から見るとSCSIデバイスが見えますが、3PAR 内ではボリュームの実体は作られません。

⑥VVol データストアのマウントをした後、データストアのサマリ情報を見るとストレージ機能プロファイルという項目があり、そこに3PAR の CPG が列挙されてきます。CPGには 3PAR のドライブタイプ、 RAID レベル、ストライプ幅を決める設定が含まれます。


⑦ストレージポリシーの作成では3PARの機能の組み合わせを一つ一つ構成していきます。

まずポリシー名を設定します。


次にルールセットを作成で、ルールの中に 3PAR の機能を選択していきます。

プライマリボリューム用の CPG、スナップショットデータを格納用のCPGの選択、リクラメーション機能のThin Persistence、重複排除機能のThin Deduplicationを必要に応じて追加します。


この例では、プライマリボリュームはFCドライブのRAID 1に、スナップショットはFCドライブのRAID 6 に、リクラメーション機能もONというポリシーを設定したことになります。


ルールの設定の後は、互換性ありと表示されているVVol のデータストアを選択します。


設定内容の確認を行い、ポリシーの作成は完了となります。


 

仮想マシンの作成

最後に一番重要な、仮想マシンの作成とそれに伴い自動的に作成されるボリュームについて、実際の作成画面等を用いて紹介していきます。

通常の手順で新規仮想マシンの作成を開始します。


ストレージの選択で、仮想マシン ストレージ ポリシーでVVol 用に作成したポリシーを選択します。ここで選択したポリシーに応じて仮想マシンの作成と共にボリュームが作成されます。


仮想マシン ストレージ ポリシーで選択されたポリシーに対して、互換性のあるデータストアが互換性ありにリストアップされます。ここでは"VVOL"という名前で作成されたVVol データストアを選択します。


最後はサマリが表示され問題なければ完了となります。


 

仮想マシンを作成すると、3PAR 上で仮想マシンに応じたVVが自動的に出来上がります。通常運用では3PAR側のVVの状態を特に意識する必要はありませんが、参考までにその確認の方法を紹介します。

VVol 用に自動的に作成された3PAR VVの表示コマンドshowvolvm –vvの実行結果で仮想マシンとVVol 名、VVol タイプ等と3PAR VVとの対応が確認できます。仮想マシン作成時点では、Config 用とData 用のボリュームが作成されています。

仮想マシンのパワーオンを実行するとSwap 用のボリュームが自動的に作られます。

仮想マシンのスナップショットを作成では、従来の手順で仮想マシンのメニューからスナップショットの作成を実行します。

スナップショットの作成手順を行うことでVVol の場合は自動的にストレージネイティブのスナップショット機能 = 3PARではVirtual Copy が自動的にとられます。

仮想マシンのメモリのスナップショットをチェックしておくと VVol ではストレージ側に Memory というタイプのボリュームを作成します。

以上、仮想マシンの作成やスナップショットの作成は全てvCenter Server 側の UI から実施可能で、3PAR 側でのボリュームの確認は任意ですので必要に応じて 3PAR のコマンドから確認してください。

現時点でまだ VVol 機能に対応していないストレージ QoS やフラッシュキャッシュ機能は 3PAR のコマンドから設定いただきご利用いただくことが可能となっております。将来的には VVol 機能の一つとして選択できるように実装される予定です。

 

最後に

HP 3PAR が VVol の開発当初から関わり、リリースと同時に完全にサポートしていることをご理解いただいたと思いますが、 VVol 機能自体がまだまだ発展途上の技術であり今後にのびしろを多く残している機能です。

特に2015年5月時点では VVol で作成されたボリュームをストレージでレプリケーションする機能は実装されていませんし、バックアップに関しても対応しているバックアップソフトウェアも少ないのが現状です。

3PAR は引き続きVVol 対応用の機能を拡充し VVol の進化に追従していく予定ですので、是非今からご利用のご検討をスタート頂ければと思います。

vSphere 問題解決までのヒント!- 第1回 トラブル発生時に役立つ 4 つのリソース

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

みなさん、VMwareのサポートにどのような印象をお持ちでしょうか。
職人のようなサポートエンジニアがログを見てさくさくっと回答していると思われるかもしれませんが、
技術的な調査に取りかかる以前に 「何が出来なくてどうお困りなのか」 をお伺いするのに苦労していたりもします。

私が日々お仕事をしていて感じるのは「事象や構成が整理されているお問い合わせは、解決までのスピードが早い!」ということです。
長引いているケースが技術的に難しくて複雑であるとは限らなくて、事象や構成がはっきりしないために技術的な調査が進められないということもあるのです。

この連載では、スムーズな問題解決のためのヒントになるようなお話しをしていきたいと思います。
技術的な話が少なくて拍子抜けかもしれませんが、「サポートエンジニアも結構地道な作業をしているのね!」と感じていただけるかと思います。
徐々にステップアップしていきましょう!

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

今回はトラブル発生時に役立つリソースとその使い方をご紹介いたします。

  1. ナレッジベース(http://kb.vmware.com/
    障害の発生事例や対処法、トラブルシューティング方法、ベストプラクティス等を検索することができます。
  2. 各種ドキュメント(http://www.vmware.com/jp/support/support-resources/pubs/
    製品マニュアルやリリースノートなど、各種ドキュメントが公開されています。
  3. コンパチビリティガイド(http://www.vmware.com/resources/compatibility/search.php
    VMware製品とハードウェアやOSの互換性をチェックすることができます。
  4. VMware製品間の相互運用性マトリックス(http://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php
    VMware製品間の互換性をチェックすることができます。

これから紹介するページは、弊社のサイト(http://www.vmware.com)トップ画面の [サポート] からアクセスできます。
設計・構築時にご利用いただいているものもあるかと思いますが、今回はトラブル発生時にどのようなポイントを確認したらいいかという観点でご説明したいと思います。
はじめての方も、まずは手を動かしながら色々調べてみましょう!

supportblog_index

1. ナレッジベースKnowledge Base(http://kb.vmware.com/supportblog_kb1
まずはここ、1つ目はナレッジベース(Knowledge Base)です。
障害の事例や対処法、トラブルシューティング方法、ベストプラクティス等を検索することができます。
エラーメッセージやコンポーネント名、ハードウェア名などで検索してみて下さい。
最近は日本語に翻訳された記事も増えてきているのですが、英語で書かれた記事をベストエフォートで翻訳していますので、最新情報ではない可能性もあります。
例えば、日本語版では回避策なしと案内されている場合も、オリジナルの英語版では回避策や修正についての情報がアップデートされているかもしれません。
日本語版の記事にはオリジナルの英語版へのリンクがありますので、必ずこちらも合わせて確認するようにして下さいね。


2. 各種ドキュメント(http://www.vmware.com/jp/support/support-resources/pubs/

そして2つ目、製品ドキュメントやリリースノートをはじめ各種ドキュメントが公開されています。
supportblog_doc1
まずは html 版の vSphere 5.5 の製品マニュアルである「VMware vSphere 5.5 ドキュメント センター(http://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/Welcome/welcome.html)」を見てみます。
上記のページ「VMware vSphereのドキュメント(http://www.vmware.com/jp/support/support-resources/pubs/vsphere-esxi-vcenter-server-pubs/)」各ガイド欄にリンクされています。
supportblog_doc2
確認してもらいたいポイントに沿ってご紹介します。

・構成(システム要件、インストール方法など)
要件を満たしていないシステムでは予期せぬトラブルが発生することがあります。
ご利用いただいている環境がシステム要件を満たしているか、インストールや設定方法に問題が無かったか確認してみましょう。
お客様のシステムはお客様が一番よく知っているはずなので、ここは頑張っていただきたいポイントです!

システム要件を見てみます。
vSphere のインストールとセットアップから展開できます。
supportblog_doc3
例えば、vCenter Server, Web Client, Inventory Service, Single Sign-On すべて同じマシンの構成だと 12GB 以上のメモリが必要ですが、この条件を満たしていないマシンをたまに見かけますね。
基本的なことではありますが、念のためひとつひとつ確認してみて下さい。
supportblog_doc4・トラブルシューティングガイド
トラブルシューティングガイドでは、よくあるトラブルについて、問題・原因・解決方法が説明されています。
このガイドに記載の無い問題であったとしても、類似の問題から何かヒントを得られるかもしれませんので目を通してみて下さい。
supportblog_doc5

次に確認していただきたいのがリリースノートです。
リリースノートには新機能の紹介だけでなく、既知の問題とその回避策も公開されています。
supportblog_rn1
「VMware vSphereのドキュメント(http://www.vmware.com/jp/support/support-resources/pubs/vsphere-esxi-vcenter-server-pubs/)」ページに戻り、vCenter Server 5.5.x の一番新しいバージョン(5.5 Update 2d)のリリースノートを見てみます。
既知の問題の欄をご参照下さい。
ここで紹介されている問題にあてはまりそうな場合、回避策を試してみて下さい。
supportblog_rn2

トラブル時の確認という観点でいうと製品ドキュメントとリリースノートあたりですが、他にも色々なドキュメントが公開されています。
製品への理解を深めるのにお役立てください。


3. コンパチビリティガイドVMware Compatibility Guide http://www.vmware.com/resources/compatibility/search.php

3つ目、少しレベルアップして構成にあわせた確認をしていきましょう。
ストレージやネットワークなど問題が絞りこめている場合は、改めてハードウェアのコンパチビリティを確認してみて下さい。
項目によっては互換性の有無だけではなく、推奨設定なども確認できます。

supportblog_hcl1

試しに私が使っているマシンのHBAのコンパチビリティを確認してみましょう。
vmhba0として認識されているIntel Corporation Avoton AHCI Contorollerにポイントします。

supportblog_hcl3

esxcfg-infoコマンドで詳細を確認してみます。

supportblog_hcl4
supportblog_hcl5

ESXi のバージョンも確認しましょう。
Buildは1892794 なので、ESXi 5.5U1 とのコンパチビリティを確認することになります。

supportblog_hcl6

Web Clientからもハードウェアの情報を確認できます。
インベントリツリーで [ホストおよびクラスタ] - [該当のホスト] – [管理タブ] でネットワークやストレージアダプタを確認できます。

supportblog_wc1

詳細な情報を確認したい場合は、[管理タブ] の右隣 [監視タブ] の [ハードウェアステータス] から該当のアダプタを選択して下さい。

supportblog_wc2

ESXiのバージョン、Buildは [サマリタブ] の [構成] から確認できます。

supportblog_wc3

では、確認した情報を元に検索してみます。

調べる対象はSATA controller なので [What are you looking for] は [IO Device] 、[I/O Device Type] は [SATA] に設定しました。
[Brand Name] や [VID] や [DID] も esxcfg-info や ハードウェアステータスタブ の内容を参考に選択し、 [Update and View Results] で検索を実行します。

supportblog_hcl7

出ましたっ!

supportblog_hcl8

ESXi 5.5U1とIntel Corporation Avoton AHCI Contorollerには互換性があることが確認できました。

supportblog_hcl8

ドライバのバージョンも問題ありませんね。
最新のドライバがあればアップデートしておくとベストです。

supportblog_hcl10

手順やよくある質問についてはこちらをご覧下さい。

* VMware KB: Identifying correct driver for ESXi/ESX host PCI devices (HBA) using VMware Hardware Compatibility Guide (HCL) (1031534)
http://kb.vmware.com/kb/1031534
* VMware KB: Identifying and downloading the appropriate driver for your adapter: Process and FAQ (2050194)
http://kb.vmware.com/kb/2050194


4. VMware製品間の相互運用性マトリックスVMware Product Interoperability Matrixeshttp://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php

見落としがちな4つ目、VMware製品間の相互運用性マトリックス(VMware Product Interoperability Matrixes)では製品同士の互換性を確認することができます。
バージョンアップや旧環境からの移行の後に問題が発生したなんていう時は、念のため確認してみて下さい。supportblog_iom1

では私の使っているマシンにインストールされている ESXi とそれを管理している vCenter Server の互換性を確認してみます。
ESXi はBuild 1892794 なのでESXi 5.5U1、vCenter Server はBuild 2183111 なので 5.5U2 に該当します。
[Select a Solution] で [ESX/ESXi] を選択し、[Version] を指定するとESXi5.5.U1の列が追加されました。

supportblog_iom2

今回確認したいのは vCenter Server との互換性です。
[Add Plat form/Solution] には [vCenter Server] を選択し [Add] すると [vCenter Server] の行が追加されました。

supportblog_iom3

チェックが付いているのが互換性ありのしるしです。
ESXi 5.5U1 と vCenter Server 5.5U2 は互換性に問題が無い組み合わせであることが確認できました。
手順は以下のKBが参考になります。

* VMware KB: Using the VMware HCL and Product Interoperability Matrixes (2006028)
http://kb.vmware.com/kb/2006028

---

ここまで調べてみて、いかがでしたでしょうか。
問題は解決しましたか?

どれにもあてはまらない…
案内されている方法を試してみたけど直らない…

という場合はサポートリクエスト(SR)を発行してみましょう。
「それなら最初から問い合わせすればよかった!」と思っているかもしれないみなさまに、
ここまで手を動かした努力は決して無駄ではない!」ということをお伝えしたいです。

最初にお話したように、スムーズな問題の解決のためには、問題に対するお客様のご理解がとても大切です。
コンパチビリティを確認してみて、普段ご利用いただいている環境のことがより理解できたのではないでしょうか。
また、ナレッジベースやドキュメントを検索しているうちに、発生している事象が整理されてきたのではないかと思います。

次回はサポートリクエスト(SR)の発行と情報採取についてお話したいと思います。

連載 vSphere 問題解決までのヒント!
第1回 トラブル発生時に役立つ 4 つのリソース
第2回 サポートリクエスト(SR)と情報採取
第3回 応用編

VMware vSphere 6.0 の新機能 vMotion編

こんにちは、パートナーSEの川﨑です。今回は VMware vSphere 6.0 のリリースに伴う、VMware vSphere vMotion の機能アップデートについてご紹介いたします。vMotion の機能拡張は今回のアップグレードの目玉の一つとなっておりますので、ぜひご注目ください。

 

■クロス vCenter vMotion( vCenter Server システム間のvMotion )

クロス vCenter vMotion とは、異なる vCenter Server の配下にある ESXi ホスト間で vMotion を可能にする機能です。これまで、vSphere 5.5 まででは、vMotion は同一の vCenter 下でしか行うことができませんでした。今後は、図1のイメージのように、異なるvCenter に所属するホストやクラスタを移行先として vMotion で移行することが可能です。(図1では、”CentOS2” という仮想マシンを ”172.16.119.132” の vCenter 下の ”Cluster2” というクラスタから、”172.16.119.131” の vCenter 下の ”VSAN” というクラスタへの移行を示しています。)

図1.クロスvCenter vMotion での移行イメージ
図1.クロスvCenter vMotion での移行イメージ

クロス vCenter vMotion の実施方法は通常の vMotion となんら変わらず、図2のように仮想マシンを選択して、アクションとして”移行”を選択し、”計算リソースのみ変更します”または”計算リソースとストレージの両方を変更します”を選択してウィザードを進めることで、通常の vMotion 同様に移行を行うことが可能です。

なお、異なる vCenter 間での移行時の要件については弊社ドキュメントの下記ページをご参照ください。

http://pubs.vmware.com/vsphere-60/index.jsp?topic=%2Fcom.vmware.vsphere.vcenterhost.doc%2FGUID-897E10D6-A413-4699-B3C6-498AA80CB9ED.html

 

図2.クロスvCenter vMotion の実施方法

図2.クロスvCenter vMotion の実施方法

クロス vCenter vMotion が可能となったことで、これまで vCenter の管理範囲ごとに区切られていた仮想基盤が vCenter の縛りを超えて一つの共通プラットフォームとして扱えるようになります。データセンターごとに vCenter を分けていたケースなどでは、今回初めて vMotion での移行が可能になり、嬉しい機能拡張ではないでしょうか。

vCenter Server を超えた際に気になる点の一つとして、仮想マシンに関する様々な情報は引き継がれるのか、といった点があります。実際には多くの情報は引き継がれ、仮想マシンの MAC アドレスや、タスクの履歴、シェアや予約値といったリソース設定、HA・DRS の設定等は引き継がれますが、パフォーマンスデータは引き継がれない仕様となっております。詳細は補足として、記事の最後に記載いたします。

■長距離 vMotion 移行

長距離 vMotion 移行は、長距離に離れたデータセンター間など、遅延が大きい環境間での vMotion を可能にします。通常の vMotion で許容される RTT (=round trip time) は 5ms ですが、これが Long Distance vMotion では 150ms まで許容されます。これにより、アメリカであれば大陸の東西、日本であればシンガポールまでの距離であっても、vMotion で仮想マシンを移動させることができます。 (*レイテンシは実際に利用する回線の品質にも依存します。上記はあくまで一例とお考え下さい。)

http://kb.vmware.com/kb/2106949

 

図3.長距離vMotion移行の実施イメージ

図3.長距離vMotion移行の実施イメージ

■vMotion ネットワーキング

vMotion のネットワーク周りについてもアップデートがあります。一つは、TCP/IP スタックが複数構成できるようになったことにより、vMotion についても専用のTCP/IP スタックが構成可能となりました。VMKernel アダプタの作成時に、TCP/IP スタックとして ”vMotion” を選択することで設定することができます。(図4)

 

図4.vMotion専用TCP/IPスタックの設定

図4.vMotion専用TCP/IPスタックの設定

TCP/IP スタックが vMotion 専用で構成できるようになったことに伴い、vMotion 用ネットワークが異なる L2 セグメントに跨る場合にも柔軟に構成できるようになりました。従来は vMotion 用トラフィックが有効化された VMKernel アダプタ も管理ネットワークと同一の TCP/IP スタックを利用しましたが、vSphere 6.0 では個別にデフォルトゲートウェイやルーティングテーブルの構成を持つことが可能です。なお、仮想マシンの接続されるネットワークについては同一のL2ネットワークセグメントへの接続が必要です。(図5では青線が vMotion 用ネットワーク、緑線が仮想マシン用ネットワークを示しています)

図5.vMotionネットワークの構成例

図5.vMotion ネットワークの構成例

次に、クロス vSwitch vMotion について触れます。vSphere 5.5 まででは、vMotion 時には接続前後で接続する標準仮想スイッチ(vSS)、または分散仮想スイッチ (vDS) の仮想マシンポートグループを選択することはできず、移行前後で同じ仮想マシンポートグループ(vSS の場合は同じラベルのポートグループ)に接続する必要がありました。vSphere 6.0 では、移行後に接続する仮想マシンポートグループの選択が可能となり、例えば vSS の仮想マシンポートグループに接続されていた仮想マシンを vDS の仮想マシンポートグループに接続することも可能となりました。ただし、vDS から vSS への移行は選択できない点と、移行前後で IP アドレスの変更はされないため、仮想マシンのネットワーク接続確保のためには同一の L2 ネットワークに接続し続けることが必要な点には注意が必要です。

 

図6.vMotion移行ウィザード中でのネットワーク選択

図6.vMotion 移行ウィザード中でのネットワーク選択

■補足:クロス vCenter vMotion で引き継がれる情報、引き継がれない情報について

下記で、クロス vCenter vMotion での移行前後で、引き継がれる情報と引き継がれない情報を整理いたします。内容については、一部検証結果に基づく情報であることをご承知ください。

①UUID

uuid.bios と vc.uuid は保持され、uuid.location は変更されます。これらは vmx ファイルを参照することで確認可能です。

x-vc_uuid

②MACアドレス

MACアドレスの変更はありません。また、移行元の vCenter Server では、 MAC アドレスをブラックリストに追加して、新しく作成された仮想マシンにその MAC アドレスが割り当てられないようにします。

x-vc_mac

 

③HA/DRS ルール

基本的には下記ルールはクロス vCenter vMotion 後も保持されます。

  • アフィニティルール
  • VM ごとのオーバーライドルール
    • 自動化レベル
    • 起動優先順位
    • ホスト分離時の対応

x-vc_affinity_ok1x-vc_affinity_ok2

ただし、下記の場合は例外的に保持されないことが社内の検証で確認されています。(判定は VM ごとに行われます)

  • アフィニティルール
    • VM ごとのオーバーライドルールが設定されている場合
      x-vc_affinity
  • VM ごとのオーバーライドルール
    • 移行先のクラスタの設定と同じ設定がされている場合
      x-vc_override

*アフィニティルールは VM 間で設定している場合、適用には双方の VM でルールが保持される必要があります

 

④リソース設定

仮想マシンに対する CPU、メモリリソースのシェア、予約、制限値は保持されます。

x-vc_resource

 

⑤タスクデータ

タスクデータは引き継がれます。

x-vc_task

 

⑥パフォーマンスデータ

パフォーマンスデータは移行の前後で引き継がれません。

x-vc_performance

 

⑦vRealize Operations Manager 上のデータ

vRealize Operations Manager 上のパフォーマンスデータは移行前後で引き継がれません。

x-vc_vROps

 

■終わりに

vSphere の基本的な機能の一つである vMotion ですが、vSphere 6.0 では更なる機能拡張がなされました。上記のアップデートを踏まえて、更に vMotion を使いこなしていただけたらと思います。最後までお読みいただきありがとうございます。

VMware vSphere Virtual Volumes (VVols) のご紹介

はじめに

VMware vSphere Virtual Volumes は、VMware vSphere 6.0 に初めて搭載されたストレージの機能です。VMware が十数年に渡り提供してきた Hypervisorである、ESX / ESXi はブロックストレージとして、LUN + VMFS の仕組みを踏襲してきました。VVols はこの枠組みを超える革新的な機能で、vSphere ユーザーに多くのメリットを提供します。今回は、この魅力溢れる新機能についてご紹介いたします。
なお、"Virtual Volumes" や "VVols" という言葉ですが、仕組み全体を指す場合と、仮想マシンのオブジェクトを指す場合、またボリュームをマウントする際のデータストアとしての3通りの意味があります。混乱を避けるため、本Blogでは以下のように使い分けたいと思います。(一般的な使い分けではありませんのでご了承下さい)

  • 全体的な仕組みとしての VVols・・・Virtual Volumes
  • オブジェクトとしての VVols・・・ VVols もしくは VVol(特定の単一オブジェクトを指す場合)
  • データストアとしての VVols・・・VVol データストア

Virtual Volumes 登場の背景

ESX / ESXiが長らく踏襲してきた LUN + VMFS という形、とりわけ、VMFS は軽く高機能なクラスタファイルシステムで、バージョンアップと共に、SCSI Reservation の最適化や取り扱える最大ファイルサイズの拡張、VAAIで代表される各種オフロードなど、より大規模環境をハイパフォーマンスでストレス無く扱えるようその機能を拡張してきました。しかしながら、様々な Tier (パフォーマンス要件や可用性要件) を持つシステムが仮想環境に混在するようになると、あらかじめパフォーマンス、可用性、必要容量などを想定して切り出す必要のある LUN という概念では時として柔軟な対応が出来ず、例えば、データストアに空き容量はあるけど要件にあわない・・・、など無駄が生じたり、必要な機能を持つ LUN を新規に切り出すために時間を要したりなど、仮想環境の利点である迅速性を阻害するリスク要因の1つにもなってきました。

また、様々な Tier をサポートするために、同一ホストへの(NFSとFCなどの)異なるストレージ装置や、異なるRAIDレベル、異なるディスクデバイス(SSD、FC、NL-SAS等)が混在して接続されるケースも多くなり、管理者がそのストレージ特性を理解して仮想マシンを最適に配置しなければならない、という管理負荷の面での問題点も顕在化する可能性がありました。


この問題に対処するため、Virtual Volumes では、あらかじめ予測と準備が必要な LUN という仕組みを廃止し、各仮想マシンディスクを1個のVVolオブジェクトとしてストレージが直接管理する仕組みを提供します。このVirtual Volumes の管理側のメリットは大きく、例えば以下のようなことが可能となります。

  • ストレージ側で、あらかじめ容量や可用性などを定義したLUNを作成する必要はない
  • 仮想マシン作成時に必要な容量、可用性を担保したVVolsがダイナミックに切り出される
  • 仮想マシンに必要なストレージの機能が、vSphere側からポリシーとして定義可能
  • 豊富なストレージ機能を直接仮想マシンディスク(VVols)に作用させることが可能
  • ストレージの機能を利用した、仮想マシンディスク毎のバックアップリストアが可能

Virtual Volumes 全体像

Virtual Volumes はいくつかのコンポーネントが連携して動作します。全体像は以下の通りです。


  • VASA プロバイダ
    • ストレージベンダー提供のコンポーネント
    • VVols の作成や複製、削除に関わるコントロールプレーンの機能を提供
      仮想マシンの作成、電源オン、スナップショット作成などの操作の際、必要な VVols を作成する
    • ストレージに実装された機能をvSphere側から把握するためのアクセスポイント
      一つの VASA プロバイダーから複数アレイ管理も可能
    • 実装方法はベンダー依存
      専用管理サーバー(仮想アプライアンス)
      ストレージ Firmware
    • ESXi と vCenter Server は VASA プロバイダーと接続
  • プロトコルエンドポイント
    • ストレージ管理者が定義する、ESXi からのI/O アクセスポイント
      ラウンドロビンやMRU 等のパスポリシーもプロトコルエンドポイントに対して設定される
    • 容量提供を目的としない管理 LUN / NFS 共有の位置づけ
      実容量を持つ、各仮想マシンの VVols は、プロトコルエンドポイントの後ろに存在するサブLUNとして存在
    • 各LUNに対してI/Oパスが定義される従来の方法に比べ、アクセスポイント数を大きく削減
    • SAN と NAS のすべてのプロトコルと互換性

      iSCSI、NFS v3、FC、FCoE

  • ストレージコンテナ
    • ストレージ管理者が定義する、VVols を収容する論理的プール
    • プロトコルエンドポイントの背後で容量を定義
    • 定義や最大コンテナ数はストレージ装置に依存
    • vSphere 管理面からはデータストアの概念

上記の他、データサービスとしてストレージの機能を定義する領域があります。定義された機能は VASA プロバイダ経由で vCenter Server へ通知され、仮想マシン作成の際利用されます。

既存の LUN + VMFS と、Virtual Volumes におけるコンポーネントの実装の比較は以下の通りです。I/O アクセスや容量、サービスレベルを画一的に定義していた LUN を、それぞれプロトコルエンドポイント、ストレージコンテナ、ストレージポリシーに分解、定義していることが分かります。また、繰り返しになりますが、LUN は事前に作成され、複数の仮想マシンを収容しますが、Virtual Volumes では、仮想マシン作成の際に VVols が直接ストレージに作成され、オブジェクトの粒度も仮想マシンディスクそのものとなります。


Virtual Volumes セットアップ

Virtual Volumesは、ストレージと連携した機能です。このため、Virtual Volumes 利用には対応したストレージが必要となります。Virtual Volumes をサポートするストレージに関しては、こちらをご確認下さい。また、Virtual Volumes が利用可能な vSphere の License に関しては、こちらからご確認いただけますが、Standard 以上となっています。
セットアップの際も、まずはプロトコルエンドポイントや VASA プロバイダ、ストレージコンテナ等をストレージ装置側で設定しておく必要があります。セットアップ方法はストレージ装置毎に様々で、例えば VASA プロバイダが、ストレージコントローラに内蔵されていて、サービスを起動させるのみという簡単セットアップというストレージ装置もあれば、仮想アプライアンスをデプロイしてセットアップを完了させるストレージ装置もあります。ストレージコンテナも、装置丸ごと1つ見せることを基本とするストレージ装置もありますし、最初から細かくストレージコンテナを定義できる物もあります。これらの設定方法に関しては、各ストレージベンダーのマニュアルをご確認下さい。

ストレージ装置側で、上記コンポーネントの定義や、ストレージ装置へのESXiホストの登録などが完了すれば、そこから先は vSphere 側からセットアップを進めることが出来ます。

 

1. VASAプロバイダをvCenter Serverに登録します。

VASAプロバイダの登録自体は非常に簡単です。登録も各ストレージ装置毎に方法が異なりますが、HP社の3PAR StoreServ (以下3PAR)におけるVASAプロバイダ登録画面は以下の通りです。


2. プロトコルエンドポイントの認識

通常の HBA のリスキャンを実行することにより、ESXi ホストにプロトコルエンドポイントが見えてきます。


こちらもストレージ装置により様々ですが、ブロックデバイスでは、プロトコルエンドポイント用に非常に小さな LUN が1つ見えます。3PAR の場合はLUN番号が 256 で、512 Byte の小さなLUNとなっています。


ラウンドロビンや MRU 等のパスポリシーもプロトコルエンドポイントに対して設定されていることが分かります。プロトコルエンドポイントがホストから見えると、自動的にその裏側にあるストレージコンテナもホストから見える様になり、データストアとしてマウントすることが可能となります。


 

3. VVol データストアのマウント

ストレージ装置で作成されたストレージコンテナをVVol データストアとしてESXi ホストにマウントすると仮想マシンの作成が可能となります。仮想マシン作成の際、指定を行うストレージポリシーに関するご説明はこちらをご確認下さい。なお、定義可能なストレージポリシーはストレージ装置により異なります。


VVols オブジェクトの種類と仮想マシン作成時の動作

仮想マシンを作成すると、仮想マシンオブジェクトとして複数の VVol が作成されますが、この VVol にはいくつかの種類があります。この種類と実際のVVol 作成の動作についてご説明します。まず種類ですが、以下の5種に分類されます。

  1. Config-VVol・・・仮想マシン構成(vmx ファイル)、ログ
  2. Data-VVol・・・VMDK やスナップショット
  3. Swap-VVol・・・Swap ファイル(仮想マシン起動時のメモリスワップ領域)
  4. Mem-VVol・・・メモリー付きスナップショット取得時やサスペンド等、仮想マシンのメモリデータ
  5. Other-VVol・・・その他ソリューション用途


仮想マシンを作成すると、仮想マシン基本VVolである、1. Config-VVol と、2. Data-VVol が作成されます。次に仮想マシンの電源を On すると、3. Swap-VVol が作成されます。上記キャプチャは、仮想マシン作成の後、PowerOn し、さらに、仮想マシンのメモリ付きスナップショットを取得したときに作成される5個の VVol を示しています。この様に、1つの仮想マシンに対して複数の VVol が作成されますが、データストアブラウザで見ると通常の VMFS ボリュームに作成された仮想マシン同様、1つの仮想マシンのパスの中に各データが保存されているように見えます。つまり、仮想環境の管理者が直接 VVols オブジェクトを意識する必要はありません。


VVols のバインド

直接管理者の目に触れる部分ではありませんが、プロトコルエンドポイント背後に存在する、各 VVols が ESXi ホストからアクセス可能となる仕組みをご説明します。仮想マシンの作成やパワーオン操作に伴い際に作成された VVols はプロトコルエンドポイントのサブ LUN として定義され、バインドという処理を介して ESXi からアクセス可能となります。簡単に申し上げると、バインドはアクセスを必要とする ESXi に対しストレージ装置が作成した VVols オブジェクトを見せてあげる処理、ということになります。具体的には以下の通りです。

  1. ESXi が VASA プロバイダ経由でバインド処理を発行
  2. ストレージ装置はプロトコルエンドポイント ID と実際の I/O 発行先であるサブ LUN ID (VVols オブジェクト ID )を応答*
    *NFSの場合は、ファイルパスとなります
  3. ホストよりアクセス可能(1:1のマッピングにより排他処理)となります


この処理の実行により、ESXi ホストは対象 VVols に対して I/O の実行が可能となります。

Virtual Volumes のメリット

Virtual Volumes のメリットは以下の通りです。

  • 豊富なストレージ機能を直接仮想マシンディスク(VVol)に作用させることが可能
    スナップショット、クローン、フラッシュキャッシュ、重複排除、暗号化、リモートレプリケーション...etc
  • 仮想ディスク毎に必要なストレージの機能を、vSphere 側からポリシーとして定義可能
  • アクセスポイントをプロトコルエンドポイントに集約することにより、最大 LUN 数の問題を回避

    多数の RDM を運用されているユーザには大きなメリットとなります

例えば、vSphere Web Client 上から仮想マシンのスナップショットを取得すると、VMFS 上の仮想マシンであれば、VMFS がサポートする Redo log ベースのスナップショットとなりますが、Virtual Volumes の場合は、同一のオペレーションでストレージベースのスナップショットとなります。特に I/O 要件の高い仮想マシンのバックアップに、VADP + VMFS ベースのスナップショットを利用している場合にはこのメリットは極めて大きく、スナップショット作成時、削除時にほとんどパフォーマンスの劣化の無い安定したバックアップの取得が可能となります。*

 *ストレージがサポートするスナップショットの機能に依存します。

まとめ

リリースされたばかりで対応ストレージがまだ少ない点、ポリシーで定義可能な項目が本来のパフォーマンスや可用性を伴っていない点など、現状では課題も垣間見えるのですが、Virtual Volumes は非常に将来性豊かなストレージの新機能です。また、vSphere の Standard License から利用可能というところも見逃せない点です。今後の機能拡張にもご期待下さい!

Hiroshi Okano

岡野 浩史

リードシステムズエンジニア (VCP3/4/5-DCV, VCP-NV, VCAP4/5-DCA, VCAP4/5-DCD)
エコシステム含めたパートナービジネスの拡大をミッションとしているエンジニアです。前職ではx86ベンダーやCPUベンダーといったハードウェアエンジニア畑を歩んできましたので、デバイスレベルの動きやHPC等のベンチマーク等に深い知識を持ちます。PartnerExchange や vForum などのイベントでは、リリース前の vSphere Core の機能紹介や Virtual SAN のセッションを担当する機会も多いので、”どこかで見たことのある顔”と思われる方もいらっしゃるのではないかと思います。今後もこの様な活動を続けていく予定です。よろしくお願いします!