In this series of posts, I will walk through Azure Site Recovery configuration in a few different scenarios. The series will cover both SMB/enterprise setups, and multi-tenant setups from a Service Provider perspective.
This first post will cover the basics to get started with Azure Site Recovery, and from there we will dive into the different parts of ASR.
Links to other posts:
Azure Site Recovery – Part 1 – Introduction (this post)
What is Azure Site Recovery?
Azure Site Recovery, or just ASR, is a Disaster Recovery offering from Microsoft Azure. In a world where IT systems is more critical than ever, the requirements for uptime are getting higher and higher. Most companies do backups of their systems, but backups only get you so far. Imagine your datacenter is flooded (this actually happened to a Danish Service Provider 5 years ago), and you do not have a failover location in place.
Not from the Danish Service Provider, but you get the point 😉
You might be able to restore your data from a backup, but you can’t do so until you have servers up and running again, and how will you do that when they’re under water? Flooding is just one example of a disaster – I have personally seen fires bring down parts of a company too.
A disaster recovery solution would have you up and running way quicker, since you will have a secondary location to start systems on. The problem for many companies is that solutions like Azure Site Recovery is often very expensive. You have to invest in compute, network, storage, cooling, power, floor space, etc. Those things are not cheap, especially if do not plan for expansions.
One customer I’m working with have their own secondary location, where the most mission critical systems and data is replicated – this is more than 200 TB now. When they started out, they invested in a huge new SAN, with 150 TB disk space. Since then, they have expanded 2-3 times, and it’s cost them a fortune, because they didn’t plan for those expansions. Failovers to the secondary datacenter is a manual process. There is no automation included, but “everything” is documented (at least they believe it is) so they know what to do.
How can Azure Site Recovery help here? Well, first of we have built-in automation. Parts of this is based on Azure Automation, and requires you to do PowerShell. The failover of servers can also be automated through the use of Recovery Plans. Recovery Plans lets you define groups of servers, and decide the order they should start in. It’s extremely simple to configure, instead of following a document that may not be up to date.
Another way ASR can help reduce costs, is by failing over servers to Azure. Instead of having a secondary location with all the costs that brings, you can leverage the huge datacenters Microsoft Azure provides. For that you will pay a fee per server, which can be found here (look for “Azure Site Recovery to Azure”): https://azure.microsoft.com/en-us/pricing/details/site-recovery/ and you will also have to pay for storage you use.
Don’t be afraid, you’re not required to user Azure as your failover location. If you already have multiple datacenters, you can still leverage Azure to orchestrate your failovers. If you do this, you get all the awesome features such as Automation and Recovery Plans, but data is just replicated between your own datacenters. Azure only receive metadata about your servers, such as names, networking, number of disks and such.
There is different scenarios when configuring Azure Site Recovery. Some people think that only Hyper-V is supported, but you can also use ASR with VMware and physical servers (which will also include XenServer and other platforms, Amazon for example :)).
The official scenarios are:
- Hyper-V to Azure
- Hyper-V/VMM to Hyper-V/VMM
- Hyper-V/VMM to Azure
- VMware to VMware
- VMware to Azure
- Physical to secondary datacenter
- Physical to Azure
See this link for more info:
In this series I will primarily focus on Hyper-V with and without VMM, to Azure.
Depending on the scenario you want to do, there are different requirements. For the scenarios I will do in this series, I have the following requirements:
- Hyper-V 2012 R2
- VMM 2012 R2
- Azure Storage Accounts – to replicate my on-premises data to
- Azure Virtual Network – for network connectivity
For storage, I will need to know how much performance I need, more specifically IOPS and bandwidth. When Azure Site Recovery in Azure Resource Manager (ARM) went GA a few days ago, Microsoft also announced support for Locally-Redundant Storage (LRS), which means we can now use both Standard and Premium Storage Accounts.
When it comes to networking, there is a lot of planning to do. My preferred way to configure network, is to use the same subnets in Azure as I locally, and then change routing for those subnets when I do a failover. You can also choose to use a different subnet in Azure, and change IP addresses when failing over. If you decide to this, make sure you do not have any hardcoded IP addresses anywhere!
The case I want to walk you through is as follows:
Cloudpuzzles Inc. is a company that monitors customer servers with Operations Manager 2012 R2 (SCOM). Cloudpuzzles uses Hyper-V 2012 R2 locally, without VMM. They will implement VMM during this project, as they’re also going to host a few customer workloads, and want to offer self-service to them. Cloudpuzzles have their own Active Directory forest, which is based on two Domain Controllers, running 2012 R2. For SCOM they have a SQL Server 2014 Standard, and the portals for self-service will also use this SQL server.
All of these servers will be protected using Azure Site Recovery, and the scenario will be Hyper-V (with VMM) to Azure.
Whatch out for the next post, where I will walk through Recovery Services Vaults which is used for Azure Site Recovery.