Microsoft has built-in several layers of resiliency into the Azure platform, but administrators still need to protect workloads. In this video, learn about availability sets, why you would use them, and how it makes virtual machines from becoming unavailable.
- [Instructor] When we plan our on-premises environment, we must account for outages and ensure that our servers are always available. Well, the same is true in Azure. We must plan for outages that may happen. There are three types of outages in Azure that you need to be aware of. First, there is the planned outage. These outages occur because Microsoft is patching, modifying hardware or performing other maintenance tasks. Typically, you'll be notified of the planned downtime and you don't need to do anything. Then we have the unplanned outages. These occur when a predictive failure is reported, like a local network failure or hard disk failure. Lastly, we have the unexpected downtime. This is when a virtual machine fails unexpectedly. If either an unplanned maintenance or an unexpected downtime occurs, the virtual machine will automatically be migrated to a healthy host. There are three ways that you can protect your virtual machines in your environment. We can use availability sets, availability zones, and scale sets. We'll be talking about availability sets and zones in this lesson, and we'll cover the scale sets in another lesson. Putting your virtual machines into an availability set will ensure you will always have one virtual machine up and running. Availability sets spread your virtual machines across fault domains, ensuring that if a VM is unavailable then another virtual machine is available. Availability sets are required for the 95.95% SLA from Microsoft. This excludes Premium Storage, there is a different SLA for that. And an availability set is not required when using Premium Storage. Virtual machines must be created within the availability set. You cannot add a virtual machine after it has been provisioned. Just like everything else in Azure, you need to plan your availability sets. First, how many tiers will you need? Typically, we group like services together. If you placed all of the virtual machines, both the front-end and back-end systems, in one availability set, all the virtual machines could be rebooted at the same time. To prevent this, the recommendation is to use an availability set tier for similar services. For example, all of your front-end web servers in one availability set, and all of your back-end SQL servers in another. Next, you'll need to think about how many virtual machines will be in each tier. You always want more than one virtual machine in an availability set, and at least one virtual machine should always be available. You need to be aware if you're adding virtual machines to an availability set, you will not be notified of any upcoming reboots since the expectation is that you have configured more than one virtual machine in that availability set. You'll also have to plan for a load balancer, which will distribute the traffic between multiple virtual machines. Using multiple virtual machines in an availability set with an associated load balancer ensures that in case of an outage, an instance will still be available to server traffic. When you add your virtual machines to an availability set, the virtual machine is automatically assigned to an update domain and a fault domain. A fault domain contains virtual machines that all share common networking and power resources, or as I like to think about it, as a rack of servers. Availability sets are spread across fault domains. There are three fault domains when you use unmanaged disks, this is not a Microsoft best practice. The best practice is to use managed disks, which will then be spread across two or three fault domains depending on the region. Your virtual machines are not only spread across fault domains, but also across update domains. Update domains are logical groups of virtual machines. The default number of update domains is five, but this can be increased to 20. When required, the update domain will reboot all of the virtual machines within that update domain at the same time. The other domains and the other virtual machines assigned to them will not be affected. Therefore ensuring a virtual machine is always available and only one update domain is restarted at a time. I've already mentioned that virtual machines are assigned sequentially to an update domain. As you can see in this chart, virtual machine one is assigned to update domain zero. Virtual machine two to update domain one. Three to two, four will be assigned to update domain three, and five will be assigned to update domain four. When you assign more than five virtual machines to an availability set, the sixth virtual machine is assigned to the same update domain as the first virtual machine. Again, I'm assuming we are only working with five update domains here. The seventh would be assigned to update domain one and eight to update domain two. Virtual machines one and six are in the same update domain, and will be rebooted at the same time. The other virtual machines in the other update domains will not be restarted at the same time as update zero would be. Now that we've discussed availability sets, fault domains and update domains, let's see how it looks when we combine the three. In our example here, we have three availability sets. We have availability set Web. This is our front-end availability set, and it is spread across fault domain zero and fault domain one. And those virtual machines have been assigned to update domain zero and update domain one. The second availability set, the Line of Business availability set is spread across fault domain zero and fault domain two, and update domain two and update domain zero. And finally, we have our back-end availability set. This is spread across fault domain one and fault domain two and update domain two and update domain one. If any of these domains or racks becomes unavailable, the other instances are still running. And if an update domain is rebooted, the virtual machines in the other update domains are still running as well. This configuration ensures that no one machine becomes unavailable. Let's touch on availability zones. Availability zones are in physically separate locations within an Azure region. Each zone has independent cooling, power and networking, and there are three zones per region. This protects against data center failure. When you use availability zones, you will have a 99.99% SLA. Microsoft suggests the following best practices when deploying virtual machines. Group two or more similar virtual machines in an availability set. The virtual machines need to be created in the same resource group as the availability set. Virtual machines can only be in one availability set, you can't share them across availability sets. Determine the number of availability sets needed based on the roles and your tiers. And finally, keep your naming conventions logical and consistent. Trust me, this will help you in the long run as you build out your Azure environment.
- Configuring high availability
- Deploying scale sets
- Creating virtual machines
- Configuring Azure Disk Encryption
- Managing virtual machine sizes
- Provisioning a virtual machine
- Automating VM deployment and configuration with templates
- Creating containers with AKS and ACI
- Creating web apps with Azure App Service