Configure vSphere Metro Storage Cluster with HPE Nimble Storage Peer Persistence

[StorageExperts]

This post will summarize the benefits of VMware vSphere Metro Storage Clusters (vMSC) and HPE Nimble Peer Persistence, as well as how they’ll be combined.

This topic is of particular interest to VMware customers seeking a site-resilient storage option for their stretch cluster. This single VMware cluster is spread out across two physical sites, whether in the same data center or across a metro area, defined as less than 5ms latency or ~100km. HPE Nimble Peer Persistence allows for an array at each site to serve data locally, while also supporting an application transparent failover when a fault situation arises.

What is VMware vSphere Metro Storage Cluster?

Let’s start with the basics.

The VMware vSphere Metro Storage Cluster (vMSC) is a tested and supported configuration for stretched storage cluster architectures. A vMSC configuration is designed to maintain data availability beyond a single physical or logical site, and minimize the amount of downtime for the application workloads. Ultimately, the configuration aims to expand the benefits from a local, highly available cluster and apply them to a geographically dispersed cluster.

The following best practices document was developed to provide additional insight and information for operation of a vMSC infrastructure in conjunction with VMware vSphere. This paper explains how vSphere handles specific failure scenarios, and it discusses various design considerations and operational procedures. VMware vSphere Metro Storage Cluster Recommended Practices.

What is HPE Nimble Peer Persistence?

Also known as “synchronous replication with application-transparent failover,” Peer Persistence offers volume-level protection between two physically separated arrays. HPE Nimble Peer Persistence is included in HPE NimbleOS 5.1 and later, including the latest HPE Alletra 6000 series, as well as previous generations, with the exception of the HF20H and CS1000H. It’s good to note that synchronous replication can be applied to specific VMFS volumes; it’s not an all-or-nothing configuration. You can find more in-depth information in the HPE Nimble Storage Peer Persistence Deployment Guide, Deployment considerations for NimbleOS 5.1 and later.

What happens when we combine the two?

HPE Nimble Storage Peer Persistence provides a resilient foundation for vMSC. There are a few requirements to meet:

• 5ms latency between arrays (10+ Gbps link is preferred)
• Exactly two arrays, formed into a group (they will be managed from a single interface)
• A single vCenter cluster with hosts local to each site
• Uniform SAN paths from each host to both storage arrays

As seen in the figure above, each site has its own local array. VMware Host and VM policies are deployed to ensure that workloads prioritize hosts connected to the local storage array. During normal operation, key volumes and datastores are protected by synchronous replication. Should a host lose SAN connectivity to its local array, the Nimble Connection Manager (NCM) coupled with the Nimble Path Selection Plug-in (PSP) automatically update which paths are active. This switchover is transparent to the VM workload. As a result, a VM restart is not necessary, as might be the case after a host failure. For full configuration details and more failure scenario examples, see Page 16 of this technical paper Implementing vSphere Metro Storage Cluster Using HPE Nimble Storage Peer Persistence.

In conclusion

Peer Persistence helps complete your VMware vMSC deployment. Existing and future HPE Nimble Storage customers can take advantage of this crucial feature through Timeless Storage for HPE Nimble Storage.

Thanks for reading my blog. I look forward to your questions and comments!

Denney Liptak is a Storage Solutions Engineer with 10+ years’ experience developing and supporting enterprise block and file storage. Currently composing application (vmware, SQL Server and virtual desktop infrastructure) solutions highlighting integration with HPE Nimble, Primera and Alletra storage arrays. You can connect with Denney on LinkedIn.

Storage Experts
Hewlett Packard Enterprise

twitter.com/HPE_Storage
linkedin.com/showcase/hpestorage/
hpe.com/storage

---

[Richard Kenyon]

Hi Denney,

" It’s good to note that synchronous replication can be applied to specific volumes" - please let's be clear, this applies to VMFS volumes only; VMware vVols are not (yet) supported in this architecture.

Also, I don't see much advancement in this blog post when comparing it to previous HPE or Partner blog posts on this subject from 2019, any reason?

• HPE Blog: Nimble OS 5.1 - Intro to Peer Persistence (Part 1) blog
• HPE Partner Blog: Sync replication and Peer Persistence setup – HPE Nimble

[StorageExperts]

Hi Richard,

Thank you for reaching out! Yes, I think it’d be good to qualify “…synchronous replication can be applied to specific VMFS volumes…”. That has now been updated.

Ultimately, the whole array isn’t required to be configured for PP, as that is defined at the volume level.

After some good conversation, it'd also be good to share that asynchronous replication cannot occur on the same pair of arrays configured for synchronous replication. To enable asynchronous jobs, a third array (not part of the pair-group) would need to be involved.

Regarding the blog post: While there is overlap with core features, we wanted to draw highlight to the combination of features as applied in a vSphere Metro Storage Cluster and to help promote the recently published white paper on the subject.

Cheers,

--Denney