Considerations for Implementing vSphere Metro Storage Cluster (vMSC) on VMware Cloud Foundation 9.0

Products

• VMware Cloud Foundation

Issue/Introduction

This article provides information about deploying vSphere Metro Storage Cluster with VMware Cloud Foundation 9.0.

Environment

VMware Cloud Foundation 9.0

Resolution

What is vMSC?

VMware vSphere® Metro Storage Cluster (vMSC) is a specific storage configuration that is commonly referred to as a stretched storage cluster or metro storage cluster.

One common vMSC type is Uniform host access configuration. In this configuration vSphere hosts from both availability zones are connected to both storage arrays. The
paths presented to the vSphere hosts are stretched across a distance. In this configuration, read/write access to a LUN takes place on one of the two arrays and a
synchronous mirror is maintained in a hidden, read-only state on the second array.

For detailed information about storage implementation, refer to the documentation provided by your storage vendor.

VMware Cloud Foundation is unaware of vMSC and treats it the same as a vSphere cluster. As a result it is important for the partner and customer to validate that all VCF
Operations workflows can run successfully with the 3rd party solution before deploying into production.

Alternatives

vSAN Stretched Clusters are an attractive alternative to vMSC and offers the following
advantages:

● Licensed as part of VCF Bundle
● Pre-built automated workflows in VCF for Deployment and Day 2 operations
● Fully tested, validated, and supported solution by Broadcom|VMware

 

Support

In the past, vMSC storage configurations were validated through a mandatory certification program. As of vSphere 6.0 this program was discontinued. Before purchasing, designing or implementing a vSphere Metro Storage Cluster solution please contact your storage vendor to ensure that your solution has been tested with VMware Cloud Foundation 9.0.

Note: Broadcom|VMware does not test any vSphere Metrocluster Storage solutions internally.

IMPORTANT: Many storage vendors have tested compatibility with ESX 9.0 but have not completed testing by deploying the full VCF 9.0 suite and validating all of the VCF
Day 0 and Day 2 workflows.

 

Technical Requirements and Constraints

• Storage connectivity using Fibre Channel or NFS is supported for Deploy, Converge, and Upgrade scenarios.
• The maximum supported network latency between sites for vSphere ESX management networks is 10ms round-trip time (RTT) although many storage vendors require 5ms round-trip time (RTT).
• The maximum supported latency for synchronous storage replication is 10ms round-trip time (RTT).
• Storage IO Control is not supported on a vMSC datastore
• The layer-2 network for the Management VMs, such as vCenter and NSX Manager, must be stretched between datacenters for all configurations.
• Some customers may also choose to stretch the vSAN, vMotion and Host Overlay (TEP) networks.
• If NFS is used as principal storage, the L2 network for NFS must be stretched.
• Consider adding an additional host to protect the cluster during an upgrade.
• vSphere HA and DRS settings must be manually configured based on the guidance from the storage vendor.
• The Minimum Number of ESX hosts can be found in the VCF 9.0 Design Guide, Stretched Cluster Model Sizing Considerations section.

 

 

Note: Because VCF is unaware of the underlying vMSC these minimums are not
enforced.

Common Network Configurations

There are several supported Network Configurations. The most common configurations include:

● Stretch Management VM Layer-2 Network Only
● Stretch All Layer-2 Networks

Stretch Management VM Layer-2 Network Only

In this example the only network that is stretched is the Management VM Network which hosts vCenter, NSX Manager, VCF Operations, etc. This example increases the total
number of subnets and VLANs required for the Stretched Cluster configuration however it creates smaller failure domains for these networks. As an example, a denial-of-
service attack or a network broadcast storm could be isolated to the local VLAN. To ensure the fastest recovery time in the event of a failure, ensure that your VMs can be
powered-on in Availability Zone 2 without requiring IP Addresses to be reconfigured.

Note: If NFS is used as principal storage, the L2-network for NFS must be stretched between Availability Zones.

Stretch All Networks

In this example all Layer-2 networks are stretched between Availability Zones. This example reduces the total number of subnets required for the Stretched Cluster
configuration. To ensure the fastest recovery time in the event of a failure, ensure that your VMs can be powered-on in Availability Zone 2 without requiring IP Addresses to be
reconfigured.

Note: The ESX Mgmt Network (vmk0) VLAN:1610 in the Stretch All Networks example above does not need to be stretched. Some customers may wish to use a unique
network for ESX Mgmt as pictured in the Stretch Management VM Layer-2 Network example.

 

Summary of Deployment Steps
There are multiple ways to deploy a vMSC with VMware Cloud Foundation. Follow the
steps in the Managing VCF Domains in VMware Cloud Foundation

Deployment Options:

● Deploy a new VCF Instance with VCF Installer **Requires Stretch All Networks
● Create a new Workload Domain using VCF Operations
● Import an Existing vCenter to Create a Workload Domain
● Workload Domain with a Layer 3 Multi-Rack Cluster
● Add an SDDC Cluster to a VCF Domain

 

Additional Steps Required

Once you have deployed the new vMSC Cluster follow storage vendor recommendations for vSphere HA and DRS.

Update vSphere HA and DRS Settings

After you have configured the new vMSC you will need to update vSphere HA and DRS settings based on the recommendations from your storage vendor. This includes the
following:

● vSphere HA Failures and Responses
● vSphere HA Admission Control
● vSphere HA Advanced Options
● vSphere HA Restart Priority
● vSphere DRS Automation
● vSphere DRS Affinity Rules