100 clusters totalling 502 nodes (drawn around 5, 3 to 7) x 8 vCPU
4016 vCPU
Mean demand
4016 vCPU x 15.0% estate average utilization (per-cluster 0.5% to 27.4%, sd 5.2%)
602 vCPU
Aggregate peak
602.4 vCPU x (1 + (2.23 - 1) / sqrt(100)), a pooled peak-to-mean of 1.123
676 vCPU
Consolidated, sized once for the peak
max(3, ceil(676.4 vCPU / (8 vCPU x 37.5% target))) = max(3, ceil(225.46)); the mean sits well under that peak
226 nodes, averaging 33.3%
Auto-scaled through the day
the pool follows the pooled curve in whole nodes, 30 minutes behind it, holding its size for 2 hours before shrinking
204 nodes on average, at 36.9% CPU
Utilization across the day
33.7% to 38.5% against a 37.5% setpoint: the pool runs hot while it's a bucket behind a rise, and cool while the cooldown is still holding capacity after a peak
33.7%-38.5%
Assumptions
8 vCPU per node. Standalone clusters are drawn around 5 nodes, snapped to an odd number for quorum and held between 3 and 15; in this estate they run 3 to 7, a 0.7-node standard deviation, for 502 nodes in total.
Each standalone cluster's CPU is a draw from a normal distribution centred on 15.0% and held between 0% and 100%; in this estate they run 0.5% to 27.4%, a 5.2-point standard deviation. The published band is 10-15% today against a 30-45% auto-scaled target, and this Private Host Cluster is set to 37.5%.
The Private Host Cluster floors at 3 nodes and must reach 226 at peak.
The auto-scaler sizes for what it saw 30 minutes ago and waits 2 hours before shrinking, so the pool averages 36.9% rather than sitting on its 37.5% setpoint.
Workloads are independent; consolidation moves where work runs, not how much there is.
What a virtual cluster gives an app team
Its own connection string, databases, schemas, users, roles and backups, and no visibility into the Private Host Cluster or any other virtual cluster.
