Month: May 2019

Capacity planning using vRealize Operations Manager Version 6.x.

Difference between Demand based Model and Allocation Based Model

In this article I share few points which might help one get more understanding on these capacity planning models.

The Demand Model element:

If you adopt a demand based policy, the capacity planning engine will only consider the   resources that are actually being used, or demanded, as consumed. So, if your 4x vCPU, 8 GB RAM, 40 GB disk VM is only using 2 vCPU, 5 GB RAM, and 20 GB disk space, the remaining resources are reported as having Some capacity still available.

The Allocation Model element:

Determines how vRealize Operations Manager calculates capacity when you allocate a specific amount of CPU, Memory and storage resource to clusters.

As allocation calculations here can be done with certain ratio or percentage of actual physical resources.

For CPU its vCPU to pCPU ratio
For Memory it is over commitment
For Storage it is thin provisioning

Questions like which policy is Ideal for Me? What is the ideal vCPU/pCPU ratio if I am using allocation based model? Is memory over commitment recommended for production environment? etc are all design based and the answers differ from environment to environment.

Customer has to work out a vCPU/pCPU ratio that fits his environment. The ideal approach would be to start with a big ratio like 8:1 and then monitor the stats. If stress comes into picture then the ratio can be decreased to something like 5:1 and so on.

Example showing difference in capacity remaining with Allocation and demand models

pic1

Below are 4 default vRealize Management policies available for customers to do capacity planning although a custom policy can be created by customer starting from scratch.

VMware Production Policy (Demand only)
Optimized for production loads, without using allocation limits, to obtain the most capacity.

VMware Production Policy (with Allocation)
Optimized for production loads that require the demand and allocation capacity models.
No over commitment for Mem and storage. Over commitment available in CPU.

VMware Production Policy (without Allocation)
Optimized for production loads that require demand capacity models, and provides the highest overcommit without contention.
Over commitment available in CPU, Mem and Storage

VMware Test and Dev Policy (without Allocation)
Optimized for Dev and Test environments to maximize capacity without causing significant contention, because it does not include capacity planning at the virtual machine level.
The key deference in these policies comes to whether we allow over commitment or not.
And if we allow over commitment then is it allowed for CPU, Memory or Storage or for all.

A breakdown of each policy capacity analysis can be seen to decide which metrics we need to include to further tweak the policy to our needs. The accuracy and value of capacity management views and reports relies on an administrator’s ability to correctly translate their environmental requirements into policies.

To navigate to these policies and to check/edit the matrices covered.

pic2

pic4

pic3

pic5

Spend time and dig deep… this could be a onetime investment with lot of returns for vSphere Admin..