posted

0 Comments

I have always been a fan of stretched cluster solutions since VMware introduced the certification program vSphere Metro Storage Cluster (vMSC) back in 2016. Who doesn’t want the ability to balance VMs synchronously between datacenters for site resilience or even site maintenance?  In my previous life working for a storage vendor, I had many conversations with customers on this topic and it usually boiled down to technical constraints, complexity, or simple cost. A traditional stretched cluster solution typically requires dedicated storage arrays at both sites, additional licensing, switches, and external gateways. And considering the complexity, its usually required to have a Professional Services engagement to deploy. Once deployed, the maintenance was also complex and spread out across multiple vendors with several points of failure. In the end, the pattern was clear that the traditional way stretched clusters were approached was a fit only to large data centers with hefty IT budgets, but no one else.

vSAN Stretched Cluster

That’s why I was pretty excited when VMware announced vSAN Stretched Cluster in 6.6. Finally, a highly resilient stretched cluster solution fully integrated into vSphere, simple to deploy, manage and at a reasonable cost. This broadens the use case to not only enterprises but SMBs as well.

Stretched Clusters the vSAN way

vSAN Stretched Clusters provide resilience against the loss of an entire site. vSAN is integrated tightly with vSphere Availability (HA). If a site goes offline unexpectedly, vSphere HA will automatically restart the virtual machines affected by the outage at the other site with no data loss. The virtual machines will begin the restart process in a matter of seconds, which minimizes downtime.

vSAN stretched clusters are also beneficial in planned downtime and disaster avoidance situations. Virtual machines at one site can be migrated to the other site with VMware vMotion. Issues such as an impending storm or rising flood waters typically provide at least some time to prepare before disaster strikes. Virtual machines can easily be migrated out of harm’s way in a vSAN Stretched Cluster environment.

Simple Deployment

The deployment of vSAN Stretched Cluster is completed using the vSphere wizard connecting a minimum of 2 (maximum 30 hosts) across two active/active sites, using an ESXi host (physical or virtual appliance) as a witness residing at a third site. The data sites are connected via a high bandwidth/low latency network link. The third site hosting the vSAN witness host is connected over a network to both of the active/active “data” sites. The connectivity between the data sites and the witness site can be via lower bandwidth/higher latency network links.

Network bandwidth and round-trip time (RTT) latency are the primary factors that must be considered when deploying a vSAN Stretched Cluster. Because writes are synchronous, they must be committed before they may be acknowledged. When RTT latencies are higher than five milliseconds (5ms) performance issues may result. The maximum supported RTT between the two data sites is 5ms. For detailed information about vSAN Stretched Cluster deployment be sure to reference storagehub.vmware.com.

vSAN stretched clusters use SPBM to provide extraordinary levels of flexibility and granularity for any vSAN environment, and is one of the staples behind vSAN’s ease of use. Using separate policies for VMs in stretched clusters is a simple operational practice that can help virtualization administrators become more comfortable with introducing and managing one or more stretched clusters in a vSAN powered environment.

Conclusion

vSAN Stretched Cluster

As I write this post on my state-of-the-art laptop, sipping imported espresso in the comfort of my air-conditioned home, it appears to me, with all the advancements in technology, we are all living a higher quality of life than the kings of old. In that same regard, vSAN puts the various benefits of a stretched cluster (site-resiliency, disaster avoidance, and nondisruptive site maintenance) in the hands of every VMware admin.

@vPedroArrow