WEBVTT

00:00:00.000 --> 00:00:04.000
Welcome back to vSphere 8 in the real world. And now we're going to discuss an introduction

00:00:04.000 --> 00:00:12.160
to resource allocation. Resources are basically going to be things on your ESXi host or in your

00:00:12.160 --> 00:00:20.160
vSphere virtual environment, your CPU, your memory, your disk, your network, things like that

00:00:20.160 --> 00:00:25.040
are all going to be resources that you're going to want to allocate and you're going to want to

00:00:25.040 --> 00:00:32.560
control the allocation of. So resources are going to be assigned to the virtual machines.

00:00:33.360 --> 00:00:38.240
So basically, it's super important that when you're assigning resources to VMs, you don't

00:00:38.240 --> 00:00:44.000
think about your VMs like you would a physical machine. When we go out to buy a physical box,

00:00:44.000 --> 00:00:52.080
we know that we're making an investment. And often if we want to upgrade a resource on a

00:00:52.080 --> 00:00:57.279
physical machine, that means taking something out that we paid for and replace it with something

00:00:57.279 --> 00:01:02.639
else that's newer and greater and better. And maybe we paid X number of dollars for this

00:01:02.639 --> 00:01:09.360
processor. We're going to upgrade the processors. And maybe we paid $500 for this processor. And

00:01:09.360 --> 00:01:14.400
the new one's $1,000. We're not just going to have to pay the additional $500 to get the newer,

00:01:14.400 --> 00:01:19.839
greater processor, right? We're going to take out the $500 one, spend $1,000, put the $1,000 one in,

00:01:19.839 --> 00:01:24.720
and now we spent $1,500 on processors and we have a $1,000 processor.

00:01:25.760 --> 00:01:32.879
Virtual machines obviously are not that way. We don't need to invest everything in the VM when we

00:01:32.879 --> 00:01:41.040
create that VM new. We want to allocate the minimal resources needed to run that VM effectively under

00:01:41.040 --> 00:01:47.839
its highest load, all right, but not say, well, I think in three years, we're going to really need

00:01:47.839 --> 00:01:53.040
this much. I can run it today with four virtual CPUs, but I think in three years, it's going to

00:01:53.040 --> 00:01:57.760
need eight, so I'm going to give it eight. If today it needs four, then you want to allocate

00:01:57.760 --> 00:02:03.680
four. If today it needs four gigs of RAM, but you think it might need 12 in three years, you don't

00:02:03.680 --> 00:02:10.479
allocate the 12, you allocate the four because you want to allocate the resources as sparingly

00:02:10.479 --> 00:02:16.080
as possible because in three years, that RAM is going to be a lot less expensive, right?

00:02:16.080 --> 00:02:22.320
So, go ahead and add the additional RAM in a year, two years, three years when you need it,

00:02:22.320 --> 00:02:26.960
and it's less expensive than it is this year. When you're buying a physical machine, that's

00:02:26.960 --> 00:02:30.080
not necessarily your thought process because you don't want to throw away the resource that you

00:02:30.080 --> 00:02:37.199
just bought and have to buy part of it again and then plus the upgrade, right? So, when you're

00:02:37.199 --> 00:02:43.279
building VMs, you want to make them as small as possible using as few resources as possible

00:02:43.279 --> 00:02:47.600
while giving it the resources it needs to perform its job. We don't want to get ridiculous and say

00:02:47.600 --> 00:02:51.600
we're going to give it, you know, 512 megs of RAM in one process and we're going to try and run a

00:02:51.600 --> 00:02:56.720
Windows SQL server. Obviously, that's not going to work, but you don't want to oversize it like

00:02:56.720 --> 00:03:02.080
you might a physical box. We can always add RAM later. We can always add some, you know, virtual

00:03:02.080 --> 00:03:08.479
CPU cores to it later when they're needed. Maybe for the first six months, we're just going to be,

00:03:09.119 --> 00:03:14.160
you know, building this application out and adding some, you know, resources to it, adding more data

00:03:14.160 --> 00:03:20.399
to the database. And as it grows in six months, then in a year, all of a sudden, we need more

00:03:20.399 --> 00:03:25.839
disk space. We need more CPU. We need more RAM, whatever the case may be. We can add those later.

00:03:25.839 --> 00:03:29.600
And again, those resources are going to be cheaper later than they are now. So, if we need to buy

00:03:29.600 --> 00:03:36.240
more later, that RAM is probably less expensive than it was a year or two years ago, right?

00:03:36.240 --> 00:03:40.639
So, what type of resources are we going to manage? Basically, everything that's related to a virtual

00:03:40.639 --> 00:03:49.360
machine, the networking, storage, power, memory, CPU can all be managed. Network utilization,

00:03:49.360 --> 00:03:54.559
we have storage, I'm sorry, network IO control. We have traffic shaping where we can, you know,

00:03:54.559 --> 00:04:00.320
throttle how much bandwidth VMs use. We can prioritize certain VMs that have higher priority,

00:04:00.320 --> 00:04:05.119
lower priority through network IO control, things like that. Storage, we have storage

00:04:05.119 --> 00:04:10.960
IO control. We can also say that certain VMs have to live on less expensive storage to allow

00:04:10.960 --> 00:04:15.679
the more expensive storage that we have less of to be available to the VMs that, you know,

00:04:15.679 --> 00:04:19.200
need it more, that are more important to us where performance is a higher priority,

00:04:20.160 --> 00:04:25.679
you know, things like that. Power, we can actually configure power management. So, we can say

00:04:26.640 --> 00:04:32.959
during slow times when the VMs are currently being used, maybe we only run our shop 8 to 5

00:04:32.959 --> 00:04:39.040
Monday through Friday. We're not a 24-7 shop. So, we don't want to run all, you know, 15 hosts

00:04:39.679 --> 00:04:47.519
24-7, 365. So, maybe we say at night, we want to move all the VMs down to seven of our 15 hosts,

00:04:47.519 --> 00:04:52.959
and we're going to power down, suspend, hibernate the other ones that we're not using. Then,

00:04:53.279 --> 00:04:58.079
as we need them, we can kick them back up again. We can use, you know, things like ILOs and stuff

00:04:58.079 --> 00:05:03.519
for vCenter to be able to go in and bring those hosts back out and start moving VMs back as we

00:05:03.519 --> 00:05:06.959
need it. Or maybe we, you know, don't need them on the weekends, and so we do the same kind of

00:05:06.959 --> 00:05:11.279
thing over a weekend or something like that. We can schedule a system and say, when you see

00:05:11.279 --> 00:05:17.359
resource utilization is very low, use fewer hosts and, you know, power down the hosts that we don't

00:05:17.359 --> 00:05:22.320
need, and we'll be able to bring them back online. So, we have power management. Memory. So,

00:05:23.600 --> 00:05:29.279
we can actually over-allocate memory on our hosts, and we can use some things like page files,

00:05:29.279 --> 00:05:33.839
paging. Those things are not going to be very efficient. They're not going to be very fast.

00:05:33.839 --> 00:05:39.760
They're going to be slower. They're available if we need them. Another option, though, and this is

00:05:39.760 --> 00:05:44.320
something that used to be turned on by default, and now it's turned off by default because it

00:05:44.320 --> 00:05:48.559
was considered to be or is considered to be a security vulnerability, and that's transparent

00:05:48.559 --> 00:05:53.920
parent page sharing. So, let's say in our environment we have, you know, 30 VMs running

00:05:53.920 --> 00:05:59.440
on this one host, and we do a great job of standardizing. So, all of our VMs are running

00:05:59.440 --> 00:06:05.760
the same version of Windows. They're all running, you know, 2019, and they all are patched to the

00:06:05.760 --> 00:06:11.760
same patch level. That means a big chunk of that operating system on all those VMs are identical,

00:06:11.760 --> 00:06:16.559
and so the pages and RAM are identical. So, I don't have to write all those pages and memory

00:06:16.559 --> 00:06:23.200
for all those VMs, you know, say 19 VMs, 19 times. I can write it once, and when another VM starts,

00:06:23.200 --> 00:06:26.799
oh, same page and RAM, I'm going to map you to that same page, and another one, I'm going to

00:06:26.799 --> 00:06:32.000
map you to that same page. So, now I've only used, for 19 VMs, I've only used that page and RAM

00:06:32.000 --> 00:06:38.559
once, not 19 times. Now, it was considered to be a security vulnerability because it was proven

00:06:38.559 --> 00:06:46.160
through a, you know, a university that theoretically that RAM can be compromised by

00:06:46.160 --> 00:06:52.239
another VM. It could be read, but it was actually something that never was found. It actually

00:06:52.239 --> 00:06:58.000
happened out in the wild, and in order for it to happen, they had to have physical access to that

00:06:58.000 --> 00:07:04.239
server, and my thought is if they have physical access to your servers, they already own you.

00:07:04.239 --> 00:07:09.279
They own your servers. Transparent page sharing is the very, very least of your concern,

00:07:09.279 --> 00:07:15.839
and the benefit definitely outweighs the risk. That's my perspective. Your company might have

00:07:16.399 --> 00:07:22.239
a policy that says we do use it, we don't use it, maybe they don't have a policy on it,

00:07:22.239 --> 00:07:27.040
it's up to you to make that policy. I'm very comfortable using transparent page sharing. So,

00:07:27.040 --> 00:07:32.480
that is another tool that can be used to help, you know, control how much memory is being used

00:07:32.480 --> 00:07:37.920
and allow me to over-allocate my memory, right, to allocate more RAM that I physically have in my

00:07:37.920 --> 00:07:44.640
house. And then CPU. For things like the CPU for memory, those are the first ones that were

00:07:44.640 --> 00:07:51.040
available. There's now other resources as well, like storage. We have what are called shares,

00:07:51.760 --> 00:07:58.799
and we have reservations, and we have limits. So, reservations mean if I have a VM and I

00:07:58.799 --> 00:08:04.799
configure the VM for a gig of RAM, and I create a reservation for that VM for half of a gig of RAM,

00:08:04.799 --> 00:08:10.399
that means that VM is guaranteed, it's reserved a half a gig of RAM. Now, it can maybe have the

00:08:10.399 --> 00:08:15.200
whole gig, right? If I have that whole gig available, then the VM gets the whole gig.

00:08:15.200 --> 00:08:21.920
But if I've over-allocated my memory, that VM's going to be guaranteed that, that half a gig. And

00:08:21.920 --> 00:08:26.399
as I start up another one, another one, another one, another one, and they start having their

00:08:26.399 --> 00:08:32.239
reservations met, what might end up happening is I've over-allocated my RAM so much with so many

00:08:32.239 --> 00:08:42.000
VMs with so much RAM that when I go to start up my 30th, my 50th one, the VMs all have half their

00:08:42.000 --> 00:08:47.760
gig reserved, if that was my configuration. The other half has to be paged or something like that

00:08:47.760 --> 00:08:53.440
because I don't have room in RAM to meet that need. So, they get their reservation, but they're

00:08:53.440 --> 00:08:59.200
guaranteed if I configured that. The rest has to be paged out or something like that. Then I go

00:08:59.200 --> 00:09:05.520
start another VM and it has a half a gig reservation. If I don't have a half a gig to give it, I can't

00:09:05.520 --> 00:09:10.559
start it. When I go to start it, I'll get a message telling me that my reservation can't be met. And

00:09:10.559 --> 00:09:16.880
because my reservation cannot be met, I cannot start that VM. So, reservations are guaranteed

00:09:16.880 --> 00:09:23.520
resources. Limits are the opposite. Maybe I configured my VM for a gig of RAM, but I put a

00:09:23.520 --> 00:09:30.000
limit on the VM of half a gig, which means it can use up to a half a gig of physical RAM. It's not

00:09:30.000 --> 00:09:37.919
guaranteed it, but if it's available, it can use it. And even if more than a half a gig is available,

00:09:37.919 --> 00:09:43.760
I want to go and use, you know, a half a gig plus one meg of RAM. And it's available and it's free,

00:09:43.760 --> 00:09:48.000
but if I have a limit on there of half a gig, it can't use it. The VM thinks it's there. The VM

00:09:48.000 --> 00:09:53.760
can say write that additional one meg, but the host will say that has to be paged. We're going

00:09:53.760 --> 00:09:57.840
to page that out. I'm not going to let you write it to actual memory because you have a limit on

00:09:57.840 --> 00:10:02.000
how much memory you can use. We can do the same thing for both of those things for CPU. We can

00:10:02.000 --> 00:10:09.520
have a reservation for CPU for so many megahertz and we can have a limit. And so, you can't use

00:10:09.520 --> 00:10:14.479
more than so many megahertz. And again, the VM might think it has more available, but it hits

00:10:14.479 --> 00:10:18.960
that limit and there's an opening that starts getting this throttle down. And what will start

00:10:18.960 --> 00:10:25.119
happening is you'll see it's latency going up and up and up on that VM. It'll start getting really

00:10:25.119 --> 00:10:32.400
slow. But reservation means I'm guaranteed a certain amount of CPU. I'm guaranteed, you know,

00:10:32.400 --> 00:10:40.239
1,000 megahertz. Even though this core is 3,000 and the VM can see that 3,000, I'm guaranteed

00:10:40.799 --> 00:10:46.080
that 1,000. So, if other VMs are trying to use it, that right there is mine. And even if I'm not

00:10:46.080 --> 00:10:52.640
using it, I'm not using that CPU time. I'm not using that 1,000 megahertz on that CPU. It's

00:10:52.640 --> 00:10:59.200
reserved. It's mine. Okay? The way to get around things like shares and limits where even if I'm

00:10:59.200 --> 00:11:04.559
not using it, it's mine or if it's available, I still can't use it are what they call shares.

00:11:05.200 --> 00:11:12.640
Shares will allow for me to configure a VM and I power it on and it says, oh, yep,

00:11:12.640 --> 00:11:18.559
all the CPU is there. This much RAM is there. Go ahead and use it. And if it's available and

00:11:18.559 --> 00:11:24.080
there's no contention for it, and that's the magic word, there's contention. If there's no contention,

00:11:24.080 --> 00:11:28.960
I can use all that I'm configured for. If I'm not using it, someone else can use it because

00:11:28.960 --> 00:11:37.119
it's not reserved for me. And if I want to use it, it's available. But if there's contention,

00:11:38.320 --> 00:11:45.280
meaning that, again, I've over allocated, for example, my CPU. I have more VMs running,

00:11:46.000 --> 00:11:52.159
consuming processor than I have processors. There's more megahertz being eaten by these VMs

00:11:52.159 --> 00:11:57.760
than I have megahertz on this processor. Now we have contention. We have VMs fighting for

00:11:57.760 --> 00:12:05.359
access to that resource. How do I decide? How does the kernel decide who gets access to what?

00:12:05.359 --> 00:12:11.520
I can allocate shares. And when contention comes into play, then shares come into play.

00:12:11.520 --> 00:12:16.080
Unlike reservations, that's mine no matter what, if I'm using it or not, or limits, I can't use it

00:12:16.080 --> 00:12:20.799
even if it's there. With shares, it only comes into effect when there's contention, when there's

00:12:20.799 --> 00:12:28.880
fighting for a resource, and they'll say, okay, this VM has 500 shares, and this VM has 500 shares,

00:12:28.880 --> 00:12:34.159
and this VM has 500 shares. All these VMs have 500 shares. So they get equal access to the

00:12:34.159 --> 00:12:38.719
resource. They want more than there's available, but they're going to get an equal amount of it.

00:12:39.520 --> 00:12:42.960
Then all of a sudden, I go to one of the VMs. I say, okay, I'm going to bump up your

00:12:42.960 --> 00:12:49.359
500 shares to 1,000 shares. So now you've got 1,000 shares, and this VM has 500,

00:12:49.359 --> 00:12:57.039
and this VM has 500. So in total, in the pool, there's 2,000 shares. This VM

00:12:57.039 --> 00:13:01.280
has half of them. This one has a quarter. The third one has a quarter. That means that the

00:13:01.280 --> 00:13:06.960
VM with 1,000 shares gets half the resource because it owns half the shares. The other two

00:13:06.960 --> 00:13:12.320
own a quarter each, so they get a quarter of the resource. So your shares say what

00:13:12.320 --> 00:13:19.200
amount of the resource you get access to when there's contention. But if there's no contention,

00:13:19.280 --> 00:13:25.520
shares don't come into play, and you get all that you want, all the CPU you're configured for,

00:13:25.520 --> 00:13:30.080
all the RAM you're configured for, if you want it. It's available to you. Until there's contention,

00:13:30.080 --> 00:13:36.000
then shares kick in. So we can manage resources in our ESXi host, as you can kind of figure out

00:13:36.000 --> 00:13:41.599
here, a lot of different ways. We have storage IO control, network IO control. We have shares. We

00:13:41.599 --> 00:13:46.559
have limits. We have reservations. There's a lot of ways of controlling access to these resources.

00:13:46.559 --> 00:13:51.599
So where do I assign these kinds of allocations resources, right?

00:13:54.559 --> 00:14:00.960
So what can provide a resource? A host can. A host can provide CPU. A host can provide

00:14:00.960 --> 00:14:08.960
memory and storage and network, and it can be power managed, right? We also can assign a resource

00:14:08.960 --> 00:14:16.479
or get resources from a cluster or pool or resource pool. A cluster is basically a top-level

00:14:16.479 --> 00:14:20.559
resource pool. When we want to go and create resource pools in vCenter, we have our cluster,

00:14:20.559 --> 00:14:23.840
and then we're going to go into our cluster and we're going to start creating resource pools,

00:14:23.840 --> 00:14:28.799
and we can choose to put VMs in resource pools. And resource pools, rather than going to the VM

00:14:28.799 --> 00:14:35.039
and saying you have 1,000 shares and you have 500 and you have 500, I said the resource pool

00:14:35.039 --> 00:14:40.719
has 1,000 shares. And this resource pool has 500, and this resource pool has 500.

00:14:40.719 --> 00:14:46.640
So where are they getting that resource from? The pool, the resource pools get their resources from

00:14:47.520 --> 00:14:54.719
the cluster, right? So the cluster is basically the top-level resource pool that then gets divided

00:14:54.719 --> 00:15:01.440
up amongst the resource pools that are below it. So if a resource pool has 1,000 shares,

00:15:01.440 --> 00:15:07.599
and then you have 500 and 500, all the VMs in that resource pool get half of the resources

00:15:07.599 --> 00:15:13.119
in the cluster. And then the other ones get a quarter and a quarter. It doesn't matter how

00:15:13.119 --> 00:15:20.159
many VMs are in that resource pool. The resource pool that 1,000 shares maybe has two VMs. Those

00:15:20.159 --> 00:15:27.760
two VMs get half of the resources in that cluster. Then the other resource pool that has 500 maybe

00:15:27.760 --> 00:15:36.799
has 10. Those 10 share the quarter that their shares give them access to when there's contention.

00:15:36.799 --> 00:15:42.559
No contention, shares don't come into play. But when there's contention, then the two VMs that

00:15:42.559 --> 00:15:48.400
are in the pool of 1,000 shares, they get half the resources. And the other ones get the share,

00:15:48.400 --> 00:15:51.520
the quarter and a quarter. No matter how many VMs are in there, that's all they get that quarter.

00:15:52.479 --> 00:15:58.719
Within the resource pool, so I have this resource pool with 500 shares and it has 10 VMs,

00:15:59.440 --> 00:16:05.919
how is the resources amongst them shared? It depends on how many shares they have. If they

00:16:05.919 --> 00:16:10.479
all have the same number of shares, they equally share their quarter of the resource. If one has

00:16:10.479 --> 00:16:17.039
more shares, it gets, you know, based upon whatever ratio of the shares it has, that much of the

00:16:17.039 --> 00:16:21.599
resource, just like we explained. So the VMs get shares within the resource pool. The resource

00:16:21.599 --> 00:16:27.359
pool gets allocation to the resource of the cluster. So it's a pretty cool concept. It works

00:16:27.359 --> 00:16:33.760
kind of well. It's easy though, as you might be able to see. I'm like, well, these VMs are really

00:16:33.760 --> 00:16:39.440
important. I'm going to give their resource pool 1,000 shares, not thinking there's only two VMs

00:16:39.440 --> 00:16:45.520
in there. They can't even use half of the resources in there. The other two resource pools only get a

00:16:45.520 --> 00:16:49.679
quarter and a quarter because they only have 500 shares, but there's way more VMs in there.

00:16:49.679 --> 00:16:55.599
So resource pools are great. I'm not trying to discourage anyone from using them, but make sure

00:16:55.599 --> 00:17:00.080
you really think it out. It's not going to be something you're going to do on the fly on a whim

00:17:00.080 --> 00:17:04.400
because what you'll find is if you don't think it out thoroughly, you're going to start choking

00:17:04.400 --> 00:17:09.599
your VMs. You have some VMs performing horribly, other ones performing great because it wasn't

00:17:09.599 --> 00:17:19.439
planned well. Resource pools are great to use. Shares, reservations are cool. Just make sure

00:17:20.000 --> 00:17:25.040
that you think out the shares in relationship to the resource pools, in relationship to the number

00:17:25.040 --> 00:17:32.880
of VMs, the size of the VMs, things like that. So what can provide the resource hosts? Clusters

00:17:32.880 --> 00:17:39.680
and resource pools, and data stores provide storage, obviously. So what uses the resources

00:17:39.680 --> 00:17:45.839
from the host, the cluster, the resource pools, or the data store? Virtual machines and virtual

00:17:45.839 --> 00:17:51.599
applications do, obviously, as we kind of just explained. So these are going to be the consumers

00:17:51.599 --> 00:17:56.160
of the resources that will be available that are provided by our clusters, our hosts, our resource

00:17:56.160 --> 00:18:04.479
pools. So we can use all of these to help us plan the allocation of the resources to our virtual

00:18:04.479 --> 00:18:12.079
machines, to our applications. So we can have some kind of predictability that when there is

00:18:12.079 --> 00:18:17.359
contention, when this thing kind of gets bigger and we're really busy, which virtual machines are

00:18:17.359 --> 00:18:21.199
going to be prioritized? Which ones are going to get more resource because they're a higher priority

00:18:21.199 --> 00:18:26.640
virtual machine? Which ones get fewer resources because they're less of a priority? They're less

00:18:26.640 --> 00:18:32.319
often used and the work they do isn't as important. But these other applications, they be the main line

00:18:32.319 --> 00:18:37.920
of business. They are what drive sales. They are what drive production, things like that. We need

00:18:37.920 --> 00:18:43.520
to prioritize those so we can allocate resources to them to make sure that happens. So it makes

00:18:43.520 --> 00:18:49.040
our workloads more predictable during heavy utilization times. When things are fine, when

00:18:49.040 --> 00:18:53.199
there's not a lot of heavy utilization, there's lots of resources, we don't have to worry about it.

00:18:53.199 --> 00:19:00.079
We're using these to ensure a certain level of performance so we can deliver on our SLAs to our

00:19:00.079 --> 00:19:06.640
end users during heavy usage times, during times of contention for the resources.

00:19:09.680 --> 00:19:14.800
So the goal here is efficiency, right? We want to make sure that resources get used as

00:19:15.520 --> 00:19:21.119
smartly as possible, right? Balance of the VMs that need the resource get the resource and the

00:19:21.119 --> 00:19:26.880
VMs that aren't as important don't get as much. But if I have 10 VMs that are very important and

00:19:26.880 --> 00:19:30.800
they all need to have a good level of performance, that the resources are being balanced among them.

00:19:30.800 --> 00:19:36.079
I don't want one VM just to like get this, what they call a noisy neighbor, just consuming a lot

00:19:36.079 --> 00:19:40.880
more resources than the other ones that are equally important for making sure our business

00:19:40.880 --> 00:19:46.640
is successful. So I can use things like shares to ensure that balance, right? And ensuring the

00:19:46.640 --> 00:19:52.400
VM can operate. What that means is maybe I have a bunch of big VMs and they're consuming a lot

00:19:52.400 --> 00:19:58.319
of resources and I have one or two small VMs. I don't want them completely written off. I don't

00:19:58.319 --> 00:20:02.880
want them out there choking and starving and not getting any resource because the big VMs are

00:20:02.880 --> 00:20:09.839
sucking all of it up. So even small ones with maybe a small number of shares will get still a small

00:20:09.839 --> 00:20:16.800
amount of resource, enough that they can operate efficiently enough for their level of importance

00:20:16.800 --> 00:20:25.520
in our operations. All right. So we discussed resource allocation and resource management.

00:20:25.520 --> 00:20:30.239
We discussed CPU, memory, disk, storage, and power.