Availability sets for redundancy in Azure - Deep Dive

Overview - Availability sets for redundancy

What is it?

Availability sets are a way to group virtual machines in Azure to keep them running even if some parts fail. They spread VMs across different physical hardware to avoid a single point of failure. This helps keep applications available and reliable. It is a simple method to improve uptime without complex setups.

Why it matters

Without availability sets, if the physical server or network fails, all virtual machines on it stop working, causing downtime. This can disrupt services, lose customer trust, and cost money. Availability sets reduce this risk by ensuring some VMs stay up while others might fail, keeping the service running smoothly.

Where it fits

Before learning availability sets, you should understand what virtual machines are and basic cloud concepts like regions and data centers. After this, you can learn about more advanced redundancy options like availability zones and load balancers to build even stronger systems.

Mental Model

Core Idea

Availability sets keep virtual machines on separate physical hardware so that if one fails, others keep running.

Think of it like...

Imagine a group of friends going on a trip in different cars instead of one van. If one car breaks down, the others can still reach the destination.

┌───────────────────────────────┐
│        Availability Set        │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ VM on Server│ │ VM on Server│ │
│ │ Rack A      │ │ Rack B      │ │
│ └─────────────┘ └─────────────┘ │
│  Different Fault Domains & Update Domains │
└───────────────────────────────┘

Build-Up - 6 Steps

1

Foundation

What is an Availability Set

Concept: Introduction to the basic idea of grouping VMs for redundancy.

An availability set is a logical grouping of virtual machines in Azure. It ensures that the VMs are spread across multiple physical servers, racks, and network switches. This way, if one hardware component fails, only some VMs are affected, not all.

Result

You understand that availability sets help avoid single points of failure by distributing VMs.

Understanding that physical hardware can fail helps explain why grouping VMs across different hardware is important.

2

Foundation

Fault Domains and Update Domains

Concept: Learn the two key concepts that availability sets use to separate VMs.

Fault domains are like separate power and network sources. VMs in different fault domains won't fail together if a power or network issue happens. Update domains are groups of VMs that get updated or rebooted at different times to avoid downtime during maintenance.

Result

You know how Azure separates VMs to protect against hardware failure and maintenance downtime.

Knowing these domains explains how availability sets reduce both unexpected failures and planned interruptions.

3

Intermediate

Configuring Availability Sets in Azure

Concept: How to create and assign VMs to availability sets.

When creating a VM in Azure, you can specify an availability set. All VMs in that set share fault and update domains. You cannot add a VM to an availability set after creation; it must be assigned during VM creation. Azure automatically distributes VMs across domains.

Result

You can create VMs that are protected by availability sets and understand the creation constraints.

Knowing the assignment timing prevents common mistakes of trying to add existing VMs to availability sets.

4

Intermediate

Impact on Service Availability

🤔Before reading on: Do you think all VMs in an availability set fail together or only some? Commit to your answer.

Concept: How availability sets improve uptime by limiting failure impact.

Because VMs are spread across fault domains, if one domain fails, only VMs in that domain go down. Others keep running. Similarly, update domains ensure not all VMs reboot at once during maintenance. This design keeps services available even during failures or updates.

Result

You see that availability sets reduce downtime by isolating failures and updates.

Understanding partial failure containment helps design resilient applications.

5

Advanced

Limitations and Best Practices

🤔Before reading on: Do you think availability sets protect against data center-wide outages? Commit to your answer.

Concept: Recognize what availability sets do and do not protect against, and how to use them well.

Availability sets protect against hardware and update failures within a single data center but not against entire data center outages. For higher redundancy, use availability zones or regions. Best practice is to have at least two VMs in an availability set to benefit from fault domain separation.

Result

You understand the scope and limits of availability sets and how to plan redundancy.

Knowing limits prevents over-reliance on availability sets and encourages layered redundancy.

6

Expert

Internal Azure Handling of Availability Sets

🤔Before reading on: Do you think Azure manually assigns fault domains or uses automation? Commit to your answer.

Concept: How Azure automatically manages VM placement in fault and update domains behind the scenes.

Azure uses automated algorithms to assign VMs to fault and update domains within an availability set. It tracks hardware and maintenance schedules to balance VMs evenly. This automation ensures optimal distribution without manual intervention. The number of fault and update domains depends on the Azure region's infrastructure.

Result

You grasp that Azure handles complex VM distribution automatically to maximize uptime.

Understanding automation helps appreciate Azure's role in simplifying redundancy for users.

Under the Hood

Azure's infrastructure divides physical servers into fault domains representing separate racks or power/network sources. Update domains represent groups of VMs rebooted sequentially during maintenance. When you create an availability set, Azure assigns VMs to these domains automatically to spread risk. This is managed by Azure's control plane, which tracks hardware health and schedules updates to minimize impact.

Why designed this way?

This design balances simplicity and effectiveness. Early cloud failures showed that hardware and maintenance caused most downtime. By isolating VMs across fault and update domains, Azure reduces correlated failures without complex user setup. Alternatives like manual VM placement were error-prone and hard to scale. This automated domain assignment was chosen for reliability and ease of use.

┌───────────────────────────────┐
│       Azure Data Center        │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ Fault Domain│ │ Fault Domain│ │
│ │     0       │ │     1       │ │
│ │ ┌───────┐   │ │   ┌───────┐ │ │
│ │ │ VM 1  │   │ │   │ VM 2  │ │ │
│ │ └───────┘   │ │   └───────┘ │ │
│ └─────────────┘ └─────────────┘ │
│ Update Domains cycle reboots to avoid downtime │
└───────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does an availability set protect your VMs if the entire Azure region goes down? Commit yes or no.

Common Belief: Availability sets protect VMs from any kind of failure, including entire region outages.

Reality: Availability sets only protect against hardware failures and maintenance within a single data center, not entire region or data center outages.

Why it matters: Relying solely on availability sets can cause unexpected downtime during large outages, leading to service disruption.

Quick: Can you add an existing VM to an availability set after creation? Commit yes or no.

Common Belief: You can add any VM to an availability set anytime after creation.

Reality: VMs must be assigned to an availability set during creation; you cannot add existing VMs later.

Why it matters: Trying to add VMs later wastes time and causes deployment errors.

Quick: Do all VMs in an availability set reboot at the same time during maintenance? Commit yes or no.

Common Belief: All VMs in an availability set reboot together during updates.

Reality: Azure reboots VMs in different update domains one group at a time to avoid full downtime.

Why it matters: Misunderstanding this can lead to poor maintenance planning and unexpected downtime.

Quick: Does having only one VM in an availability set provide redundancy? Commit yes or no.

Common Belief: A single VM in an availability set is enough for redundancy.

Reality: Redundancy requires at least two VMs to spread across fault domains; one VM alone gains no protection.

Why it matters: Deploying only one VM in an availability set gives a false sense of reliability.

Expert Zone

1

Azure's fault domain count varies by region and can affect how many VMs you can effectively spread across hardware.

2

Update domains are not guaranteed to be rebooted in a strict order but are managed to minimize simultaneous downtime.

3

Availability sets do not protect against software or application-level failures; combining with monitoring and auto-healing is essential.

When NOT to use

Availability sets are not suitable when you need protection against entire data center failures or want geographic redundancy. In those cases, use availability zones or multi-region deployments. Also, for stateless or containerized workloads, orchestrators like Kubernetes offer better scaling and redundancy.

Production Patterns

In production, availability sets are often combined with load balancers to distribute traffic across VMs. Teams deploy at least two VMs per availability set and monitor health to replace failed instances quickly. For critical apps, availability sets are a baseline, supplemented by zones or regions for disaster recovery.

Connections

Load Balancing

Builds-on

Availability sets ensure VMs stay up during failures, while load balancers distribute user traffic to healthy VMs, together providing continuous service.

Disaster Recovery

Complementary

Availability sets handle local hardware failures, but disaster recovery plans cover large-scale outages by replicating data and services across regions.

Fault Tolerance in Mechanical Engineering

Same pattern

Both use redundancy and separation of components to prevent total system failure when one part breaks.

Common Pitfalls

#1 Trying to add an existing VM to an availability set after creation.

Wrong approach:

az vm availability-set add --vm-name myVM --availability-set mySet

Correct approach:

Assign the availability set during VM creation: az vm create --name myVM --availability-set mySet ...

Root cause:

Misunderstanding that availability sets must be assigned at VM creation time.

#2 Deploying only one VM in an availability set expecting redundancy.

Wrong approach:

Create one VM in an availability set and assume it is protected.

Correct approach:

Deploy at least two VMs in the availability set to spread across fault domains.

Root cause:

Not realizing redundancy requires multiple instances to separate failure domains.

#3 Assuming availability sets protect against region-wide outages.

Wrong approach:

Rely solely on availability sets for disaster recovery.

Correct approach:

Use availability zones or multi-region replication for region-level fault tolerance.

Root cause:

Confusing local hardware redundancy with geographic disaster recovery.

Key Takeaways

Availability sets group virtual machines to spread them across different physical hardware to reduce downtime.

They use fault domains and update domains to isolate hardware failures and maintenance reboots.

VMs must be assigned to availability sets during creation; existing VMs cannot be added later.

Availability sets protect against local hardware failures but not against entire data center or region outages.

For full resilience, availability sets are combined with load balancers, availability zones, and disaster recovery strategies.

Practice

1. What is the main purpose of an Availability Set in Azure?

easy

A. To automatically back up virtual machines every hour

B. To keep virtual machines running during hardware failures by spreading them across fault domains

C. To increase the storage capacity of a single virtual machine

D. To reduce the cost of virtual machines by sharing resources

Solution

1. Step 1: Understand the role of Availability Sets

   Availability sets distribute VMs across different physical hardware to avoid single points of failure.

2. Step 2: Identify the correct purpose

   This distribution helps keep apps running during hardware failures by using fault domains.

3. Final Answer:

   To keep virtual machines running during hardware failures by spreading them across fault domains -> Option B

4. Quick Check:

   Availability sets = fault domain distribution [OK]

Hint: Availability sets protect VMs from hardware failure by spreading them [OK]

Common Mistakes:

• Confusing availability sets with backup solutions
• Thinking availability sets increase storage
• Assuming availability sets reduce VM costs

2. Which of the following is the correct way to create an availability set using Azure CLI?

easy

A. az vm availability-set create --name MySet --resource-group MyGroup --platform-fault-domain-count 2 --platform-update-domain-count 5

B. az availability-set create --name MySet --group MyGroup --faults 2 --updates 5

C. az vm create availability-set --name MySet --resource-group MyGroup --fault-domain 2 --update-domain 5

D. az create availability-set --name MySet --resource MyGroup --fault-domain-count 2 --update-domain-count 5

Solution

1. Step 1: Recall Azure CLI syntax for availability sets

   The correct command uses az vm availability-set create with parameters for fault and update domain counts.

2. Step 2: Match the correct command

   az vm availability-set create --name MySet --resource-group MyGroup --platform-fault-domain-count 2 --platform-update-domain-count 5 matches the correct syntax and parameter names exactly.

3. Final Answer:

   az vm availability-set create --name MySet --resource-group MyGroup --platform-fault-domain-count 2 --platform-update-domain-count 5 -> Option A

4. Quick Check:

   Correct CLI syntax = az vm availability-set create --name MySet --resource-group MyGroup --platform-fault-domain-count 2 --platform-update-domain-count 5 [OK]

Hint: Use 'az vm availability-set create' with fault and update domain counts [OK]

Common Mistakes:

• Using wrong command group like 'az availability-set create'
• Incorrect parameter names like 'faults' or 'updates'
• Mixing VM creation command with availability set creation

3. Given an availability set with 3 fault domains and 5 update domains, what happens if a planned maintenance affects update domain 3?

medium

A. All VMs are shut down until maintenance completes

B. All VMs in the availability set reboot simultaneously

C. VMs in fault domain 3 are rebooted, others are unaffected

D. Only VMs in update domain 3 are rebooted; others keep running

Solution

1. Step 1: Understand update domains in availability sets

   Update domains define groups of VMs rebooted one group at a time during planned maintenance.

2. Step 2: Apply update domain behavior

   Only VMs in the affected update domain reboot; others continue running.

3. Final Answer:

   Only VMs in update domain 3 are rebooted; others keep running -> Option D

4. Quick Check:

   Update domain reboot = only affected domain [OK]

Hint: Update domains reboot one group at a time during maintenance [OK]

Common Mistakes:

• Confusing fault domains with update domains
• Assuming all VMs reboot together
• Thinking fault domain 3 is rebooted on update domain maintenance

4. You created two VMs but forgot to assign them to the same availability set. What is the likely impact?

medium

A. The VMs may be placed on the same hardware, increasing downtime risk

B. The VMs will automatically be grouped into a default availability set

C. The VMs will not start until assigned to an availability set

D. The VMs will be backed up automatically to prevent downtime

Solution

1. Step 1: Understand VM placement without availability sets

   Without an availability set, Azure may place VMs on the same physical hardware.

2. Step 2: Identify impact on redundancy

   This increases risk that a hardware failure affects both VMs, causing downtime.

3. Final Answer:

   The VMs may be placed on the same hardware, increasing downtime risk -> Option A

4. Quick Check:

   No availability set = no guaranteed hardware separation [OK]

Hint: Without availability sets, VMs risk being on same hardware [OK]

Common Mistakes:

• Assuming Azure auto-creates availability sets
• Thinking VMs won't start without availability sets
• Confusing availability sets with backup features

5. You need to deploy 6 VMs with high availability. You create an availability set with 2 fault domains and 3 update domains. What is the best way to distribute the VMs to maximize redundancy?

hard

A. Place 2 VMs in fault domain 1 and 4 VMs in fault domain 2, all in update domain 1

B. Place all 6 VMs in fault domain 1 to simplify management

C. Place 3 VMs in fault domain 1 and 3 VMs in fault domain 2, spread evenly across update domains

D. Place all VMs in the same update domain to reduce reboot frequency

Solution

1. Step 1: Understand fault domain distribution

   Fault domains separate VMs across different hardware racks to avoid single points of failure.

2. Step 2: Understand update domain distribution

   Update domains ensure VMs reboot in groups during maintenance, so spreading VMs across them reduces downtime.

3. Step 3: Apply best practice for VM distribution

   Distributing VMs evenly across fault domains and update domains maximizes redundancy and availability.

4. Final Answer:

   Place 3 VMs in fault domain 1 and 3 VMs in fault domain 2, spread evenly across update domains -> Option C

5. Quick Check:

   Even VM spread across fault and update domains = max redundancy [OK]

Hint: Distribute VMs evenly across fault and update domains for best uptime [OK]

Common Mistakes:

• Putting all VMs in one fault domain
• Ignoring update domain distribution
• Assuming same update domain reduces reboots