Skip to main content

Migrate a storage VM from an ASA r2 cluster to an ASA or AFF cluster

Contributors netapp-aherbin
PDFs

Beginning with ONTAP 9.20.1, you can non-disruptively migrate a storage virtual machine (VM) from a 2-node ASA r2 cluster to a 2-node ASA or a 2-node AFF cluster. You might need to migrate a storage VM to consolidate SAN and NAS workloads, adopt ONTAP features not available for ASA r2 systems, or refresh your hardware. Existing host mappings and storage unit configurations for LUNs and namespaces are maintained during migration, reducing operational effort and risk.

Before you begin

  • You must be a cluster administrator.

  • All nodes in both clusters must be running ONTAP 9.20.1 or later.

About this task

  • You can migrate an ASA r2 storage VM from a 2-node ASA r2 cluster to a 2-node AFF cluster only.

    • You cannot migrate an ASA r2 storage VM to a FAS cluster, or to an ASA or AFF cluster with more than two nodes.

    • You cannot migrate an ASA r2 storage VM from an ASA r2 cluster with more than two nodes.

  • Data migration from an ASA r2 cluster to an AFF cluster is not reversible.

    You can abort a migration before cutover, but after cutover is initiated, you cannot interrupt or revert the migration. After the migration is complete, you cannot migrate data from an AFF cluster to an ASA r2 cluster.

    You can migrate a storage VM from an ASA to an ASA r2 cluster.

  • You can migrate only one storage VM at a time.

  • The storage VM can contain a maximum of 400 storage units.

  • The storage VM cannot contain SnapMirror destination storage units.

Step 1: Create a cluster peer relationship

Before you can migrate a storage VM from an ASA r2 cluster, you need to create a peer relationship. A peer relationship defines network connections that enable ONTAP clusters and storage VMs to exchange data securely.

About this task

In the following procedure, the ASA or AFF cluster is the destination cluster and the ASA r2 cluster is the source cluster.

Before you begin

You must have created intercluster LIFs on every node in the clusters being peered using one of the following methods.

Steps

  1. On the destination cluster, create a peer relationship with the source cluster and generate a passphrase:

    cluster peer create -peer-addrs <source_cluster_LIF_IPs> -generate-passphrase

    The following example creates a cluster peer relationship between cluster 1 and cluster 2 and creates a system-generated passphrase:

    cluster1::> cluster peer create -peer-addrs 10.98.191.193 -generate-passphrase
Passphrase: UCa+6lRVICXeL/gq1WrK7ShR
            Peer Cluster Name: cluster2
            Initial Allowed Vserver Peers: -
            Expiration Time: 6/7/2017 09:16:10 +5:30
            Intercluster LIF IP: 10.140.106.185
Warning: make a note of the passphrase - it cannot be displayed again.

  2. Copy the generated passphrase.

  3. On the source cluster, create a peer relationship with the destination cluster:

    cluster peer create -peer-addrs <destination_cluster_LIF_IPs>

  4. Enter the passphrase generated on the destination cluster.

  5. Verify that the cluster peer relationship is created:

    cluster peer show

    The following example displays the expected output for successfully peered clusters.

    cluster1::> cluster peer show

Peer Cluster Name   Cluster Serial Number   Availability   Authentication
-----------------   ---------------------   -------------- --------------
cluster2             1-80-123456             Available      ok
Result

The clusters are peered. Storage VM data can be securely transferred.

What’s next?

You are ready to prepare your ASA r2 storage VM for migration.

Step 2: Prepare the ASA r2 storage VM for migration

Before you migrate a storage virtual machine (VM) from an ASA r2 cluster, you need to remove replication and SnapMirror active sync relationships and perform various checks.

Steps

  1. Remove any existing replication relationships.

  2. Remove any existing SnapMirror active sync relationships.

  3. Check if IPsec is enabled:

    security ipsec config show

    1. If IPsec is enabled, disable it:

      security ipsec config modify -is-enabled -false

      Learn more about the security ipsec config show command.

    2. Check for IPv6 and virtual IP (VIP) LIFs:

      network interface show -vserver <storage_vm_name> -fields address-family, is-vip

      For IPv6 LIFs, the -address-family is ipv6. For VIP LIFs the -is-vip parameter is true.

    3. If any IPv6 or VIP LIFs exist, remove them:

      network interface delete -vserver <storage_vm_name> - lif <lif_name>

    4. Verify that there are no IPv6 or VIP LIFs remaining on the storage VM:

      network interface show -vserver <storage_VM_name>

      Learn more about the network interface show and network interface delete commands.

  4. Check if any interface groups are configured:

    network port ifgrp show

    1. If interface groups are configured, check if any LIFs on the storage VM are bound to an interface group:

      network interface show -vserver <storage_VM_name> -fields home,node, home-port, curr-node, curr-port

    2. If a LIF on the storage VM is bound to an interface group, migrate the LIF to a different physical port:

      network interface migrate -vserver <storage_VM_name> -lif <LIF> -des-node <destination_node> -dest-port <destination_port>

      Learn more about the network port ifgrp show command.

What’s next?

You are now ready to execute the migration pre-check.

Step 3: Execute the migration pre-check

Before you migrate a storage VM from an ASA r2 cluster, you must run a migration pre-check and fix any required issues. You cannot perform the migration until the pre-check passes successfully.

Step

  1. From your destination cluster, execute the migration pre-check:

    vserver migrate start -vserver <storage_VM> -source-cluster <sourcecluster> -check-only true

    If you need to fix any issues to prepare for migration, the issue and the corrective action are displayed. Fix the issue and repeat the pre-check until it completes successfully.

What’s next?

You are ready to migrate your storage VM from your ASA r2 cluster.

Step 4: Migrate a storage VM from an ASA r2 cluster

After you have created the necessary cluster peer relationship between the ASA r2 and ASA or AFF clusters and completed the steps to prepare both clusters, you can begin the storage VM migration.

As a best practice, leave 30% CPU headroom on both the ASA r2 cluster and the AFF cluster so the migration workload can run.

About this task

  • After the storage VM migration, client I/O seamlessly transitions to the destination cluster with no disruption and the storage VM on the ASA r2 cluster is automatically removed. Automatic cutover and automatic storage VM removal are enabled by default. You can optionally disable one or both options and perform them manually.

  • The ASA cluster is the source cluster from which the storage VM will be migrated, and the ASA r2 cluster is the destination cluster to which the storage VM will be migrated.

Steps

  1. From the destination cluster, start the storage VM migration:

    vserver migrate start -vserver <storage_VM_name> -source-cluster <source_cluster>

    To disable automatic cutover, use the -auto-cutover false parameter. To disable the automatic removal of the source storage VM, use the -auto-source-cleanup false parameter.

  2. Monitor the status of the migration

    vserver migrate show -vserver <storage_VM_name>

    If you need to pause or cancel the migration before automatic cutover begins, use the vserver migrate pause and the vserver migrate abort commands. You must pause the migration before cancelling it. You cannot cancel the migration after cutover starts.

    If automatic cutover is enabled, when the migration is complete, the status displays as migration-complete. If automatic cutover is disabled, the status displays as Ready for source cleanup.

Result

The storage VM is migrated from the ASA r2 cluster to the destination cluster.

What’s next?

If you disabled automatic cutover and automatic storage VM removal, perform post-migration cutover and cleanup to manually cut over your ASA r2 clients to your destination cluster and remove the storage VM from the ASA r2 cluster.

Step 5: Post-migration cutover and cleanup

During an inter-cluster storage VM migration, client I/O transitions to the destination cluster and the storage VM on the source cluster is automatically removed. If you choose to disable automatic cutover and removal of the source storage VM during the migration, you need to perform these steps manually after the migration status reaches Ready for source cleanup.

Manually cut over clients after a storage VM migration

If you disable automatic client cutover during the inter-cluster migration of a storage VM, after the migration relationship is ready for cutover, perform the cutover manually so the destination storage VM can serve data to clients.

About this task

Perform this task from the destination cluster.

Steps

  1. Manually execute client cutover:

    vserver migrate cutover -vserver <storage_VM_name>

  2. Verify that the cutover operation is complete:

    vserver migrate show
Result

Data is being served to your clients from the storage VM on your destination cluster.

What's next?

You are now ready to remove the storage VM from the source cluster.

Manually remove a storage VM after migration

If you disable automatic source cleanup during an inter-cluster storage VM migration, after the migration is complete, remove the storage VM from the source cluster to free the storage space.

Before you begin

Your clients should be serving data from the destination cluster.

Steps

  1. From the source cluster, verify that the status of the source storage VM is Ready for source cleanup:

    vserver migrate show

  2. Remove the source storage VM:

    vserver migrate source-cleanup -vserver <storage_VM_name>
Result

The storage VM on your source cluster is removed.