ESXiとiSCSIのエクステントタイプについてメモ
最初に
テスト環境
ESXi 6.5d Build 5310538
FreeNAS-11.0-RC2 (a4687be8c)
エクステントタイプは2種類
ファイルタイプとデバイスタイプ
速度に関しては以前の記事をご覧ください
ファイルタイプ
デバイスタイプ
速度に関して結果だけ書いておくと
CrystalDiskMarkの数値は誤差の範囲内
今回は速度ではなくVAAIについてです
VAAIとは
VAAIはvStorage APIs for Array Integrationの略で
簡単にいうと素のiSCSIよりESXiを少し快適な環境にできる感じ
VAAIサポートと一言で言ってもどの機能をサポートしてるかは別問題
FreeNASのVAAIサポート状況
FreeNASの場合はどうなのかを実際に確認してみます
FreeNAS側でファイルタイプとデバイスタイプの2種類のLUNを作成
ファイルタイプは普通に作ればスパースファイルです
デバイスタイプはzvol作成時にSparse volumeをONにする
スパースファイルとはESXiでいうシン・プロビジョニング（Thin Provisioning）
要は100GB割り当てても1GBしか使ってないなら
1GBだけストレージから確保すればいいってやつで
容量節約するには便利な機能
ESXiへiSCSI経由でvmfs6でデータストア登録し
SSHでログイン
ファイルタイプ
[root@esxi:~] esxcli storage core device vaai status get -d naa.*********************** naa.*********************** VAAI Plugin Name: ATS Status: supported Clone Status: supported Zero Status: supported Delete Status: unsupported [root@esxi:~] esxcli storage core device list -d naa.*********************** |grep Thin Thin Provisioning Status: unknown
デバイスタイプ
[root@esxi:~] esxcli storage core device vaai status get -d naa.*********************** naa.*********************** VAAI Plugin Name: ATS Status: supported Clone Status: supported Zero Status: supported Delete Status: supported [root@esxi:~] esxcli storage core device list -d naa.*********************** |grep Thin Thin Provisioning Status: yes
ATS/Clone/Zeroは両方サポートしてますがDeleteのサポート状態が違う
ファイルタイプの方はデータストア自体がThin Provisioningかどうかも
ESXi側で把握できてません
ATS/Clone/Zeroに関して超簡単に説明すると
ATSはメタデータ更新などで使うロックを細かくすることでIO効率化
Cloneはデータストア上のデータを移動・コピーする際にNAS側で全て完結させる
Zeroはシックプロビジョニング（Eager zeroed）を作成するときに特に有効で
Zeroを100GB分転送するよりZeroを100GB分埋めといてとNASへ命令するだけでOK
Deleteは要はunmapのことで
Thin Provisioningの中にある未使用領域を再利用することにより容量節約できる機能
Delete Statusにおける具体的な影響
今回はDeleteをサポートしているデバイスタイプのデータストアを使って
ESXiとNASの各使用済容量の差を確認します
最初にデータストアへ登録した直後の状態
データストア登録直後
上がESXi側で1.41GBが使用済 下がNAS側で2.8MBが使用済
ここからデータストアへ1GBファイルをアップロードします
1GBファイル転送 1回目
ESXi側が2.41GBでNAS側が1.1GBということで1GB分増えてます
次に転送した1GBファイルを削除します
1GBファイル削除 1回目
ESXi側が1.41GBに戻るもNAS側は1.1GBのまま
この段階でNAS側に未使用なのに1GBの無駄領域が発生
先ほどと同じ1GBファイルをもう一度データストアへアップロード
1GBファイル転送 2回目
ESXi側が2.41GBでNAS側が2.2GB
つまり先ほどの無駄領域は再利用されず新たに1GBが確保されました
ここでunmapコマンドを使用してみます
[root@esxi:~] esxcli storage vmfs unmap -l test_vm [root@esxi:~]
エラーなく実行できれば再度確認
unmap実行後 1回目
ESXi側は2.41GBのままですがNAS側はちゃんと1.1GBに戻りました
つまり最初に転送した1GBファイル分がNAS側でも解放されました
ここでデータストアに残っている1GBファイルを削除し再度空の状態にします
1GBファイル削除 2回目
ESXi側は1.41GBに戻るもNAS側は1.1GBとまたも2回目に上げた1GB分を消費してます
そこでもう一度unmapを実行します
unmap実行後 2回目
ESXi側が1.41GBでNAS側が3.2MBと正常な状態に戻りました
unmapコマンドについて
Delete Status: unsupportedなファイルタイプのデータストアに実行すると
[root@esxi:~] esxcli storage vmfs unmap -l datastore_name Devices backing volume ***************** do not support UNMAP [root@esxi:~]
Delete Status: supportedなデバイスタイプ（zvol）のデータストアに実行すると
[root@esxi:~] esxcli storage vmfs unmap -l datastore_name [root@esxi:~]
処理時間は先ほどの1GBファイルテストでは数秒で終わりましたが
範囲が広いと時間がかかると思うのでケースバイケース
処理中はデータストアのパフォーマンスが低下するので
該当データストアに入っているVMには注意
unmapコマンドの注意点
unmap使えば未使用領域が解放されるので素晴らしい機能なんですが
これには一つ注意点があります
それはVM内の未使用領域を解放するわけではないということ
先ほどの1GBファイルはデータストアに直接転送しましたが
VMのゲストOS内で1GBファイルを転送してからunmap使っても意味ないです
その場合はゲストOS上でまずsdeleteなどで無駄領域をZero埋めし
ESXiでシンプロビジョニングなvmdkを圧縮
その上でunmapを実行する流れになります
なぜならシンプロビジョニングはZeroでなければ未使用だと判断できないので
Zero埋めできてない未使用領域はESXiから見るとまだ使用中なのです
つまりESXiのデータストア使用済容量分まではunmapで対処可能
各VM内は別次元の話
エクステントタイプの使い分け
NAS側がiSCSI専用で容量気にしないならファイルタイプが快適でいいと思います
unmapに関しては実際問題としてVM内の未使用領域を解放する手順が必要なことと
放置していてもデータストア割り当て分を超えるわけでもなく
空き容量がなければ自動で再利用されるわけで限界までNAS側の容量節約したい人以外
そこまで必要じゃないかもです
しかもESXi 6.5dではあくまでコマンドによる手動対応です
unmapが有効に使えるケースとしては
ISO置き場などのデータストアやVM自体を頻繁に作成・削除を繰り返すデータストアです
まずデバイスタイプにVM作成してから
使い続けるVMのみファイルタイプへ移動させるとかもアリですが
シンプロビジョニングなVMの移動はコマンドでの処理になるので面倒です
ZFSに限定した話でいうと
zvolは仕様なのかわかりませんがファイルタイプより速度が安定してでない
CrystalDiskMarkの結果だけ見ると同じようなレベルなんですが
体感はなぜかzvolが遅い
海外のフォーラムでもよく議論されてるので興味ある方は検索してください
いろいろ見た感じでは本来同じパフォーマンスのはずがファイルタイプの方が現実は速い
という結論が多い印象で少なくともzvolの方が速いというのは無かったです
そういう点でもファイルタイプがオススメ
最後に
VAAIに関してはCloneがあったら便利だな～ぐらいで
ATSに関しては不具合を起こすケースもたまにあるらしくわざわざ無効にする人もいる模様
なのでVAAIに過度な期待はせずあったらいいかな程度で考えればいいと思います
iSCSIのパフォーマンスはやはりLUN分散や
1つのデータストアにどの程度VMを入れるかなどの方が大きく影響するので
そっちが重要
コメント