Introduction to Azure Availability Zones

Last week at Ignite, Microsoft announced the public preview of a new Azure feature: Availability Zones. This is a huge thing, and once again the team behind the feature, has done fantastic work to collect feedback and providing testing scenarios. Thanks!

What are Availability Zones?

As you might know, Microsoft has multiple datacenters within each region. These facilities are physically and logically isolated from each other, which defines a zone. An example is the West Europe region, where 3 zones are available: 1, 2, and 3. This means that 1 zone can fail, and the 2 others will continue operations as nothing happened.

This gives us new options when designing highly available solutions in Azure. Previously we’ve used Availability Sets to make sure VMs was placed in different fault domains. Fault domains however, are within the same facility – or as they’re named now: zone.

Along with Availability Zones, a new Load Balancer SKU – Standard – was also announced, which support Zones. So consider your web application deployed across 3 zones within a region. In this case you need to deploy a Standard Load Balancer to distribute the load:

clip_image002

What about latency?

Some application require low latency between application and data (SQL for example). Increasing the distance between servers, will also increase the latency – that’s normal physics. The goal for Availability Zones, is to keep roundtrip latency below 2ms.

Think of this as a way of deploying your application to multiple datacenters, but with much less latency than between regions.

Should I choose Availability Zones or Sets?

I know you probably want a golden answer here, but I’m going with the usual answer: it depends!

Honestly, there are too many variables in a deployment, to answer this perfectly. As mentioned above, latency kicks in when you have cross zone traffic. If your application can’t handle this, you will be doing an active/passive configuration in a zoned deployment. If your application can handle the latency, or you have other ways to distribute the traffic (load balancing for example), then I would recommend testing zones.

One thing to keep in mind though, is that you can’t mix Availability Sets and Zones. So either you deploy a VM in an Availability Set, or you deploy it in a Zone.

To understand this better, take a look at this slide:

clip_image004

You basically have 4 options when deploying VMs in Azure:

· Single VM with Premium Storage, gives you 99,9% SLA

· 2 or more VMs in an Availability Set, protect you from rack failure within a datacenter, and provides 99,95% SLA

· Deploy VMs in to Availability Zones instead of Sets, and get protection from complete datacenter failures with a whooping 99,99% SLA!

· Split your workload across regions, to avoid region failure – this is not backed by a specific SLA, instead it uses the SLAs from above

Hey, what about my network?

Don’t worry. Some resources in Azure are regional, and virtual networks are one of them. You do not need to manage a network per zone, and create VPNs etc.

Another resource type, which is not bound to a zone, is network interfaces. When you create a NIC it’s just a configuration waiting to be used. Only when it’s actually attached to a vnet, will it be created.

From a Public IP perspective, just like there is a new SKU for Load Balancers, there are also a new Standard SKU for Public IP addresses. So when you create a Load Balancer that needs a Public IP, you will also need to create a Standard Public IP to use with it. On the other hand, if you deploy a VM with a Public IP, you can create a Basic (the SKU you’ve been using until now) Public IP. This IP needs to be in the same zone as the VM though!

Deploy VMs in Availability Zones with PowerShell

To create a new VM in an Availability Zone, the only difference from normal PowerShell creation, is you need to add -Zone parameter to the New-AzureRmVMConfig cmdlet. The below script will create 3 VMs, in 3 different zones:

$vmCount = 1..3
$location = "West Europe"
$rgName = "zonevms"
$vnetRg = "Networking"
$vnetName = "WE-Network"
$subnetName = "MGMT-Administration"
$vmName = "zonevm"
$cred = Get-Credential -Message "local admin pw"

New-AzureRmResourceGroup -Name $rgName -Location $location
$vnet = Get-AzureRmVirtualNetwork -ResourceGroupName $vnetRg -Name $vnetName
$subnetId = ($vnet.Subnets |where {$_.Name -eq "MGMT-Administration"}).Id

foreach ($vmNumber in $vmCount) {
$vm = New-AzureRmVMConfig -VMName ($vmName + $vmNumber) -VMSize Standard_D2_V2 -Zone $vmNumber
$vm = Set-AzureRmVMOperatingSystem -VM $vm -Windows -Credential $cred -ComputerName ($vmName + $vmNumber)
$vm = Set-AzureRmVMSourceImage -VM $vm -PublisherName MicrosoftWindowsServer -Offer WindowsServer -Skus 2016-Datacenter -Version latest
$nic = New-AzureRmNetworkInterface -Name ($vmName + $vmNumber + "-nic") -ResourceGroupName $rgName -Location $location -SubnetId $subnetId
$vm = Add-AzureRmVMNetworkInterface -Id $nic.Id -VM $vm

# Then you can create your VM using that config
New-AzureRmVM -ResourceGroupName $rgName -Location $location -VM $vm
} 

Deploy VMs in Availability Zones with Portal

Just like PowerShell, not much has changed in the portal deployments for zones.

First, make sure you deploy the VM to a region that supports Zones (check the FAQ below for details):

clip_image006

Also make sure you use a supported VM zone (again, check FAQ):

clip_image008

And finally, on the Settings blade, you can select which Zone to deploy the VM to:

clip_image010

That’s all you need to do. If you need to check which zone a VM is deployed to, you can see this on the Properties blade of the VM:

clip_image012

FAQ

Q: Won’t everybody end up using zone 1?
A: Zone numbers are rotated between subscriptions, to avoid this

Q: What regions are supported? And how many zones do they have?
A: East US 2, West Europe. Each region has at least 3 zones

Q: Are all VM Sizes supported?
A: No. Av2, Dv2, and DSv2 are supported. In some regions, G-series might only be available in 2 zones.

Q: Does all resource types use zones?
A: No, not yet at least, but expect the list to grow. For now you can deploy Public IPs, Load Balancers, VMs, and VM ScaleSets and Managed Disks (for VMs) with zones.

Let me hear your opinion