posted

0 Comments

2-node vSAN VMC on AWS

The release of 2-node cluster support within VMware Cloud on AWS lowered the entry point for the service, allowing customers to stand up a production-ready presence within the AWS cloud using a pair of vSphere hosts. While 2-node vSAN has been available on-premises for a few years, the VMC on AWS implementation builds upon that pedigree to provide seamless scale-up capabilities from 2-200+ nodes.
 

How does it work?

 
To understand how this works and the implications for any VMC on AWS customers, let's briefly review how vSAN protects from failure.
 
An object in vSAN consists of multiple components. The actual number and composition depend on the Failure to Tolerate policy configuration. For now, remember that for a vSAN object to be available, vSAN must be able to access more than 50% of the components associated with a given object. To accomplish this goal, vSAN treats each host or node as an independent failure domain and places each component of a given object onto a separate Host. This is why vSAN requires a specific number of hosts/nodes to use a given policy option.
 

SPBM

 
A quick review of the available policy options reveals that a three-node cluster can protect from a single failure using Raid-1 Mirroring. A 1 failure - RAID-1 object, consists of two copies of the data, and a witness component. With a minimum requirement of 3 devices/hosts how does 2-node provide resiliency?
 

vSAN Metadata Witness

 
The vSAN witness uses a unique vSphere installation, which fulfills the third host requirement for a 2-node cluster. In the case of VMware Cloud on AWS, the witness runs on an EC2 M5.XL AMI, and is fully managed by VMware.

vSAN Metadata witness in VC
 
Once configured, the cluster can protect from failure using a 1 failure - Raid-1 policy by storing a full data copy on each host, sending the witness component to the metadata witness hosts. With three data components, vSAN can lose any single host without impacting data availability.
 
Raid-1 Object Tree view
 

Considerations

 
All told this means that a 2-node i3.metal cluster adds resiliency, and with it the VMware Cloud on AWS standard Service Level Agreement and support guarantees. But the second node does not add additional capacity. A 2-node cluster can hold roughly 7-11+ TiB of VM data depending on storage space savings.
 
2-node clusters are identical to 3+ node clusters in every way, but one. If scaled up to three hosts, they cannot be scaled back down. The scale-up process from 2->3 hosts replaces the Metadata Witness with a vSphere/vSAN host. Once added, the service does not support scaling back down.
 
Animated Gif Showing the scale-up process
 

Enterprise Resiliency meets Cloud Agility.

 
Over the past three years, VMware has consistently strived to reduce costs while increasing capabilities. With the addition of 2-node clusters, VMC customers can conduct paid trials with production workloads, a common challenge with our single host instances. More importantly, these clusters can exist indefinitely, potentially serving as a pilot light in the cloud or your primary SDDC. With 2-node clusters, we deliver a difference in scale, not kind. Ensuring that anyone looking for a smaller entry point into cloud will want to evaluate VMware Cloud on AWS.
 

Availability

 
To view the latest status of features for VMware Cloud on AWS, visit vmware.com/vmc-aws/roadmap.
 

Resources