Azure Migrate – Intro
Azure Migrate allows you to discover, assess, and migrate workloads into Azure quickly using a framework built using the foundations of Azure Site Recovery. Starting out with ASR is a solid and well-built foundation that allows you to replicate a source environment into Azure. Azure Migrate service is built on top of the foundation elements of Azure Site Recovery and provides a highly reliable and rapid method to sync your current data from VMWware, Hyper-V, physical servers on-premise, and AWS into Azure. This can be part of your disaster recovery plan, migration strategy, and migration testing. Azure Site Recovery has often been deployed as a major part of disaster recovery strategies for on-premise or existing Azure virtual machines.
A bit of basic information first. Azure Site Recovery will help you with:
- Console to manage discovery and connectivity to Azure
- Replication from source to Azure
- Azure Readiness Assessments (This is what we will do next!)
- Testing your migration to ensure that you get your VMs in Azure as expected
- Cut-over migration into Azure
Azure Migrate will help you with:
- A central hub to manage discovery, assessment, connectivity to Azure, and deployment
- Integration with tools to help you migrate such as ISV Offerings from Carbonite, Turbonomic, Lakeside, Rackware, and others
- Database Migration Assistant to assess databases, then using Database Migration Service (DMA & DMS) to migrate databases
- Webapp Migration Assistant to assess and migrate web apps workloads
- Movere to assess server workloads
- Use Lakeside ISV tool to assess and migrate VDI (virtual desktop infrastructure) into Windows Virtual Desktop in Azure
- Provides a unified migration platform
It’s fairly evident that Azure Migrate provides a more modern and comprehensive service offering to make migrating workloads a better and easier experience; and in my experience this has been true. There are some cases to still use ASR such as migrating Windows Server 2008 R2 workloads or where you want to use ASR as a disaster recovery tool for data replication. As always, I must place an emphasis on a repeatable and regular testing process for any tool in use for disaster recovery. I often encourage people to change their way of thinking around backups and replication to focus policies and procedures more on restore and validation testing. We can only recover to the last good data set; but we only know it’s good if we test the recovery! The Canadian in me wants to say please, but just test that you can recover, that you can actually use the system and access your data as intended. Ok, enough about that. Next, let’s talk a little bit about what you need to have to get up and running with ASR or AM.
ASR Supported Operating Systems:
- Within AWS:
- CentOS v6.4 – v6.10 and v7.1 to v7.6 for HVM virtualized instances only
- Red Hat Enterprise Linux v6.4 – v6.10 and v7.1 to v7.6 for HVM virtualized instances only – PV drivers not supported
- Windows Server x64 2008 R2 SP1 or later, 2012, 2012R2, 2016
- In General:
- Linux x64
- Linux Red Hat Enterprise v5.2 – v5.11 and v6.1 – v6.10 and v7.0 to v7.7 – – v7.7 is supported from mobility agent 9.29
- Linux CentOS v5.2 – v5.11 and v6.1 – v6.10 and v7.0 – v7.6 — Requires Linux Integration Services to be installed
- Ubuntu 14.04 LTS, 16.04 LTS, 18.04 LTS
- Debian 7, Debian 8
- SUSE Linux Enterprise Server 12 SP1, SP2, SP3, SP4 -Server 11 SP3 – Server 11 SP4
- Note upgrading replicated machines from Server 11 SP3 to SP4 is not supported.
- To upgrade Microsoft suggests disabling replication, upgrade, then re-enable replication after the upgrade.
- Oracle Linux v6.4, 6.5, 6.6, 6.7, 6.8, 6.9, 6.10, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7 running Red Hat compatible or Unbreakable Enterprise kernels v 3, 4, 5
- Windows 7 SP1 x64, 8, 8.1, 10
- Windows Server x64 and x32 2008 SP2 or later – Migration only
- Windows Server x64 2008 R2 SP1 or later, 2012, 2012R2, 2016, 2019 ( Update Rollup 34 or later)
- vCenter 5.5, 6.0, 6.5, 6.7
- vSphere 5.5, 6.0, 6.5, 6.7
- You will need to install the Mobility service (or enable it) on each Windows VM that you intend to replicate.
Installation requirements for Site Recovery configuration server:
- You will need to download the OVF. For physical servers, you will need to setup the configuration server manually.
- CPU Cores = 8
- RAM = 16GB
- DISKS = 3 disks including the OS disk
- Disk 1 = 1 OS set by OVF import
- Disk 2 = 600GB for process server cache
- Disk 3 = 600GB for retention drive
- Operating System can be selected as 2012 R2 or 2016 with the Desktop experience.
- Do not domain join this server – there is no requirement to join the recovery server to your on-premise domain.
- NETWORK = VMXNET3 if deployed within VMWare
- SECURITY = You will need to have ports 443 open for orchestration, and 9443 open for data transport.
- Assessment and Discovery port requirements for VMWare: https://docs.microsoft.com/en-us/azure/migrate/migrate-support-matrix-vmware#assessment-port-requirements
- If you use URL filtering read this: https://docs.microsoft.com/en-us/azure/migrate/migrate-support-matrix-vmware#assessment-url-access-requirements
- Data moved between your recovery server and Azure is secured.
- You will need permissions in vCenter Server to create a VM using an OVA file to deploy the Azure Migrate server.
- You will need to create a designated storage account for ASR.
- Create an ASR or Azure Migrate project
- Once the recovery server is configured you will register that server with Azure in one of the steps.
For more information about migrating AWS instances to Azure see: https://docs.microsoft.com/en-us/azure/site-recovery/migrate-tutorial-aws-azure
For more and updated information about supported operating systems and installation requirements see: https://docs.microsoft.com/en-us/azure/site-recovery/vmware-physical-azure-support-matrix
In the next article, we’ll talk about setting up Azure Migrate to assess your VMWare workloads and get you ready to look at testing fail-overs to Azure.