VMware Global Community
v1153053
Contributor
Contributor

ThinProのLUN上のVMFS5のUNMAP動作について

お世話になります。

ESXi6.0からESXi7.0にアップデート実施後、VM側のdatastoreの使用量とストレージの使用量に差が発生し、ストレージ側で削除後の処理が反映されていないことが判明しました。

下記構成であるため、UNMAPコマンドを手動実行することで、ストレージ側で領域が解放され空き領域を確保することが可能となりました。
■datastore : vmfs5
■ストレージ:Thinで作成されてLUN
■仮想マシンDIS:Thin
■仮想マシンOS:Windows2012R2

恒久対策として、下記URLより、ESXiでEnableBlockDeleteを1に設定したが、ストレージ側で少しずつデータが増えており、変更前は日次で100GB、変更後は日次で20GB増加しております。
EnableBlockDeleteを1に変更することで自動でUNMAPコマンドが発行され領域が解放されるとかんがえておりましたが、動作としては違うのでしょうか。この事象に対して対応方法があれば教えていただけますでしょうか。
また、ESXi6.0の際には設定変更することなくこの事象は発生していなかったと思われるのですが、バージョンアップしたことで何か仕様が変更されたのでしょうか。
仮想マシンはシンプロビジョニングである必要があります。

  • 仮想マシンのハードウェアはバージョン 11 (ESXi 6.0) 以降である必要があります。
  • 詳細設定の EnableBlockDelete を 1 に設定する必要があります。
  • ゲスト OS が仮想ディスクをシンとして識別できる必要があります。
Reply
0 Kudos
5 Replies
kawaman
Leadership
Leadership

状況について整理すると、

UNMAPコマンドを手動実行することで、ストレージ側で領域が解放され空き領域を確保することが可能となりました

とは、

esxcli storage vmfs unmap コマンドの実行で Thin LUN が縮小し、ストレージ領域の解放が確認できたという状況で良いでしょうか。

 

また

> 下記URLより、ESXiでEnableBlockDeleteを1に設定したが、ストレージ側で少しずつデータが増えており、変更前は日次で100GB、変更後は日次で20GB増加しております。

こちらは、EnableBlockDelete 有効化前は日次 100GB 増加していたが、
有効化後は日次 20GB に増加量が減ったということで良いでしょうか?

毎日一定量がゲストに書き込まれ、同じく一定量が削除される際、削除量が書き込み量より少なければ、
例えば 100GB 書き込まれ、80GB 削除されるという状況なら結果的に 20GB の増加は想定通りかと思いますがいかがでしょうか?

Reply
0 Kudos
v1153053
Contributor
Contributor


>esxcli storage vmfs unmap コマンドの実行で Thin LUN が縮小し、ストレージ領域の解放が確認できたという状況で良いでしょうか。
→ご認識の通りです。

 

>こちらは、EnableBlockDelete 有効化前は日次 100GB 増加していたが、
>有効化後は日次 20GB に増加量が減ったということで良いでしょうか?
→はい、ご認識の通り増加量が減っております。

>毎日一定量がゲストに書き込まれ、同じく一定量が削除される際、削除量が書き込み量より少なければ、
>例えば 100GB 書き込まれ、80GB 削除されるという状況なら結果的に 20GB の増加は想定通りかと思いますがいかがでしょうか?
→日次処理として100GB書き込み後、削除されるものがあります。日次処理停止時は、1GB程度の増加量となります。
 想定としては、EnableBlockDelete有効後、1GB程度の増加量で考えていたが、20GB程度増えるようになっている状態です。

Reply
0 Kudos
kawaman
Leadership
Leadership

追加コメントありがとうございます。

> →日次処理として100GB書き込み後、削除されるものがあります。日次処理停止時は、1GB程度の増加量となります。
> 想定としては、EnableBlockDelete有効後、1GB程度の増加量で考えていたが、20GB程度増えるようになっている状態です。

こちらの見え方についてですが、

Windows Server OS の中で見る増加量が増減後に日次 1 GB だが、
ストレージ側の管理 UI で見る Thin LUN (または vSphere Client の UI のデータストア量) の増加量がだいたい 20GB ずつ増えている、ということですね。

 ストレージのブロックレベルでの解放なので必ずしもゲスト OS 内でファイルを削除したら即その領域が解放とはならないので、その分のズレも考えられますが、あまりにも増加が想定より早く進む場合は以下で切り分けしてみるのもよいかと思います。

  1. esxcli storage vmfs unmap コマンドの実行で手動で UNMAP して領域解放ができるか否か
  2. esxtop コマンドなどで UNMAP Delete が行われているか一定間隔でモニタリングしてみる

1. は既に試している操作ですが、ゲスト OS キックの自動 UNMAP できていない領域が手動で開放できるか否かが切り分け目的です。

 

また、ストレージ筐体側の観点でも、VAAI での連携で ESXi 7.0.x と相互互換性のあるファームウェアバージョンとなっているかも合わせて確認してみてください。

 

Reply
0 Kudos
v1153053
Contributor
Contributor

ご回答ありがとうございます。

>Windows Server OS の中で見る増加量が増減後に日次 1 GB だが、
>ストレージ側の管理 UI で見る Thin LUN (または vSphere Client の UI のデータストア量) の増加量がだいたい 20GB ずつ増えている、ということですね。
→はい、ご認識の通りとなります。

> ストレージのブロックレベルでの解放なので必ずしもゲスト OS 内でファイルを削除したら即その領域が解放とはならないので、その分のズレ>も考えられますが、あまりにも増加が想定より早く進む場合は以下で切り分けしてみるのもよいかと思います。
→日次で増え続けている状態ですので、いただいた内容で切り分けしてみようと思います。
 ①の手動で UNMAP の実行ですが、EnableBlockDelete が 有効な状態で実行しても問題がないのでしょうか。

Reply
0 Kudos
kawaman
Leadership
Leadership

> ①の手動で UNMAP の実行ですが、EnableBlockDelete が 有効な状態で実行しても問題がないのでしょうか。

VMFS5 における自動 Unmap/Reclam は特定 VM 向けで、対応していないその他の VM が対象の場合は esxcli でキックしてあげる必要があるので併用は問題ありません。

Reply
0 Kudos