WEBVTT

00:00:00.440 --> 00:00:05.150
Let's consider some important details when it comes to compute services.

00:00:05.510 --> 00:00:07.640
From the provider's perspective,

00:00:07.790 --> 00:00:12.220
there are three main capabilities that come under management.

00:00:12.230 --> 00:00:17.260
Reservations for a compute is representing the minimum guaranteed that

00:00:17.270 --> 00:00:23.300
a provider gives to a consumer. Limits are the maximum amount of

00:00:23.300 --> 00:00:28.050
compute available, and then shares are only applied if there is a

00:00:28.050 --> 00:00:32.530
contention for resources that occurs. There are two elements of

00:00:32.530 --> 00:00:34.140
compute that we will consider.

00:00:34.270 --> 00:00:40.660
The first one is actually the amount of virtual CPUs that would be consumed.

00:00:40.840 --> 00:00:44.600
On the other side of it is the amount of memory that the consumer would

00:00:44.600 --> 00:00:48.490
have, along with their virtual compute resources.

00:00:48.530 --> 00:00:53.850
Let's look at it from a practical implementation perspective. Let's say that

00:00:53.860 --> 00:01:00.300
the service provider provides a minimum guaranteed of 32 GHz for every

00:01:00.310 --> 00:01:05.120
launched virtual machine. Then, they have a limit that says that from a

00:01:05.120 --> 00:01:08.790
compute perspective, you would max out at 40 GHz.

00:01:08.960 --> 00:01:13.370
The shares would kick in only if there is some kind

00:01:13.370 --> 00:01:15.800
of contention for those resources.

00:01:15.940 --> 00:01:22.330
So, let's say that we have a combined total of 128 GHz available in the

00:01:22.330 --> 00:01:26.400
compute resource pool of the cloud service provider. They install the

00:01:26.400 --> 00:01:31.360
hypervisor and pool those resources together, and then, the tenants are

00:01:31.360 --> 00:01:37.620
allowed to launch VMs. So Tenant 1 launches their 32 GHz VM, Tenant 2,

00:01:37.620 --> 00:01:43.650
their 32 GHz VM, and so does Tenant 3. Everything's working fine. There's

00:01:43.660 --> 00:01:50.160
32 GHz left over for processing. But what if something went wrong? What if

00:01:50.160 --> 00:01:56.490
there was an errant process that was occurring? Let's say that the

00:01:56.490 --> 00:02:02.580
situation was that you didn't have 128 GHz, but you actually only had 96

00:02:02.580 --> 00:02:03.320
GHz.

00:02:03.710 --> 00:02:06.560
This is where shares would come into play.

00:02:06.940 --> 00:02:11.200
Now, you're actually maxing out and the amount of

00:02:11.200 --> 00:02:14.120
processing that is available can put the cloud service

00:02:14.120 --> 00:02:16.690
provider in an oversubscription situation.

00:02:16.700 --> 00:02:19.000
The preallocation of shares,

00:02:19.010 --> 00:02:25.790
let's say VM1 gets one share, VM2, four shares, and VM3, eight

00:02:25.790 --> 00:02:30.070
shares, means that VM1 only gets one part of the whole,

00:02:30.080 --> 00:02:33.460
whereas VM3 gets eight parts of the whole that's left

00:02:33.470 --> 00:02:35.460
over from a contention standpoint.

00:02:35.470 --> 00:02:38.220
This could be something that would be applicable,

00:02:38.230 --> 00:02:42.000
connected to an SLA based off of availability,

00:02:42.010 --> 00:02:45.260
a confirmation of services that you can have allocated to

00:02:45.260 --> 00:02:48.640
you in case of some type of resource contention inside of

00:02:48.640 --> 00:02:50.340
the cloud management plane.

00:02:50.650 --> 00:02:53.600
What is visible though to the tenant?

00:02:53.610 --> 00:02:54.050
Well,

00:02:54.540 --> 00:03:00.960
here's an example of if we are in AWS and we were deciding to launch a new

00:03:00.970 --> 00:03:05.820
virtual machine. The management console will actually give the tenant the

00:03:05.820 --> 00:03:12.820
visibility to know what the size is of the virtual CPUs and how much memory

00:03:12.820 --> 00:03:14.760
will be allocated along with it.

00:03:14.840 --> 00:03:19.620
Next, we're going to take a look at storage services and how that

00:03:19.630 --> 00:03:22.550
appears to both the tenant and the cloud provider.