VMware’s vCloud Director is a very good way for organisations to start to take advantage of cloud computing, including private, public and hybrid models. Cloud computing can offer new efficiencies and cost savings for organisations that optimise it’s use. But where do you start? If you go searching for best practices, design considerations and references for designing and building a vCloud Director environment you will find plenty for large scale deployments. But it might seem difficult to find much in the way of design considerations for starting off with a small vCloud Director environment, such as for a proof of concept, small lab or pilot. In this article I hope to offer some advice that will allow you to dip your toes in the water and get up and running quickly without much complication, while allowing you to scale up in the future. This article looks at the different allocation models. Future article will discuss the rest of the components you need to consider.

Even if designing for a small environment one resource I highly recommend you review if the vCloud Architecture Toolkit (vCAT), which is a VMware Validated Architecture for Cloud Computing and supporting tools. The vCAT is fully supported by VMware, so if you leverage the design considerations and guidance contained within it you know you can get support.

This article focuses on Resource Allocation Models in vCloud Director. In future articles I will cover additional design considerations.

Pre-requisites and assumptions

1. You have enough knowledge to install and configure a simple VMware vCloud Director environment.
2. You have a minimum of 3 hosts available (1 for Management, 2 for vCloud consumption).

Allocation Models

vCloud Director allows resources to be allocated from a Provider Virtual Datacenter (PvDC) to Organisation Virtual Datacenters (OrgvDC) for consumers to use. The allocation is done in accordance with three different models. Pay as You Go (PAYG), Allocation Pool, and Reservation Pool.

The advantage with PAYG is that you get a defined reserved amount of resource per VM when the VM’s are powered on only, so they don’t consume any resources from the OrgVDC or PvDC while they are powered off. The system admin defines the overcommitment and service levels for compute resources. New in vCloud Director 5.1 the PAYG Virtual Datacenter can have a limit set to prevent one OrgVDC consuming all cloud resources.

With Allocation Pool the OrgVDC consumes the guaranteed portion from the PvDC regardless if VM’s are powered on, but this at least gives them a defined amount of resources. Each VM then is set a reservation equal to the percent that is guaranteed and the VM’s deployed can consume the resources up to the defined limit of the allocation model. Powered Off VM’s don’t consume resources from the OrgVDC. The system admin defines the overcommitment and service levels for compute resources. New in vCloud Director 5.1 all vCPU’s have a defined limit set which will impact how many VM’s can be powered on within an OrgVDC. This vCPU limit is defined by the System Administrators.

With the reservation pool the you set a defined limit and then it’s up to the tenant of the OrgVDC to define the level of overcommitment and how much resources are reserved for each VM/vApp. You guarantee the resources from the PvDC to the OrgVDC and the OrgVDC consumes those resources regardless if a vApp is powered on. VM’s or vApps can have different reservations or no reservation. It’s up to the tenant to choose. But the catch is the tenant or consumer can cause performance problems within their OrgVDC if they overcommit too aggressively. The tenant needs to take some care with capacity planning around their usage.

In some ways an Allocation Pool with 100% guaranteed is superior to a Reservation Pool, as the system admin / provider is defining the SLA of the pool and VM’s to be 100% guaranteed, I.e. Allocation = Reservation. The tenant then can’t get themselves into trouble as easily. It’s up to the system admin to manage capacity.

The Allocation Pool and Reservation Pool offer more predictability of billing to the tenant, but are less efficient from a service provider perspective in terms of resource utilization. PAYG offers less predictable billing to the tenant, but more efficient resource utilization potentially, and more flexibility in a small environment.

Recommendation

When designing a small environment I generally recommend you start with PAYG resource models, especially where usage is unknown. This allows the best sharing of resources between OrgVDC’s and Organisations. PAYG provides a dynamic on demand environment, but can still have an upper limit set per OrgVDC. The PAYG model supports an Elastic VDC, which means it can grow across clusters. This makes it easy to expand the environment as and when needed. The Allocation Pool Model also supports elastic vDC from v5.1 with some restrictions, but it will depend which update version is actually being used on what functionality of the Allocation Pool model you receive.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2013 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.