How VMware’s vSAN provides the storage component for a hyper-converged data center.

VMware’s vSAN (virtual SAN) architecture is designed to be a significant step into software-defined-computing, where the vSAN component is responsible for providing software-defined storage.

Previously, systems architecture was one server containing its own compute, operating system, networking and storage. Virtualization abstracted this so that more than one OS could run per server, if still bound by captive network functionality, and storage.

+See our review of vSAN 6.6+

What is hyper-convergence?

Hyper-convergence is the ability to abstract all of the components, be it the OS, storage, the network relationships a system has, and so forth. It’s the foundation of the software-defined-datacenter, distributed yet converged into a workload unit.

The hyper-convergence component of vSAN takes all the extra disks on your server and aggregates them as a single storage pool. The poo is shared across all the servers in a cluster of vSphere virtual servers. (vSphere is VMware’s server-virtualization platform.) No disk belongs solely to the virtual machines running on that host. The host contains compute (CPUs and memory) and network (now run through virtual switches), but it no longer owns or is captive to the disks running inside of it.

Instead, the disks are now part of the vSAN and can be used by any of the compute workloads within the cluster. Their actual location is now only sensitive to latency elements, meaning hybrid constructions (parts in different locales, or cloud/datacenter) construction designs are much more plausible and realistic to service.

How vSAN fits in a hyper-converged data center

One of the solid state disks must be used for a cache tier (vSAN cannot be used without at least one SSD) and other drives may be used in the capacity tier. If all the hard drives are SSD, then vSAN has a few more options available, such as compression and deduplication (subject to the license being used). VM files are stored on multiple servers that are not captive to the specific host where the VM (and its compute plus memory) are running.

Large storage pools could be accomplished without vSAN by using external storage methods, the most popular of which is turning just a bunch of disk (JBOD) groups into external storage spaces via the Ethernet-based iSCSI protocol.

To instantiate and maintain it, however, requires a large number of steps, and is maintained usually outside of the auspices of VMware. This means multiple vendors, and possible problems with revision syncing. RAID or RAID-like external disk subsystem arrays, sometimes with host bus adapters or other control-plane communications, can send alerts to VMware or externally to an administration console. Because vSAN’s components are integrated, third-party devices and software could be eliminated in this hyper-converged design if desired.

High availability may be maintained inside VMware or in some cases, as an add-on to VMware. The latter introduces complexity at the price of forfeiting potential features and inter-vendor problems mentioned above, and/or under the auspices of external or third-party disk subsystem storage software. The architecture behind vSAN provides a vendor-agnostic method of using potentially inexpensive server configurations. 

Tom Henderson