Replication related

What is the lifecycle of the snapshots and volumes automatically created during migration?

For each source block device, we create a corresponding EBS volume. On occasion if there is an issue with the agent on the source machine being able to send data to a volume, we may create a new volume to replace the old one. Our workflow does not necessarily delete the old volume straight away, and it may remain present for around 10 minutes after the replacement volume comes online. But this is going to be rare, if your network connection is stable.

With regards to the snapshots, we take regular snapshots, so that we can take advantage of the incremental nature of snapshots. If we were for example to take a snapshot once every 6 hours, the snapshot would contain 6 hours worth of snapshots, and could potentially take a long time to complete. By taking them more frequently, we shorten the time taken to create the actual snapshot. This in turn means that when you trigger a test or cutover instance, the time taken to get the process started is not delayed unnecessarily by waiting for EBS snapshots to complete. We would generally keep 5–6 snapshots of a volume, to be sure that there is at least one that is completed when we need it for launch. EBS snapshot creation time has no SLA, and sometimes can be delayed significantly. EBS snapshot creation is also not guaranteed. A snapshot creation can fail (Not the API call, but the actual creation process). Hence we keep the additional snapshots, just in case something more recent actually failed.

What do Lag and Backlog mean during replication?

During replication you may see a server falls out of Continuous Data Protection (CDP) mode. This may occur for various reasons, typically related to the network throughput or interruption.

• Lag – The amount of time since the server was last in CDP mode.

• Backlog – The amount of data that was written to the disk and still needs to be replicated in order to reach CDP mode.

• ETA – The estimated time remaining to return to CDP.

What is Continuous, Block level data replication?

During continuous block-level replication, the replication agent continuously monitors disk input/output (IO) activity on the protected disks. It then replicates all WRITE operations, which involve modifying or adding data, to the Replication Server, ensuring that the data is duplicated and kept up-to-date on the replication server.

What are the Replication initiation Steps?

The following replication steps are involved in the automatic creation of the replication server in the staging area and initiation of data transfer over TCP port 1500:

• Create security groups - Creating EC2 security groups with inbound TCP port 1500 allowed. This security group will be attached to replication server.

• Launch Replication Server - AWS EC2 instance is launched based on the replication configuration set.

• Boot Replication Server - The EC2 instance completes boot process which will now function as a replication server.

• Authenticate with service - Using the user data scripts and the EC2 instance configuration, the instance (replication server) will authenticate with AWS Application Migration Service using service/vpc endpoint.

• Download replication software - The Replication Server downloads replication software from S3. This replication software will write the incoming replicated data to the Replication Server disks.

• Create staging disks - The Replication Server creates replication disks to store the incoming replicated data. The number of replication disks that are created depends on the size of the replicated data.

• Attach the staging disks – In the previous step, the replication disks were created independently, without being attached to a specific Replication Server. Now, they are attached to a Replication Server.

• Pair the Replication Server with AWS Replication Agent – Until this stage, the AWS Application Migration Service managed the communication between the Agent on the Source infrastructure and the Replication Server on the Target infrastructure. Now, the AWS Application Migration Service knows that all the initiation steps have been completed successfully. Therefore, it provides the Agent and the Replication Server information about each other, so that they could start communicating with each other directly.

• Connect AWS Replication Agent to the Replication Server – The Agent and the Replication Server begin communicating with each other directly.

• Start data transfer - Replication begins from source server to Replication Server over TCP 1500.

Is the replicated data encrypted?

AWS Application Migration Service encrypts all the data in transit.

How is the Replication Server provisioned and managed in the Staging Area?

AWS Application Migration Service provisions the Replication Server(s) and automatically manages the addition and removal of the servers as necessary.The AWS Application Migration Service automatically replaces the replication server on a periodic basis. This ensures the replication server is using the latest public Amazon Machine Image (AMI) available for MGN. The latest AMI contains the most up-to-date patches, security updates, and bug fixes. Regularly updating the replication server AMIs allows MGN to maintain the replication servers with the newest components and protections. Customers do not need to take any action to receive new replication server AMIs. MGN will automatically replace the existing replication server as needed when new AMIs are released. This helps keep the replication process secure and up-to-date without any additional effort from users.

What type of replication server is utilized in the AWS Application Migration Service staging area?

AWS Application Migration Service provisions a t3.Small server. The typical ratio of volumes to replication servers is 15:1.

Can we set specific IP addresses for the replication server or conversion server in the AWS Application Migration Service staging area?

No, you cannot specify or assign static IP addresses for the replication server or conversion server in AWS MGN. These servers are managed and maintained by the MGN service itself. The IP addresses for these servers are dynamically assigned from the available pool of IP addresses in the Virtual Private Cloud (VPC) that you specify during the MGN setup process. It's important to note that while you cannot control the specific IP addresses assigned to these servers, you can control the VPC and subnet in which they are deployed. This allows you to configure network access controls and security policies according to your organizational requirements.

Does AWS Application Migration Service compress data during replication?

Yes, AWS Application Migration Service utilizes LZ4 compression during transit resulting in 60–70% compression depending on the type of data.

Are events that are generated by the AWS Application Migration Service servers logged in Cloudtrail in AWS?

Yes, AWS Application Migration Service generates standard AWS API calls that are visible in CloudTrail.

How many snapshots does AWS Application Migration Service create?

5–7 for each disk. Frequency and exact number depend on various factors, such as change rate on the source server and network stability.

There is currently no mechanism for users to adjust the frequency and number of snapshots.

Does AWS Application Migration Service delete snapshots?

AWS Application Migration Service automatically deletes snapshots that are no longer used (such as those left over after source servers have been removed from the AWS Application Migration Service console).

How much capacity is allocated to the staging area?

A volume is created for each volume in the source infrastructure of the same size.

Why is 0.0.0.0:1500 added to inbound rules in the staging area?

AWS Application Migration Service uses TCP Port 1500 for replication between the Source Agents and the replication server. The connection is open for all IPs and can be managed by ACLs or networks controls to limit inbound IPs.

Can AWS Application Migration Service replicate Oracle ASM?

Replication of Oracle with ASM is supported. AWS Application Migration Service also fully supports the use of the Oracle ASM Filter Driver.

How long does a rescan take?

The rescan time will vary depending on the size of the source disks. The time depends on the performance of the disks (linear read),staging area disk performance, and the rate of write operations on the source server (which are sent in parallel with the rescan). The rescan is functioning normally as long as it is moving forward and is not "stuck".

How can I control the bandwidth used for replication?

We recommend you do not limit the bandwidth used for replication. If you have business reasons to require replication to use less bandwidth, you can temporarily use the throttling feature to limit the bandwidth. This will cause lag, that will automatically recover once you remove the throttling.

Are migrations performed by Application Migration Service crash consistent?

Yes, MGN's services are crash-consistent.

How can I perform an SSL connectivity and bandwidth test?

Note

This tool is designed for AWS only.

You can use our SSL bandwidth tool to check for replication bandwidth availability.

1. In your target region, launch a c5.large test server using the public AMI named CE-ssl-speedtest.

2. Select the same subnet as the subnet used in the replication settings of your source machine.

3. Make sure that the security group allows TCP Port 1500 inbound access.

4. On the source machine, browse to https://{test_server_ip}:1500/speedtest

5. Click Start.

Note

• Browse to the web page using the test server public or private IP according to what you defined in your replication settings.

• The following are the AMI details per region:

  • ami-00b38c08ab3506ea7 – US East (N. Virginia)

  • ami-0bd8423a4d80563fc – US East (Ohio)

  • ami-00b7159e9c985a8da – US West (N. California)

  • ami-033a4924b13126a7b – US West (Oregon)

  • ami-0bf60b09675c8d9b6 – Africa (Cape Town)

  • ami-0f01375b50763621b – Asia Pacific (Hong Kong)

  • ami-0b1aeb50834102c18 – Asia Pacific (Mumbai)

  • ami-0b1aeb50834102c18 – Asia Pacific (Hyderabad)

  • ami-044fa8034a31d7578 – Asia Pacific (Tokyo)

  • ami-08b042df0d4c458ea – Asia Pacific (Seoul)

  • ami-0971e46306691cd68 – Asia Pacific (Osaka)

  • ami-0afd42552b236f9dd – Asia Pacific (Singapore)

  • ami-04e7cc6b5d9e8ffa1 – Asia Pacific (Sydney)

  • ami-02f31943dfd88549d – Asia Pacific (Jakarta)

  • ami-033db317ada5abd55 – Asia Pacific (Melbourne)

  • ami-01c24408802db503d – Canada (Central)

  • ami-0b8643189a66159c9 – Europe (Stockholm)

  • ami-0dd5a09d2ae8f46b3 – Europe (Ireland)

  • ami-097fb47f3a1c2bf7e – Europe (London)

  • ami-0a3f9008725d0b4d1 – Europe (Paris)

  • ami-0c65965703bb0e541 – Europe (Milan)

  • ami-01b6fcc2337f6420d – Europe (Spain)

  • ami-07b7defb87a46bb48 – Europe (Frankfurt)

  • ami-01b3e93b3ac0e1340 – Europe (Zurich)

  • ami-016edc078b48f370b – Israel (Tel Aviv)

  • ami-0c90e298af7a2e563 – Middle East (Bahrain)

  • ami-0f7c14e62ef760768 – Middle East (UAE)

  • ami-0edd5ecfc56804583 – South America (São Paulo)

  • ami-00eb76deb85085b3e – AWS GovCloud (US-West)

  • ami-0ba277e7ced412965 – AWS GovCloud (US-East)

• Ensure that the security groups are configured to permit connectivity on inbound port 1500.