Skip to main content

Protect with ONTAP SnapMirror active sync

Contributors netapp-ahibbard netapp-lenida netapp-aaron-holt netapp-dbagwell netapp-aherbin
PDFs

SnapMirror active sync offers asymmetric protection and, beginning with ONTAP 9.15.1, symmetric active/active protection.

Configure asymmetric protection

Configuring asymmetric protection using SnapMirror active sync involves selecting LUNs on the ONTAP source cluster and adding them to a consistency group.

Before you begin

  • You must have a SnapMirror synchronous license.

  • You must be a cluster or storage VM administrator.

  • All constituent volumes in a consistency group must be in a single storage VM (SVM).

    • LUNs can reside on different volumes.

  • The source and destination cluster cannot be the same.

  • You cannot establish SnapMirror active sync consistency group relationships across ASA clusters and non-ASA clusters.

  • The default IPspace is required by SnapMirror active sync for cluster peer relationships. Custom IPspace is not supported.

  • The name of the consistency group must be unique.

  • The volumes on the secondary (destination) cluster must be type DP.

  • The primary and the secondary SVMs must be in a peered relationship.

Steps

You can configure a consistency group using the ONTAP CLI or System Manager.

Beginning with ONTAP 9.10.1, ONTAP offers a consistency group endpoint and menu in System Manager, offering additional management utilities. If you are using ONTAP 9.10.1 or later, see Configure a consistency group then configure protection to create a SnapMirror active sync relationship.

Important From ONTAP 9.14.1 through 9.8, SnapMirror active sync is referred to as SnapMirror Business Continuity (SM-BC).
System Manager

  1. On the primary cluster, navigate to Protection > Overview > Protect for Business Continuity > Protect LUNs.

  2. Select the LUNs you want to protect and add them to a protection group.

  3. Select the destination cluster and SVM.

  4. Initialize relationship is selected by default. Click Save to begin protection.

  5. Go to Dashboard > Performance to verify IOPS activity for the LUNs.

  6. On the destination cluster, use System Manager to verify that the protection for business continuity relationship is in sync: Protection > Relationships.

CLI

  1. Create a consistency group relationship from the destination cluster.
    destination::> snapmirror create -source-path source-path -destination-path destination-path -cg-item-mappings volume-paths -policy policy-name

    You can map up to 12 constituent volumes using the cg-item-mappings parameter on the snapmirror create command.

    The following example creates two consistency groups: cg_src_ on the source with `vol1 and vol2 and a mirrored destination consistency group, cg_dst.

    destination::> snapmirror create -source-path vs1_src:/cg/cg_src -destination-path vs1_dst:/cg/cg_dst -cg-item-mappings vol_src1:@vol_dst1,vol_src2:@vol_dst2 -policy AutomatedFailOver

  2. From the destination cluster, initialize the consistency group.

    destination::>snapmirror initialize -destination-path destination-consistency-group

  3. Confirm that the initialization operation completed successfully. The status should be InSync.

    snapmirror show

  4. On each cluster, create an igroup so you can map LUNs to the initiator on the application host.
    lun igroup create -igroup name -protocol fcp|iscsi -ostype os -initiator initiator_name

    Learn more about lun igroup create in the ONTAP command reference.

  5. On each cluster, map LUNs to the igroup:

    lun map -path path_name -igroup igroup_name

  6. Verify the LUN mapping completed successfully with the lun map command. Then, you can discover the new LUNs on the application host.

Configure symmetric active/active protection

You can establish symmetric protection using System Manager or the ONTAP CLI. In both interfaces, there are different steps for uniform and non-uniform configurations.

Before you begin

  • Both clusters must be running ONTAP 9.15.1 or later.

  • Symmetric active/active configurations require the AutomatedFailoverDuplex protection policy. Alternately, you can create a custom SnapMirror policy provided the -type is automated-failover-duplex.

  • In ONTAP 9.15.1, symmetric active/active is only supported on 2-node clusters.

  • Beginning with ONTAP 9.16.1 GA, SnapMirror active sync supports symmetric active/active configurations on four-node clusters.

    • To use SnapMirror active sync on a four-node cluster, you must be running ONTAP 9.16.1 GA or later.

    • Before deploying a four-node configuration, you must create a cluster peer relationship.

    • Review the limits for four-node clusters.

    • If you revert to a two-node cluster, you must remove the SnapMirror active sync relationships from the cluster before reverting.

    • You can use the four-node configuration to upgrade storage and controllers. This process is non-disruptive and expands the cluster while moving volumes into the new nodes. For more information, see refresh a cluster.

  • Beginning with ONTAP 9.17.1, you can configure symmetric active/active protection on NVMe namespaces only when both clusters are running ONTAP 9.17.1 or later.

Configure symmetric active/active protection using a SCSI SnapMirror active sync configuration

Steps

You can use System Manager or the ONTAP CLI to configure symmetric active/active protection using SCSI protocol host mappings.

System Manager
Steps for a uniform configuration

  1. On the primary site, create a consistency group using new LUNs.

    1. When creating the consistency group, specify host initiators to create igroups.

    2. Select the checkbox to Enable SnapMirror then choose the AutomatedFailoverDuplex policy.

    3. In the dialog box that appears, select the Replicate initiator groups checkbox to replicate igroups. In Edit proximity settings, set proximal SVMs for your hosts.

    4. Select Save.

Steps for a non-uniform configuration

  1. On the primary site, create a consistency group using new LUNs.

    1. When creating the consistency group, specify host initiators to create igroups.

    2. Select the checkbox to Enable SnapMirror then choose the AutomatedFailoverDuplex policy.

    3. Select Save to create the LUNs, consistency group, igroup, SnapMirror relationship, and igroup mapping.

  2. On the secondary site, create an igroup and map the LUNs.

    1. Navigate to Hosts > SAN Initiator Groups.

    2. Select +Add to create a new igroup.

    3. Provide a Name, select the Host Operating System, then choose Initiator Group Members.

    4. Select Save to initialize the relationship.

  3. Map the new igroup to the destination LUNs.

    1. Navigate to Storage > LUNs.

    2. Select all the LUNs to map to the igroup.

    3. Select More then Map to Initiator Groups.

CLI
Steps for a uniform configuration

  1. Create a new SnapMirror relationship grouping all the volumes in the application. Ensure you designate the AutomatedFailOverDuplex policy to establish bidirectional sync replication.

    snapmirror create -source-path <source_path> -destination-path <destination_path> -cg-item-mappings <source_volume:@destination_volume> -policy AutomatedFailOverDuplex

    Example:
    The following example creates two consistency groups: cg_src on the source with vol1 and vol2, and a mirrored consistency group on the destination, cg_dst.

    destination::> snapmirror create -source-path vs1_src:/cg/cg_src -destination-path vs1_dst:/cg/cg_dst -cg-item-mappings vol_src1:@vol_dst1,vol_src2:@vol_dst2 -policy AutomatedFailOver

  2. Initialize the SnapMirror relationship:
    snapmirror initialize -destination-path <destination-consistency-group>

  3. Confirm the operation has succeeded by waiting for the Mirrored State to show as SnapMirrored and the Relationship Status as Insync.

    snapmirror show -destination-path <destination_path>

  4. On your host, configure host connectivity with access to each cluster according to your needs.

  5. Establish the igroup configuration. Set the preferred paths for initiators on the local cluster. Specify the option to replicate the configuration to the peer cluster for inverse affinity.

    SiteA::> igroup create -vserver <svm_name> -ostype <os_type> -igroup <igroup_name> -replication-peer <peer_svm_name> -initiator <host>

    Note Beginning with ONTAP 9.16.1, use the -proximal-vserver local parameter in this command.

    SiteA::> igroup add -vserver <svm_name> -igroup <igroup_name> -ostype <os_type> -initiator <host>

    Note Beginning with ONTAP 9.16.1, use the -proximal-vserver peer parameter in this command.

  6. From the host, discover the paths and verify the hosts have an active/optimized path to the storage LUN from the preferred cluster.

  7. Deploy the application and distribute the VM workloads across clusters to achieve the required load balancing.

Steps for a non-uniform configuration

  1. Create a new SnapMirror relationship grouping all the volumes in the application. Ensure you designate the AutomatedFailOverDuplex policy to establish bidirectional sync replication.

    snapmirror create -source-path <source_path> -destination-path <destination_path> -cg-item-mappings <source_volume:@destination_volume> -policy AutomatedFailOverDuplex

    Example:
    The following example creates two consistency groups: cg_src on the source with vol1 and vol2, and a mirrored consistency group on the destination, cg_dst.

    destination::> snapmirror create -source-path vs1_src:/cg/cg_src -destination-path vs1_dst:/cg/cg_dst -cg-item-mappings vol_src1:@vol_dst1,vol_src2:@vol_dst2 -policy AutomatedFailOver

  2. Initialize the SnapMirror relationship:
    snapmirror initialize -destination-path <destination-consistency-group>

  3. Confirm the operation has succeeded by waiting for the Mirrored State to show as SnapMirrored and the Relationship Status as Insync.

    snapmirror show -destination-path <destination_path>

  4. On your host, configure host connectivity with access to each cluster according to your needs.

  5. Establish the igroup configurations on both the source and destination clusters.

    # primary site
    SiteA::> igroup create -vserver <svm_name> -igroup <igroup_name> -initiator <host_1_name_>

    # secondary site
    SiteB::> igroup create -vserver <svm_name> -igroup <igroup_name> -initiator <host_2_name>

  6. From the host, discover the paths and verify the hosts have an active/optimized path to the storage LUN from the preferred cluster.

  7. Deploy the application and distribute the VM workloads across clusters to achieve the required load balancing.

Configure symmetric active/active protection using an NVMe SnapMirror active sync configuration

Before you begin

In addition to the requirements for configuring symmetric active/active protection, you should be aware of the supported and unsupported configurations when using the NVMe protocol.

  • Consistency groups can have one or more subsystem.

  • Volumes within the consistency group can have namespace maps from multiple subsystems.

  • Subsystems cannot have namespace maps that belong to more than one consistency group.

  • Subsystems cannot have some namespace maps that belong to a consistency group and some namespace maps that do not belong to a consistency group.

  • Subsystems must have namespace maps that are part of the same consistency group.

Steps

Beginning with ONTAP 9.17.1, you can use System Manager or the ONTAP CLI to create a consistency group and configure symmetric active/active protection using NVMe protocol host mappings.

System Manager

  1. On the primary site, create a consistency group using new volumes or NVMe namespaces.

  2. select +Add and choose Using new NVMe namespaces.

  3. Enter the consistency group name.

  4. Select More.

  5. In the Protection section, select Enable SnapMirror then choose the AutomatedFailoverDuplex policy.

  6. In the Host mapping section, choose either Existing NVMe subsystem or New NVMe subsystem.

  7. Select In proximity to to change the proximal SVM. The source SVM is selected by default.

  8. If necessary, add another NVMe subsystem.

CLI

  1. Create a new SnapMirror relationship grouping all the volumes containing all NVMe namespaces used by the application. Ensure you designate the AutomatedFailOverDuplex policy to establish bidirectional sync replication.

    snapmirror create -source-path <source_path> -destination-path <destination_path> -cg-item-mappings <source_volume:@destination_volume> -policy AutomatedFailOverDuplex

    Example:

    DST::> snapmirror create -source-path vs_src:/cg/cg_src_1 -destination-path vs_dst:/cg/cg_dst_1 -cg-item-mappings vs_src_vol1:@vs_dst_vol1,vs_src_vol2:@vs_dst_vol2 -policy AutomatedFailOverDuplex

  2. Initialize the SnapMirror relationship:
    snapmirror initialize -destination-path <destination-consistency-group>

    Example:

    DST::> snapmirror initialize -destination-path vs1:/cg/cg_dst_1

  3. Confirm the operation has succeeded by waiting for the Mirrored State to show as SnapMirrored and the Relationship Status as Insync.

    snapmirror show -destination-path <destination_path>

    The NVMe subsystems associated with the NVMe namespaces in the primary volumes are automatically replicated to the secondary cluster.

  4. On your host, configure host connectivity with access to each cluster according to your needs.

  5. Specify the SVM that is proximal to each of your hosts. This enables host access to the NVMe namespace using a path from the preferred cluster. This might be the SVM in the primary cluster or the SVM in DR cluster.

    The following command indicates that SVM VS_A is proximal to host H1 and set VS_A as the proximal SVM:

    SiteA::> vserver nvme subsystem host add -subsystem ss1 -host-nqn <H1_NQN> -proximal-vservers <VS_A>

    The following command indicates that SVM VS_B is proximal to host H2 and sets VS_B as the proximal SVM:

    SiteB::> vserver nvme subsystem host add -subsystem ss1 -host-nqn <H2_NQN> -proximal-vservers <VS_B>

  6. From the host, discover the paths and verify the hosts have an active/optimized path to the storage from the preferred cluster.

  7. Deploy the application and distribute the VM workloads across clusters to achieve the required load balancing.

Related information