Azure Site Recovery – Your Newest Best Friend
We are living in the age of cloud expansion. Even though some organizations remain dubious of the concept, many are nonetheless adopting the cloud to simplify application deployments or scaling, as well as an investment in the future. Another attractive advantage of the cloud is vendors’ pay-as-you-go model or resources-consumed model, which is great for avoiding big infrastructure investments. Disaster recovery (DR), the process of maintaining offsite copies of data and applications in the event they need to be recovered, is often embraced by companies as a starter cloud service and a way to validate a solution before utilizing it in production.
Organizations select different data recovery solutions depending on their size, the importance of the data, and the need for fast recovery. Some companies select cloud vendors that offer only basic infrastructure for a disaster recovery site. However, other companies choose a fully-featured set of combined resources and services to achieve proper business continuity and to keep applications available even in case of a disaster (human error, ransomware or natural) occurs at a primary location. In this article, we will explore Microsoft’s all-in-one disaster recovery offering—Azure Site Recovery—how to leverage it, and how it stacks up against a competing solution from Amazon.
What is DR?
Before we dive into Azure Site Recovery, let’s consider the concept of disaster recovery in general. Though DR is a common topic in the IT world, it is often mistaken for other similar terms such as data backup. Backup is a widely used IT mechanism, not only among large enterprises but among smaller businesses as well—even consumers.
The primary use case of backup is to use offline copies of data for restoring the information from a certain point in time. Data backup is used primarily in the event of human error or the failure of a certain part of the infrastructure. Typically, data is restored on the same environment as it was running before the problem arose. On the other hand, data backup is often confused with high-availability mechanisms whose goal is to ensure that business-critical services are up and running, or bound to a service level agreement, by shifting workloads among available resources if others fail in the same data centre.
Even though disaster recovery involves similar concepts, it differs from backup and high-availability mechanisms. Disaster recovery is primarily used in organizations striving to keep their services constantly available to end users, in case something catastrophic happens. It should help recover an application and all of its infrastructure and application data or a critical part of it.
Disaster recovery is used when a primary location is completely unavailable for recovery at given point in time, despite having cold backups of data. This is achieved by establishing the ability to fail over to a full copy of your environment at a remote site. The replicated entity should be ready for failover, and take over in case of an outage in the production site.
In ideal circumstances, you deploy a solution that can intelligently replicate data, be monitored, and be tested as secondary environment on a regular basis. Most importantly, it should have a defined Recovery Time Objective (RTO) and Recovery Point Objective (RPO), and the recovery should be orchestrated if something goes wrong at the primary location.
Although it is possible to independently build a physical secondary site like this — and many organizations have historically implemented such options in colocation facilities — most organizations currently consider utilizing a cloud-based solution instead. The primary advantage of using cloud-based DR is avoiding large investments in hardware, supporting software licensing and maintenance, while still getting enterprise-grade features and out-of-the-box RTOs and RPOs. This will save time on developing a DR mechanism, allowing you to focus on your data and applications.
Azure Site Recovery and Disaster Recovery
So you decided to use a cloud platform to protect workloads and be prepared for a disaster (human or natural) failure at your data centre? Now it’s time to consider Azure Site Recovery, and how it can be utilized efficiently.
The first game-changing advantage of Azure Site Recovery over the competition is that it’s a technology-agnostic solution. This means that you can easily replicate Hyper-V, VMware or even physical server-based workloads regardless of whether you are running them as standalone hosts or clusters, or whether they are backed up by simple or advanced storage systems. By comparison in AWS, you must bring data to the cloud using cold backup to cloud storage and develop way to recover independently.
While running in the background, Azure will automatically convert machines to Azure Virtual Machines on the fly, so no additional configuration or administrative overhead is needed from the customer. Azure Site Recovery uses Azure IaaS to host replicated machines, so you can count on full support for Linux, Windows and specific enterprise workloads like SAP.
Additionally, you do not need to establish and maintain dedicated tunnels to Azure in order to replicate data if you do not want them; replication is performed over the Internet using highly secure connections and session keys managed by Azure itself. Of course, the solution is sensitive to possible bandwidth issues, so it can be tuned and throttled during working hours. In an advanced scenario, you can choose to replicate data over ExpressRoute, an enterprise-grade direct connection from your data centre to Azure.
Options for Replication
Once you define which workloads to protect, it’s time to consider replication parameters. In Azure it is possible to define parameters like replication interval, failover virtual machine type, scale, and network configuration. This way, the machine has the whole configuration before it needs to start, thus eliminating time needed to trigger mandatory procedures you would have if you were operating in AWS.
You can send initial replicated data over a network, or even choose to send data on physical disks to Microsoft to prevent a large replication job from disrupting your internet uplink. On top of that, you can use compression during replication and define copy frequency in intervals as short as 30 seconds —which is amazing in terms of RPO goals — while actual numbers on the AWS side are a bit unclear and unspecific.
In addition, you can configure the number of recovery points-in-time, and the frequency of an application-aware snapshot. This is a great feature because it allows you to both replicate your virtual machines to Azure, and to ensure that you’re covering the crucial step of a consistent application state. This is extremely important in enterprise environments for applications such as SQL Server or Exchange Server.
Options for Failover
In the event of disaster, a failover process is initiated to get replicated machines up and running. One can choose between three failover processes — planned, unplanned and test. Planned failover is used in case you expect to have a major outage at a primary location. In such a situation, Azure will attempt to synchronize all differences made between two replication intervals, stop the machine at the primary location, and the spin up a machine in Azure. Once the data centre becomes available again, you can easily reverse replication from Azure to on-premises and initiate a failback procedure - another example of a critical. This is an example of another feature necessary for enterprise environments, but missing in AWS.
This out-of-the-box solution ensures zero data loss and it’s something AWS cannot offer because its solution is not DR- aware —AWS relies instead on building procedures manually. Not only can you use this option for DR scenarios, you can use it as a handy tool to move workloads from your data centre to Azure, and group your on-premises infrastructure and Azure into one hybrid entity.
Unplanned failover is used in case you have a sudden outage in production, and involves data loss between synchronization intervals. Test failover is used to create an isolated replica of a disaster recovery site for the purpose of testing the environment. Additionally, you can use Azure Site Recovery as an orchestrator between two locations in your own data centres even if they are outside of Azure.
Naturally pricing is an important factor in deciding among the various DR offerings, and Microsoft kept it simple. You will be charged a small fee per protected instance depending on whether you want to use ASR only as orchestrator between your data centres or also replicate data to Azure. Microsoft will charge actual compute power separately if you decide to start replicated machines in Azure.
Even though Azure Site Recovery is an all-in-one solution offering your organization enterprise-grade features, you still need to consider factors like which workloads to protect, what protection policies to apply, and how to ensure replication is continuous and tested. Moreover, if you plan to move VMware of physical servers to the cloud, you should comply with the supported options.
Last but not least, mapping from on-premises to the cloud is frequently not one-to-one, so you must devote careful planning before starting to replicate workloads to the cloud. The expertise of Navisite Managed Data Protection & Replication Solutions and Disaster Recovery-as-a-Services (DRaaS) can make the process much smoother, and most importantly, keep your disaster recovery site clean and efficient, in addition to constantly monitoring vital replication parameters.
If you are planning to migrate from on-premises to the cloud, or establish a disaster recovery solution, Azure Site Recovery is the tool of choice. It is a flexible and automated solution offering you out-of-the-box enterprise-grade features. Depending on your needs and situation, you can replicate your data, initiate failover or test, or even move only certain workloads from your data centre to Azure and vice-versa.
With the assistance of Navisite, you can maximize the advantages of Azure Site Recovery, thus paving the road to a reliable cloud data centre tailored to your needs with faster implementation time and TCO.
Contact our Elite 5-Star Managed Services team to learn more about how you can deploy Azure Site Recovery as part of building a robust disaster recovery strategy. For more information on our entire portfolio of disaster recovery solutions, click here.