Yesterday saw the release of vSphere 6.0 Update 2 and, as part of that, includes the 4th release of VMware’s Virtual SAN: 6.2.
Since the announcement in February, VMware have been more active in promoting certain features that, in their mind, makes an All Flash solution affordable: Deduplication and Compression, and Erasure Coding.
As the name implies, the intention is to reduce storage consumption by de-duplicating duplicate data (go on, say that five times fast). This is occurring near-line, as opposed to it being a post-processing task. While it is enabled cluster-wide, it only operates at a per disk-group level rather than across the entire VSAN logical datastore. This applies to all data from the caching tier to capacity tier at a 4k block size granularity.
As data becomes “colder and older” and, if the data is unique, then it will be compressed with the LZ4 algorithm. This acts near-line as well, so only data coming in from the write buffer is eligible.
These two features are bundled together, as opposed to being able to select just deduplication or just compression and are available for All-Flash configurations only. As mentioned earlier, VMware’s messaging is that this makes an All-Flash VSAN solution affordable. This operates under the assumption that both deduplication and compression operate efficiently enough, to the tune of 3x or more, to make the $/GB ratio favourable.
In my experience, I haven’t seen deduplication reach 2x on external dedicated All-Flash arrays, let alone with other hyper-converged offerings. I have no doubt things will improve; both with the capabilities of deduplication and with the ever-decreasing cost of Flash storage. For now, I will remain sceptical on the economics.
This is another way of describing a RAID5 or RAID6 data and parity combination. When compared to the previous implementation of “Failures To Tolerate = 2”, where the overhead was 3x, Erasure Coding reduces that to 1.5x.
This too is for All-Flash configurations only.
The features that jump out to me immediately, however, are those that can be applied to the Hybrid configurations that we’ve seen a lot of to date. Two of these in particular are:
On disk, a Virtual Machine exists as configuration files; the VMDK (hard disk) files and they also have a swap file which is sized as [Memory Allocated – Memory Reserved]. With properly managed infrastructures, you shouldn’t see this used as it is the avenue of last-resort when satisfying a VMs memory requirement. VSAN 6.2 allows you to zero out these swap files, thereby reclaiming a considerable amount of storage.
Below is the command to achieve this, which needs to be executed per-host and requires a reboot:
esxcfg-advcfg -s 1 /VSAN/SwapThickProvisionDisabled
Jase McCarty has written up a PowerCLI script that will automate this configuration change for you. This, and more details, can be found on his blog.
This one is extremely important, and I will be recommending all of our customer’s upgrade to VSAN 6.2 for this feature alone. VSAN will enable this by default and now perform the following checks to maintain data integrity and prevent “silent data rot”:
- Write failures to disks
- Network copy failures
- Checksum failures – if this occurs, VSAN will fetch data from another copy
- Disk Scrubbing, which will run in the background
- Automatically detects and solve silent disk errors
Other features, available to both All-Flash and Hybrid, include a Quality of Service (QoS) SLA that can be applied at a per-VMDK level; better capacity and performance monitoring within the vSphere Web Client and the ability to assign a Client Cache out of host memory.
Overall it reads as a solid release with some much-needed additional capabilities. VMware’s developers are clearly working hard in accelerating the maturity of the platform and catching up with the competition in key areas but, of course, the competition isn’t sleeping.
Update 18/03/16 – We’re hearing a lot of noise in the field relating to upgrade issues (https://communities.vmware.com/thread/532672), as well as the entire Dell fleet of systems not yet supported due to driver/firmware incompatibility (https://kb.vmware.com/kb/2144614).
Our recommendation is to wait for the inevitable VSAN 6.2a point release before scheduling this in your production environment.”