2-node vSAN with VMware Cloud on AWS

July 12, 2021

VMware Cloud on AWS offers a 30-day trial single host SDDC for proof of concept and development and test (dev/test) workloads. Customers looking to protect production workloads can start from as few as 2 hosts per SDDC and then scale up as needed. This post takes a closer look at VMC on AWS resiliency using a vSAN 2-node configuration. 

2-node vSAN VMC on AWS

 

How it works

VMware Cloud on AWS provides the VMware SDDC software stack to the highly scalable AWS Cloud, including vSphere, vSAN, NSX, and vCenter Server. While vSAN 2-node 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. To understand how VMC on AWS protects production workloads from failure, let's briefly review vSAN availability. 

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.

Policy Consumed Hosts
No data redundancy 100GB 1
1 Failure - RAID-1 200GB 3
2 Failure - RAID-1 300GB 5
1 Failure - RAID-5 EC 133GB 4
2 Failure - RAID-6 EC 150GB 6

Customers can use the VMC Sizer tool to plan out how to best utilize the 2-host cluster. As the cluster is RAID-1 by default, it will have usable storage similar to a Single Host SDDC upon provisioning. While the 2-host cluster does not have an SLA, upon provisioning, a managed storage policy profile is created, and scaling up to 4-hosts will enable RAID-5 and 6-hosts RAID-6. To move from an FTT of 1 to 2, one needs to scale up from 2-hosts to 5. 

According to the table above, 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. So if there's a minimum requirement of 3 devices/hosts, how then 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.

image 114

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.

image 113

Considerations

  • The 2-host cluster capability is not supported in any SDDC versions lower than 1.10v2.  All new SDDCs provisioned moving forward, regardless of the number of hosts and/or clusters, will be created using version 1.10v2 or newer and can support 2-host clusters. 
  • Scale down from 3 to 2-hosts is not currently possible. 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.
  • Elastic DRS Policies are limited to the Default Storage Scale-Out Policy

Summary

VMware has consistently strived to reduce costs while increasing its capabilities. With the addition of 2-node clusters, VMC customers can conduct paid trials with production workloads, a common challenge using single host instances. More importantly, these clusters can exist indefinitely, potentially serving as a pilot light in the cloud or your primary SDDC. 2-node clusters from VMware Cloud on AWS deliver a difference in scale, not kind, providing a smaller entry point into the cloud.

Resources

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

 

Filter Tags

Storage VMware Cloud on AWS vSAN 7 vSAN 2 Node Blog Intermediate