This tip looks at VMware flash use with Virtual SAN, which many storage pros are interested in. Essentially, VMware...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Virtual SAN can make shared storage out of a group of servers that are already in place. While VMware requires flash to be a part of its clustering configuration, this strategy doesn't make life easier for all IT pros. In addition to increasing the cost per node to a point that may place the technology beyond the reach of smaller organizations, VMware doesn't use flash storage very well in cases of write buffering.
To be clear, VMware states flash must be present in every Virtual SAN (VSAN) node, where it is used for both read and write buffering. However, it's the write-buffering role that presents a challenge when using flash with VSAN. That's because flash can be burned out quickly by VMware-hosted workloads -- when used as a write cache -- missing any sort of write technology that aggregates writes and reduces the number of write operations. Even pricey enterprise-class multi-level cell (eMLC) flash devices are limited to a couple of hundred thousand writes per cell location. When that threshold is exceeded in most MLC devices, the cell burns out, which usually requires the rest of the cells in the group to which the dead cell belongs to be retired.
The solution to this problem is well-known and already implemented in VSANs from vendors such as StarWind Software and DataCore Software. In both cases, these vendors use server DRAM for write buffering rather than flash. Writes coalesce in the DRAM buffer for a period of time, and then are written to flash storage in fewer large transactions rather than many small ones. The lower write frequency extends the life of the flash device.
The use of VMware flash solely in a caching role also stands in the way of IT planners seeking to realize the all-silicon data center. Growing the capacity of a VMware VSAN node is accomplished by adding more disks, not more flash storage. While the vendor said it will attend to these issues in next year's release, storage pros who need action sooner might do well to consider alternative software-defined storage (SDS) wares that are both hardware- and software-agnostic.
For smaller firms that aren't as interested in silicon, even 10 GB of high-quality flash can cost hundreds of thousands of dollars. Given the licensing costs for vSphere/ESXi and each node of VSAN ($2,495 per CPU), software costs alone will total between $15,000 and $20,000 for a three-node cluster. Add in the disk and flash, and the hardware will double the cost of the software -- which is a problem for those without deep pockets and a cultish loyalty to a particular hypervisor vendor.
It is no wonder smaller consumers are expressing discontent with a vendor whose strategy doesn't seem to embrace much interest in the smaller guy. Even if you agree with VMware's strategy and prefer to have your SDS delivered in a single proprietary hypervisor software stack that effectively isolates storage from any non-VMware application, the limitations imposed on the use of flash in the current version should be considered closely before adopting the VMware flash approach.
Does VSAN fit in your environment?
Key differences between a traditional VSAN and VMware's VSAN