4. 虚拟化业务存储需求分析

虚拟化业务存储需求分析的目标，是把“业务要跑多少虚拟机、跑什么负载、能接受多慢、容量怎么涨、必须达到什么服务水平”翻译成可量化的存储指标。只有这些指标明确后，Pure Storage 阵列的型号选择、卷/数据存储布局、QoS 策略、快照与复制策略才有依据。本节围绕虚拟机密度、IOPS 与吞吐量、延迟敏感度、容量增长模型和 SLA 定义五个维度展开，并给出可落地的估算与判断方法。

一、虚拟机密度：从资源占用到存储压力

虚拟机密度通常指单台 ESXi 主机或单个数据存储上承载的虚拟机数量。它直接决定存储侧的并发压力：每台虚拟机在运行态会产生操作系统盘读写、日志写入、临时文件、页面文件以及应用自身的 I/O。密度越高，存储的并发队列、IOPS 和元数据操作压力越大。

估算密度时，不能只看 CPU 和内存的整合比，还要看存储侧的“每虚拟机平均 IOPS”和“峰值 IOPS”。例如，一个典型办公虚拟机的稳态负载可能只有 10～30 IOPS，但登录、补丁、杀毒扫描时可能瞬时达到 200～500 IOPS；数据库或中间件虚拟机则可能长期维持在数千 IOPS。因此，密度规划应使用“稳态均值 + 峰值叠加”的方式，而不是简单平均。

一个可用的估算方法是：先按业务分组统计虚拟机数量，再为每组设定每虚拟机稳态 IOPS 和峰值 IOPS，最后计算数据存储的总需求。示例：某集群有 300 台办公虚拟机，稳态 20 IOPS/台，峰值 300 IOPS/台；另有 40 台数据库虚拟机，稳态 800 IOPS/台，峰值 3000 IOPS/台。则稳态总 IOPS 约为 300×20 + 40×800 = 38000 IOPS；峰值若同时发生，约为 300×300 + 40×3000 = 210000 IOPS。实际规划中通常按峰值的一定比例（如 60%～80%）做容量与性能预留，避免所有虚拟机同时达到峰值造成过设计。

二、IOPS 与吞吐量：区分小块随机与大块顺序

IOPS 和吞吐量是两种不同的压力维度。IOPS 关注单位时间内的 I/O 次数，适合描述小块随机读写，如数据库事务、虚拟机系统盘、元数据操作；吞吐量关注单位时间内的数据量，适合描述大块顺序读写，如备份、日志归档、视频流、大数据扫描。两者不能互相替代：一块 4KB 随机读达到 100000 IOPS，吞吐量只有约 400MB/s；而 1MB 顺序读达到 2000 IOPS，吞吐量可达 2GB/s。

在 Pure Storage 全闪存阵列中，IOPS 和吞吐量通常可以同时保持较高水平，但仍需关注协议层和网络层的限制。例如，iSCSI 或 NVMe over Fabrics 的链路带宽、交换机端口速率、HBA 队列深度都会影响实际可达性能。需求分析时应分别给出 IOPS 目标、吞吐量目标以及读写比例，并注明数据块大小。常见做法是：数据库类负载以 8KB～16KB 随机读写为主，备份类负载以 256KB～1MB 顺序写为主，虚拟桌面类负载以 4KB～8KB 随机读写为主。

三、延迟敏感度：平均延迟之外更要看尾延迟

延迟敏感度决定存储系统在压力下的响应质量。虚拟化环境中，延迟通常分为平均延迟、P95 和 P99 尾延迟。平均延迟容易被大量快速 I/O 拉低，掩盖少数慢请求；而数据库提交、虚拟桌面登录、交易类应用往往对 P99 更敏感。例如，某数据库虚拟机平均读延迟 0.5ms，但 P99 达到 8ms，仍可能导致应用超时。

需求分析时应为不同业务等级设定延迟阈值。示例：核心数据库要求平均读延迟 ≤1ms、P99 ≤5ms；一般业务虚拟机要求平均 ≤3ms、P99 ≤15ms；备份与归档可放宽到平均 ≤10ms。Pure Storage 阵列可通过 QoS 策略限制低优先级负载的 IOPS 和带宽，避免其抢占核心业务资源。同时要关注队列深度：当队列深度持续升高而 IOPS 不再增长时，说明已接近性能拐点，延迟会快速上升。

四、容量增长模型：从当前用量到未来采购

容量增长模型用于回答“现在需要多少、未来何时扩容”。基本公式为：未来容量 = 当前有效容量 × (1 + 年增长率)^年数。但虚拟化场景还需叠加快照、精简配置、副本、预留和冗余开销。例如，当前有效数据 80TB，年增长 25%，计划覆盖 3 年，则纯数据增长为 80×(1.25)^3 ≈ 156TB；若快照保留占 20%、精简配置超配系数 1.3、RAID 与系统预留 15%，则规划容量约为 156×1.2×1.3×1.15 ≈ 280TB。该结果属于示例估算，实际应以阵列实测和业务确认值为准。

建议按季度记录已用容量、增长量和快照占用，形成趋势线。当剩余可用容量低于 20% 或预计 6 个月内触及 80% 水位时，启动扩容评估。Pure Storage 的 Evergreen 架构支持在线扩容和不中断升级，但仍需提前规划控制器与容量包的匹配。

五、SLA 定义：把业务语言转成可验收指标

SLA 应覆盖可用性、性能、容量和恢复四个维度。可用性可定义为 99.9% 或 99.99%，并明确统计周期和排除条件；性能应写明 IOPS、吞吐量和延迟阈值及其测量点；容量应写明有效容量、增长率和告警水位；恢复应写明 RPO（恢复点目标）和 RTO（恢复时间目标）。例如，核心交易系统 SLA 可定义为：可用性 99.99%，P99 读延迟 ≤5ms，RPO ≤15 分钟，RTO ≤30 分钟；一般业务系统可放宽为可用性 99.9%，P99 ≤15ms，RPO ≤4 小时，RTO ≤4 小时。

六、需求分析交付示例

下表给出一个可直接参考的需求分析表结构，字段可根据项目裁剪。表中数据为教学示例，不代表真实实测结果。

完成上述分析后，应输出一份需求基线文档，至少包含：各业务分组的虚拟机密度与性能参数、总 IOPS 与吞吐量、延迟阈值、容量增长预测、SLA 指标及验收方式。该基线将直接指导后续的 Pure Storage 阵列选型、数据存储设计、QoS 策略和监控告警配置。需求分析不是一次性工作，建议每季度复核一次，随业务变化更新参数，确保存储系统始终与业务目标匹配。