we get back again with new interested topic in Azure, today we will discuss about one of the most interested features in Azure ( At least for me ), so in this article we will discuss the concept of azure site recovery (ASR), also in this part and the next one’s we will show the implementation of ASR in details.
Azure site recovery (ASR) concept:
By Microsoft definition: The Azure Site Recovery contributes to your business continuity and disaster recovery (BCDR) strategy by orchestrating replication, fail-over and recovery of virtual machines and physical servers. Machines can be replicated to Azure, or to a secondary on-premises data center.
so in another word, ASR can contribute in many ways to help you to administer the disaster recovery site of your environment, ASR will help you if you have physical servers, virtual machines based on Hyper-v and even if it’s based on VMware.
Keep in mind that ASR is not responsible for automatic fail-over, ASR is supported for manual fail over, we can say it’s a one click fail-over, YES ! just one click and within minutes your DR site will be up and running.
Azure site recover types:
there is many types of ASR, we will mention and do a demo’s for most important types:
Let’s talk about each type in quick overview:
In VMware site to Azure, it’s assumed you have a VMware based virtual machines and you need to protect your VM’s to Azure, in case of disaster or any failure in your on-premise VM’s you can do a fail-over to Azure.
In the scenario of VMware to Azure, if you need to switch to DR site in azure, it’s recommended to turn off your on-premise servers before do the fail-over if the servers is still accessible, since in this type of ASR there is no automatic turn off the local servers like VMM to VMM type.
in VMM site to Azure, it’s supposed you have a virtual machine manager (VMM) managed the hyper-v hosts which hold the VM’s, in this type you can protect your VM’s in Azure as a DR site.
In this scenario, if you fail-over to Azure DR site, ASR will try to turn of the local servers if it’s still accessible.
Now, in physical to Azure site type, it’s similar to VMware to azure site, you can protect your physical servers to Azure as DR site, also keep in mind that ASR will not turn off the local servers automatically in case you switch to azure.
In physical to Azure type, one of the most important limitation of this method at least for now, after fail-over to azure you cannot fail-back again to physical server, you can fail-back to VMware only.
last type you will discuss about, it’s a VMM to VMM site protection, in this method ASR is only responsible for orchestration your DR, this is means you will not have a real DR in Azure, it’s assumed you have two site the main site and the DR one, both sites is based on VMM, in this case you can only manage your DR site from Azure portal.
In this article and next parts we will discuss about VMware / Physical to Azure site, so how ASR protect on-premises resources:
Site Recovery helps protect your on-premises resources by orchestrating, simplifying replication, fail-over and fail-back in a number of deployment scenarios. If you want to protect your on-premises VMware virtual machines or Windows or Linux physical servers here’s how Site Recovery can help:
- Allows VMware users to replicate virtual machines to Azure.
- Allows the replication of physical on-premises servers to Azure.
- Provides a single location to setup and manage replication, failover, and recovery.
- Provides easy fail-over from your on-premises infrastructure to Azure, and fail-back (restore) from Azure to on-premises.
- Implements recovery plans for easy fail-over of workloads that are tiered over multiple machines.
- Provides multi VM consistency so that virtual machines and physical servers running specific workloads can be recovered together to a consistent data point.
- Supports data replication over the Internet, over a site-to-site VPN connection, or over Azure Express-route.
- Provides automated discovery of VMware virtual machines.
Now let’s talk about the deployment scenario for this type of ASR:
In above diagram, it’s shows most of requirements in this deployment type, first of all you need a three additional servers, config server, Master Target server and the process server, Config and Master server should be deployed in Azure, the process server should be deployed on-premise environment and it’s recommended to be in the same subnet of the servers to be protected.
So what is the functionality of each server:
Process Server: this server will be deployed in the on-premise environment, it’s recommended to be in the same subnet of the server need to be protected, simply the main functionality of this server is to talk with the mobility service which will be installed on all VMware VM’s or physical servers, the process server will take the data and make some encryption, compression and caching then send the data to the Master target server. Also this server is responsible of the automatic discovery of VMware virtual machines. for process server sizing, below table summarize it:
This server must be windows server 2012 R2 at least, also it’s recommended to have at least a disk space of 600 GB, since this server will cache all data in case if there is a network connectivity failure between the on-premise and the Azure.
Mobility service will be pushed by process server to all VM’s or physical servers need to be protected. The mobility service will capture all changes made on the servers by monitoring the RAM and send all these changes to process server.
Master Target Server:
It’s deployed in Azure, there is three template of this server available in azure, it can be a windows based or Linux based. simply the functionality of this server to receive all data from the on-premise process server. Both server the config and master one must be in the same virtual network in azure.
For Master Target server sizing, see below Table:
Configuration server: there is no real work on this server, this server is only responsible to manage and coordinate all above mentioned servers, it’s also deployed in Azure. also it’s coordinate the fail-over and fail-back processes.
Config and Master target server must be in healthy state before the fail-over occur, otherwise the fail-over / fail-back will failed, In azure you can setup a notifications to monitor these servers.
Great, Now lets list the available replication mechanisms:
Azure offer three methods for this, below is the methods as mentioned in Microsoft articles:
Over the Internet—Communicates and replicates data from protected on-premises servers and Azure using a secure SSL/TLS communication channel over a public internet connection. This is the default option.
VPN/ExpressRoute—Communicates and replicates data between on-premises servers and Azure over a VPN connection. You’ll need to set up a site-to-site VPN or an ExpressRoute connection between the on-premises site and your Azure network. for VPN setup you can refer to our previous article.
Considerations for the source environment:
- Maximum disk size—The current maximum size of the disk that can be attached to a virtual machine is 1 TB. Thus the maximum size of a source disk that can be replicated is also limited to 1 TB.
- Maximum size per source—The maximum size of a single source machine is 31 TB (with 31 disks) and with a D14 instance provisioned for the master target server.
- Number of sources per master target server—Multiple source machines can be protected with a single master target server. However, a single source machine can’t be protected across multiple master target servers, because as disks replicate, a VHD that mirrors the size of the disk is created on Azure blob storage and attached as a data disk to the master target server.
- Maximum daily change rate per source—There are three factors that need to be considered when considering the recommended change rate per source. For the target based considerations two IOPS are required on the target disk for each operation on the source. This is because a read of old data and a write of the new data will happen on the target disk.
- Daily change rate supported by the process server—A source machine can’t span multiple process servers. A single process server can support up to 1 TB of daily change rate. Hence 1 TB is the maximum daily data change rate supported for a source machine.
- Maximum throughput supported by the target disk—Maximum churn per source disk can’t be more than 144 GB/day (with 8K write size). See the table in the master target section for the throughput and IOPs of the target for various write sizes. This number must be divided by two because each source IOP generates 2 IOPS on the target disk. Refer Scalability and Performance Targets when using Premium Storage while configuring target for Premium Storage account.
- Maximum throughput supported by the storage account—A source can’t span multiple storage accounts. Given that a storage account takes a maximum of 20,000 requests per second and that each source IOP generates 2 IOPS at the master target server, we recommend you keep the number of IOPS across the source to 10,000. Refer Scalability and Performance Targets when using Premium Storage while configuring source for Premium Storage account.
Now, we discussed most important features, Limitations and Sizing of this ASR deployment Type, In Next Article we will start the implementation part, Stay tuned 🙂
Ahmad Yasin in a Microsoft Cloud Engineer and the publisher of
AzureDummies blog. He also hold many certificates in office 365
and windows azure including Developing Microsoft Azure Solutions, Implementing Microsoft Azure Infrastructure Solutions
and MCSA office 365.