Infrastructure · Capacity & scaling
See tomorrow’s capacity problems today.
Understand current resource consumption, identify trends, anticipate growth and plan expansion before performance becomes a problem. Office Unbound is being designed to combine infrastructure analytics with capacity recommendations an operator can act on.
Project status Planned. The Infrastructure Control Server is in the roadmap’s Infrastructure Operations track; nothing described here has been built.
Why capacity needs its own tools
Productivity platforms grow unevenly. Mail and file storage grow every day; meeting and document-editing load arrives in peaks; a new tenant can double the size of a deployment in a week. A host that looks comfortable on average can still run out of memory on a Monday morning, and storage that grows slowly can still fill a pool before anyone checks.
The ICS already collects the metrics needed to see this coming. The capacity features are intended to turn that history into trends, forecasts and specific recommendations, and to carry out approved changes safely.
Proposed interface concept Not released · example data · subject to change
| 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 |
Used, weeklyProjectionLikely rangeAlert at 85%
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.
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.
- 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
- 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
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
Monitoring and analytics
What the capacity planner is designed to measure and keep as history.
Resources
CPU utilization, RAM usage, storage utilization and growth rates, network throughput, disk performance.
Workloads
Service-level resource usage, VM and container utilization, resource contention between workloads.
Patterns
Historical trends, peak usage and performance baselines, so a busy hour is compared with normal for that hour.
Tenants
Growth projections per tenant, so an MSP can see which customers are driving demand.
Protection
Backup capacity, and how much of it future growth will consume.
Redundancy headroom
Whether the remaining hosts could absorb the workload if one failed.
Questions it is designed to answer
When will storage run out?
How many more users can this environment support?
When will more RAM be needed?
When should another hypervisor be added?
Which services use the most resources?
Is the current infrastructure overprovisioned?
Can the environment survive a host failure?
Can another tenant be added safely?
Which workloads need more capacity?
What infrastructure will be needed in six months?
How forecasts are meant to be made
A forecast is only as good as its inputs. Each one is designed to be built from metrics the deployment has actually collected, to state the assumptions it rests on, and to show a range rather than a single date.
- Collected metrics. Forecasts use this deployment’s own history, not generic sizing tables. A new deployment with little history gets wide ranges, and is told so.
- Explicit assumptions. Growth rate, the period it was measured over, planned tenant additions and seasonal patterns are shown with the forecast and can be changed.
- Stated uncertainty. “Storage is projected to fill between two dates, assuming current growth” rather than one confident day.
Trends change: a migration, a new customer or a change in how people work can make last quarter’s growth rate irrelevant. Forecasts are planning aids for an administrator, not commitments about performance.
Scaling recommendations
Specific changes, each with the reason and the data behind it.
- Concept An idea or design direction; not yet committed to the roadmap
- Under evaluation Being assessed; no choice made yet
- Planned Committed to the roadmap; work not started
- In development Being worked on now
- Implemented Code exists in a public repository
- Tested Passed published tests
- Production-ready Shipped in a supported release
| Capability | What it means | Status |
|---|---|---|
| Resize VMs | Memory and CPU allocation adjustments, up for constrained workloads and down for overprovisioned ones. | Planned |
| Expand storage | When and where to add storage, based on growth per pool. | Planned |
| Balance workloads | VM migrations between hosts to relieve contention, within failure-domain rules. | Planned |
| Add a hypervisor | When the cluster will need another host, including to keep redundancy headroom. | Planned |
| Replicate services | Additional instances for services that support horizontal scaling. | Planned |
| Plan redundancy | Where a single failure would take out a service, and what would prevent it. | Planned |
| Assess a new tenant | Whether a new customer’s expected size fits the current environment, before it is provisioned. | Planned |
| What-if simulation | Model a change, such as adding a block of users, losing a host or moving a tenant, and see the projected effect before committing to it. | Planned |
Controlled scaling implementation
Recommendations are only half the job. The ICS is designed to carry out approved infrastructure changes through supported hypervisor and orchestration APIs, the same way it carries out recovery actions: only with authorization, only after checks, and with every step recorded.
Before a change runs, the ICS is designed to confirm that it can be done safely. If any check fails, the change does not run and the reason is shown.
Horizontal scaling applies only to services that support it. Some components scale by adding instances; others only by giving one instance more resources. Which is which is part of the component evaluation.
Available capacity
The target host or pool has room for the change, with headroom left.
Storage consistency
Storage is healthy and replicated as expected before data is moved or resized.
Failure domains
The change does not place redundant services on the same host or storage.
Workload compatibility
The workload supports the operation, such as live migration or adding an instance.
Rollback feasibility
There is a way back if the change does not work as expected.
Approval
An administrator approves, unless the operation is one the operator has explicitly allowed to run under policy.
Planning capacity for customers?
If you size and grow environments for others, tell the project which forecasts you need most. That shapes the first analytics features.