Server Consolidation: Sizing Hosts and the Risk It Creates
Consolidation is the cheapest capacity project most organisations can do, and the one most likely to be done badly. This covers sizing it and the risk it creates.
Why consolidation pays
Several lightly-used machines cost several machines’ worth of everything.
Power and cooling for each, whether busy or idle. An idle server still draws a substantial fraction of its load consumption.
Rack space, billed directly in colocation and real but invisible in your own room.
Support contracts and spares per platform.
Administration time, which scales with machine count rather than workload.
Our TCO guide covers counting these, and consolidation reduces all of them at once.
Measure before you plan
The step that decides whether consolidation works.
Measure actual usage at peak, not allocated capacity, across every candidate workload. Allocated is almost always far higher than used, because machines are specified generously and never revisited.
Measure over a period long enough to catch the peaks: month-end processing, backup windows, seasonal load. A workload sized on a quiet Tuesday will not survive month-end.
Our memory sizing guide covers the number that usually decides host count.
Size for memory, then check everything else
Virtualisation hosts run out of memory long before cores, almost every time.
So: total the peak memory across workloads, add hypervisor and storage overhead, add failover capacity, add growth. That total divided by per-host memory gives host count. Then check cores, storage and network against that host count rather than the other way round.
Failover capacity is the part most often forgotten. A three-host cluster must run everything on two, or it is not a cluster. That means sizing each host so the cluster works with one gone.
Storage is where consolidation projects run into trouble
Consolidating compute concentrates storage demand that was previously spread across many machines’ local disks.
Three consequences.
Aggregate throughput matters more than capacity. Twenty workloads on shared storage produce a random access pattern that mechanical drives handle poorly. Our SSD versus HDD guide covers where flash becomes necessary rather than optional.
Shared storage becomes a single point of failure for everything consolidated onto it. Redundancy at the storage layer matters more after consolidation than before. Our storage architecture guide covers the options.
The network carries what the backplane used to. Where storage is shared, storage traffic goes over the network and needs bandwidth and separation. Our iSCSI guide covers this.
The risk consolidation creates
Being explicit, because it is the honest cost.
Twenty workloads on twenty machines means one failure affects one workload. Twenty workloads on three hosts means one failure affects a third of everything.
Three responses that are not optional after consolidation.
Cluster with failover capacity, sized so any host can be lost.
Redundant storage and network paths, because those are now shared by everything.
Backups that work, tested by restore rather than by the job reporting success. Our backup guide covers testing.
What comes out, and what it is worth
Consolidation produces surplus hardware, and deciding what happens to it before it is unplugged preserves its value.
Keep what is a genuine spare for platforms you still run.
Sell the rest promptly, while it has value. Our selling guide covers what holds value.
Sanitise everything properly before it leaves. Our decommissioning guide covers the order, including the machines worth leaving powered off in place for a few weeks first.
Frequently asked questions
How do I size hosts for consolidation?
Total peak memory across workloads, add hypervisor and storage overhead, add failover capacity, add growth. Divide by per-host memory for host count, then check cores, storage and network against that count.
Should I measure allocated or actual usage?
Actual, at peak, measured over long enough to catch month-end, backup windows and seasonal load. Allocated capacity is almost always far higher than used, because machines are specified generously and never revisited.
Where do consolidation projects usually go wrong?
Storage. Consolidating compute concentrates storage demand that was previously spread across many local disks, producing a random access pattern that mechanical drives handle poorly, and making shared storage a single point of failure.
What risk does consolidation create?
Concentration. Twenty workloads on twenty machines means one failure affects one workload; on three hosts it affects a third of everything. Failover capacity, redundant storage and network paths, and tested backups stop being optional.
How many hosts do I need for failover?
Enough that the cluster runs everything with one host gone. A three-host cluster must run the full workload on two, which means sizing each host accordingly rather than to the average.
What should I do with the hardware that comes out?
Keep genuine spares for platforms you still run, sell the rest promptly while it has value, and sanitise everything properly before it leaves.
Tell us the workloads and their actual peak usage, and we will size hosts and storage including the failover capacity people forget.
