This is Part 2 of the Diaxion blog series focusing on the Azure Migrate service to Discover, Assess, Replication and Migrate workloads from an on-premises location to Azure. Part 1 was focused on Discovery and Assessment and can be found here – Azure Migrate – Discovery and Assessment
Now that we have completed the Discovery and Assessment as per Part 1 of this blog, we are now ready to replicate the selected servers from our on-premises environment to Azure. Previously, most replications were accomplished over a secured, encrypted Internet connection, however this did run the risk of transmitting private, potentially business sensitive data over an Internet link. There are now options to replicate servers over an ExpressRoute connection either using Microsoft Peering or Private Peering using private endpoints, however as the private peering method is only new it is quite limited. The decision on which network methodology is best for you is an individual business decision that must be considered prior to replication.
Regardless of the network methodology you choose, once the network is in place the replication of data itself is quite similar. The on-premises Azure Migrate appliance co-ordinates communications and manages the data replication for servers replicating to Azure.
The replication process copies the server storage and the hosting configuration file from on-premises to a configured storage account in your Azure tenancy. Once the initial replication is completed, delta synchronisations occur frequently to keep changed blocks in check from on-premises to Azure. The replication of a server is a multi-step process allowing you to configure each replication manually. The steps take into consideration the different ways Azure Migrate can support your environment. These include:
- The source settings of your environment and whether you are replicating virtual servers with VMware vSphere or Hyper-V or physical servers.
- The ability to include metadata from the Discovery and Assessment phase including migration groups that you may have configured to group servers.
- The target settings specific to the replication you are looking to complete. These include the target subscription, resource groups, storage account, virtual network and high-availability options that may apply to your servers, whether that’s an Availability Zone (not available in all regions) or an Availability Set. You can also choose to apply the Azure Hybrid Benefit in this step if you servers that are already licensed with a valid Windows Server License.
- The target compute settings for the server that will end up running in Azure. You can choose to let the Assessment make these decisions for you with regards to the Azure VM size, OS type and OS disk or you can select these manually if you wish to override the assessment details. These sizes and options can be changed at any time prior to replication starting, once the replication is underway the options cannot be changed. A VM can always
be resized post-migration however. - The disks that are available for replication. The normal practice is to migrate all disks that are attached to your on-premises server but depending on your configuration you have the option to take selected disks only. The disk replicas in Azure will be managed disk, you can choose either Standard HDD/SSD disks or Premium managed disks.
After the above options have been taken into consideration, the replication begins. The replication of the virtual machine is a ‘live’ event where the replication is ongoing until the VM is migrated to Azure. The replication is a storage-based data transfer keeping the on-premises VM and the Azure disks synchronised to minimise the amount of time required for the migration. This delta replication is handled through the Azure Migrate appliance that is deployed on-premises. Alerts and details of the replication are raised in the Azure portal under Azure Migrate.
The status of the replicating servers can be viewed through the Azure Portal, whether the replication is ongoing and showing a percentage of data replicated, or the state of the replication and whether it is healthy or critical. The replication for any server can be stopped if required via the Portal, as well as current and past events related to the replication of a server.
The actual duration of the replication is obviously dependent on your network and source environment. If you are transferring the data over an Internet link you must be aware of the risk of data flooding the link thus impacting the business. The source environment, whether Hyper-V or VMware can also contribute to the performance of the replication as the transfer is only as fast as the hosts and storage can manage. The source environment is generally also the cause of replication failures, there are a
few ‘gotchas’ that can trigger errors, we will talk to some of these cause and solutions in Part 4 of this blog.
Some technical comments about the replication process are as follows:
- The Azure Migrate appliance is responsible for the compression and encryption of data prior to uploading to Azure. The end storage in Azure is also encrypted using “encryption at rest” protocols. HTTPS and TLS 1.2 are used for the transfer of data.
- Replication cycles are dependent on how long the previous delta cycle required. The formula is previous cycle time divided by 2 or one hour, whichever is higher.
- A delta cycle is started immediately after the initial replication is finished. Future delta cycles then follow the above formula for timing.
- Folders are created in the Azure Storage account that has been configured for replication per replicating server. These folders contain the disks and the VM configuration file. These can be explored using Azure Storage Explorer.
- Azure Migrate will automatically create selected Azure services on the first replication attempt. These services include a Service Bus, Gateway Storage account, Log Storage account and a Key Vault for managing the connection strings for the Service Bus and access keys for the storage accounts.
And that’s it for Part 2 of this Azure Migrate blog series. The next blog will look at the migration of data using the Azure Migrate service. Hopefully this has been helpful and if you have any questions about the migration of workloads to Azure, please contact the team at Diaxion and we’ll be happy to assist with any questions you may have. Stay tuned for Part 3, coming shortly!
Part 1 – Discovery and Assessment
Part 2 – Replication
