In the previous article of this series we discussed the very first phase in every virtualization adoption project: recognition of best physical servers for migration inside a virtual infrastructure.
We saw how not every service can be virtualized and how some of them require special attentions. We also considered some available solutions to help in the task, discovering the virtualization market is still very poor in this aspect.
Once decided which machines will be virtualized we must move to the next, most critical phase of the entire project.
Capacity planning
What is capacity planning and why it’s the most delicate aspect of every project?
In this phase we evaluate distribution of virtualized physical machines inside physical hosts, dimensioning their resources, including processors type, memory size, mass storage dimension and type, redundant motherboard architecture and so on.
These machines have to contain planned virtual machines without suffer, have to survive more or less severe faults, depending on project’s requirements, and have to scale up easily.
In a medium complexity project chosen hardware doesn’t simply include physical servers, but means one or more storage devices, internetworking devices, network cards and cabling.
Every piece has to be chosen carefully and not for a performance need only: our decision will impact on next phase, when the return on investment (ROI) will be calculated, understanding if the project is worthwhile or not.
One critical value in hardware sizing is the virtual machines per core (VM/core) ratio.
Every virtualization platform has an expected performance level on the average, influenced by several factors, independents from the hardware chosen, from the virtualization engine optimization to the load virtual machine will have to handle. And the amount of virtual machines a single core (or a single CPU, in case of non-multicore processors) can support without problems depends on these factors.
So a VMware ESX Server 3.0 and a Microsoft Virtual Server 2005 R2 have a completely different VM/core ratio on the same host.
Why this value is so vague? The number of these factors is so large that it’s quite hard state a definitive ratio for a single product and virtualization vendors can barely provide an indication.
For example VMware states its ESX Server is able to handle up to 8 virtual machines per core, while its Server (formerly GSX Server) can handle up to 4 virtual machines.
But this numbers can be much higher or much lower depending on things like hosted application technology (a legacy accounting software written in COBOL is not what we call something efficient), I/O loads, etcetera.
Even if the value is so uncertain it’s still the most critical point in a virtualization project and it’s mandatory for a product comparison. Which is sometimes impossible: at the time of writing Microsoft has still to provide a suggested VM/core ratio for its Virtual Server 2005 R2.
Going beyond mere VM/core calculation, it’s mandatory to remember we are not going to virtualize a physical server but one or more server roles, so trying to size a virtual machine in the same way the actual physical server is could not be the best solution.
Given more than one host machine, a typical erroneous approach is consolidating virtual machines with the same logic of their physical location. So all production machines have to be virtualized in the first host, all development machines have to be virtualized in the second one, and so on.
It mainly depends on two factors: a natural desire to maintain what is considered a logical order, and a typical cultural bias, where physical location strictly relates to contained services (a way of thinking we’ll loose progressively towards our evolution to grid computing).
This approach usually leads to bad consolidations ratios: architects trying to cram several production virtual machines in the same host will find that machine overloaded by the huge weight of exercise services. Meanwhile another host, serving underutilized virtual machines, will waste most of its computing time.
So it’s pretty evident the big challenge of capacity planning is finding complimentary services to balance virtual machines allocation.
This operation has to consider several services factors, including expected workloads during all hours of a day, kind of physical resource requested, inclination to have very dynamic fluctuations, etc.
Obviously these factors can change over time, scaling up or completely mutating, so capacity planner must also try to forecast workloads growth, while in the enterprise management virtual administrators will have to rearrange virtual machines upon environment changes.
If this seems complex enough the biggest value still misses from the equation: acceptable performance level of every service.
This usually is the most overlooked aspect of capacity planning, giving for sure virtualized applications will always perform at their best. In the reality, even in the best arrangement, every software needs a certain amount of physical resources to perform in an acceptable way.
Capacity planning has to consider complementary workloads scenarios and must contemplate alternatives arrangements to always grant the expected performance for every service.
The task appears overwhelming but luckily part of it will be simplified in a near future, when all virtual infrastructures will be able to seamlessly and dynamically move virtual machines on different hosts, depending on their workloads.
VMware just launched this feature, called Distributed Resource Scheduler (DRS), within its new Virtual Infrastructure 3 (aka ESX Server 3.0 and VirtualCenter 2.0).
Microsoft expect offer the same capability with its upcoming Virtual Machine Manager tool.
This amount of factors can be partially managed today with help of few products.
The first and possibly most complete one is provided by the current market leader, VMware, which offers its Capacity Planner tool as a consulting service, available at fixed price of $22,000 for up to 200 servers.
The biggest benefit of this tool it’s the huge database where average performance values of industry applications are stored.
Based on these values the VMware Capacity Planner not only is able to suggest the best placement possible, but it’s also able to recognize troublesome applications, both at physical and virtual level.
VMware is not the only one offering this kind of tools: for example HP, with its Solution Sizer, and Sun, with its Consolidation Tool, are offering their customers a notable aid in this aspect of the project.
In both cases products are free but are tuned and locked for sizing just specific servers.
Once again PlateSpin PowerRecon, already mentioned in the candidates recognition phase, seems to be the most cost-effective solution for workload placement.
Thanks to its new Consolidation Planning Module it’s able to offer same capabilities of VMware Capacity Planner, minus the Industry Average database.
Its biggest feature is the integration with company physical to virtual (P2V) product, which we’ll see in the fourth phase of our virtualization adoption, offering a logical and integrated flow of actions during the initial steps of the project.
In the next part we’ll how the critical work of capacity planning translates in an economical value, justifying or not the entire project.
This article originally appeared on SearchServerVirtualization.