在VMWare環境將Thin-Provision LUN空間回收(Reclaim)

從vSphere 5.0之後開始提供VAAI Thin-Provision的功能(UNMAP)，原本在5.0第一版版本中default會將此功能開啟，所以當有VM在進行Stroage vMotion或著delete時，會立即對後端儲存設備下達UNMAP指令，對線上的環境來說會有一定的壓力，甚至會遇到效能不彰的問題，所以VMWare後來都建議將此功能關閉，透過手動的方式在適合的時間點再執行空間的回收。

若要手端將此功能關閉可以參考此文章: http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2007427

SSV自v9 PSP4 update 3之後也開始支援VAAI Thin-Provision，可以先用此指令確認VAAI的狀態:
# esxcli storage core device vaai status get -d naa
<<Example output:>>
naa.60a98000572d54724a346a6170627a52
VAAI Plugin Name: VMW_VAAIP_NETAPP
ATS Status: supported
Clone Status: supported
Zero Status: supported
Delete Status: supported  <= 代表Thin-Provision Reclaim有支持

接下來當有空間需要執行回收時，在ESX 5.0跟5.5的作法不同，以下是指令的範例參考:

## vSphere 5.0 U1 or later and vSphere 5.1

請使用vmkfstools的指令來作，以下是指令的範例: 
# cd /vmfs/volumes/volume_name
# vmkfstools -y percentage_of_deleted_blocks_to_reclaim

註: 在執行此動作的時候，會在該DataStore裡頭產生一個暫存檔後來寫零用的，不要一下子用到100%，此時若有執行VM快照會其他新的資料要寫，可能會因為空間不夠而failed。

Example usage
To reclaim 60% of the free space on a datastore named Datastore1 in the current directory, run the commands:
# cd /vmfs/volumes/Datastore1
# vmkfstools -y 60

If there is 10 GB of free space on the example VMFS volume Datastore1, the operation will reclaim 60% of the 10 GB of space; in other words, 6 GB will be reclaimed.

## vSphere 5.5

請使用esxcli的指令來作，以下是指令的範例:
esxcli storage vmfs unmap --volume-label=volume_label|--volume-uuid=volume_uuid --reclaim-unit=number

• -l|--volume-label=volume_label
  
  The label of the VMFS volume to UNMAP. This is a mandatory argument. If you specify this argument, do not use -u|--volume-uuid=volume_uuid.

• -u|--volume-uuid=volume_uuid
  
  The UUID of the VMFS volume to UNMAP. This is a mandatory argument. If you specify this argument, do not use -l|--volume-label=volume_label.

• -n|--reclaim-unit=number (預設是200個單位)

reclaim的單位，會根據當初在格式化此DataStore所使用的block size: 

• 200 MB for 1 MB block VMFS3 / VMFS5
• 400 MB for 4 MB block VMFS3
• 1600 MB for 8 MB block VMFS3

在執行reclaim動作時，同樣會在該datastore的根目錄下產生一個影藏的temp file " .asyncUnmapFile" 用來填"0"使用的，reclaim完畢之後就會消失。




如果reclaim執行失敗，或著command一下就執行完了，代表reclaim並沒有成功，可能的原因包括此DataStore是從VMFS3升級到VMFS5的版本，或著透過手動的方式將此LUN作磁區的分割(fdisk)，解決方式請參考此文章: http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2048466)




SSV v9 PSP4 update 3之後會在背景掃描若有全"0"的SAU則會自動回收，在Console上點選該vDisk的Info Tab，會看到狀態顯示"auto-reclaiming")，不過priority很低，所以是"慢慢"回收，要一次回收可以手動用"start reclaim"的動作。

還是要提醒一下，Reclaim的動作是大量寫"0"的I/O動作，建議逐次逐量的來執行回收的動作，避免對線上環境的性能影響太大。此外，隨著資料持續的更新，存在於後端Disk Pool的SAU位址也會分散，因此就算對該DataStore的Volume執行多次的reclaim動作，也不代表後端Disk Pool就能夠全數回收100%的空間，因為只要SAU中有一個資料不是"0"(可能是其他資料佔據)，該SAU就不會被SSV回收，這點請特別注意。