Hello and welcome back to Cyber Aires. Microsoft Azure Administrator A Z 103 course I'm Will Carlson. And this is Episode 31 about virtual machine availability zones and availability sets.
In today's episode, we're gonna talk about the concept of an availability zone and what it's designed to guard against. We're going to deploy a virtual machine to an availability zone,
and then we're gonna move on to discussing the concept of an availability set what it is, what it was designed to guard against. And we're also gonna configure of'em in an availability set.
But first of all, I want to talk about some of the downtime items that may impact your azure environment, particularly the top three here that are things that Microsoft is planning and mitigating against with a number of solutions.
The 1st 1 is gonna be a planned maintenance event and those air gonna be events that happened because Microsoft is maintaining the hyper visor and all of the underlying infrastructure that makes the azure environment run.
Most of these updates are not going to impact your azure environment whatsoever.
Then we move on to unplanned hardware maintenance, and these were gonna be maintenance events that are triggered by the azure fabric when it senses that something in the environment is likely to fail or is about to fail.
When this happens, Microsoft is goingto live. Migrate your virtual machine workloads off of the failing hardware and on toe healthy hardware.
However, depending on the workload, you may notice this migration. The migration process could pause your virtual machine workload for a short period of time and shortly before and shortly after the migration, there may be a bit of service degradation,
the last event here that Microsoft is trying to guard against. There's going to be unexpected downtime, and these can include any local failures, either within the network of the data center that your workloads are housed in, or even within the Cabinet that you're workloads are housed in as well.
When there is unexpected downtime, the same live migration and the azure fabric kicks in, and it attempts to move your workload onto healthy
hardware. However, this most often will require a reboot and in some cases, a loss of the temporary disks that we discussed previously
in the last downtime event that your azure environment is likely to experience is actually all a whole host of other downtime events that could happen because of your infrastructure because of the operating system, because of the application that you're running, any of the normal downtime events that we have in our administrative life are gonna fall into this fourth category here.
So the real question is, is what is Microsoft doing? And how can we architect our systems here in Azure to help avoid these problems? And the first way we can do this is through the concept of an availability zone.
Now we've talked about azure regions already. An azure region is just a geographic area. Let's use South Central as an example or central us is another example. And within this region or rather within some regions,
Microsoft has multiple data center facilities that are relatively close to each other and connected by
high band with low latent seat network connections. And each of these availability zones as a separate data center has redundant power cooling and networking.
What this solves to do when you have workloads across multiple availability zones? Is it guards against a zonal failure or a single data center failing? So your data is still in one region, but it's across multiple data centers. So if there's a data center level failure,
your workload still continue to run.
The next concept here, under high availability for Azure, is going to be that of availability sets. Now, availability sets are a little different than availability zones. Availability zones exist to protect you against a data center. Wide failure
availability sets exists to protect you against a server rack level failure. And there could be a couple of failures that occur at the server rack level. And the first of those is gonna be a fault Domain and a fault domain is simply a set of equipment that's ultimately impacted by
one single piece of other equipment or another group of other equipment. And think about this again
as our entire server rack of the server rack is gonna have redundant switching. But ultimately at that switching fails. The entire rack is gonna be impacted by that. If the power fails for an entire rack again, the entire rack of equipment is going to be impacted by that, so that would make up a single fault domain.
An update domain is going to be a logical construct here within the azure fabric that allows Microsoft to safely reboot and update a single update domain and know that they're not going to impact a completely separate update Domains
and again to clarify a fault domain and updated remain are part of an availability set, and an availability set is designed to guard against an equipment level or a rack cabinet level failure, whereas an availability zone is meant to protect us against a data center level failure.
Now that we have those fundamentals under our belt, we're gonna go ahead and step into portal and begin deploying some virtual machine workloads in availability zones and availability sets.
We're gonna come in here to virtual machines were gonna click on add to add a new virtual machine. And for the most part, we're gonna leave all of this a default settings. We do have to create a resource group or select one. I'm gonna go ahead and create a new one.
It's like, OK, name the virtual machine
and we're gonna leave this in the south central region to illustrate the fact that availability zones are not available in all regions. And that's gonna be because Microsoft does not have three data centers available to them in every region. So
availability zones are gonna be dependent upon the region that you select. So if I change this from us South Central to U. S Central,
I now have the ability to deploy this virtual machine into an availability zone.
And we can see here that I get to choose which availability zone I'm deploying this virtual machine into. There are three availabilities own options. The one that you choose isn't necessarily important. So we're gonna go ahead and select availability Zone one
gonna make this a Windows workload to simplify the password solution down here and into my credentials.
I'm gonna go ahead and leave. Everything else is default, and we're gonna review and create this virtual machine in an availability zone.
Now that our deployment is complete, we're gonna go ahead and click on go to resource and see that this virtual machine looks very much like any of the other virtual machines that we've deployed so far.
And in large point of fact, it is just like any other virtual machine, except that exists and is set up in an availability zone, not keep in mind that simply deploying one virtual machine in tow. One availability zone does nothing for us if the availability zone this virtual machine is running in
availability Zone one in central us.
we lose the access to this virtual machine.
So the solution here, ultimately, when deploying virtual machines into availability zones, is to deploy two identical virtual machines into two different availability zones.
Then we come into the question of how we manage traffic to each of these virtual machines. And that's gonna be through the use of something called a load balancer, which you may have experienced in your professional career so far. And Azure has an equivalent with a few different flavors that you can use as well.
So you would put two virtual machines in two different availability zones,
and you would put them behind a load balancer, and the load balancer would handle passing the traffic to the virtual machine that was online and avoiding the one that may be off line.
This is another great pointer or benefit to arm templates. If you have regular workloads that you need to deploy into availability zones fronted with a load balancer, you could set up an armed template that does that and simply point and click fell out the parameters and the arm template would deploy. All of the resource is
instead of you, is the administrator having to go in and separately, set up each virtual machine
and the load balancer itself.
We're gonna move on now to the concept of an availability set and again, availability sets exist to protect us from Cabinet level failures within a data center, whereas this availability zone set up exists to protect us from data center wide failures.
And in order to do this, we're gonna go ahead and come up here to create a new resource,
and we're gonna search for availability.
We're gonna click on availability set,
but the first thing we're gonna do is actually create the container, as it were of the availability set.
We're gonna leave this in the free trial. We're gonna go ahead and create a new resource group,
and I want to call your attention to this location here. So the location of an availability set is important because you're gonna have to deploy the virtual machine work loads into the same region as the availability set If you want to take advantage of the availability set,
we're gonna go ahead and leave this at U S central
and you can see here that we can change the number of fault and update domains again. A fault domain exists to protect us against, ah, hardware level failure in the cabinet and then update domain is a logical way for azure to keep up with what's being updated to ensure that it doesn't affect multiple things in multiple update domains.
Tool tips here are really quite helpful. These air actually ceasing to believe it or not,
I highly recommend if you see the tool tips hover over him, see what they're all about.
Use managed disks is an option here. For the most part, it's recommended to use manage discs for your virtual machines. So you can simply leave this at Yes, that's gonna enable Azure to be a little more intelligent about how it manages fault and update domains all the way down through to the storage.
Now we're gonna create this availability set, and now that that deployment is done, we can come in and deploy a virtual machine into that availability set.
This is very much similar to the availability zone process. We're gonna come in.
Same thing we did before
we're gonna name is virtual Machine. Pick the region. Now you'll see here if we sick select availability said
I have nothing here. I don't have any availability sets and the South Central US region. Now, thankfully, I could go ahead and create one from here. Or I can come down and change this to us Central, where we created the availability, said already select that
and then review and create this virtual machine.
Now, availability sets are going to be dependent upon the same thing that an availability zone is as soon as I have two identical virtual machines running identical workloads. I need to be able to effectively route traffic to the healthy virtual machine. And that's gonna be done with a load balancer.
We're gonna talk quite a bit more about load balancers in the networking section.
Just keep in mind that this is how you do the virtual machine. Part of availability sets and availability zones will handle the load balancing network piece in an upcoming episode.
So in this episode, we called out the concept of what an availability zone is that essentially, it's multiple data center facilities that are segregated and discreet but interconnected within an azure region, and it helps guard against data center level failures.
We also talked about availability sets and how they help protect us against Cabinet level failures, both for updates and also for hardware level failures. And we step to the process of configuring or adding a virtual machine to both an availability set and availability zone.
Keep in mind if all you deploy is one virtual machine tow Either of these options. You have not increased your redundancy and resiliency whatsoever.
You have to have two virtual machines in each of these products when you do so. Microsoft has relatively high levels of SL requirements, for example to virtual machines, and an availability zone gives you four nines up time s L A.
Coming up next availability sets really are great. But if we want even more automation to this type of high availability and scalability, we have another option in a virtual machine scale set. Thanks for joining me. I'll see you in the next video