4. HPE计算平台容量规划基础
容量规划不是“等资源不够了再买机器”，而是一套以业务需求为输入、以资源数据为依据、以模型推演为手段、以工具平台为支撑的持续闭环过程。它的核心目标是回答三个问题：当前资源够不够用、未来什么时候会不够用、以什么方式补足最经济。本章围绕容量规划流程、业务需求收集与预测、资源利用率监控、容量模型构建，以及 HPE Capacity Advisor 与 InfoSight 两类工具展开。
一、容量规划流程：从业务目标到资源决策
一个可落地的容量规划流程通常包含六个环节：明确服务目标、收集业务需求、采集资源数据、建立容量模型、生成并比较方案、执行与复盘。它与单纯的“监控告警”最大的区别在于向前看：监控回答“现在怎么样”，容量规划回答“三个月后、十二个月后会怎么样”。
流程的起点是服务目标，例如“核心交易系统工作日 9:00–11:00 平均响应时间不超过 200 ms，峰值不超过 500 ms”。这个目标决定了后续所有指标的阈值口径。若目标缺失，容量规划就会退化为“CPU 不超过 80%”这类与业务无关的经验规则，容易在低负载系统上过度采购，在高价值系统上却仍然出现瓶颈。
流程的终点不是一份采购清单，而是决策依据：在给定预算与风险偏好下，选择扩容、优化、迁移还是重构。执行后必须回到监控数据，验证预测是否准确，并修正模型参数，形成闭环。
二、业务需求收集与预测
业务需求收集要避免只问“你们需要多少 CPU”。更有效的做法是收集可换算为资源量的业务量指标：日活用户数、订单笔数、并发会话数、批处理窗口时长、数据日增量、报表生成频率等。以某订单系统为例，业务方给出“日均订单 80 万笔，大促日峰值是日均的 6 倍，每笔订单平均产生 12 次数据库交互”。据此可估算峰值 TPS：800000×6÷(高峰 4 小时×3600 秒)≈333 TPS，再乘以每笔交互次数，得到数据库层约 4000 次/秒的请求压力。这个数字才是容量模型的输入。
预测方法上，常用三类：趋势外推（按历史复合增长率延伸，适合稳定增长业务）、驱动因子法（资源量 = 业务量 × 单位业务资源消耗，适合有明确业务指标的系统）、场景法（针对大促、月末结账、版本上线等事件单独建模）。实际工作中通常三者结合：基线用趋势外推，弹性部分用场景法叠加。
三、资源利用率监控：采集什么、怎么看
监控数据是容量模型的燃料。需要采集的维度至少包括：CPU 使用率（区分用户态/系统态/等待）、内存使用率与换页情况、磁盘 IOPS 与吞吐、存储容量与增长速率、网络带宽与丢包、以及虚拟化层的 vCPU 就绪时间与内存气球回收。仅看“平均 CPU 使用率”是危险的：一台日均 20% 的服务器，可能在每天 10:00–10:15 出现 95% 的尖峰，而业务故障恰恰发生在尖峰期。
因此监控要同时保留均值、P95/P99 分位值、峰值三个口径。容量判断通常以 P95 或业务高峰时段的峰值为准，均值只用于观察长期趋势。采样粒度建议不高于 5 分钟，保留周期至少覆盖一个完整的业务周期（如一年，以捕捉季节性）。
| 指标 | 采集口径 | 容量判断用途 |
|---|---|---|
| CPU 使用率 | 5 分钟均值 + 高峰 P95 | 计算剩余计算余量，判断是否需要加核 |
| 内存使用率 | 已用/总量，含缓存与换页 | 识别内存泄漏与超分风险 |
| 磁盘 IOPS/时延 | 读写分开，关注 P99 时延 | 判断存储层是否成为瓶颈 |
| 存储容量 | 日增量与剩余可用天数 | 预测容量耗尽时间点 |
| 网络带宽 | 入/出方向峰值利用率 | 判断链路与交换机端口余量 |
四、容量模型构建
容量模型的本质是把“业务量”映射为“资源量”，并叠加冗余与安全余量。一个常用的简化模型为：
所需资源量 = 业务峰值量 × 单位业务资源消耗 × 冗余系数 × 安全余量
示例（计算节点）：
峰值 TPS = 333
单节点可承载 TPS = 120（实测压测得出）
冗余系数 = 1.5（N+1 且预留故障切换能力）
安全余量 = 1.2（应对突发与预测偏差）
所需节点数 = ceil(333 × 1.5 × 1.2 ÷ 120) = ceil(4.995) = 5 台模型中的“单节点可承载量”必须来自压测或历史实测，而不是厂商标称值。厂商标称的峰值性能通常在理想条件下取得，实际业务因锁竞争、GC、IO 等待等因素会明显下降。模型建好后要做敏感性分析：若增长率从 15% 变为 25%，或单机承载下降 20%，结论是否改变？如果结论对某个参数高度敏感，就应优先去核实该参数。
五、HPE 容量规划工具
HPE Capacity Advisor 面向单机与虚拟化环境的容量建模与推演。它通过采集一段时间的历史资源数据，建立服务器与虚拟机的资源画像，然后支持“假设分析”：例如模拟把 8 台物理机上的虚拟机整合到 5 台，观察目标主机的 CPU、内存、IO 是否超限，并给出整合前后的资源对比。它的价值在于把“拍脑袋整合”变成可量化验证的方案，尤其适合虚拟化整合、机房搬迁、硬件更新换代前的评估。
HPE InfoSight 则是基于遥测数据的云端智能分析平台，覆盖服务器、存储与部分网络设备。它持续收集设备遥测，利用跨客户的聚合数据与机器学习模型，提供容量趋势预测、性能异常检测和风险预警。与 Capacity Advisor 的“离线建模推演”不同，InfoSight 更偏向在线持续观测与提前预警：例如预测某存储卷将在 45 天后达到容量阈值，或识别出某主机 IO 时延偏离同类设备的正常基线。
六、落地要点
- 先定义服务目标，再谈资源阈值；没有业务口径的容量规划无法判断“够不够”。
- 业务需求要换算成可计算的资源量，并给出乐观/中性/悲观三种预测区间。
- 监控同时保留均值、P95/P99 与峰值，采样粒度不高于 5 分钟，保留周期覆盖完整业务周期。
- 模型中的单机承载量必须来自压测或实测，并做敏感性分析。
- 用 InfoSight 做持续趋势与异常预警，用 Capacity Advisor 做方案推演，执行后回填数据修正模型。
容量规划的质量最终体现在预测偏差上。建议每次扩容或优化后，记录“预测值 vs 实际值”，持续修正增长率与单机承载系数。经过两到三个周期的迭代，模型精度会显著提升，容量决策也会从经验判断转向数据驱动。