VMwareでの仮想ディスクのタイプ

VMwareでの仮想ディスクのタイプについてちょっとまとめてみた。
VMware環境で、仮想ディスクを作成する際には、

　１．Thick Provisioning (Lazy Zeroed)

　２．Thick Provisioning (Eager Zeroed)

　３．Thin Provisioning 

がある。

Lazy ZeroedとEager Zeroedの違い

　VMware上の動作としては、

　・Lazy Zeroedは仮想ディスク作成時に、スペースを確保するものの、Zero埋めせず、初回書き込み時にブロックに対してZero埋めする。

　Eager Zeroed は仮想ディスク作成時に、Zero埋めする。

　

そのため、

　

　・Lazy Zeroedは初期作成時の時間は短い（大容量ディスクの場合特に）。ストレージの負荷も低い。

　・Lazy Zeroedは初回書き込み時にちょっと性能劣化が発生する(ブロックに対してZero埋めするから？）。

　・Lazy Zeroedは、ディスク作成ではZero埋めしないので、昔のデータが残っている可能性がある（セキュリティ上リスクになる可能性がある）

となる。またEager Zeroedの特徴は上記との裏腹になるが、

　・Eager Zeroは初期フォーマットは時間がかかる

　・Eager Zeroは初回の書き込みが速い(比較して）

　・すべてZero埋めするので、過去データもフォーマットされる

という違いがあるみたい。ちなみにVAAI対応したストレージを使っている場合、Zero埋めの負荷をストレージ側にオフロードすることで、性能向上を図れる。

また外部のストレージ（SANストレージなど）でThin Provisioning との組み合わせも考慮がある。

ストレージ製品によっては、Thin Provisioningを使った場合でも、VMware上のThick Provisioningの場合は、Lazy ZeroedだどろうがEager Zeroedだろうが使ったことになる。hp社製3PARでは、その場合でもZero埋めされた部分は割り当てされないため、ストレージ側のThin Provisioningの機能が活かされるみたいです。ただし、このストレージの機能が、VMwareのThinと比較したときにどれくらいのメリットがあるのか？は気になるところ。（VMware Fault ToleranceがThick/Eager Zeroedのみサポートなので、その時？）

参考

※)http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.0.pdf (31ページあたり）

※）http://h50146.www5.hp.com/products/storage/whitepaper/pdfs/3par/4aa3-4023enw.pdf

tips:vmware(vsphere4)でのJumboFrame対応

VMware(vpshere4でのみ確認）環境でiSCSIをつかっているので、JumboFrameに関する備忘録を記載。

今回は、esxiにコンソールログイン（もしくはsshログイン）して、確認する方法を記載

（設定はマニュアル見てGUIで）

■VMware本体（VMkernel)で使うiSCSI NICのMTU設定の確認

# esxcfg-vmknic -l

Interface Port Group/DVPort IP Family IP Address Netmask Broadcast MAC Address MTU TSO MSS Enabled Type

vmk0 Service Console IPv4 x.x.x.x 255.255.255.0 x.x.x.x xx:xx:xx:xx:xx:xx 1500 65535 true STATIC

vmk1 VMotion IPv4 x.x.x.x 255.255.255.0 x.x.x.x xx:xx:xx:xx:xx:xx 1500 65535 true STATIC

vmk2 iscsi1 IPv4 x.x.x.x 255.255.255.0 x.x.x.x xx:xx:xx:xx:xx:xx 9000 65535 true STATIC

※上記の例では、vmk2というインターフェースのMTUが9000に設定されている。

■VMware本体（VMkernel)で使うiSCSI NICの仮想スイッチのMTU設定の確認

# esxcfg-vswitch -l

Switch Name Num Ports Used Ports Configured Ports MTU Uplinks

vSwitch0 128 5 128 1500 vmnic0,vmnic2

PortGroup Name        VLAN ID  Used Ports  Uplinks

  VMotion               135      1           vmnic2,vmnic0

  Service Console       125      1           vmnic0,vmnic2

Switch Name Num Ports Used Ports Configured Ports MTU Uplinks

Backup 128 4 128 1500 vmnic1

PortGroup Name        VLAN ID  Used Ports  Uplinks

  Backup                0        2           vmnic1

Switch Name Num Ports Used Ports Configured Ports MTU Uplinks

iSCSI 128 9 128 9000 vmnic6,vmnic7,vmnic10,vmnic11

PortGroup Name        VLAN ID  Used Ports  Uplinks

　　　・

　　　・

　　　・

※上記の場合、iSCSIという仮想スイッチのMTUは9000Bytesになっている（つまりJumboFrame対応になっている）

※上記NICと仮想スイッチ両方がJumboFrame向け設定が必要となる。

■ネットワーク経路でJumboフレームが通るか？確認

# vmkping -s 8972 -d [相手先] 

  -s  : パケットサイズ

  -d  : Set Don't Fragment flag(IPv4)

NGの場合は、、

PING [相手先] (x.x.x.x): 8972 data bytes

sendto() failed (Message too long)

OKの場合は、、

PING [相手先] (x.x.x.x): 8972 data bytes

8980 bytes from x.x.x.x: icmp_seq=0 ttl=128 time=0.501 ms

※8972bytesはJumboframeのパケットサイズ9000bytesから、IPヘッダサイズ20bytes＋ICMPヘッダサイズ8bytesを引いたもの。

※8980 bytesは、8972(指定）+ICMPヘッダサイズ(8Bytes) = 8090 Bytesのこと。

■tcpdumpでjumboframeをキャプチャするには

esxiにはtcpdumpの代わりに、tcpdump-uwが入っているので、これを使う。

# tcpdump-uw -i vmk0 -s 9014 -B 9 host x.x.x.x　-w /tmp/test.pcap

上記は

　・vmknicのvmk0で行われている (-i)

　・通信の宛先が x.x.x.xの(host)

　・size 9014以下のpacket(-s)

　・デフォルトではバッファ制約により8138 Bytesまでしかキャプチャができないため、

　　9014 Bytesまでキャプチャができるよう拡張(-B)

　・収集したパケットデータを/tmp/test.pcapに保存(-w)

の例です。

参考：

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1031186