Home > Blogs > Japan Cloud Infrastructure Blog

vSphere ユーザー向け技術資料2種 「事例に学ぶ仮想化導入成功ノウハウ」&「10の技術ポイント」のご案内

こんにちは。マーケティングを担当している坂本です。本日はvSphere をお使いの方向けの資料2種、「お客様の管理画面を公開!事例に学ぶ仮想化導入成功ノウハウ」Ebookと「vSphere を管理する10の技術ポイント」という2つの資料をご紹介します。是非ダウンロードして御覧ください。

Ebookは vSphere with Operations Management を使い、自社の仮想化環境の運用を効率化された方のお話を元に作成いたしました。

  • IT 部門の課題とそれを解決した VMware ソリューション
  • Q&A 形式でご紹介するお客様の声
  • 管理ダッシュボードのカスタマイズ例

という3つのステップでそれぞれの特長を紹介しており、vSphereを管理されている方には参考になると思います。  (ダウンロードはこちら

eBook

また、 「vSphere を管理する10の技術ポイント」では、潜在的な課題を事前に検知して問題解決を効率化する10のポイントを、

  • 健全性監視とパフォーマンス分析
  • キャパシティの管理と最適化
  • 直感的に操作可能な運用ダッシュボードと根本原因の分析

という3つの軸に注目して紹介しております。是非御覧ください。(ダウンロードはこちら

Tech Tips
これらの資料は米国VMware 作成の資料の翻訳版です。翻訳のご要望はこのブログのコメントやTwitter  https://twitter.com/VMware_Japan へのメンションでお受付しております。 ご要望もお寄せください。

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

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

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

NWV02-01-02

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

NWV02-02

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

 

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

NWV02-03-02

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

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

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

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

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

 

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

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


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

NWV02-04

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


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

NWV02-05

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

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

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

補足情報:論理スイッチを構成する際、VTEP間の通信にマルチキャストを使用するモード(マルチキャストモード)と、使用しないモード(ユニキャストモード)、及び併用するモード(ハイブリッドモード)を選択できます。この後の説明は、ユニキャストモードを前提に進めています。ユニキャストモードでは、コントローラでVTEP テーブルを集約して管理することで、物理ネットワークでマルチキャストを運用する必要がありません。

 
———-
STEP0: ネットワーク仮想化環境は、ハイパーバイザとコントローラ間で各種テーブル情報を交換するコントロールプレーンと、VTEP 間で仮想マシントラフィックを転送するデータプレーンから構成されています。2台のESXi ホスト上でVNI(VXLAN Network Identifier 物理環境のVLAN IDに相当)5001 に接続している端末間の通信を確認してみます。端末A,B は、論理スイッチ VNI 5001 に対応するポートグループに接続し、電源がOFF の状態になっています。

NWV02-06


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

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

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

NWV02-07


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

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

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


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

NWV02-08


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

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

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

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

上記よりESXi01 が、VXLAN5001 の転送先としてESXi02のVTEP を認識していることが分かります。

 
———-
STEP2: 仮想マシンから通信が発生した際、カーネルモジュールが通信の送信元MAC アドレスから、仮想マシンのMAC アドレスを認識します。認識した仮想マシンのMAC アドレス情報をコントローラクラスタに通知します。

NWV02-09

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

上記よりコントローラでは端末A,BのMACアドレスと、対応するVTEP を認識していることが分かります。

 
———-
STEP3: 仮想マシンのIP アドレス情報を含む特定の通信(ARP ResponseもしくはDHCP ACK)から、カーネルモジュールが仮想マシンのIP アドレスとMAC アドレスを認識します。認識した情報をコントローラクラスタに通知します。ARP 抑制(ARP Suppression)が有効な場合、このステップが実施されます。

NWV02-10

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

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

上記よりコントローラでは端末A,B のARP テーブル情報を認識していることが分かります。

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


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

NWV02-12

ハイパーバイザでの確認方法
ESXi01 # esxcli network vswitch dvs vmware vxlan network arp list --vds-name=Compute_VDS --vxlan-id=5001
IP(端末のIP)		MAC(端末のMAC)	
------------		-----------------		
172.16.10.12(端末B)	BB:BB:BB:BB:BB:BB(端末B)

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


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

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

NWV02-13

ハイパーバイザでの確認方法
ESXi01 # esxcli network vswitch dvs vmware vxlan network mac list --vds-name=Compute_VDS --vxlan-id=5001
Inner MAC(端末のMAC)		Outer MAC(VTEPのMAC)		Outer IP(VTEPのIP)
-----------------		-----------------		-------------	
BB:BB:BB:BB:BB:BB(端末B)	02:02:02:02:02:02(ESXi02)	172.16.250.52(ESXi02)

上記よりESXi01 は、ESXi02 上に端末B が存在することを認識していることが分かります。

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


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

NWV02-14


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

 

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


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


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

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


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


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


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

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

NWV02-15

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

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

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

NWV02-16

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

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

 

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

NWV02-17

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

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

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

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

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

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

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

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

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

NWV02-18-02

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

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

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

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

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

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

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

 

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

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

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

VMwareテクニカルトレーナーよりワンポイントアドバイス~シェアと予約をおさえよう!~

こんにちは。VMware EducationのテクニカルトレーナーのSatokoです!!!
前回は、物理のCPUやメモリがどのように仮想レイヤと紐づいているか、お話させていただきました。その中で仮想環境では物理的なリソース量に対して、その物理量を超えた仮想マシンを載せることができること  (= 設定時におけるオーバーコミット状態 ) についても触れました。今回は、多くの仮想マシンを載せてしまったが、実際運用時ではどのようにリソース制御をすればよいか?の基本をお話します。

■物理リースを超えた仮想マシンのリソース総量

例えば、VMware ESXi ホスト ( ESXi ) 上に、Webサーバ、Appサーバ、DBサーバ、Fileサーバ等の仮想マシン(仮想マシン)を構成しています。

図1

 

図1 が示すように、
40GB(ホストの持つメモリリソース)  <  43GB(仮想マシンに設定されたメモリリソースの合計)
となり、ESXi ホストがもつ40GBメモリーリソース以上に仮想マシンのメモリリソース合計が設定されている状態です。この状態はどうかといういうと、設定されている値 (ここでは43GB )をすべて使用するとは限らず、必要な分だけ各仮想マシンに割り当てられていますので、物理のリソースを超えた設定自体がパフォーマンスに影響を与えるものではないことを、前回もお話しました。

続いてCPUリソースをみていきましょう

図2

図2

 

こちらもvCPU数が物理のコア数を超えていても、それぞれの仮想マシンが必要な時に必要なCPUリソースを配分されることで、パフォーマンスに影響なく複数のサービスの提供が可能です。そのため、設計時にそれぞれの仮想マシンのリソース消費のピークが重ならないように組み合わせを考慮することが重要になります。

図3

図3

図3のように、CPUリソースが競合した場合には、処理の遅延が発生することでパフォーマンスへの影響が懸念されます。
メモリリソースもCPUリソースもオーバコミットしていること自体パフォーマンスへの影響はないのですが、リソースを有効に使用する!という仮想基盤の特性上、このリソース競合とどう付き合っていくか?がとても大事になってきます。今回は、その仮想基盤の特性上欠かせない、リソース制御の「シェア」と「予約」の基本についてみていきます。

■CPU/メモリリソース制御における「シェア」を押さえよう

CPUのシェアの考え方

まず、CPUのシェアをみていきましょう。シェアはリソースが競合してしまったときに、設定した「シェア値」でリソース配分を決めることができます。

図4

図4

 

上記の図4で、CPUリソースの割り当てを具体的に見てみましょう。

物理CPU:3GHz×1
各仮想マシンvCPU:3GHz×1

1つの物理Coreを2つの仮想マシンvCPUで共有しているパターン(合計2vCPU)です。

リソースが競合した場合、シェアの値によって、リソースが割り当てされます。
デフォルトであれば、各vCPUは、1.5GHzのCPUリソースが均等にハイパーバイザによって割り当てられます。もちろん共有している物理CPUは1つなので、所有できる時間をシェアの値によって優先度を変えています。

例えばシェアの値を変えてみましょう。シェア値を大きくすることによって、特定の仮想マシンに対してより優先的にリソースを分配することが可能なのです。(図5)

図5

図5

メモリシェア編

同様に図6で、メモリシェアの割り当ても具体的に見てみましょう。

図6

図6

ESXi ホストの持つ 6GB の物理メモリを2つの仮想マシンで共有しているパターンです。
この例では、6GB の物理メモリリソースでは、各仮想マシンに設定された4GBが割り当てられるわけではなく、仮想マシンでのメモリ使用量合計が 6GB を超えた場合 (= 競合状態) にシェアの値が働きます。シェア値がデフォルトであれば、各仮想マシンは、3GBずつのメモリリソースが均等にハイパーバイザによって割り当てられます(左図)が、 シェア値を大きくすることで、優先的にリソースを分配することが可能です(右図)。

リソースの競合が起きたとき、デフォルトでは、均等にリソースは割り当てられますが、競合時にCPUメモリリソースを優先的に割り当てたいシステムは存在します。 競合発生時、それぞれのサーバが必要とするリソースが均等ではないのであれば、ここは、管理者が優先度に従い、割合を指定していくことで柔軟にリソースの割り当てを実施していきます。

 

■「予約」の基本 ~CPU編~

シェア値の設定によって、リソース競合時の優先度を定義できるのですが、シェアは、あくまでも割合の指定です。
例えば、Applicationのために十分なパフォーマンスを確約したいということであれば、具体的な数値で指定する「予約」の値を指定することで、より確実に指定したリソースを担保することも可能です。

図7

図7

CPUリソースの予約を指定した場合を見てみましょう。

1Coreを4つの仮想マシン(vCPU)で共有しているパターン(合計 4vCPU )です。
予約の値はデフォルト設定されていません。予約の値を設定することで、CPUリソースは、起動時や運用時のCPUリソースの割り当てを担保することができます。
CPUリソースは、ハイパーバイザによって割り当てられます。CPUリソースは、指定した予約の値のCPUリソースを使用していない時は、別の仮想マシンにCPUリソースが割り当てられ、より柔軟にCPUリソースは活用されます。

■「予約」の基本 ~メモリ編~

続いてメモリリソースの予約を見ていきましょう。

図8

図8

ESXi ホストの持つ物理メモリ 6GB を4つの仮想マシンで共有しているパターンです。

CPUリソースと同様に、デフォルトでは予約は設定されていません。A_VMの予約値を2GBと指定することで、2GB が起動時にハイパーバイザによって確保されます。A_VMが予約されたメモリリソース以上のメモリリソースが必要な場合は、残る共有リソースから割り当てられることになります。
予約は特定の仮想マシンがリソースを占有することになります。すなわち、仮想化のメリットであるリソースの共有を最大限に生かすのであれば、予約値を必要最低限にしておくのがコツです♪

 

■設定してみよう!

それでは各仮想マシンに対するシェアと予約の設定方法を見ていきましょう。各仮想マシンを右クリックして「リソース設定の編集」を開きますデフォルトの設定では、下記のように、シェアは「標準」、予約は「0」となっています。

図9

図9

CPUを例にシェアの値を指定してみましょう。仮想マシンに割り当てたシェアの値を、ESXi ホスト側からも確認することができます。この例の場合、CPUのシェアが4 (高): 2 (標準): 1 (低)になっていることが分かります。このように優先順位が指定されます。予約に関しても同じ画面で設定することができますので、設定自体はとても簡単ですね♪

 

図10

図10

今回は、リソースの制御方法である「シェア」と「予約」を見てきました。 安全に多くの仮想基盤を運用するには、このリソース管理の考え方が基本になってきます。ここでは、単体のESXi ホスト上でのリソース制御を紹介しましたが、クラスタ(複数のESXiホストをグループ化)のリソース制御では、リソースプールが利用できます。それはまた次の機会にお話したいと思います!

VMwareテクニカルトレーナーよりワンポイントアドバイス
第1回:VMware vSphereにおけるCPU・メモリの考え方編
第2回:シェアと予約をおさえよう!(本記事)

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

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

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

 

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

NWV01-01

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

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

 

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

NWV01-02

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

NWV01-03

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

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

NWV01-04

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

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

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

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

 

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

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

NWV01-05

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

NWV01-06

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

NWV01-07

 

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

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

NWV01-09

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

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

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

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

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

 

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

速報!VMware vSphere 6.0 新機能の概要

2015年3月12日に、vSphereの次バージョンとなる、VMware vSphere 6.0(以下vSphere 6.0)が公開されましたので、こちらのバージョンで追加された新機能・特徴の概要をご紹介します。

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

 

1.スケーラビリティ

以前のバージョンに比較して、ESXiホスト/仮想マシンのスケーラビリティが大きく拡張しております。

vCenterに関してもWindows版/アプライアンス版ともに下記の通り、管理可能なホスト数や仮想マシン数が拡張しております。

詳細な「構成の上限」に関する情報は、弊社ドキュメントを参照下さい。

 

2.プラットフォーム機能

  • ローカルの ESXi アカウントおよびパスワード管理の強化・・・ユーザーのアカウントのロックアウトや詳細設定による、複雑なルールが設定可能になり、ESXi の管理操作の監査性が向上しました。
  • Microsoft Cluster Service (MSCS) の機能拡張・・・MSCS 仮想マシンの vMotion をサポート。

 

3.vCenter Server

  • Platform Services Controller の導入・・・Platform Services Controller (以下 PSC)が導入され、単なるシングル サインオンの機能に加えてライセンス、証明機関の役割を持ちます。これにより柔軟な構成が可能になります。
  • 拡張リンク モードの使用・・・拡張リンク モードを使用することにより、すべてのリンクされた vCenter Server システムを表示し、まとめて検索することができます。

  • vCenter Server と ESXi の証明書ライフサイクル管理・・・vSphere 6.0 以降では、VVMware 認証局 (VMCA) が証明書を使用して環境のプロビジョニングを行います。これには、安全な接続用のマシン SSL 証明書、vCenter Single Sign-On への認証用のソリューション ユーザー証明書、vCenter Server に追加された ESXi ホスト用の証明書が含まれます

 

4.コア機能の強化

  • VMware vSphere vMotion(以下 vMotion)

vMotionについては、主に下記点で機能強化・改善が行われております。

 

・Cross vSwitch vMotion(別の仮想スイッチへの移行)・・・異なるタイプの仮想スイッチ間で仮想マシンを移行が可能です、但しDistributed Switch から標準スイッチへの vMotionは不可となります。(標準から標準または Distributed Switch に、および Distributed Switch から別の Distributed Switch に仮想マシンを移動することができます。)

・Cross vCenter vMotion(別のvCenter Server システムへの移行)・・・異なる vCenter Server インスタンス間で仮想マシンを移行。

・Long Distance vMotion(長距離 vMotion 移行)・・・ネットワークの最大往復待ち時間は 100 ミリ秒までの環境下で仮想マシンを移行。

・vMotion ネットワークの柔軟性の向上・・・vMotion TCP/IP スタックを使用して、vMotion のトラフィックを隔離し、このトラフィックの専用デフォルト ゲートウェイ、ルーティング テーブル、および DNS 構成を割り当て可能。

 

  • コンテンツライブラリの導入・・・仮想マシン テンプレートと vApp を簡単かつ効率的に管理が可能になります。

 

  • vSphere Fault Tolerance (FT)・・・vSphere Fault Tolerance は、最大で 4 つの vCPU を持つ対称型マルチプロセッサ (SMP) 仮想マシンに対応できます。以前のバージョンの vSphere(vSphere5.5以前) とは、Fault Tolerance に異なる技術が使用されております。

 

  • vSphere HA・・・仮想マシンのコンポーネント保護 (VMCP) の導入により、vSphere HA はデータストアのアクセス障害を検出して、影響を受ける仮想マシンの自動リカバリを実行できます。

 

5.仮想マシン

  • サポートゲストOSの拡張(詳細は互換性ガイドを参照ください)
  • ハードウェアバージョンのアップデート(ESXi 6.0以降:Virtual Hardware version 11)
  • 仮想マシンは、最大128個の仮想CPUと、4 TBの仮想メモリをサポート

 

6. Client

  • Web Clientの応答性が向上

 

7.ネットワーク

  • Network I/O Control バージョン 3・・・ホスト上の物理アダプタのキャパシティに基づいて、システム トラフィックのバンド幅を予約するメカニズムを導入しています。これにより、CPU およびメモリ リソースの割り当てに使用するモデルと同様に、仮想マシン ネットワーク アダプタ レベルでリソースを詳細に制御できます。

 

8.ストレージ

  • vSphere Virtual Volumes・・・外部ストレージアレイを仮想マシン単位で管理することができます。
  • 仮想マシン ストレージ ポリシー・・・ストレージ情報およびデータストアの特性を、特定のデータストアタイプ共通の管理機能を提供します。これにより、仮想マシンの配置について適切に決定し、ストレージ環境を監視することができます。
  • VMware Virtual SAN 6.0
・All Flash のサポートによるパフォーマンス・スケーラビリティの向上。
・ユーザビリティの向上(vSphere Web Client UIでサポート)。
・信頼性向上。

 

9.その他

  • VMware vSphere Replication

・End-to-End でのネットワークの圧縮・・・帯域幅の要件をさらに削減

・ネットワーク トラフィックを管理ネットワークから分離・・・帯域幅を制御し、パフォーマンスとセキュリティを向上

・Linux ファイル システムの静止機能 (quiescing)・・・Linux 仮想マシンをリカバリする際の信頼性を向上

 

次回から、各機能の詳細な情報をご紹介していきます。

VMwareテクニカルトレーナよりワンポイントアドバイス~VMware vSphereにおけるCPU・メモリの考え方編~

こんにちは!VMware EducationのテクニカルトレーナーのSatokoです!!
みなさん、「Tech Day」というイベントをご存知でしょうか?すでにVMware製品をお使い、または導入検討されているエンドユーザ様に無償で提供している大人気イベントです。(今年も2月に実施予定です) TechDayでは実際QAタイムを設けて、実際に今困っていることや今更聞けない基本的なこと等、機能や使い方に関して、多くのご質問をいただいています。その中で多いご質問が、CPU、メモリリソースに関してのご質問です。
今回は、この場をお借りして、vSphere環境におけるCPUやメモリの見え方や考え方を復習していきます。

§1.vSphereにおけるリソースの扱い方~CPU編~

まず物理CPUにおける用語 「ソケット」 「コア」 「スレッド」をみていきます。

図1

ソケットとは、コアをマザーボードに装着するための、穴の空いた板状の部品で、ピンを差し込んで固定して使用します。
コアは、実際に演算を行う部分です。昨今ではソケットに複数のコアを搭載しているタイプが多いです。スレッドは、一連の命令が順番に処理されていく流れ(最小の処理単位)のことです。スレッドは、「LCPU」とも呼ばれます。仮想マシンはこのLCPUをあたかも自分が認識している”CPU”として扱います。では、物理のCPUと仮想マシンで認識するCPU = vCPUとの紐付きを確認していきましょう。

 

 

図2

 

上記の図2 1ソケットに4コアあるCPUでは、仮想マシンで構成できるvCPUの数は最大4つとなります。仮想マシンに割当てるvCPUは物理の持つコア数を超えない範囲で割当て可能です。例えば、1ソケット4コアを搭載している物理サーバの場合、その上で動作する仮想マシンに割当てられるvCPUの上限は4つになります。その上限の中で、各仮想マシンにvCPUの割り当てが可能になります。上の例ですと、向かって左からVM1,2にvCPUが4、VM3にvCPUが2、VM3にvCPUが1割当られ、合計11個のvCPUが割当てられてます。
※ハイパースレッドが有効な場合は、ハイパースレッドがLCPUとなります。

図2のように物理ソケットx1 コアx4コア構成で、仮想マシンに割当てられているCPU数(vCPU)合計は11個となっております。これがよく言われる仮想基盤特有の”オーバコミットされている状態”であり、物理リソースを有効にしようする為の考え方になります。

 

§2.どのように物理CPUが仮想マシンに割り当てられているのか?

では、実際にこの“仮想が物理を超えている状態”で内部的にはどのように動作しているのかを見ていきます。基本動作は、空いているLCPUをハイパーバイザがスケジュールしながら、仮想マシンに割当てしていく、というシンプルなものです。

ただし、vCPUに割当てられている全てのvCPUを必ず同時に割当てることを前提にすると、必要なvCPU数分のLCPUが空いていない割当てられない!事態になってしまいますが、そこはご安心ください。ハイパーバイザレベルで仮想マシンのCPU処理を矛盾なく行うよう最適化されております。オーバコミットの比率が高ければ高いほど、スケジューリングの処理が重くなってしまうこともありますので、まずは必要最小限のvCPU数で仮想マシンを構成することをおススメしております。

 

§3.vSphereにおけるリソースの扱い方~メモリ編~

次に、メモリリソースの扱い方をみていきましょう。
例として、800MBのメモリが割当てられている仮想マシンにアクセスします。「仮想マシン」→「監視」→「リソース割り当て」でメモリ情報をみると 「ホストメモリ」 と 「ゲストメモリ」 が見えてきます。

図4:ホストメモリとゲストメモリ

 

この「ホストメモリ」「ゲストメモリ」ちょっとわかりにくいのですが、例えていうならば、どこから仮想マシンを眺めるか?という目線だとイメージしやすいかもしれません。

ホストメモリ:ハイパーバイザから仮想マシンを眺めている目線
ゲストメモリ:仮想マシンの中で眺めている目線

この仮想マシンをPoweronして「ホストメモリ」の状態をみてみましょう。

図5:仮想マシンPoweron/ホストメモリ

 

消費:443MB、オーバヘッド 25MBとあります。これはこの仮想マシンが物理メモリを443MB使用している状態を示しています。(物理メモリ800MB丸々使用してるわけではありません!)オーバヘッドとはこの仮想マシンを動かすためのリソースであり、ハイパーバイザから眺めているからこそ見える値です。このオーバヘッドの値は仮想マシンの構成や負荷によって変動するものです。

 

図6:仮想マシンPoweron/ゲストメモリ

 

一方上の図は「ゲストメモリ」(=仮想マシンの中から眺めている)になりますが、図中の”プライベート”の値が418MBとなっております。これはちょうど443MBからオーバヘッドの値を引いた値となっておりますね。すなわち、純粋に仮想マシンが使用しているメモリ量です。そのプライベートをつかさどる値も 「共有」 「バルーン済み」 「圧縮済み」 「スワップ済み」 等から構成されております。それぞれをざっくりですが、簡単に紹介します。

共有:メモリページを仮想マシン同士で共有する仕組み 透過的ページシェアリング(TPS)
※ 共有(TPS)はバージョンによってデフォルトの設定が異なります。http://kb.vmware.com/kb/2097593
バルーン済み/圧縮済み/スワップ済み:仮想マシン同士でメモリを有効に再利用する仕組み
有効なゲストメモリ:現在アクティブ状態のメモリ値

メモリリソース用語の詳細は、以下のKBを参照ください

http://kb.vmware.com/kb/2017642

§4.メモリをより有効に活用する

CPUと同様、メモリも物理メモリ以上に仮想マシンにメモリを割当てることが可能です。下の例は検証環境なので、とても小さいESXiホストですが、物理メモリ約5GBを搭載しています。ここに仮想マシン割当てメモリ合計約7Gの仮想マシンがPoweronしております。

図7:オーバコミット状態におけるPoweron

ESXiホストの持つ物理メモリリソース(5GB) < 仮想マシンに割当てられたメモリリソースの合計 (7GB)

仮想マシンに割当てられたリソース量が、物理メモリリソースの合計値が上回ったとしても、それ自体が問題になることはありません。もちろん、”盛りすぎ”はパフォーマンスに影響がでてしまいますのでその辺をどう加減していくかが仮想基盤を有効使用していく為の肝になります。

このように仮想環境では、仮想マシンへのリソース割当てを実際の物理リソース以上に割当てることが可能となり、物理環境と比較して、より物理リソースを有効に使用できる仕組みを備えています。そこが仮想環境のメリットでもありますが、逆にリソース管理が難しい側面も持ち合わせております。

次回はリソース管理の仕組みを少しお話させてもらいますね♪

エンドユーザ様向けTech Day 2015のお知らせ

Techday2015
今年は2/10東京、2/13に大阪で開催!

VMware TechDay は、ユーザー企業・団体の方向けに認定教育コースの講師が実施する 1日の技術セミナーです。VMware vSphere を使用されている方や、評価を開始されている方を対象に、vSphere を使いこなすことで、その価値を十分に享受いただくことを目的としております。本ブログの内容もお話させていただきますので、ぜひご参加くださいネ!
※ユーザー企業・団体の方に限定させていただきます。あらかじめご了承ください。

VMwareテクニカルトレーナーよりワンポイントアドバイス
第1回:VMware vSphereにおけるCPU・メモリの考え方編
第2回:シェアと予約を押さえよう!

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

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

20141226-v2c-01-2

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

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

 

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

20141226-v2c-02-2

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

 

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

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

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

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

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

 

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

20141226-v2c-05-2

 

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

20141226-v2c-04-2

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

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

 

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

新卒 SE 社員が贈る vSphere のキソ!第8回 ( 追加編 ) 〜 まだまだあった!ストレージ関連機能 〜

みなさん、こんにちは! VMware SE の氏田 ( Ujita ) と申します。
本エントリでは、前回ご好評頂いた新卒ブログの追加編として、VMware vSphere のストレージ関連機能である vFRC 、Multipathing 、VAAI をご紹介します!

 

~ はじめに ~

私は以前、新卒ブログシリーズにて vSphere のキソ!第5回 を担当させていただきましたが、その中でストレージに関する機能として、 SIOC と Storage DRS を挙げさせていただきました。これらはいずれも vSphere 単体による工夫でしたが、ストレージのパフォーマンスを向上させる機能の中には、ESXi サーバ内の SSD や外部のストレージの機能と連携できるものがあります。それが、今回ご紹介する vFRC ( vSphere Flash Read Cache ) 、Multipathing 、VAAI ( vStorage API for Array Integration ) といった機能になります。

 

§ 1 . vFRC ( vSphere Flash Read Cache )

まずは、vFRC からご紹介していきます。vFRC とは、ESXi サーバ内の SSD を仮想マシンの読み取りキャッシュとして利用する機能です。SSD を内蔵している ESXi サーバ上に読み取りパフォーマンスを向上させたい仮想マシンがある場合、仮想マシン単位 ( 正確には、vmdk 単位 ) でキャッシュ領域を割り当て可能です ( 図 1 ) 。

 

vFRC
図 1 . vFRC

 

ESXi サーバには、図 2 のように、SSD を仮想フラッシュリソースとして追加できます。

 

仮想フラッシュリソース管理
図 2 . ESXi サーバにフラッシュリソースを追加
( ※ フラッシュリソースの用途としては、今回ご紹介する読み取りキャッシュの他に、ESXi ホストのメモリスワップ領域として利用する方法もあります )

 

仮想マシンのキャッシュ領域は、このフラッシュリソースから切り出されて提供されます。仮想マシンへのキャッシュ領域の割り当ては、サーバにフラッシュリソースを追加後、インベントリから仮想マシン名を右クリック -> [設定の編集] から簡単に行うことが出来ます( 図 3 )。仮想マシンに特別な変更を加える必要はありません。

 

仮想マシンへ読み取りキャッシュ領域を追加
図 3 . 仮想マシンへのキャッシュ領域の割り当て

 

前回ご紹介した SIOC は、特定のストレージへ I/O が集中した場合、優先的に I/O を通す仮想マシンを設定できる機能でした。これに対し、vFRC では、仮想マシンのストレージパフォーマンス自体を向上させる事が可能です。特に、読み取りが多く、遅延に敏感なアプリケーションを実行している仮想マシンに有効です。キャッシュ内にデータがある場合、ストレージへアクセスする必要は無いので、ストレージの負荷を減らすことができるというのも大きな利点となります。

 

§ 2 . Multipathing

次に、Multipathing についてご紹介します。図 4 に示したように、ESXi サーバ – ストレージ間のパスは複数存在します ( 実際には、ESXi サーバが複数あるためもっと複雑 ) 。Multipathing は、このパスを効率よく利用するための機能であり、仮想マシンが共有ストレージにアクセスする際、どこを通ればパスの負荷を分散できるかを常に考えてくれます。

 

Multipathing
図 4 . サーバ – ストレージ間のパス

 

ご存じの通り、仮想環境では一台のサーバ上でたくさんの仮想マシンが稼働するため、物理環境と比べサーバ – ストレージ間のパスが大変混み合います。従って、サーバ – ストレージ間のパスの負荷を分散させることは非常に重要です。ESXi サーバがどのようにパスを選択するかの基準を、パス選択ポリシー ( PSP : Path Selection Policy ) といいますが、vSphere のデフォルトの機能だと、パス選択ポリシーには、最近の使用ラウンドロビン固定の3つしかありません ( 図 5 ) 。

 

vSphere_PSP
図 5 . パス選択ポリシー

 

vSphere では、ストレージの種類を見て、最適なパス選択ポリシーを自動で設定してくれますが、これら 3 つのポリシーはどれも機械的なものであり、パスの負荷が適切に分散されるわけではありません。特定のパスに負荷が偏ると、レイテンシが発生し、アプリケーションの安定稼働に影響を与える可能性があります。

これに対し、Multipathing は、ストレージベンダが提供する専用のマルチパスの仕組みを利用します。これにより、インテリジェントかつ動的なパスの選択が可能になるため、パスの負荷が平滑化されます。以前、私が書いたブログで NIC の負荷分散機能である LBT ( Load Based Teaming ) をご紹介しましたが、適切なパスを選択して負荷を分散するという考え方は同じです。

Multipathing を利用することで、パスの帯域を最大限有効に使うことができるので、I/O 要求が混み合っている場合でも安定したストレージパフォーマンスを期待できます。

 

§ 3 . VAAI ( vStorage API for Array Integration )

最後に、VAAI についてご紹介します ( ※ VAAI を利用するには、vSphere の Enterprise 以上のエディション、ストレージのファームウェア対応が必要となります )。VAAI を有効にすることで、ストレージが持つ機能と vSphere が連携し、仮想環境におけるストレージパフォーマンスを向上させることができます。

例えば、仮想環境のストレージには、以下の課題があります。

    ( 1 ) 大量の仮想マシンからのアクセス
    ( 2 ) 仮想マシンファイル ( 大容量 ) のコピー、移動が頻発
    ( 3 ) ストレージへの 0 書きが頻発

VAAI は、これら仮想環境特有のストレージ処理を効率よくこなすための仕組みを提供します。以下、それぞれの課題を VAAI がどのように解決するかについてご説明します。

 

( 1 ) 大量の仮想マシンからのアクセス

今までは、たくさんの仮想マシンが同一のストレージを利用することによって I/O が混雑するというお話をしていましたが、実はもう一つ大きな課題があります。それが、ストレージの排他制御です。排他制御はデータの整合性を保つために必要ですが、これはファイルシステムのメタデータを更新する場合にのみ実行されます。しかし、仮想環境では多くの仮想マシンからアクセスが発生するため、排他制御により生じる待ち時間は馬鹿になりません。そのうえ、vSphere の標準機能の場合、排他制御は LUN 全体をロックすることにより行われるため、同じ LUN を利用している仮想マシン全てが待たされる状態でした ( 詳しくは、過去のブログ 押さえておきたいvSphereの基本~ストレージ編 第2回~ をご覧ください ) 。

これに対し、VAAI が有効なストレージでは、LUN 全体ではなく、より細かい単位でストレージをロックします。従って、排他制御の影響を受ける仮想マシンを大幅に減らすことが可能になります。これを実現している VAAI の機能を ATS ( Atomic Test & Set ) と呼びます。

 

( 2 ) 仮想マシンファイル ( 大容量 ) のコピー、移動が頻発

仮想環境には、仮想マシンがファイルであることを生かした便利な機能がたくさんありました。前回のブログでご紹介した Storage vMotion もその一つです。こういった便利な機能を利用するには、大容量の仮想マシンファイルをコピーしたり、移動したりする必要があります。VAAI が有効でない場合、この処理は ESXi サーバの CPU が行います。つまり、 ESXi サーバが対象となるデータをストレージから読み込み ( read ) 、再びストレージへ送って書き込む ( write ) という処理を行う必要がありました。このため、本来仮想マシンによって利用されるべき ESXi サーバの CPU リソースが奪われるうえ、サーバ – ストレージ間の帯域も一時的に逼迫してしまいます。

これに対し、VAAI が有効なストレージでは、ファイルコピーや移動の処理をストレージ単体で行うことが可能になります。ESXi サーバは、ただ一度命令を出すだけで済むので、CPU リソースが奪われることがありません。また、実際のデータは、ストレージ内でのみ流れることになるため、サーバ – ストレージ間の帯域も消費されません。これを実現している VAAI の機能を Full Copy と呼びます。

 

( 3 ) ストレージへの 0 書きが頻発

これまでお伝えしてきたように、仮想環境では、一つのストレージを複数の仮想マシンが利用します。従って、ある仮想マシンが書き込んだ領域を別の仮想マシンが使うということが頻繁に起こります。しかし、ある仮想マシンが過去に書き込んだ情報に別の仮想マシンからアクセスできるというのはセキュリティ上良くありません。そのため、仮想マシンがストレージ上のとある領域に初めてアクセスする場合、まずは 0 書きされるという仕組みになっています。仮想マシンを新たに作成する際にも大量の 0 書きが行われます。VAAI が有効でない場合、この 0 を書く処理は、ESXi サーバの CPU が行います。当然、( 2 ) と同じように、ESXi サーバの CPU リソースやサーバ – ストレージ間の帯域に影響を与えてしまいます。

もうおわかりかと思いますが、VAAI が有効なストレージでは、この処理をストレージ側にオフロードすることが出来ます。従って、ESXi サーバの CPU リソースに影響を与えませんし、サーバ – ストレージ間の帯域にも影響しません。これを実現している VAAI の機能を Block Zeroing と呼びます。

 

図 6 に、VAAI 機能のイメージ図を示します。

 

VAAI
図 6 . VAAI

 

~ おわりに ~

今回は、新卒ブログシリーズのおまけとして、vFRC 、Multipathing 、VAAI をご紹介させていただきました。前回ご紹介した SIOC や Storage DRS も考えると、vSphere にはストレージ関連機能がたくさんあると言うことがおわかりいただけたと思います。機能が多すぎて複雑に見えてしまうかも知れませんが、裏を返せば、それだけストレージが重要視されているということでもあります。皆様には、本シリーズでご紹介したストレージ関連の機能を生かし、仮想化の恩恵を最大限受けられる環境を構築していただけたらと思います。ありがとうございました。

VMware SE 氏田裕次

 

新卒 SE 社員が贈る vSphereのキソ!
第1回 vSphereを俯瞰する
第2回 仮想環境におけるネットワークとストレージ
第3回 vMotionとvSphere HA/vSphere FTの違いとは?
第4回 仮想マシンの配置管理はDRSにお任せ!
第5回 様々な仮想マシンが混在&混雑しても大丈夫!?ネットワーク と ストレージの帯域を維持する仕組み
第6回 vSphere でココまでできる!データ保護
第7回 仮想環境となが〜くお付き合いしていく
第8回 ( 追加編 ) まだまだあった!ストレージ関連機能

3rd Party Image/Backup Tool から VMware vSphere 環境への移行

皆様、こんにちは。VMware の大原と申します。

本エントリでは、ブログ [仮想化への移行] シリーズの第三弾として、VMware vCenter Converter Standalone (以下Converter) でサポートされないバージョンのOSをvSphere環境にP2V(Physical to Virtual)するための手段についてお伝えします。

[仮想化への移行] シリーズ

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

 

2015年7月15日のWindows 2003サポート終了に伴い、その上で稼動しているアプリケーションをWindows 2008やWindows 2012といったOSに移行することが急務となっています。しかし、そのアプリケーションを使用しているユーザが少ないケースや、アプリケーションの使用期限(たとえば、あと2年以内に全ユーザを別のアプリケーションへ移行するようなケース)が明確な場合には、コストをかけてアプリケーションを改修するのではなくWindows 2003を延命させることで既存のアプリケーションを使い続けたいというニーズをお持ちのお客様も多くいらっしゃるのではないでしょうか。
一方で物理サーバ上でWindows 2003を稼動し続ける場合、サーバ老朽化に伴う保守パーツ不足により保守サポートが受けられなくなるリスクも発生します。
そういった場合に、既存のWindows 2003に変更を加えることなく、vSphere環境上に移行することを検討する必要があり、それを可能にする製品がVMware vCenter Converter standaloneです。以前のブログでは、Converterを使ってWindows 2003を移行する手順もご紹介していますのでご参照下さい。

しかし、ConverterでサポートされるWindows2003のバージョンはWindows 2003R2SP2のみとなります。それ以前のバージョンでは、Converterを使って移行することはサポートされません。

※Windows2003 R1 SP2の環境をConverterを使って移行を試みましたが、サポートOS外ということでConverterのエージェントのインストールに失敗して移行することができませんでした。

Error_message

そのような環境下では、Windows2003をvSphere環境へ移行するために3rd Partyのソフトウェアを使用してP2Vを行う必要があります。本ブログでは、アクロニス社のAcronis Backupを利用したP2V手法についてご紹介していきます。

以前は、Acronis Backupのようなバックアップソフトウェアで取得したイメージをConverterに読み込ませることでvSphere環境への移行を行っておりましたが、最近ではバックアップソフトウェア側の機能で直接vSphere環境にイメージを戻すことができるようになっています。

Backup_Image

以下にAcronis Backupを使用したWindows2003(およびLinux※)の詳細な移行手順につきまして、アクロニス・ジャパン株式会社セールスエンジニア部の佐藤匡史様にブログを執筆頂きましたのでご紹介させて頂きます。

※LinuxについてもConverterでサポートされるディストリビューションは限定的ですので、Acronis Backupを検討されるケースも多くあるのではと思われます。

 

□Acronis Backupのご紹介

Acronis Backupはイメージバックアップをコアテクノロジとするバックアップ製品です。日本のイメージバックアップ市場ではNo1のシェアを持ち業種、規模によらず幅広く利用されています。

さらにAcronis BackupではWindows、Linux、物理、仮想の集中管理や、アプリケーションに対応したバックアップ、重複除外機能など多くの付加価値を提供します。また様々な保存先が利用できるのでシーンに応じた最適なバックアップ環境を提供します。vSphere環境ではvStorage APIと連携したエージェントレス型バックアップ、仮想マシンへのコンバート、レスキューメディアを利用した簡単P2Vなどお客様のニーズに合わせた利用が可能です。

AcronisBackup

□Acronis Backup によるP2Vの実施

Acronis Backup では、現在利用しているサーバで取得したバックアップを仮想サーバに復元するP2V機能を標準の機能として提供します。物理サーバで取得したバックアップデータをドライバを含めたハードウェア環境から分離し、仮想マシン上に復元して稼働させることができるのです。この作業はWindows/Linux共に直観的に利用可能なGUIを利用し、バックアップと復元という単純な作業により実施できることが特徴となります。また、付加機能を利用することで効率的な作業に貢献します。

Acronis Backup のP2Vは3つのステップで実施します。Step1で移行元においてシステム丸ごとバックアップしイメージ化します(P2I)、Step2ではESXi上に移行先の仮想マシンを任意の構成で作成します。Step3では新規仮想マシンにStep1で取得したイメージを復元します(I2V)。

移行STEP

□イメージバックアップ

OS、アプリ、システムファイルなどすべてをイメージバックアップすることがが可能です。このバックアップは実際にデータが配置されているブロックのみを検知しブロックベースのコピーを行いますので高速なバックアップが可能です。Windowsのダイナミックディスク、LinuxのLVM(ロジカルボリューム)を認識したバックアプ、復元も可能です。また、その保存先としてCD、DVD、テープ、USBメディア、ローカルディスク、ネットワークディスクなど様々な場所に保存することが可能です。P2V実施時、移行元と移行先がネットワークで接続されていない環境などではポータビリティのある外部媒体にバックアップイメージを保存し、搬送するなどの手段が必要となります。このような条件下でもAcronis Backupを活用頂けます。

イメージバックアップ

バックアップ時に利用するレスキューイメージは常に最新のものをWebからダウンロードすることが可能です。このレスキューイメージはAcronisが独自開発しているLinuxベースのレスキューイメージとなり、各社のHWに対応するための汎用ドライバが既に組み込まれ即時利用することが可能です。特殊なHWを利用している場合には汎用ドライバで対応ができないことからレスキューイメージでシステムが起動できない状況が発生します。その場合には任意のドライバを組み込んだWinPEベースのレスキューイメージを作成することも可能です。また、オフラインバックアップにおいて、完全、差分、増分を取得することが可能です。停止時間が限られた移行を計画している場合には事前に完全バックアップを取得しておき、移行作業時は増分のみを取得することでバックアップ時間(つまり停止時間)を最小に抑えることが可能です。

オフラインバックアップ

□Universal Restore(異機種への復元)

Universal Restoreは復元時に機能し、異なる環境へのOSイメージ移行を簡素化します。(本ブログでは、vSphereへのリストア手順をご説明します)

以下に、OS毎のUniversal Restore実施時の動作について記載します。

・Windows

復元時にHAL(Hardware Abstraction Layer)を調整、その後チップセット、ストレージコントローラ用ドライバの変更・インストールを行うことでOSを起動させます。OS起動後プラグアンドプレイもしくは手動で必要なドライバを適用します。

・Linux動作(RHELの場合)

復元時に新たな環境に合わせRAMディスクを作成します。またBootスクリプトを新しいHW、パーティションレイアウトに合わせ調整します。GRUBおよびfstabを修正しOSを起動させます。

これらの処理は各OSに関する専門知識を持ったエンジニアであれば実施可能と思われますが、一般的には実施することがない操作と考えています。また、自身で実施した場合、起動不能、OS破損などの移行後の問題に対処することを考えると得策ではないと思われます。OS起動部分までをメーカサポートが付帯したツールで実施することで移行作業が簡素化され、品質が安定します。

UR

□サポートOS一覧

Acronis Backupでは非常に多くのOSをサポート(※)しています。特徴的なのはWindows2000や無償版のLinuxのサポートです。

(※)移行先でのOSサポートにつきましては、vSphereのサポートOS情報を参照下さい。

・Acronis BackupでサポートされるWindows OS一覧
WindowsSupport

・Acronis BackupでサポートされるLinux OS一覧
LinuxSupport

□Acronis Backupを使用したP2V手順

・レスキューメディアから物理マシンを起動
 移行元の物理マシンにレスキューメディアを挿入し起動します。レスキューメディアが起動すると以下のような画面が表示されます。マウス、キーボードを使って操作が可能ですのでご利用のHWに応じて32ビット用、64ビット用を選択しAcronis Backupを起動します。

移行元

・Acronis Backupによるバックアップの実施
Acronis Backup起動後はP2Iのためのバックアップを実施します。設定項目は大きくは3つ。

①バックアップ対象の指定
Acronis Backupではディスク、ボリューム、ファイルの何れかを指定することが可能です。P2Vであればディスクまたはボリュームを選択します。

②バックアップ保存先の指定
保存先はサポートする任意の保存先を選択することが可能です。GUIに表示される保存先を選択します。UNCを直接入力することも可能ですが “¥” の入力ができませんので “/” を入力します。

③バックアップ方法の指定 
完全、差分、増分の指定が可能です。完全はすべてのデータ、差分は前回取得した完全バックアップから変更されたデータ、増分は前回取得したバックアップから変更されたデータを取得します。バックアップ時間は完全が最長で、増分が最短となります。

移行元バックアップ

・新規仮想マシンの作成とレスキューメディアからの仮想マシンの起動
移行先となるvSphere環境で新規の仮想マシンを作成します。レスキューメディアからAcronis Backupを起動するためにはCD/DVDドライブ、1GB以上の仮想メモリが必要です。ネットワーク共有越しにバックアップアーカイブを参照する場合にはネットワークアダプタが必要です。レスキューイメージを仮想マシンにマウントし64ビット用のAcronis Backupを起動します。

移行先

・バックアップしたイメージの復元
Acronis Backup起動後はI2Vのための復元を実施します。設定項目は大きくは3つ

①復元データの選択
復元するバックアップアーカイブをAcronis Backupから参照すると世代、内部のデータを参照することが可能です。P2Vであれば復元の対象はディスクまたはボリュームを選択します。LVMを利用している場合にはボリュームを選択します。

②復元先の指定
復元するディスク、ボリュームは自動でマッピングされますが、意図しない構成となった場合には手動でマッピングすることも可能です。プロパティから各ボリュームのサイズ変更することも可能です。NTシグネチャは“自動的に選択する”がデフォルト設定となり、P2Vの場合には(新規ディスクへの復元時)は新しいNTシグネチャが生成されます。

③Universal Restore
P2Vを行う場合には必ずこの項目を“使用する”に変更して下さい。このUniversal Restore機能を有効にすると任意のドライバをAcronis Backupに追加することが可能ですが、vSphereへの移行に関しては必要なドライバがAcronis Backupに内包されておりますので手動でドライバの追加を行う必要はありません。

移行先復元

□P2Vの留意点

・IPアドレスについて
移行元のIPアドレスは移行先に継承されません。ネットワーク設定は初期化されますのでOS起動後手動での変更が必要です。

・SIDの重複
このP2Vではデフォルト移行元で利用されていたSIDがコピーされます。移行元と移行先の環境でSIDの重複が発生しないように配慮が必要です。

・ハードウェア監視ツール
RAID管理ユーティリティ、NICチーミング・ドライバなど移行先の環境に適応できずにシステムの起動、動作を阻害する可能性がございます。状況に応じてセーフモードでの起動、不要なユーティリティ、サービス、デバイスドライバ等の停止、削除が必要です。

本ブログ執筆に向け、Windows環境につきましてはHP社のML350G3、Linux環境につきましてはHP社のML350G5、それぞれ物理サーバを使用して詳細な移行手順を作成しました。
以下に、WindowsおよびLinuxそれぞれの詳細移行手順、および注意点を記載しておりますので、是非ご参照下さい。
※お客様情報を入力頂くことで手順のダウンロードが可能です。

Windows環境での詳細移行手順
⇒“実画面でステップを紹介!Acronis BackupによるWindows Server 2003 P2Vガイド”

Linux環境での詳細移行手順
⇒“実画面でステップを紹介!Acronis Backup for Linux ServerによるP2Vガイド”

 

□まとめ

いかがでしたでしょうか?ConverterでサポートされないOSが稼動している物理サーバをvSphere環境へ移行する際には、Acronis Backupのようなツールと連携して移行することをご検討下さい。

 

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