Skip to main content
NetApp Solutions

Contributors kevin-hoke
PDFs

Migrate VMs to Amazon EC2 using FSxN: Deployment Guide

This article describes the deployment procedure for this migration solutions.

Configure FSx for ONTAP and Cirrus Data for migration operations

This step-by-step deployment guide shows how to add FSx for ONTAP volume to a VPC. Since these steps are sequential in nature, make sure they are covered in order.

For the purposes of this demonstration, “DRaaSDemo” is the name of the file system created.

Image of the demonstration file system user interface

Once your AWS VPC is configured and FSx for ONTAP is provisioned based on your performance requirements, log in to cloud.cirrusdata.com and create a new project or access an existing project.

Image of the Cirrus Data projects user interface

Before creating the recipe for MigrationOps, AWS Cloud should be added as an integration. CMC provides built-in integration with FSx for ONTAP and AWS. The integration for FSx for ONTAP provides the following automated functionalities:

Prepare your FSx for ONTAP file system:

  • Create new volumes and LUNs that match the source volumes

Note: A destination disk in the FSx for ONTAP FS model is a “LUN” that is created on a “Volume” that has enough capacity to contain the LUN plus a reasonable amount of overhead for facilitating snapshots and meta-data. The CMC automation takes care of all these details to create the appropriate Volume and the LUN with optional user-defined parameters.

  • Create Host entity (called iGroups in FSx) with the Host Initiator IQN

  • Map newly created volumes to appropriate host entities using mappings

  • Create all other necessary configurations

Prepare Production Host for iSCSI connection:

  • If necessary, install and configure iSCSI feature and set up Initiator.

  • If necessary, install and configure multipath (MPIO for Windows) with proper vendor identifiers.

  • Adjust system settings, if necessary, according to vendor best practices, e.g. with udev settings on Linux.

  • Create and manage iSCSI connections such as persistent/favorite iSCSI targets on Windows.

To configure CMC Integration for FSx for ONTAP and AWS, perform the following steps:

  1. Log in to the Cirrus Data Cloud portal.

  2. Go to the Project for which you want to enable the integration.

  3. Navigate to Integrations → Goodies.

  4. Scroll to find FSx for NetApp ONTAP and click ADD INTEGRATION.

    Image of the Cirrus Data 'Add Integration' user interface

  5. Provide a descriptive name (strictly for display purposes) and add the appropriate credentials.

    Image of the Cirrus Data 'Add Integration' user interface

  6. Once the integration is created, during the creation of a new migration session, select Auto Allocate Destination Volumes to automatically allocate new volumes on FSx for ONTAP.

    Note: New LUNs will be created with the same size as the source volume's size, unless “Migrate to Smaller Volumes” is enabled for the migration.

    Note: If a host entity (iGroup) doesn’t already exist, a new one will be created. All host iSCSI Initiator IQNs will be added to that new host entity.

    Note: If an existing host entity with any of the iSCSI initiators already exists, it will be reused.

  7. Once done, add the integration for AWS, following the steps on the screen.

    Image of the Cirrus Data 'Add Integration' user interface

    Note: This integration is used while migrating virtual machines from on-premises storage to AWS along with FSx for ONTAP integration.

    Note: Use management relays to communicate with Cirrus Data Cloud if there is no direct outbound connection for production instances to be migrated.

With Integrations added, it’s time to register hosts with the Project. Let’s cover this with an example scenario.

Host registration scenario

Guest VMware VMs residing on vCenter in on-premises data center:

  • Windows 2016 running with SQL Server with three VMDKs including OS and data disks. It is running an active database. The database is located on a data volume backed by two VMDKs.

Note: Since the source is a VMware environment and VMDKs are used, the Windows iSCSI Initiator software is not currently configured on this guest VM. To connect to our destination storage via iSCSI, both iSCSI and MPIO will have to be installed and configured. Cirrus Data Cloud integration will perform this installation automatically during the process.

Note: The Integration configured in the previous section automates the configuration of the new destination storage in creating the new disks, setting up the host entities and their IQNs, and even remediation of the application VM (host) for iSCSI and multipath configurations.

Image of the VMware virtual machines that will be migrated

This demonstration will migrate the application VMDKs from each VM to an automatically provisioned and mapped iSCSI volume from FSx for ONTAP. The OS VMDK in this case will be migrated to an Amazon EBS volume as Amazon EC2 instances support this Amazon EBS only as the boot disk.

Note: The scale factor with this migration approach is the network bandwidth and the pipe connecting on-premises to AWS VPC. Since each VM has 1:1 host session configured, the overall migration performance depends on two factors:

  • Network bandwidth

  • Target instance type and ENI bandwidth

The migration steps are as follows:

  1. Install CMC agent on each host (Windows and Linux) designated for the migration wave. This can be performed by executing a one-line installation command.

    To do this, access Data Migration > Migration Hosts > Click on “Deploy Cirrus Migrate Cloud” and click to select “Windows”.

    Then, copy the iex command to the host and run it using PowerShell. Once the deployment of the agent is successful, the host will be added to the Project under “Migration hosts”.

    Image of the Cirrus Data installation interface

    Image of the Windows installation progress

  2. Prepare the YAML for each virtual machine.

    Note: It is a vital step to have a YAML for each VM that specifies the necessary recipe or blueprint for the migration task.

    The YAML provides the operation name, notes (description) along with the recipe name as MIGRATEOPS_AWS_COMPUTE, the host name (system_name) and integration name (integration_name) and the source and destination configuration. Custom scripts can be specified as a before and after cutover action.

    operations:
    -   name: Win2016 SQL server to AWS
        notes: Migrate OS to AWS with EBS and Data to FSx for ONTAP
        recipe: MIGRATEOPS_AWS_COMPUTE
        config:
            system_name: Win2016-123
            integration_name: NimAWShybrid
            migrateops_aws_compute:
                region: us-west-2
                compute:
                    instance_type: t3.medium
                    availability_zone: us-west-2b
                network:
                    vpc_id: vpc-05596abe79cb653b7
                    subnet_id: subnet-070aeb9d6b1b804dd
                    security_group_names:
                        - default
                destination:
                    default_volume_params:
                        volume_type: GP2
                    iscsi_data_storage:
                        integration_name: DemoDRaaS
                        default_volume_params:
                            netapp:
                                qos_policy_name: ""
                migration:
                    session_description: Migrate OS to AWS with EBS and Data to FSx for ONTAP
                    qos_level: MODERATE
                cutover:
                    stop_applications:
                        - os_shell:
                              script:
                                  - stop-service -name 'MSSQLSERVER' -Force
                                  - Start-Sleep -Seconds 5
                                  - Set-Service -Name 'MSSQLSERVER' -StartupType Disabled
                                  - write-output "SQL service stopped and disabled"

                        - storage_unmount:
                              mountpoint: e
                        - storage_unmount:
                              mountpoint: f
                    after_cutover:
                        - os_shell:
                              script:
                                  - stop-service -name 'MSSQLSERVER' -Force
                                  - write-output "Waiting 90 seconds to mount disks..." > log.txt
                                  - Start-Sleep -Seconds 90
                                  - write-output "Now re-mounting disks E and F for SQL..." >>log.txt
                        - storage_unmount:
                              mountpoint: e
                        - storage_unmount:
                              mountpoint: f
                        - storage_mount_all: {}
                        - os_shell:
                              script:
                                  - write-output "Waiting 60 seconds to restart SQL Services..." >>log.txt
                                  - Start-Sleep -Seconds 60
                                  - stop-service -name 'MSSQLSERVER' -Force
                                  - Start-Sleep -Seconds 3
                                  - write-output "Start SQL Services..." >>log.txt
                                  - Set-Service -Name 'MSSQLSERVER' -StartupType Automatic
                                  - start-service -name 'MSSQLSERVER'
                                  - write-output "SQL started" >>log.txt

  3. Once the YAMLs are in place, create MigrateOps configuration. To do this, go to Data Migration > MigrateOps, click on “Start New Operation” and enter the configuration in valid YAML format.

  4. Click “Create operation”.

    Note: To achieve parallelism, each host needs to have a YAML file specified and configured.

  5. Unless the scheduled_start_time field is specified in the configuration, the operation will start immediately.

  6. The operation will now execute and proceed. From the Cirrus Data Cloud UI, you can monitor the progress with detailed messages. These steps automatically include tasks that are normally done manually, such as performing auto allocation and creating migration sessions.

    Image of the Cirrus Data migration progress

    Note: During the host-to-host migration, an additional security group with a rule allowing Inbound 4996 port will be created, which will allow the required port for communication and it will be automatically deleted once the synchronization is complete.

    Image of the inbound rule required for Cirrus Data migration

  7. While this migration session is synchronizing, there is a future step in phase 3 (cutover) with the label “Approval Required.” In a MigrateOps recipe, critical tasks (such as migration cutovers) require user approval before they can be executed. Project Operators or Administrators can approve these tasks from the UI. A future approval window can also be created.

    Image of the Cirrus Data migration syncronization

  8. Once approved, the MigrateOps operation continues with the cutover.

  9. After a brief moment, the operation will be completed.

    Image of the Cirrus Data migration completion

    Note: With the help of Cirrus Data cMotion™ technology, the destination storage has been kept up-to-date with all the latest changes. Therefore, after approval is given, this entire final cutover process will take a very short time—less than a minute—to complete.

Post-migration verification

Let’s look at the migrated Amazon EC2 instance running the Windows Server OS and the following steps that have completed:

  1. Windows SQL Services are now started.

  2. The database is back online and is using storage from the iSCSI Multipath device.

  3. All new database records added during migration can be found in the newly migrated database.

  4. The old storage is now offline.

Note: With just one click to submit the data mobility operation as code, and a click to approve the cutover, the VM has successfully migrated from on-premises VMware to an Amazon EC2 instance using FSx for ONTAP and its iSCSI capabilities.

Note: Due to AWS API limitation, the converted VMs would be shown as “Ubuntu.” This is strictly a display issue and does not affect functionality of the migrated instance. An upcoming release will address this issue.

Note: The migrated Amazon EC2 instances can be accessed using the credentials that were used on the on-premises side.