Image by Thought Catalog

Post Details

  • ALIF Consulting

Multi-tier web application built for HA/DR

About Alif: Alif empowers Microsoft MSP-CSP partners to provide exceptional IT services to their clients to ensure that the partners reduce their costs and focus on their business. We provide white-labelled managed services for technologies like Microsoft Azure, Microsoft 365, Microsoft Dynamics 365, Microsoft Security, SharePoint, Power Platform, SQL, Azure DevOps and a lot more. Our headquarter is in Pune, India whereas we work with over 50 partners across the globe that trust us with their client delivery.


Multi-tier web application built for HA/DR –


This example scenario is applicable to any industry that needs to deploy resilient multitier applications built for high availability and disaster recovery. In this scenario, the application consists of three layers.


  • Web tier: The top layer including the user interface. This layer parses user interactions and passes the actions to next layer for processing.

  • Business tier: Processes the user interactions and makes logical decisions about the next steps. This layer connects the web tier and the data tier.

  • Data tier: Stores the application data. Either a database, object storage, or file storage is typically used.


Common application scenarios include any mission-critical application running on Windows or Linux. This can be an off-the-shelf application such as SAP and SharePoint or a custom line-of-business application.


Use Case of this Example –


Other relevant use cases include :


  • Deploying highly resilient applications such as SAP and SharePoint

  • Designing a business continuity and disaster recovery plan for line-of-business applications

  • Configure disaster recovery and perform related drills for compliance purposes


Application Architecture with HA/DR –


In Azure regions that support availability zones, you can deploy your virtual machines (VMs) in a source region across availability zones and replicate the VMs to the target region used for disaster recovery. In Azure regions that don't support availability zones, you can deploy your VMs within an availability set and replicate the VMs to the target region.


To route traffic between regions, you need a global load balancer. There are two main Azure offerings:

  • Azure Front Door

  • Azure Traffic Manager



This architecture uses Traffic Manager because it's lightweight. The failover timing is sufficient for illustrative purposes.


Solution Components –


  • Availability sets ensure that the VMs you deploy on Azure are distributed across multiple isolated hardware nodes in a cluster. If a hardware or software failure occurs within Azure, only a subset of your VMs are affected and your entire solution remains available and operational.

  • Availability zones protect your applications and data from datacenter failures. Availability zones are separate physical locations within an Azure region. Each zone consists of one or more datacenters equipped with independent power, cooling, and networking.

  • Azure Site Recovery allows you to replicate VMs to another Azure region for business continuity and disaster recovery needs. You can conduct periodic disaster recovery drills to ensure you meet the compliance needs. The VM will be replicated with the specified settings to the selected region so that you can recover your applications in the event of outages in the source region.

  • Azure Traffic Manager is a DNS-based traffic load balancer that distributes traffic optimally to services across global Azure regions while providing high availability and responsiveness.

  • Azure Load Balancer distributes inbound traffic according to defined rules and health probes. A load balancer provides low latency and high throughput, scaling up to millions of flows for all TCP and UDP applications. A public load balancer is used in this scenario to distribute incoming client traffic to the web tier. An internal load balancer is used in this scenario to distribute traffic from the business tier to the back-end SQL Server cluster.

Alternatives of above components –


  • Windows can be replaced by other operating systems because nothing in the infrastructure is dependent on the operating system.

  • SQL Server for Linux can replace the back-end data store or Azure SQL and Managed instance can be used.

  • The database can be replaced by any standard database application available.

  • Azure Traffic Managed can be replace by Azure Front Door with WAF for Layer 7 Security.

Scalability –

  • Add or remove VMs in each tier based on your scaling requirements.

  • Use Azure VM scale set if supported by application for burstable scaling.

  • Use Azure SQL or Managed Instance for high scalability and zero manageability of underlaying VMs.

Security –


  • Azure Defender for Cloud can be used to protect the workloads.

  • Use Azure Firewall if cost is not an issue else use NSG to protect the workload.

  • Use Azure Front Door for WAF with frontend application.

  • Use Managed Disk Encryption and Host Encryption for end to end encryption.

Pricing –


Configuring disaster recovery for Azure VMs using Azure Site Recovery will incur the following charges on an ongoing basis.


  • Azure Site Recovery licensing cost per VM.

  • Network egress costs to replicate data changes from the source VM disks to another Azure region. Azure Site Recovery uses built-in compression to reduce the data transfer requirements by approximately 50%.

  • Storage costs on the recovery site. This is typically the same as the source region storage plus any additional storage needed to maintain the recovery points as snapshots for recovery.

  • Any other components like Azure Firewall, Azure SQL and Managed Instances.


Microsoft have provided a sample cost calculator for configuring disaster recovery for a three-tier application using six virtual machines. All of the services are pre-configured in the cost calculator.









4 views0 comments