Learn about the importance of availability sets, and fault and update domains, including how virtual machines are spread across the domains ensuring the virtual machines are always available.
- [Instructor] Just as we do on Premise, in Azure, we have to design for high availability and redundancy when planning our infrastructure. Availability sets provide this redundancy for your virtual machines and applications by leveraging fault and update domains. Let's start off with the reasons why your virtual machines may be rebooted. Typically, this is because of maintenance. Remember, Microsoft is responsible for everything from the concrete up to the high provider level. This means that the host virtual machines need to be updated.
And just as we do on Premise, we'll have scheduled updates. After an update, the host machine may be rebooted, which will mean that your guest operating systems will also be rebooted. Next, we have unplanned maintenance. This is typically because of a physical failure. And, as before, after the failure has been corrected, the machine will be brought back up, and your guest OS may be rebooted. Let's go ahead and take a look at how the Azure fabric is set up and why, during one of these outages, your virtual machines may be down or rebooted.
As you can see here, we have three fault domains and, within our fault domains, we have some racks, and within those racks, we have virtual machines. Each of these fault domains share a power supply and a network switch. If there is a failure in any of these fault domains, then all the resources in that fault domain will become unavailable. This means that your virtual machines that were sitting in that fault domain will not be available to you. So, how do we prevent this? Well, we do it with availability sets. Just because your virtual machines are in the cloud, don't think Microsoft is providing backups and high availability for you.
Availability sets spread your virtual machines across the fault domains, ensuring that if one fault domain is unavailable, that your virtual machines in another fault domain are still available. Availability sets are required to meet the 99.95% SLA from Microsoft. This excludes VMs that are configured with premium storage. You will group similar virtual machines together in availability sets. For example, all your web service would be in one availability set, and your SQL servers in another availability set.
Let's take a look at an example. In this example, we'll go ahead and add in our availability sets. As you can see here, I have web one, two and three in an availability set, which is spread out through three VMs across the three fault domains. And I have done the same for database one or DB one, two and three. If fault domain two fails, the other virtual machines within those availability sets are still up and running because they are not affected.
If you require high availability, this is what you must do. Let's go ahead and take a look at the Microsoft Best Practices for our availability sets. As we've already stated, you'll need to group two or more similar virtual machines within an availability set, the virtual machines need to be created in the same resource group as the availability set, and keep in mind, your virtual machines can only be in one availability set. You cannot spread across availability sets. You will want to determine the number of availability sets needed based on the roles and tiers, and you'll want to do this before we start provisioning your virtual machines, as you can only assign virtual machines to availability sets during the creation of the virtual machine.
Next, create separate storage accounts for each of your virtual machines. And finally, consider your naming conventions. I recommend that you keep them logical. I know naming your resources after your favorite Star Trek series is fun, but in Azure, you will want to use descriptive and logical names for your resources and then keep those naming conventions consistent. Next, we have our update domains. Update domains are used for patching of the host VMs, and only one update domain is updated at a time.
All the virtual machines within that update domain will reboot together. The nice thing is that virtual machines are assigned to an update domain automatically when you put your virtual machines into an availability set. Now, let's go ahead and take a look at how virtual machines are spread across the fault and update domains after they've been put into an availability set. I'm going to start off with ASM, the Azure Service Manager, or classic mode of Azure.
In this classic mode, we only actually have two fault domains to work with. As I have already said, we don't have to manage the update in fault domains, but we do need to understand how our VMS are assigned to these update and fault domains for us. The good news is it's done sequentially, which makes it easier. By default, we have five update domains and two fault domains within the classic mode. When we create VM1, it will be put into update domain zero and fault domain zero.
Our second VM will be put into update domain one and fault domain one. Next, VM3 will be put into update domain two, but fault domain zero. Again, remember, there is only two fault domains in the classic mode. VM4 will be put into update domain three and fault domain one. And where do you think VM5 will go? VM5 will be put into update domain four and back to fault domain zero. Let's take a look at the same thing in the new portal.
Here, we work with three fault domains and five update domains. But those five update domains can be increased to 20 if required. Let's go through the same exercise. So, VM1 will be placed in update domain zero and fault domain zero. VM2 will be put into update domain one and fault domain one. VM3 in update domain two and fault domain two. Okay, now this is where it gets tricky. Where's VM4 going to be placed? It will be placed in update domain three and fault domain zero.
Remember, we have three fault domains to work with here. And finally, VM5 will be put in update domain four and fault domain one. Now, let's put availability sets, fault and update domains together in one example. You'll notice here, we have our three fault domains, fault domain one, two and three. And we have two web servers, two line-of-business servers, and two database servers. First, we'll group our web servers into one availability set.
Our line-of-business servers will be grouped together in another availability set. And finally, the same will happen for our database servers. If any of these fault domains becomes unavailable, the other instances or VMs are still up and running. So, if we lose fault domain one, we still have all other servers available to us in the other fault domains. And if an update domain is rebooted, the virtual machines in the other update domains are still up and running because remember that virtual machines and our update domains will be rebooted together.
As you can see, we still have a virtual machine available in each of those availability sets to manage our traffic. Moving our infrastructure to the cloud requires the same attention to detail of not more. You are still responsible to ensure that your virtual machines are available at all times.
- Designing virtual machines
- Selecting appropriate VM SKUs
- Designing template deployment
- Deploying ARM templates via PowerShell and CLI
- Designing for availability
- Designing Azure Virtual Networks
- Azure VPN and ExpressRoute architecture and design