Japan IBM Storage User Group

シンプロとレクラメーションとSCSI UNMAP【その3 VMware編】

By Keitaro Imai posted Thu May 21, 2020 05:30 AM

  
以下、前回前々回に続き、3回目。少し長いです。。。
シンプロとレクラメーションとSCSI UNMAP【その1 概要編】
シンプロとレクラメーションとSCSI UNMAP【その2 Windows編】
今回はVMwareです。
VMwareの場合は、ハイパーバイザーの層でのレクラメーションと、ゲストOSの層でのレクラメーションを考慮する必要があります。
前者については、仮想マシンやVMDKの削除、移動などにより、無効となった領域を解放するもので、後者の場合はゲストOS上でのファイルの削除領域を解放するものです。
以下、それぞれ説明します。
【ハイパーパイザー層でのレクラメーション】
VMwareはESXi5.0以降でUNMAPが使えるようになりました。
ESXi5.0では、自動でUNMAPが有効になっていましたがStorage vMotion時のパフォーマンス等の問題からESX5.0 u1ではUNMAPは自動では行われない設定になりました。
ESXi5.0u1/5.1において手動でレクラメーションを実行する方法は、"vmkfstools -y"というコマンドを実行することです。
ESXi5.5以降では、これに変わり"esxcli storage vmfs unmap"というコマンドが提供されるようになりました。
これらのコマンドは無効となりえる領域にバルーン・ファイルというファイルを作成した後に解放します。
そのため、容量の指定を誤ると一時的にボリュームのサイズが大きくなり他の書き込みができなくなる可能性があるため、指定する値には注意してください。
前者のコマンドは、容量に対する%指定なのに対し、後者のコマンドはブロック数指定(デフォルト200ブロック × 1MB)となり、バルーン・ファイルによる容量の圧迫が起こりにくくなっています。
さらに、前者は指定した容量のみですが、後者は全ての空き領域をレクラメーションしてくれるという点が利点となっています。
ファイル作成の負荷などもあるため、基本的には上記コマンドを都合の良いタイミングで実行する手動でのレクラメーションが推奨されています。
ただ、ESXi6.5のVMFSバージョン6では、レクラメーションは自動で有効になっているようですが、非同期なのでパフォーマンスへの影響はないとのことです。
ストレージ側がUNMAPに対応しているかどうかの判断は、"esxcli storage core device vaai status get"コマンドの、「Delete Status」が「supported」であれば対応しています。
[root@x3690x5k:~] esxcli storage core device vaai status get
eui.001738004e8c39a2
   VAAI Plugin Name:
   ATS Status: supported
   Clone Status: supported
   Zero Status: supported
   Delete Status: supported
UNMAPに対応している場合、ストレージの提供するボリュームがシンプロかどうかは、"esxcli storage core device list"コマンドを使用します。
[root@x3690x5k:~] esxcli storage core device list
eui.001738004e8c39a2
   Display Name: IBM Fibre Channel Disk (eui.001738004e8c39a2)
   Has Settable Display Name: true
   Size: 147699
   Device Type: Direct-Access
   Multipath Plugin: NMP
   Devfs Path: /vmfs/devices/disks/eui.001738004e8c39a2
   Vendor: IBM
   Model: 2810XIV
   Revision: 0000
   SCSI Level: 5
   Is Pseudo: false
   Status: on
   Is RDM Capable: true
   Is Local: false
   Is Removable: false
   Is SSD: false
   Is VVOL PE: false
   Is Offline: false
   Is Perennially Reserved: false
   Queue Full Sample Size: 0
   Queue Full Threshold: 0
   Thin Provisioning Status: yes
なお、UNMAPに対応していない場合は、シンプロのステータスもNoと表示されます。
ハイパーパイザー層でのレクラメーションの際は上記を考慮すれば良いでしょう。
【ゲストOS層でのレクラメーション】
ESXi6.0以前のVMFSでは、ゲストOSでファイルを削除した後に、ゲストOSのUNMAPで領域を解放しようとしても、外部ストレージにはUNMAPのコマンドは到達しないので領域の解放は出来ません。
これの対応策としては、
・ゲストOS内でsdeleteやddで0を書いて解放する
・VMFSレベルでシンプロのVMDKを作成し、ゲストOSのUNMAP+ハイパーバイザーのUNMAPを組み合わせる
・RDMを使用する
などが考えられます。2点目ですが、VMFSレベルでのシンプロを使用した場合にも、当然ゲストOSからのレクラメーションは必要になります。レクラメーションをすると、データストアの領域は解放されます。そのうえで、ハイパーバイザーでUNMAPを実行すれば外部ストレージ上の領域も解放される、ということです。
ESXi6.0以降では、条件にもよりますが、ゲストOSのUNMAPがダイレクトにストレージに伝えられるようになりました。
以下がその条件です。
・VMFS6の場合
  • ゲストOSがUNMAPを使用可能であること
・VMFS5の場合
  • 仮想マシンはシンプロビジョニングであること
  • 仮想マシンのハードウェアはバージョン 11 (ESXi 6.0) 以降であること
  • 詳細設定の EnableBlockDelete を 1 に設定すること
  • ゲスト OS が仮想ディスクをシンとして識別できること
  • CBTは無効にすること(VMFS6ならOK)
またvVolについては、こちらも使用するゲストOSがUNMAP可能であれば問題ありません。
詳細はVMware社の以下のサイトをご覧ください。
・esxcli storage vmfsアンマップコマンドを使用してシン プロビジョニング LUN 上の VMFS 削除済みブロックを再クレームする。
・シン プロビジョニングされた LUN 上での VMFS 削除ブロックを再要求する方法
・シン プロビジョニングと容量再利用
・VMFS データストアからの容量再利用の要求

#thin-provisioning
#vmware
#scsi-unmap
0 comments
10 views

Permalink