Active-Active VM Storage at Datastore Granularity: SnapMirror Active Sync meets ONTAP tools Granular Datastore Protection
The two things to remember
- Active-active with synchronous SnapMirror (SnapMirror active sync / SM-as) — ONTAP TOOLSONTAP tools Granular Datastore Protection (GDP) lets you hand-pick VMFS-FC or VMFS-iSCSI datastores inside an ESXi host cluster and protect them with zero recovery time objective (RTO)/zero recovery point objective (RPO)replication backed by ONTAP SnapMirror Active Sync. VMs can read and write from either site.
- Load balancing across sites: Workloads can actively use I/O from either location.
- With uniform host proximity, peered datastores at both sites are mapped to ESXi hosts at both sites. If one ONTAP cluster becomes unreachable, VMs continue serving I/O from the surviving site with typical failover latency on the order of ~11 ms (the actual I/O resumption time [IORT] will be environment-dependent).
- With non-uniform host proximity, ESXi hosts are only mapped to the local copy of the datastore. I.e. If a VM migrates or fails over to a host on the other site, that host only accesses the local ONTAP cluster. If one ONTAP cluster becomes unreachable, the VM will use vSphere HA to failover to the other site since it can only access its local copy.
Everything else in this article explains how ONTAP tools 10.6 provisions and governs that experience.
Why GDP changes the protection conversation
Before ONTAP TOOLS 10.6, Host Cluster Protection (HCP) was all-or-nothing: protecting a cluster meant protecting every eligible VMFS datastore on that cluster together.
Granular Datastore Protection (GDP) shifts the unit of protection from the host cluster to individual VMFS datastores — while still operating within a single ESXi host cluster boundary.
Aspect | HCP (pre-10.6) | GDP (ONTAP TOOLS 10.6) |
|---|
Protection unit | Entire host cluster | Selected VMFS datastores |
Mixed protected / unprotected DSs | No | Yes — same cluster can mix |
Unprotect one datastore | Not supported | Supported (non-last DS) |
Multiple protection groups/cluster | One group for all DSs | Multiple groups allowed (one SVM per group) |
Write-order consistency | One consistency group (CG) per host cluster | Multiple CGs can be configured with different combinations of datastores |
Customer value: Protect only the datastores that matter, add/remove datastores over time, and run different SnapMirror targets per SVM, without forcing every datastore in the host cluster into the same protection group.
What ONTAP SM-as brings to GDP
SnapMirror Active Sync (SM-as) is ONTAP’s synchronous, active-active replication mode used by the Automated Failover Duplex (AFD) policy. Combined with GDP, it delivers:
- RPO = 0 — writes are synchronously committed to NVRAM on both sites before acknowledgment
- RTO = 0 — because both copies are always available, IO can resume as soon as the mediator initiates the failover and the host multipath driver can retry any required I/Os
- Active-active data path — both copies are read/write capable (policy and proximity permitting)
- Consistency group (CG) backed protection — multiple LUNs/datastores in one atomic replication unit
- Automatic host access orchestration — ONTAP TOOLS manages igroups, LUN maps, mounts, and HBA rescans
GDP is the ONTAP TOOLS control plane; SM-as is the ONTAP replication engine. ONTAP TOOLS creates and lifecycle-manages:
- Protection Settings — which datastores are protected, CG membership, SnapMirror relationship
- Cluster Configuration — fault domains, host-to-SVM mapping, uniform vs non-uniform proximity
- Initiator groups (igroups) — host IQNs/WWPNs mapped to protected LUNs at each site
ONTAP TOOLS 10.6 constructs that you configure
1. Protection Setting
A protection group ties together:
- One or more VMFS datastores (same host cluster, same SVM)
- An ONTAP consistency group
- A SnapMirror Active Sync relationship (for AFD)
- Initiator groups for host access
Typical workflows: Protect · Modify (add/remove datastore) · Unprotect · Delete
2. Cluster Configuration (required for AFD / SM-as)
Maps an ESXi host cluster to two fault domains (Site A / Site B):
- Each fault domain lists ESXi hosts + peered source/target SVMs
- The uniform_host_config attribute is set at create time and is immutable
The following table illustrates the two protection constructs.
Object | Purpose |
|---|
Cluster Configuration | Topology — fault domains, hosts, SVM peers, uniform vs non-uniform |
Protection Setting | Data — which datastores, CG, SnapMirror, igroups |
Prerequisite: Create Cluster Configuration before protecting datastores with AFD/SM-as. Async-only SnapMirror does not require cluster configuration.
Uniform vs Non-Uniform Host Proximity
This is the architectural fork that determines the system behavior during various modes of failure in different fault domains.
Uniform proximity (uniform_host_config = true)
Behavior: Peered datastores from both sites are mapped to ESXi hosts at both sites. All hosts in the cluster can access all protected datastores. ONTAP TOOLS manages igroup replication and host proximity settings across both SVMs.
Use cases:
- Active-active workload distribution — VMs on either site issue I/O to locally mapped LUNs based on proximity settings
- Metro / stretched cluster — compute at both sites, storage synchronously mirrored
How does GDP use SMas to protect you in different failure scenarios:
- Storage cluster failure — IO continues without vSphere HA by using remote copy
- Storage network failure on local target side of network — IO continues without requiring vSphere HA by using the remote copy
- Storage network failure on local initiator side of network — A vSphere HA event triggers automatic recovery on the remote site with VM reboot
- Compute failure — vSphere HA reboots VM on an applicable ESXi host based on resource availability. Affinity and anti-affinity rules may dictate which site the VM is rebooted on
- Full site outage — VM’s on the failed site are rebooted and recovered by vSphere HA on the surviving site, and I/O is resumed; typical switchover latency ~11 ms (lab/field reference; actual depends on distance, network, and load)
Metric | Uniform + SM-as |
|---|
RPO | 0 |
RTO | Near-zero for I/O continuity (automatic path to surviving copy) |
I/O pattern | Both sites active |
Non-uniform proximity (uniform_host_config = false)
Behavior: Peered datastores are mapped only to hosts locally within each site. Site A hosts access Site A SVM LUNs; Site B hosts access Site B SVM LUNs. Replication is still synchronous (SM-as), but with a reduced number of non-disruptive failure scenarios at the VM layer. For this reason, uniform configurations are considered the best practice when the environment can support it.
Use cases:
- Campus / dual-room: each room’s hosts only access their local copy
- Optimizing limited WAN bandwidth: eliminating host network traffic between failure domains
- Reduced SAN path management: hosts cannot see remote paths
- Sync DR with site affinity: zero data loss
How does GDP use SMas to protect you in different failure scenarios:
- Storage cluster failure — A vSphere HA event triggers automatic recovery on the remote site
- Storage network failure on target side of network — A vSphere HA event triggers automatic recovery on the remote site
- Storage network failure on initiator side of network — A vSphere HA event triggers automatic recovery on the remote site
- Compute failure — vSphere HA reboots VM on applicable ESXi host based on resource availability. Affinity and anti-affinity rules may dictate which site the VM is rebooted on
- Full site outage — VM’s on the failed site are recovered by vSphere HA on the surviving site, and I/O is resumed; typical switchover latency ~11 ms (lab/field reference; actual depends on distance, network, and load)
Metric | Non-uniform + SM-as |
|---|
RPO | 0 |
RTO | Non-zero — hosts at DR site must regain access (mount, igroup, rescan orchestration) |
I/O pattern | Site-local active; other site is sync replica |
Side-by-side comparison
Dimension | Uniform | Non-uniform |
|---|
Host access to peer DS | All cluster hosts → both sites | Site-local hosts → local SVM only |
Igroup model | Replicated igroups across SVMs | Per-site igroups |
Load balancing across sites | Yes — primary value prop | No — site-affine I/O |
Site failure behavior | Surviving hosts continue I/O (~11 ms class) | Failover orchestration needed; RTO > 0 |
Cluster config flag | uniform_host_config=true | uniform_host_config=false |
Immutable after create? | Yes | Yes |
End-to-end user flow: from datastore selection to protected active-active
GDP use cases (where customers win)
Use case | Why GDP + SM-as fits |
|---|
Protect critical DS only | Dev/test DSs stay unprotected; production DSs get SM-as |
Incremental adoption | Add newly created DSs to an existing protection group via Modify |
Multi-SVM on one cluster | Different SnapMirror targets per SVM — separate protection settings |
Uniform metro cluster | Active-active I/O + sync replication + ~11 ms class failover |
Non-uniform dual-room | Sync data protection with strict site-local compute affinity |
Decommission one DS | Non-last unprotect shrinks CG; others stay protected |
Version and platform guardrails (ONTAP TOOLS 10.6)
Supported
Requirement | Detail |
|---|
ONTAP TOOLS | 10.6 |
Datastore type | VMFS only |
Protocol | iSCSI or FC (FCP) |
ONTAP for SM-as | SVM ONTAP ≥ 9.16.1 |
ONTAP cluster size | ≤ 4 nodes |
SnapMirror policy | AFD (Automated Failover Duplex) for active sync Standard SnapMirror policies are also supported |
Disaggregated individual unprotect/delete | ONTAP ≥ 9.17.1 |
Not supported in 10.6
- NFS and NVMe datastore protection
- Sync / strict-sync policies outside AFD SM-as scope
- Local snapshot policies for GDP workflows
- Protecting datastores across different SVMs in one protection setting
- Moving a datastore between protection groups (unprotect + re-protect required)
- Custom async SnapMirror policies
- MetroCluster-backed configurations
- ONTAP clusters with > 4 nodes
- Mixing uniform and non-uniform protection on the same host cluster
- Protection failover initiated from ONTAP TOOLS UI (use ONTAP System Manager)
- ONTAP TOOLS discovering CGs / SnapMirror created outside ONTAP TOOLS (CLI/SM)
Operational guardrails customers should know
Guardrail | Impact |
|---|
Cluster config is immutable | Cannot switch uniform ↔ non-uniform without delete/recreate (blocked if AFD protection exists) |
One DS unprotect at a time | Parallel unprotect of multiple DSs not supported |
Last DS = full delete | Unprotecting the last datastore deletes the entire protection group |
Protected DS unmount | Only from hosts outside the protection host cluster |
Async SM on unified (O9) | Individual (non-last) unprotect blocked |
Sequential ops in cluster | Create/delete DS blocked while another protected DS op is in-flight |
Parallel protection ops | Second op on same group returns 409 while state=updating |
Host proximity and igroups — what ONTAP TOOLS automates
When you protect a datastore, ONTAP TOOLS 10.6:
- Creates or extends an ONTAP consistency group spanning the protected LUNs/volumes
- Establishes SnapMirror Active Sync to the peered SVM
- Creates nested igroups (parent per datastore, child per host) with host IQNs/WWPNs from participating sites
- For uniform AFD: replicates igroups across sites so all hosts retain access
- For non-uniform AFD: creates site-local igroups mapped to local fault-domain hosts
- Mounts peer datastores and rescans HBAs when topology changes (cluster config modify)
You do not manually patch igroups for GDP lifecycle operations — ONTAP TOOLS owns add/remove host, mount, unmount, and shrink flows.
Deeper dive, what happens when a complete site or failure domain goes down?
Uniform proximity + SM-as
- Both copies were actively serving I/O
- SM-as maintains synchronous consistency
- ESXi hosts at the surviving site continue I/O on the accessible LUN paths
- Expected: I/O continuity with failover latency typically in the ~11 ms range (not a guaranteed SLA — validate in your environment)
Non-uniform proximity + SM-as
- Source-site hosts were actively using local LUNs; target site held the sync replica
- RPO remains 0 — no committed write loss
- RTO is non-zero — DR-site hosts (or orchestrated failover) must establish access via igroup/mount/rescan workflows
- ONTAP TOOLS cluster configuration modify / protection discovery may be needed after topology events
Quick decision guide
Summary
ONTAP SnapMirror active sync provides the synchronous, active-active replication engine. ONTAP TOOLS 10.6 Granular Datastore Protection provides the VMware-native control plane to:
- Hand-pick which VMFS datastores to protect inside a host cluster
- Model uniform or non-uniform host proximity via Cluster Configuration
- Lifecycle-manage consistency groups, SnapMirror, igroups, mounts, and rescans
Key Takeaways
Active-active sync SnapMirror: GDP + SM-as delivers zero-RPO, dual-site VMFS protection at datastore granularity.
Load balancing: SnapMirror active sync enables both sites to actively serve I/O, maximizing resource utilization with best of breed business continuity on failure.
