ESXiとiSCSIのエクステントタイプについて

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を入れるかなどの方が大きく影響するので
そっちが重要