Availability sets

In a nutshell, availability sets are logical groupings of virtual machines that provide the availability of the virtual machines within a data center and provide the virtual machines a 99.95% SLA.

Availability sets deploy virtual machines across different hardware instances through what is known as a fault domain, meaning the virtual machines are placed on hardware that is in physically separated racks when they are created. If there is a within-rack failure, then all virtual machines are not impacted; only a subset will be impacted, as you have spread your eggs over many baskets. Without availability sets, however, you have kept your eggs all in the same basket.

Without virtual machines being part of an availability set, the best SLA for a single virtual machine will be 99.9% when ultra or premium SSD disks are used. This drops down to 99% when standard SSD disks are used and 95% when standard HDD is used.

These SLAs equate to the following figures:

  • 99.5 % availability results in a period of allowed downtime/unavailability of 3h 39m 8s
  • 99.9 % availability results in a period of allowed downtime/unavailability of 43m 49s
  • 99.99 % availability results in a period of allowed downtime/unavailability of 4m 22s

The following diagram helps to visualize resource placement in an availability set:

Figure 3.8 – Azure availability sets

Availability sets also act as an update (patching) boundary; an update domain is automatically assigned to all virtual machines that are part of an availability set. Updates to one set of virtual machines are isolated from other virtual machines to ensure that only one update domain gets updated at a time. If an update impacted the service of virtual machines in one update domain, that update would not be applied to other update domains.

Some points to consider for availability sets are as follows:

  • Availability sets are not billable items.
  • A virtual machine is part of a single availability set.
  • Virtual machines can only be added to an availability set at the time of creation. It is not possible to add to an availability set or change the availability set after the virtual machines have been created; in this case, you would need to delete the virtual machine and redeploy, but this time as part of an availability set. Planning is critical for this purpose.
  • You might consider deploying a single virtual machine as part of an availability set already from the start. While it won’t help meet the availability set SLA – as that requires at least two instances or more – it would make your workload ready for the future without redeploying.
  • You will need to create the virtual machine in the same resource group as the availability set to add the virtual machine.
  • There are three fault domains and five update domains (a maximum of 20 can be configured) as part of an availability set.
  • The assignment is carried out automatically and horizontally in sequence, that is, vm1 in fault domain #1, vm2 in fault domain #2, and vm3 in fault domain #3, as we have only three fault domains in this example. This means that vm4 will be assigned fault domain #1.

This section looked at availability sets. The following section takes a close look at fault domains and update domains.