Virtual machines have gone from being revolutionary to being a standard part of nearly every organization’s infrastructure. Now containers are the revolutionary technology, but VMs are still very important. Virtual machines give you full control over not only the software that you want to run but also the operating system. This is especially useful when you’re migrating existing servers to the cloud.

When you use VMs to run mission-critical applications, you need to architect the solution so that it will keep running even if there’s a hardware failure, a system update, or a spike in demand.

In order to understand how to implement high availability for VMs, it's important to consider the different causes for a system to become unavailable. There are two Azure related causes for a VM to become unavailable, which are planned and unplanned maintenance. Planned maintenance is where Microsoft makes some sort of update to the Azure platform. This could be any sort of improvement. For example, it could be security patches, performance fixes, or anything like that.

A lot of the time you won't notice that anything has even happened. However, there will be times when your VM will need to be rebooted, such as when Microsoft patches the hypervisor that's running the VM. Now, unplanned maintenance, as the name suggests, happens due to some unexpected event, such as a power failure, a hardware failure, or a network failure.

Because of these two possible causes for outages, Azure has the concept of update domains and fault domains. These correspond to the two types of outages I just mentioned. To ensure that your solutions remain available during a planned maintenance event, you can use update domains. Update domains put virtual machines into groups where the VMs can be rebooted at the same time.

To help with hardware failures, Azure offers fault domains. A fault domain represents a shared power source, storage, and network switch. The maximum number of fault domains you can use depends on the region where your VMs reside. In many regions, the maximum is 3, but in some, it’s only 2. Now because your VMs are provisioned in 2 or 3 separate groups, if there’s a failure in one fault domain, the VMs in the other fault domains will still be available.

The way that you use fault and update domains is through an availability set. The availability set allows you to change the number of fault and update domains. In order to ensure high availability and have an SLA of at least 99.95 percent, you need to have at least two VMs, at least two fault domains, and at least two update domains. The default number of update domains is 5, but you can set it to anything between 2 and 20. Azure will automatically alternate the distribution of the VMs into the fault and update domains.

Here's an example, if you have two fault domains and four update domains, then the first VM will be created in fault domain one and update domain one. The next VM will be in fault domain two and update domain two. The third VM is going to be in fault domain one and update domain three. The fourth VM will be in fault domain two and update domain four. And then if you created a fifth VM, it would belong to fault domain one and update domain one.

Notice how it loops through the fault and update domains to evenly distribute the virtual machines. When you plan out the design of highly available applications, it's common to create an availability set for each application tier (typically one for the web layer and one for the business layer because the database layer is often handled differently).

When it comes time to create an availability set, you'll need to determine how many fault and update domains to use for your application based on its expected usage. Using availability sets will help to ensure that your application has a high level of availability.

They won’t protect against a data center failure, though. That’s where availability zones come in. They’re an alternative to availability sets. An availability zone is a physically separate zone within an Azure region. So, if one zone goes down, then the other zones will likely still be up. Not every region offers availability zones, but in the ones that do, there are always three of them.

To take advantage of this capability, you should deploy multiple replicas of your application’s VMs in different availability zones. You can specify a particular availability zone when you create each VM. 

However, even this level of redundancy won’t protect you against an outage that affects an entire region. Regional outages aren't common, but they can and do happen. So, if you need higher availability than a single region, you'll have to use multi-region deployment.

When it comes to multi-region deployments, there are different options for how you might configure things depending on your availability requirements and your budget.

If you need an extremely high level of availability, then you can use an active/passive model with hot standby. With this approach, you have another version of your solution running in a secondary region and it doesn't serve up any traffic unless there's a failure in the primary region.

A variation on that is the active/active model with geo-location based request routing. This is similar to the previous option, but the solution that's running in the secondary region is actively serving up requests to the users who are closer to that region than the primary.

Then there's the active/passive model with cold standby, which basically means that there's not a solution running in a secondary region. Instead, it's dynamically created when the first region is unavailable. This is a great option if you want to balance the cost versus the SLA. The switchover is not going to be immediate, but with a well-defined automation plan, this is a viable option.

Another reason to deploy multiple VMs is for scaling purposes. Of course, you can scale individual VMs quite easily by switching them to a larger size, but there are limits to that approach. This is known as vertical scaling. Horizontal scaling, on the other hand, is when you scale by adding more VMs. It’s more complicated to scale horizontally, though.

First, you need to architect your application so it can run across multiple identical machines. Ideally, you should make that tier of your application stateless. That is, the VMs should not store any data locally. Otherwise, the application wouldn’t scale well because client requests would be tied to particular VMs. So the application should save data in a shared external datastore.

Next, you need to create a scale set. This is similar to an availability set because the VMs are distributed across fault and update domains, but you can do a lot more with it.

You can configure a scale set to automatically increase or decrease the number of VMs in it according to rules you define. For example, you can create a rule that says if the average CPU usage goes above 80%, then add 3 more VMs. You can also use disk and network metrics in your rules. If you need to scale based on guest OS metrics, such as available memory or number of processes, then you can enable the diagnostics extension. This will even let you use custom metrics based on something specific in your application logs. 

You’ll also usually want to set limits on how far a scale set can scale up or down by configuring a maximum and minimum number of VMs. Considering that a scale set can have up to 1,000 VMs in it, setting a maximum is a good idea. 

And that’s it for virtual machines.