Skip to main content

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

Contributors netapp-aherbin
PDFs

Beginning with ONTAP 9.18.1, you can non-disruptively migrate a storage virtual machine (VM) from any ASA cluster to any ASA r2 cluster. Migrating from an ASA cluster to an ASA r2 cluster allows you to adopt the simplified and streamlined architecture of ASA r2 systems for SAN-only environments.

Storage VM migration between ASA and ASA r2 storage systems is supported as follows:

From any of the following ASA systems: To any of the following ASA r2 systems:

  • ASA C800

  • ASA C400

  • ASA C250

  • ASA A900

  • ASA A800

  • ASA A400

  • ASA A250

  • ASA A150

  • ASA AFF A800

  • ASA AFF A700

  • ASA AFF A400

  • ASA AFF A250

  • ASA AFF A220

  • ASA A1K

  • ASA C30

  • ASA A90

  • ASA A70

  • ASA A50

  • ASA A30

  • ASA A20
Note For the most current list of ASA and ASA r2 systems, see NetApp Hardware Universe. ASA r2 systems are listed in NetApp Hardware Universe as "ASA A-Series/C-Series (New)".

You can migrate a storage VM to an ASA r2 cluster from an ASA cluster only. Migration from any other type of ONTAP system is not supported.

Before you begin

All nodes in the ASA r2 cluster and the ASA cluster must be running ONTAP 9.18.1 or later. The ONTAP 9.18.1 patch versions on the cluster nodes can vary.

Step 1: Verify the status of the ASA storage VM

Before you migrate a storage VM from an ASA system, there should be no NVMe namespaces or vVols present and each volume in the storage VM should contain only one LUN. Migration of NVMe namespaces and vVols is not supported. The architecture of ASA r2 systems requires that volumes contain a single LUN.

Steps

  1. Verify that no NVMe namespaces are present in the storage VM:

    vserver nvme namespace show -vserver <storage_VM>

    If entries are displayed, the NVMe objects must be converted to LUNs or removed. See the vserver nvme namespace delete and the vserver nvme subsystem delete commands in the ONTAP command reference for more information.

  2. Verify that there are no vVols present in the storage VM:

    lun show -verser <storage_VM> -class protocol-endpoint,vvol

    If any vVols are present, they should be copied to another storage VM and then deleted from the storage VM to be migrated. See the lun copy and lun delete commands in the ONTAP command reference for more information.

  3. Verify that each volume in the storage VM contains a single LUN:

    lun show -verser <storage_VM>

    If a volume contains more than one LUN, use the volume create and lun move commands to create a 1:1 volume-to-LUN ratio. See the ONTAP command reference for more information.

What’s next?

You are ready to create a cluster peer relationship between your ASA and ASA r2 clusters.

Step 2: Create a cluster peer relationship between your ASA and ASA r2 clusters

Before you can migrate a storage VM from an ASA cluster to 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.

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 ASA r2 cluster, create a peer relationship with the ASA cluster and generate a passphrase:

    cluster peer create -peer-addrs <ASA_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 ASA cluster, create a peer relationship with the ASA r2 cluster:

    cluster peer create -peer-addrs <ASA_r2_LIF_IPs>

  4. Enter the passphrase generated on the ASA r2 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 ASA and ASA r2 clusters are peered and storage VM data can be securely transferred.

What’s next?

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

Step 3: Prepare for storage VM migration from an ASA to an ASA r2 cluster

Before you migrate a storage virtual machine (VM) from an ASA cluster to 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 ASA r2 cluster, execute the migration pre-check:

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

    If you need to fix any issues to prepare your ASA cluster for migration, the issue and the corrective action is 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 cluster to an ASA r2 cluster.

Step 4: Migrate an ASA storage VM to an ASA r2 cluster

After you have prepared your ASA cluster and created the necessary cluster peer relationship with the ASA r2 cluster, you can begin the storage VM migration.

When performing a storage VM migration, it is a best practice to leave 30% CPU headroom on both the ASA cluster and the ASA r2 cluster to enable the CPU workload to execute.

About this task

After the storage VM migration, clients are automatically cut over to the ASA r2 cluster and the storage VM on the ASA cluster is automatically removed. Automatic cutover and automatic storage VM removal are enabled by default. You can optionally disable them both and perform the cutover and the storage VM removal manually.

Before you begin

  • The ASA r2 cluster must have enough free space to hold the migrated storage VM.

  • If the ASA storage VM contains encrypted volumes, the onboard key manager or the external key manager on the ASA r2 system must be configured at the cluster level.

  • The following operations cannot be running on the source ASA cluster:

    • Failover operations

    • WAFLIRON

    • Fingerprint

    • Volume move, rehost, clone, create, convert or analytics

Steps

  1. From the ASA r2 cluster, start the storage VM migration:

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

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

  2. Monitor the status of the migration

    vserver migrate show -vserver <storage_VM_name>

    When the migration is complete, the status displays as migration-complete.

Note 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.
Result

The storage VM is migrated from the ASA cluster to the ASA r2 cluster. The storage VM’s name and UUID, the data LIF name, IP address, and object names, such as the volume name, remain unchanged. The UUID of the migrated objects in the storage VM are updated.

What’s next?

If you disabled automatic cutover and automatic storage VM removal, manually cut over your ASA clients to your ASA r2 cluster and remove the storage VM from the ASA cluster.