Infrastructure Control Server · Capacity planner

Tomorrow’s capacity problems, today

Proposed interface concept Not released. A design for discussion, drawn in HTML and CSS; not a screenshot of working software.

Available capacity per resource, historical growth, projected exhaustion as a range with its assumptions, whether the cluster survives the loss of a host, resizing and expansion recommendations, and a what-if for adding a tenant. The figures shown are example data.

View full size Download image (WebP, 1600×1136) Capacity and scaling

Proposed interface concept Not released · example data · subject to change

Office UnboundInfrastructure ControlRidgeline IT · ProductionSearch hosts, VMs, containers, services/2DO

Production1 of 4 environmentsOverviewHypervisorsContainersServicesMonitoringAlerts2Updates3CapacityRecoveryAudit logSettingsController ics-01Standby ics-02 ready

ProductionCapacityCapacity plannerExample data

Both clustersCluster ACluster BExport plan

Available capacity and host-failure headroomCan the cluster survive the loss of 1 host?

Resource	Total	In use	Available	Survives loss of 1 host
CPUCluster A	192 cores	46% at peak	104 cores	Yes
MemoryCluster A	1,536 GB	1,180 GB	356 GB	No · 156 GB short
Storageceph-a	60 TB	31 TB	20 TB to 85%	Yes
CPUCluster B	64 cores	31% at peak	44 cores	Yes
MemoryCluster B	512 GB	190 GB	322 GB	Yes · 66 GB spare
Storageceph-b	40 TB	28.4 TB	5.6 TB to 85%	Yes

Storage cluster B (ceph-b) · % used

Used, weeklyProjectionLikely rangeAlert at 85%

100%85705540

85% in about 7–10 weeks 71% today

90 days ago6030Today+4 wk+8 wk+12 wk

Estimate, not a date. Based on 90 days of metrics: growth of 1.4–2.0 points a week (central 1.65), assumed to continue. Range shown is ± one standard deviation of weekly growth. Excludes tenants not yet added.

What if: add a tenantSimulation

60 users Mail, Files, Docs, Chat Place on cluster B

Fits. Estimated +38 GB memory, +4 vCPU and +1.2 TB storage in the first year.

N+1 memory headroom, cluster B66 → 28 GB
CPU at peak, cluster B31 → 36%
ceph-b reaches 85%~2 weeks sooner (5–8 wk)

Sizing per user from this environment’s last 90 days, not a vendor table.

VM resizing recommendations

docs-01 · 16 → 12 GB memoryPeak 9.1 GB in 30 daysReclaim
search-01 · 4 → 6 vCPUCPU-bound 3 h each night, indexing lagsGrow
db-01 · +200 GB disk81% full · 3 GB a dayGrow

Storage expansion plan · ceph-b

NowWeek 0Order 4 × 7.68 TB SSDsLead time 2–3 weeks
Week 3windowAdd 2 disks per hostUsable 40 → 55 TB · rebalance overnight
AfterUsage falls to about 55%85% then 6–9 months away, estimate

Scaling proposalNeeds approval

Restore N+1 memory on cluster A: add 256 GB to each of pve-a1, a2, a3

One host at a time, each in its own maintenance window
Live-migration room is 156 GB short: 3 non-critical VMs stop during each host’s window
Rollback: host returns unchanged if checks fail

Approvals 0 of 2RejectApprove

OverviewMonitoring2AlertsCapacityMore

Headroom, host-failure tolerance, growth with stated assumptions, a tenant what-if and a scaling proposal that waits for approval.

Shape this before it is built

This screen is a proposal. MSP design partners review concepts like this one against how they actually run customers, and say what is missing.

Become an MSP design partner Register interest