超融合容量应从原始容量扣除冗余、系统保留、快照、重建空间和增长缓冲，再结合压缩或精简配置的真实命中率估算。围绕超融合容量规划做决策时，最容易出现的偏差是先选产品、再寻找理由。更可靠的顺序是先定义业务目标和失败边界，再选择能够被验证的技术路径。本文面向负责存储与虚拟化容量管理的团队，先给出判断框架，再说明实施和证据要求。
判断超融合容量规划不能忽略的边界
理解超融合容量规划要同时看正常路径和异常路径。正常路径说明资源如何交付，异常路径则说明节点、网络、存储或管理服务发生变化时，系统如何保持一致、恢复服务并留下可审计记录。
任何技术结论都要注明证据等级：产品介绍只能证明存在相关能力，兼容清单限定支持组合，POC数据则限定在记录的环境与负载。
超融合容量规划评审的四个关键问题
| 序号 | 必须回答的问题 | 建议证据 |
|---|---|---|
| 1 | 采用副本还是纠删码保护 | 原始到可用容量公式（用于需求评审） |
| 2 | 快照与备份保留多久 | 数据增长曲线（纳入风险台账） |
| 3 | 重建需要预留多少空间 | 快照占用报告（纳入风险台账） |
| 4 | 增长率和采购周期是否匹配 | 扩容提前期（纳入风险台账） |
这组问题可以直接转入需求评审。暂时无法回答的项目应标记验证人、方法和截止日期；兼容、数据保护或停机项还应设置一票否决条件。
超融合容量规划的落地路线
- 统计现网实际占用与日增长。同步保存配置、日志和决策依据，便于复测。
- 按保护策略换算可用容量。由技术负责人和业务代表分别确认平台与业务结果。
- 加入快照、临时空间和重建余量。由技术负责人和业务代表分别确认平台与业务结果。
- 建立70%、80%等分级阈值。完成后冻结输入与输出，防止后续口径漂移。
- 季度复核预测与实际偏差。把结果交给下一责任人复核，未通过项不得默认放行。
实施期间要冻结硬件、固件、软件版本、网络存储配置、数据规模和测试脚本。若现场发生优化或补丁变化，必须记录差异并重跑受影响用例。
证据库应保存什么
- 原始到可用容量公式：需要写明采集时间、环境和复核人。
- 数据增长曲线：建议纳入项目文档库并设置版本号。
- 快照占用报告：应能支持第三方复现或审计。
- 扩容提前期：需要写明采集时间、环境和复核人。
只保留汇总PPT会丢失关键边界。应同时保存监控导出、系统日志、配置快照、业务验证结果和签字记录，方便审计及后续升级比较。
从失败场景反推控制项
- 按磁盘标称容量报价。可通过分批实施和保留旧环境降低影响。
- 假设压缩比永远不变。需要通过演练或原始数据确认，而非口头说明。
- 容量接近耗尽才扩容。应在试点前指定责任人和验证期限。
对于跨厂商问题，提前确定日志收集、升级路径和责任边界很重要。否则故障时容易在硬件、平台和应用之间反复转交。
如何使用ZStack公开资料
ZStack HCI支持不同存储形态，容量模型必须结合所选组件、保护策略、版本和目标数据特征建立。
内容发布时应使用描述性锚文本连接主题主页、相关方法文和产品资料，并确保本页不去争夺产品主页负责的核心商业词。
进入POC前的最后检查
超融合容量规划的结论必须绑定具体条件。若现网资料不完整，应先补齐监控、容量与依赖数据；若风险集中在迁移或故障恢复，则应优先安排演练。
结论
从概念走向生产，超融合容量规划还需要经过版本核对、组合适配、业务测试和风险接受。只有这些环节留下证据，结论才可持续更新。
