Capacity planning¶
New in the next release
Capacity planning is on the dev and qa builds now, and in the next release.
Capacity planning answers the questions that come before a purchase order:
- When will it be full? "On or around 4 March, the Prod cluster's memory reaches 80%." For every cluster, host, datastore, Ceph pool, backup store and NAS volume Ferrule watches, with a likely range rather than one falsely precise day.
- How much more fits? How many more VMs of a size you choose, and what stops the next one.
- What if? Add VMs, add a host, lose a host, move VMs between clusters, or add disks to a pool, and see the new date before you do it.
- Will a new host actually fit the rack? Free switch ports of the right kind on the right switches, the optic to buy, VLANs, the BMC's port, UPS and PDU headroom, rack units, free addresses and licenses.
- What can we take back? VMs off or idle all month, VMs bigger than they use, old snapshots, and disk files no VM uses.
- Where is the space going? Which VMs grew each datastore, and how much of it was new VMs.
It all appears on a Capacity tab, in the daily inventory reports, in a monthly one-page summary you can email to a manager or client, and as runway alerts through your usual notifications.
Capacity planning is paid (Business and MSP, and the 30-day trial). Ferrule keeps the history it needs on every edition, so forecasts start from everything it has collected the day a license is added.
The pages¶
| Page | What's on it |
|---|---|
| The Capacity tab | Reading the table and the charts |
| How forecasts work | What's measured, how the trend is fitted, why a date can be "needs more history", spare hosts, Ceph, thin provisioning |
| Planning: how many fit, and what if | Fitting VMs, adding and losing hosts, moving VMs, adding disks |
| Adding a host: the rack check | Switch ports, optics, VLANs, BMC, UPS, PDU, rack units, addresses, licenses; reserved ports and racks |
| Reclaim and right-size | Idle and oversized VMs, old snapshots, orphaned disks |
| Storage and backups | Where growth comes from, backup retention and deduplication, pool layouts |
| Reports and the monthly summary | Inventory sheets, reporting-database tables, the monthly email |
| Settings | Thresholds, spare hosts, allocation ratios, the VM size, the summary, racks; every variable |
| Alerts, metrics and the API | Alert keys, metric names, endpoints, the files on the volume |
| Questions and troubleshooting | Blank rows, ? lines, privileges, and what to check |
What you need¶
Capacity planning reads what Ferrule already watches. The more it watches, the more it can say.
| To get | You need |
|---|---|
| CPU and memory forecasts | vCenter or Proxmox VE |
| Datastore and pool forecasts | vCenter or Proxmox VE (Ceph included) |
| NAS volume forecasts, and the add-disks what-if | Synology, QNAP or TrueNAS |
| Backup store forecasts with retention | Proxmox Backup Server |
| Allocation (vCPUs, VM memory, provisioned disk), right-sizing, orphaned disks, storage growth | The daily inventory, which is paid and on by default |
| The rack check's switch ports, VLANs and optics | UniFi switches, or SNMP switches |
| Its BMC port and the host's power draw | Redfish on the host's BMC |
| Its UPS line | A UPS, and the rack's UPS on Settings |
| Its PDU line | A metered PDU whose outlets are named for the hosts |
| Its rack units | NetBox, or a rack on Settings |
| Its free addresses | phpIPAM or NetBox |
| Its license line | vCenter, with the Licenses privilege |
| The monthly email | Email set up for alerts (SMTP_HOST, SMTP_FROM) |
Nothing here needs a database. Everything is kept in files on Ferrule's own volume. The reporting database is optional, for Power BI or Grafana.
What to expect, and when¶
Capacity planning gets more useful as history builds up. You don't need to do anything but wait.
| When | What works |
|---|---|
| The first poll | The tab lists everything, with use now. How many more fit, every what-if, the add-disks what-if and the rack check work straight away. |
| The first inventory (02:30 by default, or Take inventory now) | Allocation figures; orphaned disks; the rack check learns each host's NICs. |
| At once, from old inventories | On its first start, Ferrule reads back every inventory it already holds, so disk and allocation history goes back as far as they do. |
| One week | Storage growth, once two inventories are a week apart. |
| Three weeks | Forecasts get dates. Runway alerts start. Reclaim and right-size judge each VM with 21 days of history. |
| Four weeks | The weekly cycle is learned, so a busy Monday isn't read as growth. |
| The 1st of each month | The monthly summary is emailed. |
Why three weeks?
A forecast from a few days of data is a guess, and a guess that a cluster fills next Tuesday is worse than no forecast. Until a row has 21 days behind it, it says how many more it needs.
Watch out for¶
- Capacity changes reset a forecast. Add a host, grow a datastore or replace disks and the trend restarts from that day, so that row needs three weeks again. That's deliberate: the old trend described different hardware.
- Forecasts describe the past continuing. A migration you've planned for next month isn't in the history; use What if for that.
- Ferrule changes nothing. Every suggestion is for you to act on.