Capacity Planning for Small Hosting Providers
Capacity planning is the discipline of buying or reserving resources before customers experience the shortage. It combines technical measurements with lead times, failure reserves, business forecasts, and the reality that a small provider cannot instantly add a rack, circuit, storage shelf, or experienced operator.
Usable Capacity Is Not Installed Capacity
A cluster may show free CPU, memory, and disk while still lacking enough capacity to survive a node failure, complete a migration, absorb a backup window, or handle customer growth.
Installed capacity
- platform overhead
- reserved failure capacity
- maintenance and migration reserve
- performance safety margin
- growth lead-time reserve
= safely sellable capacity
N+1 thinking
If a three-node cluster must continue after losing one node, the remaining two nodes need enough CPU, memory, storage access, and network capacity for the workloads that must restart. Capacity that disappears with the failed node cannot be counted toward recovery.
Compute Capacity
CPU allocation and actual CPU consumption are different. Virtualization allows overcommit because most guests do not peak simultaneously, but the overcommit ratio must be based on observed workload, not a marketing number.
CPU signals
- Sustained host CPU utilization and peak duration
- Load average in context of runnable and blocked processes
- Virtual-machine CPU ready or scheduling delay where available
- NUMA placement for large guests
- Steal time inside guests
- Performance during backup, migration, malware scan, and maintenance windows
Memory signals
- Host free and available memory
- Guest working set, ballooning, swap, and page-fault behavior
- Filesystem and database cache requirements
- Memory needed to evacuate or restart guests after a node failure
- Kernel, ZFS ARC, hypervisor, and management overhead
Example cluster calculation
| Item | Amount |
|---|---|
| Three nodes, 512 GB RAM each | 1,536 GB installed |
| Host/platform reserve, 32 GB each | -96 GB |
| One-node failure reserve | -480 GB usable-node capacity |
| Operational growth margin | -120 GB |
| Approximate safely allocated guest memory | 840 GB |
The exact numbers depend on the platform and workload. The important point is that 1.5 TB installed does not mean 1.5 TB should be sold.
Storage Capacity and Performance
Storage planning has at least four dimensions:
Raw capacity
Total bytes before RAID, replication, metadata, snapshots, and reserved space.
Usable capacity
Bytes available to workloads after protection and filesystem overhead.
Performance
Latency, IOPS, throughput, queue depth, and workload mix.
Recovery capacity
Space and bandwidth for rebuilds, snapshots, restores, migrations, and temporary copies.
Why percent free is not enough
Twenty percent free on a 1 TB volume is 200 GB. Twenty percent free on a 100 TB array is 20 TB. Both may be acceptable or dangerous depending on growth rate, rebuild behavior, and the largest operation that must fit.
Track rate of change
Days to full = current free capacity / average daily growth
Example:
Free capacity: 12 TB
Average growth: 180 GB/day
Estimated time to full: about 68 days
Then subtract procurement, shipping, installation, migration, and validation lead time. A 68-day runway may already be an emergency if expansion normally takes 60 days.
Storage alerts
- Absolute free capacity
- Percent free capacity
- Forecasted days to full
- Thin-pool data and metadata use
- Snapshot or clone growth
- RAID rebuild state and duration
- Latency and queue-depth deviation from baseline
- Backup-repository prune and garbage-collection health
Network Capacity
A port’s line rate is not the same as available service capacity. Consider traffic direction, commit, burst rules, oversubscription, packet rate, flow count, and failure behavior.
Measure more than bandwidth
- Average, peak, and 95th-percentile utilization
- Packets per second and small-packet load
- Interface errors, drops, discards, and pause frames
- Optical receive/transmit levels
- Latency, jitter, and packet loss
- BGP route count and control-plane resource use
- State table and connection rate on firewalls or load balancers
Failure-state capacity
Two 10 Gbps transit links do not necessarily provide 20 Gbps of resilient capacity. If the design must survive either link failing, the remaining link needs enough commit, port capacity, packet-processing capacity, and upstream headroom for the required traffic.
| Condition | Question |
|---|---|
| Normal | Is traffic balanced as intended? |
| One transit down | Can the surviving link carry critical load without sustained congestion? |
| One switch down | Do server bonds and upstream paths converge correctly? |
| DDoS | Does the access circuit saturate before local mitigation can act? |
| Backup window | Does internal backup traffic contend with storage or customer traffic? |
Power, Cooling, Rack Space, and Ports
Facility constraints often grow in discrete steps. Adding one server may require a new circuit, PDU, switch, cabinet, cross-connect, or cooling review.
Track physical inventory
- Available rack units by usable depth
- Power draw and breaker capacity per A/B feed
- PDU outlet count and connector type
- Switch port and optic availability
- Patch-panel and cross-connect capacity
- IP address and VLAN availability
- Spare rail kits, cables, drives, power supplies, and optics
- Facility delivery and installation lead times
IP address capacity
IPv4 scarcity can become a product constraint before compute or disk. Track assigned, reserved, quarantine, infrastructure, and genuinely available addresses. Design IPv6 as a normal service capability rather than an afterthought.
People and Process Are Capacity
A provider can have empty rack space and still be out of capacity if every new customer adds manual work the team cannot absorb.
Operational capacity indicators
- Tickets per customer or product
- After-hours alerts and false-positive rate
- Time spent on manual provisioning
- Number of one-off configurations
- Backlog of patches, lifecycle work, and documentation
- Incidents caused by knowledge concentrated in one person
- Time required to onboard another operator
License and vendor capacity
Include control-panel licenses, virtualization subscriptions, backup licenses, IP transit commits, support contracts, warranties, domain renewals, certificate services, and software limits in capacity planning. A technical expansion may be blocked by commercial lead time or license cost.
Build a Capacity Review
Monthly capacity table
| Resource | Current | Failure-state | Growth | Lead time | Action point |
|---|---|---|---|---|---|
| Cluster RAM | 61% allocated | 88% after one node loss | 3%/month | 30 days | Order at 70% allocated |
| Primary storage | 72% used | N/A | 1.8 TB/month | 60 days | Expand with 6 months runway |
| Transit | 4.2 Gbps 95th | 8.4 Gbps on one link | 0.3 Gbps/month | 45 days | Upgrade before failover exceeds 80% |
| Rack power | 58% A / 55% B | Within circuit policy | 2 A/quarter | 90 days | Reserve second circuit |
Use scenarios, not one forecast
- Expected: Current customer and sales trend continues.
- High growth: A large customer or successful product adds demand quickly.
- Failure: A node, storage shelf, circuit, or facility path is unavailable.
- Migration: Temporary duplicate capacity is needed during replacement.
- Supplier delay: Hardware or circuit lead time doubles.
Capacity review questions
- Which resource reaches its action point first?
- What is the longest procurement or implementation lead time?
- What capacity disappears during the most likely failure?
- What can be reclaimed safely before purchasing?
- Which monitoring data is missing or misleading?
- Does expansion create a new single point of failure?
- Can current staff operate the expanded design?