In my previous blogs I’ve highlighted how Microsoft Azure Site Recovery technology keep on improving everyday. Overall Microsoft Azure keep on adding new features frequently and keeping the phase with that is somewhat difficult as well
Azure Site Recovery is such area Microsoft has been keep on improving to provide Disaster Recovery solutions to customers across the business segments. With the acquisition of the Image Scout who specialize in the disaster recovery solutions Microsoft expand their portfolio of DR options. Now ASR can provide support to protect VMware sites and physical machines as well. Current option are as follows,
1. VMware Site A to VMware Site B orchestrated DR failover via ASR
2. Protecting Physical machines from Site A to Site B orchestrated DR failover via ASR
3. Migrating VMware and Physical servers to Azure using Microsoft Migration Accelerator (Which use Image technology)
Microsoft leveraging Image technology as it is without much modification at this stage. Main components and function model of Image Scout is as follows,
- 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.
Base on the VM’s, physical machines capacity you need to size the PS (Process Server) & MT (Master Target) servers accordingly. PS server will be holding all the data which is need to be replicated to the Azure side.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.
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.
Replication of the data will occur over IP network. This can be via Site to Site VPN between onsite and Azure or via the public internet. 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.
n 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. In future you’ll find more exciting news from ASR team on their improvement for the Disaster Recovery with combination of Image Scout