记录一次给 6 个旧 HDD OSD 挂槽 10 缓存盘

2026-09-11 到 2026-09-14。三台 Dell R730xd：k8s-10-1-16-21（10.1.16.21）、k8s-10-1-16-22、k8s-10-1-16-23。Rook v1.17.9，Ceph Squid 19.2.3（镜像 harbor.cyxc.club/quay/ceph/ceph:v19.2.3），host-based OSD。集群 fsid 7a0e0897-87d2-41e7-9d91-02e2765a7191。SSH：ssh root@10.1.16.21、22、23。

对象池 ceph-objectstore.rgw.buckets.data：EC 2+1、故障域 host、min_size=2。块 / CephFS / RGW 索引钉在 ssd。定位硬盘只用 WWN / 序列号 / 槽号，不要用 /dev/sdX。PERC：0:0:槽:0。

下面按实际怎么做的写。命令和数字可以原样复现。改 CR 不会把已有 OSD 的 WAL/DB 搬家；removeOSDsIfOutAndSafeToRemove=false。这次没有 helm upgrade。 以后换 16T / 槽 10 见 机械盘和缓存盘故障时怎么换，不要跟这篇重建混。

目录

• 要解决什么
• 槽 10 怎么切
• 第一波：空盘能过
• 为什么旧 6 个必须删掉重建
• 6 块一起，还是 3+3
• 必须等 remap
• 时间线（CST，UTC+8）
• 第一趟 remap
• purge 和按 WWN 擦盘
• 开 operator 之后：metadata device is not found
• 社区给出的几条路
• 为什么不把槽 10 上已有 OSD 全删重建
• 做成这样才稳
• 16.21 验证
• 16.22 / 16.23
• 验证
• OSD 号已换盘
• 以后换盘还是这个问题
• 踩过的坑
• 不要做
• 还没做
• 附录：Job 骨架
• 附录：擦盘只认这 6 行

要解决什么

每台前舱 2U，4 列 × 3 行，从左上角第一列往下编号：

 0  3  6  9
 1  4  7 10
 2  5  8 11

槽 0 系统盘。槽 1–4 各一块 16T HC550，对象数据走 hdd。槽 10 是一块 Samsung PM883 1.92T SATA SSD，只当 BlueStore 的 WAL/DB，不是 OSD。背面槽 12/13 是 960G ssd。

2026-09 上旬，每台槽 1–4 已经有 4 个 HDD OSD。其中 每台 2 块是整盘 BlueStore：WAL/DB 和数据同住 16T。另外 2 块是 09-11 新加的，创建时就把 DB 放到了槽 10。

BlueStore 不会在 OSD 活着的时候把 RocksDB 从 HDD 搬到 SSD。CR 里写了 metadataDevice 也只对新创建的 OSD 生效。所以那 6 个旧 OSD 只能：out → 等 remap → purge → 擦 16T → 再做成带 block.db 的 OSD。

槽 10 怎么切

官方量级是 HDD 容量的大约 4% 给 DB；现场按 2.5% 切：16T × 2.5% ≈ 430 GiB。Rook 字段是 databaseSizeMB: "440320"（440320 MiB = 430 GiB）。

每台 4 个 HDD OSD × 430 GiB = 1720 GiB。PM883 在 LVM 里大约 1788.5 GiB，切完剩约 68 GiB。缓存 WWN 不进 devices:，只出现在各 HDD 的 metadataDevice。按盘写，不写节点全局，免得槽 9 以后的 SSD / 槽 5–8 误继承。

host-based Rook 走 ceph-volume lvm batch --db-devices。不要写 walSizeMB：会被忽略，WAL 同住那条 430 GiB DB LV，没有独立 osd-wal。helm rev 30 已经把 walSizeMB 从 CR 拿掉，当时没有重建任何 OSD。

第一波：空盘能过

2026-09-11 晚上，三台槽 10 刚擦过，还是空盘。helm rev 29 把每台剩下的 2 块 16T 加进 devices:，并给槽 1–4 都写上 metadataDevice。槽 10 当时没有 LVM 子设备，inventory 认得出这块盘，lvm batch 一次切出 2 条 430 GiB osd-db。

做成：

每台槽 10 还剩约 928 GiB，刚好够再挂 2 条 430 GiB。扩容回填结束后，对象数据已经主要在这 12 块 16T 上。10.1.16.254（原 TrueNAS）已关机，12 块 16T 都在 21/22/23，不要开机、不要把盘插回去。

为什么旧 6 个必须删掉重建

09-13 检查：那 6 个仍是 bluefs_dedicated_db=0。CR 早已写好 metadataDevice，改配置、helm upgrade、重启 OSD 都不会搬家。

要挂槽 10，只能重建。removeOSDsIfOutAndSafeToRemove 是 false，Rook 不会自动 purge。不要用 osd.rook.io/replace，也不要用 rook-ceph-purge-osd Job。

6 块一起，还是 3+3

曾想先做干净的 3 块（当时的 osd.11 / 8 / 7），避开 SMART 重分配偏高的两块。算过墙钟之后改成 6 块一起 out：

• 每台 out 2 块，数据搬到同机剩下的 2 块已挂缓存 HDD，大约每台 6.4 TiB。
• 3+3 要等两轮 remap，墙钟更长。
• 对象池 EC 2+1、min_size=2。6 个 out 之后每台还剩 2 个 HDD OSD，集群还能写。再丢一台就到 min_size，重建期间不要整机维护、不要动 N9K。

SMART attr 5（Reallocated_Sector_Ct），2026-09-13 19:48 对照 09-04/05。pending / uncorr 当晚全是 0，12 块都 PASSED。

重分配对照必须看序列号，不要看当时的 OSD 号。重建之后号换了，见下文。

必须等 remap

6 个 OSD 里有 30 个 PG 三份都在这 6 块上。out 之后 Ceph 会把它们搬到还 in 的盘。safe-to-destroy 在 remap 完成前是 EBUSY。

不要在 EBUSY 时 purge，也不要加 --force。 那 30 个 PG 会丢。等 393 个 PG 全 active+clean、没有 remapped，再 ceph osd safe-to-destroy 3 5 6 7 8 11。

时间线（CST，UTC+8）

第一趟 remap

刚 out 时 misplaced 50.6%（约 1031 万 / 2038 万 shard）。数据从每台 2 块旧盘搬到同机 2 块已挂缓存的 HDD。

墙钟约 17 小时 55 分。6 个 OSD 此时是空壳，还在 up/out。数据已经在每台剩下的 2 块 HDD 上。purge 前不要关机、不要动盘。

加大并发的命令（toolbox）：

ceph config set osd osd_mclock_profile high_recovery_ops
ceph config set osd osd_max_backfills 24

原值 balanced / 16。第二趟 remap 干净之前不要改回去。

purge 和按 WWN 擦盘

顺序：

1. kubectl -n rook-ceph scale deploy/rook-ceph-operator --replicas=0
2. scale rook-ceph-osd-{3,5,6,7,8,11} --replicas=0，等 6 个 pod 消失
3. 必要时 ceph osd down 3 5 6 7 8 11
4. 分别 ceph osd purge <id> --yes-i-really-mean-it。ceph osd tree 里没有这 6 个 ID
5. 三台各擦 2 块 16T（下一节附录）。禁止 dmsetup remove_all，禁止碰槽 10
6. kubectl delete deploy rook-ceph-osd-{3,5,6,7,8,11}。残留 prepare job 也删

擦盘：

DEV=$(readlink -f /dev/disk/by-id/wwn-0x…)
lsblk -ndo SERIAL,SIZE,MODEL "$DEV"   # 必须对上序列号
wipefs -a "$DEV"
sgdisk --zap-all "$DEV"
dd if=/dev/zero of="$DEV" bs=1M count=64 oflag=direct status=progress
partprobe "$DEV"
wipefs "$DEV"   # 应为空

不要 /dev/sdX，不要 blkdiscard，不要 ceph-volume lvm zap 槽 10。osd.6 / osd.3 当时那两块有历史重分配，擦的是分区签名，不是全盘 shred。擦完槽 10 的 VFree 仍应约 928g，已有 osd-db 还在。

开 operator 之后：metadata device is not found

擦完 16T，以为开 operator 就会按 CR 再挂槽 10。prepare 报：

metadata device /dev/disk/by-id/wwn-0x5002538e… is not found

槽 10 在第一波里已经是 LVM PV：上面有 VG，还有 2 条 430 GiB osd-db（osd.15/17、13/16、12/14 还在跑）。Rook inventory 看到有 child 的盘就跳过，WWN 进不了可用设备表。CR 里的路径于是查不到。

同一件事的下一层：手跑 ceph-volume lvm batch --db-devices 报 fast devices were passed, but none are available。ceph-volume 也把「已经有 VG 的 DB 盘」当成不可用。

这不是擦盘擦坏了，也不是 WWN 写错。空盘第一次挂槽 10 能过；往已有 VG 上再加第 3、第 4 个 OSD 就会踩。对应 Rook 源码就是 context.Devices 里找不到这块盘，然后 metadata device %s is not found。

09-14 14:34 联网搜的结论：这不是个案，Rook 自己就记着。databaseSizeMB 只影响第一次切 LV 的大小，不会让二次添加突然可用。单靠开 operator / helm 过不去。

• rook#13634：往已经占用的 LVM metadata 盘再加 OSD → 同样 metadataDevice is not found。维护者原话：ceph-volume lvm batch 第一次会把 DB 盘按当时的数据盘切满；以后再加盘时这块 DB 盘不再 available。
• rook#15220（travisn）：节点上 已经有 OSD 占用了这张 metadata 盘，再加新 OSD，目前不支持。
• rook#13240：共享 metadata 盘上换单块 OSD，Rook 还没做完。
• rook#7121 + ceph-users：手动 lvm batch 时，必须把当初那一组数据盘全部再传一遍（已做好的会 skip），只传新盘会报 none are available。
• Ceph tracker #44749：lvm batch 不会自动吃 VG 上剩余的 VFree。

社区给出的几条路

当天从表里挑，没有「改个 CR 就能接着挂」的开关。

为什么不把槽 10 上已有 OSD 全删重建

表里第一行是 Rook 官方态度：把共享这块缓存盘的 HDD OSD 全部删掉，槽 10 变回空盘，再一次 lvm batch。理论上能绕过限制。

现在只有 3 台，这条走不通。 对象池是 EC 2+1、故障域 host、min_size=2。每个 PG 已经用满三台。把一台槽 1–4 的 4 个 HDD OSD 全 out，第三份没有第四台可搬，safe-to-destroy 不会通过。若不等 remap 就 purge，等于故意丢掉这台身上那 1/3，靠另外两台做 EC 重建；全程只剩 min_size，再坏一台就丢数据。当天否决的就是这个。

机器够多时可以按官方做。 至少 4 台已经有 HDD OSD 的机，才能一台一台：out 这一台全部 HDD → 等 remap 到另外三台 → safe-to-destroy → purge → 擦槽 10 → 一次 batch 把这台 4 块 16T 建齐。一次只动一台，对象池还能放满 2+1。这是「想让 Rook 自己 batch」时才需要的路径，不是换单块 16T 的必经之路；换一块仍然用第三行（预切 LV + prepare --block.db）。

当天选定第三行：预切 LV + ceph-volume lvm prepare --data vg/lv --block.db vg/lv，然后 operator lvm list 收养。不走 lvm batch，不动已经在跑的 osd.12–17。

做成这样才稳

operator 保持 0，直到 6 块都 prepare 完。Job：

• hostIPC: true，特权，镜像 harbor.cyxc.club/quay/ceph/ceph:v19.2.3
• 不要挂宿主机 /etc/lvm（宿主机默认 udev_sync=1，容器里 lvcreate 会卡在 do_semtimedop 十几分钟）
• 不要挂整个 /run（会连上宿主机 lvmpolld，IPC 对不上）
• 挂：/dev、/run/udev、/run/lock、/var/lib/rook
• 需要 client.bootstrap-osd keyring：ceph auth get client.bootstrap-osd

每块盘：

1. 槽 10 现有 VG 上：

   lvcreate --noudevsync -y -Wn -Zn -L 440320M -n osd-db-<uuid> <slot10-vg>

   不要 -W y，否则 Failed to wipe start of new LV（udev 还没创节点）。

2. 16T 上自己做 data LV（这样 prepare 不再自己 lvcreate，也就不会再卡 udev）：

   pvcreate --yes /dev/disk/by-id/wwn-0x…   # 没有 --noudevsync
   vgcreate --yes ceph-<uuid> /dev/disk/by-id/wwn-0x…
   lvcreate --noudevsync -y -Wn -Zn -l 100%FREE -n osd-block-<uuid> <data-vg>
   dmsetup mknodes
   # 等到 /dev/<vg>/<lv> 出现

3. prepare：

   ceph-volume lvm prepare --bluestore --no-systemd \
     --crush-device-class hdd \
     --data <data-vg>/<data-lv> \
     --block.db <slot10-vg>/osd-db-<uuid>

4. 宿主机事后 pvscan --cache，否则 host pvs 暂时看不见新 PV。

开 operator 前清掉已 purge OSD 的：

/var/lib/rook/rook-ceph/<cluster-fsid>_<osd-fsid>

否则 ceph-volume raw list 会误起幽灵 deploy。

16.21 验证

先做 k8s-10-1-16-21。槽 10 VG ceph-9cd37193-a269-4cd4-9a98-8473cc0d34c7，缓存 SN S455NY0MB34106 / WWN 5002538e09b8d73f。

osd.15 / osd.17 未动。槽 10 变成 4 条 430 GiB osd-db，VFree 约 68.49g。

中间失败过一次：给槽 10 切第二条 DB LV 时用了 -W y，udev 节点没出来。改成 -Wn -Zn 后第二条做成。数据盘那次 14.55T lvcreate 在没加 hostIPC、还挂着宿主机 lvm.conf 时卡了大约 12 分钟。

开过一次 operator：raw list 扫到已 purge 的 osd.11 残留目录，差点在 2PG180HT 上再起一个幽灵 rook-ceph-osd-11，并对这块盘跑 raw activate。删掉那个 deploy，清旧 fsid 目录，operator 缩回 0。后面 22/23 开 operator 之前同样先清。

16.22 / 16.23

同一套 Job，换节点、换 WWN、换槽 10 VG，KEEP_DBS 写成该机已有的 2 条 osd-db（osd.13/16、osd.12/14），避免误用。

16.23 一次成功。16.22 第一块成功；第二块 osd new 报 entity osd.11 exists but key does not match——purge 留下了 auth。ceph auth del osd.11 后复用已经切好的 LV，做成 osd.11。

清旧 rook 目录后 operator replicas=1。Rook lvm list 收养，没有再走失败的 lvm batch。

验证

2026-09-14 14:55 起：

osd: 18 osds: 18 up, 18 in

ceph osd metadata：12 个 HDD 都是 bluefs_dedicated_db=1、bluefs_dedicated_wal=0、bluefs_db_size=430 GiB、bluefs_db_rotational=0。device_ids 里同时有对应 16T 序列号和该机槽 10 PM883。SCSI 路径 pci-0000:02:00.0-scsi-0:0:<槽>:0 与前舱槽位一致。

每台槽 10：4 条 430 GiB osd-db active，VFree 68.49g。没有独立 osd-wal。

硬认命令：

ceph osd tree
ceph osd metadata osd.7 | grep -E 'hostname|device_ids|bluefs_dedicated|bluefs_db_size'
ssh root@10.1.16.22 'pvs; lvs -o vg_name,lv_name,lv_size,lv_attr'

OSD 号已换盘

purge 之后 Ceph 复用了 3/5/6/7/8/11，但盘和号不再是原来那一对。认序列号。

未重建：2PGAK6VT=osd.15，2PGBNGKV=osd.17，2DG026YS=osd.13，2PG0KHYT=osd.16，2PG1XWJT=osd.12，2PG22LLT=osd.14。SSD 未变：21 osd.0/1，22 osd.2/4，23 osd.9/10。

以后换盘还是这个问题

这不是 09-14 擦盘留下的一次性故障。槽 10 只要还有 LVM，Rook 的 metadataDevice 就找不到这块盘。换槽 1–4 里一块 16T，会再报同一个 metadata device is not found。 槽 10 这块 PM883 坏了则是另一条：这台 4 个 HDD OSD 的 DB 一起掉，3 台上等不到 remap。

换盘不要写在这篇重建记录里跟做。完整两条流程：机械盘和缓存盘故障时怎么换。

下次若用槽 11 带槽 5–8：尽量 4 块一起加。--block-db-slots 4 只对还没切过的缓存盘有用，槽 10 已经切满，补不上。

踩过的坑

不要做

• safe-to-destroy 还是 EBUSY 就 purge / 加 --force
• 擦槽 10 / dmsetup remove_all / 动缓存 VG（osd.12–17 的 DB 在上面；重建期间它们曾是每台仅剩的 2 块）
• 用 /dev/sdX 擦盘
• 为了重建去 helm upgrade / 改 CR（配置已经对了，改了也不会搬家）
• 换一块槽 1–4 的 16T 之后指望开 operator 自动挂槽 10（还是 metadata device is not found，见 换盘）
• 把槽 10 上已有 6 个 HDD OSD 全删再 batch（当时数据全在它们身上）
• 重建期间整机维护或动交换机
• remap 没干净就改回 mclock / 开 scrub

还没做

写这篇的时候（2026-09-14 约 15:00）第二趟 remap 还在跑：158/393 active+clean，235 remapped，约 55.6% objects misplaced，回填约 450–560 MiB/s。新 6 个 OSD 刚 in，PGS 还是 0，数据会摊回去。

等 393 个 PG 全 active+clean、无 remapped 之后：

ceph config set osd osd_mclock_profile balanced
ceph config set osd osd_max_backfills 16
ceph osd unset noscrub
ceph osd unset nodeep-scrub

HEALTH_WARN 里「59 pgs not deep-scrubbed in time」是 noscrub 期间积下来的，unset 之后会自己补。

附录：Job 骨架

namespace: rook-ceph。nodeSelector、槽 10 VG、WWN、KEEP_DBS 按机替换。KEEP_DBS 必须是该机已经在跑的 osd-db 名字，prepare 前用 lvs 核对。

apiVersion: batch/v1
kind: Job
metadata:
  name: cv-prepare-<node>
  namespace: rook-ceph
spec:
  backoffLimit: 0
  activeDeadlineSeconds: 1800
  template:
    spec:
      restartPolicy: Never
      hostIPC: true
      nodeSelector:
        kubernetes.io/hostname: k8s-10-1-16-22
      containers:
        - name: cv
          image: harbor.cyxc.club/quay/ceph/ceph:v19.2.3
          securityContext:
            privileged: true
            runAsUser: 0
          env:
            - name: LVM_SUPPRESS_FD_WARNINGS
              value: "1"
            - name: PYTHONUNBUFFERED
              value: "1"
          command: ["bash", "-lc"]
          args:
            - |
              set -euo pipefail
              mkdir -p /etc/ceph /var/lib/ceph/bootstrap-osd
              cp /var/lib/rook/rook-ceph/rook-ceph.config /etc/ceph/ceph.conf
              cp /var/lib/rook/rook-ceph/client.admin.keyring \
                /etc/ceph/ceph.client.admin.keyring
              ceph --name client.admin \
                --keyring /etc/ceph/ceph.client.admin.keyring \
                auth get client.bootstrap-osd \
                -o /var/lib/ceph/bootstrap-osd/ceph.keyring
              # assert WWN + SERIAL；槽 10 VG 对得上；KEEP_DBS 仍在
              # lvcreate --noudevsync -y -Wn -Zn -L 440320M -n osd-db-… <DB_VG>
              # pvcreate --yes /dev/disk/by-id/wwn-0x…
              # vgcreate --yes ceph-… /dev/disk/by-id/wwn-0x…
              # lvcreate --noudevsync -y -Wn -Zn -l 100%FREE -n osd-block-… <DATA_VG>
              # dmsetup mknodes；等到 /dev/vg/lv 出现
              # ceph-volume lvm prepare --bluestore --no-systemd \
              #   --crush-device-class hdd \
              #   --data <DATA_VG>/<DATA_LV> \
              #   --block.db <DB_VG>/<DB_LV>
          volumeMounts:
            - {name: devices, mountPath: /dev}
            - {name: udev, mountPath: /run/udev}
            - {name: lvm-lock, mountPath: /run/lock}
            - {name: rook, mountPath: /var/lib/rook}
      volumes:
        - {name: devices, hostPath: {path: /dev}}
        - {name: udev, hostPath: {path: /run/udev}}
        - {name: lvm-lock, hostPath: {path: /run/lock}}
        - {name: rook, hostPath: {path: /var/lib/rook}}

现场用过的完整 Job 在节点操作机 /tmp/cv-prepare-21.yaml、cv-prepare-21-slot3.yaml、cv-prepare-22.yaml、cv-prepare-22-slot2.yaml、cv-prepare-23.yaml。22 第二块是 cv-prepare-22-slot2：auth 删掉之后只 prepare 已切 LV，不再 lvcreate。