Worldwide Locations
Abstract
In 2013, VMware announced VMware Virtual SAN (VSAN), which is VMware's native version of Software Defined Storage (SDS). It is simple, easy to setup, and managed by user-defined policies. This paper explains VSAN, its basic requirements and how it works.
Sample
How VSAN Works
VSAN is designed to perform well and maximized available space. Previously it was mentioned that it is implemented at the vmkernel level to maximize performance from the compute side. This requires SSD drives for caching to maximize performance from the disk perspective, and requires at least 1 GbE (with 10 GbE recommended) on the network side. To maximize space, all vmdk files are thin provisioned and no parity or mirroring RAID is employed on the hosts. Additional capacity can be added by simply adding disks to a host and giving VSAN access to the new disks.
Enabling
Enabling VSAN is a very simple process. Once VSAN has been properly licensed, simply go to the desired cluster and check the box for VSAN, like you would for DRS or HA. Note that if HA is already enabled, you will need to temporarily disable it so that VSAN can be configured, then you can re-enable it.
Once you check the box, the only major question is how VSAN should get the disks it needs to work: automatically or manually? If you choose automatically, VSAN will automatically use all the SSD and magnetic disks that it can find that are not used elsewhere in the system (for example to boot the host) and will create disk groups automatically. If you want more control over which disks are to be used and/or which disks belong in which disk groups, choose manual and configure the disks as desired.
Storage Policies
The power of VSAN is not so much that it turns local storage into shared storage, though that is very impressive, but rather that policies can be setup and applied to VMs and that the system will automatically enforce those policies. There are several policies that can be set in VSAN. They include:
Failures to Tolerate:
Defines the number of copies of the disk(s) that should be created by specifying the number of concurrent failures that need to be withstood (from zero to three). If zero is specified, any failure of a disk or host will cause the VM to be inaccessible until the failure is corrected (and possibly data restored from backup). The number of copies will be one more than the number specified (i.e., one means two copies). This is sometimes known as RAIN (redundant array of independent nodes) and is always a mirroring-style replication (i.e., RAIN 1, even if more than one failure is tolerated). The purpose of this parameter is availability.
Stripe Width:
Specifies how many physical disks the data for a single vmdk is spread across. This is always done in RAIN 0 fashion (although it can be combined with the Failures to Tolerate to create a RAIN 0+1 design if desired). This setting is most important when greater performance is necessary and the read caching provided by the SSD drive is insufficient, requiring data to be read from the spinning disk(s), instead of the SSD read cache. If a value greater than one is specified, the data is split into 1 MB chunks across the disks. Note that enabling this feature will consume additional system resources.
Object Space Reservation:
Reserves the specified percentage of the disk space for the VM (assuming it is thin provisioned); it does not thick-provision the space, but rather uses the calculated space as if it were already provisioned in much the same way that a CPU or memory reservation is used in compute calculations used by vSphere, HA, and DRS. If a vmdk has been configured as either eager or lazy zero thick, this parameter is ignored (i.e., it is already at 100%).
By default, a single policy is created and used by everything that uses VSAN, and that policy is not visible in the Web Client. It is simply configured to tolerate the loss of a host, disk, or disk group by setting Failures to Tolerate to one.
Note: Don't confuse Storage Policies (used by VSAN only) with Storage Profiles (usable with any datastore type). Storage policies determine the performance and availability of a VM located on a VSAN datastore and are fully automatic once assigned, while Storage Profiles define a preferred storage type (typically based on the speed of the underlying disks) for a VM. The profiles are manually created and manually assigned and do not automatically move VMs to other disks if the profile-configured type is not the actual location of the VM (Storage vMotion would typically be manually invoked to fix the issue).