VMware VSAN : What’s new.
I’ll start with the little things. In addition to pushing out new features with each major release, VMware is great at delivering usability and management tools that make adoption and deployment easy. While many tend to focus on flashy numbers in new releases (“Support for a bazillion cores!”; “245% more cloud!”) my focus is generally focused on management and back end features that enable my team and customers accomplish more with less time.
On the front end, management of VSAN has been made “even more radically simple” in this release. With a click of a button, you will now be able to:
- trigger the notification lights for drives,
- evacuate and remove individual drives,
- flag drives as SSD (or not),
- and remove existing partitions to prepare a disk for VSAN
While hunting down device numbers through the CLI was fun, it’s good to replace “./storcli /c0 /e252 /s2 start locate” with clicking on the green light icon, making drive replacement service a less technical and less complex experience.
A lot of proof of concepts and brownfield deployments count on RAID-0-only controllers, and this should simplify and remove the need to manually flag devices for flash. Granular evacuations will allow for simple, safe and quick drive-by-drive upgrades, and simplifies proactive removal of drives nearing the end of their life. . These enhancements effectively eliminate my need to keep a StorCLI reference guide on my desk.
On the back end, some major low-level house cleaning has been done. The old VMFS-L system used by VSAN 5.5 is replaced with the new Log Structured File System. This was made possibly by VMware’s acquisition of Virstro in 2013. Virstro brought an innovative file system to the table, allowing not only significant improvement to random write workloads (VDI and OLTP users rejoice!), but radically different snapshots that carried lower overhead. It appears some of these concepts have finally made it to VSAN with the release of the new file system. While VSAN 5.5 buffers bursts of writes, this new system will radically improve non-burst steady state write IOPS.
In addition, a new log structure checkpoint system for snapshots allows for rapid snapshot creation and removal without the significant performance penalty that traditional redo log snapshots entail. With today’s vmfsSparse Snapshots, it is not recommended to leave snapshots open for any length of time as snapshot consolidation can “stun” a VM with a burst of write IO. Further, running a VM with multiple open snapshots can lead to a 50% or more decline in performance. The new vsanSparse snapshots should deliver comparable performance to traditional hardware array snapshots. This should drastically reduce issues with snapshot merges stunning VM’s under high load, snapshot consolidation errors, and allow for using regularly scheduled virtual machine snapshots to augment backups as part of your data protection strategy. QA and test/dev environments that use deep snapshot chains will experience orders of magnitude better disk performance.
Migrations to the new format will be non-disruptive (and will be managed through the RVC console) and though the legacy file system will still be supported, we expect quick adoption for the new format.