Having a robust Disaster Recovery (DR) plan in place is a key foundation of any IT strategy and risk management approach. Ensuring key services are protected, at a minimum through backup, or cost permitting through some form of replication, is of critical importance. This will help to ensure that, in the event of a disaster, be it small or large, the organisations IT systems can be recovered allowing the business to continue functioning from an IT perspective.
This post will focus on the capabilities provided by Azure Site Recovery (ASR), and how this is a perfect solution to bolster an organisations protection. However protecting yourself from disaster involves a much wider set of considerations, e.g. Backup, Plans, RunBooks, Automation and Replication services. Each of these topics has its own unique considerations and is for another post.
A large number of organisations survive with a single datacentre, or perhaps two but at a single location, mainly because of cost constraints. This leaves those organisations susceptible to many disasters, e.g. natural disasters (flooding, earthquake, fire, etc.) as well as man-made, e.g. electrical failure, collapse, etc. A disaster like this could result in the need to recover to a temporary location, perhaps from backup (with finger crossed that the backups work!), with a lengthy lead time to rebuild and recover systems. This lead time can be the difference between an organisation recovering or suffering serious financial loss/reputation damage, etc. Come in ASR…
Azure Site Recovery (ASR) provides a great solution to help organisations overcome the risks outlined above. Put short, ASR provides a solution that can provide protection and replication of your on-premises (and cloud) based services to ensure they are protected to the Microsoft datacentres. If you are an organisation that only has a single datacentre then this can provide that much sought after secondary/tertiary location. In addition to replication, ASR can also provide monitoring, recovery plans and testing services. As pointed out earlier, ASR can protect on-premises workloads, as well as workloads already in Azure (to ensure they are replicated to another Azure region). Since the focus is on-premises in this post, how does this part work?
ASR supports the replication of services/virtual machines from all key platforms, including Hyper-V and VMware. If you do not use these virtualisation platforms you can use the “physical” agent option which can be installed on a physical server or as an in-VM agent (if using a differing virtualisation platform, e.g. KVM). If you are using the VMware integration, or Physical option, a configuration server is required. The following link provides more detail around the support matrix for replicating these workloads.
Dependent upon the on-premises capabilities, the following Microsoft links provide the architectural details for each configuration:
To get started with Hyper-V, you require an Azure subscription, System Center Virtual Machine Manager (VMM) server, Hyper-V hosts, VMs and appropriate networking. A Site Recovery Vault and Storage Account is configured in the Azure Subscription and the Site Recovery provider is installed on to the VMM server which is then registered into the above vault. The recovery services agent .exe is installed on all Hyper-V hosts (or cluster members). In this configuration, no agent is required on any of the Hyper-V virtual machines as it is proxy’d via the host connection.
Virtual machines can then be replicated as per the associated replication policy (e.g. sync intervals, retention, etc.). Initial sync’s can take time to move the data up to the Azure platform (unless using Import/Export and seeding).
Note: two key questions that come up with clients are as follows:
- Do I need Azure Networking / VPN in place
- Can replication traffic be forced over the VPN?
1) Strictly speaking no, however if you want to provide client access to private virtual machine IPs then the answer is yes. If you have a client/server application that is internally addressed, then that application will need to support IP address change/DNS update and the client will still need a network route to connect to the application. If the application can be made publically accessible then you may have alternatives.
2) In short, no – ASR is designed (like many Azure services) to be publically accessible via a public URI. This means that data is typically sent via HTTPS to the endpoint over the internet. There is some changes you can make if you have ExpressRoute however that is outside of the scope of this post. This may change soon with the introduction of virtual network service endpoints however this is currently preview feature only supported on storage accounts and Azure SQL.
I hope this helps you to understand how ASR can help your organisation, and provide a brief overview of some of the typical considerations and architectures.