Stretched Clusters are a force multiplier within the VMware Cloud on AWS Service. The ability to resolve AWS Availability with an infrastructure level solution enables mission-critical workloads to move into the AWS cloud without rearchitecting site availability. In a strange turn of events, this capability introduces new challenges while solving for availability. Mainly, what if I don’t want to mirror a workload between AZ’s, can AZ locality be managed?
Background
It’s common for a business to have one or more key applications. These workloads are often critical for essential business functions and intolerant of any loss. In such situations, vSAN Stretched Clusters can protect all transactions by synchronously mirroring data between Availability Zones. There is an added cost associated with this redundancy, and therefore customers who deploy a stretched cluster often ask if they can remove AZ redundancy for select workloads. The short answer is yes; however, a couple of things to know when doing so.
Considerations
SLA Impact
For vSphere to restart a workload in the event of AZ failure, there must be an accessible copy of the data inside the surviving AZ. This is why Dual Site Mirroring is a prerequisite for SLA eligibility. VMware Operations cannot guarantee 99.99% availability without the redundant copy of the data. Therefore, only consider disabling when the complete loss of the workload and its data would be tolerable. In practice, these are usually applications that handle data consistency and availability (E.g., Microsoft SQL Server Always-On Availability Group).
Compute Policies
The other consideration when disabling site disaster tolerance is VM locality. While DRS will not vMotion a VM between AZ’s, an Administrator can accidentally separate a VM from its local data copy resulting in all reads and writes traversing the cross-AZ connection. Since this is a metered connection, it is best practice to configure Compute Policies to keep any non-replicated VM’s in the appropriate AZ.
Storage Policies
When using the service’s default, vSAN synchronously replicates data between AZ. Each AZ is associated with a vSAN Fault Domain. To pin a VM’s data to a particular AZ (fault domain), create a pair of custom storage policies pinning the VM’s data within either the preferred or non-preferred fault domains.
Preferred/Non-preferred are merely labels to differentiate one fault domain from the other, they are both active, and workload can reside in either.
Putting it All Together
To configure the SDDC to pin a workload within a designated AZ, create the appropriate VM storage policies.
With the Storage Policies in place, vSAN is ready, but DRS is still ignorant of the desired layout. To bring it into the mix, add a pair of VM-Host affinity Compute Policies.
With both the Compute and VM Storage policies in place, the environment is ready to manage AZ locality. If dealing with several SDDC’s this process can be automated.
Configure Locality
- With the prerequisites in place, Storage locality can be managed by assigning the relevant VM Storage Policy.
- Ensure that the equivalent compute policy is also applied by adding the associated Tag.
- With both in place, vSAN will work in conjunction with DRS to keep the VM and its data contained within the designated Availability Zone.
These policies can be changed at any time and locality will be non-disruptively updated accordingly.
Summary
The VMware Cloud on AWS Service enables customers to bring their essential operations directly within the AWS cloud. When those operations are intolerant to lose, Stretched Clusters can resolve AWS availability using an infrastructure level solution. This powerful capability can also be deactivated on a per-VM or per-VMDK basis as needed. This flexibility enables our Customers to right-size their SDDC for their particular business or workload, controlling cloud costs without compromising on capability.
Availability
To view the latest status of features for VMware Cloud on AWS, visit https://cloud.vmware.com/vmc-aws/roadmap.
Resources:
- Learn more about VMware Cloud on AWS and watch this VMware Cloud on AWS: Overview (video)
- Follow us on Twitter at@vmwarecloudaws and at @VMwarevSAN and give us a shout with #VMWonAWS
- Try the VMware Cloud on AWS Hands-on Lab for a first-hand immersive experience
- Read our latest VMware Cloud on AWS blogs
- Obtain the VMware Cloud on AWS Solution Brief and VMware Cloud on AWS TCO 1-pager
- Follow the VMware Cloud on AWS release notes on continuing updates
- Connect with me on Twitter at @glnsize
