In part 1, we discussed most important types of azure site recovery, also we discussed the components, limitations and sizing of VMware/Physical to azure site recovery.
In this part and the next one’s we will discuss to prepare for the implementation part of this ASR type and how we can implement a DR solution in Azure (In the Next Article).
in this part, i will consider that you have a VMware environment, and you need to protect your virtual machines in Azure.
How does it 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, fail-over, 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.
1- you need an azure subscription, you can get a free trial subscription following this URL: https://azure.microsoft.com/en-us/pricing/free-trial/
2- You need create an azure virtual network and setup a site to site VPN with azure, we already discussed this before, follow this article: http://azuredummies.com/2015/07/14/site-to-azure-vpn-connection/
3- You need to create an azure storage account, also we discussed this before following this article: http://azuredummies.com/2015/08/02/windows-azure-storage-account/
For Now, The storage account with local redundant type is not supported, so keep in mind when creating the azure storage account to choose Geo-Redundant type.
4- Azure Site recovery vault, we will discuss this in this article.
1- VSphere ESX/ESXi / VCenter version 5.1 or 5.5 with the latest updates.
2- All VM’s must match below conditions before you can protect it:
Below points is from Microsoft Article.
- 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.
4- Operating system Version that is supported (Windows) for now is: Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2 with at least SP1, also the OS architecture should be 64 bit.
5- VM Operation system should installed on C: Drive only.
6- All VM Disks should be basic not dynamic.
7- Operating system Version that is supported (Linux) for now is: Centos 6.4, 6.5, 6.6; Oracle Enterprise Linux 6.4, 6.5 running either the Red Hat compatible kernel or Unbreakable Enterprise Kernel Release 3 (UEK3), SUSE Linux Enterprise Server 11 SP3, the same here: the OS architecture should be 64 bit.
In this article we will deal with windows machines only.
Important Note: Make sure that the remote desktop is enabled on the VM’s need to be protected, since if you don’t have a VPN setup with azure you will not be able to access the VM’s in case of fail-over.
As we discussed in part 1, we need to prepare three additional servers: Config, Master Target and process 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.
So in Next Article we will begin directly the Implementation, 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.