需求拆解：容量、带宽、IOPS 三条线
客户说"要 1PB 高性能存储"，这句话里缺了至少五个关键参数。
学完这节你能做到
- 列出一份完整的存储需求调研清单
- 把业务语言翻译成可计算的指标
- 识别需求中互相冲突的部分并给出取舍建议
客户说的话和你要的数字之间
真实的需求沟通通常长这样：
我们要建一套 1PB 的高性能存储，给 AI 训练用，越快越好，预算不多。
这句话里有五个词是不可计算的：1PB（哪个口径？可用还是裸？）、高性能（带宽还是 IOPS？）、AI 训练（什么规模的数据集？多少并发？）、越快越好（没有目标就没有验收标准）、预算不多（不多是多少）。
需求拆解的工作，就是把这五个词换成数字。
三条线：容量、带宽、IOPS
任何存储需求最终都落到这三条线上，而且它们经常互相冲突。
容量线：要存多少数据，增长多快
带宽线：每秒要搬多少数据（大文件顺序读写）
IOPS 线：每秒要处理多少次操作（小文件、随机、元数据）
冲突的典型例子：为了容量选大盘、选 EC，结果 IOPS 和重建时间双双恶化；为了 IOPS 选小盘、选副本，结果每 TB 成本翻三倍。
你的工作不是同时满足三条线，而是搞清楚哪条线是真需求，哪条线可以让步。
需求调研清单
带着这张表去和业务方谈，比问"你们要什么存储"有效得多。
容量
| 问题 | 为什么问 |
|---|---|
| 需要多少可用容量？TB 还是 TiB？ | 避免验收时的口径争议 |
| 当前已有多少数据？ | 判断是新建还是迁移 |
| 每月增长多少？ | 决定扩容节奏和预留 |
| 数据保留多久？有没有归档/删除策略？ | 有生命周期就能少买盘 |
| 需要快照吗？保留几份？ | 快照要额外占空间 |
性能
| 问题 | 为什么问 |
|---|---|
| 峰值还是均值？峰值持续多久？ | 按均值配会在峰值挂掉 |
| 读写比例大概是多少？ | 写比读贵得多（副本放大） |
| 平均文件/对象大小？ | 决定是带宽型还是 IOPS 型负载 |
| 并发客户端数量？每个客户端多少线程？ | 并发不够时后端再强也跑不满 |
| 能接受的延迟上限？P99 还是平均？ | 延迟敏感型要放弃 EC |
可用性
| 问题 | 为什么问 |
|---|---|
| 能容忍多久的不可用？ | 决定冗余级别和故障域 |
| 单机架、单机房够吗？ | 决定 CRUSH 层级 |
| 需要异地容灾吗？RPO / RTO 是多少？ | 决定是否需要多站点复制 |
| 有没有合规要求（加密、审计、留存期）？ | 影响方案选型 |
"如果这套存储挂了 4 小时，业务会发生什么？"
这个问题能把对方从"当然要最高可用"拉回现实。如果答案是"没什么影响，任务重跑就行"，那你可以省下一大笔钱在冗余和容灾上；如果答案是"生产线停摆，每小时损失百万"，那预算讨论的基调就完全不同。
从业务语言到可计算指标
几个常见场景的翻译示例：
场景一：AI 训练
业务说：训练 100 张卡的大模型，数据集 200TB，训练慢了 GPU 就闲着
翻译：
- 容量：200TB 数据集 + checkpoint（每次几百 GB × 保留 N 份）+ 增长
- 带宽：100 张 GPU × 每卡约 1~2 GB/s 读 = 100~200 GB/s 峰值读
- IOPS：如果数据集是海量小图片，元数据操作会是主要压力
- 关键结论：这是典型的高带宽 + 高元数据 IOPS 场景
→ CephFS 不合适（元数据缓存瓶颈），应看 GPFS / Weka / VastData
场景二：虚拟机 / 数据库
业务说：跑 200 台虚拟机，每台 100GB 系统盘，还有几个 MySQL 实例
翻译：
- 容量：200 × 100GB = 20TB（薄分配的话实际占用更少）
- IOPS：随机 4K 为主，按每虚拟机 200 IOPS 估 → 4 万 IOPS
- 延迟：数据库对延迟敏感，P99 要控制在几毫秒
- 关键结论：块存储 + 副本 + 全闪，不要 EC
场景三：备份归档
业务说：存历史数据，很少读，越便宜越好
翻译：
- 容量：主需求，且增长可预测
- 带宽：只在备份窗口内需要，比如每晚 4 小时写 20TB → 1.4 GB/s
- IOPS：几乎不需要
- 关键结论：对象存储 + EC + 大容量盘，这是 EC 的理想场景
"每天写入 20TB"听起来是 240 MB/s，很轻松。但如果这 20TB 集中在凌晨 2 点到 4 点的备份窗口里写完，实际需求是 2.8 GB/s——差了十倍。
永远要问：这个量是在多长时间内产生的。
增长预测与扩容节奏
第 1 年需求 = 当前数据量 + 12 个月增长 + 冗余开销 + 水位预留
但不要一次买满三年。理由：
- 硬件在降价，晚买更便宜
- 盘从上架那天就开始老化，闲置的盘也在损耗质保期
- 需求预测的误差随时间放大
推荐节奏：首期按 12~18 个月规划，预留扩容能力（机位、网口、交换机端口），之后按季度复盘增长曲线滚动扩容。
最尴尬的情况：容量该扩了，但机柜没位置、交换机没端口、或者当初买的机型已经停产。
首期规划时就要明确：
- 机柜还剩多少 U 和多少电
- 接入交换机还剩多少口
- 选型的机型和盘型至少还能采购多久
- 集群规模上限是多少（受 MON、网络架构限制）
输出物：一份需求确认单
调研完要落成书面文档，双方签字确认。这不是官僚流程，而是保护双方——没有白纸黑字，验收时就会变成扯皮。
## 存储需求确认单
| 项 | 确认值 | 备注 |
| --- | --- | --- |
| 可用容量 | 500 TiB（系统口径） | 不含冗余，按 0.80 水位计 |
| 年增长 | 约 30% | 按季度复盘 |
| 峰值读带宽 | 40 GB/s（持续 2 小时） | 训练任务启动时 |
| 峰值写带宽 | 8 GB/s | checkpoint 写入 |
| 随机 IOPS | 未明确要求 | 以带宽为主 |
| P99 延迟 | 无硬性要求 | |
| 可用性 | 允许每年 4 小时计划内停机 | 不要求异地容灾 |
| 故障域 | 主机级 | 单机房 |
| 协议 | POSIX 文件系统 + S3 | |业务方说「每天写入 30TB 数据」。规划带宽时下一个必须问的问题是？
某 AI 训练场景：数据集是 3000 万张小图片，100 张 GPU 并发读取。下面哪些判断是对的？（多选）
关于容量规划的节奏，下面哪种做法更合理？
这节课的落点
- 需求调研的产出是数字，不是形容词
- 三条线（容量 / 带宽 / IOPS）经常冲突，先分清哪条是真需求
- "挂 4 小时会怎样"是最能拉回现实的一个问题
- 峰值与均值的差别决定配置差别，永远追问时间窗口
- 平均文件大小和文件数量往往比总容量更能决定选型
- 首期按 12~18 个月规划，但扩容路径要在第一天就预留
- 需求确认单要书面化，这是验收时的唯一依据