A couple of days ago I posted some information on how the vCloud Allocation Pool Model manages resources with Elastic vDC is not enabled. This is the follow-up post to run through the same scenario except enabling the Elastic vDC Option. When you do this some things change. I will try to use the same basic example setup so we can see the differences between the two scenarios. This elastic feature came out with vCloud Director 5.1.2 so as long as you are running that version or higher you can enable it.
Let’s start again with what the service provider might tell you they are giving you.
What You Get
As before we will use the following numbers:
- 5Ghz burstable up to 10Ghz
- 20GB vRam
- “X” Amount of storage
- “X” Amount of bandwidth
- “X” number of public IP’s
One big thing that changes with Elastic vDC is that there is a vCPU Speed setting when you enable the option under “General” within vDC Show below.
Now, I will explain how this affects your resources above, but it’s not something more service providers will tell you the setting on. For the purposes of my example I will be using a 260Mhz vCPU Speed as we go forward. I will explain where and how it is used and why the setting itself is important. In most cases providers will have determined a fair value for this that allows you to use all the resources you have access to. This setting tends to be a bit confusing to people and we will look at it next.
The other advantage I will mention about elastic vDC is it allows providers to span your Virtual Data Center across clusters. Although you still have the same pool of resources, you could have machines running on different clusters that the provider has scaled out to. This is a good thing for everyone involved.
Example vCloud Allocation Pool Settings
What is different when that simple check box above is enabled like before there are settings applies at the vSphere resource pool level, however unlike before we will see that there is no settings applied to the individual virtual machines. Much of the resource controls are handled by vCloud Director itself, but as we will see there are still some things going on in vSphere.
What The vRAM Resources of 20GB Means
- 20GB Memory Allocation in vCloud Director
- 100% Memory Resources Guaranteed in vCloud Director
This setting is identical to what is done without Elastic vDC enabled from a vCloud perspective. Where we see the difference is in the vSphere resource pool. Recall from the previous article the resource pool itself was set to a 20GB reservation and also a 20GB limit. Below you can see that with elastic vDC enabled the resource pool is different. The memory is set to expandable and there is no limit.
What changes is as we power on some virtual machines in this virtual datacenter, in this case two 8GB Linux machines, we now see that the memory reservations are increased since they are still 100% guarantee set. This will simply continue to go up until you consume all 20GB of memory in any combination of virtual machines. You can see here that the resource pool has now been set to a 16GB reservation, leaving only 4GB left to allocate.
It is also worth noting for those vCloud folks that if you are spanning clusters and a machine is deployed on the other cluster a matching resource pool will be create. However, vCloud Director will control how much that pool can be allocated based on what machines are already deployed and running. Just because it’s on a new cluster with more available resources in our example here the consumer only has 4GB left. That means even if the next machine went on a new cluster it still can only be allocated at 4GB.
What The vCPU Resources of 5Ghz with 10Ghz Burstable Means
- 10Ghz CPU Allocation in vCloud Director
- 50% CPU Resources guaranteed in vCloud Director
- .26Ghz vCPU Speed (Set be the provider, .26 for this example only)
We can see unlike the first post there is now the vCPU Speed option. Just like before the total allocation is 10GHz with a 50% Guarantee , but let’s take a look at the base vSphere resource pool without any machines powered on. We can see that unlike the memory there is a limit of the 10GHz, but there is no reservation set. Also it’s not made to be expandable since the 10GHz is your total available.
Now, once we power on those same two virtual machines, which each only have a single vCPU we will see something change. We notice that there is now a 260Mhz reservation. So where does that come from? Well recall the CPU guarantee is 50% and the vCPU Speed is set to 260Mhz. Therefore there is two vCPU’s, one per machine, each allocated a 130Mhz reservation.
The main point I want to make here is that the vCPU Speed is not the “actual speed” of your vCPU. It’s just used to calculate the reservations allocated in vSphere. Your machines with two or 4 vCPU’s can still run up to the 10Ghz amount. Of course each vCPU will only be as many GHz as the physical processors themselves, but hopefully you get the point. In my lab my physical CPU’s are 2.66GHz for example. If a provider were to set this vCPU Speed to high, you might end up hitting your 5GHz reservation sooner than your memory. Frankly it’s for the provider to decide what numbers work best, but in this example with 100% memory you can see you will hit that much sooner most likely.
The Individual Virtual Machine Settings
Unlike the previous example without Elastic enabled, there is no real per virtual machine settings done. All the control is placed in the resource pool instead making it, in some cases, much easier to manage and understand. You will not have to deal with both a resource pool and individual machine settings working together. This is one reason why many providers like the allocation pool model with elastic vDC. That and the fact they can scale to other clusters. Below is the individual machine settings on CPU.
Below is the individual machine settings on Memory.
We can see that the machines themselves have nothing specific configured just to show it visually for people who are like me and need to see it.
Why Is This Version Important?
Well for vCloud Architects this will determine a lot about how your consumers can deploy machines and it’s one of those single check box decisions. However, that single check box as you can see changes the behavior quite a bit from the first example. Even I was not fully aware of the difference until I got it all configured in my lab. As a consumer, a service provider that enables this actually makes it better for you in my personal opinion. People do seem to get freaked out about the vCPU speed, but all it’s doing is setting a CPU reservation that will grow on the pool in this case up to a 5GHz reservation, (50% of 10GHz). You can still run a CPU intensive application and consume more than that so don’t get too upset about the number, it should not mean that much to you.
I will show this same comparison for a Reservation Pool model next, which may be attractive to some people who want to control the individual machine settings themselves. Personally I like this model but I like to have more control myself, but let’s see what you all think. If you have a chance to play with this in your own lab with and without Elastic vDC enabled, it’s quite interesting to look at.
I will point out one final advantage to this model is that any overhead required for the virtual machines, which is always there, will be handled by the parent pool unlike when this option is not enabled. Again, there are plenty of other resources for people to learn about overhead, but just know this also gives the advantage for a consumer to use their full allocation without worrying about the overhead reservation.
Please leave comments and questions below.
The post vCloud Resource Management – Allocation Pool WITH Elastic vDC appeared first on Chris Colotti's Blog.