Cluster Expansion Calculator

Find when a virtualization cluster hits its utilisation threshold and when to order hardware given procurement lead time.

About Cluster Expansion Calculator

Compound growth turns capacity planning into a logarithm rather than a division: at 4% per month a cluster grows 60% in a year, so a linear projection badly overstates the runway. Subtracting the procurement lead time converts the answer from a capacity date into a purchase-order date, which is the number that actually needs a decision. Hardware lead times of two to three months are common and growth does not wait for them, so the useful output is not when the cluster fills but the last month in which an order still arrives in time. Substitute your own quoted host cost — hardware and licensing pricing changes constantly.

Formula

Cluster Expansion

months to threshold = ln(threshold VMs ÷ current VMs) ÷ ln(1 + monthly growth); order date = that minus lead time in months, where lead weeks ÷ 4.345 converts weeks to months.

threshold VMs: Cluster capacity × the utilisation you act on, not 100%
monthly growth: Compound growth rate, so the runway shortens faster than it appears
lead time: Procurement, delivery and racking, which growth does not pause for

Worked example

With the default values below, Cluster Expansion Calculator returns Months Until the Threshold of 0.3. Change any input above and every figure here is recalculated in your browser.

Inputs used

Hosts in cluster todayaccepts 1–2,000 hosts: 8 hosts
VMs each host supportsaccepts 1–1,000 VMs: 30 VMs
VMs running todayaccepts 1–500,000 VMs: 190 VMs
VM growth per monthaccepts 0–50 %: 4 %
Utilisation threshold to act onaccepts 30–100 %: 80 %
Procurement and racking lead timeaccepts 0–104 weeks: 10 weeks
Fully loaded cost per hostaccepts 0–1,000,000 USD: 22,000 USD
Planning horizonaccepts 1–60 months: 12 months

Results

Months Until the Threshold: 0.3 months
Order Hardware Within: 0.0 months
Hosts Needed by the Horizon: 5 hosts
Cluster VM Capacity: 240 VMs
Expansion Cost: $110,000.00
Procurement Urgency: Order now — lead time already exceeds the remaining runway

Step by step

1Values used
2Cluster Expansion
3Months Until the Threshold= 0.3 months
4Order Hardware Within= 0.0 months
5Hosts Needed by the Horizon= 5 hosts
6Cluster VM Capacity= 240 VMs
7Expansion Cost= 110,000.00
8Procurement Urgency= Order now — lead time already exceeds the remaining runway

Assumptions and limits

The result is derived only from the 8 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation or tax into account.
Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

How is Cluster Expansion calculated?

months to threshold = ln(threshold VMs ÷ current VMs) ÷ ln(1 + monthly growth); order date = that minus lead time in months, where lead weeks ÷ 4.345 converts weeks to months. Compound growth turns capacity planning into a logarithm rather than a division: at 4% per month a cluster grows 60% in a year, so a linear projection badly overstates the runway. Subtracting the procurement lead time converts the answer from a capacity date into a purchase-order date, which is the number that actually needs a decision.

Why does Cluster Expansion matter?

Hardware lead times of two to three months are common and growth does not wait for them, so the useful output is not when the cluster fills but the last month in which an order still arrives in time. Substitute your own quoted host cost — hardware and licensing pricing changes constantly.

What values do I need to enter?

This calculator takes 8 inputs: Hosts in cluster today, VMs each host supports, VMs running today, VM growth per month, Utilisation threshold to act on, Procurement and racking lead time, Fully loaded cost per host, Planning horizon. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why act at 80% rather than 100%?

The last 20% is failover capacity and scheduling headroom. A cluster at 100% cannot absorb a host failure, cannot accept a maintenance-mode evacuation and cannot place a large VM even when the totals suggest room.