算一遍：Ceph 集群容量规划
给定裸盘配置，算出真正能用的容量 —— 交互计算器边调边看。
学完这节你能做到
- 独立完成一次从裸容量到可用容量的推算
- 解释 TB 与 TiB、水位线、冗余开销各吃掉多少
- 判断给定节点数下哪些 EC 方案可选
客户问"1PB 要多少钱"，你该先算什么
采购一套 Ceph 集群，最先要回答的问题是：买多少块盘，才能真正给业务交付 1PB 可用空间？
新人常见的算法是 1PB ÷ 单盘容量，然后被现实教育三次：
- 厂商标称的 TB 是十进制，操作系统显示的 TiB 是二进制，这里先蒸发 9%
- 3 副本要存三份，这里再蒸发 67%
- 集群不能写满，水位得留，这里再蒸发 15%
三刀砍下来，1PB 可用需要采购约 4PB 裸盘。这个数字必须在报价前就算清楚，否则项目一开始就注定超支。
第一刀：TB 与 TiB
1 TB = 1,000,000,000,000 字节（厂商口径，十进制）
1 TiB = 1,099,511,627,776 字节（系统口径，二进制）
1 TB = 0.909 TiB
买一块标称 7.68TB 的盘，系统里看到的是约 6.98 TiB。规划表里必须标明用的是哪个口径——这是最容易引发扯皮的地方，客户看到验收时容量"少了"，往往就是这一刀没提前说清。
业务方谈需求习惯用 TB，硬件报价用 TB，但监控系统、df、ceph df 全部显示 TiB。规划文档建议两个口径都写：采购按 TB，交付承诺按 TiB。storplan 的规划结果也是这个处理方式。
第二刀：冗余开销
这一刀在上一阶段已经算过：
3 副本 → 效率 33.3%
EC 4+2 → 效率 66.7%
EC 8+2 → 效率 80.0%
选择不是随意的，节点数会限制可选方案。EC 8+2 需要 10 个不同主机各放一片，加上重建余量，实际要 11 台起。5 台节点的集群只能选 3 副本或 EC 4+2（且 EC 4+2 在 5 台上也是勉强）。
第三刀：水位与重建预留
Ceph 有三条水位线：
| 参数 | 默认值 | 触发后的行为 |
|---|---|---|
nearfull_ratio | 0.85 | 告警 HEALTH_WARN，提醒该扩容了 |
backfillfull_ratio | 0.90 | 停止数据回填与再平衡 |
full_ratio | 0.95 | 整个池拒绝写入，业务中断 |
注意这些比例是按单个 OSD 判定的，不是按集群平均。由于 PG 分布不可能完全均匀（标准差通常在 5% ~ 10%），当集群平均到 85% 时，最满的那块盘可能已经到 95% 了。
所以规划口径应该按 0.85 甚至 0.80 来算，而不是 0.95。
还有一项更容易被忽略：节点故障后的自愈空间。一台 12 盘的节点宕掉，它承载的数据要重新分布到其余节点上。如果没预留这部分空间，一次节点故障就会把集群推到 full。预留量大致是 1 / 节点数——5 节点集群预留 20%，20 节点集群预留 5%。这也是节点数越多越经济的原因之一。
一旦某个 OSD 触到 full_ratio，涉及它的所有池立刻拒绝写入。此时集群已经没有腾挪空间，你既不能删数据（删除也需要写元数据），也不能靠再平衡救回来——只能紧急调高 full_ratio 争取时间窗口，风险极高。容量管理的目标就是永远不要走到这一步。
交互计算器：改参数看结果
下面这个计算器把三刀串起来了。建议按顺序试这几组对比，比读文字有效得多：
- 看冗余的影响：固定 5 节点 × 12 盘 × 7.68TB，把冗余方式从 3 副本切到 EC 4+2，看可用容量怎么变，再注意警告栏说了什么
- 看节点数的影响：把节点数从 5 改到 20（其余不变），看端到端效率的变化——预留比例从 20% 降到 5%
- 看水位的影响：把满水位从 0.85 拉到 0.95，看多出来的容量，再想想值不值得承担那个风险
- 反推采购量：调整参数，让"实际可写容量"逼近 1 PiB，看看需要多少块盘
- OSD 数量
- 60 个
- 裸容量（厂商口径）
- 460.80 TB
- 裸容量（系统口径）
- 418.87 TiB
- 冗余后（3 副本）
- 139.62 TiB
- 可容忍主机故障
- 2 台
真实项目还要扣掉 BlueStore 的元数据开销（RocksDB、WAL，约占 1% ~ 3%）、PG 分布不均带来的木桶效应、以及快照和多版本占用的空间。 规划时在计算器结果上再打 90% 的折，作为对外承诺的容量。 少承诺永远比多承诺安全。
把结果写成一份配置建议
算完不是终点，产出物应该是一份能直接进采购单的表格。以"交付 1PiB 可用、块存储为主"为例：
| 项 | 取值 | 依据 |
|---|---|---|
| 存储节点数 | 8 台 | 满足 3 副本主机故障域，预留 1/8 自愈空间 |
| 每节点数据盘 | 12 × 7.68TB NVMe | 单节点 92TB 裸容量，OSD 数适中 |
| 冗余方式 | 3 副本 | 块存储为主，随机小 I/O 多，不适合 EC |
| 规划水位 | 0.80 | 留出 PG 分布不均的余量 |
| 裸容量 | 737 TB / 670 TiB | 8 × 12 × 7.68 |
| 可写容量 | 约 156 TiB | 670 × 1/3 × 0.80 × (1 − 1/8) |
| 节点配置 | 32 核 / 256GB 内存 | 每 OSD 1 核 4GB，留恢复余量 |
| 网络 | 2 × 25GbE（前后端分离） | 副本流量与客户端流量隔离 |
这正是要练的点：8 节点 × 12 盘 × 7.68TB 在 3 副本下只能给出约 156 TiB。想交付 1 PiB 可用，要么把节点数翻到 40 台以上，要么换成 EC 并接受性能取舍。 先算账，再谈方案 —— 拍着胸脯说"这套配置能给你 1PB"是新人最常见的翻车方式。用上面的计算器自己验证一遍这个结论。
采购 100 块标称 7.68TB 的盘，用 3 副本，规划水位 0.85，不考虑节点预留。可写容量约为多少？
关于 Ceph 的三条水位线，下面哪些说法正确？（多选）
同样的盘数和冗余方式，为什么 20 节点集群的端到端容量效率比 5 节点更高？
这节课的落点
- 三刀口径：TB→TiB 砍 9%，冗余按效率砍，水位与自愈预留再砍
- Ceph 水位按单 OSD 判定，规划取 0.80 ~ 0.85 而不是默认的 0.95
- 自愈预留约 1/节点数，节点越多越经济
- 计算器结果再打 90% 折作为对外承诺
- 产出物是一张能进采购单的配置表，不是一个孤零零的数字
延伸资料
- ·Storplan 容量与性能规划 ↗
- ·k8s-in-action
storage/gpfs/day-0-plan-ece.md