다음을 통해 공유

Azure Migrate: Server Migration Overview

  • 아티클

Introduction

Azure Migrate offers one stop solution to migrate non-Azure infrastructure to Azure. Using Azure Migrate, you can migrate Servers, Databases, Web Applications, Data and Virtual Desktops from almost any environment to Azure.

Azure migrate is not just a migration tool. You can perform discovery, assessment, dependency check, performance bench-marking of your infrastructure before you migrate you infrastructure to Azure.
 

In this article, we will focus on the server migration solution offered by  Azure Migrate.

This article is a generic article on Azure Migrate Server migration, which gives you an overview of the service, points to be considered and high level steps. Most of the information published here are already available in Microsoft Documentation , however this article will give you a single window view of the Azure Migrate Server Migration Service. 

Azure Migrate: Important Points

• Azure Migrate comes in two versions. The previous version supported discovery and assessment, but not migration. Current version supports discovery, assessment and migration. You cannot create any new project in the previous version, and Microsoft recommends to use the current version for discovery, assessment and migration.

• **For Server Migration, Azure Migrate offers two major tools 1) Server Assessment tool 2) Server Migration tool. ** You can use Microsoft native tools or third party tools which are integrated with Azure Migrate. These third party tools are referred as Independent Software Vendor (ISV) tools.

• Azure Migrate is a free service. However, if you use ISV tools for assessment or migration, you might incur charges depending on the tool which you are using. If you use Microsoft native (first party) assessment and migration tools, there is no cost associated with it.

• If you use Dependency visualization during assessment, then data will be stored at Log Analytics Workspace. You will incur standard Log Analytics Workspace charges after 180 days.

• There is no SLA associated with Azure Migrate, as it is a free service.

• Azure Migrate supports replication over Internet or ExpressRoute. Replication traffic goes over port 443.

• In general, migration of Encrypted Disk is not supported. However, if you have encrypted disks at VMWare VM, you can check this document to migrate that, using REST API.

Agent-based and Agent-less Migration

Azure Migrate offers two migration approaches, agent-based and agent-less. Both these approaches have their own advantages, drawbacks and use cases.

Agent-based migration

You can use agent-based migration to migrate almost any kind of workload, which include VMware, Physical Server, AWS, GCP and servers running on other platforms.

Agent-based migration uses some backward functionality from Azure Site Recovery.

  

You need to deploy Replication Appliance for agent-based migration, which uses Configuration Server and Process Server. The Configuration Server handles server migration and co-ordinates replication. The Process Server receives machine data, compresses and encrypts it, and sends to Azure. The data is written in managed disk in Azure. Generally both these roles are installed within same server.

When you use agent-based migration, you also need to install mobility agent in each machine which you are planning to migrate. This mobility agent sends the replication data to the Process Server, which in turn sends it to Azure. 

For agent-based migration, Azure Migrate appliance is not mandatory. It is only required if you want server assessment before migration. 

For more information, please refer Agent-based migration architecture.

Agent-less migration

In agent-less migration, you do not need to install mobility agent in each machine. Azure Migrate takes care of the assessment as well as replication and migration.

**For agent-less migration, deployment of Azure Migrate appliance is mandatory. **

For VMware VMs, Azure Migrate supports agent less migration as well as agent based migration. For agent less migration, Azure Migrate creates a Key Vault to manage access keys for the replication storage account. 

Agent-based vs Agent-less

A thumb rule is to opt for agent-less migration whenever possible. You do not need to install agent in every single VM. Also, you do not need to configure Replication Appliance.

However, not all migration scenarios support agent-less migration. Agent-based migration, on the other hand, is supported in almost any scenario.

If you are migrating from VMware or Hyper-V , the recommended approach is agent-less. In fact, for Hyper-V VMs, Microsoft does not mention any option for agent-based migration.
**
However, for VMware ; you might need to consider agent-based migration in some scenarios.** The most common such scenarios are  :

  1. When you are using RDM / Pass-through Disks at VMware VM.

  2. When VMware VMs are using UEFI Boot.

Above two scenarios are not supported by agent-less migration, but supported by agent-based migration.

Starting from Sep 2020, Azure Migrate supports Availability Zone. This means, you can migrate your server to a specific Availability Zone using Azure Migrate.

In case you are not sure which migration approach will be suitable to migrate your VMware environment, please refer this document to see supported and unsupported features for both the methods.

To do agent-based migration, please refer this link. 

For Hyper-V VMs, you just need to install the agent on Hyper-V host or cluster node. You do not need to install the agent on each Hyper-V VM. For more information, you can refer to Hyper-V Replication Architecture document. 

For Physical Servers, AWS, GCP and all other platforms, you have to install the mobility agent on each machine that you want to migrate. For more information, please refer Agent-based Migration Architecture documentation. 

Migration Planning

Before you configure the migration, you have to plan it well. Your planning should include cover following points : 

1) Support Matrix

Please refer Azure Migrate Support Matrix to  check features and limitations associated with each migration scenario. You will get support matrix for each source such as VMware, Hyper-V and Physical Servers.

  

2) Supported Geographies

Microsoft has published a table, where you can create your Azure Migrate Project. However, you can assess and migrate systems for other target locations. 

3) Permission Required

• You need Contributor or Owner permissions in the subscription to create an Azure Migrate project and to register the Azure Migrate appliance.

• If you are leveraging agent-less migration feature for VMware VMs, Azure migrate will create a Key Vault. You account should have permission to create the Key Vault.

• You should also have the privilege to create an Azure AD App.

• You need proper privileges in source environment to deploy the appliance , perform assessment and initiate the migration.

4) Network Planning

• You need to open all required ports to allow Discovery, Assessment, replication and Migration. This depends on multiple factors like source environment, migration approach and network topology.

5) Target Setup

Before you perform the migration, you need to ensure that following components are available at the target location : 

• Target Resource Group, where the Azure VM will be created.

• Target VNet and Subnet for the Azure VM.

• An isolated network to perform test migration.

Below are some of the useful links which you need to refer to list down all the requirement. Please research it well and gather all the requirements before you setup your Azure Migrate Project.

Create Azure Migrate Project

An Azure Migrate Project is the topmost hierarchy of the migration solution. It stores all metadata related to the migration such as discovery and assessment data.

In order to create an Azure Migrate project, you must have an Azure Account.  

You can create more than one Azure Migrate project within an Azure subscription. Within a single project, you can configure migration from different sources such as VMware, Hyper-V, Physical and others.

You can create Azure Migrate project in certain Geographies. However, that geography selection is only for storing metadata which are gathered from on-premises VMs. You can select any target region for migration, which is irrespective of your project location. 

During the Azure Migrate Project creation, you will get options to select the Server Assessment tool and Server Migration tool. You can select the tools while creation a project, or you can skip it and do it later. 

Please refer this article for more details.

Machine Discovery and Grouping

Once you create an Azure Migrate project and add Server Assessment tool, the next phase is machine discovery. In this phase, machines from on-premises will be discovered and added to Azure Migrate project. 

**For machine discovery and assessment, you need to deploy Azure Migrate appliance. **

Azure Migrate Appliance

Azure migrate appliance is used for following scenarios :

  

• To discover machines at source.
• To collect machine metadata (Name, configuration, disk etc)
• To collect performance metadata.
**• To replicate and migrate source VM (Only for agent-less migration)

**

For VMware VMs, the appliance performs some additional function which includes : 

• Discover applications running on the VMware VM (agent-less)
• Discover machine dependencies
• Replicate VMware VM to Azure  

As mentioned before, Azure Migrate offers agent-less migration for VMware VMs. This replication is being orchestrated by Azure Migrate appliance.

For more information, please refer Azure Migrate Appliance Architecture document.

Replication Appliance

There is another component called Azure Migrate Replication Appliance, and it is easy to get confused between Azure Migrate Appliance and Azure Migrate Replication Appliance. 

Azure Migrate Replication Appliance is used in agent-based migration. Replication Appliance has no role to play in agent-less migration.

For agent-based migration, the assessment is being done using Azure Migrate Appliance but replication and migration is being done using Replication Appliance.

For more information on replication appliance, please refer this link. 

Appliance: Important Points

• For agent-less migration, the same appliance is used for assessment , replication and migration.

• For agent based migration, the Azure Migrate appliance is used only for assessment. For replication and migration, you need Replication Appliance.

• Appliance OS is Windows Server 2016, which comes with 180 days of free license. Once the license expires, you can activate the license or create a new appliance. 

• Appliance needs Internet connectivity, either directly or through proxy.

• For VMware, you need VCenter server to use the Azure Migrate Appliance. The mapping between Vcenter and appliance is one-to-one, which means you have to deploy separate Azure Migrate Appliance for each VCenter.

• For VMware, you have to download an .OVA file to deploy the appliance, which will run under an ESXi host. The appliance communicates with vCenter server over TCP port 443. 

• For Hyper-V, you have to download a zipped folder with .VHD file to deploy the appliance, which will run under a Hyper-V Host. The appliance communicates with Hyper-V host over WinRM ports 5985 (HTTP) and 5986 (HTTPS). 

• For Physical servers and other sources, you have to download a zipped folder which contains PowerShell scripts to setup the appliance. In this case, you can run the appliance in a dedicated physical server or within a VM. 

• Irrespective of the source (VMware, Hyper-V or other), the appliance sends collected data from on-premises to Azure over SSL port 443. 

• For on-premises to Azure Migrate connectivity, the appliance can use Internet or ExpressRoute with Public / Microsoft peering.

• For more information on Azure Migrate appliance, please refer this link.
• To setup appliance for VMware, please refer this link.
• To setup appliance for Hyper-V, please refer this link.

Dependency Visualization

Before you migrate servers to Azure, you must need to know the inter dependencies between those servers to decide what all servers you need to migrate together. 

  

Dependency Visualization would help you to visualize and understand inter dependencies between servers. This will help you to migrate related servers together and will help you avoiding any unwanted outage.

Dependency visualization can also indicate whether a server is actually being used or not. If you see no inbound and outbound traffic over a period of time, chances are high that the server is not serving any purpose and might be decommissioned, instead of migrating to cloud. At least , you can shut down the server for a period of time and see whether this is causing any outage.

Create Dependency Visualization

To create Dependency Visualization , you need to perform following steps: 

a) Associate a Log Analytics Workspace with the Azure Migrate Project : The Workspace and the project should be in same subscription. Also, the workspace must reside in East US, Southeast Asia, or West Europe regions. Workspace in any other region cannot be linked to Azure Migrate project. In addition, the workspace must reside in a location where Service Map feature is supported. 

b) Install MMA Agent : This need to be installed in each Windows and Linux machine , for which you are planning to analyze the dependency. While installing the MMA agent, you need to attach it with the Workspace ID and Workspace Key, which you will find in the portal. 

c) Install Dependency Agent : Finally, you need to install dependency agent in each VM. 

The Log Analytics Workspace which you will create here is used to store all the dependency logs which are generated by VMs and captured by the service map.

Analyze Dependency

You can view the dependency from below locations:

1) From Azure Migrate Console :

Azure Migrate: Server Assessment > Discovered servers > Dependencies > View dependencies (for each VM)

Here you can view the inbound and outbound connections to and from the VM. This will help you to identify inter-dependent VMs which are talking to each other over certain ports, and therefore you can create a group consisting those VMs.

2) From the Workspace :

You can also query dependency data in the Log Analytics Workspace. Based on your requirement, you can create your query.

For more information on dependency visualization, please refer this link. This page also contains some sample Log Analytics queries.

Create Machine Groups

Machine groups are created to assess and migrate related machines together. You can run assessment against a machine group.

There are two ways you can create a machine group :

1) If you already know the inter dependency, you can create a group manually. For example, there is an application which has five servers associated with it, and you know that all these five servers need to be assessed and migrated together. So you can manually create a group with these five servers.

2) If you do not know or not sure about the inter-dependency, you can use Dependency Visualization to create a group.

For information on machine groups, please refer this link.

Server Assessment

Server Assessment is one of the most crucial step of Azure Migrate. A proper assessment would ensure a smooth migration, with minimum or no business impact post migration.

**It is important to note that you cannot run an assessment against a VM, but you have to run assessment against a machine group. **
**
**

Assessment Properties

When you create a server assessment for a machine group, you can set following properties :

• Target location : You can specify only one target location per assessment

• Target disk type : Automatic / Standard / Standard SSD / Premium SSD.

• Reserved instances : 1 year / 3 years / No reserved instances.

• VM sizing criteria : Performance based / As-on premises.

• Performance history (number of days) : Applicable only if we have opted performance based analysis.

• Performance utilization : This is used for right sizing the target VM. Applicable only if we have opted performance based analysis.

• VM series : You can select what all VM series will be allowed for target VMs which are part of this assessment. You can select multiple series.
  
• Comfort factor : This is a buffer which is used during assessment. To put it simple, the more comfort factor you are putting, the more buffer you are creating in terms of CPU, memory, Disk and Network utilization.

• Pricing : There are few options related to currency, offer, discount and VM uptime.
  
• Azure Hybrid Benefit : Specify whether you would like to leverage Azure Hybrid benefits.

Assessment Type

As mentioned in the previous section, you can select any one of the below two assessment types. As this is one of the crucial selection, we will discuss this in detail. 

1) Performance Based : This is the default and recommended assessment approach. The assessment tool will collect and analyze CPU, and Memory utilization of the on-premises server, and based on that will recommend Azure VM size.  

Azure VM Disk type (Standard or Premium) will be determined by analyzing on-premises VM Disk IOPS and throughput. 

When you select performance based option, you also need to define how many days of performance history it will analyze. It will collect the performance the from the Log Analytics Workspace, which we have setup during dependency analysis phase. 

Following are some of the best practices for creating performance based assessment : 

a) Once you discover a VM, do not run performance base assessment immediately as gathering performance data is time consuming. If you want to analyze performance data for last two weeks, you need to wait for at least two weeks after the machine is discovered in Azure migrate. If you do not give adequate time to gather required performance data, your analysis will not be comprehensive and you will not get five star confidence rating. 

b) Assessment data is not updated automatically, so it will become stale over a period of time. To generate latest assessment data, recalculate the assessment. 

2) As on-premises : In this approach, there will be no performance data analysis, and Azure VM size will be determined by based on the on-premises VM configuration. Azure VM disk type will be taken from the assessment storage settings. 

Assessment Output

Once an assessment is complete, you will get below information which you can review : 

  1. Azure Readiness : Whether the VM is suitable for migrate to Azure. For example, if the VM is having encrypted disk at on-premises or EFI BIOS, you cannot migrate it with Azure Migrate. So this section does some kind of compatibility check.
  2. Monthly Cost Estimation : This will give an overview of compute and storage cost for running the VM in Azure.
  3. Monthly Storage Cost Estimation: This view shows the aggregated storage cost for the entire machine group.

Once you click on any of these views, you will get more detailed option using which you can drill down further and get an in-depth picture. 

Confidence Rating

When you run an Azure Migrate assessment, you get a confidence rating in a scale of 1 to 5. 

**A higher confidence rating generally indicates a more reliable and comprehensive assessment. A lower confidence rating indicates that the performance data which is captured is either not adequate or stale. **

To increase confidence rating, you need to generate more number of data points over a period of time. 

You can refer below Microsoft documents to get more information on server assessment : 

Replicate Servers

Once the assessment phase is complete, you need to replicate servers to Azure before you migrate it.

  

Before you start replication, you have to ensure that the target region is ready with VNet/Subnet and target resource group.

As we have already discussed, for an agent-based migration, we need to deploy Replication Appliance to do the replication and migration. 

For agent-less migration, replication and migration is taken care by Azure Migrate appliance. 

You can use Internet or Azure ExpressRoute to replicate on-premises servers to Azure.

Here are few recommendation for server replication: 

  • When you start replication for multiple servers, always keep the network bandwidth in mind.
  • If possible, do not start replication of large number of servers at the same time. Try to run them in small batches.
  • Even after the replication is complete, you can change the target resource groups and network settings during actual migration. But you cannot change the disk type. So please carefully select target disk type before replication. 
  • Initial replication takes time to finish, depending on disk size and network bandwidth. After initial replication finishes, delta replication begins. Incremental changes to source disks are periodically replicated to the replica disks in Azure.
  • You can monitor the replication status from the 'Replicating Servers'  console under Azure Migrate Server Migration.

For VMware and Hyper-V agent-less migration, when you perform replication for the first time in an Azure Migrate project, it will create following resources in the Azure Migrate Resource Group. For more details please refer this link. 

1) Service Bus
**
2) Gateway Storage Account

  1. Log Storage Account

  2. Key Vault**

Test Migrate

This is an optional step, but if you are going to migrate a set of critical server hosting some complex application, this step is recommended.

The purpose of the test migration is to assess the potential behavior of the server and application functionality before the actual migration.

Few important points regarding Test Migration : 

  1. You can do test migration, once initial replication is complete.
  2. Unlike Actual migration, when you perform the test Migration, the source server does not power off and is still accessible to business.
  3. **For this reason, make sure the hostname or any other parameter of the test server will not be conflicted with the source server. **
  4. When you test migrate an Azure VM, it will add a suffix -Test with server name in Azure VM . However,  ensure that the name within OS is different than the original server, to avoid any potential conflict.
  5. Always reserve a separate and isolated VNet for test migration. Do not use a VNet for test migration which you are going to use for actual migration. Keep the VNet isolated and do not peer it with any other Azure or on-premises VNet.
  6. When you do the application testing at cloud, make sure the production database is not getting updated at on-premises. Be careful about source database.
  7. Once your testing is done, the clean up the test server using Clean up test migration button. You can take VM disk snapshot before that, if you think you need to refer this in future. 
  8. You cannot initiate actual migration, unless your test migration VM is cleaned up.

Migrate

Its now time for the actual cut over. We have divided this activity in pre and post migration sub activities.

Pre-Migration Activities

Before you perform actual migration of server(s), please perform below steps:

  • Notify stakeholders and take downtime from business. Always keep some buffer when you take the downtime, which should also include time to roll back in case required.
  • Do a pre-migration check. For windows server, ensure you have local admin access to the server which might be required post migration.
  • Perform a final on-premises backup before migration, both for application and database.
  •  If you are migrating both application and database, please maintain the sequence. Before migration, stop source database or make it read-only. 
  • ** Make sure that replication state is healthy**, and there is no warning. Any issue in the last replication can lead to migration failure.
  • Make sure the target VM size, Network and Resource Groups parameters are correct. If not, you can change it before migration.
  •  It is a good practice to check the migration appliance health and Internet connectivity before you initiate the migration. For agent-less migration, it is Azure Migrate appliance. For agent-based migration, it is Replication Appliance (Process Server).
  •  If Network Security Group (NSG) is implemented, make sure it has RDP for Windows Server or SSH for Linux server is allowed.

Remember, once the migration is complete, you cannot delete the target server and re-migrate it. If you want to do so, you must start the replication from scratch. However, if the migration fails from some reason, you can initiate migration again. 

Ideally, you should maintain a pre and post migration checklist to ensure that you do not miss any point. 

Once all the pre-migration checks are green and downtime starts, you can initiate migration. As mentioned before, if you are migrating an application server, please stop source database before you initiate migration. 

During migration, you will get an option to shut down the source server, and ideally you should select Yes to shut down the source server. If Azure Migrate cannot shut down the source server due to any reason, you have to shut it down manually. 

Post-Migration Activities

Once the server is successfully migrated to Azure, you should perform following basic checks :

  • The server and associated resources (Disks, NICs) are in correct Resource Group. If not, move it to correct Resource Group.
  • You are able to login to the server using local admin / root and domain (if applicable) credential.
  • All required services are running.
  • All drives / Volumes and data are intact.
  • Any critical event in event viewer. Once this basic checks are complete, it is time for post migration activities. The actual list of activities will depend on the target environment, but we have captured following high level steps which are essential for any environment :
  • Before you perform any activity on the migrated VM, first take snapshot of all the disks. Start post migration activities only when the snapshot is complete. This will ensure that if anything goes wrong during post migration, you can at least come back to this point and you do not need to replicate and migrate the on-premises server again.
  • Uninstall all on-premises agent which are no longer required. This might include backup, monitoring, patch management agents.
  • If you have migrated a VMware VM, then uninstall VMware tools.
  •  If you have installed Dependency Agent and MMA agent on the on-premises server before migration (for Assessment), please uninstall both.
  • Before you install any component or extension on Azure VM, first install Azure VM agent. This agent is necessary to enable communication between Operating System and Azure. Once the Azure VM status will show as Ready in the portal, you can start installing other agents.
  •  Install additional agents / extensions depending on the requirement. This might include Azure Backup Agent , ASR Agent, Dependency Agent, MMA agent.
  •  When you enable backup of your Azure VM (either through Azure backup or through any third party service), initiate the first backup. Make sure that the VM is attached to the correct backup and retention policy.
  • Check CPU, Memory, Disk and Network performance for some time to ensure that the VM has been right sized. However, this requires to be monitored for next few days to draw final conclusion about VM sizing.

Once all the post migration activities are complete, hand over the server to application / testing team. If it is an application server, make sure that it is connecting to the correct database. 

Summary

In this article, we have gone through an overview of the Server Migration solution which is offered by Azure Migrate. We have used Azure Migrate Server Assessment and Migration tool, which is offered by Microsoft at no extra cost. 

As you have observed, migrating a server from on-premises or from non-Azure environment to Azure is a step by step process, which requires detailed and careful planning. Without proper planning, your server might be migrated to Azure but post migration end users and business might face lots of issues. Therefore, when you plan for the migration, please involve all the stakeholders, application team, DBA, network team and all relevant parties. 

Also, make sure you have latest backup at source before the migration (including app and DB) and take another backup / snapshot at Azure just after the migration. Please take sufficient downtime which include roll back time. in case required.

See Also