When designing your applications and services, regardless if they are in the cloud or on-premises, one of the essential aspects is high availability. To achieve high availability for application, you need to make sure that you plan your infrastructure correctly to reduce the possibility of service impact in case of planned or unplanned downtimes. That includes using high-availability solutions that Azure provides and which we will go in-depth later on.
Within Azure infrastructure, downtime can happen in the following scenarios:
- Planned maintenance: This occurs when some maintenance is being conducted on infrastructure. For example, when Azure infrastructure updates some servers, or perform other hardware regular maintenance to increase system stability and security or when adding new features
- Unplanned maintenance: Azure cloud has developed a system of health checks which can detect if any component of the infrastructure (network, server or any type of hardware) can go wrong in some near future and based on these readings it then performs maintenance activities as soon as possible, without scheduling them previously
- Unexpected downtime: This kind of downtime usually happens when some unexpected failure occurs due to unforeseen circumstances
Let’s take a look at what options does Azure provide us with to help us to achieve even better availability for our services and application. We will explain how these high availability solutions work and how much effort you need to implement each of them in your Cloud infrastructure:
Azure Availability Set feature relies on the use of Update domains and Fault domains to provide high availability for your Azure VMs on the datacenter level.
Update domain (UD) represents a physical host in Azure on which your VMs can be running. Each of these update domains can be rebooted or updated at the same time. Microsoft takes care of that process with Azure Service Fabric and therefore makes sure that planned downtime during maintenance window occurs for each Update Domain separately. Once it completes an update for one Update domain, it proceeds with updating another Update domain. Therefore, it is good to distribute your VMs across multiple UDs just to avoid potential planned downtime from affecting your Azure VMs.
Fault domain (FD) represents set or grouping of Hyper-V hosts that share the same infrastructure in the background, like power supply, network switch and similar. That only means that all virtual machines will be affected if any issue happens on that same underlying infrastructure.
When implemented, Availability Set makes your Azure VM infrastructure much more resilient to failures. When you place your virtual machines in Availability Set, Azure distributes VMs across different update and fault domains to prevent any potential planned or unplanned VM reboots. There are several ways on how you can deploy Availability Set.
Deployment using Azure Portal
Once you login to your Azure portal, you can search for and Availability Set when you want to create a new resource. The next steps include giving your Availability Set name and selecting appropriate Resource Group as well as Region where it will be deployed. As you can see, by default number of a Fault domain is 2 (we can increase up to 3) and the number of Update Domains is 5, but we can increase it up to 20. That all depends on the planning and number of VMs that we plan to add to this Availability Set.
Under the Advanced tab, we can select the Proximity Placement group if needed.
A proximity Placement group is a logical grouping that is used to make sure that all Azure Compute resources are physically located close to each other. They are handy when we have workloads which require low latency for optimal performance
Once you add all the needed information, you are ready to create your Availability Set.
Deploy Availability Set with PowerShell or Azure CLI
PowerShell is also a speedy and efficient way to create any resource in Azure and we can use it for this purpose as well. You just need one line of the code which has all required parameters and your Availability Set will be deployed:
New-AzureRmAvailabilitySet -ResourceGroupName "AzLearning" -Name "AvSet1" -Location "Central US" -PlatformUpdateDomainCount 5 -PlatformFaultDomainCount 2
For those who prefer using Azure CLI, you can also use it as well to create needed Availability Sets:
az vm availability-set create -n AvSet1 -g AzLearning --location “central us” --platform-fault-domain-count 2 --platform-update-domain-count 5
Availability Set can also be created during the VM creation or you can assign existing Availability Set to new VMs. An important thing to mention is that you cannot add existing VMs to newly created availability set or move VM between them. To add or remove VMs from Availability Set, you will need to recreate these VMs. In the example below, you can see that we have deployed three VMs and added them to the existing Availability Set. You can also notice how VMs are distributed to the different update and fault domains (FDs and UDs).
In case you want to go beyond Availability Sets and have your service available even in case of data centre failure, then you can go one step further and get yourself familiar with Azure Availability Zones. Single Azure region can have multiple different physical locations with separate and independent infrastructure (separate power resources and separate underlying networking, compute and storage infrastructure).
These locations can be close to each other or can be far away from each other, but still within the same Azure region. Fast links are connecting these locations and therefore, low latency is guaranteed between datacenters. As always, the goal is to have your cloud services and infrastructure to run at optimal levels.
Every Azure region that supports Availability Zones is splint into four zones, but only three zones are visible to you as a customer. An important thing to mention is that Availability Zone Identifiers (which are marked with numbers 1, 2 and 3) are logically mapped to physical zones for each subscription independently. Because of this, Microsoft advises not to rely on Availability Zone IDs across different subscriptions for azure virtual machine placement. Many Azure services can be deployed across Availability Zones. More info can be found in official Microsoft documentation.
How does this work in real-time?
Let have an example that you have two Azure VMs. We will name them VM1 and VM2, which have some mission-critical service running on them. When deployed, you defined Availability Zone 1 for VM1 and Availability Zone 2 for VM1. In case something goes wrong and Zone 1 has some unexpected downtime, you will still be able to access VM2 in Zone 2 and have your service operational while the Microsoft resolves an issue in Zone 1.
How to add Availability Zone for your VM
For testing purposes, we have deployed three separate VMs in different Availability Zones within the Azure region. Availability Zone is defined when you deploy your VM, nevertheless of the deployment method. Below you can see the example on how to do this from Azure Portal:
As you can see, we have selected Availability Zone and selected which zone to use (zone 2 in this case). Upon finalization of VMs deployment, we can see that all three virtual machines are deployed to different Availability Zones:
Use of Availability Sets and Availability Zones is highly recommended whenever you are planning the deployment of new infrastructure. It grants you high availability and less chance that your services will experience interruption during any planned or unplanned maintenance that can occur on any part of the underlying Azure infrastructure.
What about pricing?
Availability Sets are free of charge. You only pay for VMs that are inside your Availability Sets. The same goes for Availability Zones, they are free of charge, but any additional inter-availability Zone data transfer and bandwidth usage between VMs will be charged. More info on bandwidth pricing can be found here.
Dedicated Host – isolated host only for your environment
It is worth mentioning that Azure included Dedicated Host in its vast array of IaaS offerings. In regular scenarios where you create your own VMs, Azure will place VMs on some host which is, in the back end, actually shared with VMs from other customers. You will never notice this, but it is how it works.
Azure Dedicated Host allows you to run your Virtual machines in an environment that is not shared with other customers. This is especially useful in scenarios where you are under specific compliance, security or regulations which requires that you have a separate and isolated host for your workloads.
What are the benefits of Azure Dedicated Host?
- You have full control over the server infrastructure: you manage host maintenance policies and overall load on the server.
- You are control over hosts performance and capacity
- Unlimited virtualization possibilities for Windows Server and SQL server which are limited only by the host resources
Pricing and licensing
Azure Dedicated Host is charged on host-level (it doesn’t matter how many VMs you are planning to run on it). Software licenses are billed separately and this part of billing is at VM level based on its usage. The Pay-as-you-go service model is used for Azure Dedicated Host. As always, you can choose between several different host types:
- Host Type 1 offer consist of Dsv3 and Esv3 series host
- Host Type 2 offer consist of Fsv2 Series host
Additional cost reduction can be achieved if you have Azure Hybrid Benefit. That way, you can use the existing licenses that you already purchased for your On-Premises Windows and SQL servers. More details on pricing and licensing can be found on Microsoft Azure portal.
When is it worth considering the use of Azure Dedicated Host?
As mentioned above, customers usually go for dedicated hosts when their workloads have certain regulatory compliance which they fall under. Another reason for considering Azure Dedicated Host is mostly because of guaranteed hardware specifications and architecture.
It comes with a price, especially if you are not bringing your licenses, but then again, you are guaranteed that your workloads are all running on the same hardware.