Welcome back to vSphere 8 in the real world. Now we're going to discuss an introduction to vSphere.
So what is vSphere? So vSphere is not really a single product. It's a suite of products. So it's
kind of like talk about Microsoft Office, right? We have Word, we have Excel, we have PowerPoint,
we have OneNote. There's all these different applications, all these different products,
and then Microsoft has grouped them together into a suite that they call Microsoft Office.
So vSphere is kind of the same way. So with vSphere, we have ESXi, right? And that's kind
of the core, the foundation, that's like the basic piece you have to have to have a vSphere
environment. But if you want to manage that vSphere environment, which without management,
you don't have a vSphere environment, you also need vCenter, right? So there's at least two
products you're going to have to have to have vSphere. You're going to have to have ESXi,
and you're going to have to have vCenter. Now, as I mentioned in previous lessons,
you might also have Horizon for virtual desktops. You might also go, you know,
real advanced in your networking and go to software-defined networking and use NSX.
You might add other tools in for Kubernetes for, you know, for doing containers. You might also do,
you know, advanced reporting and things like that with vRealize. So there's a lot of different
things that VMware sells that you can plug into, you know, your vCenter and work with your ESXi.
But the foundation, the most basic components that you're going to have to have to have a vSphere
environment, ESXi, the hypervisor, and vCenter, the management tool for the hypervisor. And then
there's a bunch of other things you can plug in on top of that to enhance that experience to make
your data center more robust, okay? So for managing this vSphere environment,
you have a lot of different options. The most common one, usually one of the very first ones
most people use after the DCUI, because you'll probably go into DCUI on your ESXi host and
assign it an IP address and things like that. But then it's the web client. You're going to connect
to your host through the web client, or you might connect to vCenter through the web client and add
your host in. It kind of, you know, it's up to you. But the web client is where you're going to do a
lot of your management in your vSphere environment. That's where people spend most of their time.
If you want to look at performance, you know, of your vSphere environment, you're probably going to
go to the web client or vCenter and look at performance. If you want to create a data store,
if you want to add another host, you want to create a new VM. Now, you don't have to do all
those things for the web client. You can also do a lot of these things from a command line.
You can go into either the DCUI, meaning like, you know, the console of that machine,
or you can connect to the host or vCenter through SSH and manage them that way.
If you have, you can do a lot of scripting, you want to automate a lot of tasks and things like
that, that might be how you do it. You might, you know, create scripts and, you know, the automate
tasks that you do a lot and connect through SSH and run your scripts. Most people spend a lot of
their time actually in vCenter. And that, you know, that would be done through that web client.
So, objects that you're going to see in your web client, objects that you're going to manage
in your vSphere environment will be the VMs, obviously, right? The first thing, first and
foremost, will be your hosts. You're going to configure your virtual networking, you're going
to configure your storage, you're going to configure, you know, all that kind of stuff to
get the host ready for virtual machines. Then you start creating VMs. And that's the whole point.
That's why you have vSphere. You have vSphere because you want to, you know, run virtual
machines, you want to run workloads, you want to get work done. What gets that work done are your
VMs and those VMs live on your hosts, okay? Now, there's data centers too. And data centers
are kind of what they sound like. A lot of times your data center might be, if you have a data
center in Houston, you might have a Houston data center in your vSphere environment. And if you
have another data center in, you know, San Francisco or New York or Seattle, you might
have data centers listed like that. Now, they don't necessarily have to be that way, right?
You can kind of call them whatever you want. They don't have to be geographically,
you know, divided or organized in vCenter. This is a really common way that most people kind
of organize and group their resources. Maybe you have some huge infrastructure with this
massive backbone and to use San Francisco and Houston are the same thing. I can easily move
a VM from a server in Dallas over to San Francisco, no problem, because I have this huge
pipe between them and they just kind of live like they're one environment, okay? That's really
uncommon. That's not the most likely scenario for 99% of the people out there. So, if that is you,
then you may not have a San Francisco data center and a Houston data center. You might,
you know, have some other name for it that, you know, is more business oriented,
business function oriented or something like that. Most people are going to have their Houston and
their San Francisco and their New York and their LA and things like that. And then within that
data center, I can start creating clusters. If I only have five hosts or 10 hosts in my data center
in Dallas or Houston or whatever, then maybe I just have one cluster. But maybe I have a couple
of hundred hosts in my, you know, Dallas data center. And so, I have a cluster that is for
this group of hosts that run these kinds of workloads. And I have another cluster that's
for another group of hosts that runs a different type of workload. Another reason why you might
create multiple clusters would be these hosts here are three years old. They have a certain
generation of Intel processor and certain resources, your hardware in them. And this
other cluster that we just got last week has the most latest, greatest Intel generation processors.
Well, vMotion isn't going to work from hosts in this cluster to this one unless I turn on what
they call enhanced vMotion capabilities. And then basically, I'm dumbing down the processor. I just
paid a bunch of money for. And I don't want to do that. In this scenario, for this example,
I don't want to dumb down my processors and not let my VM use all the new advanced features of
this processor. So, I'm going to create a cluster for my newest hosts. And so, the VMs can move
around all these hosts, no problem, because they all have the same processor. And this other cluster
has, you know, a slightly older generation of Intel processor. And so, they can move around
them, no problem, because they're all the same. But they can't go back and forth very easily.
And I might have a third cluster that's running AMD processors. And so, therefore,
I need to have those divided up separately too. So, that's just, you know, one reason why you
might create multiple clusters. The number of hosts you have might be multiple clusters. The
types of workloads you want to run on these clusters. I want this cluster to just be for
a certain type of workload. So, I create a cluster for that. All right. So, clusters are just groups
of hosts. And you can group them for various different reasons. Then a resource pool is a way
of carving up that cluster to say that the VMs that I put in this resource pool either are going
to be limited and only able to use a certain amount of resource, or they're going to be
guaranteed through a reservation a certain amount of resource, right? So, maybe in this resource pool,
I have, you know, a few VMs that are a very critical, high-priority workload. And I want
to make sure they're guaranteed at least certain resources. So, I put a reservation on the resource
pool, put the VMs in there. These VMs are always going to have at least minimum the resources
guaranteed on that resource pool. Maybe you have another resource pool, and these VMs are the
complete opposite. I want them to run. I need their work done. But if it gets done right away,
or if it takes them 20, 30, 40 minutes, or whatever, I don't care. So, I'm going to put
limits on this resource pool. So, these VMs are going to run and get their work done,
but it might take them a while because they can't use all the resources that are available.
They can't use all the resources that are available to the first resource pool that ran my
priority workload, right? They have that reservation set to it. So, resource pools can be used for
different reasons. You do see resource pools used for sure, but not as much as you might think
because they can get tricky. Because I can have a resource pool within a resource pool.
I can have my cluster, which your cluster is kind of without being called this a resource pool.
Then within this cluster, I can create another resource pool, and I can guarantee it a certain
amount of resources. I can then create a resource pool within that and guarantee this another amount
of resources. But this resource that's guaranteed can't exceed what the one above it's guaranteed
because it has to feed off of that percentage of that. We'll get into resource pools and stuff
more. Just realize that they're very useful. They are definitely used, but they're not used
just willy-nilly, not just kind of thrown around. Not everything lives in a resource pool,
okay, because they can get a little bit tricky. Use them when appropriate, but don't abuse them.
So, plugins. So, with vSphere 8, they actually, plugins used to be installed into your vCenter
server, right? And they're kind of managed through there. When you logged in, you would
see the plugin. Now, we have what we call remote plugins. And so, the plugins no longer live
in vCenter. They live outside of vCenter. They live with the host and with your browsers and
stuff. And so, it's a much more secure model. It makes it kind of easier for managing plugins.
And for the time being, your local plugins might still work, but they might not. So,
make sure before you upgrade to vSphere 8 that you know, are you using plugins or not? And is
there a new remote plugin to replace the one you're currently using from your vendor? Because
if not, whatever you're using that plugin for might not work with vSphere 8.
So, some goals of virtualization. So, first of all, hardware independence.
I no longer have to worry that my VM has to run on this certain generation Intel processor
and this network card and this motherboard and things like that. It's going to use a VMware
driver for a network card, a VMware driver for the video display, and everything's going to
be virtualized. The only thing that really the VM sees directly that it knows it has
is that processor. But if I shut down the VM and move it to a different host with a different
processor, the VM should still run no problem. The only issue would be trying to live migrate
it from one host to another. The processors can't be different. They need to be the same family,
same generation of processors. But what that means is that this VM running on this host over here,
all of a sudden, this host catches fire. I can just start it up on those hosts over there.
And maybe those hosts have newer processors, older processors, different vendor processors.
It doesn't matter. I don't have to worry about what network cards over there. I don't have to
worry about what hard drives over there, what motherboard, what BIOS is on that motherboard,
devices are attached to the motherboard. None of that's going to matter. The VM is going to
see the same set of drivers it saw before because it's all just virtualized, right?
There's that abstraction of the hardware from the physical machine to the virtual machine,
and the hypervisor in the middle there abstracts that out. So efficiency, like I mentioned before,
in a physical environment, when we had all physical data centers, it was very common to see
people do reports on data center utilization and find out, yeah, we're running hundreds of servers,
and we are running below 10% utilization on average across this whole data center.
We're wasting a ton of money on hardware, a ton of money on electricity, a ton of money on cooling
of those machines because I have to isolate this application from that application, and this
service from that service, and things like that. So with virtualization, I can take all these VMs,
these applications that are isolated from each other in VMs, and stack them on top of each other
in this host, and none of them see each other. Now my host went from 6% or 7% utilized to 75%
utilized. So what that now means, I don't need 300 hosts. I only need 65 hosts or something like that
maybe, right? I can get by with far fewer. That means less electricity, less cooling, less square
footage in my data center, all that kind of stuff. So flexibility, again, I can easily move VMs from
one host to another. If I want to patch this physical host over here, I can just move the VMs
off onto another host. They're still running. No one ever knows they moved. I can patch the host,
move things around. If I need to upgrade hardware, I need to add more RAM to the host. I need to add
more network cards, upgrade the network cards. I need to take out these one gig NICs and put in 10
gig NICs because the network's running too slow. The VMs don't know. They don't care. When they
get back on the host with a new 10 gig NICs, they see the same network interface card. They just keep
running and doing their thing. It's no problem at all. Resource allocation, we've talked about
resource pools and things like that. We can create reservations. We can then use shares.
We can allocate a certain number of virtual CPUs to a VM, a certain amount of RAM to a VM.
We can add RAM. We can add virtual CPUs to the VM. We don't have to worry about, in the old days,
when we bought a host, we bought the biggest host our budget would allow us. Did I need all that?
I don't know. Maybe not. But I have the budget today. And if I don't spend the money today,
and all of a sudden, next year, I need more RAM, I may not have the budget for it. I may not get that.
In a virtual environment, you want to give your VMs the minimum hardware they need to do their
job. So maybe I'll create a VM and only give it two virtual CPUs, and I'll give it four or six
gigs of RAM. And it runs fine. All of a sudden, next year, it's not running so well. All of a
sudden, it needs more RAM. Adding RAM, it's a matter of checking a little arrow, bumping up
the RAM. I need to add more virtual CPUs. No problem. Add more virtual CPUs. I don't have to
go out and ask for more budget to buy this. They're already in the box. I bought the biggest
box I can afford budget-wise. But now, I only allocate what VMs need. I'm not wasting resources
that way. So you can allocate resources in a very detailed, methodical way.
DR and business continuity plans. So there's all kinds of different solutions out there now to
where I can be running my data center, and everything in this data center, maybe I'm running
hundreds of virtual machines, thousands of virtual machines on hundreds of hosts or something like
that. And everything's being copied over to another data center in a different city or state or
country. And all of a sudden, something happens, and this data center catches fire, it burns down,
a tornado takes it out. There's a massive power outage that's not going to be fixed for days and
days and days. And my generators can't run that long. ISP issues. Someone hit the side of the
building with a truck and took out all the ISPs that were coming into the building. I just fail
over to this other data center over here, and all the VMs come up. And maybe I had some downtime.
Maybe I had downtime of 10, 15, 20 minutes. Maybe I didn't have any at all. I planned it. I said,
oh, wow, there's a huge storm coming, and pretty likely we're going to lose power to this building
for quite a while. And our generators, I know, only run for eight hours before we're out of fuel,
and we won't get more fuel. I'm just going to fail everything over to this data center over in this
other city, this other state that won't be impacted by the storm. So, I just DR everything over,
right? I planned for this failure to happen. I don't have to sit there and sweat and worry
what happens if this goes down. How am I going to get these resources up and running?
I can do it by checking a couple boxes in an application. So, my DR, my business continuity
plans become very flexible, very dynamic, really easy to implement. There's all kinds
of solutions out there to help me do that. So, advantages and disadvantages of virtualization.
So, some advantages, shared resources, right? A bunch of VMs running on one host,
taking advantage of all these resources that I paid a bunch of money. I paid a bunch of money
for all this RAM. I paid a bunch of money for these super fast processors. And with virtualization,
I'm taking advantage of all these resources with all these different services on these
different virtual machines using them up, okay? Business continuity solutions, like we just
described, become very simple, much easier to plan, much easier to implement, much easier to
execute, all that kind of stuff. Flexibility from hardware. I don't have to worry about,
you know, buying more servers and getting the exact same Dell server with the same motherboard
and the same NICs and the same processors. I'll be like, oh, a year later, I need more servers.
Great. Give me the fastest processor. Give me the greatest, latest, greatest, you know, chip set on
the network cards and all that, and we're going to roll this out. And we'll create a new cluster
for these guys and move some VMs over there. No problem. Everything's good, right? Downtime for,
you know, maintenance for patching and things like that becomes very easy.
So, some disadvantages. Isn't that kind of funny? The first advantage is shared resources,
and the first disadvantage is also shared resources. The disadvantage of shared resources,
it could be that if you haven't used things like shares, if you haven't used things like
reservations, that certain VMs can start to monopolize a host. Certain VMs, you might allocate,
you know, more resources to, more virtual processors or something like that, and all of a sudden,
other VMs are being impacted. It's what they call a noisy neighbor. One neighbor is just more
demanding for resources, and the hypervisor's trying to be fair and dish things out, but based
upon how you configured things, this guy is getting a lot more than the other ones, and it's choking
those ones out. You can fix that. Obviously, you can implement shares. You can implement
reservations and things like that, but it's something you need to keep in mind. It could
become a problem if you don't think about it and plan it out in advance.
So, host failures lead to multiple VM failures. In a physical environment, if a host burns down,
you lost a service. You might have lost a domain controller. You might have lost a DHCP server or
something like that. In a virtual environment, if a host burns down, I might have lost 30 VMs. I
might have lost a domain controller and a DHCP server and a SQL server and an Exchange server
and on and on and on, and I lost a lot of resources. Now, again, back to the advantages,
we have the ability to use something like HA and start those VMs up and going again. So,
I might have that initial pain of losing 30 services or 30 applications all at once,
but then I have DRS bringing them back up somewhere. So, I'm only down for 5, 10, 15
minutes, something like that, while we get all the different services started up, okay?
And another disadvantage is it's more complicated. VMware makes virtualization just about as easy as
it can be made. I just worked with a lot of different hypervisors over the years, and VMware
really makes it the easiest, but it's not easy. It's not pain, you know, completely
set it and forget it. It's not just check a box and everything's configured and you walk away from
it. It's definitely something you have to plan and think about and, you know, put some thought
and consideration into. It's complex, right? But VMware makes it about as easy as it can be made.
So, I mentioned earlier about how VMware is like a suite of products. So, in the VMware vSphere
ecosystem, there's a lot of products. There's Horizon for virtual desktops. There's Workspace
One, which is actually, you know, a VMware-hosted solution for managing desktops and policies and
things like that. NSX is software-defined networking. It's a very, very cool product
that allows you to do a lot of really cool things to your network. It allows you, like I
had mentioned before, create firewalls on, you know, individual VMs. Every VM is firewalled from
all the others and from out in the physical world and all these things. There's all kinds of logging
that's happening, all kinds of intrusion detection and prevention. You know, NSX has a lot of really
great features for security. There's vSAN. vSAN is a great product if you have a bunch of servers,
a bunch of storage, because maybe you were a physical environment before. This day, it's not
as common as it used to be. And you're like, okay, I'm going to put ESXi on these servers, and I,
you know, put things in the SAN over there. What do I do with all the disks and all these hosts?
Well, vSAN lets you use those disks. Either you can use them as your primary storage for running
your production VMs, or maybe you run it off your SAN and you, you know, have that as, you know,
target for backup or something like that. That's very uncommon. Usually, if you're running vSAN,
it's for your production workloads. But you have options and flexibility.
Cloud Health basically is how it monitors your VMware environment and your vCenter and
reports to you about different things that are going on. Oh, patching needs to be done. There's
resource utilization is excessive. Certain services might have failed, things like that,
right? Carbon Black endpoint protection is an antivirus solution, a really great antivirus
solution. Workstation is a Layer 2 or Type 2 hypervisor for running on Linux and Windows,
and Fusion is for running on Mac, Type 2 hypervisor for Mac.
You know what, I think I'm going to tap out for the day.
Yeah, I don't know if you can hear it, but I can feel it.
No, I am good. I'm good. So, I don't think we meet again, unfortunately, until Monday.
Well, check with Brittany. I mean, if you're, you know, supposed to be off,
then great. But I'm pretty sure she scheduled me for Monday.
Actually, I have nothing. She told me Monday, Tuesday, Wednesday, but nothing's on my calendar
yet. She hasn't scheduled it yet, at least not with me. Yeah. So, if Monday's not an option,
then, you know, I can do next week. I can do Tuesday, Wednesday, Thursday, Friday,
Saturday. I know you're not available all those days. I'm just saying I'm available every day
next week. Well, and also, I'm off Monday, too. So, if you wanted, like, to go do something
Monday and you wanted to do it early, I can do it any time Monday, because I'm off Monday, too.
So, if you want. Okay. Let me know if, again, I don't want to, if you have plans or whatever,
I don't want to screw up your, you know, your time off, your holiday.