It ain't what you do

It ain’t what you do (its the way that you do it)

Clouds…. Puffy things… stretching as far as the eye can see… limitless.

White, wispy clouds that brings thoughts of hazy summer days?

Or dark, foreboding, angry clouds that warn of heavy rain or snow?

That’s the thing about Clouds.  They can be all things to all men, and what sort of clouds they are will change what you think about them completely.

The IT cloud is no different.  Depending upon how your cloud has been implemented will completely change what value it brings to your organisation, how you can get the best out of it, and for the Capacity Manager… how you need to manage it.

I’ve blogged before about the issues related to the sharing of resources within a cloud.  If two clients are promised the same CPU resource, then you better be certain that they don’t both want to make use of it at exactly the same time, otherwise you’re going to run in to the same contention for resources that Capacity Managers have been dealing with for ages.  The Cloud isn’t helping or introducing anything new to the equation.

But recently, I have been involved in the Capacity Management of a private cloud in which the client has decided that there would be NO sharing of resources!

This is a new concept to me.

Effectively, a bunch of blades are combined into a single Vmware cluster, and that cluster then hosts a multitude of Guest OSs (Linux, Windows, etc).  But whereas in a normal Cloud architecture you would oversell the CPU and Memory by a factor of X, in this private cloud the memory was undersold (on purpose) by a factor of 0.9.

This meant that for every 512Gb of memory that was installed on the physical blade, only 460Gb would be available for client use.  CPU was still being oversold at a ratio of 2.5x, on a per core count, which on these blades was 80cores * 2.5 = 200 vCores.

The challenge for the Capacity Manager changes from the usual assessment of utilisation approaching 100% of the available resources, into an assessment of when allocation will reach 100% of the available resources.  In this case, checking whether the allocation of cpu & memory to guests would reach the limits of 200 vCores or 460Gb vMemory first.

Consider the following list of guest demand (arriving in this order)

As you can see from the table above; although the total vCore demand is only 110 cores (far below the 200vCore capacity limit), there is too much vMemory demand and two of the guests (G and J) cannot be accommodated because the accumulated memory requirement is above the 460Gb that is available.  Even if two of the guests are powered down (B & E) the Capacity Manager must assess the impact onto cluster for when they are powered up, and therefore their vMemory allocation is considered to be active.  Their combined 160Gb of memory cannot be allocated to anyone else... just in case they are powered up and need it.

In Utilisation based Capacity Management, it would be normal to consider the fact that these two guests are powered down, and also to look at the utilisation of all other guests.  For example, guest F that has an allocation of 128Gb vMemory might only use 50% of this allocation at its peak.  In this case the unused 64Gb of vMemory would be available to allocation to other guests and thereby we would be able to make fuller use of the assets.

In Allocation based Capacity Management, the policy of the business not to over-allocate resources means that we must ignore this potentially available resource, and effectively plan on a “worst-case scenario”.

So you see…. It ain’t what you do (converting from stand-alone infrastructure to a cloud based solution) it’s the way that you do it.  Because doing it with inefficient policies will not deliver the full benefits that you might have hoped for.