WEBVTT 00:00:00.000 --> 00:00:04.000 Welcome back to vSphere 8 in the real world, and now we're going to discuss high availability. 00:00:07.120 --> 00:00:14.400 So HA is basically a way of ensuring business continuity. It's making sure that we can 00:00:14.400 --> 00:00:20.160 continue to function in case of a failure. Of course, that depends on how drastic our failure 00:00:20.160 --> 00:00:23.920 is. So what we're talking about here is like a host failure. We have a certain host that's failed, 00:00:23.920 --> 00:00:27.360 and we want to make sure that we can continue running when this happens. 00:00:28.799 --> 00:00:37.520 HA is not DRS. They're two different services, and DRS is a way of balancing the workload 00:00:37.520 --> 00:00:42.880 between our hosts. And so we see that a host is getting overloaded, its utilization is getting 00:00:42.880 --> 00:00:50.720 to be too high, and we're going to vMotion a VM from one host to another. Now, a pure HA in 00:00:50.720 --> 00:00:58.639 its simplest form means that a host failed, and so I need to start that VM on another host. 00:00:58.639 --> 00:01:04.959 With DRS, we don't have any downtime. With a very traditional HA configuration, 00:01:04.959 --> 00:01:09.919 there's going to be downtime. Hopefully, we can measure it in seconds or maybe like a minute or 00:01:09.919 --> 00:01:17.839 so. What will happen is that a host can fail, and then within seconds, the other host in the 00:01:17.839 --> 00:01:22.480 cluster realized that this host is down. We cannot communicate with this host. We know what 00:01:22.480 --> 00:01:28.239 VMs are on that host, and so now we need to restart those VMs and all the other hosts in our cluster. 00:01:28.239 --> 00:01:34.879 This is determined in advance. The hosts have already decided that these VMs are on this host. 00:01:34.879 --> 00:01:40.480 If this host goes down, then the VMs start up here. If this host goes down, the VMs start up 00:01:40.480 --> 00:01:44.800 here. The reason why it's important to note that is some people have been hesitant in the past. 00:01:44.800 --> 00:01:48.239 I don't think that's so much the case anymore because people realize how this works now. 00:01:48.239 --> 00:01:53.519 In the past, though, they did not want to have a virtualized vCenter server because if the host 00:01:53.519 --> 00:01:58.000 running vCenter were to go down, then how is HA going to run? It's because it's already been 00:01:58.000 --> 00:02:04.080 determined. vCenter does not determine if a host is up or down. vCenter does not tell the other 00:02:04.080 --> 00:02:10.479 host in the cluster if a host is up or down. They decide this amongst themselves. They figure it 00:02:10.479 --> 00:02:14.320 out amongst themselves, and there's different ways they can do that. It used to be back when 00:02:14.320 --> 00:02:20.080 we had very simple HA in the older version of ESXi. Basically, there's a heartbeat. If these 00:02:20.080 --> 00:02:27.199 other hosts could see that host HA heartbeat, it's online. If they can't, they can't. What 00:02:27.199 --> 00:02:33.199 sometimes happens is whatever the network HA was on, that might have an outage, but all the other 00:02:33.199 --> 00:02:39.119 networks may be fine. The storage is running. The VMs are running. Everything's fine on this host. 00:02:39.119 --> 00:02:46.240 Everything's running well, but the HA heartbeat for that host went down. The other host would say, 00:02:46.240 --> 00:02:51.279 oh, that host is down. We need to start its VMs up, but they're already running, and they're 00:02:51.279 --> 00:02:54.080 already running on the host they're supposed to be running on, and everything's fine. 00:02:54.960 --> 00:03:00.399 Now we also have other mechanisms in place besides that HA heartbeat. What that is, 00:03:00.399 --> 00:03:05.839 is we can have a datastore that HA is going to write to. All the hosts can see that datastore, 00:03:05.919 --> 00:03:10.880 and all the hosts are writing to that datastore, and they're saying, I'm checking in, I'm checking 00:03:10.880 --> 00:03:17.919 in, I'm checking in. What will happen is if the host that's running those VMs, 00:03:17.919 --> 00:03:23.199 if HA heartbeat goes down, it has other checks it can do, and it can say right in the datastore, 00:03:23.199 --> 00:03:28.240 hey, I'm still here. I'm still running my VMs. My VMs are fine. Everything's good. The other host 00:03:28.240 --> 00:03:33.039 will say, okay, we'll leave you alone. We'll let you run your VMs. Or the host can say, you know 00:03:33.039 --> 00:03:38.880 what? I'm having a problem, and I'm going to shut down my VMs, and it can write to that datastore. 00:03:38.880 --> 00:03:43.520 I'm shutting down my VMs, and the VMs go down, and then the other hosts know, okay, that host is 00:03:43.520 --> 00:03:51.119 down. It's having some issues. It has shut down its VMs, and now we're going to start up the VMs 00:03:51.119 --> 00:03:59.199 someplace else. We also have a form of HA that's a preemptive or proactive HA. If a host starts 00:03:59.199 --> 00:04:03.440 reporting problems, and often in event logs, the host is like, wow, problem, problem, problem, 00:04:03.440 --> 00:04:08.320 problem. All of a sudden, I'm getting errors on my power supply. I'm getting errors for my CPU. 00:04:08.320 --> 00:04:14.320 I'm getting errors in RAM. Something significant has happened, and this host is no longer considered 00:04:14.320 --> 00:04:21.359 to be trustworthy, stable, reliable, and we can preemptively HA, but in that case, we work with 00:04:21.359 --> 00:04:26.559 DRS to move the VMs off of that host, right? So, we'll re-motion them off in that scenario, 00:04:26.559 --> 00:04:31.200 but if something happens and the host just goes down, that means it's not writing to that 00:04:31.200 --> 00:04:36.160 datastore anymore. There's no HA heartbeats, and nothing's happening to let us know that that host 00:04:36.160 --> 00:04:40.640 is in any way still active and running those VMs. Then the other hosts in the environment have 00:04:40.640 --> 00:04:47.920 already determined if host A goes down, VM1 goes here, VM2 goes there. If host B goes down, then 00:04:47.920 --> 00:04:53.119 VM10 goes here, and VM11 goes there, that kind of thing. It's already determined. So, if the host 00:04:53.119 --> 00:04:58.480 running vCenter goes down, the other host will know that host is down. vCenter is one of the 00:04:58.480 --> 00:05:03.440 VMs on there. We're going to start that VM up like with any other VM, get it up and going again, 00:05:03.440 --> 00:05:09.119 all right? So, you don't need to worry about using a virtual appliance for vCenter and HA, 00:05:09.119 --> 00:05:15.679 because vCenter is not involved in figuring if an HA event has occurred or not. It's not involved 00:05:15.679 --> 00:05:20.880 in starting the VMs up someplace else. That was a concern for people for a while in the earlier days, 00:05:20.880 --> 00:05:26.399 like the 3, 5, and 4, and things like that. But even then, vCenter was not involved, 00:05:26.399 --> 00:05:30.160 because people didn't realize that, right? So, they always wanted a physical vCenter server. 00:05:30.160 --> 00:05:35.040 They wanted a physical Windows server running vCenter for reasons like that. And they're like, 00:05:35.040 --> 00:05:38.640 what if we don't know where it's at, which it didn't matter where it was at. We knew what host 00:05:38.640 --> 00:05:43.279 it was on, that kind of thing. Now, vCenter is only a virtual appliance. People understand better 00:05:43.279 --> 00:05:47.440 how HA works and things like that, and it's only available as a virtual appliance, okay? 00:05:48.079 --> 00:05:52.720 So, vCenter is a way of ensuring business continuity. If a host were to fail, 00:05:52.720 --> 00:05:56.880 we can get the VMs up and running very quickly on other hosts. We don't have to wait 00:05:56.880 --> 00:06:02.160 for an admin to be notified, and for them to get to a computer and log into the computer and say, 00:06:02.160 --> 00:06:06.880 oh, lookit, this server's down. What VMs are down? Oh, I think these ones are down. Let's 00:06:06.880 --> 00:06:12.320 start them someplace else. It's automated completely, so VMs are down, hopefully, 00:06:12.320 --> 00:06:18.320 only for minutes, not for half an hour, hour, two hours, however long it may be, all right? 00:06:19.279 --> 00:06:26.079 So, it keeps downtime to a minimum, and maybe with this preemptive HA to not at all, 00:06:26.079 --> 00:06:31.839 no downtime at all. If a server just all of a sudden blows up and catches fire out of nowhere, 00:06:31.839 --> 00:06:36.640 there's going to be downtime, right? But again, that downtime should be minimal, 00:06:36.720 --> 00:06:43.359 should be minutes while the other hosts turn up those VMs, okay? So, that's what HA's all about. 00:06:43.359 --> 00:06:48.559 That's what, you know, is meant by that business continuity, okay? So, high availability, 00:06:49.359 --> 00:06:53.839 you know, hardware backups, software backups, interoperability, administration control. So, 00:06:54.640 --> 00:07:01.600 admission control, what that means is that if I set up my HA cluster, and I'll show you how to do 00:07:01.600 --> 00:07:07.279 that, if I show up my HA cluster, I can say, I want to be able to survive one host failing, 00:07:07.279 --> 00:07:10.799 or I won't be able to survive two hosts failing, I won't be able to survive three hosts failing, 00:07:10.799 --> 00:07:15.519 right? If I have a large cluster of 30 hosts in there, maybe I want to be able to survive if 00:07:15.519 --> 00:07:20.320 three hosts were to fail on me, right? That's kind of a lot, but in a big cluster, that's, 00:07:20.320 --> 00:07:25.920 you know, a reasonable number. So, what will happen is, as hosts power on in that cluster, 00:07:26.799 --> 00:07:31.279 the, you know, things like reservations and things like that are all taken into consideration, and, 00:07:31.359 --> 00:07:36.000 you know, CPU size, what's being guaranteed, and, you know, what's necessary to run the VMs, 00:07:36.640 --> 00:07:41.839 is all looked at, and it says, okay, if a host were to fail, can I still run all the VMs? I power 00:07:41.839 --> 00:07:46.559 on another one, another one, another one, and as I'm powering on VMs, it's calculating every time 00:07:46.559 --> 00:07:52.880 I power on a VM, if a host were to fail, can I power on all the VMs? Or, if my number is set to 00:07:52.880 --> 00:07:58.239 two, if two hosts were to fail, can I restart all those VMs someplace else? And eventually, 00:07:58.239 --> 00:08:04.239 if you keep powering on VMs, eventually you'll get to a point where HA can't guarantee if a host 00:08:04.239 --> 00:08:09.440 fails, or two hosts fail, whatever your limit is set to, it can be a percentage as well. If, 00:08:09.440 --> 00:08:15.920 you know, 5% of my hosts were to fail, can I start up all the VMs that were on those hosts 00:08:15.920 --> 00:08:23.440 that failed? And if I can't, then what happens? You can tell HA that you want to still power on 00:08:23.440 --> 00:08:28.959 the VMs anyway, but you want to be warned, or just, nope, hard limit, we're not going to allow 00:08:28.959 --> 00:08:36.080 VMs to power on that are going to exceed my HA threshold, meaning if, you know, those two hosts 00:08:36.080 --> 00:08:41.200 failed, I can't start up all their VMs again, so I'm not going to power on any more VMs. It's going 00:08:41.200 --> 00:08:46.880 to put a hard limit on that, so that you will be able to start everything up, and you might be 00:08:46.880 --> 00:08:52.159 heavily utilized on those hosts, but I can power everything up. So, the downside is, you don't want 00:08:52.159 --> 00:08:58.000 to set it to 50%, especially if you have a large cluster, and if you only have two hosts, then 50%, 00:08:58.000 --> 00:09:05.119 one host, same thing, right? But if I have 30 hosts, and I set it to 50% is my threshold, 00:09:05.119 --> 00:09:11.359 that means I can utilize 15. The VMs can be on all 30, but really, I'm only running enough workloads, 00:09:11.359 --> 00:09:17.280 really, to accommodate, you know, the need 15 hosts. I'm wasting half of my resources then, 00:09:17.280 --> 00:09:23.200 right? I have way too much, probably, in reserves, so that's something to consider, okay? 00:09:23.200 --> 00:09:29.760 So, data protection. So, one of the things about business continuity, obviously, is you want to 00:09:29.760 --> 00:09:33.760 make sure your VMs are backed up and some things like that. High availability is a piece of data 00:09:33.760 --> 00:09:38.799 business continuity. Backing up your data is a piece of business continuity. Disaster recovery. 00:09:38.799 --> 00:09:44.000 Now, people sometimes think, well, that's kind of the same thing, right? And it's really not. 00:09:44.000 --> 00:09:50.479 DR and backup are two different things. Backup is meant for me to be able to restore an entire VM 00:09:50.479 --> 00:09:56.159 back into my environment, and if there's corruption on that VM, go back in time. I need to have 00:09:56.159 --> 00:10:02.799 versions of VMs, versions of files that I can go back to. That's the point of backup. Backup is, 00:10:02.799 --> 00:10:08.159 oh, look, this got corrupted, and it looks like, you know, it got corrupted a week ago. I want to 00:10:08.159 --> 00:10:13.440 restore that from before it got corrupted and start, you know, from that point, you can start 00:10:13.440 --> 00:10:19.359 going forward, whereas DR doesn't necessarily give you all that version history, right? 00:10:19.359 --> 00:10:25.679 Version history is backup. DR is every time a change is made to a VM, I'm going to replicate 00:10:25.679 --> 00:10:29.200 that change. I'm going to replicate that change. I'm going to replicate that change. Some DR 00:10:29.200 --> 00:10:36.880 solutions will allow you to, you know, start a VM in your DR environment at a certain point in time. 00:10:36.880 --> 00:10:42.080 It'll keep, like, so many seconds of, you know, versions of VMs, but that's not really what 00:10:42.080 --> 00:10:47.359 applications are about. When you look at a DR solution, you're not seeing versions. You're 00:10:47.359 --> 00:10:55.119 seeing how many seconds out of date is this copy of the VM from the production one that's running, 00:10:55.119 --> 00:11:00.239 and if you can keep that, you know, within, like, 30 seconds or so, that is fantastic. If you can 00:11:00.239 --> 00:11:04.559 get below 30 seconds, that's phenomenal. It's great. It means you have huge bandwidth between 00:11:04.559 --> 00:11:09.119 them and things like that. So, what a DR solution is going to do, disaster recovery, 00:11:09.119 --> 00:11:15.840 is this production environment failed, right? And it's down. The building caught fire, 00:11:16.400 --> 00:11:20.080 and I need to go to my DR environment, which is probably going to be a different building, 00:11:20.080 --> 00:11:25.280 maybe in a different region, different state, and I need to power everything up, and now run 00:11:25.280 --> 00:11:31.359 all of everything that was here over here, and a backup solution will restore a VM for you 00:11:32.320 --> 00:11:39.359 exactly how it was. So, my address was 192.168.5.20 on that VM. Backup is going to restore 00:11:39.359 --> 00:11:44.479 it, and I'll have the same IP address. A DR solution might go in and say, well, over there, 00:11:44.479 --> 00:11:50.000 you were 192.168.5.20, but over here, we have a different IP scheme. So, over here, I'm going to 00:11:50.880 --> 00:11:57.840 IP this one at 172.16.5.20 or something like that. We have a different IP scheme over here, 00:11:57.840 --> 00:12:04.559 and so part of DR is going to be bringing up those VMs and re-IPing them in this new environment. 00:12:04.559 --> 00:12:10.799 That's a DR solution. So, Veeam is an example of a data protection of backup solution, right? 00:12:10.799 --> 00:12:16.400 There's lots of them out there. This is an example of one. Zerto is not a backup solution. Zerto is 00:12:16.400 --> 00:12:21.840 a DR solution. So, when you look at Zerto, you don't see that you have, you know, 10 different 00:12:21.840 --> 00:12:27.919 copies, and you have, you know, one copy of this VM, one backup of this VM, you know, for the last 00:12:27.919 --> 00:12:33.200 day, and one from two weeks ago, and one from six months ago. I see that this is just in synchronized 00:12:33.200 --> 00:12:38.719 from the production to my Zerto environment, and we're within 45 seconds, right? And that number 00:12:38.719 --> 00:12:44.159 might go down. It might go up, but, you know, it'll tell you how in sync it is from production. 00:12:44.159 --> 00:12:48.479 That's disaster recovery. That's something like what Zerto would do versus Veeam. That would just 00:12:48.479 --> 00:12:52.960 make a copy, and then make another copy, and keep old copies, and say, okay, now I've got so many 00:12:52.960 --> 00:12:57.679 copies and start deleting older ones. That's what backup is. That's data protection. So, they're 00:12:57.679 --> 00:13:02.799 very different things. People sometimes will kind of talk about them as the same, and they're 00:13:03.520 --> 00:13:08.400 definitely not. They're very different functions, different purposes, different use cases, all right? 00:13:10.559 --> 00:13:13.679 So, ensuring business continuity with high availability, 00:13:14.239 --> 00:13:20.799 vMotion is possible with a, you know, with a predictive or preemptive HA solution. 00:13:21.359 --> 00:13:26.880 Replication, so replicating, you know, VMs from one place to another. So, maybe our SAN does 00:13:26.880 --> 00:13:31.119 replication for us. Zerto also does replication for you, things like that, and high availability 00:13:31.119 --> 00:13:36.400 solutions, right? High availability. A host failed, and I want to start that VM up on other hosts in 00:13:36.400 --> 00:13:42.960 that environment. So, HA isn't really a DR solution. So, I'm not saying this entire cluster 00:13:42.960 --> 00:13:47.840 failed, the entire data center running these VMs failed. I'm saying a host failed in a cluster, 00:13:47.840 --> 00:13:51.440 and all, there's plenty of other resources that are very healthy in a healthy environment 00:13:51.440 --> 00:13:57.679 to start that VM. I'm going to do a disaster recovery if all the hosts in my cluster failed, 00:13:57.679 --> 00:14:02.159 and maybe that happened because there was like a power outage or something significant, and, 00:14:02.159 --> 00:14:06.320 you know, it's going to run for so long that the batteries can't keep up. Now, I'm going to DR it. 00:14:06.320 --> 00:14:10.880 I'm going to fail it over to this other environment over here that still has power, okay? 00:14:11.440 --> 00:14:15.679 Data protection is also a beast for data protection, for instance, replication and things like that. 00:14:15.679 --> 00:14:17.840 You're probably going to use some kind of third-party solution for that. 00:14:19.599 --> 00:14:25.200 So, an HA cluster. So, you need to have at least two hosts. Really, you want more than two. One of 00:14:25.200 --> 00:14:30.799 the things that's important that VMware really is great about evangelizing is when you're dealing 00:14:30.799 --> 00:14:37.919 with your environment, you want whatever you, you know, whatever resources you need, plus, 00:14:38.159 --> 00:14:43.760 plus, in case of a failure, plus one, right? So, they don't really just say you want to have 00:14:43.760 --> 00:14:47.919 N plus one. So, you like, you know, you need three hosts plus one more for a disaster. 00:14:47.919 --> 00:14:51.359 They want, you want to have N plus one, and they'll say, you know, plus two or N plus one, 00:14:51.359 --> 00:14:55.840 plus one, and why would you want that? Because maybe I'm patching a host, and while I'm patching 00:14:55.840 --> 00:15:00.559 a host, that host is in maintenance mode. That host is no longer available. You still want your 00:15:00.559 --> 00:15:06.400 N plus one capability, even if a host is in maintenance mode and being patched. So, if 00:15:06.400 --> 00:15:10.880 another host that isn't in that, you know, the one being patched were to have a failure, 00:15:10.880 --> 00:15:16.000 a process error to fail or something like that, you want the VMs on that host to be able to be 00:15:16.000 --> 00:15:21.359 started, right? So, that, we're that N plus one, plus one, because one is for maintenance mode, 00:15:21.359 --> 00:15:26.559 for, you know, patching and updating, plus you still have your failure. They really talk about 00:15:26.559 --> 00:15:30.960 that a lot, evangelizing that a lot when we talk about vSAN, because that's the actual data, 00:15:30.960 --> 00:15:36.080 right? I mean, if you lose multiple copies of VM, it's just gone forever. The zeros are just, 00:15:36.080 --> 00:15:40.799 you know, in the air and gone forever. But it's not only true for vSAN. Again, 00:15:40.799 --> 00:15:44.159 they talk about that a lot with vSAN, and it's, you know, for very good reason. 00:15:44.960 --> 00:15:49.679 But they also talk about that in other environments. So, if you're, you know, 00:15:49.679 --> 00:15:55.760 what you need is an N plus one or an N plus three, then you want actually N plus four. Or, you know, 00:15:55.760 --> 00:16:00.239 if you have an N plus one, you want, you actually want N plus two, because you want whatever your 00:16:00.239 --> 00:16:06.000 company's standard is for recovery. You know, if that happens to be an N plus two, 00:16:06.559 --> 00:16:11.919 you, well, if I'm patching, I have a host down for patching, I no longer have N plus two. So, 00:16:11.919 --> 00:16:18.080 now I need to add another one and actually be an N plus three, if my company standard is N plus two, 00:16:18.080 --> 00:16:21.679 right? So, that's just something to consider, right? So, let's say you need to have at least 00:16:21.679 --> 00:16:26.239 two hosts. You really, you want three, four, five hosts kind of thing. Small environments, 00:16:26.239 --> 00:16:31.919 I see it all the time where they only have two or three hosts, and if they lose two, 00:16:31.919 --> 00:16:36.000 meaning one's patching and one fails, they're going to not have all their VMs running for a 00:16:36.000 --> 00:16:42.960 little while. And the idea is there that eventually that host is going to be done patching within 20, 00:16:42.960 --> 00:16:47.039 30 minutes probably, comes back up, hopefully it's healthy, and then we can start up all the 00:16:47.039 --> 00:16:53.280 other VMs. So, that's something that you, with your business, have to take in consideration and decide 00:16:53.280 --> 00:16:57.919 what your acceptable risk factor is for things like that, right? So, we need to have at least 00:16:57.919 --> 00:17:02.960 two hosts because, again, if one fails, the other one needs to run the VMs. We can't over-allocate 00:17:02.960 --> 00:17:10.239 resources in scenarios like that. So, one host has two VMs running. The other host will have 00:17:10.239 --> 00:17:15.760 no VMs on it because, again, we perform a failover. VMs running application that clients 00:17:15.760 --> 00:17:20.400 are accessing. So, what happens in this scenario is that the VMs are running, the clients are 00:17:20.400 --> 00:17:26.000 accessing the VMs, and there's resources being used on that. So, how can you protect that process 00:17:26.000 --> 00:17:31.599 on that VM if the host is showing signs that it may fail soon? Well, that is when predictive HA 00:17:31.599 --> 00:17:36.800 is going to come into effect and it can just move things over for us. So, then we don't see downtime. 00:17:36.800 --> 00:17:42.000 If we see that we're going to have hosts having problems and we can predict it, 00:17:42.000 --> 00:17:46.640 we can then do a preemptive HA, right? That's one possible solution. 00:17:47.199 --> 00:17:52.640 So, here we're looking at, we have our ESXi host 2, we have EFX host 1 with a VM on it. 00:17:52.640 --> 00:17:58.479 They're in an HA cluster. Host 1 were to fail, the VM is going to, and this is really important, 00:17:58.479 --> 00:18:05.439 the VM restarts on the other host. Sometimes, you know, I've had people ask, so, if I have HA, 00:18:05.439 --> 00:18:11.680 then a VM motions the VM to the other host. In traditional, very basic HA, no, because the host 00:18:12.640 --> 00:18:17.280 failed. The host failed, the host caught on fire, it's no longer serving resources, 00:18:17.280 --> 00:18:23.439 and it was unexpected. That VM isn't running to vMotion over. It's going to be restarted 00:18:24.000 --> 00:18:29.280 on that new host, okay? So, was there downtime? Yes, there was downtime. Was the downtime measured 00:18:29.280 --> 00:18:33.760 in hours? No, it was probably measured in single-digit minutes, you know, three, 00:18:33.760 --> 00:18:36.560 four, five minutes, maybe at the most, maybe less than that, depending upon 00:18:37.280 --> 00:18:43.359 how quickly the HA cluster, you know, realized the downtime and how large was the VM that needed 00:18:43.359 --> 00:18:47.199 to be booted up and services to start and things like that. But it can be a very short amount 00:18:47.199 --> 00:18:57.439 of downtime. So, active, passive, and witness nodes. So, with HA, really, you need three nodes 00:18:57.439 --> 00:19:01.839 to make it work. So, how can I do it with two? I can have my active passes, and I can have what's 00:19:01.839 --> 00:19:06.319 called a witness node. And that witness node could actually be an ESXi host, for example, 00:19:06.319 --> 00:19:11.839 in another cluster, right? They can both talk and communicate to it. And so, because otherwise, 00:19:11.839 --> 00:19:18.479 they'd only have the two. And let's just say neither one are down, but there is a breaking 00:19:18.479 --> 00:19:23.920 communication between them. Well, they both think they're running, right? So, they need a witness 00:19:23.920 --> 00:19:29.520 to say, do you see me? Yes, I see you. The other one, do you see me? Do you see me? And when it 00:19:29.520 --> 00:19:33.359 doesn't respond, oh, it's me that's down. It's my network that's down. That's why I can't see 00:19:33.359 --> 00:19:37.520 the other one. And again, we do have things like data stores and things like that as well. 00:19:38.079 --> 00:19:42.479 If I had a larger cluster, let's say I had three nodes in my cluster, and one would lose 00:19:42.479 --> 00:19:47.439 communication, the other two will ask, do you see me? And they both say, yeah, I see you. 00:19:48.000 --> 00:19:52.719 Okay, we know we're good. Can we see him? Nope, he's the one that's down. We need to look at his 00:19:52.719 --> 00:19:58.319 VMs and get his VMs up and running. Or the one that's isolated will ask, can you see me? Can 00:19:58.319 --> 00:20:03.040 you see me? No response. It's me. All right. And then what do you do? That's an option you can 00:20:03.040 --> 00:20:07.280 configure, and when you configure HA, is do I shut down my VMs, or do I leave them running? 00:20:07.280 --> 00:20:11.760 This is a host isolation incident. And probably most of the time, you're going to say, shut down 00:20:11.760 --> 00:20:16.560 my VMs. This is a host isolation incident. Shut down my VMs so the other host can start them up. 00:20:16.560 --> 00:20:20.959 It's possible that the problem is just on the HA network, and the other networks are running fine, 00:20:20.959 --> 00:20:26.640 the VMs are running fine. But it's also very possible that they're not, and how do you know? 00:20:26.640 --> 00:20:30.719 So to be safe, shut down the VMs, let them start someplace else. You will have a little bit of 00:20:30.719 --> 00:20:35.839 downtime. You're probably going to get some help. That's tickets really fast. But before the tickets 00:20:35.839 --> 00:20:41.040 can even be addressed, the host should have those VMs restarted, okay? So a witness node is just 00:20:41.040 --> 00:20:48.319 simply a node that isn't part of the HA cluster that will, you know, basically identify who it 00:20:48.319 --> 00:20:51.520 can see, who it can't see if there's some kind of host isolation response, okay? 00:20:52.079 --> 00:20:59.839 So ActiveNode runs with a vCenter server instance, right? Has a public-facing IP address, 00:21:00.479 --> 00:21:06.239 links to the management interface that the hosts are running on, used to reenact the passive and 00:21:06.239 --> 00:21:12.000 the witness nodes, okay? That's an ActiveNode. PassiveNode starts as a clone of the ActiveNode, 00:21:12.000 --> 00:21:17.599 right? Updates and synchronizes with the ActiveNode, so it exchanges information in there. 00:21:17.680 --> 00:21:22.880 ActiveNode fails, so the passive node can replace and become the ActiveNode. 00:21:22.880 --> 00:21:28.079 And then a witness node starts as a clone with the ActiveNode and prevents a split-brain. It 00:21:28.079 --> 00:21:32.959 doesn't do any of the other work other than it's just witness, CFIC, you guys are there, all right? 00:21:35.119 --> 00:21:38.880 So here we're just looking at, you know, we have our HA interfaces, management interfaces. So for 00:21:38.880 --> 00:21:43.359 the HA interface, they all can see and talk to each other. And then we have a management interface 00:21:43.359 --> 00:21:48.560 that is there for, you know, managing, you know, communications, connecting to vCenter, 00:21:48.560 --> 00:21:58.400 and things like that. So primary host, right, is our manager. And it can, you know, do things like 00:21:58.400 --> 00:22:02.640 monitor the state of the VMs, that kind of stuff, determines who's who in the cluster, 00:22:02.640 --> 00:22:05.599 and helps communicate, like, what's going to happen in case of an incident response, 00:22:05.599 --> 00:22:09.760 that kind of stuff. The secondary nodes are just running the VMs, right? They're running the VMs, 00:22:09.760 --> 00:22:14.319 they're monitoring the state of their host, what's going on, and they'll report any updates 00:22:14.319 --> 00:22:20.959 if anything changes to the primary. Admission control, we kind of talked about that. 00:22:20.959 --> 00:22:26.000 So you want to make sure if you're running HA that you have enough resources available 00:22:26.000 --> 00:22:32.880 so that if there is a failure that you can start all the VMs. So you will say you won't allow, 00:22:32.880 --> 00:22:38.800 you can say that you won't allow more VMs to start, then the cluster can run and meet all 00:22:38.800 --> 00:22:45.119 the reservations and things like that in case of a failure of how many hosts? X number of hosts. 00:22:45.119 --> 00:22:50.400 You can determine what happens there, right? And then what happens, you know, are you going to 00:22:50.400 --> 00:22:56.319 start the VMs or not start them? And then what happens when there is a failure, right? You can 00:22:56.319 --> 00:22:59.839 control, you know, whether VMs are shut down and running and that kind of thing, right? 00:23:01.119 --> 00:23:05.119 So you can say that you want to basically keep reserved a certain amount of resource 00:23:05.119 --> 00:23:14.880 in your cluster for HA recovery, all right? So admission control often determined as a 00:23:14.880 --> 00:23:21.199 percentage of a resource. So you could say in my cluster I have 30 hosts and I want to be able to 00:23:21.199 --> 00:23:25.920 handle, you know, if 10 percent of my cluster were to fail, 10 percent of your cluster, that's three 00:23:25.920 --> 00:23:32.560 hosts out of 30, right? You can also say that you want to be able to specify a number of hosts 00:23:32.560 --> 00:23:36.880 failing. So I can say I want to be able to handle two hosts failing. You can say two hosts or you 00:23:36.880 --> 00:23:41.280 can say three hosts or whatever number you want. And the reason why people sometimes use a 00:23:41.280 --> 00:23:49.439 percentage is because they can then add and remove hosts which are resources from the cluster. And 00:23:51.119 --> 00:23:57.359 the number of hosts that can fail is going to dynamically, you know, move with the number of 00:23:57.359 --> 00:24:02.239 hosts in that cluster. If I were to say I want to be able to survive three and then over time I take 00:24:02.239 --> 00:24:06.719 hosts out of the cluster, all of a sudden three might be way too many. But if I said 10 percent 00:24:06.719 --> 00:24:12.239 and I take hosts out of the cluster, when I'm down to 20, now it's only two, right? So using 00:24:12.239 --> 00:24:17.119 a percentage like that makes it easier to add and remove hosts. And if that's something that you do 00:24:17.119 --> 00:24:22.719 in your environment often, then that's a useful configuration. If you have a very static 00:24:22.719 --> 00:24:27.920 configuration, I have these 15 hosts, it's always going to be this 15 hosts. It would be like a 00:24:27.920 --> 00:24:32.880 significant, you know, change to our environment. It's very unusual. If we added the 16th or took 00:24:32.880 --> 00:24:38.239 away the 15th and only had 14, that kind of thing, then, you know, then maybe you might 00:24:38.239 --> 00:24:42.319 want to say the number of hosts. But most people would go with a percentage. That's just common, 00:24:42.319 --> 00:24:52.079 all right? So interoperability. So HA does work with other services like vSAN, for example. 00:24:52.079 --> 00:24:57.280 It can work with DRS. So with DRS, if we have preemptive HA. With vSAN, what happens, 00:24:57.280 --> 00:25:05.599 because vSAN keeps multiple copies of VMs on different hosts, right? So the host that's running 00:25:05.599 --> 00:25:11.520 the VM always has a copy of that VM. And if I'm running on an N plus one, that means the host 00:25:11.520 --> 00:25:17.359 running the VM has a copy of that VM on its, you know, disk on vSAN, and another host has a copy. 00:25:17.359 --> 00:25:23.280 Well, if the host that's running this VM fails, now I only have one copy of that VM. So I might 00:25:23.280 --> 00:25:28.959 start up that VM on the host that is running that VM, but I'm going to let vSAN know that we 00:25:28.959 --> 00:25:34.319 need to make another copy. So HA is going to let vSAN know, okay, we're going to start up the VM 00:25:34.319 --> 00:25:39.760 on the host with the other copy, but we're also going to make another copy. vSAN will say, 00:25:39.760 --> 00:25:44.719 make another copy of that VM someplace else so we can get back to our N plus one, right? 00:25:44.719 --> 00:25:49.359 If we're doing an N plus two, then I'll have two places to pick from to start up that VM, 00:25:49.359 --> 00:25:53.359 and, you know, then I'll start up and create, again, another copy to replace the one that 00:25:53.359 --> 00:25:59.760 failed. So it does work with vSAN in communicating, one, where copies of the VMs live, as well, 00:25:59.760 --> 00:26:10.000 making sure we have copies of VMs being made. So HA clusters are great. They do reduce downtime. 00:26:11.040 --> 00:26:14.880 You don't need to reconfigure a VM if a host fails. So if a host were to go down 00:26:14.880 --> 00:26:20.479 and completely fail, I don't have to go to another host, browse the storage, find that 00:26:20.479 --> 00:26:26.400 VM on my shared storage, and import the VMX file to get the VM to come in and power it on and find 00:26:26.400 --> 00:26:31.359 out which ones are down, that kind of thing. It'll just automate that process and keeps downtime to 00:26:31.359 --> 00:26:41.119 a minimum, again, minutes. So HA with DRS. So we can preemptively move VMs around. 00:26:41.760 --> 00:26:48.160 What also happens, though, when there's an HA event, we don't look and see, you know, 00:26:48.160 --> 00:26:55.359 what host has the most resources, where's the best place. It just starts VMs up on the first host 00:26:55.359 --> 00:26:59.439 that's available, right, and then the next, and then the next kind of thing. So what can happen 00:26:59.439 --> 00:27:05.119 is we might end up finding that we have, out of our, you know, 30 nodes in our cluster, two or 00:27:05.119 --> 00:27:10.400 three hosts are really overworked now because an HA event happened and we started up a bunch of VMs. 00:27:11.680 --> 00:27:17.839 Then what will happen is DRS will say, okay, you're done, you did your thing, all the VMs 00:27:17.839 --> 00:27:23.680 are running, good job, now let's balance out the cluster. Let's move VMs around using DRS 00:27:23.680 --> 00:27:28.959 to balance the cluster out better so if another host were to fail, one of those hosts, we don't 00:27:28.959 --> 00:27:33.439 lose so many VMs on that host, and we get better resource utilization, better performance for our 00:27:33.439 --> 00:27:41.199 VMs, all that kind of stuff, right? So that's basically how DRS works with HA. 00:27:44.000 --> 00:27:49.040 So for an HA cluster, what do we need? A minimum of two hosts, only two hosts and a witness, 00:27:49.040 --> 00:27:54.400 but a minimum of two hosts, you probably, you know, want more than that. Persistent IP addresses 00:27:54.400 --> 00:27:59.680 on the host, so whatever VM kernel port is being used for this HA needs to have a static IP address, 00:27:59.680 --> 00:28:04.319 right? We need a common management network so VM kernel port that all of them can communicate 00:28:04.319 --> 00:28:12.719 on the same network, the same IP subnet. VMs to host compatibility across the board. So that means 00:28:12.719 --> 00:28:17.920 is that we don't want to have VMs that are using hardware features that the other hosts in the 00:28:17.920 --> 00:28:23.199 cluster don't have. If all of a sudden, you know, if one host has a special piece of hardware and 00:28:23.199 --> 00:28:28.239 it's running VMs and it fails, then that dependency might stop that VM from running 00:28:28.239 --> 00:28:31.839 and functioning properly on another host. We want to make sure we have hardware compatibility 00:28:31.839 --> 00:28:38.160 for all the hosts that are in our cluster, okay? VMware tools. So VMware tools are important if 00:28:38.160 --> 00:28:44.239 we're doing VM monitoring. HA can, we've been talking about this whole time about monitoring 00:28:44.239 --> 00:28:51.920 the host, but also HA can monitor VMs. So if a VM were to stop running, let's say Blue Springs, 00:28:51.920 --> 00:28:57.199 well then VMware tools heartbeat is going to stop too. And the host can say, oh, this VM 00:28:57.199 --> 00:29:01.199 has failed. VMware tools aren't responding. I don't see any heartbeat on the VMware tools for 00:29:01.199 --> 00:29:07.920 this VM. And then it'll start that VM up again, restart it on a different host. And then different 00:29:07.920 --> 00:29:13.119 hosts is just important because what if whoever caused this problem was host specific? And the 00:29:13.119 --> 00:29:16.800 reason why it failed was something was wrong is going on with this host. I don't want to start 00:29:16.800 --> 00:29:20.719 up on the same host again, have the same problem again. So I started up on a different host just 00:29:20.719 --> 00:29:25.920 to make sure it's not a host specific problem. So VMware tools are important for VM monitoring 00:29:25.920 --> 00:29:32.560 with HA. Supporting IP protocols, okay? You need to have IP configured. So IP4, IP version 6, 00:29:32.560 --> 00:29:38.000 depending on what we're using, we need to have supported versions of IP protocols that all of 00:29:38.000 --> 00:29:41.760 our hosts can use. We don't want some hosts on 4 and some hosts on 6 and then they can't talk to 00:29:41.760 --> 00:29:50.479 each other. VMPC needs ESXi 6 or later. So we just need to, basically we're talking about we have 00:29:50.479 --> 00:29:53.199 vSphere 8, we're going to have them across the board, we're going to be just fine with all of 00:29:53.199 --> 00:29:57.760 that. And then you need to have a cluster. You need to create a cluster, put the host in a 00:29:57.760 --> 00:30:05.599 cluster, and then enable HA on that cluster. So configuring a cluster. So one of the things you 00:30:05.599 --> 00:30:12.479 can do is host failure. How many hosts are we going to allow to have a failure on in my cluster? 00:30:12.479 --> 00:30:18.079 It can be a percentage, it can be a number, right? Host isolation. What happens if there's a host 00:30:18.079 --> 00:30:24.479 isolation incident, right? So do you want the host to shut down the VMs that are running on it or do 00:30:24.479 --> 00:30:29.680 we want to keep running them? Most of the time, you're probably going to say shut down those VMs 00:30:29.680 --> 00:30:34.719 to make sure they can run on other hosts that are healthy still, okay? Now, data stores, 00:30:36.000 --> 00:30:41.839 if what can cause an HA response could be a data store issue, right? We could say a 00:30:42.800 --> 00:30:49.119 permanent device loss, which is a PDL. So a PDL being a permanent device loss, this data store is 00:30:49.119 --> 00:30:55.599 just completely gone. How are we going to respond to losing a data store on a host and we can't get 00:30:55.599 --> 00:31:01.119 it back but the other hosts still see it, right? Or, and more likely, you know, an all-path-down 00:31:01.119 --> 00:31:06.160 scenario is one host can't see but other ones can. And what would cause one host to not be able to 00:31:06.160 --> 00:31:11.280 see a data store anymore but another host can still see that data store? Our HBA could have failed. 00:31:11.280 --> 00:31:16.160 If we have, you know, special – not special, but, you know, 25-gig NICs that we use for our 00:31:16.160 --> 00:31:22.560 iSCSI storage and they're dedicated just to our iSCSI storage, which is ideal, maybe our switch 00:31:22.560 --> 00:31:28.160 didn't fail but maybe the iSCSI NIC, you know, failed if that is connected to our data store. 00:31:28.160 --> 00:31:33.040 So an all-path-down event is simply just saying that we can't access that data store. All the 00:31:33.040 --> 00:31:38.000 paths that we have are down. So maybe we have, like, one card with four ports and that entire 00:31:38.000 --> 00:31:43.119 card failed versus, like, a port failing or a cable failing, right? And then VM monitoring. We 00:31:43.119 --> 00:31:49.199 can also monitor VMs. So we want to enable VM monitoring and on our cluster or just monitor 00:31:49.199 --> 00:31:57.040 the hosts, right? Admission control. So we can specify the number of hosts in a cluster we want 00:31:57.040 --> 00:32:03.280 to allow to fail, right? So we have a failover capacity. It can be a percentage of resources. 00:32:03.280 --> 00:32:11.280 So slot policy. It used to be that we have what's called slots, right? And basically, a slot is a 00:32:11.280 --> 00:32:17.920 VM. How big is a slot? It used to be back in the, you know, four days and things like that, I think 00:32:17.920 --> 00:32:25.199 even, like, in 5.5, 5 and 5.5, that a slot was a set size for the entire cluster. And how big was 00:32:25.199 --> 00:32:30.880 that slot? Whatever our biggest VM was in our environment, that was our slot size. That was 00:32:30.880 --> 00:32:36.959 the size of the VM. So I might have, in my environment, one VM that was a beast that had, 00:32:36.959 --> 00:32:43.760 you know, 16 virtual CPUs and it had, you know, 100 gigs of RAM and whatever, you know, big VM, 00:32:43.760 --> 00:32:50.880 and all the rest were really small. But to HA, they were all the size of my biggest VM. So when 00:32:50.880 --> 00:32:56.880 I enabled admission control, I wasn't really getting the full, you know, size that I wanted to. 00:32:56.880 --> 00:33:02.160 Now slot size on the newer versions of ESXi, like in 7 and in 8, slot size is actually just 00:33:02.160 --> 00:33:07.199 basically it's dynamic and every VM has its own slot size. And so we can more accurately configure 00:33:08.319 --> 00:33:13.920 that. We can also specify a slot size. We say we want all of our VMs to be measured as, 00:33:14.479 --> 00:33:20.479 you know, this size CPU and this much RAM, that kind of stuff. Okay. We can have a dedicated 00:33:20.479 --> 00:33:25.760 failover host. A dedicated failover host simply means that if a host fails, I want this host over 00:33:25.760 --> 00:33:31.839 here to be running and set aside just for failovers. Okay. And I can disable failover 00:33:31.839 --> 00:33:39.680 capacity, which means I'm going to let as many VMs run in this HA cluster as the cluster can fit. 00:33:39.680 --> 00:33:46.560 And if a host were to fail, I'll start up as many VMs as I can. And when I can't start anymore 00:33:46.560 --> 00:33:51.760 because I can't guarantee resources for reservations and things like that, I stop running, 00:33:51.760 --> 00:33:57.280 you know, stop starting VMs. That is not obviously a recommended 00:33:59.119 --> 00:34:03.280 path because you don't know which of your VMs aren't going to start and you might get some 00:34:03.280 --> 00:34:08.159 high priority VMs that don't get started. Right. So you can do a percentage if you want to for 00:34:08.159 --> 00:34:15.520 your failover capacity. Obviously, the more hosts that fail, the more utilized your hosts get, 00:34:15.520 --> 00:34:19.600 your performance starts to degradate. Right. And are you going to allow performance degradation? 00:34:19.600 --> 00:34:23.439 Are you going to over-allocate? If you don't have reservations, then all your VMs are going 00:34:23.439 --> 00:34:27.199 to start. You'll be very over-allocated. Right. And that could be a problem. 00:34:30.239 --> 00:34:34.320 So, selecting a data store for the heartbeat. So, as I mentioned earlier, 00:34:34.320 --> 00:34:40.719 HA now can have a data store for the HA heartbeat for monitoring if, you know, 00:34:40.719 --> 00:34:45.040 HA is functioning properly for the hosts or if a host is functioning properly that's in HA. 00:34:45.600 --> 00:34:50.800 And so, we can specify what data store or data stores they're going to write to and all the 00:34:50.800 --> 00:34:55.040 hosts need to be able to see that same data store and they'll write to it and they'll all monitor 00:34:55.040 --> 00:34:58.719 and say, okay, yeah, I see this host is writing, this host is good, that host is good, and they 00:34:58.719 --> 00:35:05.280 just monitor that information. Okay. You can also specify a pool of data stores. They all 00:35:05.280 --> 00:35:13.439 are going to share the same ones for that HA cluster. Okay. Proactive HA is basically just 00:35:13.439 --> 00:35:19.600 going to allow you to, if you see a host or the system sees a host that looks like it's not 00:35:19.600 --> 00:35:25.679 performing very well, it's seeing power supply issues, you know, errors from the power supply, 00:35:25.679 --> 00:35:30.239 error of CPU, error in RAM, things like that. You know, different components don't look healthy 00:35:30.239 --> 00:35:34.800 anymore to the system. It's being logged. What do you want it to do? You can say you want to 00:35:35.520 --> 00:35:41.199 quarantine that host, put it in makes mode, quarantine it, or you can say manually you 00:35:41.199 --> 00:35:45.600 want VM server to make, you know, suggestions are migrating VMs. You can say you want to 00:35:45.600 --> 00:35:50.560 automatically migrate all the VMs off that host and then we can say we want, like, for example, 00:35:50.560 --> 00:35:54.399 quarantine the VMs or the host that's on there that's not doing well. So, because you don't, 00:35:54.399 --> 00:35:59.600 what you don't want to have happen is you might, HA might see a host and say, oh, this one isn't 00:35:59.600 --> 00:36:04.000 healthy. If I just moved the VMs off and didn't do anything else to it, DRS might start putting 00:36:04.000 --> 00:36:07.439 them back. So, we're going to put that host in maintenance mode. That way DRS won't start 00:36:07.439 --> 00:36:14.399 putting VMs back on it. All right. So, what are the, what can you do with a degraded host? 00:36:14.399 --> 00:36:18.159 You can put it in quarantine mode, you can put it in maintenance mode, or you can have a mixture 00:36:18.159 --> 00:36:22.879 of different ways that you can say that you want to do it based upon what is the problems you're 00:36:22.879 --> 00:36:31.520 seeing. Some troubleshooting. So, common issues, deployment errors, right? So, what can cause some 00:36:31.520 --> 00:36:35.760 issues with deploying this? Network latency. Network latency is going to be a big deal for 00:36:35.760 --> 00:36:39.439 any of these things. You want to make sure that your networks are healthy, you're not dropping a 00:36:39.439 --> 00:36:44.639 lot of packets, your latency is not super high, things like that. A degraded HA cluster. Are you 00:36:44.639 --> 00:36:49.919 routing between nodes? And if you are, is it, you know, is routing configured correctly? Again, 00:36:49.919 --> 00:36:54.399 network issues, not necessarily latency, but network issues are going to be a problem. Any 00:36:54.399 --> 00:37:00.560 kind of network issues with HA are going to be a problem for you because HA requires that 00:37:00.560 --> 00:37:04.320 communication between the host to know who's up and who's not, that kind of thing. 00:37:05.199 --> 00:37:10.080 Active nodes start serving client requests, right? You want to check the health of your active node 00:37:10.080 --> 00:37:15.040 and your passive node and your witness nodes, make sure your nodes are running, make sure your 00:37:15.040 --> 00:37:22.479 network's healthy. So, why is my cluster considered degraded? Did a node fail? If you have, you know, 00:37:22.479 --> 00:37:29.360 one of your nodes are down, then HA will report a degraded cluster. Also, make sure you have enough 00:37:29.360 --> 00:37:33.520 bandwidth between your hosts. If they're all running, they all look, you know, fine, 00:37:34.479 --> 00:37:37.679 do they all know that? There's enough bandwidth on the network for them to see each other and 00:37:37.679 --> 00:37:43.600 know that they're all fine, they're all healthy. Database replication failed. Again, network 00:37:43.600 --> 00:37:50.800 latency. Configuration file not copied from the active and passive nodes. So, check for down 00:37:50.800 --> 00:37:56.159 hardware network isolation. Are the two hosts able to see each other and communicate that database 00:37:56.159 --> 00:37:59.840 back and forth? Is there enough bandwidth to communicate it, you know, not too high of a 00:37:59.840 --> 00:38:08.320 latency? Again, network, network, network, right? Why is my active node not serving client requests? 00:38:08.320 --> 00:38:13.199 Is it isolated? Check and see if there's connectivity between them. Not connected to 00:38:13.199 --> 00:38:17.679 the active or passive node. What you can try doing there, if everything else looks fine, 00:38:17.679 --> 00:38:24.080 is destroy the active node, go into Bash yourself, destroy the active node and recreate it and see 00:38:24.080 --> 00:38:26.959 if it joins back. If everything else looks good, everything's healthy, maybe there's some kind of 00:38:26.959 --> 00:38:34.399 corruption or something. Just recreating that node can fix that. So, your active node still 00:38:34.399 --> 00:38:39.919 functions, but it's not – so, not replaced. And here you'll see there's a command. You can 00:38:39.919 --> 00:38:48.239 write the Bash shell to go in and resolve that. That is HA. That is some of the more advanced 00:38:48.239 --> 00:38:53.760 features of HA with a vSphere environment. And let's go ahead and go to our demo environment, 00:38:53.760 --> 00:38:58.159 and I'll show you how to basically enable HA on a cluster. So, here we are in our vSphere 00:38:58.159 --> 00:39:04.800 environment, and I have my datacenter, and here's my production cluster. If I want to configure 00:39:04.800 --> 00:39:10.320 HA on this cluster, I can just click on, you know, production here. I can go to my configuration, 00:39:11.199 --> 00:39:17.280 go to high availability, and here I'm seeing HA is turned off, right? So, I can say I want to edit 00:39:17.280 --> 00:39:26.159 that, and I can say I want to enable HA, and now I have a bunch of different options that we 00:39:26.159 --> 00:39:33.280 discussed, right, in here. So, we're going to enable HA. So, host failure response. What do 00:39:33.280 --> 00:39:38.000 we want to do? We want to restart the VMs on another host, or do we want to disable, you know, 00:39:38.000 --> 00:39:44.959 the host response? Response for host isolation. So, meaning that the host thinks it's up, but, 00:39:45.919 --> 00:39:50.800 you know, it doesn't see anybody else. So, that's a host isolation response. We can say power off 00:39:50.800 --> 00:39:55.360 and restart the VMs. If we do that, I'll be able to restart them on a different host, right? Or do 00:39:55.360 --> 00:39:59.919 you want to shut down and reset the VMs? The difference is power off is going to literally 00:39:59.919 --> 00:40:05.679 just take them down, whereas a shutdown will try to shut them down gracefully. The reason why you 00:40:05.679 --> 00:40:09.919 might power them down is if you're using, like, say, iSCSI, and you think that if there's an 00:40:09.919 --> 00:40:16.560 isolation response, it can't then see the storage. So, just power them off. If you think you still 00:40:16.560 --> 00:40:21.679 can see the storage, maybe you have fiber channel HBAs or separate network adapters for your iSCSI 00:40:21.679 --> 00:40:26.159 storage, and so you think there's a really good chance that VMs are still running properly and 00:40:26.159 --> 00:40:33.600 still seeing storage, then you can shut them down, right? So, VM monitoring. Do you want to 00:40:33.600 --> 00:40:38.399 enable VM monitoring? Right now yours are disabled. We can say we want to enable VM monitoring, 00:40:38.399 --> 00:40:42.639 right? So, we do enable VM and application monitoring, right? There's some different 00:40:42.639 --> 00:40:47.280 options there. VM monitoring sensitivity, right? You can specify, like, you know, 00:40:47.280 --> 00:40:51.919 how long before you consider it a failure, some things like that. Admission control. 00:40:53.280 --> 00:40:58.000 Host failures in the cluster to tolerate. Here we can say, you know, we want to tolerate one. 00:40:58.000 --> 00:41:02.479 We only have two in here, so we really can't say more than that. We can't tolerate two with only, 00:41:02.479 --> 00:41:07.679 you know, two in the cluster. We can also say if you want to do a percentage of the cluster or 00:41:07.679 --> 00:41:11.439 some things like that. We can specify data stores for our data store heartbeat. We only have the 00:41:11.439 --> 00:41:16.719 really one shared data store, so that was the only one we could do. We could also say we wanted to 00:41:16.719 --> 00:41:21.120 automatically select it from, you know, the host. So, as you can see, HA is actually really simple 00:41:21.120 --> 00:41:25.600 to configure. The first thing is just check that little green button there. It'll turn it on, 00:41:25.600 --> 00:41:29.199 and then we can go through and configure all the different options that we've talked about. 00:41:29.199 --> 00:41:36.080 So, once I've said that, I can say okay, and it'll enable HA on my cluster. That is HA for vSphere 8.