容量规划应以真实业务负载的实测数据为基础，预留至少30%的计算与存储性能余量，选择单节点级的细粒度扩展方式，并验证高使用率下的性能衰减与故障恢复行为，避免将理论容量直接等同于可用容量。
选型该看什么
-
计算与存储资源的配比灵活性
多数业务在增长过程中，计算（CPU、内存）与存储容量的消耗曲线并不平行。如果平台只能按固定的资源比例（例如每增加一定数量的硬盘必须配齐对应的计算节点）进行扩展，就容易在后期出现一类资源严重富余而另一类资源紧缺。评估时应确认系统能否支持存储节点和计算节点的独立添加，或者是否允许在同一集群内混合使用计算密集型与存储密集型的节点。对资源配比固定但单节点扩展能力完整的方案，也可以通过采购不同配置的节点，分批次调整总体比例，这种做法也是可以接受的。 -
最小扩展粒度与混合扩展能力
扩容的最小单位直接影响资源规划的精确度和初期投资规模。如果只能以多个节点组成的固定机框或设备组为最小单元进行添加，小规模扩展时就会产生大量资源闲置。需要检查平台是否允许一次只增加一个节点，以及是否可以将不同CPU代次、不同内存容量、不同磁盘规格的节点纳入同一个集群，而不强制要求设备型号完全一致。对于不允许同一集群内混用多种硬件代次的系统，只要能够通过划分独立集群并将它们纳入统一管理界面来调度，也是一种可接受的替代方式。 -
数据保护机制带来的实际容量损耗
超融合会采用多副本或纠删码来应对节点或磁盘故障，这两种机制对裸容量的消耗差异很大。多副本的实际可用容量大致为裸容量除以副本数量（例如三副本的利用率约33%），纠删码能以更低的冗余比例获得更高的有效容量，但会增加计算开销并可能延长数据重建时间。容量规划时必须基于选定的数据保护策略，准确计算实际可供给业务的容量，同时还要为快照、克隆、元数据等内部操作留出空间。对备份、归档这类非性能关键数据采用纠删码，而在核心交易数据库上保留多副本并额外预留更多容量，是行业常见的折中做法。 -
集群规模增长时的性能衰减曲线
分布式系统随着节点数量增加，跨节点元数据操作、东西向网络流量和IO路径的延迟可能会逐渐上升，出现某种“拐点”。应当了解目标平台在你们预期节点数量范围内（例如从5个节点到未来可能达到的20个节点）的性能波动趋势，以及重均衡、数据重建等后台任务对前台业务性能的影响强度。对于核心业务，需要要求性能下降曲线尽量平滑，并且通过容量余量来减少因使用率过高而频繁触发的全局重分布任务。如果业务之间能够用QoS策略严格隔离，后台干扰对前台影响被控制在很低的范围内，那么即使有一定程度的管理开销也是可以接受的。 -
故障域与资源预留机制
日常运行中，节点会因故障、升级或维护暂时退出集群。需要明确平台是如何处理临时离线和永久故障的：数据重建的并发度如何、能否控制重建速度、重建期间对业务IO的干扰有多大。通常建议在整体容量和性能上采用不低于N+1的预留策略，也就是至少保留一个节点故障时，集群仍有足够的资源支撑所有业务正常工作，且不触发保护性的写入降级或禁止写入。除了物理上的资源预留，通过严格的容量告警阈值和自动暂停非关键写入的机制，亦能起到类似的保护作用，不算是一种错误设计。 -
后台服务对业务IO的带宽抢占
重均衡、数据校验、碎片整理、垃圾回收等后台操作不可避免地会占用磁盘和网络带宽。需要验证平台能否在业务高峰时段自动限制这些任务的资源使用量，或者将其调度到指定的低峰时间窗口执行。同时，应关注在高容量利用率（例如超过70%）下，这些任务完成一次周期循环所需的时间，避免因后台任务堆积太久而影响后续扩容或恢复操作。如果业务天然存在明确且规律的低峰期（例如每天深夜），依赖手动安排或固定维护窗口来执行这些任务，也是一种成熟的使用方式。
怎么在 POC 验证
使用至少5个节点搭建测试环境，导入来自生产环境采样得到的真实IO模型（包括读写比例、块大小、工作集大小和并发数）。从10%容量开始逐步填充到70%，记录延迟、IOPS和吞吐量的变化趋势，重点观察95分位及99分位延迟是否出现非线性的恶化。
模拟意外故障：直接强制关闭其中一个节点，详细记录集群检测到故障的时间、数据重建启动耗时、重建过程中的业务性能变化（尤其是延迟峰谷）以及重建完成后的性能恢复水平。反复执行至少3次，确认行为稳定且可预测。
将集群容量使用率推进到85%甚至90%，在如此高的利用率下执行卷扩容、创建快照和克隆等常规运维操作，验证是否仍能成功且响应时间在可接受范围内，同时确认告警和保护机制（例如拒绝写入）是否按预期触发。
如果未来规划了异构节点混部，应当在POC中加入一批不同硬件配置的节点，让数据发生重均衡，然后再次运行性能测试，判断新旧节点之间的性能偏离是否会被系统放大。
最后，执行不少于72小时的连续稳态负载测试，观察内存消耗、磁盘碎片增长以及延迟的长期漂移，确保没有缓慢的资源泄漏或性能衰减。
选型建议
要求平台支持单节点粒度扩展，允许计算与存储资源独立调配，并具备明确的数据保护模式选择能力；容量规划时需要供应商提供在不同保护策略下的实际可用容量计算模型和对应的性能约束阈值，且在POC中必须覆盖70%负载下的故障模拟与85%容量下的稳态操作测试。
可接受的不同做法
对于难以独立扩展计算或存储的系统，如果能够给出清晰且经过核对的历史资源增长比，证明固定比例在至少3年内不会造成严重资源浪费，则也可以选用。对于扩容粒度较大（例如只能整机框添加）的方案，可将框内资源富余部分计入成本，并评估长期平均利用率是否在财务可接受范围内。数据保护方面，如果核心业务已有外部备份和容灾手段，选择不做额外系统级冗余的架构是可以接受的，前提是清晰理解故障窗口和数据丢失风险。对于性能曲线不是完全线性增长的平台，只要衰减幅度在产品规格书承诺的范围内，并且在POC中验证了极限负载仍满足需求，就不算缺陷。关于故障预留，基于软件的快速迁移和动态资源回收机制，若经过充分测试证明其故障恢复时间能满足业务RTO，同样可以作为物理预留的替代方案。对于后台任务始终占用固定资源量的设计，只要在业务全量负载测试中确认IO延迟仍未突破业务忍受上限，就可以视为适用。
常见问题
Q：扩容时，是不是所有节点都必须保持硬件配置一模一样？
A：不一定。如今许多超融合软件允许同一集群内混合不同CPU代次、不同内存容量和不同磁盘类型，但通常会引入一些约束，例如新节点的整体性能不应大幅低于原有节点，以免严重拖累整个集群的分布式处理效率。有些系统会通过标签或资源降级策略将较慢的节点隔离给低负载业务。如果不能接受任何性能不一致，也可以在新建集群中统一硬件，通过管理平台进行跨集群的全局调度。
Q：容量规划时预留多少性能与空间才算安全？
A：通常建议在预估峰值资源需求的基础上预留30%以上的计算和存储性能余量，以应对突发流量、单节点故障、后台维护任务等叠加场景。对于有明确周期性且突发量可控的企业稳态业务，20%的余量可能足够；而电商促销、金融等具有显著波峰的业务，应按照过往波峰数据的1.5倍以上进行规划。任何预留值都必须通过注入故障场景的压力测试来验证。
Q：原有集中式存储阵列的剩余容量，能不能直接融入超融合作为一部分容量？
A：可以，但是需要区别对待。如果旧存储仍在其生命周期内，比较稳妥的做法是将它作为备份、归档或者低性能测试数据的存放目标，而不作为核心业务实时IO的承载层。某些超融合平台确实支持通过存储网关或外部存储接入，把原有阵列的LUN呈现给虚拟化层，但其增加的额外网络跳数和延迟可能对事务型数据库不友好。建议在POC中实测这种混合架构的延迟和带宽，确保满足关键业务的SLA，且日常运维的复杂度在可承受范围内。