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