Capacity planners are often faced with a difficult decision to make, because much of their job requires balancing the challenging tradeoff between application performance and infrastructure efficiency. The responsibility of the capacity planner is to understand when more hardware is needed to assure application performance, while at the same time, avoiding wasted hardware. The traditional approach involves figuring out the current excess capacity, then trying to match it with future growth. This is usually done against key metrics such as CPU and memory.
The simple formula below helps illustrate this approach:
For example, if trying to solve for memory headroom in a cluster, one would take the following steps:
- Cluster has 5 hosts; each host has 128 GB of memory. So, total capacity = 640 GB.
- The average host memory utilization in the cluster is 80 GB. So, used capacity = 400 GB.
- Desired utilization of memory is 70%.
- The average VM uses 0.5 GB of memory (average utilization = 0.5).
- ((640 * 0.7) – 400) / 0.5 = 96 Virtual Machines = Available Headroom
Obviously this is a simplified formula, and there are other dependencies to take into consideration, such as how long does the hardware take to rack, licensing constraints, seasonal demand, etc. Regardless, no matter how sophisticated the calculation is, you eventually understand that a cluster can accept a specific amount of VMs from a specific template size, at a particular point in time. That data is later calculated separately against the future growth expected from the environment. This is usually done in a “batch process” mode against yearly or quarterly buying cycles.
The problem with this approach is that it is a static calculation that makes MANY assumptions, and does not change along with the changes in the utilization of the environment. As discussed in a previous post detailing the limitations of calculating capacity in a vacuum on an excel sheet, it is impossible to guarantee there are enough resources for the individual VMs on the individual hosts taking this approach. In order to understand the available capacity, you must intelligently make placement and sizing decisions that will consider all resources in the environment. Better placement causes better density that enables buying less hardware.
If you want this type of data, Turbonomic gives it to you in the click of a mouse against all your clusters, better than any utilization based excel sheet calculation:
The image above shows for every cluster in your environment, based on the average workload demand (considering ALL resources the VMs need), the available headroom for similar workloads per cluster taking into consideration storage, compute and network. The output is not only based on “average demand” but also encapsulates maximizing headroom based on efficient placement and sizing of the existing and the new workload.
A Demanding Approach
But what happens if we turn this approach on its head? Instead of starting with the supply (available capacity) then figuring out the demand offline, what happens if we start with the demand (needed VMs) and figure out the hardware needed, continuously, online, across the organization.
By taking this approach you eliminate many different assumptions in your growth plan. If you actually know how far you need to go, you can plan better against it. This is the difference between knowing you have a 75% full gas tank, and knowing that you can go 150 more miles before you need to fill it up.
Let’s take a look at how Turbonomic leverages this approach:
From Turbonomic’s “Deploy” tab you can specify what workload you expect to deploy when, along with when you need to reserve the necessary capacity:
From that moment on, all reservations are taken into consideration against all of Turbonomic’s generated decisions. For example, if you have an active reservation and you do not have enough capacity, Turbonomic will generate an action to provision more capacity. Or, whenever you run a future projection plan, you will understand when exactly you need to buy more hardware for future growth. These are calculated in real time against fluctuating demand in the environment.
The Projection Results view shows the future requirements for your environment. The charts show data points that correspond with the start date of the plan, and the intervals you specified — monthly, every 2 months, every three months, etc.
The charts on the top plot the utilization of host and storage resources over the time span of the projection. The additional resources summary panel lists the resources that will be added to your environment over time. The three provision projection panels on the lower right show the projected workload and projected resource requirements for VMs, hosts and storage. The green line indicates the current capacity, and the bars indicate the projected values. As you can see in the example above, on 11/16 – we will need more storage added to the environment.
Using this approach, capacity planners can be sure that they are adding exactly the capacity they need, when they need it, to assure application performance while remaining efficient. No guessing games or spreadsheets required.
There is no obligation to use Turbonomic UI in order to make these reservations and deploy the VMs. As a matter of fact, I would assume that in many organizations the deployment process is more complexed and will include additional steps. You can create reservations and get placement using Turbonomic’s API.
Detailed examples are available on our Green Circle community: https://greencircle.Turbonomic.com/community/products/blog/2016/03/25/reserve-vms-using-api-into-user-defined-segments. Turbonomic’s customers are using this to have a single source of truth where the entire organization can request future demand that is calculated against existing and coming capacity.