In summer of 2014, Microsoft acquired a company called InMage Systems that specialized in building enterprise-class Disaster Recovery (DR) products supporting a wide range of platforms and operating systems. Soon after the acquisition, InMage’s flagship product for site-to-site and site-to-hoster DR became part of Microsoft Azure Site Recovery (ASR). We followed this up with the preview of Microsoft Migration Accelerator– a service based on InMage technology that enables our customers to quickly and easily migrate their workloads into Microsoft Azure with the least amount of downtime.
Fundamentally, all current offerings leveraging the InMage replication channel are based on the same underlying architecture. The core components involved are:
- Configuration Server– VM running at the secondary site that is responsible for maintaining replication policies, replication status, and health reports.
- Master Target– VM running at the secondary site that acts as the repository for all replicated data and change journals.
- Mobility Service – Light-weight software component that captures data changes being generated on the protected workloads continuously, in real-time and directly from memory, for replication purposes.
- Process Server– Gateway residing at the primary site that handles all compute and IO intensive aspects of replication.
This blog post provides guidance on sizing and placement of the Process Server component for users implementing ASR with the InMage replication channel or Migration Accelerator the very first time.
What is a Process Server?
The Process Server is a gateway appliance residing at the same location as primary workloads that are being protected. It can be deployed on a physical or a virtual machine running Windows Server 2012 R2. It is responsible for receiving data changes from the primary workloads, performing compression, encryption, caching and bandwidth management, before replicating to a secondary location for DR purposes. This approach off-loads all compute and IO intensive tasks involved in continuous replication to the Process Server, thereby eliminating nearly all overheads on the protected workloads.
Process Server Placement
As a thumb rule, to obtain maximum benefits of InMage’s host off-load architecture, always provision the Process Server at the same location as your primary workloads being protected. This will ensure that compute and IO overheads on the primary workloads are nearly non-existent.
Process Server Sizing
In general, Process Server sizing depends on the daily change rate across all protected workloads. Sufficient compute is needed to perform tasks such as inline compression and encryption. You also need to ensure that you provision sufficient cache storage in the event of a network bottleneck or outage between primary and secondary sites. The table below provides a good guideline to follow, especially when implementing ASR with the InMage replication channel, or Migration Accelerator the first time.
| Data Change Rate | CPU | Memory | Boot Volume Capacity | Cache Disk Size | Total Disk Throughput Required | NIC Details |
| Up to 300 GB/day | 4 cores | 8 GB | 40 GB | Minimum of 400 GB | 15 – 20 MB/s | 2 x 1 GigE with Static IP |
| Up to 700 GB/day | 8 cores | 16 GB | 40 GB | Minimum of 790 GB | 34.9 – 46.6 MB/s | 2 x 1 GigE with Static IP |
| Up to 1 TB/day | 8 cores | 32 GB | 40 GB | Minimum of 790 GB | 51.2 – 68.27 MB/s | 2 x 1 GigE with Static IP |
IO on the cache disk is typically large and sequential. In order to achieve required throughput, spindle count behind the cache disk tends to be more important than capacity. If your Process Server is being provisioned on a physical machine, it is recommended to provision the cache disk/LUN from a FC or iSCSI storage array with wide striping to obtain sufficient spindles. If your Process Server is being provisioned as a VM, you may not have to do anything special, besides ensuring the virtual disk for cache resides on a block or file based datastore originating from a SAN. For change rates over 1 TB/day, it is recommended to scale out by deploying additional Process Servers as needed. This will be elaborated further in a future blog article that will go over profiling and capacity planning.
Other Considerations
Since replication occurs over IP networks, the Process Server will require a few inbound and outbound ports to be open. Inbound ports include 9080 or 9443 for data transfer from source and target entities; and outbound ports include 80 or 443 to the Configuration Server to provide real-time updates on replication status and health. For connectivity between the components in primary and secondary sites, you can either use a secure site-to-site VPN tunnel or the public Internet with NAT IP for one of the interfaces of the Process Server. A complete view of ports required for deploying Migration Accelerator can be seen here.
Summary
In summary, sizing and placement aspects of provisioning a Process Server for ASR with the InMage replication channel depend on a couple of factors such as number of protected workloads, and daily change rate. For best results, it is recommended to follow the guidelines provided in this blog post. For further questions or comments, check out the Azure Site Recovery forum on MSDN. To learn more about Azure Site Recovery and our ability to protect VMware and Physical workloads, check out our step-by-step documentation. You can also sign-up for a free Azure Trial to get started with Azure Site Recovery.