Many service providers have been deploying their services using vCloud Director of the past couple years. Of the various models I have seen the Allocation Pool used most often, but there is two ways it can be configured and each way changes the way your virtual machine resources are handled. With vCloud Director 5.1 you have the option of enabling Elastic vDC which allows you to span clusters of vSphere hosts. It’s very useful, however it manages the virtual machine’s resource differently than when it is not enabled.
Since I returned from the networking world to the vCloud world I decided to get back into the lab and see first hand how it works myself. Last year Frank Denneman and I co-authored a paper on the vCloud Allocation Models however it was based on vCloud 1.5 and the Allocation Pool now has this new option. I will break this topic up into a few posts. One covering the Allocation Pool offering without Elastic vDC enabled, another with it enabled, and finally the Reservation Pool and some of the advantages it has. Why do I feel this important? The more you know about how vCloud Director and vSphere is managing the resources the better you will be able to design your use of the service and maximize the number of workloads you want to run. vSphere resource management itself has not changed much, but these changes to the vCloud Allocation models has allowed varying levels of control. Knowing how it works may be important to some folks who want to understand and maximize just how many virtual machines they can run in any given provider offering using the Allocation Pool model.
What You Get
Many providers list simply the following specifications around their offerings and in various sizes:
- 5Ghz burstable up to 10Ghz
- 20GB vRam
- “X” Amount of storage
- “X” Amount of bandwidth
- “X” number of public IP’s
What I am going to do is attempt to break down only the compute and memory component of this example without Elastic vDC enabled and then again with it enabled. I feel people can better understand how your virtual machines will be deployed in this offering leading to better consumption of the offering. For the vCloud Director savvy this may seem like review, but for the new people to this it’s about education. You may not know if your provider has elastic enabled or not, so understanding both examples may empower you to just ask them.
Example vCloud Allocation Pool Settings
In order to understand further we need to break down the numbers above to what is configured in vCloud Director and thus what is translated to vSphere itself. This is because vSphere is actually what is doing the resource management in most cases. vCloud Director is just giving the setting inputs. Below is a basic translation, and we have to remember with this model some settings are applied both to a resource pool and the virtual machines. We will cover that later on, but remember this example is WITHOUT elastic vDC enabled.
What The vRAM Resources of 20GB Means
- 20GB Memory Allocation in vCloud Director
- 100% Memory Resources Guaranteed in vCloud Director
This in turn translates to vSphere as a resource pool with a 20GB limit, and a 20GB Reservation.
What The vCPU Resources of 5Ghz with 10Ghz Burstable Means
- 10Ghz CPU Allocation in vCloud Director
- 50% CPU Resources guaranteed in vCloud Director
This in turn translates to vSphere as a resource pool with a 10Ghz limit, and a 5GHz Reservation.
Understanding the Resource Pool Created
As you can see so far what gets created with these settings is a single vSphere Resource Pool with a full 20GB of memory reserved for you, along with a limit, or cap, as well. The initial 5GHz of CPU is reserved and there is a 10GHz limit you can “burst” into, but not over. Simply put is that all your memory is reserved, and half your CPU is also reserved but you can leverage additional CPU resources of the cluster pool with other tenants. In both cases you can not go over the limts that have been set. So how do these affect virtual machine deployments? Let’s examine the settings of a virtual machine deployed to this model and settings.
The Individual Virtual Machine Settings
The example virtual machine deployed will be your basic 2 vCPU by 2GB variety as that’s pretty common for most people. The thing we need to completely understand from the previous settings is that in the Allocation Pool Model, the percent reservation listed for memory not only applies to the vSphere resource pool, it ALSO applies to the virtual machines deployed.
Once a virtual machine is deployed looking at the vSphere side of things we can see that the following CPU settings are applied.
What is tells us is nothing really impactful. The individual virtual machine has no specific machine level CPU reservation or limit. Therefore it can leverage what is available in the overall pool of 5GHz and the “burst” space. The memory settings are a little bit different.
Here we can see that a 2GB reservation has been applied to the virtual machine. If you recall the vCloud Allocation Pool is set to 100% memory reservation and this Virtual Machine was configured for 2GB. If we shut it down and changed the memory we’d also see this reservation change to match the new settings. It’s also something to point out that without elastic vDC enabled there is nothing specific set for the CPU other that the resource pool level having the initial 5GHz reserved. Each virtual machine will use that reserved and can go up to the full 10GHz.
Why Is This Important?
Well I am not going to go into the full depth on this as Frank and Duncan have done that plenty over the years. The good news is the fundamental usage of these settings has not changed. What I will also not get into is the topic of overhead reservations or HA admission Control at this point. If you want to know more about that you can read Frank and Duncan’s books on the topic or the vSphere Resource Management Guide. However, it is useful to learn about these topics at some point.
The purpose here is to let you see how much you can carve up a Virtual Private Cloud based on your virtual machine configuration with very “rough” calculations. What we know about Resource Pools and Per Virtual Machine reservations when they are combined is that the individual machine reservation of 2GB is removed from the overall pool of 20GB leaving 18GB left for more virtual machines. You can see as we add more machines, the 20GB pool will have those machines reservations removed from it as well until there is no more water left in the pool.
Simply put as you can roughly determine in a single Allocation Pool instance out of the box you can get any number of virtual machines based on the sizing of the machine themselves. The basic math for a ballpark as you can see is certainly not rocket science.
- 2GB Machines is less than or equal to 10
- 1GB Machines is less than or equal to 20
If you mixed and matched you’d be somewhere in between of course, and you can add-on more resources as you need to scale to more machines. I should say this is not meant to be a sizing guide, this is for education purposes only so you can see what you can run in your VPC. Stay tuned for the Dedicated Cloud breakdown which is actually pretty interesting.
If you have never really played with reservations and limits I have been saying for over a year as a vCloud Director advocate and architect, you should start understanding them if you want to understand the “why” of how things work. I realize many vSphere customers have not deployed reservations on resource pools or even adjusted the per virtual machine settings in-house. However, since vCloud Director does it for you it’s maybe worth knowing a little more so you can design applications to maximize the various options.
Much of this changes when you simply enable Elastic vDC so I will cover that in the next post. Please leave comments and questions below so the conversation can be useful to others.