SnapMirror Active Sync & SM-BC Guide

Architecture Overview

SnapMirror Active Sync (SM-AS, introduced in ONTAP 9.14.1 and expanding upon SnapMirror Business Continuity / SM-BC) provides granular, volume-level and Consistency Group-level synchronous replication with automated, zero-touch storage failover. An independent third-site witness—the ONTAP Mediator—maintains continuous quorum and orchestrates sub-second failover without risk of split-brain.

1. Evolution & Feature Comparison

NetApp data protection architectures span asynchronous disaster recovery to fully synchronous active/active clusters. Understanding the exact boundaries between SM-S, SM-BC, SM-AS, and MetroCluster is critical for system design:

2. Quorum Mechanics & ONTAP Mediator

To eliminate split-brain scenarios (where both clusters mistakenly assume primary ownership and write conflicting data), SM-AS requires the ONTAP Mediator deployed at a separate third location or cloud failure domain (e.g., AWS EC2, Azure VM, or a third datacenter).

Quorum and Automated Failover (AFO) Decision Matrix

The clusters maintain constant bidirectional heartbeats with each other over the intercluster LIFs and with the ONTAP Mediator over secure HTTPS REST (port 443):

3. Host Multipathing Topologies

SM-AS supports two primary host connectivity models for SAN environments:

A. Uniform Host Access (Recommended for Metro Distances)

Host HBAs/NICs are cross-cabled and zoned to storage target ports on both Cluster A and Cluster B simultaneously:

• Path Priority (ALUA): Paths to the Primary Cluster report as Active/Optimized. Paths to the Secondary Cluster report as Active/Non-Optimized (or Standby).
• Instant Failover: If Cluster A fails, the host multipathing driver (ESXi NMP/PSP, Linux DM-Multipath, or Windows MPIO) simply shifts I/O to the already-connected Secondary paths without needing to re-scan LUNs or re-login to target ports.

B. Non-Uniform Host Access

Hosts in Site A only cable to Cluster A; hosts in Site B only cable to Cluster B. Cross-site replication handles data mirroring. Used primarily in stretched hypervisor clusters where local compute always accesses local storage.

4. Prerequisites & Network Requirements

• Network Latency: Maximum Round Trip Time (RTT) ≤ 10ms between storage clusters (recommended < 5ms for write-heavy databases). RTT to ONTAP Mediator can be up to 100ms.
• Network MTU: 9000 bytes (Jumbo Frames) strongly recommended across intercluster LIFs to minimize packet fragmentation overhead during synchronous writes.
• Licensing: ONTAP One license or "Data Protection" bundle on both clusters.
• ONTAP Mediator Host: Linux virtual machine (RHEL 8/9, Rocky Linux, or AlmaLinux) running SCST kernel modules and Python 3.9+ with an SSL certificate.

5. Step-by-Step Implementation Runbook

Step 1: Verify Intercluster Peering & Ping Latency

::> cluster peer show
::> cluster peer ping -destination-cluster cluster02
Node: node01-a   Destination Cluster: cluster02
Destination Node: node02-a  Latency: 1.42 ms  Status: reachable
Destination Node: node02-b  Latency: 1.51 ms  Status: reachable

::> vserver peer show

Step 2: Add and Validate the ONTAP Mediator

Run on both clusters to bind the Mediator witness:

::> snapmirror mediator add -mediator-address 192.168.100.50 -port 443 -user mediatoradmin

::> snapmirror mediator show
Mediator Address Peer Cluster     Connection Status Quorum Status
---------------- ---------------- ----------------- -------------
192.168.100.50   cluster02        connected         true

Step 3: Create the Consistency Group and Synchronous Relationship

Configure the SnapMirror relationship using the AutomatedFailover policy:

# Create destination volume on Cluster 2
cluster02::> volume create -vserver svm_db_dr -volume vol_prod_db -aggregate aggr1_ssd -size 2TB -type DP

# Provision SnapMirror relationship with AutomatedFailover policy
cluster02::> snapmirror create -source-path svm_db_prod:vol_prod_db -destination-path svm_db_dr:vol_prod_db -policy AutomatedFailover -cg-item-mappings vol_prod_db:vol_prod_db

# Initialize relationship
cluster02::> snapmirror initialize -destination-path svm_db_dr:vol_prod_db

# Verify relationship reaches "InSync" status
cluster02::> snapmirror show -destination-path svm_db_dr:vol_prod_db -fields state,status,sync-type
source-path           destination-path      state        status   sync-type
--------------------- --------------------- ------------ -------- ---------
svm_db_prod:vol_prod_db svm_db_dr:vol_prod_db Snapmirrored Idle     sync

Step 4: Provision Identical igroups & Map LUNs on Both Clusters

For uniform host access, the initiator group and LUN geometry (LUN serial number and WWN) must match so the host operating system recognizes them as identical paths to the same block storage device:

# Cluster 01: Create igroup and map LUN
cluster01::> igroup create -vserver svm_db_prod -igroup esx_cluster_ig -protocol fcp -ostype vmware -initiator 21:00:00:24:ff:56:10:01,21:00:00:24:ff:56:10:02
cluster01::> lun map -vserver svm_db_prod -path /vol/vol_prod_db/lun_oracle_data -igroup esx_cluster_ig -lun-id 1

# Cluster 02: Create identical igroup and map secondary LUN
cluster02::> igroup create -vserver svm_db_dr -igroup esx_cluster_ig -protocol fcp -ostype vmware -initiator 21:00:00:24:ff:56:10:01,21:00:00:24:ff:56:10:02
cluster02::> lun map -vserver svm_db_dr -path /vol/vol_prod_db/lun_oracle_data -igroup esx_cluster_ig -lun-id 1 -additional-reporting-node-regex *

6. Operational Runbook: Planned Failover & Disaster Recovery

A. Planned Switchover (Maintenance / DR Drill)

Perform a non-disruptive, zero data loss planned switchover from the destination cluster:

# Initiate planned switchover on Cluster 02
cluster02::> snapmirror failover start -destination-path svm_db_dr:vol_prod_db

# Monitor switchover progress
cluster02::> snapmirror failover show -destination-path svm_db_dr:vol_prod_db
Source Path: svm_db_prod:vol_prod_db
Destination Path: svm_db_dr:vol_prod_db
Failover Status: completed
Error Reason: -

During a planned failover, ONTAP ensures all in-flight synchronous writes are committed on the source, reverses the replication direction, and transitions Cluster 02's paths to Active/Optimized while Cluster 01 becomes standby.

B. Forcing Unplanned Failover When Quorum is Lost

If the primary cluster is destroyed and the ONTAP Mediator is unreachable (catastrophic double-failure), an administrator can force promotion on the secondary cluster:

# Force failover (breaks relationship and promotes secondary to read/write)
cluster02::> snapmirror failover start -destination-path svm_db_dr:vol_prod_db -force true

C. Post-Incident Resynchronization

Once the failed site is restored, resynchronize data back to restore zero RPO protection:

# Re-establish synchronous replication in the reverse direction
cluster01::> snapmirror resync -destination-path svm_db_prod:vol_prod_db

7. Troubleshooting & Diagnostics Matrix

Essential Diagnostic Commands

# Comprehensive SnapMirror synchronous state check
::> snapmirror show -destination-path svm_db_dr:vol_prod_db -instance

# Check Mediator connectivity and event status
::> snapmirror mediator show -instance
::> event log show -message-name csm.*|snapmirror.* -time >5m

# Check Consistency Group operational status
::> consistency-group show -vserver svm_db_dr -instance