TLDR：关于Ceph集群节点更换HBA卡后OSD识别机制的探究

之前的博客有提到硬盘柜改用SFF8088接口代替SFF8087接口连接Ceph节点，在经过了4个月的准备后，终于完成了硬件准备，可以升级了。

由于需要更换SAS HBA卡，以及将原本安装在机箱内部的两块板载SATA口连接的硬盘挪到新的硬盘柜，推测硬盘的设备名和PCI路径肯定会变，担心启动后主机无法识别原先的OSD。

{
    "id": 1,
    "bluestore_bdev_dev_node": "/dev/dm-5",
    "bluestore_bdev_devices": "sdc",
    "bluestore_bdev_partition_path": "/dev/dm-5",
    "device_ids": "sdc=ATA_TOSHIBA_MG04ACA4_37GBK8E7FVLC",
    "device_paths": "sdc=/dev/disk/by-path/pci-0000:0b:00.0-sas-phy3-lun-0",
    "devices": "sdc",
    "hostname": "ceph-node1",
    "objectstore_numa_unknown_devices": "sdc",
    "osd_data": "/var/lib/ceph/osd/ceph-1",
}

从OSD的元数据来看，如果OSD取的是/dev/dm-5这个device mapper或者是sdc这个设备名或者device_paths的话，风险就很大，到时候就要想办法手动修改参数来识别对应的硬盘。LLM也告诉我需要使用ATA_TOSHIBA_MG04ACA4_37GBK8E7FVLC这种唯一序列号作为持久化识别符确保使用正确的硬盘。但是这意味着需要清空OSD重新创建，然后等它backfill完，每个硬盘来一遍，就太费时间了。

于是决定把数据全备一遍然后随机应变，大不了从备份中恢复数据。

前置工作

当前版本18.2.2不支持在dashboard直接部署SMB服务，所以单独起了一台虚机挂载cephfs再用smb服务共享出来，读写速度只有30MB/s左右。本以为是集群节点网络接口瓶颈，给集群节点增加了额外的2个千兆口，做LACP，单独作为集群通讯网络使用，然而问题不在此。又怀疑到了虚拟机的性能瓶颈，准备在集群节点上直接起SMB服务，想着或许新版本能够能优雅地部署SMB服务。

升级集群版本

如果是用cephadm部署的集群的话，升级只要一行命令或者在Dashboard的升级页面点一下就好了。

ceph orch upgrade start --ceph-version 18.2.7

Ceph Orchestrator会自动执行升级步骤，不过这里指定所用镜像的–image参数似乎不起作用，仍旧会去拉取官方的quay.io/ceph/ceph@[digests]，甚至手动拉完同样digests的quay.io/ceph/ceph:v18.2.7也没用，升级程序还是会报拉取镜像失败，不知道是什么BUG。最后还是挂上梯子拉的镜像。

另一个插曲是在更新OSD重启容器时，由于有个pool使用了单副本，由于会导致PG下线，所以升级程序阻塞了重启该OSD。手动redeploy或者restart这个OSD容器无效，没有找到绕过的方式，只能临时增加到2副本解决。

v18最终版本18.2.7也没有提供dashboard部署smb，升级到19.2.2才有。最后手动起了个smb服务，不过读写还是30MB/s……

备份数据

一次15T的全量备份花了12天，因为需要12块LTO5磁带，而由于磁带驱动器不像带库可以自动换带，上班所以一天只能写一张磁带。笑……

记录OSD元数据信息

担心HBA卡更换后OSD无法正确识别，为了应对最糟糕的结果，提前记录下了OSD的元数据信息和对应的硬盘序列号。

迁移

测试硬盘同HBA卡更换硬盘插槽

正式开始制造混乱之前先测试了一下使用原HBA卡更换硬盘柜插槽安装硬盘的操作，重启节点后惊喜地发现系统仍旧可以正确识别到这个OSD，并且设备名和设备路径都变化了，设备路径从sas-phy3改到了sas-phy4，PCI路径倒是没有变。

这是一个好消息！ 虽然还不知道为什么没出问题。

更换HBA卡增加硬盘柜

于是就开始依次下线节点更换HBA卡，拆出硬盘放到新的硬盘柜里，重新连接，上线。没有出现问题。

事后回顾

迁移过程意外得比想象中顺利，集群经过短暂地rebalance后所有PG恢复active+clean，于是开始好奇CEPH是如何识别路径变更后的硬盘。

结论是orch创建OSD时lvm在磁盘上创建了block uuid和osd fsid对应的pv、lv，而vg和lv信息持久化在磁盘头部的LVM元数据中。因此是LVM确保了即便接口变化，pci路径改变，仍旧能动态生成正确的device mapper。

{
    "Type": "bind",
    "Source": "/var/lib/ceph/a94d2d38-3302-11ef-94fe-351d24676c48/osd.11",
    "Destination": "/var/lib/ceph/osd/ceph-11",
    "Mode": "z",
    "RW": true,
    "Propagation": "rprivate"
},

从容器的volume挂载信息能看到osd容器挂载的是/var/lib/ceph/[cluster fsid]/osd.[id]目录，对应osd metadata里osd_data的参数值。该目录下的block文件链接到了/dev/mapper/ceph–cfddddbe–525a–41ef–b574–225e4c2bedb0-osd–block–b97f88a5–5e23–4c47–b3d8–b43ef79c6ded这个device mapper路径的lv。容器本身不关心lv和物理磁盘的映射关系，即硬盘更换HBA卡或者槽位时实际由LVM工具保证设备映射不错乱。

进一步来看，ceph orch在声明osd进程容器时，由cephadm调用ceph-volume在物理磁盘上创建了lvm卷，并且给lv打上了cluster fsid，block uuid，osd fsid，osd id等tag。之后系统重启后，内核检测到物理设备动态分配设备名，udev生成持久化设备路径，LVM工具扫描PV/VG并且激活，最后创建Device Mapper 设备，udev生成DM设备不变的符号链接，提供给osd容器挂载。

这么一想，cephadm的设计还是挺优雅的。

后记

为了降低存储集群硬件之间的耦合性，人为创造了一些不确定性的操作，说好听点叫做混沌测试，在验证了集群的可靠性的同时还学习到了cephadm处理物理磁盘的原理。