SnapMirror Replication Policies for Cinder¶

Overview¶

Asynchronous replication transfers data from the source SVM to the destination SVM at scheduled intervals, resulting in a small recovery point lag (typically minutes). This is the simplest replication model to deploy and supports the widest range of protocols—iSCSI, FC, and NFS.

Two ONTAP pre-defined policies are supported:

• MirrorAllSnapshots

  SnapMirror asynchronous policy for mirroring all snapshots and the latest active file system.

• Asynchronous

  A unified SnapMirror asynchronous policy for mirroring the latest active file system and daily and weekly snapshots with an hourly transfer schedule.

Protection Topology: Per-Volume vs. Single Consistency Group¶

By default, the driver creates one independent SnapMirror relationship per FlexVol volume in the backend stanza. During failover, each FlexVol is failed over individually, which may result in slightly inconsistent point-in-time data across volumes if transfers are not all at the same snapshot.

Setting netapp_consistent_replication = True changes this to a single shared Consistency Group (CG) protecting all FlexVol volumes in the stanza. The CG ensures all volumes are failed over from the same crash-consistent snapshot, eliminating cross-volume inconsistency.

Failover and Failback¶

Planned failover (primary site is healthy, but administrator initiates failover for testing or maintenance):

cinder failover-host <hostname> \
 --backend_id <failover target>

After failover, the replication status of each OpenStack volume changes to failed-over and the destination backend becomes the active I/O-serving site.

Failback (returning I/O to the original primary site after it is restored):

Before issuing the failback command, manually resync the SnapMirror relationships from the secondary site back to the primary site on ONTAP so that data written during the failover period is transferred back. manually perform reverse replication of the snapmirror relationship. Refer to the ONTAP SnapMirror documentation for resync steps. Then run:

cinder failover-host <hostname> \
 --backend_id default

After failback, volumes return to replication_status: enabled, and the primary site resumes as the active backend.

Configuration Example¶

[source-async-backend]
volume_backend_name = source-async-backend
volume_driver = cinder.volume.drivers.netapp.common.NetAppDriver
netapp_server_hostname = source-cluster-mgmt-ip
netapp_login = admin
netapp_password = secret
netapp_storage_protocol = iscsi
netapp_storage_family = ontap_cluster
netapp_vserver = source-svm
netapp_use_legacy_client = False

# Replication settings
replication_device = backend_id:dest-async-backend
netapp_replication_policy = Asynchronous
netapp_consistent_replication = True

[dest-async-backend]
volume_backend_name = dest-async-backend
volume_driver = cinder.volume.drivers.netapp.common.NetAppDriver
netapp_server_hostname = dest-cluster-mgmt-ip
netapp_login = admin
netapp_password = secret
netapp_storage_protocol = iscsi
netapp_storage_family = ontap_cluster
netapp_vserver = dest-svm
netapp_use_legacy_client = False

Limitations¶

• Custom ONTAP SnapMirror policies are not supported. Only the ONTAP pre-canned policies MirrorAllSnapshots and Asynchronous are accepted.

• Changing netapp_replication_policy from an asynchronous value to AutomatedFailOver or AutomatedFailOverDuplex is not supported after a relationship exists. This is an ONTAP limitation.

• ASAr2 (disaggregated) ONTAP platforms are not supported.

Overview¶

The AutomatedFailOver policy implements ONTAP SnapMirror Active Sync in asymmetric mode. It provides synchronous replication—data is committed to both the source and destination clusters simultaneously—resulting in a recovery point objective (RPO) of zero: no data is lost at failover.

Supported protocols: iSCSI and FC only. Minimum ONTAP version: Unified ONTAP 9.15.1. API requirement: REST only (netapp_use_legacy_client = False).

Single Consistency Group per Backend Stanza¶

Prior to the Hibiscus release, each FlexVol volume in the backend stanza was placed in its own individual Consistency Group and protected independently. This meant that failover broke each SnapMirror relationship separately, which could introduce data inconsistencies across volumes if transfers were not perfectly aligned.

With Hibiscus, setting netapp_consistent_replication = True causes the driver to place all FlexVol volumes in the stanza into a single shared CG, which is then protected with the AutomatedFailOver policy. The result is that all volumes fail over atomically from the same crash-consistent point.

This flag defaults to False to avoid disrupting existing deployments that relied on the per-volume behavior.

Failover and Failback¶

Planned failover:

Fails over the volumes from primary to secondary site

cinder failover-host <hostname> \
 --backend_id <failover target>

Failback:

Fails back the volumes from secondary to primary site

cinder failover-host <hostname> \
 --backend_id default

Configuration Example¶

[source-af-backend]
volume_backend_name = source-af-backend
volume_driver = cinder.volume.drivers.netapp.common.NetAppDriver
netapp_server_hostname = source-cluster-mgmt-ip
netapp_login = admin
netapp_password = secret
netapp_storage_protocol = iscsi
netapp_storage_family = ontap_cluster
netapp_vserver = source-svm
netapp_use_legacy_client = False

# Replication settings
replication_device = backend_id:dest-af-backend
netapp_replication_policy = AutomatedFailOver
netapp_consistent_replication = True

[dest-af-backend]
volume_backend_name = dest-af-backend
volume_driver = cinder.volume.drivers.netapp.common.NetAppDriver
netapp_server_hostname = dest-cluster-mgmt-ip
netapp_login = admin
netapp_password = secret
netapp_storage_protocol = iscsi
netapp_storage_family = ontap_cluster
netapp_vserver = dest-svm
netapp_use_legacy_client = False

Limitations¶

• NFS and NVMe protocols are not supported.

• ZAPI is not supported (ONTAP limitation for SnapMirror Active Sync).

• ASAr2 platforms are not supported.

• Changing the policy from AutomatedFailOver to AutomatedFailOverDuplex on an existing relationship is not supported. Remove and recreate the replication configuration.

• Changing from AutomatedFailOver to an asynchronous or synchronous policy is not supported (ONTAP limitation).

—

Overview¶

The AutomatedFailOverDuplex (AFD) policy implements ONTAP SnapMirror Active Sync in symmetric mode. Both sites serve read and write I/O simultaneously, and ONTAP automatically redirects I/O to the surviving site when a failure is detected. No manual operator intervention is required. This delivers zero RPO and near-zero RTO, making it the strongest protection tier available.

The AFD topology is designed for stretched cluster deployments where OpenStack compute nodes span two physical sites or availability zones. Each compute host has network connectivity to storage at both sites, and the storage system uses host proximity metadata to determine the optimal storage path for each host.

Supported protocols: iSCSI and FC only. Minimum ONTAP version: Unified ONTAP 9.15.1. API requirement: REST only (netapp_use_legacy_client = False). netapp_consistent_replication: mandatory (must be True).

Host Proximity Configuration¶

In a symmetric stretched topology, ONTAP needs to know which site each compute host is physically closest to (proximal to) so that it can prefer the local data path for I/O. The driver configures this proximity metadata on the ONTAP igroup objects automatically during volume attach operations.

The netapp_proximal_nodes option provides the list of iSCSI IQNs or FC WWPNs of compute host initiators that are local to the SVM in the backend stanza. This option is set independently in both the source and destination backend stanzas, reflecting the initiators local to each respective site.

The driver derives host proximity as follows:

• Initiators listed only in the source netapp_proximal_nodes are proximal to the source SVM only (local-only to site A).

• Initiators listed only in the destination netapp_proximal_nodes are proximal to the destination SVM only (local-only to site B).

• Initiators listed in both stanzas are considered shared — they have connectivity to both sites. The driver configures proximity to both SVMs for these initiators.

Failover and Failback¶

Because both sites serve I/O simultaneously, ONTAP handles site failure automatically without requiring operator action. The surviving site continues serving I/O transparently. The OpenStack volume replication_status changes to failed-over once the Cinder periodic health check runs.

For planned failover (e.g., scheduled maintenance on one site):

cinder failover-host <hostname> \
 --backend_id <failover target>

For failback after the original primary site is restored:

After verifying that the primary site ONTAP cluster is healthy and the SnapMirror relationship is re-synchronized, run:

cinder failover-host <hostname> \
 --backend_id default

Configuration Example¶

The following example shows a stretched iSCSI deployment across two sites. The netapp_proximal_nodes in each stanza lists the IQNs of compute hosts that are local to that site’s SVM.

[source-afd-backend]
volume_backend_name = source-afd-backend
volume_driver = cinder.volume.drivers.netapp.common.NetAppDriver
netapp_server_hostname = source-cluster-mgmt-ip
netapp_login = admin
netapp_password = secret
netapp_storage_protocol = iscsi
netapp_storage_family = ontap_cluster
netapp_vserver = source-svm
netapp_use_legacy_client = False

# Replication settings — AFD requires consistent_replication = True
replication_device = backend_id:dest-afd-backend
netapp_replication_policy = AutomatedFailOverDuplex
netapp_consistent_replication = True

# IQNs of compute hosts physically local to the source SVM's site
netapp_proximal_nodes = iqn.1994-05.com.redhat:compute-host-a1,iqn.1994-05.com.redhat:compute-host-a2

[dest-afd-backend]
volume_backend_name = dest-afd-backend
volume_driver = cinder.volume.drivers.netapp.common.NetAppDriver
netapp_server_hostname = dest-cluster-mgmt-ip
netapp_login = admin
netapp_password = secret
netapp_storage_protocol = iscsi
netapp_storage_family = ontap_cluster
netapp_vserver = dest-svm
netapp_use_legacy_client = False

# IQNs of compute hosts physically local to the destination SVM's site
netapp_proximal_nodes = iqn.1994-05.com.redhat:compute-host-b1,iqn.1994-05.com.redhat:compute-host-b2

Limitations¶

• NFS is not supported (ONTAP limitation for AFD).

• NVMe is not supported in this release (planned for a future release).

• ZAPI is not supported (ONTAP limitation for SnapMirror Active Sync).

• ASAr2 platforms are not supported.

• Changing from AutomatedFailOver to AutomatedFailOverDuplex on an existing relationship is not supported. Remove and recreate.

• Changing from AutomatedFailOverDuplex to an asynchronous or synchronous policy is not supported.

—