Allocation Pool–Behind the scenes
In the last post I discussed Pay-as-you-go model. Let’s discuss the next widely used model in vCloud director. Allocation Pool model is generally used for Production workloads. In this model you have ability not only to allocated resource but also guarantee some percentage of resources. Below is the example of customer requirement where he wants 50% resources to be guaranteed and leaving a room for a burst of 50% in case of unexpected peaks.
Figure:01 – Allocation Pool model
Above requirement can be translated into allocation pool model as shown below. Use CPU allocation and Memory allocation to define how much CPU and Memory you wish to allocate to this vDC. Below screen it is 4 GHZ and 2 GB RAM. These are hard limits, you can’t provision anything beyond this. It is worth noting here, vCenter Chargeback manager uses 4 GHZ and 2 GB RAM and will charge based on it.
Figure:02 – Allocation Pool Resource allocation model
Below screen is example where in none of the VM’s are powered ON. So reservation is set to zero. However limit on resource pool for CPU is set.
Figure:03 Resource Pool settings before powering ON VM
It is worth noting there is NO limit set on memory resource in spite of configuring it in allocation screen shown above. In fact there is expandable reservation is selected. It means resources from parent resource can be pooled to meet the cap of 2 GB and 50% reservation i.e. 1 GB.
Below is the screen of resource pool property when three VM’s are started.
Figure:04 Resource Pool settings After powering ON VM
Referring figure:02 allocation model, below spread sheet can be used to tally the resource pool settings.
Table:01 VM Resource calculation
Relationship between allocation pool model, resource pool and calculation in spread sheet is explained below. You can see all are matching and making complete sense.
Figure:05 Relationship between resource pool and allocation model
Figure:06 Virtual machine configured memory size
In table:01 you will notice configured RAM is 1536 MB RAM and 3000 MHZ CPU and it is still below the configured resource. Now lets try to exceed one of the limit. Let’s bump up configured memory of VM27 to 1.5 GB, then total will be 2.5 GB RAM (512+512+1536=2560 > than 2 GB RAM)
Figure:07 Configured memory size of VM27 changed to 1536 MB
Figure:08 VM27 cannot be powered ON because of memory resources not available
VM27 cannot be powered ON because memory configured is exceeded. Admission controls kicks in and stop VM27 from powering.
Similarly we can prove that if you over allocate CPU more than configured even then admission control will be in effect. In below screen I have changed the vCPU count of VM27 to 3. Total vCPU becomes 5 here and Single vCPU speed we have restricted to 1000 MHZ, therefore total CPU demand changes to 5000 MHZ but we have allocated only 4000 MHZ. Admission control got kicked in and it didn’t allowed VM to power ON
Figure:09 CPU Count of VM27 changed to 3
Figure:10 VM27 cannot be powered ON because of CPU resources not available
In Allocation pool reservation/limits are set at resource pool level as shown in figure 03 and figure 04 . There are no VM level resource limits/reservation set as we saw in Pay-as-you-go model.
Reservation is set at resource pool level, therefore resources within the pool will be consumed first come first service.
Memory & CPU reservation are configured on the resource pool dynamically i.e. only when VM is powered ON as shown in figure 4. If other organization vDC is using more resources, then it is no guarantee that resources will be available to power ON VM’s. So underline availability of resource is must, not only to power ON VM but also guarantee reservation to VMs