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.

0  

Azure CSP and Marketplace images

Just a short post, to describe how we got around the limitations of CSP, at my job, and why we did it. We recently moved all our Azure consumption from an Enterprise Agreement to CSP. The reasons was quite simple:

  1. EA doesn’t offer the same discounts anymore, and nothing close to what we get on CSP
  2. No upfront commitment
  3. Easy billing – the CSP we use sends a bill every month, we don’t have to do the number crunching (though we had automated most of it)

Of course everything isn’t just wonderful. We run a department that does monitoring using System Center Operations Manager, and part of doing this, is 24/7 alerting for customers. To accomplish that, we use Derdack Enterprise Alert which is available in Azure Marketplace. There’s 2 different models when using Derdack (and a lot of other 3rd party Marketplace offerings):

  • Bring Your Own License – BYOL
  • Pay the license through Azure (in this case, user CALs)

We could have bought our own licenses directly from Derdack. We did some calculations however, and since we do not use Derdack in work hours, we can turn of the server roughly 7 hours every weekday. This adds up to more than 140 hours every month where we did not have to pay for the license. Or to put it another way, we save about 15-18% of the cost, by turning off the VM.

So what’s the downside? On CSP subscriptions, you can only buy BYOL images. Ugh!

We discussed internally if the CSP move was a blocker for us. There are ways around this however, and we decided to go forward with the following design:

CSP-EA subscriptions

We kept our EA subscription (but didn’t do an upfront commitment – yes you can do that), but the only thing running on that subscription, is Derdack. On the other side, we have all our other VMs, like Active Directory, SQL, SCOM, ADFS etc. To connect the networks, we use vnet peering with gateway transit. That way, we can reach the Derdack VM from the VPN connection we have to our office.

From a billing point of view, we get a bill every now and then, for the Marketplace item (Derdack), and we get one every month from the CSP. Normally I prefer to have as few subscriptions as possible, but this design didn’t complicate our environment too much, and gave us the full flexibility we needed.

0