WEBVTT 00:00:00.000 --> 00:00:13.600 Welcome to VMware vSphere VCP 2024 Data Center Virtualization. 00:00:13.600 --> 00:00:17.000 We're going to start with some virtualization basics. 00:00:17.000 --> 00:00:22.360 So first thing we do is compare physical computing to what you might see with virtualization. 00:00:22.360 --> 00:00:26.840 With physical computing, you have one server and one server often would mean one service. 00:00:26.840 --> 00:00:30.840 So we might have a server and that server is going to run an Exchange server, 00:00:30.840 --> 00:00:37.040 it's going to run a SQL server, or it's going to run an Active Directory, Directory Services services, things like that. 00:00:37.040 --> 00:00:44.639 So if we're running a physical environment, a physical computer, one server is dedicated to one service very often. 00:00:44.639 --> 00:00:48.639 It doesn't always have to be that way. You can add things together. 00:00:48.639 --> 00:00:50.639 Usually it's best practice not to. 00:00:50.639 --> 00:00:57.040 You want to have some isolation dedication so you don't have one resource overwhelming another, 00:00:57.040 --> 00:01:00.439 or you don't want to have one service conflicting and causing problems with another, 00:01:00.439 --> 00:01:08.239 or a service gets updated by its vendor and then starts causing conflicts with another service that hasn't been updated yet or something like that. 00:01:08.239 --> 00:01:16.040 So usually when we have a physical environment, we have a lot of servers running a lot of different services, one each, 00:01:16.040 --> 00:01:22.239 and not a lot is heavily utilized. You might find that if you were to average out everything in your data center, 00:01:22.239 --> 00:01:26.639 maybe you're running out by 5% or 7%, 8% utilization a lot of times. 00:01:26.639 --> 00:01:32.639 So with a physical environment without virtualization, you'll find that you have a lot of resources, 00:01:32.639 --> 00:01:40.040 a lot of purchases, a lot of servers, and not a lot of utilization, not a lot of bang for your buck, so to speak. 00:01:40.040 --> 00:01:47.839 And with virtualization, you'll see that we can greatly reduce that footprint. 00:01:47.839 --> 00:01:52.239 So some of the components of a physical server. Physical servers are going to have the physical hardware. 00:01:52.239 --> 00:01:56.440 They're going to have things like RAM, CPU, hard disk networking. 00:01:56.440 --> 00:02:00.339 Then you're going to have an operating system installed on that physical computer, 00:02:00.339 --> 00:02:06.839 and then that operating system will have sole control over the CPU, the memory, the storage, all that kind of stuff, right? 00:02:06.839 --> 00:02:10.740 So some common operating systems for physical servers in a data center will be, you know, 00:02:10.740 --> 00:02:18.240 Windows Server or some version of Linux, for example, like Red Hat. 00:02:18.240 --> 00:02:25.740 Now with virtualization, all of a sudden, we're creating these containers, these virtualized containers on this physical box. 00:02:25.740 --> 00:02:30.039 So the operating system in our VMware vSphere environment will be ESXi. 00:02:30.039 --> 00:02:32.440 That's what we're going to install on that bare metal. 00:02:32.440 --> 00:02:41.139 But then that hypervisor, the ESXi, is going to allow us to create these containers that will virtualize hardware 00:02:41.139 --> 00:02:47.139 so that we can have multiple operating systems installed on top of that ESXi host. 00:02:47.139 --> 00:02:52.639 So we might have Windows. We might have Windows 2016, Windows 2019, Windows 2022. 00:02:52.639 --> 00:02:55.940 We might have Red Hat Linux running on the same machine as those Windows servers, 00:02:55.940 --> 00:03:01.139 as well as, you know, SUSE or Ubuntu or something like that, Debian. 00:03:01.139 --> 00:03:06.940 So we can mix all these different operating systems together because they're all self-contained. 00:03:06.940 --> 00:03:08.940 One does not see the other. 00:03:08.940 --> 00:03:13.240 The only way that one could impact the other is if one started using a lot of resources, 00:03:13.240 --> 00:03:16.639 maybe starts using a lot of network bandwidth or a lot of CPU, 00:03:16.639 --> 00:03:21.940 and causing the other virtual machines to not have that level of access to the resources they need. 00:03:21.940 --> 00:03:23.940 But there are also ways to prevent that. 00:03:23.940 --> 00:03:25.940 We can, you know, create limits. 00:03:25.940 --> 00:03:27.440 We can create resource pools. 00:03:27.539 --> 00:03:34.139 We can throttle bandwidth on the network interfaces and say that we only are going to let a virtual machine use, 00:03:34.139 --> 00:03:38.940 you know, half of one core or, you know, two cores max or however you want to configure that. 00:03:38.940 --> 00:03:42.240 So that way, virtual machines don't impact others. 00:03:42.240 --> 00:03:47.539 But the great thing is we can patch one of our virtual machines, and we don't have to patch the other. 00:03:47.539 --> 00:03:50.440 So we have on one box, maybe we have an Exchange server running. 00:03:50.440 --> 00:03:53.039 We have an Active Directory Directory Services server running. 00:03:53.039 --> 00:03:55.539 Maybe we have a Linux box running, a database. 00:03:55.539 --> 00:03:58.639 And we can say, okay, we're going to upgrade Exchange. 00:03:58.639 --> 00:04:05.139 And we're going to actually upgrade the OS to 2022, but we're going to leave this other server over here on 2019. 00:04:05.139 --> 00:04:07.440 And the Red Hat box, we're not going to patch that one at all right now. 00:04:07.440 --> 00:04:10.139 We're going to get to that one next week or next month or whatever. 00:04:10.139 --> 00:04:12.539 And they don't impact the others, right? 00:04:12.539 --> 00:04:15.940 They all are running isolated. 00:04:15.940 --> 00:04:17.339 So there's two types of hypervisors. 00:04:17.339 --> 00:04:20.540 There's what's called Type 1 hypervisor and a Type 2. 00:04:20.540 --> 00:04:28.739 ESXi, which is kind of the core OS for a vSphere, a VMware vSphere environment, is what we refer to as a bare metal hypervisor. 00:04:28.739 --> 00:04:30.239 It's a Type 1 hypervisor. 00:04:30.239 --> 00:04:31.540 There's also a Type 2. 00:04:31.540 --> 00:04:36.140 With a Type 2, you install a hypervisor on top of an operating system. 00:04:36.140 --> 00:04:40.839 So an example of that would be VMware Workstation, where maybe we're running Windows. 00:04:40.839 --> 00:04:43.540 And on top of Windows, we want to install VMware Workstation. 00:04:43.540 --> 00:04:47.940 And so that's a Type 2 hypervisor because it doesn't get installed on bare metal. 00:04:47.940 --> 00:04:54.239 It does work with another operating system below that. 00:04:54.239 --> 00:05:01.140 So oftentimes in a virtual environment, what we refer to that server, the one that is doing the virtualization. 00:05:01.140 --> 00:05:05.140 So in this example, our ESXi host, we refer to that as a host. 00:05:05.140 --> 00:05:11.640 So if you're talking to somebody about your data center, you might say, yeah, we have, you know, 100 hosts. 00:05:11.640 --> 00:05:17.739 And those 100 hosts are running 800 virtual machines or 1,200 virtual machines. 00:05:17.739 --> 00:05:20.940 So the VMs, you might have 1,200 operating systems running. 00:05:20.940 --> 00:05:25.839 You might have, you know, multiple different versions of Windows and Linux like we mentioned. 00:05:25.839 --> 00:05:29.640 But they're running on 100 physical boxes. 00:05:29.640 --> 00:05:32.440 And maybe those boxes are running ESXi. 00:05:32.440 --> 00:05:38.739 So the ESXi boxes are the hosts that are running the guests' virtual machines, okay? 00:05:38.739 --> 00:05:44.140 Also in a virtual environment, you want some kind of software that allows you to manage those hosts. 00:05:44.140 --> 00:05:50.239 I don't want to log into this host and manage the VMs that are on there, then log out and log into another one and manage those ones. 00:05:50.239 --> 00:05:57.540 I want to be able to look at my entire infrastructure in one view, see all the hosts that are in my infrastructure, 00:05:57.540 --> 00:06:02.040 see all the VMs on all those hosts that are in my infrastructure, and manage those. 00:06:02.040 --> 00:06:06.640 I want to be able to say, okay, these, you know, 10 hosts here, these are going to be a cluster. 00:06:06.640 --> 00:06:13.940 And in this cluster, we're going to create a resource pool that says how much of the resources for these 10 hosts, 00:06:13.940 --> 00:06:20.440 these 30 VMs, or maybe just these three VMs are in that one resource pool, how much they can use, right? 00:06:20.440 --> 00:06:23.940 And so by using a resource pool, we can carve up a cluster. 00:06:23.940 --> 00:06:26.239 A cluster is a grouping of hosts. 00:06:26.239 --> 00:06:36.440 And we can say how much resource these VMs are either going to be guaranteed to have or limited to, or both. 00:06:36.440 --> 00:06:38.940 We can say we're guaranteed they have this much resource. 00:06:38.940 --> 00:06:40.739 So the other VMs can't overwhelm them. 00:06:40.739 --> 00:06:42.239 These ones are really important. 00:06:42.239 --> 00:06:48.440 We're going to make sure they have, you know, at least, you know, 10% of the resource pool CPU processing power. 00:06:48.440 --> 00:06:50.040 But they can't use more than 20. 00:06:50.040 --> 00:06:52.239 You might say something like that, okay? 00:06:52.239 --> 00:07:00.940 So the tool in a vSphere environment for doing all that management of all those hosts and all the VMs and things like that is going to be your vCenter server. 00:07:00.940 --> 00:07:10.940 So really the core two basic pieces you're going to have in a vSphere environment will be your host, ESXi, and your management tool, which will be your vCenter server. 00:07:10.940 --> 00:07:13.940 So that is really kind of the basic there. 00:07:13.940 --> 00:07:18.540 Now, there are a lot of things you can add in to help you manage this environment. 00:07:18.540 --> 00:07:23.140 You can use things for managing or making your network far more robust, like NSX. 00:07:23.140 --> 00:07:27.540 Maybe you want to do virtual desktop hosting, so you might get Horizon. 00:07:27.540 --> 00:07:31.839 There's a lot of different tools you can use, you know, tools for reporting, you know, things like that. 00:07:31.839 --> 00:07:39.140 But the basic bare bone, you know, data center environment, you're going to have your ESXi hosts, and you're going to have a vCenter server. 00:07:41.839 --> 00:07:54.040 So on those hosts, when we want to configure networking, so we want to say, all right, this host, this physical box that's running these 30 VMs on it, for example, it has two network cards. 00:07:54.040 --> 00:08:02.640 Maybe it has two 10-gig network cards in there, and those two 10-gig network cards are going to allow access for these 30 VMs. 00:08:02.640 --> 00:08:05.540 But not all the VMs are going to be on the same VLAN. 00:08:05.540 --> 00:08:11.140 On a typical physical environment, my server is going to live on a VLAN. 00:08:11.140 --> 00:08:15.140 My Exchange servers live on VLAN 50, okay? 00:08:15.140 --> 00:08:19.440 And my Active Directory Services, you know, VMs, maybe they're also on VLAN 50. 00:08:19.440 --> 00:08:20.940 All my servers are on VLAN 50. 00:08:20.940 --> 00:08:29.239 But maybe I say my Windows boxes are going to be on VLAN 50, and my Linux boxes are going to be on VLAN 60. 00:08:29.239 --> 00:08:37.140 Or maybe I say my Exchange servers are on 50, and my Active Directory Services are going to be on 51, and my file and print servers are on 52. 00:08:37.140 --> 00:08:41.739 I really segment them out because I'm running thousands of virtual machines. 00:08:41.739 --> 00:08:53.539 And so because I have so many VMs, I'm going to really start isolating down what lives on each network so that when I see an IP address, I know, oh, that is, you know, 172.16.50. 00:08:53.539 --> 00:08:54.739 That's my VLAN 50. 00:08:54.739 --> 00:08:59.039 And so I know that is a Exchange server or something like that, right? 00:08:59.039 --> 00:09:09.039 So how do we take two network cards and run three or four or 10 or 15 different VLANs on two network cards? 00:09:09.039 --> 00:09:15.140 On an ESXi host, I create a virtual switch, or maybe I can create multiple virtual switches. 00:09:15.140 --> 00:09:20.039 If I had in my host, instead of having two network cards, maybe I had 10 network cards. 00:09:20.039 --> 00:09:21.440 Again, that would be a lot. 00:09:21.440 --> 00:09:22.940 But maybe I have 10 network cards. 00:09:23.039 --> 00:09:29.840 And I'm going to say on this virtual switch, I'm going to let these six network cards be on this virtual switch. 00:09:29.840 --> 00:09:34.239 And on this other second virtual switch, I'm going to have these four network cards be on that one. 00:09:34.239 --> 00:09:36.640 You can divide them however you want. 00:09:36.640 --> 00:09:44.039 I could have three, you know, virtual switches, and I could say I have these three on this one and these three on this one and these four on that one or something like that. 00:09:44.039 --> 00:09:49.140 And maybe the reason why I have two virtual switches is all my VMs are on one virtual switch. 00:09:49.140 --> 00:09:54.239 And on my second virtual switch, I have my iSCSI storage. 00:09:54.239 --> 00:10:01.739 Or maybe I have three virtual switches, and my VMs live on one virtual switch, and my iSCSI storage is on my second virtual switch. 00:10:01.739 --> 00:10:04.640 And my third virtual switch has, like, my VM kernel ports. 00:10:04.640 --> 00:10:12.539 I have a VM kernel port for management and another VM kernel port for things like vMotion and things like that. 00:10:12.539 --> 00:10:19.739 And on my iSCSI virtual switch for my virtual storage, I need a VM kernel port also there that connects to my iSCSI storage, too. 00:10:19.739 --> 00:10:25.340 So you can see we can take those virtual switches and we can divide up our physical NICs on there. 00:10:25.340 --> 00:10:34.340 But again, if I have one virtual switch and I'm running 10 VLANs, how do I say what VLANs are, you know, what and what VMs connect to what? 00:10:34.340 --> 00:10:37.440 On a virtual switch, I can create what's called a port group. 00:10:37.440 --> 00:10:42.840 So I can divide up my virtual networking in my host with virtual switches. 00:10:42.840 --> 00:10:46.840 I can divide up those virtual switches into what they call port groups. 00:10:46.840 --> 00:10:52.739 And a port group is going to basically kind of be analogous with a VLAN, okay? 00:10:52.739 --> 00:10:53.539 It doesn't have to be. 00:10:53.539 --> 00:10:55.340 It's not exactly, you know, one for one. 00:10:55.340 --> 00:11:03.039 But oftentimes, the reason why we create port groups on a virtual switch is so we can create different VLANs with different VLAN tags. 00:11:03.039 --> 00:11:07.340 So I might go in and say, okay, I'm going to create this VLAN 50 for my exchange servers. 00:11:07.340 --> 00:11:12.539 And I'm going to create another port group that is for file and print servers, and that's VLAN 51. 00:11:12.539 --> 00:11:16.940 And another port group for my domain controllers, and that's VLAN 52. 00:11:16.940 --> 00:11:18.539 I'm not sure what examples I said before. 00:11:18.539 --> 00:11:24.739 But, you know, basically, I can create port groups for different types of VMs and then put different VLAN tags on there. 00:11:24.739 --> 00:11:30.039 Maybe I have my Linux boxes that are running a certain database. 00:11:30.039 --> 00:11:36.940 So I might have my Linux boxes be on VLAN 60 through 69, and databases are on VLAN 60. 00:11:36.940 --> 00:11:43.940 And my Linux boxes that are running, you know, web applications are on VLAN 61, okay? 00:11:43.940 --> 00:11:47.640 So I can look at these different things again, 172, 16, 61. 00:11:47.640 --> 00:11:51.440 Oh, that's a Linux box and it's running a web application, okay? 00:11:51.440 --> 00:11:53.940 That might be how I decided to break things up. 00:11:53.940 --> 00:12:00.239 You don't always see things divided up so cleanly like that where, you know, you just look at an IP address and know exactly what it is. 00:12:00.239 --> 00:12:06.239 But wouldn't it be fantastic if we actually did design our data centers that cleanly and stuck to it? 00:12:06.239 --> 00:12:07.840 That's strictly. 00:12:07.840 --> 00:12:13.940 So a virtual switch is a way of breaking up the networking on a host. 00:12:13.940 --> 00:12:18.340 And we can assign physical NICs to a virtual switch and then a port group to that. 00:12:18.340 --> 00:12:24.340 But the problem with a virtual switch is, in my example, maybe I have in my data center 100 hosts. 00:12:24.340 --> 00:12:29.539 With a regular virtual switch, I have to go to every host, create those virtual switches, 00:12:29.539 --> 00:12:34.840 and create those port groups named exactly the same on all the hosts. 00:12:34.940 --> 00:12:40.440 If the name isn't exactly the same, including maybe I want to call this port group Exchange. 00:12:40.440 --> 00:12:44.340 I did capital E-X-C-H-A-N-G-E, Exchange. 00:12:44.340 --> 00:12:46.739 But on the next one, I did a lowercase e. 00:12:46.739 --> 00:12:47.440 Guess what? 00:12:47.440 --> 00:12:50.940 So the two hosts, those are different port group names. 00:12:50.940 --> 00:13:00.440 And so if a VM has a connection with a virtual NIC to that Exchange port group with a capital E and I want to vMotion it to another host, 00:13:00.440 --> 00:13:06.840 I want to move that VM to another host with that same port group, but it's a lowercase e, 00:13:06.840 --> 00:13:08.340 it'll say that's not the same. 00:13:08.340 --> 00:13:10.039 I can't vMotion over there. 00:13:10.039 --> 00:13:14.140 Or I have to go in there and select the different port groups I wanted to move to and things like that. 00:13:14.140 --> 00:13:16.140 It gets to be cumbersome. 00:13:16.140 --> 00:13:18.640 DRS will have a hard time working in that kind of environment. 00:13:18.640 --> 00:13:21.140 HA will have a hard time working in that kind of environment. 00:13:21.140 --> 00:13:23.039 So they need to be named exactly the same. 00:13:23.039 --> 00:13:28.739 So you can see creating virtual switches, just regular virtual switches, when you have a large number of hosts, 00:13:28.739 --> 00:13:35.739 becomes very cumbersome and you have to make sure you are typing things meticulously and the VLANs have to be meticulously the same. 00:13:35.739 --> 00:13:40.140 So what VMware came out with is what they call a distributed switch. 00:13:40.140 --> 00:13:42.140 So now, again, I go back to vCenter. 00:13:42.140 --> 00:13:46.539 This switch is created in vCenter, not on the host. 00:13:46.539 --> 00:13:51.039 A regular virtual switch, I can go into vCenter and connect to my host and say create my virtual switch, 00:13:51.039 --> 00:13:53.640 then go to the next host and create my virtual switch. 00:13:53.640 --> 00:13:59.340 But with a distributed switch, I can go to my networking option and create a distributed switch. 00:13:59.340 --> 00:14:01.239 And I define the switch. 00:14:01.239 --> 00:14:05.539 I define my exchange port group on there and I give it VLAN 50. 00:14:05.539 --> 00:14:12.140 And I create my ADDS port group and I give it VLAN 51 and so on. 00:14:12.140 --> 00:14:19.640 Then I say I want this virtual switch and these port groups I created to go to and then live on all of these hosts. 00:14:19.640 --> 00:14:21.039 Maybe I say all 100. 00:14:21.039 --> 00:14:30.340 Or maybe I say, well, exchange and Active Directory and all these things are only going to live on this cluster of hosts. 00:14:30.340 --> 00:14:36.940 So I only assign to those 10 or 20 or 30, however many are in those clusters, to those hosts. 00:14:36.940 --> 00:14:44.940 And now they automatically all have the same virtual switches created on them, distributed virtual switches, 00:14:44.940 --> 00:14:49.840 the same port groups, named exactly the same with the exact same VLANs configured, 00:14:49.840 --> 00:14:54.239 and they have the same network, physical network card configuration. 00:14:54.239 --> 00:14:59.739 Because I can say on this virtual switch, I want it to have three uplinks. 00:14:59.739 --> 00:15:03.640 And then when I assign it to host, it'll say, okay, well, which physical NICs do you want to go to uplink one, 00:15:03.640 --> 00:15:06.039 to uplink two, uplink three on the next host? 00:15:06.039 --> 00:15:09.739 Which physical NIC do you want to go to uplink one, uplink two, uplink three? 00:15:09.739 --> 00:15:11.539 And you can do that for all of them. 00:15:11.539 --> 00:15:16.039 So now when I make changes and I add another port group, it goes to all the hosts. 00:15:16.039 --> 00:15:20.539 If I change the VLAN tag on one of the port groups, it goes to all the hosts automatically. 00:15:20.539 --> 00:15:24.440 I don't have to manage those hosts one at a time and make all those changes. 00:15:24.440 --> 00:15:33.840 So a vSphere distributed switch is a centrally managed switch that all my hosts in my vSphere environment potentially can use. 00:15:33.840 --> 00:15:35.239 Now, they don't have to use it. 00:15:35.239 --> 00:15:36.640 I can pick and choose which one to use. 00:15:36.640 --> 00:15:40.739 I can create a different distributed virtual switch and assign it to different hosts if I wanted to. 00:15:41.039 --> 00:15:42.340 Or to the same host. 00:15:42.340 --> 00:15:44.140 My hosts have 10 NICs. 00:15:44.140 --> 00:15:46.940 This first distributed virtual switch is only using three. 00:15:46.940 --> 00:15:52.039 The next distributed virtual switch goes to the same 30 hosts maybe, but uses different NICs. 00:15:52.039 --> 00:15:56.539 And I create another one that goes to a different set of hosts, a different 10 or 20 or 30 hosts. 00:15:56.539 --> 00:16:00.940 So virtual switches are defined on each host one by one. 00:16:00.940 --> 00:16:09.440 And a vSphere distributed switch is going to be defined in vCenter and then attached or assigned to the host I choose. 00:16:09.440 --> 00:16:10.440 Okay. 00:16:10.440 --> 00:16:13.840 So that's the networking part of some basic virtualization. 00:16:13.840 --> 00:16:17.140 Now, if this sounds like I'm just kind of glossing over it, I am. 00:16:17.140 --> 00:16:19.039 This is an introductory lesson. 00:16:19.039 --> 00:16:27.640 So we're going to get into a lot more depth onto how to configure these things in later lessons, later chapters throughout the course. 00:16:27.640 --> 00:16:28.440 So storage. 00:16:28.440 --> 00:16:33.140 There's different types of storage you can configure in a vSphere environment. 00:16:33.140 --> 00:16:34.739 There is local storage. 00:16:34.739 --> 00:16:38.340 So there's storage that is, you know, disks in this host. 00:16:38.340 --> 00:16:44.239 And I'm going to put on the disks that are in this host, I'm going to put my VMs on there. 00:16:44.239 --> 00:16:47.539 But the problem with that is those VMs are on this host. 00:16:47.539 --> 00:16:50.739 If this host goes down, if it catches fire, those VMs are there. 00:16:50.739 --> 00:16:52.140 And so now they're gone, right? 00:16:52.140 --> 00:16:59.140 I can't just start them up from someplace else because they lived on the storage on that host, which is no longer available because the host caught fire. 00:16:59.140 --> 00:17:02.140 The other option would be a SAN, right? 00:17:02.140 --> 00:17:05.939 So the nice thing about a SAN, which is a storage area network, right? 00:17:05.939 --> 00:17:08.739 So storage area network kind of refers to an entire network. 00:17:08.739 --> 00:17:12.140 This is going to be a device that lives on that network. 00:17:12.140 --> 00:17:16.339 So this device is going to be either fiber channel or it's going to be iSCSI. 00:17:16.339 --> 00:17:22.540 And I'm going to be able to connect my hosts to this storage device. 00:17:22.540 --> 00:17:26.939 And the storage device is going to have, for example, a LUN carved out on it. 00:17:26.939 --> 00:17:31.439 And multiple hosts can point to that same LUN and see that same LUN. 00:17:31.439 --> 00:17:40.439 So now the VMs that are on there are accessible to all the hosts that are connected to and, you know, in that cluster and connected to that LUN and so forth. 00:17:40.439 --> 00:17:43.439 Now, only one host can run a VM at a time. 00:17:43.439 --> 00:17:48.640 So I'm not trying to suggest that, you know, multiple hosts can all access the same VM. 00:17:48.640 --> 00:18:01.239 But if my host 1 is running VMA and everything's going great, VMA is running, doing its job, and host 1 catches fire and it's gone and we can't connect to it anymore, 00:18:01.239 --> 00:18:05.040 host 2 can then say, oh, look it, host 1's gone down. 00:18:05.040 --> 00:18:07.040 That's what HA is, high availability. 00:18:07.040 --> 00:18:11.640 Host 1 has gone down and it was running VMA. 00:18:11.640 --> 00:18:13.439 I know VMA lives over here. 00:18:13.439 --> 00:18:17.439 I'm going to connect to the files that were for VMA and start up VMA. 00:18:17.439 --> 00:18:21.439 Now, HA is more complicated than that, and we'll discuss that when we get into that lesson. 00:18:21.439 --> 00:18:29.239 But for right now, just know another host can connect to that same storage, find that VM, and start that VM up. 00:18:29.239 --> 00:18:35.239 And maybe I'm down for, you know, a minute or two or something like that if a host has a catastrophic failure. 00:18:35.239 --> 00:18:49.239 There's also DRS so that, let's say, again, host 1 is running VM A, B, C, and D, and all of a sudden these VMs are really working hard and they're using a lot of network or a lot of CPU. 00:18:49.239 --> 00:18:55.239 And host 1 can't keep up with the load from all these VMs and all the heavy lifting they're doing. 00:18:55.239 --> 00:19:00.239 DRS, distributed resource scheduler, can just say, well, I'm going to move a VM over to host 2. 00:19:00.239 --> 00:19:04.239 And host 2 can see that same storage because it's on the network, right? 00:19:04.239 --> 00:19:05.239 It's on the SAN. 00:19:05.239 --> 00:19:09.239 And it just moves it over while it's running and users don't even see a thing. 00:19:09.239 --> 00:19:11.239 They don't even notice it's been moved. 00:19:11.239 --> 00:19:14.239 They don't notice an impact in performance. 00:19:14.239 --> 00:19:17.239 They don't notice, you know, a loss of connectivity. 00:19:17.239 --> 00:19:23.239 The only thing that might happen is it might not be as resource constrained anymore so it might be responding a little faster. 00:19:23.239 --> 00:19:25.239 And that way performance might be better. 00:19:25.239 --> 00:19:27.239 That's the hope anyway, right? 00:19:27.239 --> 00:19:36.239 So by having a SAN and that shared storage versus just local storage, we have different DR capabilities. 00:19:36.239 --> 00:19:38.239 We have different HA capabilities. 00:19:38.239 --> 00:19:40.239 We just have better resource utilization. 00:19:40.239 --> 00:19:44.239 Maybe I don't have a problem with my resources at all, but I need a patch host A. 00:19:44.239 --> 00:19:46.239 Host A is kind of out of date. 00:19:46.239 --> 00:19:50.239 VMware released a new critical security patch that I need to get pushed out. 00:19:50.239 --> 00:19:58.239 I can just move all the VMs from host 1 to host 2, patch host 1, get it all up to date and current and, you know, no longer security vulnerability. 00:19:58.239 --> 00:20:01.239 And then when it's done, it comes out of maintenance mode. 00:20:01.239 --> 00:20:06.239 I can move all the VMs off of host 2 over to host 1, and I can patch host 2. 00:20:06.239 --> 00:20:13.239 And, you know, if I had five hosts, I can divide them up amongst the five, you know, the four that are remaining, and patch that one. 00:20:13.239 --> 00:20:18.239 Then I can move VMs back around and evacuate host 3 to the other host and patch that one. 00:20:18.239 --> 00:20:25.239 So having shared storage like a SAN, either an iSCSI or a Fibre Channel SAN, allows me a lot of functionality. 00:20:25.239 --> 00:20:35.239 Again, things like, you know, DR capabilities, backup capabilities, DRS capabilities, you know, for resource scheduling, HA capabilities. 00:20:35.239 --> 00:20:42.239 Now somewhat sort of newer, but it's been out for quite a while now actually, functionality is what they call vSAN. 00:20:42.239 --> 00:20:47.239 So with vSAN, we're going back to the disks that are on the host. 00:20:47.239 --> 00:20:51.239 All the hosts have local storage on them. 00:20:51.239 --> 00:20:59.239 And maybe they have 15 or 20 or 30, or it depends on how big of a host you need, how much storage you need, and how fast you need your storage to be. 00:20:59.239 --> 00:21:01.239 But they have local disks on them. 00:21:01.239 --> 00:21:04.239 Let's just say they have, you know, 15 disks each. 00:21:04.239 --> 00:21:07.239 And they're all the same size, all the disks across all the hosts. 00:21:07.239 --> 00:21:11.239 They're built for this functionality, so they're all the same size. 00:21:11.239 --> 00:21:14.239 They have the same number of disks, the same speed of disks. 00:21:14.239 --> 00:21:22.239 And rather than just put VMs on host one, and that's where they live, it creates a virtual SAN. 00:21:22.239 --> 00:21:25.239 So it's not central storage stored in one place. 00:21:25.239 --> 00:21:26.239 It's on the host. 00:21:26.239 --> 00:21:31.239 But what it does is it actually replicates the VMs between the other hosts. 00:21:31.239 --> 00:21:42.239 So if host one is running a VM, and the VM is on that host, and the other four, five, or six hosts in my environment also are running vSAN, 00:21:42.239 --> 00:21:54.239 that host one with VMA, that's running VMA, is also the copy of VMA, maybe on host three and on host six or something like that or host five. 00:21:54.239 --> 00:21:56.239 And so that VM is in multiple places. 00:21:56.239 --> 00:22:06.239 So then all of a sudden, if that host one catches fire again, all of a sudden host three can say, oh, I have resource availability for that machine. 00:22:06.239 --> 00:22:10.239 And I have the machine, you know, copy the files on me. 00:22:10.239 --> 00:22:13.239 I'm going to start VMA on host three. 00:22:13.239 --> 00:22:16.239 And then host two can say, well, you know what, copy it over to me too. 00:22:16.239 --> 00:22:21.239 Because we need to have, you can configure, you know, an N plus how many copies you want. 00:22:21.239 --> 00:22:24.239 Maybe you have a N plus two kind of configuration. 00:22:24.239 --> 00:22:27.239 So we have the one we're running, and we want two copies of it. 00:22:27.239 --> 00:22:31.239 So when host one caught fire, I had the one running and one copy of it. 00:22:31.239 --> 00:22:33.239 So host two says, give me another copy. 00:22:34.239 --> 00:22:41.239 Copy to me also, so that way we can keep up our N plus two, you know, failover capability that we were hoping for. 00:22:41.239 --> 00:22:49.239 So vSAN is a way of using local disks on your hosts as if it's shared storage out on the network. 00:22:49.239 --> 00:22:51.239 And they replicate that across all each other. 00:22:51.239 --> 00:22:52.239 It's very cool. 00:22:52.239 --> 00:22:56.239 It's been around since I believe like vSphere 5.5 or something like that. 00:22:56.239 --> 00:23:02.239 So it's been around since around 2000, I want to say around 2010, 2011, something like that. 00:23:02.239 --> 00:23:06.239 So it's not super new, but it keeps getting better and better and better. 00:23:06.239 --> 00:23:11.239 And we'll have a lesson on vSAN, and we'll talk about, you know, how we used to have to have cache disks. 00:23:11.239 --> 00:23:17.239 And now with the most current version of vSphere 8, we don't have to if we have certain other requirements met, things like that. 00:23:17.239 --> 00:23:25.239 So vSAN is a way of using local disks on our hosts as if it's a SAN, as if it's shared storage available on the network. 00:23:27.239 --> 00:23:31.239 So here's a typical and traditional installation in our physical environment. 00:23:31.239 --> 00:23:32.239 We have our hardware. 00:23:32.239 --> 00:23:34.239 We have that physical server. 00:23:34.239 --> 00:23:37.239 We are going to install an operating system on that box. 00:23:37.239 --> 00:23:40.239 We're going to put an application on that operating system. 00:23:40.239 --> 00:23:48.239 And that big, huge box is dedicated to just that one OS and maybe that one application or that one service that's running on that box, right? 00:23:48.239 --> 00:23:54.239 So all the resources that, you know, this OS and this application need all come from that one box. 00:23:54.239 --> 00:23:58.239 And you might find your utilization level be very, very low. 00:23:58.239 --> 00:24:05.239 You might only find, you know, in a physical environment, if you had 100 servers, you'd be running like 10% utilization or something super low like that. 00:24:05.239 --> 00:24:12.239 In a virtualized environment, you'll see here, as we discussed, you have this server, right, with all this hardware. 00:24:12.239 --> 00:24:19.239 You have, you know, 30 cores, and you have 256 gigs of RAM, and you have however many hard drives you need, and you've got all these network cards. 00:24:19.239 --> 00:24:21.239 And I installed ESXi. 00:24:21.239 --> 00:24:24.239 I installed a Type I hypervisor on top of the hardware. 00:24:24.239 --> 00:24:33.239 And then I create virtual machines on that host, and then I install an operating system on there, and I install my application or my service. 00:24:33.239 --> 00:24:41.239 And on that same physical box, I create another virtual machine, install another operating system, and another application or another service. 00:24:41.239 --> 00:24:46.239 And the great thing about it is these virtual machines are very secure containers. 00:24:46.239 --> 00:24:51.239 So this VM doesn't see what's happening in that one, but this one doesn't see what's happening in the other. 00:24:51.239 --> 00:24:57.239 They're secure containers so that what's happening on one CPU doesn't get affected by the other. 00:24:57.239 --> 00:25:01.239 One can't see the other one's RAM. 00:25:01.239 --> 00:25:07.239 You will sometimes see, you know, different security bulletins out there about a vulnerability where a hacker can do this weird thing, 00:25:07.239 --> 00:25:12.239 but usually they have to have physical access to the box and all this stuff in order for that to become a problem. 00:25:12.239 --> 00:25:15.239 It's very rare. 00:25:15.239 --> 00:25:19.239 VMware has a feature they call transparent page sharing. 00:25:20.239 --> 00:25:28.239 And quite a while ago, a professor at some university or somewhere figured that it was possible for a VM, 00:25:28.239 --> 00:25:38.239 if you gave it really specific instructions in a certain way, to see what might have used to have been in RAM from another VM that's no longer there. 00:25:38.239 --> 00:25:42.239 There was never any reports of that actually being done. 00:25:42.239 --> 00:25:45.239 It was just proven that theoretically it might be possible kind of thing. 00:25:45.239 --> 00:25:49.239 So VMware by default turns off transparent page sharing now. 00:25:49.239 --> 00:25:58.239 But a lot of these vulnerabilities you hear about are either ones that are extremely difficult to take advantage of. 00:25:58.239 --> 00:26:00.239 You would need physical access to the box. 00:26:00.239 --> 00:26:02.239 You have to be in the data center. 00:26:02.239 --> 00:26:09.239 Or it's something where it's, you know, very unlikely you'll get what you're looking for if you can even possibly execute this. 00:26:09.239 --> 00:26:13.239 It's really, honestly, a very secure environment. 00:26:13.239 --> 00:26:19.239 You would not have the government, DOD, large financial institutions like, you know, banks and lenders. 00:26:19.239 --> 00:26:24.239 And, you know, Wall Street is using, you know, these types of things. 00:26:24.239 --> 00:26:27.239 The New York Stock Exchange uses VMware. 00:26:27.239 --> 00:26:35.239 Obviously it's been proven to be a very, very secure platform and allows us to, you know, take advantage of these resources. 00:26:35.239 --> 00:26:42.239 So in a data center where maybe before I only was using 10% of my resources, now all of a sudden I can start using like 75% of the resources. 00:26:42.239 --> 00:26:47.239 And I don't want to get to 100 because I want to have room for growth and room for spikes and things like that. 00:26:47.239 --> 00:26:50.239 I want to have room to take hosts down so I can patch other hosts. 00:26:50.239 --> 00:26:52.239 So maybe I get like up to around 75% utilization. 00:26:52.239 --> 00:26:59.239 And if I start to go above that, I add another host or two or whatever I need to get back to that 75%. 00:26:59.239 --> 00:27:06.239 And the hypervisor does this really fantastic job of policing who gets access to what resource and when. 00:27:06.239 --> 00:27:12.239 So one VM doesn't get to monopolize the entire host or get to monopolize, you know, the network and things like that. 00:27:12.239 --> 00:27:21.239 So that's what virtualization resource allocation looks like, where you have a hypervisor controlling when VMs get access to resources. 00:27:21.239 --> 00:27:26.239 Now, one thing that's really cool you can do, too, is by default they'll all get equal access. 00:27:26.239 --> 00:27:31.239 So they'll all get like a certain level of, you know, the same level of access to a resource. 00:27:31.239 --> 00:27:34.239 But maybe I have an application that's just really critical to me. 00:27:34.239 --> 00:27:38.239 And I need this application to be guaranteed to perform better. 00:27:38.239 --> 00:27:46.239 So I can tell the hypervisor that I want this VM to have a higher level of priority to the CPU, for example. 00:27:46.239 --> 00:27:53.239 Even though all these VMs have two virtual CPUs, so they should all be equal, this one needs a higher level of access. 00:27:53.239 --> 00:27:57.239 And I can go in there and I can control things like shares and things, and we'll discuss that, 00:27:58.239 --> 00:28:08.239 to make sure that this VM actually gets the resources it needs when it needs it and it performs at a higher level than the other ones if there's contention. 00:28:08.239 --> 00:28:11.239 If there's no contention, they're all getting what they want, everything's fine. 00:28:11.239 --> 00:28:20.239 But if they start to get constrained and now there's contention on the resource, I can control which ones have a higher priority or which ones have a lower priority to that resource. 00:28:20.239 --> 00:28:27.239 So, in conclusion, we discussed virtualization basics and we discussed some terminology and components in virtualization.