WEBVTT 00:00:00.000 --> 00:00:06.000 Welcome back to vSphere 8 in the real world. Now we're going to discuss some topology. 00:00:06.000 --> 00:00:11.000 So this is a typical data center type of environment. So we have our hosts. 00:00:11.000 --> 00:00:16.000 Our hosts have VMs running on them. The VMs are running an operating system and applications. 00:00:16.000 --> 00:00:20.000 They're connected to networking. They're connected to storage. 00:00:20.000 --> 00:00:26.000 Down in the bottom, the left there, you see there is a management computer that can be used for managing our network. 00:00:26.000 --> 00:00:29.000 There is, you know, obviously a connection to the cloud. 00:00:29.000 --> 00:00:36.000 So this is just kind of like a real generic overview of what a data center topology might sort of look like. 00:00:36.000 --> 00:00:41.000 Now, some different components in there is we want to manage that network, right? 00:00:41.000 --> 00:00:44.000 We want to be able to connect in and manage this environment. 00:00:44.000 --> 00:00:49.000 So you have a vCenter server. A vCenter server is going to be a virtual appliance. 00:00:49.000 --> 00:00:53.000 It used to be an application you install onto a Windows server. 00:00:53.000 --> 00:00:56.000 So it could be a VM running Windows or a physical box running Windows. 00:00:56.000 --> 00:01:00.000 People had different preferences back in the day, but now it's a virtual appliance. 00:01:00.000 --> 00:01:05.000 And this virtual appliance is going to run on an ESXi host somewhere in our data center. 00:01:05.000 --> 00:01:12.000 It can run in a cluster. So a vCenter server can be a member of a cluster that it's managing. 00:01:12.000 --> 00:01:15.000 So you don't have to have a separate set of hosts running vCenter. 00:01:15.000 --> 00:01:18.000 It can live in the environment that it manages. 00:01:18.000 --> 00:01:25.000 And actually, that might not be a horrible thing in that this VM is managing the host that it lives on, 00:01:25.000 --> 00:01:30.000 and something happens and the host fails that's running vCenter, HA can start vCenter up on another host. 00:01:30.000 --> 00:01:38.000 So you have still all those advantages of vCenter, even when vCenter maybe happens to fail. 00:01:38.000 --> 00:01:40.000 So you can see that little red box on that first host there. 00:01:40.000 --> 00:01:44.000 That little red box is kind of just showing that's our vCenter server. 00:01:44.000 --> 00:01:50.000 So our admin station, where our admin is sitting there working every day, will connect that vCenter server. 00:01:50.000 --> 00:01:55.000 And from there, he can manage all the hosts that are in the vCenter environment. 00:01:55.000 --> 00:02:00.000 Another way of managing a vCenter environment is you can manage the hosts one by one. 00:02:00.000 --> 00:02:04.000 You can actually open up your browser, and you can connect to vCenter from your browser, 00:02:04.000 --> 00:02:08.000 or we can connect directly to a host from our browser. 00:02:08.000 --> 00:02:11.000 And we can manage the host through that one by one. 00:02:11.000 --> 00:02:13.000 That's not typically how we want to do that. 00:02:13.000 --> 00:02:17.000 We usually only do that if, for some reason, there's something wrong with our vCenter 00:02:17.000 --> 00:02:21.000 or something wrong with the host connecting to vCenter, and we want to see can we manage the host directly. 00:02:21.000 --> 00:02:29.000 We log into the host directly and say, oh, yeah, this network card is where the vCenter is connected to, 00:02:29.000 --> 00:02:32.000 and this one's not connected correctly or something like that. 00:02:32.000 --> 00:02:36.000 So we can manage our hosts through the web interface directly. 00:02:36.000 --> 00:02:40.000 And then there's also the console, the direct console access. 00:02:40.000 --> 00:02:46.000 So in this case, it basically means we've gone to the server, and maybe we have an IP KVM 00:02:46.000 --> 00:02:51.000 or some kind of KVM appliance, or maybe we have a DRAC or an ILO or something. 00:02:51.000 --> 00:02:57.000 But basically it's sort of like we have connected a monitor into the server and keyboard 00:02:57.000 --> 00:03:00.000 and mouse, whether it be the virtual monitor from the DRAC or from a KVM 00:03:00.000 --> 00:03:05.000 or an actual monitor or a crash card or something, and we are connected to the host. 00:03:05.000 --> 00:03:11.000 And there we'll have the ability to, even if the network's completely down, we can look at the network settings 00:03:11.000 --> 00:03:17.000 and say, oh, well, there's no NIC selected here, or the wrong NIC is selected for our management interface, 00:03:17.000 --> 00:03:19.000 the wrong IP address is on there. 00:03:19.000 --> 00:03:21.000 Let's fix the NIC. 00:03:21.000 --> 00:03:25.000 Let's add an IP address or the correct IP address, and now let's test that. 00:03:25.000 --> 00:03:28.000 Oh, now we can ping our gateway, and we can ping DNS and all those things. 00:03:28.000 --> 00:03:31.000 We can resolve the name for the host now in DNS. 00:03:31.000 --> 00:03:34.000 So our testing is good, and we can go back to vCenter and say, oh, look, 00:03:34.000 --> 00:03:37.000 and now the host shows up in vCenter like it was supposed to. 00:03:37.000 --> 00:03:38.000 Everything's good to go. 00:03:38.000 --> 00:03:39.000 All right. 00:03:39.000 --> 00:03:41.000 So we can manage our host through vCenter. 00:03:41.000 --> 00:03:49.000 We can manage our host directly through our web client interface or through the DRAC console user interface, right, 00:03:49.000 --> 00:03:53.000 basically keyboard-mouse monitor. 00:03:53.000 --> 00:03:58.000 So there's also we can manage the resources on a host-by-host basis. 00:03:58.000 --> 00:04:05.000 So in this case, the admin is connected to the vCenter server, and we are looking at how, you know, a host on there. 00:04:05.000 --> 00:04:11.000 We can also manage, rather than just managing even with vCenter host-by-host-by-host, we can create a cluster. 00:04:11.000 --> 00:04:21.000 So now we're saying that instead of saying this computer is on this host, we're saying this virtual machine is going to be in this cluster. 00:04:21.000 --> 00:04:25.000 So now it has all these resources, you know, available to it. 00:04:25.000 --> 00:04:31.000 So if the host that it's living on starts to become resource constrained, CPU utilization is hitting like, you know, 90 percent, 00:04:31.000 --> 00:04:37.000 very little RAM is available, maybe none, maybe it's ballooning and paging and things like that. 00:04:37.000 --> 00:04:43.000 But this other host is only running at, you know, 15 percent CPU, has got tons of free RAM. 00:04:43.000 --> 00:04:51.000 We can move the VM to another host and take advantage of those resources because the cluster will allow us to run services like, 00:04:51.000 --> 00:04:55.000 you know, DRS if we have licenses for DRS. 00:04:55.000 --> 00:05:02.000 And then basically we're kind of pooling all the resources from all those hosts into one pool, all right? 00:05:02.000 --> 00:05:10.000 So the host, one individual, you know, compute resource, clusters, all the hosts into a big group. 00:05:10.000 --> 00:05:15.000 We can carve that big group of clusters into a smaller group, right? 00:05:15.000 --> 00:05:20.000 Now, the way they're going to show it here isn't exactly quite right because here it's kind of showing, 00:05:20.000 --> 00:05:27.000 well, I'm going to say these two hosts are a resource pool, and that's not really kind of how resource pools work, right? 00:05:27.000 --> 00:05:34.000 You have your cluster, and I can say I'm going to create a resource pool in the cluster that is the equivalent of two hosts. 00:05:34.000 --> 00:05:39.000 I can say two-thirds of the pool, you know, so instead of saying that it can use 100 percent of the resources, 00:05:39.000 --> 00:05:44.000 it can only use two-thirds of the resources, it being a VM. 00:05:44.000 --> 00:05:49.000 But really that resource pool still spans across the whole cluster, 00:05:49.000 --> 00:05:56.000 but it can say that a VM is only allowed to use so much of the resources that are configured for this, 00:05:56.000 --> 00:06:01.000 are configured for that, only so much CPU, only so much RAM, or only has so many shares, 00:06:01.000 --> 00:06:07.000 whereas this VM has, you know, 100 shares, this other VM only has 60 shares, things like that. 00:06:07.000 --> 00:06:15.000 So it's a way of limiting the resources that are available for use to VMs so VMs cannot overwhelm. 00:06:15.000 --> 00:06:20.000 It can also be used to reserve resources, the complete opposite. 00:06:20.000 --> 00:06:29.000 A resource pool can also be used to create a reservation, and what a reservation says is even if the VM's not using a resource, 00:06:29.000 --> 00:06:34.000 so where shares say when things start to get constrained, how much do you get? 00:06:34.000 --> 00:06:39.000 A reservation says even when it's not being used, that resource belongs to me. 00:06:39.000 --> 00:06:41.000 So I can reserve so much RAM. 00:06:41.000 --> 00:06:49.000 So maybe I configured the VM with, you know, 24 gigs of RAM, but I'm going to reserve 8 gigs. 00:06:49.000 --> 00:06:56.000 I'm going to say that this VM always has 8 gigs available to it physically on the host it's on, no matter what. 00:06:56.000 --> 00:07:00.000 So even if all of a sudden tons of other VMs start up and there's almost, you know, 00:07:00.000 --> 00:07:06.000 very little RAM available and we've way over allocated the amount of RAM that the host has available to it, 00:07:06.000 --> 00:07:10.000 this reservation is going to always be honored. 00:07:10.000 --> 00:07:15.000 So what that also means is let's say I have a host and the host has 32 gigs of RAM. 00:07:15.000 --> 00:07:18.000 It's a very small little host to make the math easy for us. 00:07:18.000 --> 00:07:21.000 And on this VM, I reserve 8 gigs. 00:07:21.000 --> 00:07:24.000 Well, that leaves me with 24 gigs plus some that's used by the host. 00:07:24.000 --> 00:07:26.000 Actually, I only probably have like maybe 20 gigs. 00:07:27.000 --> 00:07:31.000 So then I start up another VM that also has an 8-gig reservation, right? 00:07:31.000 --> 00:07:36.000 So that first one is 8, took me down to 16, and a few gigs were, you know, used for the host. 00:07:36.000 --> 00:07:37.000 Now I'm down to 12. 00:07:37.000 --> 00:07:42.000 Start up another one with 8 gigs, and now I'm down to 4 gigs of available RAM on the host. 00:07:42.000 --> 00:07:46.000 I go to start another VM that also has an 8-gig reservation. 00:07:46.000 --> 00:07:48.000 I'm going to get an error back saying, 00:07:48.000 --> 00:07:53.000 this VM has an 8-gig reservation that I can't honor on this host, so I can't start it. 00:07:53.000 --> 00:07:57.000 It won't start VMs up if it can't honor the reservation. 00:07:57.000 --> 00:08:04.000 Now, if we're in a cluster, the DRS can look at it and say, oh, well, I'll just start it on that host over there 00:08:04.000 --> 00:08:07.000 because that host over there has enough resource to honor the reservation. 00:08:07.000 --> 00:08:13.000 Great, no problem, until I get to the end of all the hosts and they're all allocated. 00:08:13.000 --> 00:08:20.000 Then what's going to happen is it will stop starting VMs whose reservations it cannot honor. 00:08:20.000 --> 00:08:25.000 So resource pools can be used to guarantee resources or limit the amount of resources that are used, 00:08:25.000 --> 00:08:30.000 but it's a way of carving up a cluster into a smaller set of resources. 00:08:30.000 --> 00:08:38.000 So in a cluster, I can maybe have 2 or 3 or 10 or whatever resource pools in a cluster. 00:08:38.000 --> 00:08:41.000 So networking components, we have our physical network, right? 00:08:41.000 --> 00:08:47.000 We have the physical NICs that are in our host, and those physical NICs that are in our host connect to physical switches, 00:08:47.000 --> 00:08:50.000 and we might have our access switches, and we have our core switch, 00:08:50.000 --> 00:08:54.000 and our core switch is connected to our firewall, which connects up to the Internet. 00:08:54.000 --> 00:08:57.000 Those are all the physical components of our network. 00:08:57.000 --> 00:09:03.000 In our virtualization environment, we're going to have the physical NICs on the host, 00:09:03.000 --> 00:09:07.000 and our physical environment, virtually we're going to create virtual switches, 00:09:07.000 --> 00:09:11.000 and our virtual switches are going to have port groups configured on them, 00:09:11.000 --> 00:09:14.000 and the VMs don't connect to the virtual switch. 00:09:14.000 --> 00:09:17.000 They connect to the port group that's on that virtual switch. 00:09:17.000 --> 00:09:20.000 So they indirectly connect to the virtual switch through the port group, 00:09:20.000 --> 00:09:22.000 and the port group is going to be named. 00:09:22.000 --> 00:09:27.000 A lot of times you'll name it something like, you know, that means something to you, 00:09:27.000 --> 00:09:30.000 Exchange Servers or, you know, Active Directory Services Services. 00:09:30.000 --> 00:09:32.000 It might be more complicated. 00:09:32.000 --> 00:09:38.000 It might be something along the lines of Dallas Data Center, West, you know, 00:09:38.000 --> 00:09:42.000 Building Directory Services Field Servers or something like that, right? 00:09:42.000 --> 00:09:46.000 So you'll know that this port group is in the Dallas Data Center 00:09:46.000 --> 00:09:49.000 and this port group is on, you know, this server. 00:09:49.000 --> 00:09:52.000 The problem with doing things like that, though, and I've seen that, 00:09:52.000 --> 00:09:56.000 the problem with that is that what if you need to do a DR situation 00:09:56.000 --> 00:10:01.000 and we need to failover this Dallas Data Center over to our San Francisco Data Center? 00:10:01.000 --> 00:10:05.000 Are we creating Dallas port group names in our San Francisco Data Center? 00:10:05.000 --> 00:10:10.000 So it's really a good idea to kind of, like, limit the naming of our port groups 00:10:10.000 --> 00:10:16.000 to maybe types of workloads or types of services or, you know, things like that. 00:10:16.000 --> 00:10:21.000 Maybe a client, maybe if you're hosting multiple, you know, different types of clients, 00:10:21.000 --> 00:10:26.000 you might say, you know, accounts payable or, you know, golden pianos, you know, 00:10:26.000 --> 00:10:29.000 if it's a third-party client that you're hosting, things like that. 00:10:29.000 --> 00:10:32.000 You know, maybe you say accounts payable file servers, 00:10:32.000 --> 00:10:36.000 and then you have that same accounts payable file server in your DR location 00:10:36.000 --> 00:10:39.000 in San Francisco, things like that, right? 00:10:39.000 --> 00:10:43.000 So you'll create virtual switches, and you'll create port groups. 00:10:43.000 --> 00:10:46.000 Now, you might also create distributed virtual switches, 00:10:46.000 --> 00:10:51.000 and distributed virtual switches are going to have – live in vCenter, 00:10:51.000 --> 00:10:53.000 and they're going to have port groups on them, 00:10:53.000 --> 00:10:56.000 same kind of thing as far as, like, how you're going to send those out. 00:10:56.000 --> 00:11:01.000 Now, the thing about a distributed virtual switch is because I'm not creating it on the host, 00:11:01.000 --> 00:11:05.000 I'm creating it in vCenter, and vCenter can manage my Dallas Data Center, 00:11:05.000 --> 00:11:07.000 and it can manage my San Francisco Data Center. 00:11:07.000 --> 00:11:13.000 So when I create this virtual switch and I create this accounts payable, you know, 00:11:13.000 --> 00:11:18.000 file server port group, I can add it to hosts in San Francisco automatically 00:11:18.000 --> 00:11:22.000 and to hosts in Dallas automatically, okay? 00:11:22.000 --> 00:11:23.000 And then there's NSX. 00:11:23.000 --> 00:11:28.000 NSX is a really great product, super cool, does amazing stuff, 00:11:28.000 --> 00:11:31.000 but it's very advanced software-defined networking. 00:11:31.000 --> 00:11:36.000 So I can actually go in and create firewall rules for every VM in my environment, right? 00:11:36.000 --> 00:11:40.000 And I can create NAT policies, and I can, you know, intrusion detection systems 00:11:40.000 --> 00:11:46.000 and all kinds of crazy awesome stuff through NSX, through this software-defined networking, okay, 00:11:46.000 --> 00:11:52.000 which obviously is going to require vCenter and things like that. 00:11:52.000 --> 00:11:56.000 So this just kind of shows, you know, creating the distributed virtual switches and, you know, 00:11:56.000 --> 00:12:03.000 NSX and things like that in vCenter, and they can just get pushed out to all the hosts. 00:12:03.000 --> 00:12:06.000 So storage components, we talked about physical hosts, right? 00:12:06.000 --> 00:12:12.000 Physical hosts can have hard drives, and we can store, you know, a VM on a disk in my host. 00:12:12.000 --> 00:12:18.000 The downside of that, though, is that that VM only lives on that disk on that host, right? 00:12:18.000 --> 00:12:21.000 Where if we have shared storage, like a SAN, whether, you know, 00:12:21.000 --> 00:12:27.000 an iSCSI SAN or a proper channel SAN, now all the hosts can access the files on that SAN. 00:12:27.000 --> 00:12:33.000 The only downside, well, actually not only, but one of the big downsides about a SAN is they're very expensive. 00:12:33.000 --> 00:12:36.000 You can spend, you know, $100,000, $1 million. 00:12:36.000 --> 00:12:40.000 You can spend, you know, very expensive devices, 00:12:40.000 --> 00:12:47.000 and each gig is going to be a rather expensive dollar amount per gigabyte of storage on a SAN. 00:12:47.000 --> 00:12:55.000 vSAN is a way of taking, relatively speaking, you know, inexpensive disks that are in our servers 00:12:55.000 --> 00:12:57.000 and treating them like they're a SAN. 00:12:57.000 --> 00:13:02.000 So where I create a VM on host one, it's going to get copied over to host two in case host one fails, 00:13:02.000 --> 00:13:04.000 and then we can start the VM over there, that kind of thing. 00:13:04.000 --> 00:13:08.000 So vSAN, just, you know, virtual SAN, virtualized on our hosts, 00:13:08.000 --> 00:13:12.000 and it gets copying VMs between the different hosts, okay? 00:13:12.000 --> 00:13:17.000 And we'll have a lesson on vSAN and shared storage. 00:13:17.000 --> 00:13:23.000 So we discussed the different components in our data center and the topologies of our data center.