Organisations need a business continuity and disaster recovery (BCDR) strategy to keep workloads and data safe and available during planned and unplanned downtime, and recover to regular working conditions as soon as possible. Site Recovery is an Azure service that contributes to your BCDR strategy. Using Site Recovery, you can deploy application-aware replication to the cloud, or to a secondary site. Whether your apps are Windows or Linux-based, running on physical servers, VMware or Hyper-V, you can use Site Recovery to orchestrate replication, perform disaster recovery testing, and run failovers and failback. Site Recovery integrates with Microsoft applications, including SharePoint, Active Directory, IIS, SQL Server and so on.
Why use Site Recovery for application replication?
Site Recovery contributes to application-level protection and recovery as follows:
- Providing replication for any workloads running on a supported machine.
- Near-synchronous replication, with RPOs as low as 30 seconds to meet the needs of most critical business apps.
- App-consistent snapshots, for single or multi-tier applications.
- Integration with SQL Server AlwaysOn, and partnership with other application-level replication technologies, including AD replication, SQL AlwaysOn, Exchange Database Availability Groups (DAGs) and Oracle Data Guard.
- Flexible recovery plans, that enable you to recover an entire application stack with a single click, and include to include external scripts and manual actions in the plan.
- Advanced network management in Site Recovery and Azure to simplify app network requirements, including the ability to reserve IP addresses, configure load-balancing, and integration with Azure Traffic Manager, for low RTO network switchovers.
- There are no compute, network infrastructure, facility rental, or software licensing fees required during ongoing protection only ongoing costs are for storage required to support the application replicas.
- A rich automation library that provides production-ready, application-specific scripts that can be downloaded and integrated with recovery plans.
What workloads can you protect with Azure Site Recovery?
When you are planning for ASR and question comes what kind of workload is supported by ASR and what kind of planning or prerequisites required to enable replication for workload.
- Protect Active Directory and DNS
Enterprise applications such as SharePoint, SQL, Dynamics AX, and SAP depend on Active Directory and a DNS infrastructure to function correctly. When you create a disaster recovery solution for applications, it’s important to remember that you need to protect and recover Active Directory and DNS before the other application components, to ensure that things function correctly when disaster occurs.
Single domain controller environment- If you have a few applications and only a single domain controller, and you want to fail over the entire site together, then using Site Recovery to replicate the domain controller to the secondary site (whether you’re failing over to Azure or to a secondary site). The same replicated domain controller/DNS virtual machine can be used for test failover as well.
Environment with multiple domain controllers- If you have many applications and there’s more than one domain controller in the environment, or if you plan to fail over a few applications at a time than set up an additional domain controller on the target site (Azure or a secondary on-premises datacenter).
2. Protect SQL Server
Many workloads use SQL Server as a foundation, and it can be integrated with apps such as SharePoint, Dynamics, and SAP, to implement data services.
Standalone SQL Server: SQL Server and all databases are hosted on a single machine (physical or a virtual). When virtualized, host clustering is used for local high availability. You can use Site Recovery to replicate the Standalone SQL Server to the secondary site (whether you’re failing over to Azure or to a secondary site).
SQL Server Failover Clustering Instances (Always On FCI): Two or more nodes running SQL Server instanced with shared disks are configured in a Windows Failover cluster. If a node is down, the cluster can fail SQL Server over to another instance.
ASR doesn’t provide guest cluster support when replicating to Azure. It’s recommended and if you have Enterprise license of SQL 2012/14 than you can configure Always On availability groups with secondary site which provide asynchronous replication with secondary Site.
If you have SQL Server cluster (standard edition/Windows Server 2008 R2) than use Site Recovery replication to protect SQL Server.
SQL Always On Availability Groups: Two or more nodes are set up in a shared nothing cluster, with SQL Server databases configured in an availability group, with synchronous replication and automatic failover. It’s recommended to configure Always On availability groups with secondary site which provide asynchronous replication with secondary Site.
Note- While extending Always On availability groups with secondary site you also need to plan for site-to-site VPN connection and SQL related configuration like update the existing AG listener.
3. SharePoint application
Microsoft SharePoint is a powerful application that can help a group or department organize, collaborate, and share information. SharePoint can provide intranet portals, document and file management, websites, enterprise search, and so on.
The following SharePoint server versions are supported.
- SharePoint server 2013 Standard
- SharePoint server 2013 Enterprise
- SharePoint server 2016 Standard
- SharePoint server 2016 Enterprise
ASR support standalone SharePoint server and SharePoint server farm. You can replicate single server of a farm as well if your all servers are identical same and not have any kind of application dependency with other servers in Farm.
Note- If you are using a shared disk-based cluster as any tier in your application then you will not be able to use Site Recovery replication to replicate those virtual machines.
4. IIS based web application
Various web applications can serve different purposes in an organization. Some of these like payroll processing, financial applications and customer facing websites can be utmost critical for an organization. It will be important for the organization to have them up and running at all times.
Azure Site Recovery provides disaster recovery by replicating the critical components in your environment to a cold remote site or a public cloud like Microsoft Azure. Since the virtual machine with the web server and the database are being replicated to the recovery site, there is no requirement to backup configuration files or certificates separately.
Conclusion- There are number of other workload (Dynamics AX, RDS, Exchange, SAP, File Server, Citrix XenApp/XenDesktop and other too) which is supported by ASR but here I was more focused on these four workloads. This give some idea which kind of workload can be migrated or configured as DR using Azure Site Recovery. I also tried to show which kind of workload not supported AS IS also what workaround available to configure those workload.
Next blog I will go through in planning of ASR where I will try to include what need to consider during planning phase.
You can refer this Microsoft Article for current supported workload.
Cloud DNA 
Super article
LikeLike