For years, NetApp has led the storage industry with its renowned MetroCluster capabilities, providing 0 RPO/ 0 RTO architectures for disparate locations. With SnapMirror Async, customers can quickly move data between clusters for technology updates.
With ONTAP 9.10.1 release, NetApp introduced SVM data mobility (SVM Migrate); the ability to non-disruptively move workloads across clusters, providing unprecedented uptime and flexibility for load balancing and tech refreshes. During the migration process, SVM Migrate replicates not only the SVM’s volume data, but also the SVM’s configuration information – think data LIFs, access control lists, SnapMirror relationships, NAS server identity, etc. – and once everything is duplicated at the new cluster, performs a non-disruptive switchover activating the new SVM and allowing clients to automatically reconnect to their NAS servers hosted in the SVM.
When we first released SVM Migrate, it only supported SVMs hosting NFS v3 FlexVol volumes and was limited to only all-flash array models such as the NetApp ONTAP A-series arrays. With each new ONTAP release, we added support for new platforms (FAS and C-Series array families), and expanded the supported ONTAP features that the migrating SVMs could use, such as SnapMirror asynchronous and SnapMirror cloud relationships, as well as additional NAS protocols such as NFS v4, and SMB/CIFS. With ONTAP 9.16.1, we continue to build on our solid foundation.
So, without further ado, I would like to announce that starting with ONTAP 9.16.1, MetroCluster support has finally come to SVM Migrate!
With this release, we support three primary SVM migration workflows involving MetroCluster:
- Moving an SVM from a stand-alone cluster TO MetroCluster (upper right of Figure 1)
- Moving an SVM FROM MetroCluster to a stand-alone Cluster (lower right of Figure 1)
- Moving an SVM from one MetroCluster FC or MetroCluster IP to another MetroCluster IP (upper left of Figure 1)
We are not supporting INTRA-MetroCluster migrations such as migrating an SVM hosted on an unprotected aggregate on one of the MetroCluster endpoint cluster to a protected aggregate on the other endpoint cluster within the MetroCluster relationship (lower left of Figure 1)
Figure 1: Supported MetroCluster configurations
In any of the three supported use cases described above, the process for initiating a migration is the same as that used to migrate an SVM between two non-MetroCluster clusters. To start a migration, initiate the following CLI command or REST API JSON payload sent to /api/svm/migrations service point of the destination cluster:
|
CLI |
|
dest::> vserver migrate start -source-cluster <source> -vserver <svmname>
|
|
REST API |
|
{ "source": { "cluster": { "name": “source" }, "svm": { "name": “svmname" } } } |
Before we get into the specific use cases listed above, there are a few common behavioral points I want to make:
- All the existing limitations documented for SVM Migrate are still valid. For example, this means that the migrating SVM cannot be configured to use SnapMirror synchronous replication, nor can it be configured to use SnapMirror SVM-DR. For a complete list of limitations you can visit SVM data mobility overview.
- If the migrating SVM does have data protection enabled on the SVM, those protections will continue until the final cutover to the new destination. So, if the migrating SVM is on a stand-alone cluster, then any active volume-scoped SnapMirror asynchronous operations will continue, and if the migrating SVM is hosted on a MetroCluster, then the MetroCluster protections will continue.
- Once the migration has started, we do not allow planned switchover (MCC) or failover (stand-alone HA) of the source or destination SVMs, but SVM Migrate is very tolerant of unplanned switchover/failover events.
- The migrating SVM cannot have any other peer relationships with any SVMs already on the target MetroCluster.
- For this initial release, both source and destination cluster must be running 9.16.1. In the future, both clusters must be running ONTAP 9.16.1 or later, and the source cluster must be running an ONTAP version no more than two major ONTAP versions older than the destination cluster.
Now, let’s look at each of the three supported use cases in a bit more detail.
Migrating SVM from stand-alone cluster to a MetroCluster
In this case, the destination MetroCluster must be in a normal operational state, i.e. not in a waiting-for-switchback state.
When the destination is a MetroCluster, SVM Migrate must create two SVMs in the destination MetroCluster…an SVM on the source cluster and an SVM on the destination cluster. Once both SVMs are created, we enable MetroCluster protection of the SVM to allow changes to be automatically replicated and to support continued migration in the case of a MetroCluster sync-source cluster unplanned failure (Figure 2).
Figure 2: Automatic continuation of migration when MetroCluster hosted target SVM fails
If there is an unplanned switchover of the target SVM on the destination MetroCluster endpoint, SVM Migrate will automatically switch the migration from the original MetroCluster target SVM (now in a switchover state) to the DR SVM at the other MetroCluster endpoint and will continue the migration. The migration process must be completed in this state, or cancelled, before manually switching the MetroCluster back to normal operational state where the SVM is active on the sync-source cluster.
Finally, a MetroCluster can have mirrored and unmirrored aggregates. In the case where the migrating SVM originates from a stand-alone cluster, we assume you want the SVM protected and the SVM migration process will always migrate to a mirrored aggregate by default.
Migrating SVM from a MetroCluster to a stand-alone cluster
In this case, the MetroCluster must be in a normal operational state with the SVM must be a sync-source SVM on a mirrored aggregate.
If, during the migration process, the source MetroCluster sync-source cluster fails, SVM Migrate will automatically stop the migration process from the sync-source SVM and redirect the migration process from the sync-destination SVM as the source SVM for the migration. Once the MetroCluster sync-source SVM is back online, SVM Migrate will continue to use the SVM on the MetroCluster sync-destination SVM until the migration process is completed (Figure 3).
Figure 3: Automatic continuation of migration when MetroCluster hosted source SVM fails
Migrating SVM from a MetroCluster to another MetroCluster
In this case, SVM Migrate basically behaves on the source MetroCluster as described in the MetroCluster-to-Stand-alone use case, and it behaves on the destination MetroCluster as described in the earlier Stand-alone-to-MetroCluster use case.
This implies that once the migration process has started, SVM migrate can survive the failure of either the source or destination SVM cluster or the failure of both the source and destination SVM clusters (though the latter is very unlikely to happen) by automatically switching the migration to or from the failed cluster SVM as appropriate without user intervention(Figure 4).
Figure 4: Automatic continuation of migration when either MetroCluster hosted SVM fails
Final words
SVM migrate can be a powerful addition in your data management toolbox. Providing non-disruptive movement of NAS workloads means that you can start thinking about data management in terms of more efficient resource utilization, proactive disaster avoidance, and faster, more efficient technology upgrades. With the addition of support for MetroCluster – a popular data management solution for mission critical workloads – those who are using MetroCluster now also have a fast, efficient way to migrate their workloads as part of their technology upgrade program. In addition, MetroCluster adds a critical HA aspect to the migration process by allowing the migration process to continue even if the MetroCluster has an unplanned switchover event.
To learn more about NetApp ONTAP MetroCluster, I encourage you to read the NetApp MetroCluster technical report or visit the online documentation.
To learn more about NetApp SVM data mobility, visit the online documentation.