What are availability sets in Azure?
In a nutshell, they are a way to define declaratively policies about how your services (VMs, Apps, etc.) are deployed in order to ensure high availability.
To get more specific, you need to understand two more concepts: Fault Domain & Update Domain.
Two physical machines in a Fault Domain share a common power source and network switch. This means that when there is a physical fault, an outage, all machines on the same fault domain are affected. Conversely, two machines in two different fault domain shouldn’t fail at the same time.
Update Domain, on the other hand, define a group of machines that are updated at the same time. Azure has automatic maintenance patches requiring reboots. Machines on the same update domain will be rebooted at the same time.
So, if you understand those two concepts, you will realize that if you want your solution to be highly available, you’ll want to avoid to either:
- Have all instances of the same service on the same fault domain (a physical outage would affect both instances)
- Have all instances of the same service on the same update domain (a planned maintenance would take them both down at the same time)
This is where availability sets come in. Azure guarantees that an availability set has:
- 5 Update Domains
- 2 Fault Domains
Those are defaults and can be modified, to an extend.
So by defining the instances of your services to belong to an availability set, you ensure they will be spread on different fault and update domains.
Conversely, you’ll want the different tiers of your solution to belong to different availability sets. Otherwise, it could happen (depending how the update & fault domains are distributed among the instances, which you do not control) that all the instances of the same tier be rebooted or failed at the same time.
Those were the two big rules with availability set, which you could coalesce in one:
Define an availability set per application tier, have more than one instance per tier and load balance within a tier.