Home > Blogs > VMware Cloud Management


vCenter Operations Management Tech Tips: Tip #9 – Best Practices for vSphere Capacity Planning – Part 1 of 4

Welcome back from VMworld San Francisco 2013. We promised that we will come back and share the content from our VMworld presentations on vSphere Capacity Planning using vCenter Operations. Here is a mini-series of Tech Tips  covering:

1) picking the right metrics and knowing your operational knobs
2) picking the right visuals to understand
2a) your VM growth, Infrastructure burn rate and capacity risk
2b) Insights into right sizing your VMs 
2c) how to optimize your infrastructure utilization and realize savings?

Some of the patterns I am seeing across the infrastructure IT leaders are often around trying to find answers to these key questions for effective capacity planning:

i) Am I meeting my SLAs or do I have capacity risk?
   - by analyzing VM growth, infrastructure burn rate and capacity risk
ii) Can I optimize & improve infrastructure utilization & realize savings?
   - by reclaiming unused resources & increasing utilization safely
iii) Do I have enough for future growth?
   - What does my VM demand growth looks like and do I have enough or will i run out?

Working with several IT leaders, we present here how they are using vCenter Operations to get answers to the above questions. But the first step is to understand what your operational policies are across your production or test-development environments and getting the right metrics.

I take a simplistic example – over the summer, my 7 year old son fell in love with playing his Ninjago game – he played for 30-45 minutes at a stretch. But now school is on and he is ‘entitled’ to play for 10 minutes after his homework is done. His ‘demand’ – what he wants is still to play for 30-45 minutes. When he does not get what he wants, there is ‘contention’ (tantrums!).  Virtual Machines ( VMs) in vSphere are very similar to my son! Lets take the example shown below of a SQL VM configured with 16GB capacity.

 

 

 

 


Some points to note :
- What a VM is configured with is what we call ‘allocation’. What a VM demands due its OS/Application workload is ‘Demand’. What a VM gets is ‘Usage’. What a VM does not get is ‘Contention’.

So what a VM wants  = what a VM gets + what a VM does not get
Or Demand = Usage + Contention

 - If you do sizing or capacity planning based on just ‘usage’ you may be under-sizing and under planning. If you size or plan future capacity based on allocation, you may be over-sizing or over-provisioning it.

In addition, there are several metrics available in vCenter  – for different purposes – e.g. Memory consumed is a great metric to tell you how ballooning and sharing is working  – ummm. But wait it  does not tell you how much a VM wants – or what is its Demand – based on all the active pages it touches. vCenter Operations uses the concepts of Allocation, Demand etc to help you analyze the right way.

Ok, so we got the right metrics, now lets understand what are your policies to manage capacity and risk across your production or test-dev environment.

Several customers want to optimize for performance in production environment but optimize for higher density of VMs in their test-dev environment.

 

 

 

They over-commit CPU and Memory in test-dev but don’t over-commit in production. They have higher buffers in production etc. vCenter operations enables you to capture your ‘operational knobs’ into policies used by its analytics. It also provides out of box policies such as ‘production’ and ‘test-dev’ that can be used.

Don’t forget to check out our part 2 of this Tech Tip series on getting the right visuals to understand demand, utilization and capacity risk in your virtual environment!

 

2 thoughts on “vCenter Operations Management Tech Tips: Tip #9 – Best Practices for vSphere Capacity Planning – Part 1 of 4

  1. Pingback: vCenter Operations Management Tech Tips: Tip #10 – Best Practices for vSphere Capacity Planning – Part 2 of 4 | VMware Cloud Management - VMware Blogs

Comments are closed.