Sizing Bandwidth & Storage for Azure Site Recovery

This post will show you Microsoft’s method for calculating the storage account requirements and replication bandwidth requirements for the DR-in-the-cloud solution, Azure Site Recovery (ASR), for VMware and Hyper-V.

The Challenge

I’ve been asked “How much bandwidth do I need for ASR?” countless times. How long is a piece of string? The bandwidth requirements of any kind of replication system are dependent on several factors; I’ll break these into two phases:

• Synchronization: The first copy of your machines to the DR site (Azure in our case). This typically requires a lot of bandwidth. You can control the actual bandwidth requirements by starting synchronization a few machines at a time. Your bandwidth requirement will then be dictated by how quickly you need the average machine to be synchronized. There isn’t normally much pressure on this phase — the business has probably survived without a DR solution for some time, and they’ll have one in a few days/weeks.
• Replication: This is the phase that will continue until the building burns down! All of your replicating machines will be sending data on a periodic basis to the DR site, so the bandwidth requirements will be dictated by the total rate of data churn.

 

 
Luckily, ASR uses asynchronous replication, so latency is not an issue. You might choose to use a local Azure region for your recovery services vault(s), or you might opt to use a remote region for an additional layer of protection.
Storage is the second variable. Everyone realizes that the amount of storage required impacts the cost of the solution, but few ever thing about storage account performance. ASR supports Standard Storage (HDD) and Premium Storage (SSD) accounts. The other issue is that a storage account has a limit on performance, so you might need to have multiple storage accounts instead of just one. How will you know how many you need, short of sticking a wet finger in the air?

The Official Sizing Solution

Microsoft has shared a process that allows us to scientifically estimate our bandwidth and Azure requirements for an ASR deployment. The process works as follows:

• Scan your on-premises environment to gather information.
• Use that information to populate an ASR capacity planning tool (an Excel spreadsheet).

Scan Your Environment

We need to identify the machines in the on-premises environment, get disk size information, and determine data churn. Both Microsoft and VMware share tools for doing so for their respective hypervisors:

• Capacity Planner for Hyper-V Replica
• vSphere Capacity Planning Appliance

You should run those tools for as long as you can to get a realistic scan of your environment. Then you can use the resulting information to size ASR.

Azure Site Recovery Capacity Planner

The ASR Capacity Planner is a spreadsheet tool that you can use, assuming you have gathered the required data, to size your ASR deployment. The tool works in two ways:

• Quick Planner: If you only have summary information.
• Detailed Planner: For when you have per-virtual machine metrics and want a more accurate sizing.

The Quick Planner is easy to use. You enter:

• Total number of machines to replicate.
• Average number of virtual hard disks per machine.
• Average size of a virtual hard disk.
• Disk utilization average, as a percentage.
• Daily data rate change on average, as a percentage.
• Retention (days).
• Maximum time for an initial synchronization (for a batch of machines).
• The number of machines in an initial synchronization batch.

You get results instantly — note that the bandwidth requirements are for ASR, in addition to whatever other services your business is running:

• Bandwidth required for ongoing replication.
• Bandwidth required for initial synchronization.
• GBs of storage (affecting Azure pricing).
• Number of storage accounts (affecting performance).
• Number of required on-premises “Configuration Servers” for VMware-Azure replication.

Alternatively, if you have detailed per-machine data, you can use the detailed planner. This approach will take more time, but the results will be more accurate.