NetApp® ONTAP SnapMirror® is a mission-critical solution that customers have come to depend on for broad data protection and disaster recovery. SnapMirror provides a very versatile suite of data protection capabilities that support both backup and recovery use cases as well as synchronous (RPO=0) real-time data protection.
Recently, we announced the availability of the release candidate for NetApp ONTAP 9.12.1. As the General Availability release is now upon us, I want to highlight some of the great new capabilities that come with this release for SnapMirror and SVM data mobility.
Before we look at the new SnapMirror features, I want to let everyone know that our long-term plan to deprecate the legacy Block Replication Engine (BRE) – the method of replicating data for -type DP relationships – has been completed and upgrades to ONTAP 9.12.1 will be blocked if any BRE relationships exist on the cluster. See Convert an existing DP-type relationship to XDP (netapp.com) to understand how to convert DP relationships to the newer XDP relationship type.
SnapMirror Asynchronous data protection
Improved fan-out scalability for some array models
SnapMirror now supports a fan-out of a source volume to up to 16 destination volumes for some array models such as the all-flash A700, A800, and A900. Visit NetApp Hardware Universe to determine if your node models support this feature.
Tamper-proof Snapshot copy support
A great new feature for ONTAP 9.12.1 is tamper-proof Snapshot™ copies, and with that, the ability to replicate the copies using SnapMirror. SnapMirror will replicate tamper-proof Snapshot copies using the same replication policy engine as non-tamper-proof Snapshot copies. You can change existing Snapshot policies – with existing SnapMirror labels – to tamper-proof or create new Snapshot policies using the tamper-proof designation…your choice…and SnapMirror will replicate them based on the replication rules in your SnapMirror protection policies. This applies to individual volume relationships as well as volumes that are part of an SVM DR relationship.
Improved RPO after FlexGroup volume rebalancing
Prior to ONTAP 9.12.1, FlexGroup rebalancing operations could impact SnapMirror replication. The impact of this was directly related to the configured SnapMirror schedule. Why? If a scheduled SnapMirror replication operation attempted to start while a FlexGroup rebalance was in progress, then that replication failed and SnapMirror waited until the next scheduled replication operation to “catch up.” If your protection policy has a daily schedule, then this means that SnapMirror may not replicate changes for up to two days since the last replication operation:
With ONTAP 9.12.1 and later, SnapMirror will immediately start a replication operation once the FlexGroup volume rebalance completes (green box). This eliminates the delay of the next scheduled replication before getting your data protected:
SVM DR + FlexGroup volumes + FabricPool volumes
SVM disaster recovery (SVM DR) can now replicate SVMs hosting FlexGroup volumes and FabricPool volumes in the same SVM. In earlier ONTAP versions, SVM DR supports only one of these volume types per SVM. In addition, the FabricPool volumes on the source and destination can have different FabricPool policies.
Data warehouse rebuild progress indicator
During a resync operation, a data warehouse rebuild is required. ONTAP 9.12.1 adds a data warehouse rebuild indicator to provide visibility into the time required to recover from a DR rehearsal or a recovery due to a DR failover event. This indicator can be accessed using ONTAP CLI and REST APIs.
SnapMirror Synchronous data protection
Support for non-disruptive operations (NDO) without impacting replication
Starting with ONTAP 9.12.1, SnapMirror Synchronous no longer experience I/O disruption for both Sync and StrictSync policies when planned and unplanned ONTAP NDO events occur. This feature requires AFF and ASA all-flash array models.
Improved replication interoperability
Starting with ONTAP 9.12.1, SnapMirror Synchronous source volumes can now replicate to a target cluster running any ONTAP version still within the 3-year full support period. See the latest relationship interoperability matrix for details.
Quality of service support
Starting with ONTAP 9.12.1, SnapMirror Synchronous supports setting a QoS ceiling value as well as supports adaptive QoS peak-operations settings.
|
QoS type |
ONTAP 9.11.1 and earlier |
ONTAP 9.12.1 |
|
Floor |
No |
No |
|
Ceiling |
No |
Yes. QoS policy having max-throughput settings are supported on source and destination clusters. |
|
Adaptive QoS |
No |
Yes. Adaptive QoS settings honors peak-operations only. |
NOTE: Both the primary and secondary clusters must run ONTAP 9.12.1 to support QoS.
NFS 4.2 extended attributes and sparse file support
SnapMirror Synchronous now supports replication of NFS 4.2 volumes that use extended attributes and files defined with pre-allocated space (also called sparse files). SnapMirror Synchronous will retain both extended attributes and sparse file definitions during replication to the destination DR volume.
SVM data mobility
Introduced in ONTAP 9.10.1, SVM data mobility – aka SVM migrate – enables non-disruptive movement of running SVMs from one cluster to another. It is a great tool for a variety of use cases such as resource management operations such as capacity or performance load balancing, or for technology upgrades. New features for SVM migrate in ONTAP 9.12.1 include:
Assigning data LIFs to specific ports on destination cluster.
As part of the SVM migration, administrators can assign LIFs to specific ports on the destination cluster node. Prior to ONTAP 9.12.1, SVM migrate assigned LIFs automatically and required a post-migration LIF rehome step to move them to different ports. This capability is supported using REST APIs only.
Assign volumes to aggregates on the destination cluster.
As part of the migration process, you can map volumes to specific aggregates on the destination cluster. This capability is supported using REST APIs only.
Support for SMB
SVM migrate can now migrate SVMs hosting SMB 2.1, 3.0, and 3.1 server shares. Due to the nature of SMB being disruptive, clients will still need to refresh their connection to mapped shares once the migration is complete.
Support FAS and hybrid arrays
SVM migration can now migrate SVMs between clusters using different disk technologies such as FAS and hybrid arrays. SVM migrate can migrate SVMs hosting up to 100 volumes for AFF arrays and up to 80 volumes for FAS and hybrid arrays.
While there are a multitude of smaller improvements and bug-fixes, these are the major features added to the various implementations of SnapMirror. SnapMirror offers a lot of flexibility, and we are working to make it even more valuable to you. We hope you will find these new features useful.
To learn more about SnapMirror, visit netapp.com
Let us know your thoughts in the comments or through your NetApp sales or partner representative.
