2026-09-03 三台 R730xd 换成裸机 之后，前舱几乎是空的。后舱已经钉着 6 块 Intel S4510 960G，做 ssd OSD：块、CephFS、RGW 索引都在这里。对象正文还没地方放。TrueNAS 上还有 12 块 16T，当时抽不出来。盘位必须先锁死，再谈迁数据和加缓存。下一篇才是迁 NAS：不能整池搬走：TrueNAS RAIDZ2 怎么把数据迁进 RGW。槽 10 后来怎么挂上已有 OSD，见 给 6 个旧 HDD OSD 挂槽 10，不要和这篇混。
目录
要解决什么
09-03 对照时，每台只有槽 0 系统盘和后舱槽 12/13 两块 960G。前舱 1–11 空着。09-04 凌晨（01:35–01:48）用 12 个 RBD 客户端打满 ceph-block：顺序写合计大约 388 MiB/s，4K 随机写大约 22.8k IOPS。那是 6 块 SATA SSD、三副本、多流打散之后的集群写天花板，不是「再加一块 SSD OSD 就能解决对象容量」。
对象进 ceph-objectstore.rgw.buckets.data（EC 2+1、故障域 host）。块 / 文件 / RGW 索引继续钉在 ssd。16T 只给对象，960G 不进对象池，缓存盘 不加容量、不是 OSD。怎么把 TrueNAS 上的数据迁进来是下一篇；这篇只定盘位和缓存角色。
机箱不是能插就插
每台前舱 2U，4 列 × 3 行，从左上角第一列往下编号：
0 3 6 9 1 4 7 10 2 5 8 11锁死：
| 槽 | 角色 |
|---|---|
| 0 | 系统盘（480G） |
| 1–8 | 16T 对象 hdd。现在用到槽 4，5–8 预留下一轮 |
| 9 | 以后给 ssd 池加一块 SATA SSD |
| 10 | 1.92T 缓存 #1，WAL/DB，带槽 1–4 |
| 11 | 缓存 #2，带槽 5–8；先买这块，再一次加齐 4 块 16T |
| 12–13 | 后舱 960G ssd，没有空 2.5 寸 |
16T 不要进最右列。缓存盘不要做成 OSD。 后舱两块 960G 已经占满 2.5 寸，块池要涨只换后舱更大的盘，不要占前舱。
定位只用 WWN / 序列号 / 槽号，不要用 /dev/sdX。OSD 号会换盘，认序列号。对照留在机器台账里，这篇不贴三台的盘表。
两套池，互不串盘
| 池 | crush | 冗余 | 盘 |
|---|---|---|---|
对象 rgw.buckets.data |
default~hdd |
EC 2+1、host、min_size=2 |
前舱 16T |
| 块 / CephFS / RGW 索引 | default~ssd |
replica 3、host | 后舱 960G |
EC 2+1 必须 三台同一天各加同规格 16T。只给一两台加，可用几乎不涨；故障域是 host，慢的那台拖 ACK。缓存盘出现在各 HDD 的 metadataDevice 里，不进 devices:，免得槽 9 以后的 SSD、槽 5–8 的 16T 误继承槽 10。
09-04 那次 fio 只说明一件事：6 块 960G 已经把随机写打到盘 util 83–90%，再加一块 SSD OSD 救不了对象池。对象要机械盘，而且要三台一起加。
为什么不是 cache-tier
Ceph 的 cache-tier 已经过时。对象池主要是大对象顺序写，再复制一层热数据没有意义，GET 仍然打机械盘。
槽 10 的 Samsung PM883 1.92T 只做 BlueStore 的 WAL + RocksDB，不是把对象正文缓存在 SSD 上。现网 Squid 19.2.3，HDD 的 deferred 阈值 64 KiB：
| 写什么 | 缓存盘上 | 16T 上 |
|---|---|---|
| ≤64 KiB | WAL 里整笔（日志 + 正文） | 稍后批量刷 |
| 更大的对象 | 只日志和 onode | 正文直接打机械盘 |
| GET | 查 onode 快一点 | 正文还在机械盘，几乎不改善读 |
RGW 桶索引已经在后舱 960G，不走这块盘。HDD 上 META 只有十几 GiB，960G 当 DB 也「够用」，但按官方比例偏紧。读者要分清：元数据盘 和 热数据缓存 不是一回事。
host-based lvm batch 不要写 walSizeMB：会被忽略，WAL 同住那条 DB LV，没有独立 osd-wal。
为什么买 1.92T，一刀 430 GiB
文档口径：WAL+DB 至少数据盘的大约 2.5%（更早的 RGW 常按 4%）。
16T × 2.5% ≈ 400 GB/OSD。一块盘带 4 个 OSD ≈ 1.6 TB，1.92T 刚好盖住。按 4% 要约 2.56 TB，得上 3.84T。现场按 2.5% 切：430 GiB。Rook 字段是 databaseSizeMB: "440320"（440320 MiB = 430 GiB）。
| SKU | 每 OSD DB（带 4 块） | 占 16T | 对照 |
|---|---|---|---|
| 960G | 约 210 GiB | 1.3% | 现网 META 够；低于 2.5% |
| 1.92T | 约 430 GiB | 2.7% | 贴 2.5%，就买这个 |
| 3.84T | 约 880 GiB | 5.5% | 老口径 4% 才需要 |
PM883 在 LVM 里大约 1788.5 GiB。4 × 430 GiB = 1720 GiB，切完剩约 68 GiB。不要一块切 8 刀（每 OSD 约 215 GiB，又回到 1.3%，IOPS 也不够）。不要消费级 QLC。
Rook 按盘写 metadataDevice + databaseSizeMB，不写节点全局。
一块缓存带 4 块 16T
| 盘 | 切几刀 | 带哪几块 16T |
|---|---|---|
| 槽 10 · 1.92T #1 | 4 × 430 GiB | 槽 1–4 |
| 槽 11 · 1.92T #2 | 4 × 430 GiB | 槽 5–8（先买缓存，再一次加齐） |
一块缓存坏 = 它带的 4 个 HDD OSD 一起掉，等于丢一台。EC 2+1、min_size=2 还能扛。所以缓存 只做 metadataDevice，不要做成 OSD，不要 cache-tier。
09-11 / 09-14 已经把槽 1–4 十二块 16T 都挂上槽 10。那是重建过程，这篇只定角色。
容量台阶
台阶按后来装满槽 1–4 来写；09-03 当晚每台还是 0 块 16T。现网每块 16T 在 Ceph 里大约 14.55 TiB。对象 = 每台条数 × 14.55 × 2（三台、EC 2+1）。full_ratio 0.95。缓存不加容量。块只看 ssd class。
| 阶段 | 每台 16T | 缓存 | 对象大约可用 / 95% | ssd 大约可用 / 95% |
|---|---|---|---|---|
| 现在（12 个 HDD OSD） | 4 | 槽 10 已满 4 刀 | 116 / 111 TiB | 1.75 / 1.66 TiB |
| 充足终态 | 8 | 再加槽 11 | 233 / 221 TiB | 看槽 9 |
| 不要：11×16T 填满前舱 | 11 | 没槽给缓存和 ssd 加盘 | 数字更好看 | 永远 1.75 / 1.66 |
槽 9 才给 960G 池加盘。块池 stored 大约 413 GiB，MAX AVAIL 大约 1.1 TiB；先维持后舱 960G。
加第四台：同样 8×16T + 后舱 2×960G，对象大约再涨该机机械盘 raw 的 2/3。第四台必须进现在这套 Rook 当 OSD 才算数。
下一轮不要 16T 先上、缓存后补
Rook 二次 metadataDevice 找不到 已经有 LVM 的缓存盘。槽 11 还是空盘时，三台同一天把槽 5–8 一次加齐，一次 lvm batch 切 4 刀。先加 1 块再补 3 块，会再走预切 LV + ceph-volume lvm prepare --block.db。换一块槽 1–4 的 16T 也是同一条，见 机械盘和缓存盘故障时怎么换。
顺序：remap / scrub 恢复正常 → 先买 3 块槽 11 → 再三台同一天加满槽 5–8 → ssd 池要涨再买槽 9。现在不要为了「插满」把 16T 塞进右列。