Availability sets for redundancy in Azure - Step-by-Step Execution

Process Flow - Availability sets for redundancy

Create Availability Set

↓

Assign VMs to Availability Set

↓

VMs distributed across Fault Domains

↓

VMs distributed across Update Domains

↓

If hardware or update failure

↓

Only subset of VMs affected

↓

Other VMs remain running

↓

Service stays available

Create an availability set, place VMs inside it to spread them across fault and update domains, so failures affect only part of the VMs, keeping service running.

Execution Sample

Azure

az vm availability-set create --name myAvSet --resource-group myRG --location eastus
az vm create --name vm1 --resource-group myRG --availability-set myAvSet --image UbuntuLTS
az vm create --name vm2 --resource-group myRG --availability-set myAvSet --image UbuntuLTS

Creates an availability set and two VMs inside it, ensuring they are spread across fault and update domains for redundancy.

Process Table

Step	Action	Result	VM Distribution	Service Status
1	Create availability set 'myAvSet'	Availability set created with 3 fault domains and 5 update domains	No VMs yet	No service yet
2	Create VM 'vm1' in 'myAvSet'	VM 'vm1' created	vm1 in Fault Domain 0, Update Domain 0	Service partially available
3	Create VM 'vm2' in 'myAvSet'	VM 'vm2' created	vm2 in Fault Domain 1, Update Domain 1	Service fully available
4	Simulate hardware failure in Fault Domain 0	VM 'vm1' affected	vm2 unaffected in Fault Domain 1	Service still available via vm2
5	Simulate update in Update Domain 0	VM 'vm1' rebooted	vm2 running normally	Service still available via vm2
6	All updates and failures handled	Both VMs running after recovery	vm1 and vm2 running	Service fully available

💡 Execution stops after all VMs are created and redundancy scenarios show service availability maintained.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5	Final
Availability Set	None	Created with 3 fault domains, 5 update domains	Same	Same	Same	Same
VM vm1 Status	Not created	Running in FD0 UD0	Running in FD0 UD0	Failed (hardware)	Rebooting (update)	Running
VM vm2 Status	Not created	Not created	Running in FD1 UD1	Running	Running	Running
Service Availability	None	Partial (1 VM)	Full (2 VMs)	Full (vm2 only)	Full (vm2 only)	Full (both VMs)

Key Moments - 3 Insights

Why does the service stay available even if one VM fails?

Because VMs are placed in different fault domains, failure in one domain affects only some VMs, others keep running (see execution_table step 4).

What is the difference between fault domains and update domains?

Fault domains separate hardware to avoid simultaneous failures; update domains separate VMs for rolling updates. Both ensure not all VMs go down at once (see concept_flow).

Can VMs outside an availability set get the same redundancy?

No, only VMs in the same availability set are distributed across fault and update domains for redundancy (see execution_table steps 2 and 3).

Visual Quiz - 3 Questions

Look at the execution_table, at which step does VM 'vm2' get created?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Check the 'Action' and 'Result' columns in execution_table rows for VM creation.

According to variable_tracker, what is the status of VM 'vm1' after step 5?

A Rebooting (update)

B Failed (hardware)

C Running

D Not created

💡 Hint

Look at the 'VM vm1 Status' row under 'After Step 5' column in variable_tracker.

If we add a third VM to the availability set, how would the service availability change after a fault domain failure?

A All VMs would fail simultaneously

B Service would be unavailable

C Service would still be available via VMs in other fault domains

D Service availability depends on update domains only

💡 Hint

Recall from concept_flow and execution_table how fault domains isolate failures.

Concept Snapshot

Availability sets group VMs to spread them across fault and update domains.
Fault domains isolate hardware failures.
Update domains isolate planned maintenance.
This setup keeps service running if some VMs fail or reboot.
Use 'az vm availability-set create' and assign VMs to it.

Full Transcript

An availability set is created first. Then VMs are assigned to it. The availability set divides VMs into fault domains and update domains. Fault domains separate hardware racks to avoid simultaneous hardware failure. Update domains separate VMs for rolling updates. When a hardware failure or update happens, only VMs in one domain are affected. Other VMs keep running, so the service stays available. This redundancy improves reliability. The example shows creating an availability set and two VMs inside it. When one VM fails or reboots, the other VM continues serving. This keeps the service up during failures or maintenance.

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