In the first two parts of this three-part blog series on Azure availability, we discussed uptime and associated SLAs of single Virtual Machines (VMs), as well as availability sets. To bring it home in this final installment, we’ll explore availability zones.
To recap, an availability set can be used to ensure that multiple VMs are spread across different infrastructure within the same data center, significantly reducing the potential of downtime due to hardware failure. The key here is they are still in the same data center.
In most conversations about Azure data centers, they are equated to a region. So, the West US 2 data center and the West US 2 region are often considered synonymous, but the reality is that the West US 2 region actually has three data centers. Microsoft refers to the different data centers in a region as zones. The West US 2 region, therefore, has 3 zones.
For most deployments, knowing the destination zone is not significant. Resources will be able to communicate with each other regardless. Resources that are region specific, like virtual networks, can be used by any zone in the region. So VMs in different zones can all be connected to the same VNet. There are no ingress or egress charges that occur, as the traffic is not leaving the Azure region.
From an availability perspective, the different zones are always considered separate domains. A VM deployed in zone 1, for example, is guaranteed to be on different power and have a different update schedule than a VM in zone 3. Having resources in different zones also ensures that a single data center outage will not affect all the resources in use. Understanding this, Microsoft provides a 99.99% uptime SLA for VMs deployed in an availability zone.
When planning out availability zones, all the same considerations must be made as when planning for an availability set. A zone-aware load balancer must be used to direct traffic. VMs cannot freely move in or out of zones. In fact, moving a VM into or out of a zone is much more complex than moving in or out of an availability set. Instead of simply deleting and recreating the VM, the VM must be deleted and the associated disks must be copied into the desired zone. Then the VM must be recreated in the same zone. A VM deployed specifically to zone 2 can only see disks deployed specifically to zone 2.
When creating a new VM, all the resources will be deployed to the zone selected. In the portal, selecting an availability zone will display all the zones available. If using PowerShell, there is a -zone parameter. The same holds true for a JSON template. In this fashion, zones are very different than sets. When VMs are added to an availability set, the allocation process ensures that they are deployed to different domains. When deploying VMs into an availability zone, the zone must be manually selected. It is therefore the responsibility of the person doing the deployment to ensure that VMs are distributed appropriately.
When deploying from the portal, the region selected will determine the ability to select availability zones. For example, West US only has one zone, so availability zones are not an available option, as shown.
Selecting West US 2 will display the number of zones available, as shown.
When a VM has been deployed as part of an availability zone, it will show up in the location on the Overview tab.
Keep in mind that there is no guarantee all the services available in a region will be available in all the zones in that region. As Microsoft rolls out new technology, it is still done in a data center-centric method. Deploying from the portal will filter this out most of the time, so if a specific VM type in not available in a zone, that zone will not be listed in the dropdown. In order to check availability ahead of time, PowerShell can be used to display the resources available in a specific region.
Running this command:
Get-AzComputeResourceSku -Location "westUS2"
Returns a list similar to:
Obviously, additional filtering can be used to find a given machine size.
The increase in availability does not mean that every deployment should leverage availability zones, even if zones are an option in the desired region. The tradeoff in SLA can come with additional network latency. It will not be as drastic as the latency seen between regions, but for highly sensitive applications, an availability set may be more appropriate.
In final review, understanding and planning for the correct uptime when deploying VMs in Azure is very important. However, if the correct architecture is not put in place, it is not the end of the world. Some changes, like disk tiering, are simple to fix. Others, like changing zones, may require significant rework.
Thanks for reading!
