Convert SM active sync from asymmetric to symmetric active/active with VMware vSphere Metro Storage Cluster
This article details how to convert SnapMirror active sync from asymmetric to symmetric active/active with VMware vSphere Metro Storage Cluster (VMSC).
Overview
NetApp Snapmirror active sync (SM active sync) is a robust solution for achieving zero Recovery Time Objective (RTO) and zero Recovery Point Objective (RPO) in a virtualized environment.
VMware vSphere Metro Storage Cluster (vMSC) is a stretched cluster solution across different fault domains and allows virtual machines (VMs) to be distributed across two geographically separated sites, providing continuous availability even if one site fails.
Combining vMSC with SM active sync ensures data consistency and immediate failover capabilities between two sites. This setup is particularly crucial for mission-critical applications where any data loss or downtime is unacceptable.
SM active sync, previously known as SnapMirror Business Continuity (SMBC), enables business services to continue operating even through a complete site failure, supporting applications to fail over transparently using a secondary copy. Beginning with ONTAP 9.15.1, SM active sync supports a symmetric active/active capability. Symmetric active/active enables read and write I/O operations from both copies of a protected LUN with bidirectional synchronous replication so that both LUN copies can serve I/O operations locally.
This document shows you the steps of how to convert SM active sync asymmetric active/active to SM active sync symmetric active/active in a VMware stretch cluster environment, in other words converts a SM active sync from an automated failover policy to automated failover-duplex policy. For the details of how to setup the vMSC with SnapMirror active sync (SM-as) utilizing System Manager and ONTAP Tools, check VMware vSphere Metro Storage Cluster with SnapMirror active sync.
Prerequisites
-
NetApp storage systems: ensure you have two NetApp storage clusters (source and destination) with Snapmirror licenses.
-
Network connectivity: verify low-latency network connectivity between the source and destination systems.
-
Cluster and SVM peering: set up cluster peering and Storage Virtual Machine (SVM) peering between the source and destination clusters.
-
ONTAP Version: ensure both clusters are running a version of ONTAP that supports synchronous replication. For SM active sync, ONTAP 9.15.1 and onward, is required.
-
VMware vMSC infrastructure: a stretched cluster enables the subsystems to span geographies, presenting a single and common base infrastructure set of resources to the vSphere cluster at both sites. It stretches network and storage between sites.
-
Use ONTAP tools 10.2 onwards for ease of use for NetApp SnapMirror, more details check ONTAP tools for VMware vSphere 10.
-
A zero RPO Snapmirror synchronous relationship must exist between the primary and secondary cluster.
-
All LUNs on the destination volume must be unmapped before the zero RTO Snapmirror relationship can be created.
-
Snapmirror active sync only supports SAN protocols (not NFS/CIFS). Ensure no constituent of the consistency group is mounted for NAS access.
Steps to convert from asymmetric to symmetric SM active sync
In the example below, selectrz1 is the primary site and selectrz2 is the secondary site.
-
From the secondary site, perform a SnapMirror update on the existing relationship.
selectrz2::> snapmirror update -destination-path site2:/cg/CGsite1_dest
-
Verify that the SnapMirror update completed successfully.
selectrz2::> snapmirror show
-
Pause each of the zero RPO synchronous relationships.
selectrz2::> snapmirror quiesce -destination-path site2:/cg/CGsite1_dest
-
Delete each of the zero RPO synchronous relationships.
selectrz2::> snapmirror delete -destination-path site2:/cg/CGsite1_dest
-
Release the source SnapMirror relationship but retain the common snapshots.
selectrz1::> snapmirror release -relationship-info-only true -destination-path svm0.1:/cg/CGsite1_dest ".
-
Create a zero RTO SnapMirror synchronous relationship with the AutomatedFailoverDuplex policy.
selectrz2::> snapmirror create -source-path svm0.1:/cg/CGsite1 -destination-path site2:/cg/CGsite1_dest -cg-item-mappings site1lun1:@site1lun1_dest -policy AutomatedFailOverDuplex
-
If the existing hosts are local the primary cluster, add the host to the secondary cluster and establish connectivity with respective access to each cluster.
-
On the secondary site, delete the LUN maps on the igroups associated with remote hosts.
selectrz2::> lun mapping delete -vserver svm0 -igroup wlkd01 -path /vol/wkld01/wkld01
-
On the primary site, modify the initiator configuration for existing hosts to set the proximal path for initiators on the local cluster.
selectrz1::> set -privilege advanced selectrz1::*> igroup initiator add-proximal-vserver -vserver site1 -initiator iqn.1998-01.com.vmware:vcf-wkld-esx01.sddc.netapp.com:575556728:67 -proximal-vserver site1
-
Add a new igroup and initiator for the new hosts and set the host proximity for host affinity to its local site. Enable igroup replication to replicate the configuration and invert the host locality on the remote cluster.
selectrz1::*> igroup modify -vserver site1 -igroup smbc2smas -replication-peer svm0.1 selectrz1::*> igroup initiator add-proximal-vserver -vserver site1 -initiator iqn.1998-01.com.vmware:vcf-wkld-esx01.sddc.netapp.com:575556728:67 -proximal-vserver svm0.1
-
Discover the paths on the hosts and verify the hosts have an Active/Optimized path to the storage LUN from the preferred cluster.
-
Deploy the application and distribute the VM workloads across clusters.
-
Resynchronize the consistency group.
selectrz2::> snapmirror resync -destination-path site2:/cg/CGsite1_dest
-
Rescan host LUN I/O paths to restore all paths to the LUNs.