As the pressure increases for companies to "cloud-enable" their business to remain competitive, IT managers are looking for the best way to get their workloads moved from on-premises, or co-located, datacenters to Azure.
Most companies start with a few individual servers and services to gain familiarity with the platform, but still need a way to "lift and shift" their remaining workloads. Some use a combination of PowerShell and Azure Resource Manager (ARM) templates to create the new infrastructure, but are then tasked with the best way to migrate their existing data and configuration.
To migrate servers and data together, with minimal downtime and impact to the business, a tool that does near real-time replication is needed.
That tool is Azure Site Recovery, or ASR.
Primarily known as a tool for protecting servers in the event of a disaster, ASR can also be used to move servers to Azure with relative ease. And with the right planning and preparation, it can essentially be done FOR FREE!
Yes, you read that correctly. Microsoft allows up to 31 days of protection PER SERVER before the charges begin. Simply put, if you can get a server fully migrated in 30 days or less, you will be charged nothing more than the cost of the storage for the data itself. That's tough to ignore.
So, how do we get started?
Step #1 - PLAN!
We've all heard the phrase "Failing to plan is planning to fail" (paraphrased from Benjamin Franklin's original "If you fail to plan, you are planning to fail!").
While I don't think he had server migrations in mind when he coined the phrase, it definitely applies here. Setting up ASR and migrating the servers is fairly simple in the grand scheme of things, but if you don't plan ahead, it can be - and WILL BE - a frustrating experience.
So, what kinds of things need to be considered ahead of time?
- How should I structure my network?
- what will the virtual network address space be?
- how many subnets are needed?
- do I need connectivity back to on-premises?
- what public endpoints need to be exposed?
- What workloads will be migrated?
- Domain controllers/Active Directory/DNS?
- SQL Server?Application/Web servers?
- How much bandwidth can I spare without impacting daily business?
- Will I need to expand the infrastructure/implement high availability in the future?
There are also several limitations to what ASR can currently handle:
- UEFI/EFI drives are NOT supported
- iSCSI and FC Disks are NOT supported
- Static IP addresses on Linux servers are NOT supported
- The Servers must be running 64-bit Operating Systems of Windows 2008 or higher
- Hostnames, Mount Points, Device Names and Windows System Paths should be in English language
- Operating System should be installed on the C Drive
- Drive Letter E is reserved in Azure. If you have servers to be migrated that have Data on the E Drive, then the drive letter needs to be changed prior to migration
- Windows Server Disks should be Basic
- Shared Disks are not supported
- Failover Clusters are not supported
- Administrator rights may be needed to deploy the Azure Agents
- ASR Supports Premium Storage for replicated data, but a Standard storage account is still needed for logging purposes
- All standard Azure Limitations still apply
With those items in mind, be sure to review and fully understand the requirements and prerequisites listed in the ASR Support Matrix.
Step #2 - Migrate and Test
With the planning out of the way, we come to the fun part - setting up the migration.
I won't be going into the fine details in this particular post (keep your eyes open for a related post with that information), and check our webinar presentation at the end of this post where I go into some of the steps for getting servers migrated to Azure.
ASR supports the following scenarios for replication:
- Hyper-V to Azure
- Hyper-V VMM to Azure
- VMWare to Azure
- Physical servers to Azure (failback to VMWare only)
Two additional scenarios that are supported for migrations ONLY are:
- Azure region to Azure region (failback is currently in Preview)
- AWS Windows instances to Azure IaaS VMs
In all of these cases, the steps for setting up migration are very similar.
- Create a Recovery Services vault
- Create storage accounts to hold the replicated data before migration, and the server VHDs after
- Configure the required servers needed for your migration (Hyper-V, VMWare, VMM, etc) and add them to the vault configuration
- Specify replication settings
- Enable replication for the servers you want to migrate
- Do a Test Failover to verify that the servers are working as expected
- After multiple rounds of testing and adjustments, do a planned failover to recover the new VMs in Azure
- Complete the migration for each server
Each of the scenarios has their subtle nuances, but understanding these general steps will help with filling in those specific pieces later.
Step #3 - Protect, Monitor and Improve
Once your servers are migrated and working as expected, there is still more work to be done.
First would be to make sure that the original servers still on-premises have been turned off to avoid any accidental network conflicts. You can then handle decommissioning them as needed.
Next would be to setup backup jobs for the migrated servers. Be sure to take a look at the Azure Backup service for this, which actually integrates with the Recovery Services vault that you just created for migration.
Another recommendation is to setup server monitoring such as that provided by Operations Management Suite (OMS). You can do this by simply going to the Log Analytics blade in the Azure Portal, creating and OMS Workspace, and having Azure inject the OMS agent into your virtual machines to begin the monitoring. Then you can view your system metrics using the OMS dashboard on your computer or mobile devices.
That's a wrap!
That should be enough to get you started on your path to migrating resources to Azure. You can also view the below webinar recording where I give a high-level look at the supported workloads and how ASR works, then I dive deeper and walk through some of the steps needed to get those workloads into Azure. I also explore the Testing and Validation process before finally completing the migration and shutting down the on-premises servers.