vSAN’s ability to provide a fully active-active, stretched cluster has already been proven. vSAN 6.6 takes this a step further, allowing for storage redundancy within a site AND across sites at the same time.
This helps deliver effective, affordable protection against entire site outages, as well as host outages within a site. When using across sites and within site protection, data does not have to be fetched from the alternate site in the event of a host or disk failure, helping deliver greater performance along with the added layer of protection.
This allows for mirrored protection across sites (RAID1), as well as mirrored protection for Hybrid architectures, and either mirrored (RAID1) or erasure coding (RAID5/6) protection for All-Flash architectures within a local site. Each site will still require enough hosts/capacity to meet the requirements of the local policy.
A common question asked since the announcement of vSAN 6.6, is “How do I properly size for capacity with vSAN 6.6 with Local Protection or Site Affinity?”
Sizing using traditional Policy Rules
vSAN Stretched Clusters capacity has traditionally been sized based on a single copy of data in each site. A VM that has a 100GB vmdk would require 200GB because of the mirrored replica. Before the introduction of Per-Site Policy Rules, vSAN could only provide a mirrored level of protection. Whatever the size of the data is, double it, minus any savings from thin provisioning.
When vSAN 6.2 was released, Erasure Coding was introduced. Like Mirroring, Erasure Coding provides protection based on the number of Failures to Tolerate. Erasure Coding requires All-Flash configurations as well as 4 or 6 Hosts/Fault Domains, depending on whether RAID5 or RAID6 protection is desired respectively. Traditional Stretched Clusters do not support Erasure Coding because the the Fault Domain requirements.
Sizing using vSAN 6.6 Per-Site Policy Rules
The Per-Site Policy Rules in vSAN 6.6 add the ability to provide either local protection to Stretched Cluster workloads, or provide protection for workloads that have an affinity to a single site. Providing additional protection is not without overhead though. Data written across sites is mirrored (like pre-vSAN 6.6), but local protection has additional space requirements.
Here is a quick reference to the amount of space required when using these features when compared to pre-vSAN 6.6 Stretched Cluster policies:
Hybrid vSAN 6.6 can have Across Site protection with local Mirroring, while All-Flash vSAN 6.6 can have Across Site protection with either Erasure Coding or Mirroring.
All-Flash architectures where customers choose to enable Erasure Coding will see the smallest additional capacity requirements. Enabling local protection with RAID5 only requires 33% more storage than without local protection. Local protection with RAID6 will consume 50% more storage than without local protection.
Local protection is not only for All-Flash vSAN 6.6 architectures. Hybrid vSAN 6.6 can mirror within sites. Protecting from a failure across sites, as well as within a site will require 100% more capacity for every level of Secondary Failures to Tolerate.
Also remember that policies may be configured and applied independently across vSAN objects. It may not be necessary to provide local protection to all virtual machines residing on a vSAN Stretched Cluster. Sizing requirements will depend on the workload and level of protection that is acceptable for it.
Summary
With the introduction of Local Protection and Site Affinity, vSAN 6.6 provides even more choice and availability to VM Storage Profiles on vSAN. These rules change the sizing conversation somewhat, but should be considered when performing a capacity sizing exercise for vSAN 6.6.
For more information on Stretched & 2 Node vSAN Clusters be sure to check out StorageHub.
