Disaster recovery for Azure IaaS VMs

Every organization needs a business continuity and disaster recovery (BCDR)  strategy to keep data safe and react to unplanned or planned outage in the best way. Azure Site Recovery (ASR) significantly simplifies these processes providing replication, failover and failback functionalities for your major IT systems.

azure site recovery for azure vms_6

ASR can be used in the following scenarios:

  • VMware VMs replication to Azure w/CSP (uses InMage Scout software)
  • Physical servers to Azure (uses InMage software as well)
  • VMware VMs/Physical servers to a secondary site (through InMage Scout)
  • On-premises Hyper-V VMs without VMM to Azure (Hyper-V Replica inside)
  • On-premises Hyper-V VMs with VMM to Azure (Hyper-V Replica inside)
  • On-premises Hyper-V VMs with VMM to a secondary site (Hyper-V Replica inside)
  • Multi-Tier applications (uses SQL AlwaysOn AG, for instance)

But yesterday Microsoft officially extended this list by adding possibility to replicate Azure IaaS VMs running on Windows/Linux to another region within the same geographic cluster.

Now, you may ask, why we need this if Azure already provides high-availability and reliability for every business critical workloads. Official statement says that it’s required by ISO 27001 and it’s compliance requirements.

Furthermore if you’d like to be able to completely meet BCDR strategy in the event of disaster and you are not happy with built-in Azure protection features – new option can also help (seamless failover and failback between different regions to keep RTO/RPO very low)

TIP: the following demo was done with public preview version. Currently, this feature is GA and might be some things are bit changed

azure site recovery for azure vms_1


As usual, you need to create ASR vault  and enable replication for workloads. You should place ASR Vault at the TARGET location/region to make it work (wizard also checks it automatically).

It’s simple..if source location is down, ASR vault and resource groups will be also offline and your BCDR strategy will be failed –> ASR vaults should be always in the target region

I‘m using ASR created in UK West region and my workloads are running in West Europe DCs. Regions are in the same geographical cluster (Europe).

TIP: new managed disks and VMs scale sets are not supported + temporary disks always excluded from replication

azure site recovery for azure vms_3

You don’t need to prepare target infrastructure. ASR does almost all “dirty”” work by itself (network mapping, target networks/groups and storage/cache accounts + availability sets if they are in use in the source region) Continue reading “Disaster recovery for Azure IaaS VMs”

TOTD: How to manually move Azure VMs to another subscription

Here is a new tip of the day. We’ll discuss only the Azure Resource Manager. Azure Service Management (ASM or classical) won’t be covered.

Azure portal has a simple built-in tool to migrate resources between subscriptions/resource groups and it’s available under Resource Group – Move

azure move in portal

Or using PowerShell :  Move-AzureRmResource

It’s also well described @MSDN and there are some main limitations that we need to consider:

  • Move in Azure Portal works only for subscriptions/resources groups in the same tenant (the most important!)
  • Not any resources can be migrated. For example, it’s not supported to move VPN Gateway or Recovery vaults. So we need to create and configure the new ones in the target subscription.
  • There are different limitations for ASM (classical deployments) and ARM. Check them before migration.

If the tenant IDs for the source and destination subscriptions are not the same, you can attempt to change the directory for the subscription. This operation requires Service Administrator which sometimes are not available for user. For example, migration from CSP to EA.
In this case, manual migration is required.

To get list of subscriptions and TenantIDs associated with them use PowerShell:

get azure subscriptions and tenants

In this example, the first two subscriptions are in the same tenant and migration between them can be done through Azure portal using Move option.

However, moving resources between the subscriptions “Visual Studio Premium..” and “Microsoft Azure Sponsorship” requires manual migration steps (look at the TenantID..they are different).

So, how to move? It’s quiet simple if you are familiar with AzCopy and Azure PowerShell.

The process of migration consists of several simple steps:

  • Prepare your target subscription (general services like storage accounts and networks)
  • Download and install AzCopy, stop VMs, copy VHDs of each VM to the target
  • Install AzureRM module, create VMs using the copied VHDs
  • Add additional resources such as VPN Gateways/S2S connections and Recovery vaults (optional)

Some details

1) To copy (asynchronously) VHDs use the following command

AzCopy /Source:<Source URI>  /Dest:<Dest URI>  /SourceKey:<Source Key> /Pattern:<sorcevhdname.vhd>

<Source Key>  is one of the access keys (Storage Account – Access Keys or use PowerShell):

List of all storage accounts in the source subscription

Get-AzureRmStorageAccount|Ft ResourceGroupName,StorageAccountName

list of azure storage accounts

List of source storage account keys (example). Use one of the keys value with AzCopy

Get-AzureRmStorageAccountKey -ResourceGroupName <resource group name> -Name <storage account name>|ft -AutoSize

azure storage account keys

To get URIs and VHDs name (Storage Account – Containers – <name of container>):

(Get-AzureRmStorageAccount -Name <stor acc name> -ResourceGroupName <rg name>|Get-AzureStorageContainer|Get-AzureStorageBlob).ICloudBlob.uri.AbsoluteUri

azure uri and vhds

Stop VM or VMs and run copy in AzCopy then. Wait while AzCopy finishes initiated process.

Tip: prepare script for all VMs before stopping them. simultaneous copies are allowed.

2) Open PowerShell ISE with installed AzureRM module, replace values (variables and subID) with yours and run:

#Open new Azure session

#Target subscription details
$sub=(Get-AzureRMSubscription -SubscriptionName "your subscription name" ).TenantId
Select-AzureRmSubscription -SubscriptionId $sub

$rgname = "your rg name"
$vmsize = "required VM size <Example:Standard_A4>"
$vmname = "your vm name"
$locName="location (example:East US)"
$vnetName="Virtual Network Name"
$SubName = "Subnet Name"
$osDiskName = "vmdiskname"
$osDiskVhdUri = "https://destination.blob.core.windows.net/vhds/name.vhd"

#New VM config
$newvm = New-AzureRmVMConfig -VMName $vmname -VMSize $vmsize

#Get virtual network
$vnet=Get-AzureRmVirtualNetwork -Name $vnetName -ResourceGroupName $rgName

#Get subnet
$subnet = $vnet.Subnets | Where-Object { $_.Name -eq $SubName}

#New Public IP
$publicip=New-AzureRmPublicIpAddress -Name $nicName -ResourceGroupName $rgName -Location $locName -AllocationMethod Dynamic

#New nic for VM
$nic=New-AzureRmNetworkInterface -Name $nicName -ResourceGroupName $rgName -Location $locName -SubnetId $subnet.Id  -PublicIpAddressId $publicip.Id

#Update VM config
$newvm = Add-AzureRmVMNetworkInterface -VM $newvm -Id $nic.Id

#Attach copied disk to VM (sample. just one OS disk)
$newvm = Set-AzureRmVMOSDisk -VM $newvm -VhdUri $osDiskVhdUri -name $osDiskName -CreateOption attach -Windows

#Create VM
New-AzureRmVM -ResourceGroupName $rgname -Location $locName -VM $newvm

Verify that VM is running in the target subscription and all disks are attached.

Note: latest AzureRM (3.5.0) module doesn’t output status of VM creation (it’ll be corrected in future releases). Use Azure Portal instead.


How to run synchronous copy in AzCopy?

Place /SyncCopy parameter to the end of the AzCopy command above. It ensures that the copy operation will get consistent speed. AzCopy performs the synchronous copy by downloading the blobs to copy from the specified source to local memory, and then uploading them to the Blob storage destination. It’s recommended to prepare VM in the source subscription and run AzCopy from there to avoid egress cost

Should I pay for traffic during migration?

If you are moving data within the same region, you don’t have to pay for it. It’s free. Additional costs required only for moving data between different regions.

What’s the maximum speed of data transferring?

It depends on VM and storage types. Basically, for standard accounts it’s up to 60 Mb/s. Premium storage accounts can provide throughput up to 200 Mb/s. In the real world throughput can vary widely.
Example: about 1 Tb were migrated in 14 hours between subscriptions with standard accounts, VMs with Ax size and within the same region

%d bloggers like this: