在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回收，這點請特別注意。

在Linux環境正確將Thin-Provision Disk空間回收

在Linux的環境若要使用到精簡配置的磁碟達到空間自動回收的話，要注意該版本是否支援"mount -o discard"的參數，以下用一個範例來說明，如何達到空間自動回收的功能。

O/S: CentOS 6.5 x64 / vDisk: 10GB (mirror)

剛開始透過iscsiadm掛載該10G的磁碟後，同樣進行標準的磁區劃分(fdisk)與格式化(mkfs.ext4)，此時觀察此vDisk的空間使用狀況(Disk Pool Allocation)已經佔了1.75GB。這時在Linux掛載的方式需要加入上述的參數:

mount -o discard /dev/mapper/mpathhp1 /mnt/

這時開始對該掛載的磁碟寫入資料，此時Disk Pool Allocation的空間已經達到2.12GB，再將剛寫入的檔案全數刪除(不是丟入垃圾桶喔~)，從作業系統層用df -h觀察/mnt/ 可用的空間雖顯示原來全部可使用的空間，但實際上vdisk底層已allocate的空間SAU尚未回收。

在SSV 9 PSP4以後的版本，搭配mount -o discard的參數，可以達到自動回收的功能，不過為了不影響前端其他系統的運作，SSV會在background自動已low priority的方式"慢慢"回收。如果要加快處理，可以以手動的方式執行"start reclaim"的動作，再觀察該vDisk在Disk Pool Allocation的空間又回到起初的1.75GB。

若是作業系統沒有支援mount -o discard的方式掛載，或著一開始就沒有使用此參數掛載，可以透過dd寫 "0"的方式，將剛使用過的空間填零，再搭配手動在SSV執行Reclaim的方式也可以達到空間回收的功能。不過要注意的是，由於資料可能分散在多個SAU裏頭，只要SAU裏頭有任何一個空間不是"0"則SSV不會將其回收，所以透過dd寫"0"的方式，會需要嘗試多次之後，再觀察空間回收的狀況，採"逐次逐步"的方式來回收。