vCHS Monitoring and Capacity Management 101 – the Theory

This is blog one of a series of two. In these blog posts I will be introducing (at 101 level) how resource monitoring and capacity management work in vCHS.

Before we get into the meat, it is important to understand how capacity is delivered to tenants in vCHS.

Background

One of the many things that make vCHS unique in the public cloud landscape is that VMware sells (IaaS) capacity and not VMs. This isn't to diminish the value of a PAYGO VM-based approach (that VMware publicly stated is looking at introducing later) but there are a lot of customers that would like to buy capacity in the cloud a little bit differently than how it works in "the real cloud" (which is how the #clouderati crew would define PAYGO). For these customers predictability is of more value than flexibility and pay-per-use.

When you approach today vCHS for raw IaaS capacity, you have the option of subscribing to VPCs (Virtual Private Clouds) or DCs (Dedicated Clouds). This is possible because of the cloud of clouds approach VMware took in designing the service. More about this concept in this short video.

More practically, this is the architectural view of what you can subscribe to:

Discussing the nature of VPCs and Dedicated Clouds is beyond the scope of this post, but suffice to say that, ultimately, the virtual data center is the atomic unit of consumption of your subscription. It is inside the virtual data center that "things happen". This core concept is also described in this vCHS APIs 101 blog post.

When you subscribe to the VPC SKU VMware will provision a virtual data center on a shared vCloud Director based cloud.

When you subscribe to a DC SKU VMware will provision a brand new vCloud Director based cloud dedicated to you and you will be allowed to create your own virtual data centers (in self-service mode).

At the very high level a VPC and a vDC on a Dedicated Cloud are essentially the same thing: a virtual data center carved out from a vCloud Director instance. Regardless of their nature, all virtual data centers appear as badges in the vCHS portal:

Virtual data centers can also be consumed via APIs as I mentioned above.

While in general VPCs and vDCs appear to be one and the same, a VPC and a vDC on a Dedicated Cloud are two (very) different beasts when it comes to consumption monitoring and capacity management.

For those that understand vCloud Director, the former is created with the allocation model whereas the latter is created with the reservation model. If you are not familiar with the concepts, don't bother reading the post I linked in this paragraph. It won't help.

Many months ago I tried to document these differences in a vCHS technical paper. The idea was to simplify the technicalities and write a couple of pages that could be easy to consume for the masses. That document is still in draft at 16 pages. An obvious gigantic failure.

In this post I am taking a different approach to describe consumption and capacity management for these two offerings. Let's see if it works.

A virtual data center is like a bus (sort of)

The easiest way I found to dumb down the heavy technical details behind this discussion, is to describe a virtual data center as a bus.

If you subscribe to a VPC, VMware will give you a bus.

If you subscribe to a Dedicated Cloud, you can create your own bus (or buses)

These buses (VPCs and vDCs) look identical from the outside and you drive them fairly in the same way. However the interiors are completely different.

The VPC interiors

VMware will provide you with a fully furnished bus. 55 comfortable standard seats.

On the VPC bus no one is allowed to stand. Max 55 people. That's it.

However, if not all 55 show up, people can take two or more seats (like lying on the 5 seats in the back of the bus if you are lucky!)

Similarly, in a vCHS VPC there is only a limited number of VMs you can deploy. Each vCPU will take a CPU slot (or seat) and each GB of memory will take a memory slot (or seat). Discussing what these numbers are is outside the scope of this paper. What you need to remember is that there is a finite number  of vCPUs and a finite amount of memory you can configure and instantiate with your VMs.

The vDC interiors

When you create a vDC bus you have nothing inside. That's the beauty of it.

You can configure your interiors the way you want.

1. You can, as I usually say, overbook your bus "like hell" by not even installing seats and having all people stand (all over the places):

Screw the comfort. You only care about bringing as many people as possible from point A to point B. As long as they can (barely) breath, you are good.

2. Or you can create a luxury bus for a few selected people you want to carry around:

Screw volumes! Focus on value. You only want to have 3 VIPs on your bus. Comfortable chairs, champagne, massage. Way to go!

3. Or mix of the above two. You can have business class and coach sections in your bus. You can have 1 VIP sitting in the front with all comforts and then you can pack as many people as you can "in the back".

Similarly, in a vCHS vDC you are in control and you can determine whether you may want to reserve capacity for very important VMs (think SAP?) and / or you want to instantiate as many VMs as possible (think test and development environments).

How do you do monitoring and capacity planning (for a bus)?

When it comes to understand how many people you can put on a bus, there are a few things that you want to know. These are:

1- You want to know how big the bus is. That will determine, in the end, how many people you can get on it (regardless of whether you want to seat them in business class, in a small economy seat or standing). You can fit more people in a 10 meters long bus than you could in a 5 meters long bus.

2- In case you don't want anyone to stand, you want to know how many seats you have on a bus. That will, ultimately, determine how many people you can carry around. Obviously the assumption is that, while someone can take more than one seat if they are free, it is not possible for two or more people to use one single seat.

3- You want to know how the people on the bus are behaving. Regardless of whether they are seating or standing, the louder they are, the less comfortable the others will be. The behavior of individuals on a bus may also determine how many individuals you want carry around without the others to complain.

How does this relate to a vCHS virtual data center?

In a somewhat similar way. Since a vCHS virtual data center is, ultimately, a vSphere resource pool (i.e. a bus), we use reservations (i.e. seats) to assign capacity to VMs (i.e. people).

As alluded to, a virtual data center created on a Dedicated Cloud doesn't have any reservation policy pre-configured (i.e. it's an empty bus). By default all VMs you deploy will contend for all the resources in the pool. However, you have the option to set reservations on a per VM basis. As said above, you may want to do something like this for a, say, SAP VM, while you may want to pack as many test & dev VMs as possible with no reservations at all in the same resource pool.

On the other hand, a VPC (aka a virtual data center created on a shared cloud), does have reservation policies set from the get go. The difference here is that vCHS doesn't assign the reservation to the VMs but it rather assign the reservation to the pool (i.e. the virtual data center itself). As you add VMs to the VPC the reservation applied to the VPC increases of a certain amount. As the reservation (of either memory or CPU) reaches the value of the allocated capacity of the VPC, no other VMs will be allowed to be deployed (since there are no resources left in the VPC to be reserved).

Think about the VPC reservation as a "ticket to run" that the VM is given (i.e. a seat on the bus). When the VPC has no more tickets, no other VMs will be allowed to be powered on. When you get 55 people on the bus, no other people will be allowed to get on the bus.

Conclusions

This is the theory so far. This is a high level explanation of the principles behind those resource pools behavior. This isn't intended to be exhaustive but rather a 101 introduction.

I hope the parallel makes sense and is instrumental to have more people (without a deep vCloud Director know-how) to understand how vCHS virtual data centers behave from a capacity perspective.

In the follow up post we are going to see this in action from a practical perspective.

Massimo.