Claim your free disk space
Fri 13 Dec 2013 | View all blogs
Okay, so in today’s world of flashy storage (pun intended), the vendors are cramming in all kinds of features to improve performance and space utilisation. Dedupe, compression, variable block sizes, block-zeroing, you name it and chances are someone has thought of and implemented it.
Today we’re looking at a Pure Storage Flash Array. First of all, here’s a bit of background to the infrastructure:
We have a VMware 5.1 cluster mounting a volume called “SSD-1” from the Flash Array. This volume is primarily used to host heavy I/O workloads such as SQL and Oracle database servers. The virtual machine disks (vmdk’s) are thick provisioned with eager zeroing in order to maximise performance and minimise fragmentation.
As such we get around 2.4:1 data reduction, which is within the same figures that Pure themselves claim for database environments.
According to VMware, this volume is 12TB in size and currently has 7.09TB of virtual machine data residing on it.
According to the Flash Array, the volume is indeed 12TB and is consuming 599.52GB of its capacity (after formatting, parity etc. )
Without removing any virtual machines or deleting any files inside them, we’re going to show you how we freed up over 134GB, which equates to 323GB of useable space increase.
The disclaimer we’d like to add is that this example is completely specific to the infrastructure we have here. Unless you are running VMware 5.1 with a Pure Storage Flash Array (or an alternative which offers the same feature set) it won’t work for you. In addition these commands should be run inside a maintenance window so as not to risk disrupting production workloads.
Let the magic begin
Well, no magic sadly - just a solid understanding of how our infrastructure works at a very low level.
Firstly, consider a virtual hard disk belonging to a virtual machine. Over time files are added and removed, databases grow and are shrunk. The “free space” on the drive really isn’t free at all. They are simply blocks of data which have been used and then subsequently marked as available in the file allocation tables; the data is still actually there, so it’s sitting on your SAN.
Enter the superhero “SDelete”, or “Secure Delete”. Originally written to ensure old data held on disk would be unrecoverable, it has a nifty option to zero free space.
Why would you want this? Well in our case the Flash Array has a zero space reclamation feature where it spots blocks that contains all zeros and doesn’t store them.
SDelete was run on just 3 of the 40 VMs using this volume.
Secondly, in a very similar way to the above, when deleting VMs (or svMotion’ing them away) from a volume VMware only marks the space as available in its VMFS filesystem. This space would be reused by VMware but for now it’s just dead space which is still containing actual data, residing on your SAN.
Enter the next superhero, the SCSI UNMAP feature or “Dead Space Reclamation” which was added to vSphere 5.0. This is another manual process and relies on using the command “vmkfstools –y” option. Again, our Flash Array supports UNMAP so we can take advantage of this feature.
The results
Here is the space utilisation graph from the Flash Array. You can see it’s reasonably consistent until we come along and run our magic commands:
Free space as if from nowhere.
Freeing up 323GB useable on a 12TB volume may not sound like much, but what if SDelete had been run on all 40 of the virtual machines? Additionally as your VM count and volume capacity increases, the gains will too.
In short – know your infrastructure, understand how it works and this will help to drive a more efficient platform which can only ever be a good thing.