vSphere/DataCore UNMAP - Reclaiming unused space from thin-provisioned disks

For a long time it was a hard way to reclaim unused space from thin provisioned disks. The old way includes deleting files, manually fill the free space up with a zeroed vmdk, delete this vmdk, manually start a reclamation process on DataCore and wait until it finishes.

Not a very comfortable way to get some space back.

The good news is, vSphere 5.5 and DataCore SANsymphony-V 9.0 PSP4 (which was released on 11/11/2013) now fully support the fourth VAAI principle UNMAP. With this new principle you now have the ability to ease the process of reclaiming unused space.

Well, UNMAP is not new to vSphere. Version 5.0 already supported UNMAP but a few weeks after the release date of vSphere 5.0, the feature was generally disabled by U1 because it has some bad effects on some storage systems.

So it seems worth a bit of testing this new feature along with SANsymphony to see how it works, if there are still some things to keep in mind etc.

 

So, back in my test lab, I built up a new environment out of two ESXi 5.5 servers (two Dell R900 servers), two DataCore SSY-V 9.0 PSP4 servers running on top HP ProLiant DL380G5 servers with Windows Server 2012, a 8GBit FC environment and a single old but still working MSA2000fc G1 with 24 SAS disks.

The setup is quite common, I use 3 RAID10 sets each containing 4 disks and serving two volumes per RAID set to each DataCore server, so in sum I have 6 disks in each DCS pool. Not very much but should be enough to get some decent performance. From this storage I presented two mirrored volumes, a 3TB and a 1 TB volume, to my vSphere hosts.

I installed vCenter 5.5a inside a VM running on top of my vSphere cluster, enabled HA and DRS and left everything else default.

For the test, I first deployed vSphere Operations (a two VM vApp) on the 1TB datastore and later on I installed another VM on the 1TB volume. The vSphere Operations vApp uses 338GB, the additional VM uses 10GB so I have 348GB in use on that 1TB datastore. vSphere Operations is not a neccessary component for this test but I wanted to have some additional VMs in the datastore I reclaim storage from to have a real life scenario. Additionally, vSphere operations can monitor my environment to check if UNMAP has some impact on it.

To test UNMAP I first have to delete the VM to get some disk space back. Said and done, vSphere tells me I only have 338GB in use. Not very surprisingly... checking SSY-V and still have the info that 348GB is in use on that vdisk. Until now everything works as expected.

If you think UNMAP is an inline feature and by simply deleting files in the VMFS datastore the space will get reclaimed automatically you will probably be disappointed. Nothing happens automatically. Why? Well, we will see this in a few minutes.

But how to reclaim this storage? Using SSY-V's space reclamation feature? You can still use it but you won't get any space back if you simply start it and let it run.

What you have to do is issuing a command on one of your vSphere hosts to start the UNMAP process. The command to issue is

esxcli storage vmfs unmap -l datastore-name -n reclaim-unit

Datastore name is self-explaining but reclaim-unit is not that easy to understand. To cut a long story short, UNMAP is an iterative process. In each cycle the amount of MB you specify with the -n switch will be processed until all storage is reclaimed. To do this, a so called balloon file will be created with the size of the -n switch x the block size of your VMFS datastore.

Tangled? Don't worry, there is a very good explanation on boche.net.

For the moment it's enough to know that the command esxcli storage vmfs unmap -l VMFS02 -n 200 will generate a 200MB balloon file in each cycle, reclaim the unused storage and switches to the next cycle.

Oky, by pressing RETURN after typing in the command above my storage gone wild. I saw a 1,6GB/s read rate in SSY-Vs performance counter and ~1500 IOPS issued to the datastore. Quite impressive vaules if you remember my tiny setup with the 5years old MSA2000.....

The whole process took about 15min to complete for this 1TB volume. It seems that the UNMAP command will traverse every single bit on the datastore to check if it contains empty blocks to reclaim or not.

After the command completed, the reported used space within SSY-V decreased exactly to 338GB. Wow, cool, UNMAP works but for what price?

I don't have to mention what this command will do to your production storage if you issue it during normal working hours. Things get worse if you have large datastores because size will directly influence the processing time and therefore the time your storage has nearly nothing lese to do than reclaim unused storage blocks.

Switching to my vSphere Operations system, the metrics for the VMFS02 datastore were all marked red because of 100% usage so you can see that the impact is not only on the storage system but will also affect your vSphere environment.

So my conclusions about this feature are:

  • although simplyfied, UNMAP is still a manual process you have to trigger on the command line. It is still not an inline feature!
  • it puts very high load on your storage subsystem so really think twice before reclaiming space (probably this feature should currently ONLY be used during maintenance windows)
  • space reclaiming, of course, only makes sense if you delete whole VMs/virtual disks on a datastore. It won't work for files deleted inside the guest OSes
  • always consider moving VMs with SVMotion to other datastores and completely delete the empty datastores as an alternative. This will achieve the same result regarding space reclamation but probably with less impact on storage performance
  • with DataCore's SSY-V UNMAP works perfectly so if you want to use this feature, don't hesitate to upgrade to 9.0PSP4 and get your vSphere hosts to 5.5.

 

Leave your comments

Post comment as a guest

0
Your comments are subjected to administrator's moderation.
  • No comments found
Powered by Komento
joomla templatesfree joomla templatestemplate joomla
2017  v-strange.de   globbers joomla template