Anda di halaman 1dari 9

DR deployment steps

1) Prepare Azure (subscription, storage, network) -> 2) Prepare on-premises (configuration

server machine, VMware account) -> 3) Create Recovery Services vault -> 4) Set up the
configuration server -> 5) Configure replication settings -> 6) Prepare to deploy the mobility
services agent -> 7) Enable replication -> 8) Test replication and failover.

Failback to production

Fail back is to VMware only, even if you replicate physical servers.

You need a VPN or Azure Express Route between Azure and the primary site.

You need a temporary process server set up as an Azure VM. You can create this when youre ready
to fail back, and delete it after fail back is complete.
The table below helps you with capacity planning.

Component Details

Replication Maximum daily change rateA protected machine can only use one
process server, and a single process server can handle a daily change
rate up to 2 TB. Thus 2 TB is the maximum daily data change rate thats
supported for a protected machine.

Maximum throughputA replicated machine can belong to one

storage account in Azure. A standard storage account can handle a
maximum of 20,000 requests per second, and we recommend that you
keep the number of IOPS across a source machine to 20,000. For
example if you have a source machine with 5 disks and each disk
generates 120 IOPS (8K size) on the source then it will be within the
Component Details

Azure per disk IOPS limit of 500. The number of storage accounts
required = total source IOPs/20000.

Configuration The configuration server should be able to handle the daily change rate
server capacity across all workloads running on protected machines, and
needs sufficient bandwidth to continuously replicate data to Azure

As a best practice we recommend that the configuration server be

located on the same network and LAN segment as the machines you
want to protect. It can be located on a different network but machines
you want to protect should have L3 network visibility to it.

Size recommendations for the configuration server are summarized in

the table below.

Process server The first process server is installed by default on the configuration
server. You can deploy additional process servers to scale your
environment. Note that:

The process server receives replication data from protected machines

and optimizes it with caching, compression, and encryption before
sending to Azure. The process server machine should have sufficient
resources to perform these tasks.

The process server uses disk-based cache. We recommend a separate

cache disk of 600 GB or more to handle data changes stored in the
event of network bottleneck or outage.
Size recommendations for the configuration server

Cache Data
disk change
CPU Memory size rate Protected machines

8 vCPUs (2 16 GB 300 GB 500 GB Replicate less than 100 machines.

sockets * 4 or less
cores @

12 vCPUs (2 18 GB 600 GB 500 GB Replicate between 100-150

sockets * 6 to 1 TB machines.
cores @

16 vCPUs (2 32 GB 1 TB 1 TB to 2 Replicate between 150-200

sockets * 8 TB machines.
cores @

Deploy > 2 TB Deploy additional process servers

another if you're replicating more than
process server 200 machines, or if the daily data
change rate exceeds 2 TB.


Each source machine is configured with 3 disks of 100 GB each.

We used benchmarking storage of 8 SAS drives of 10 K RPM with RAID 10 for cache
disk measurements.

Size recommendations for the process server

If you need to protect more than 200 machines, or daily change rate is greater than 2
TB, you can add additional process servers to handle the replication load. To scale out
you can:
Increase the number of configuration servers. For example, you can protect up to 400
machines with two configuration servers.
Add additional process servers, and use these to handle traffic instead of (or in
addition to) the configuration server.

This table describes a scenario in which:

You're not planning to use the configuration server as a process server.

You've set up an additional process server.
You've configured protected virtual machines to use the additional process server.
Each protected source machine is configured with three disks of 100 GB each.

Cache Data
Additional process disk change Protected
Configuration server server size rate machines

8 vCPUs (2 sockets * 4 4 vCPUs (2 sockets 300 GB 250 GB Replicate 85 or

cores @ 2.5GHz), 16 * 2 cores @ or less less machines.
GB memory 2.5GHz), 8 GB

8 vCPUs (2 sockets * 4 8 vCPUs (2 sockets 600 GB 250 GB Replicate

cores @ 2.5GHz), 16 * 4 cores @ to 1 TB between 85-
GB memory 2.5GHz), 12 GB 150 machines.

12 vCPUs (2 sockets * 12 vCPUs (2 1 TB 1 TB to 2 Replicate

6 cores @ 2.5GHz), 18 sockets * 6 cores TB between 150-
GB memory @ 2.5GHz) 24 GB 225 machines.

The way in which you scale your servers depends on your preference for a scale up or
scale out model. You scale up by deploying a few high-end configuration and process
servers, or scale out by deploying more servers with less resources. For example, if you
need to protect 220 machines, you could do either of the following:

Set up the configuration server with 12vCPU, 18 GB of memory, an additional process

server with 12vCPU, 24 GB of memory, and configure protected machines to use the
additional process server only.
Alternatively, you could configure two configuration servers (2 x 8vCPU, 16 GB RAM)
and two additional process servers (1 x 8vCPU and 4vCPU x 1 to handle 135 + 85
(220) machines), and configure protected machines to use the additional process
servers only.