Availability zones are one of Microsoft Azure’s key features to provide increased resilience within a region.
Azure availability zones (AZs) are “physically separate locations within each Azure region that are tolerant to local failures”
The idea behind this is that it’s possible to design and implement highly resilient solutions that span multiple availability zones.
Microsoft classify the three different types of zone-aware services as -
Zonal services — a resource that can be deployed or “pinned” by a customer to a specific zone, i.e. a virtual machine or Application Gateway
Zone redundant services — a resource is replicated across three zones. Azure manages its availability, and it can’t be “pinned” to a single zone, i.e. a storage account
Always-available services - are highly available and resilient to zone-wide and region-wide outages. These include critical services such as Azure AD, Azure DevOps and Azure DNS.
Some solutions don’t always need to deploy resources to a specific zone. However, I’ve worked with customers where this is critical, i.e. High-Performance Computing (HPC) or big data solutions that are sensitive to latency.
For example, you're guaranteeing the smallest possible latency by deploying a virtual machine and its storage (i.e., Azure NetApp Files) to the same zone. If they were deployed to different zones, there would be a slight but measurable increase in latency.
In this post, we’ll focus on Zonal services, i.e. those that we, as Azure customers, can deploy to a specific zone within a region.
The Logical-to-Physical zone mapping challenge
So far, we’ve seen that Availability Zones are helpful, but there’s a slight catch when using multiple subscriptions.
As Azure customers, we target a “logical” zone for zonal services. Here’s an example of selecting zone 1 for a virtual machine deployment in UK South -
For other deployments within that same subscription, any other deployments (VM or otherwise) targeting zone 1 will land in the same underlying “physical zone,” i.e. data centre. All good.
The catch is when deploying resources across multiple subscriptions. Two virtual machines in different subscriptions targeting the same logical zone won’t necessarily land in the same underlying “physical zone”.
At first, this seems a bit odd, but it makes sense. When I deploy a zonal resource for testing, I often select “zone 1” by default. If the logical-to-physical zone mapping were the same for all Azure subscriptions for all customers, then that single physical zone would quickly become oversubscribed. By, I assume, randomizing the mappings, then resource usage across physical zones is more evenly spread.
The diagram below shows the zone mapping for a couple of my test subscriptions against UK South. Immediately, you can see the difference between the two subscriptions. Each of the subscriptions' logical zones maps to different physical data centres -
If your solution is single-subscription, this behaviour isn’t an issue. But if you’re designing a multi-subscription, zone-aware solution that needs to be resilient and highly performant, being able to physically co-locate resources is critical.
Identifying the Logical-to-Physical zone mappings
So, how do we determine which logical AZ (1,2, etc.) corresponds to which underlying physical DC (LON22, 23 etc.) for each subscription? The Azure portal doesn’t surface this information. But there are a couple of ways to get this.
Approach 1 — using a PowerShell script
Azure has a REST API that allows us to compare the logical zone mappings for two subscriptions. Thankfully, the community has created several wrapper PowerShell scripts around the API that enable easier consumption.
In my opinion, the best of these is RZOMERMAN’s PowerShell script. I’ll walk through running this script against my Management and Corp LZ subscriptions and interpreting the results.
First, I need to register the AvailabilityZonePeering feature on my Management subscription -
Register-AzProviderFeature -FeatureName AvailabilityZonePeering -ProviderNamespace Microsoft.ResourcesIt can take a while for the provider to register, but this can be checked with the following command -
get-AzProviderFeature -FeatureName AvailabilityZonePeering -ProviderNamespace Microsoft.Resources2. Once registered, I run the PowerShell script to check the zone mappings.
Note — the script runs in the context of my current subscription i.e. Management. With the Targetsubscription parameter I specify the subscription I wish to check against i.e. Corp LZ
.\Check-AzureAZmapping.ps1 -Targetsubscription “71924c05-xxxx-xxxx-xxxx-xxxx” -location uksouthThe output of the script looks like this -
Approach 2 — Deploying Virtual Machines
The above script works well, but sometimes you won’t have permissions to register the AvailabilityZonePeering feature on the subscription.
Additionally, some customers need to ensure that their resources reside in a specific Azure data centre (e.g. LON22) to co-locate with physically provisioned kit, i.e. a Cray ClusterStor that has been provisioned specifically for that customer.
As mentioned above, the following approach will identify how AZ’s map across subscriptions. However, it will also identify the logical-to-physical zone mappings against the underlying data centres.
One of the Microsoft folks I’m currently working with pointed out that this information is buried in a config file on Azure Linux VMs. By viewing the /var/lib/hyperv/.kvp_pool_3 file, we can obtain a bunch of information about the Azure Hyper-V host our VM is running on. But crucially, we’re able to view its physical zone name. In this example, the VM is deployed to a host in LON23 -
The steps to create the mappings are -
Deploy a VM to each of the Availability Zones for the region you’re interested in
Obtain the underlying physical data centre from the .kvp_pool_3 file for each VM
Repeat for each subscription
Here, I’ve deployed six VMs across zones 1–3 in the Management and Corp LZ subscriptions:
Using the information from the .kvp_pool_3 files I can create the following initial table -
Simplifying the table to show how these zones map across both subscriptions -
So, we end up with the same information as the script-based approach plus the underlying Azure data centre.
Using my subscriptions as an example, I may wish to co-locate zonal resources for performance reasons in LON22. I would target Availability Zones 2 and 1 for the respective Management and Corp LZ subscriptions.
If the solution also needed to be resilient across zones, I would select either LON23 or LON24 for those secondary or DR resources within both subscriptions.
Conclusion
I’ve worked with customers where cross-region (i.e. UK South / UK West) high availability or disaster recovery isn’t technically practical or cost-effective. Therefore, relying on a well-designed, single-region, and zone-redundant solution has been key to ensuring that the customer’s RTOs and RPOs can be met.
I’ve used UK South as my example, but this approach applies equally to any other Azure region. You can repeat the PowerShell script, or VM approaches against additional subscriptions if you have more than two subscriptions.
In summary, for each type of Azure resource you’re going to deploy, consider -
How am I going to make this resource highly available?
Is it zone-aware? Does it support zonal deployments?
Do resources across multiple subscriptions need to reside in a shared physical zone for performance or resiliency requirements?
Which logical zone do I need to target for each subscription?
I hope you found this helpful, and as always, any feedback and comments are welcome!
Useful links
Microsoft have a useful reference document on the different Azure services and their zone configurability
RZOMERMAN’s Availability Zones Mapping Checker script (GitHub download)
Azure Check Zone Peers REST API
Azure Architecture Center — Build solutions for HA using availability zones
Comentários