Recent Posts



No tags yet.

Application Continuity with Azure Site Recovery


One of the biggest issues with continuity today is not the technology, it is the inability to bring together the application and the end-user together in minutes in the context of business.

The concept of continuity has often been focused on either the physical server, the virtual servers and in more recent times, virtual machine replication. It is true that applications run in datacentres and in most scenarios as virtual machines, but modern applications are often very complex ecosystems within the datacentre or the network. It has many moving pieces that evolve within themselves as they operate together, failing over datacentres and replicating virtual machines is not a guarantee that applications will work in its newly moved state. The end state is often missing the last mile and it should not be. The last mile is when the application meets the user.

Azure Site Recovery operates at the layer of business that matters, the delivery of the application to end users by making infrastructure workloads boot correctly at a target site. It is able to bring all of the dependent pieces of infrastructure into one coordinated action without the administrator needing to perform any manual tasks.

Application Continuity with Azure Site Recovery is different in that it has the following characteristics:

Application Awareness

What are the moving pieces of the application? How many tiers make up the application, what are the dependencies of the application? Application Continuity is not generic continuity, it is specific. It is application specific. It is a firm understanding, testing and a belief that the process of fail-over of that particular application from start to finish, from source to destination will work exactly as it was before being initiated. It may form part of a bigger fail-over process, but the focus has to be specific per application. Azure Site Recovery allows the creation of recovery goals.

An Azure ASR Recovery Goal is a grouping of application servers and failover logic into a simple group. This group can then be programmed to start up certain servers before others and also allows the inclusion of scripts which may be needed for proper startup at the destination.

Virtualize the Network

What good is the application having being failed over if the supporting infrastructure the network is not the same or exact? The network is the single biggest reason why most continuity solutions fail or why RTOs are in hours and not minutes. The goal is to deal with the network requirement first when planning and architecture application continuity. Will the application function in its new location and will the access to the end user be seamless using the same IP addresses?

Using Hyper-V replication with System Center Virtual Machine Manager and IP encapsulation, Azure Site Recovery can failover workloads between a source site and destination site whilst maintaining the same IP address of the workload and the network or internet service provider unaware of the IP encapsulation and routing. As long as Hyper-V is the source or Hyper-V/Azure is the destination, the workload will function perfectly at destination startup.

Orchestrating the Fail-over

If the fail-over process involves more than a single action or step. The process will be prone to errors. It will never be predictable. Predictability is key to continuity. Many continuity solutions provide replication of data, replication of data is a requirement of application continuity, it is not the end measurable state. being able to fail-over over VMs or keep VMs in sync is only a partial requirement. Azure Site Recovery allows the failover of a complex recovery goal from the source to the destination using Powershell, Azure CLI and the Azure portal using single action commands. Detailed granular progress is available during the failover process.

Monitoring and Reporting

The byproduct of continuity solutions is the ability to prove that a continuity action will work every time all the time. It should never be that you trust a vendor that it "will" work or something you do a few times a year. This is called "proof of success", This "proof of success" must be tangible, measurable to very repeatable. Application Continuity solutions must have "test fail-over" options, which is the ability to fail-over without compromising production workloads. Azure Site Recovery produces immutable reporting in terms of the success or failures that will occur before they are executed in production. This can be executed as frequently as possible without impacting production. Every step, sequence or action is recorded, traced and can be viewed.

End User Availability

Finally, The purpose of a well structured, tested and coordinated recovery plan must be there to service its intended recipient, the end user. This is the reason it exists in the first place. End users must receive the lowest RPO and the highest RTOs in minutes. Users must be completely unaware and the process of fail-over absolutely transparent. The goal is for the application to not know it has been relocated and the end-user to work with zero re-configuration even if he/she has been relocated. Azure Site Recovery enables rich options for application continuity,

"ASR makes available what matters to whom it matters in minutes."

Contact a Cloudlogic representative for further information on "Application Continuity Solutions".


Contact a Cloudlogic representative for further information on "Application Continuity Solutions".