Diaxion’s history and heritage was born in the data centre. We have been involved in many data centre migrations both large and small, however we are now seeing more and more data centre migrations to public cloud. For many organisations, the adoption and migration to public cloud offers the opportunity to transform yet there are still perfectly acceptable situations where a direct server migration to an IaaS platform is the answer. For example, the migration of Windows Server 2008 R2 workloads to Azure offered customers extended support for the 2008 operating system allowing further time to transform to newer operating systems.
Where a server migration to IaaS is required, the major public cloud providers offer great tools to assist with the migration. Diaxion recently worked with a customer where Azure Migrate was used to migrate many servers from an on-premises location to their new Azure tenancy. Azure Migrate uses Azure Site Recovery (ASR) technology for many of its features which many customers are already using and are familiar with. The ASR technology offers an easy path for the replication and migration of workloads but what Azure Migrate offers, is a business friendly, analytical view of the expected Azure footprint for the servers and is the recommended tool of choice for migrating workloads to Azure.
This blog series will walk through the process of using Azure Migrate to Discover, Assess, Replicate and Migrate workloads from an on-premises location to Azure with some handy tips and tricks we’ve experienced.
Azure Migrate is compatible with on-premises VMware and Hyper-V virtualised environments or even physical servers. For VMware and Hyper-V environments, after an Azure Migrate project is created in the Azure Portal, a lightweight virtual appliance is available for deployment into the on-premises environment. This appliance can be deployed with no impact to the existing environment but should be performed under ITIL change controls. The Azure Migrate project is created within a valid Azure subscription with the deployed appliance registered to Azure Migrate with unique keys specific to the project. The appliance can be configured to auto-discover the on-premises environment with no outage or impact. The destination hosts / clusters hosting the virtual workloads must be listed in the appliance with valid credentials to locate the servers within the environment. Once the initial Discovery is completed, the discovered servers will be listed in the Azure Migrate project with a set of specific information.
With the on-premises environment now set as Discovered in Azure Migrate, the features of Azure Migrate such as Migration Groups and Server Assessments come into play and this is what sets Azure Migrate apart from ASR.
Migration Groups are a construct to group servers logically. These Migration Groups can be manually created allowing servers that will be migrated together. These servers are typically servers that share a common workload or service such as a multi-tiered application or servers that share a similar business function. If the on-premises information is not detailed enough to build comprehensive groupings, an Azure Migrate feature called “Dependency Visualisation” can be used. Dependency Visualisation does have its own requirements to deploy and can be used in an agent-based mode or agentless mode depending on the on-premises environment. These agents are installed on each VM that requires the Dependency Mapping and are specific to Windows and Linux clients. Dependency Mapping can also use data from Systems Center Operations Manager 2012 R2 or later, if that is currently running in the environment you are working with the MMA (Microsoft Monitoring Agent) does not need to be installed. The agents for Dependency Mapping can all be installed with no impact to the operating system.
The migration group that is created must be linked to a specific discovery source (e.g. the Azure Migrate appliance), each group should have a unique name for the project, and each group will contain the servers that you intend to migrate together.
Server Assessments are another feature of Azure Migrate. A Server Assessment uses discovered data and migration groups to provide analytical data to the customer to help inform the choices available for the migration of servers. A Server Assessment can use two types of sizing criteria, either “Performance based” or “As on-premises”. The “Performance Based” data is based on collected performance data for CPU, memory utilisation and disk data such as IOPS and throughput. The “As On-premises” data matches the on-premises VM size and aligns it to the closest match for Azure VM sizes.
When creating a Server Assessment, there are several properties that can be populated depending on your own requirements, these properties influence the outcome of the assessment. The properties include:
- The target location where you want to migrate the virtual machines into
- Storage information such as the type of disks (automatic, premium SSD or standard HDD),
- Azure Reserved Instance usage
- Sizing criteria to right-size the VM
- VM series that can be utilised
- Cost factors such as hybrid benefit, EA licensing, Azure offers applicable to your subscription, the currency and any discounts that may apply.
Depending on your individual use case, many of these properties will be the same for all server assessments across your set of machines to be migrated.
After the assessment has been created, the output from the assessment describes:
- The Azure readiness of each assessed server, i.e. Whether the VMs are suitable for migration to Azure
- A monthly cost estimation based on the compute (e.g. VM series and size) and storage (disk sizing and performance level)
The Azure readiness describes each VM as ready for migration, ready for migration with conditions, not ready for migration or unknown (if there are issues with data collection). These readiness states are explained in detail with remediation steps where applicable, most of which are easily achieved.
The cost estimation is a very handy set of information that can assist with budgeting and forecasting the future Azure spend. The compute and storage cost estimations are aggregated for all VMs in the assessment.
The Azure assessment can be exported in CSV format to be kept as a point in time record and distributed to the teams involved in the Azure migration process, e.g. operational and finance teams.
And that’s it for Part 1 of this Azure Migrate blog series. The next blog will look at the replication 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.
Part 2 – Replication
Part 3 – Migration
Part 4 – Tips, Tricks and Troubleshooting
