Designing for high availability in Azure compute involves choosing between different levels of isolation. Availability Zones are physically separate datacenters within a single region, each with its own power and network. Availability Sets provide logical isolation by spreading virtual machines (VMs) across different hardware racks within a single datacenter. Use Availability Zones to protect against a full datacenter outage, and use Availability Sets to guard against a single rack failure.
For automatically managing large groups of identical VMs, use Virtual Machine Scale Sets in flexible orchestration mode. This mode automatically spreads VMs and their disks across multiple Availability Zones. Key configuration settings include zone balance, which controls how evenly VMs are distributed, and fault domain spreading, which determines how VMs are placed on physical racks. You must also integrate the scale set with an Azure Load Balancer and its health probes to automatically remove unhealthy VMs from receiving traffic.
When an application cannot use a scale set, you can still achieve high availability by manually placing at least two VMs in each of three Availability Zones. Traffic must be directed to these VMs using an Azure Load Balancer. To prevent data loss during a zone failure, the VMs' operating system and data disks must use zone-redundant storage (ZRS), which replicates data across multiple zones automatically.
A system architecture diagram showing an Azure Load Balancer distributing traffic and monitoring health probes across Virtual Machines deployed in three separate Availability Zones, backed by Zone-Redundant Storage.
Maintaining uptime during updates requires coordination. Before starting, check the Azure Service Health Dashboard for any ongoing platform issues. Then, configure the load balancer to drain traffic away from the zone you are updating, and perform rolling upgrades one zone at a time. To handle traffic spikes, define autoscaling policies that add or remove VM instances based on metrics like CPU usage. The load balancer and its health probes work with these rules to ensure new VMs only get traffic after they are fully running and healthy.
Choosing a high-availability solution for relational data depends on your required Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Azure offers several built-in techniques with different synchronization models and failover processes.
Active geo-replication for Azure SQL Database creates up to four readable secondary databases in different regions. It uses asynchronous replication, so the secondary is nearly up-to-date with a small lag. This technique is good for disaster recovery, offering a low RPO (about 5 seconds), and it can also offload read-only workloads to the secondaries. After a failover, applications must be redirected to the new primary endpoint.
Auto-failover groups manage failover for a group of databases together, for both Azure SQL Database and SQL Managed Instance. The group provides a single endpoint that doesn't change after failover, so application code doesn't need updating. Failover can be automatic or manual. Automatic failover has an RTO of about 60 seconds, and the RPO depends on the replication delay at the time of the outage, so some data loss is possible.
Managed Instance availability groups in Azure SQL Managed Instance work like traditional SQL Server availability groups. Within a single region, they use synchronous replication between the primary and a secondary, guaranteeing zero data loss (RPO of 0). This supports automatic failover for high availability within the region. For disaster recovery to another region, you can configure a manual failover.
Backups provide an additional safety net. Azure SQL Database automatically creates full, differential, and transaction log backups. Point-in-time restore lets you recover the database to any moment within the retention period. Geo-restore uses geo-redundant backups to restore the database in another region, with an RPO of about 1 hour. For long-term compliance, long-term backup retention can store backups for up to 10 years.
Your choice is driven by RTO and RPO targets. For high availability within a region using zone redundancy, you can achieve an RTO under 30 seconds and an RPO of 0 with synchronous replication. For cross-region disaster recovery using failover groups, expect an RTO around 60 seconds, with the RPO varying based on asynchronous replication delay. To minimize data loss, you can combine synchronous replication within a region with asynchronous replication across regions.
Azure offers different built-in redundancy models for storage services. Azure Storage provides options like Locally Redundant Storage (LRS), which replicates data three times within one data center, and Zone-Redundant Storage (ZRS), which replicates across multiple data centers (availability zones) in one region. For protection against a regional disaster, Geo-Redundant Storage (GRS) copies data to a secondary region. Read-Access Geo-Redundant Storage (RA-GRS) adds read access to that secondary copy.
Azure Cosmos DB uses a different replication approach. You can configure a single-master setup, where one region handles all writes for strong consistency, or a multi-master setup, where writes can happen in any of several regions for lower latency and higher availability. Both support multi-region replication to place data copies close to users.
The replication model you choose affects the balance between data consistency and operation latency. Cosmos DB offers configurable consistency levels. Strong consistency guarantees all users see the latest write but increases latency. Eventual consistency offers the fastest reads and writes but allows temporary differences between regions. Middle-ground options like bounded staleness and session consistency provide specific guarantees about how out-of-date data can be.
Selecting the right model is key to meeting your Recovery Point Objective (RPO) and Recovery Time Objective (RTO). For the lowest RPO and RTO, you need automated failover and geo-redundancy, such as GRS for Storage or multi-region replication for Cosmos DB. Regular snapshots and geo-backups provide a safety net for point-in-time recovery. You must test the configuration through failover drills and monitor it with tools like Azure Monitor to ensure it works during a real outage.
Venture into the world of Azure Infrastructure, where design meets functionality. Harness your skills and gain mastery over complex cloud structures to ace the AZ-305 Designing Microsoft Azure Infrastructure Solutions exam!
Prepare and test your skills
Prepare and test your skills
Availability Zones are physically separate datacenters within a single region, protecting against a full datacenter outage, while Availability Sets provide logical isolation by spreading virtual machines across different hardware racks within a single datacenter to guard against a single rack failure.
To achieve zero data loss (RPO of 0) within a region for Azure SQL Database, you can use Managed Instance availability groups, which use synchronous replication between the primary and a secondary instance.
Zone-redundant storage (ZRS) replicates data across multiple Availability Zones automatically, preventing data loss during a zone failure for the operating system and data disks of the virtual machines.
Active geo-replication creates readable secondary databases in different regions using asynchronous replication, while auto-failover groups manage failover for a group of databases together and provide a single endpoint that doesn't change after failover, so application code doesn't need updating.
StudyCerts
StudyCerts