If you are using or intend to use Microsoft’s Recovery Services to protect your infrastructure from disasters, it is important to understand the workloads Microsoft officially supports and some specific characteristics of each one of them. Before that, a summary of supported workloads (on-prem to Azure):
Active Directory (AD) is the base for authentication for most Microsoft and 3rd party applications. As such, in a disaster scenario, where you have to failover your environment, Active Directory (and DNS) often, if not always, the first component to be failed-over.
Most companies will have more than one Domain Controller and DNS servers in their environment. Some will even have a hybrid environment with one or more DCs already present in the cloud. Depending on which scenario, you can have different approaches:
A special consideration is needed when your DNS servers are not installed in the same machines as the Domain Controllers. In case of a test fail-over, you might be able to create a new VM out of an existing DNS VMs (the same way as above) or have one of the DNS servers to be replicated to Azure using ASR.
There are some cost considerations: when you have VMs running constantly in Azure, you will incur in Compute costs. If you have machines being replicated, compute costs will only happen when you have them up. However, there is a fixed cost per VMs to be replicated.
Similarly to Active Directory, many modern applications leverage a database backend to provide their functionalities, making the SQL availability a critical component for business continuity. SQL already has some great technologies in itself to help with HA/DR scenarios like Clustering, Mirroring and Availability groups. Azure Site recovery will integrate with some of those technologies to provide the best experience.
The first aspect to be analyzed is in regards of the type of the basic setup of SQL Server. Depending on each scenario below, the technic to enable protection will be slightly different. Independently of which version, ASR will protect VMs in Hyper-V or VMWare, as well as physical servers. The supported implementation options are thoroughly described in this article from Microsoft. However, a few highlights are worth mentioning:
Considering the complexity SharePoint environments may have, one won’t find strange to have a specific document for that. SharePoint relies both on Active Directory+DNS and SQL. Hence, the first part of the complexity. Additionally, there are different server roles to be protected.
With that, let’s review some highlights:
Please review the technical guide for SharePoint thoroughly to guarantee the functionality.
Microsoft supports already supports many complex technologies as well as the basic building blocks of IaaS in its Recovery Services, as we can per the table in the beginning of this post. The technology behind it solid and flexible, allow for the customizations and automation required for a great experience when failing over. However, building this initial plan may still be a hard and time consuming task, since we may be dealing with complex technologies, many moving parts and possibly many customizations that will require testing. For that, make sure you invest most of the project time in getting the best analysis and plan, with the best analysts and technical resources you can get. This will sure guarantee some good nights of sleep knowing you have a planned for the worst.