VMware VM Migration to AWS with Pure Cloud Block Store and AWS Application Migration Services

Last updated
Save as PDF

This document illustrates the steps to perform a migration of a VMWare virtual machine (VM) contained on a vVol datastore to Amazon Web Service (AWS). The tools involved include AWS Application Migration Service (MGN) and native replication technology on the FlashArray and Pure Cloud Block Store (CBS).

Abstract

The solution leverages two workflows. First, by using AWS MGN to migrate and convert the VM(s) to AWS including the VM’s boot volume. Second, Pure Storage array-based replication will be replicating the data volumes from FlashArray to CBS. Data volume replication requires the VM(s) volume to be in a vVol or RDM datastore. the replicated data volume can be presented to the newly created AWS EC2 via in-guest iSCSi.

By combining the software capabilities of Pure Cloud Block Store alongside the orchestration and integration that AWS MGN provides, enterprises will leverage a viable method for migrating vVol VMs to AWS while also taking full advantage of the benefits that come from utilizing an array-based shared storage pool. These benefits include Pure Storage’s industry-leading data reduction combined with enterprise-class storage features including array-based replication, instantaneous snapshots, and Purity CloudSnap™. In addition, AWS MGN provides a reliable and proven agent-based VM migration and EC2 conversion technology on AWS.

The main use case for this document is lift-and-shift migration from on-premises VMware to AWS.

Architecture

The figure illustrates the migration process. As briefly mentioned above, the source environment consists of a Linux VM running on VMware infrastructure. The virtual machine is configured with two virtual disks, boot volume, and data volume(s). Each volume type will have its own migration path.

The reason behind this separation is that AWS EC2 instances are locked to EBS disks for booting. Therefore, AWS MGN will handle the migration and conversion of the boot volume. On the other path, data volume will be migrated using async replication between FlashAarray and CBS. These two parts can be combined together to offer up a simple and efficient migration path for even the largest of virtual disks.

Migration Process

The following are high-level migration workflow steps:

Verify the prerequisites are met.
Install the AWS Replication agent on the source machine.
Replicate the data volume.
Launch test instance.
Perform acceptance tests on the machine and verify data is presented.
Mark the server as ready to cutover.
Launch cutover instance.
Confirm all services are operational and data is presented.
Finalize the cutover.

Prerequisites

The following steps are to be checked or done prior to starting the migration process:

Deployment of Cloud Block Store on AWS. Cloud Block Store can be deployed from the AWS console via AWS Marketplace (See Cloud Block Store Deployment and Configuration Guide), or it can be deployed using Terraform ( See Using Terraform to deploy Cloud Block Store).
Connectivity established between on-premises FlashArray and Cloud Block Store.
Source VM prerequisites:
1. Confirm source machine OS is supported by AWS MGN. Check Supported operating systems.
2. Verify source machine has at least 2 GB of free disk space on the root directory or boot disk (i.e. c: driver on Windows). also 300 MB of free RAM in order to run the AWS replication agent.
VMware prerequisites:
1. VM volumes are contained on a vVol datastore or on raw device mapping (RDM) disks and backed by on-premises FlashArray. If VMFS datastores are in use, please convert them to vVols.
2. Install Pure Storage vSphere Plugin.
3. Verify network communication over TCP ports 443 and 1500 between the source machine and the Staging area subnet. See Appendix B.
AWS prerequisites:
1. Verify AWS region is supported by AWS MGN. Check Supported AWS regions.
2. Create or use an existing Virtual Private Network (VPC).
3. Create staging area subnet. This subnet within the Replication and Converter Server will be launched.
4. Create launch area subnet(s) and security groups. This subnet and security group where the migrated servers, EC2 instance will be launched.
5. Generate or retrieve AWS account credentials, AWS Access key, and secret key. Those will be used during the replication agent installation. Check generating AWS credentials.

Migrate the Boot/OS Volume

Step 1:

Initialize AWS Application Migration Service

1. In AWS console, navigate to Application Migration Service, Select Get started.

2. Set up the setting for the replication server template. This setting can be modified at any time for a new source server or you can group the source server to use a template.

a. Staging area subnet: Select the subnet group where you want the replication server to be launch.

b. Replication Server instance type: By default, t3.small instance types are utilized for the most common workload migration. It can support the replication of up to 15 disks from multiple source servers. If you are

c. EBS volume type: Select General purpose (gp2).

d. EBS encryption: Keep the default EBS encryption, or select a custom key.

e. Security group: Application Migration Service creates a security group upon initializing and assigns it to the replication server.

f. Data routing and throttling: In case VPN or DirectConnect are used to route traffic between AWS and on-premises you can tick this option and use private IP for data replication. Otherwise, leave as is and use public IP. (For the public IP data traffic, make sure the staging subnet has internet access)

Step 2:

Install AWS Replication Agent

In order to add source servers to the Application Migration Service console, you need first to install the replication agent on each individual VM. Once the agent is installed the VM will be added to Source Server page.

Windows

Download the Agent installer by copying the following link on a browser. Make sure to select a supported region and modify the link accordingly ( the region is indicated by green ).

https://aws-application-migration-service-us-west-2.s3.amazonaws.com/latest/windows/AwsReplicationWindowsInstaller.exe

2. Navigate to the downloaded file AWSReplicationWindowsInstaller.exe, right-click and Run as an Administrator. The command prompt (CMD) will open.

3. Enter AWS Region Name, the AWS Access Key ID, and the AWS Secret Access Key. Then the script will prompt which disk to be replicated, enter the boot disk C:. The installer then starts installing the Agent.

Note: If installation fails due to Failed to validate AWS credentials. Alternatively, you can run the installer by passing the parameters to the installation script command. check the below examples can be run in CMD or Windows PowerShell.

AwsReplicationWindowsInstaller.exe --region us-west-2 --aws-access-key-id AKIAIOFODNXXXXXXX --aws-secret-access-key wJalrXUtnFEMDENXXXXXXXXXXXX

4. Once finished, the installer will provide the source server ID (indicated by green in the example below).

The installation of the AWS Replication Agent has started.
AWS Region Name: us-west-2
AWS Access Key ID: AKIAIOFODNXXXXXXX
AWS Secret Access Key:
Verifying that the source server has enough free disk space to install the AWS Replication Agent.
(a minimum of 2 GB of free disk space is required)
Identifying volumes for replication.
Choose the disks you want to replicate. Your disks are: c:,d:
To replicate some of the disks, type the path of the disks, separated with a comma (for example, C:,D:). To replicate all disks, press Enter:c:
Disk to replicate identified: c:0 of size 90 GiB
All volumes for replication were successfully identified.
Downloading the AWS Replication Agent onto the source server... Finished.
Installing the AWS Replication Agent onto the source server... Finished.
Syncing the source server with the Application Migration Service Console... Finished.
The following is the source server ID: s-5d7113fc9be07a28f.
The AWS Replication Agent was successfully installed.
Press Enter to close...

5. Navigate back to AWS MGN console, then select Source Servers. You can use the search bar to filter source machines by the provided source server ID from the previous step.

6. Wait till the first initial sync is done then move to the next step Test and cut over the migration.

Linux

1. Download the Agent installer by copying the following link on a browser. Make sure to select a supported region and modify the link accordingly ( the region is indicated by green ).

wget -O ./aws-replication-installer-init.py https://aws-application-migration-service-us-west-2.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py

2. Verify Python3 is installed python3 --version. If python is not installed use your Linux distribution download manager to install it.

Ubuntu example:

sudo apt-get install python3

3. Run the script and pass the parameters as follow:

sudo python3 aws-replication-installer-init.py --region us-west-2 --aws-access-key-id AKIAIOFODNXXXXXXX --aws-secret-access-key wJalrXUtnFEMDENXXXXXXXXXXXX

4. The script will scan the disks mounted on the system and prompt you to select the disks to be replicated. In this case, enter the boot disk /dev/sda.

5. Once finished, the installer script will provide the source server ID. This ID is used to locate the source server on the AWS MGN console.

The installation of the AWS Replication Agent has started.
Identifying volumes for replication.
Choose the disks you want to replicate. Your disks are: /dev/sda, /dev/sdb
To replicate some of the disks, type the path of the disks, separated with a comma (for example, /dev/sda,/dev/sdb). To replicate all disks, press Enter:/dev/sda
Identified volume for replication: /dev/sda of size 16 GiB
All volumes for replication were successfully identified.
Downloading the AWS Replication Agent onto the source server... Finished.
Installing the AWS Replication Agent onto the source server... Finished.
Syncing the source server with the Application Migration Service Console... Finished.
The following is the source server ID: s-583ad44ca8f665999.
The AWS Replication Agent was successfully installed.
Press Enter to close...

Note that in some cases during or after the initial sync is complete. The server may show a yellow lagging alert, which indicates the server is not in sync with the source and the data is not up to date. Typically this will be resolved by the MGN automatically. However, if this persists or a red stalled alert occurred instead, this will require user intervention as it might be a communication or agent issue. See Troubelshoot AWS MGN.

Migrate the Data Volume

Step 1:

Connect and Configure Async Replication

1. Access Cloud Block Store and get the connection key.

This step requires an established connection between the on-premises FlashArray and Cloud Block Store in AWS. This can be achieved with various approaches, i.e AWS Site-to-Site VPN or AWS DirectConnect.

2. Access on-premises FlashArray and establish the connection with Cloud Block Store by clicking on the plus icon, and fill the following:

Management Address: This is the Cloud Block Store floating IP address used to access the GUI.
Type: Async Replication
Connection Key: The key obtained in the previous step.
Replication Address: The replication addresses are auto-discovered unless NAT is used. (In order to get the replication address use the CBS GUI and go to Settings > Network).

3. Create a protection group for replication to Cloud Block Store.

4. Click on the created protection group and enable and edit the replication schedule.

For more detailed information on protection group replication interval and retention schedule. See FlashArray Asynchronous Replication Configuration and Best Practices Guide.

5. Click on the shown ellipsis to add the target to the protection group. The target for this should be Cloud Block Store connected in the previous steps.

Step 2:

Configure the Data Volume Replication in VMware

1. Import the protection group created using the Pure Storage plugin in vCenter.

2. From VM and Templates, Right-click on the VM(s) to be replicated to CBS and click on Edit VM Storage Policies.

3. In this step, enable Configure per disk and assign the replication policy to the data disks/volumes (No need to select the OS disk since it has been already replicated using AWS Migrate in the previous sections).

Finalize the Migration (Test and Cutover)

Step 1:

Modify the EC2 Launch Template

1. Navigate back to AWS MGN console and select the Source Server, then Launch settings, and click on Modify.

2. By default the AWS MGN is launching the test and cutover instance in the default VPC and subnet in the region. Therefore, these steps are required in order to launch the EC2 instance in the designated VPC, subnet, and security group.

a. Template version description: Enter the template description.

b. Instance type: select the instance type.

c. Key pair: (optional) select key pair for the login securely after launch. Make sure you have access to the key before selecting one or create a new pair.

d. Network settings: select Virtual Private Cloud (VPC). Do not select security group. The security group will be selected under the Network interface.

e. Storage: By default, this shows the migrated boot volume. Under the disk you can change the Volume type, the maximum number of IOPS supported. You can not change the Size, since this disk will be created from a snapshot of the migrated disk.

f. Resource tags: Keep the generated tags or enter your own customized tags.

Under Network Interface:

g. Subnet: Select launch subnet.

h. Security group: select security group, make sure that security group and subnet are under the same VPC.

i. Auto-assign public IP: (Optional) for easy access during testing the migration assign public IP. Or opt-out and use jump box or bastion machines.

2. Under Advance details, scroll down and copy the bash script below in paste it into User data. Make sure to enter the required variables in green at the beginning of the script. The script applies the best practice configuration for iSCSi and Multipath. Also provisions the data volume from CBS by creating a host, cloning the replicated snapshot, and connect the volume to the host.

This script works for Linux Ubuntu. Windows and other Linux distributions will be added soon. See Appendix A for more information.

#!/bin/bash

# VARIABLES

CBS_MNGMT_IP=<enter-cbs-management-ip>     # i.e CBS_MNGMT_IP=172.23.2.180
SNAPSHOT=<enter-snapshot-name>             # i.e SNAPSHOT=flasharray-m20-1:cbs-aws-migration-policy.3.vvol-Linux-ubuntu/Data-a2e2d086
DATA_VOLUME_PATH=<enter-mount-path>        # i.e DATA_VOLUME_PATH=/mnt/data

sudo apt -y install git
sudo git clone https://github.com/PureStorage-OpenConnect/cloudblockstore-scripts.git
sudo chmod 700 /cloudblockstore-scripts/linux-migration/ubuntu-post-migration.sh

sudo sh /cloudblockstore-scripts/linux-migration/ubuntu-post-migration.sh $CBS_MNGMT_IP $SNAPSHOT $DATA_VOLUME_PATH > /tmp/pure-post-migration.log 2>&1

3. Modifying the template won't change the current "default" version. In order to change it, navigate to EC2 console, under Launch Templates select the created template by MGN, (you can go back to the AWS MGN to verify the launch template ID is matching). Click on Actions and then Set default version.

4. Select the launch template from the list using the description name that has been entered in the previous step.

Step 2:

Test the Migration

1. Navigate back to AWS MGN console and select the source server. Click Test and Cutover, and select Launch test instance. This will take a couple of minutes.

You can follow the test job steps by clicking on the job ID under Lifecycle.

2. Go to EC2 console, connect to the launched instance by using the public IP or the private IP.

3. Perform acceptance tests on the servers, and verify data volume is mounted and data is presented.

Example:

Linux machine

Note: If the data is not present or the disk is not mounted, check the generated log file for any error/tmp/pure-post-migration.log. Appendix A.

4. After the Test instance is tested successfully. Mark the machine "Ready to cutover" from Test and cutover dropdown. This will finalize the test and delete the test instance.

Step 3:

Cutover the Migration

1. Once Next actions change to "Launch cutover instance". From the top-right, click the Test and cutover and select Launch cutover instances.

2. Last step is to finalize the migration. Click the Test and cutover and select Finalize cutover. This disconnects the source machine and stops the replication.

Appendix A

Post-Migation Script

Consider the following when using the script:

1. The current script works only on Ubuntu-based Linux machines. Other operating systems will be added eventually.

2. The script works on provisioning one data volume.

3. The script requires entering the snapshot name. Make sure you enter the last one.

4. The script redirects the output to this file /tmp/pure-post-migration.log

5. If any issue occurred during the iSCSi/Multipath configuration part. Please refer to Configure Linux Host.

6. If any issue occurred during the CBS storage provisioning. Please refer to the Manually Provision Data Volume.

Manually Provision Data Volume

Clone Replicated Snapshot

1. Once the protection group snapshot is replicated to Cloud Block Store. Go to Protection.

2. Under Snapshot, click on ellipses icon, then select Copy.

Create the Host

You must create a host with corresponding IQN before you can attach a volume to it.

The following example provides steps using the GUI. For CLI users, SSH into the management port and run:purehost create --iqnlist <Host IQN number> <host name>

Using the Cloud Block Store's GUI:

1. On the left navigation pane, click Storage.

2. Click Hosts.

3. Click the + icon to add a new host.

4. Enter the desired name for the host and click Create.

5. Once created, the host is displayed in the list of available hosts. Click on the new host.

6. In the Host Ports box, click the ellipsis (three dots) icon, then select Configure IQNs.

7. Enter the IQN name of the iSCSI host.

8. Locate the host's IQN number by running the following commands on the respective OS. Ensure iSCSI service has started on the host.

Windows PowerShell (Run as Administrator):

(Get-InitiatorPort).NodeAddress

Linux:

cat /etc/iscsi/initiatorname.iscsi

Connect the Volume

The following example provides steps for the GUI. For CLI users, SSH into the management port and run:purevol connect --host <host name> <vol name>

Using the Cloud Block Store's GUI:

1. On the left navigation pane, click Storage. Click Volumes.

2. Select the desired volume.

3. In the Connected Host box, click the ellipsis icon and select Connect.

4. Select the desired host(s) and click Connect.

5. Ensure appropriate clustering software on your hosts is installed if you wish to connect the same volume to multiple hosts.

Appendix B

Verify inbound Replication Communication Between Source Server and AWS over 1500 port

1. Since AWS MGN creates a Security Group upon initialization. First, Confirm that the security group has been created and set with the required inbound rules 1500/TCP.

2. Create and launch a lightweight Linux EC2 Instance in the staging subnet and select the AWS MGN security group.

3. Access the instance and make sure the nc (netcat) command is installed. Then run the following command to open a listener:

nc -l 1500

3. On the source server, run the following command

nc -zv <Linux EC2 IP> 1500

Example output:

adam@linux-ubuntu:~$ nc -zv 34.217.94.162 1500
Connection to 34.217.94.162 1500 port [tcp/*] succeeded!