Azure Recovery Services in CSP: Site Recovery

아티클
04/11/2016

I've already mentioned in my previous post, that Azure Backup and Azure Site Recovery functionality became available in Azure CSP. Previous post was related to Azure Backup, and today I'll talk about Azure Site Recovery.

Azure Site Recovery (ASR) is a cloud service that provides management and orchestration for disaster recovery scenarios.

Here are details regarding ASR pricing:

You are charged for every protected instance (VM) - ~$16 for VM, replicated to non-Azure site (customer's backup DC or service provider DC) and ~$54 for VM, replicated to Azure.
If you use replication or VMs to Azure, then you also will be charged for consumed storage and storage transactions. ASR uses Page blobs on Geo-redundant Storage Accounts (GRS). I recommend to use storage pricing calculator. (UPD: Now ASR works with LRS too. No need to pay extra for GRS if it's not needed!)
If a failover occurred and protected VMs in Azure become activGe, then you also will be charged for consumed Compute resources. In this scenario replication traffic direction will be opposite - from Azure DC to customer's DC. It means that you also will be charged for outbound network traffic.

Available Azure Site Recovery scenarios in CSP

ASR in Azure CSP is a little bit different from ASR in traditional subscriptions. First of all, there is no Backup Vault and Site Recovery Vault anymore. Now there is only one vault called "Recovery Services Vault", which combines Backup and Replication functions.

Here are ASR Scenarios, currently available in Azure CSP:

From my site to Azure #1: VMM
Replicates Hyper-V VMs managed my VMM to Azure using Hyper-V Replica
From my site to Azure #2: Standalone Hyper-V Hosts
Replicates Hyper-V VMs to Azure using Hyper-V Replica, without VMM.
From my site to Azure #3: vCenter
Replicates vSphere VMs to Azure on vCenter-managed hosts using Configuration server (former InMage Scout).
From my site to Azure #4: Physical Machines
Also former InMage based scenario. Simillar to scenario #3, but doesn't use vCenter. In fact - this scenario allows you to replicate any supported Windows Server or Linux server to Azure - no matter is it a VM on KVM or non-virtualized server. Universal scenario.
From my site to another site: VMM
Replicates Hyper-V VMs from primary VMM-managed site to secondary VMM-managed site using Hyper-V Replica.

There are scenarios, that are available in traditional Azure subscriptions, that are not available via Azure CSP (yet?):
1. Between two on-premises VMM sites with SAN Array Replication
Although this scenario is very similar to scenario #5, I assume that you won't be able to configure source and target storage array mapping in the current UI on newAzure portal. I mean this button from the old portal:

Anyway - I don't have any supported storage arrays in the lab, so I can't check it by myself. If you'll be to check it - please, leave information in the comment.

2. Between two on-premises VMWare sites
This scenario allows you to install InMage Scout solution in 2 different VMWare sites and configure replication of VMs and disaster recovery. InMage was acquired by Microsoft in 2014, so currently this solution is licensed via Azure Site Recovery subscription, using the pricing model provided above. But the overall installation and management experience of InMage Scout is very different from other ASR scenarios. Because of that, I suppose, this scenario wasn't migrated to the new Azure Portal.

Also this scenario covers physical servers in one site to VMWare VMs in a backup site disaster recovery. More details about this scenario is available here.

Disaster Recovery to Azure

For all Disaster Recovery scenarios to Azure location, you must use a Storage Account to store replicated VMs data. On the Azure Portal click +New -> Data & Storage -> Storage Account. Specify a Storage Account name and choose:

Deployment mode = Resource Manager (classic non-ARM storage account won't fly)
Performance = Standard (we don't need SSD storage here)
Replication = Geo-redundant Storage (GRS) - because ASR doesn't support LRS storage (UPD: Now you can choose LRS too)
Choose Subscription and Resource Group where your Recovery Services vault is stored
Choose the preferred location. When a disaster will occur, VMs will be launched in this geo.

Also you need to create at least one Virtual Network in Azure region that you will use for DR.

There are some requirements for this scenario that you must remember:

Hyper-V hosts must run Windows Server 2012 R2.
Guest OS in the VM must be supported in Azure, it must be 64-bit.
Max virtual disk size is limited by 1023Gb, this is the current limitation for Azure VMs.
iSCSI, SharedVHDX and FC-attached disks are not supported.
VHDX is supported. Although VHDX isn't currently supported in Azure, Site Recovery automatically converts VHDX to VHD when you fail over to Azure.
VMs with multiple network adapters are now supported.
Generation 2 VMs are supported only if they run Windows Server 2012 R2. Linux on Gen2 VMs is not supported. Also generation 2 virtual machine with OS disk type of Basic Disk which includes 1 or 2 Data volumes with disk format as VHDX which is less than 300GB is supported.

From Hyper-V to Azure without VMM

This scenario allows you to replicate tenant VMs that run on clustered Hyper-V hosts in customer or service provider datacenter (main DC). If a main DC will fail, then ASR will manage the disaster recovery process and launch all protected in a specified Azure datacenter. This is the simplest scenario in terms of deployment. Read the full documentation about this scenario here.

Go to "Site Recovery" menu in Recovery Vault Settings and select "From my site to Azure" and "Standalone Hyper-V hosts" scenario.

Create a new Hyper-V Site:

Then download Vault Credentials for this site:

Download and install Azure Site Recovery Provider (not Agent!) on all Hyper-V hosts that you wish to protect. Use the vault credentials that you've downloaded from Azure portal during the installation process. After that, these Hyper-V hosts will appear on Azure Portal.

Create a Replication Policy:

Associate the Replication Policy with this Hyper-V Site:

OK, configuration step is done. Now we need to add replication for specific Hyper-V VMs. Click +Replicate button and select a Hyper-V Site that we've just created. Choose Resource Manager deployment model (because Classic is not available in CSP).

On the next step you'll see all VMs on all Hyper-V hosts that were found in this site. Choose the VMs that you wish to replicate to Azure.

Specify OS type (Windows or Linux) and select a storage account:

And choose the replication policy:

That's all. Now we can go to "Replicated Items" menu, where we'll see all the replicated VMs. You can check the status of initial replication, which can take some time.

As you see, Azure automatically detects the most appropriate size for this VM. Don't forget to select a desired vNet in Azure, which will be used after the failover:

When everything is done, try to launch a test failover:

From Hyper-V to Azure with VMM

This scenario allows you replicate tenant VMs that run on Hyper-V hosts, managed by VMM 2012 R2, to any Azure location. Also it has integration with Azure Pack. If a main DC (customer's DC or service provider's DC) will fail, then ASR will manage the disaster recovery process and launch all VMs, that were assigned to a protected VMM cloud, in a specified Azure datacenter. Read the documentation regarding this scenario here. It covers classic non-ARM ASR functionality, but the overall approach is the same. Also read this article.

Download the Vault Credentials:

Download and install Azure Site Recovery Provider on the VMM server. If you have a clustered VMM installation, then install ASR Provider on the active cluster node, and install it on all passive nodes after that.

Important note - ASR Provider configuration is applied to a whole VMM environment. It means that you can't use different recovery vaults for different clouds/VMs. So if a service provider wants to use Azure as a backup datacenter, he'll need to use the same Azure subscription to enable ASR for different tenants.

Download and install Azure Site Recovery Agent (not Provider!) on all Hyper-V hosts that a part of a protected Cloud in VMM. All VMs are being replicated to Azure using Hyper-V Replica functionality, so no agents need to be installed inside a VM.

OK, after that your VMM server (or cluster) will appear on the Azure Portal. Create a replication policy, choose VMM clouds that you wish to protect and configure Network Mapping.

Then you need to enable replication for all existing VMs in the protected cloud that you wish to replicate to Azure by clicking "Enable Hyper-V recovery manager protection":

Also you can enable replication for all new VMs by modifying the template or enabling the replication manually during the VM creation:

If you use Azure Pack on the main site, that you can enable replication for VMs by clicking "Enable protection" option in the Plan settings. After that all the VMs in this plan will be replicated to Azure using ASR.

Also you can enable VM replication on Azure Portal:

After all these steps, try to make a test failover VMM cloud to Azure using the procedure, described in the previous scenario.

From any server to Azure

This scenario is called "From my site to Azure: Physical Machines (not virtualized)" in the UI. But in fact you can use it to replicate any Windows Server or supported Linux to Azure, no matter is it a physical server or Hyper-V/VMWare virtual machine. Read the documentation for this scenario here.

This scenario is agent-based, so an agent need to be installed on every VM that you want to replicate (but it can be installed automatically). This is different from Hyper-V/VMM scenarios described above, where the replication is provided on a host level using Hyper-V Replica functionality.

Go to "Site Recovery" menu in settings and choose "From my site to Azure" and "Physical machines (not virtualized)" scenario.

You need to add new Configuration server in your On-Premise environment. This is a re-designed InMage Scout server, which combines former Process Server and Master Target Server roles of Scout (btw, you still can install them manually and add via Azure Portal).

Download Vault Credentials from this page:

Deploy a new VM with Windows Server 2012 R2 in the site, where you want to use replication to Azure. In my case it is a service provider environment, managed by Azure Pack. Logon to this VM as an administrator. Download and launch Azure Site Recovery Unified Setup:

Choose "No", because we don't plan to protect VMWare VMs in this case:

Use your Vault Credentials file:

And wait until the installation will complete:

After that Microsoft Azure Site Recovery Configuration Server wizard will launch. Click "Add Account" and specify a domain user, who have admin credentials on servers, that you with to replicate to Azure. You can change this later by launching this wizard using C:Program Files (x86)Microsoft Azure Site RecoveryHomesvsystemsbincspsconfigtool.exe.

If you plan to replicate Linux servers, that you'll need to add a separate account with root access on your Linux machines.

Then download and install the latest version of Azure Site Recovery Provider (current ASR Provider version, included in Configuration server distributive, was outdated).

Configuration Server will appear on Azure Portal just after the installation:

Create new Replication Policy. Enable "Multi-VM consistency", to be able to replicate servers in groups. Replication across the group members will be consistent (e.g. several domain controllers).

OK, configuration is completed. Now we need to add protected servers and configure their replication to Azure. Prepare Windows Server and Linux machined like is described in the documentation.

After that, go to "Replicated Items" and click "+Replicate".

Add servers that you wish to replicate. That must be accessible via LAN from the Configuration Server.

Wait until the specified servers will be discovered by Configuration Server. Enable "Replicate physical machines together in a replication group" to use replication policies with "Multi-VM consistency" enabled.

Choose a replication policy:

After that Configuration Server will push a replication agent installation on the specified servers. Agent will check if all the requirements are met and start the initial replication.

When the initial replication will be completed, try to launch test failover to check if everything is OK.

From VMWare to Azure

This scenario allows you to replicate VMWare vSphere VMs, hosted in On-Premise environment (customer or service provider datacenter) to Azure. Very similar to previous scenario. Documentation is the same, it is available here.

Go to "Site Recovery" menu in settings and choose "From my site to Azure" and "vCenter" scenario.

Now you'll need to add new Configuration server in your On-Premise environment (if you didn't install it in previous scenario). This is a re-designed InMage Scout server, which combines former Process Server and Master Target Server roles of Scout (btw, you still can install them manually and add via Azure Portal).

Download Vault Credentials from this page:

Deploy a new vSphere VM with Windows Server 2012 R2 in the site, where you want to use replication to Azure. Logon to this VM as an administrator. Install VMWare PowerCLI 6.0. Then install Download and launch Azure Site Recovery Unified Setup:

Use your Vault Credentials file:

And wait until the installation will complete:

Then Microsoft Azure Site Recovery Configuration Server wizard will launch. Click "Add Account" and specify a domain user, who have admin credentials on servers, that you with to replicate to Azure. Also add another account that has access to vCenter server. You can change this later by launching this wizard using C:Program Files (x86)Microsoft Azure Site RecoveryHomesvsystemsbincspsconfigtool.exe. If you plan to replicate Linux servers, that you'll need to add a separate account with root access on your Linux machines.

After that download and install the latest version of Azure Site Recovery Provider (current ASR Provider version, included in Configuration server distributive, was outdated).

Configuration Server will appear on Azure Portal just after the installation:

On the next step you need to add vCenter to the Configuration Server. I think that there is a bug on this step, because in my case UI can't load the available Configuration Server, it can show this message forever:

As a workaround, go back to step 2, choose the available Configuration Server and click "+vCenter" button.

Create new Replication Policy. Enable "Multi-VM consistency", to be able to replicate servers in groups. Replication across the group members will be consistent (e.g. several domain controllers).

OK, configuration is completed. Now we need to add protected servers and configure their replication to Azure. The procedure is similar to the previous scenario. When the initial replication will be completed, try to launch test failover to check if everything is OK.

Disaster Recovery across two sites

As I already mentioned before, currently ASR supports only one site to site scenario - VMM to VMM. Documentation regarding this scenario is available here. In this scenario there are 2 On-Premise sites - main datacenter and backup datacenter. Any of them can be a customer datacenter or a service provider datacenter. ASR manages the disaster recovery processes, but a replication traffic goes directly between Hyper-V hosts using Hyper-V Replica functionality. You can use this scenario to offer DisasterRecovery-as-a-Service in Azure Pack.

To configure this scenario, go to "Site Recovery" menu in Recovery Services vault Settings and choose scenario "From my site to another site":

On the next step you need to add VMM server (or several VMM servers in a cluster) to ASR. Download the vault registration key:

Download and install Azure Site Recovery Provider on VMM servers in both sites. If you have a clustered VMM installation, then install ASR Provider on the active cluster node, and install it on all passive nodes after that.

Important note - ASR Provider configuration is applied to a whole VMM environment. It means that you can't use different recovery vaults for different clouds/VMs. So if a service provider wants to provide "Backup Datacenter" service to a customer and replicates all the VMs from customer DC to his DC, he needs to use the same Azure subscription with the same Recovery Services vault for different tenants.

Download and install Azure Site Recovery Agent (not Provider!) on all Hyper-V hosts that a part of a protected Cloud in VMM (in main on in backup DC). All VMs are being replicated to a backup DC using Hyper-V Replica functionality, so no agents need to be installed inside a VM.

OK, after that your VMM servers will appear on the Azure Portal. Create a replication policy:

Then choose VMM clouds in main and backup datacenter:

Last step in the configuration wizard - map virtual networks in Main DC and Backup DC. This step is optional, but very recommended.

Then you need to enable replication for all existing VMs in the protected cloud that you wish to replicate to the backup site by clicking "Enable Hyper-V recovery manager protection":

Also you can enable replication for all new VMs by modifying the template or enabling the replication manually during the VM creation:

Also you can enable VM replication on Azure Portal:

After all these steps, try to make a test failover VMM cloud to the backup site and check if everything is working right.

ASR Recovery Plans

OK, now when you've deployed, configured and tested ASR functionality for disaster recovery of Hyper-V VMs, vSphere VMs and physical servers from your site to Azure, or from your main datacenter to your secondary datacenter, it's time to feel the true power that ASR gives you with a functionality called "Recovery Plans".

Recovery Plans allow you to configure all the steps that can be needed during disaster recovery failover situations. For example, re-configure network load balancer or change Traffic Manager configuration when a disaster occurs. To create a new recovery plan, go to Recovery Services vault settings and click "+Recovery Plan":

Then you can configure steps for a failover process. You can add your own actions to the process. There are 2 types of actions: Azure Automation Scripts and Manual actions. Azure Automation Scripts are powerful, you can read about some ASR examples here.

You need to have Azure Automation account with a Runbook in the same subscription, where the Recovery Services vault is stored. To create it, click +New -> Developer Services -> Automation -> Runbook.

Manual actions are instructions that you or your colleague should do during the failover. This is a simple text, that guide you through the whole process when a disaster will occur. No so exciting as Azure Automation Scripts though.

OK, that's all for today. Check Azure Site Recovery by yourselves. It is a great cloud service with a great value, and it's great that it became available via Azure CSP. Let's see how Microsoft CSP Partner will use it to provide Disaster Recovery services to their customers.

Comments

Anonymous
April 11, 2016
Great news! Starting this week, Azure Recovery Services (which include Azure Backup and Azure Site Recovery ) are available for all CSP partners. It means that 2 very popular Azure services can be used by customers through the CSP model.
This is what
Anonymous
April 15, 2016
In my previous post I've mentioned, that currently there are significant feature differences between Microsoft Azure, purchased via traditional channels (Direct, Open, EA), and Azure CSP. In this port I'll continue my CSP story and describe Azure
Anonymous
April 29, 2016
Thank you--exactly what i was looking for.
Anonymous
April 29, 2016
Thank you--exactly what i was looking for.
Anonymous
May 22, 2016
What about non CSP members? is there any option to get it.
- Anonymous
  June 02, 2016
  Are you Microsoft partner? Do you have P-seller account?
Anonymous
September 13, 2016
> VMs must be highly available (= run on top of Hyper-V cluster).Are you sure? Haven't found it in docs, nor it seems relevant as Hyper-V Replica shoud be agnostic to the particular configuration.
- Anonymous
  September 13, 2016
  This requirement was removed recently. It was a VMM requirement, not related to Hyper-V Replica. I've updated the text.

다음을 통해 공유