Design Implications

High performance relates to guaranteeing physical resources in the provider virtual datacenter. Providers must keep in mind that this could mean lower consolidation ratios on the provider clusters. In all cases Company1 has imposed a “total number of virtual machines” limit on the consumers. This is to mitigate some of the considerations below.

Pay-As-You-Go – With this model the consumer may get performance that is easier to manage, but due to its “all you can eat” nature, Company1 must closely monitor the provider virtual datacenter. If the provider virtual datacenter is low on resources, it can affect the consumer’s ability to add more virtual machines.

Reservation Pool – With this model it is up to the consumer to use resources responsibly to get the desired performance within the pool. Otherwise, higher consolidation ratios can be achieved, but performance can suffer. In addition, this can also affect other consumers on the same datastores due to swapping.

Allocation Pool – The model can mitigate some of the issues found in the Reservation Pool model. Due to the fact this is a hybrid of the Pay-As-You-Go and Reservation Pool models, it handles everything provided you use the high performance configuration. By using the high performance configuration you get a dedicated pool that the consumer cannot grow out of (like the reservation pool). Each virtual machine in the pool gets 100% guarantee of the available resources. When the pool is completely consumed, provisioning stops.

Company1 has designed the deployment with some aspects of consumer performance in mind, not only with each allocation model, but also with levels within each model. These templates are not static—they are just an initial starting point. Customer requirements can drive customization and changes to these options. Company1 will bill customers for any changes required. They feel consumers can start with these models and then modify them as needed.

Note: It is not possible for a consumer to change between models without downtime and migration. Modifying settings of each allocation model is possible but some virtual machine reboots may be required.

See the following for more information: VMware vSphere 5.1 Clustering Deepdive (Chapter 13) available from Amazon.com.