Ceph重启后OSD挂载信息丢失，如何恢复？

Question

Ceph集群重启后，部分OSD因挂载信息丢失无法正常启动，表现为OSD目录未挂载、数据盘未激活或systemd挂载单元失效。常见原因为fstab配置缺失、设备UUID变更或ceph-volume元数据损坏。如何在不影响数据安全的前提下，快速恢复OSD挂载并重新接入集群？

Answer 1

一、问题背景与现象分析

Ceph集群在经历重启后，部分OSD（Object Storage Daemon）节点未能正常启动，表现为：

• OSD数据目录未挂载（如/var/lib/ceph/osd/ceph-*为空或未绑定设备）
• 底层数据盘未激活，lsblk显示设备存在但无挂载点
• systemctl status ceph-osd@*报错“Device not found”或“Mount failed”
• 使用ceph-volume lvm list无法识别已存在的OSD逻辑卷

常见根本原因包括：

1. fstab配置缺失：系统重启后依赖/etc/fstab自动挂载，若条目丢失则挂载失败
2. 设备UUID变更：磁盘热插拔、RAID卡重置或udev规则变动导致设备标识变化
3. ceph-volume元数据损坏：LVM标签丢失或/etc/ceph/osd/*元数据文件异常

二、诊断流程与关键检查项

为确保数据安全，恢复前必须进行完整诊断。以下是标准排查顺序：

步骤	命令	预期输出
1. 检查物理设备状态	lsblk -f	确认设备存在且文件系统类型为xfs/btrfs
2. 验证LVM逻辑卷	lvs -o +tags /dev/ceph-*/osd-block-*	查看是否含ceph.osd_id=*等标签
3. 查询ceph-volume记录	ceph-volume lvm list	列出所有已注册的OSD信息
4. 检查fstab配置	cat /etc/fstab | grep osd	确认有对应UUID的挂载条目
5. 查看systemd挂载单元	systemctl list-units | grep mnt-	确认mnt-var-lib-ceph-osd-*是否存在
6. 检查OSD目录挂载状态	mount | grep ceph	确认/var/lib/ceph/osd/ceph-N已绑定
7. 查阅日志线索	journalctl -u ceph-osd@N	定位具体错误（如device not found）
8. 核对udev设备路径	udevadm info /dev/disk/by-path/* | grep ID_SERIAL	确认设备唯一性
9. 验证FS一致性	xfs_repair -n /dev/ceph-vg/osd-lv	只读检测文件系统完整性
10. 确认Ceph集群状态	ceph -s	观察OSD map中该OSD是否处于down状态

三、分场景恢复策略

根据诊断结果，采用不同恢复路径：

场景1：fstab条目丢失但LVM标签完整

# 获取逻辑卷挂载信息
ceph-volume lvm list | grep -A5 "osd id"

# 输出示例：
# data device: /dev/ceph-vg/osd-data-xxxx
# block device: /dev/ceph-vg/osd-block-xxxx
# devices: /dev/sdb

# 重新生成fstab条目（以xfs为例）
echo "UUID=$(blkid -s UUID -o value /dev/ceph-vg/osd-data-xxxx) /var/lib/ceph/osd/ceph-0 xfs defaults,noatime,inode64 0 2" >> /etc/fstab

# 手动挂载并启动OSD
mount /var/lib/ceph/osd/ceph-0
systemctl enable ceph-osd@0
systemctl start ceph-osd@0

场景2：设备UUID变更导致fstab失效

当磁盘被重新识别，原UUID不再匹配时：

1. 使用blkid /dev/sdX获取新UUID
2. 编辑/etc/fstab替换旧UUID
3. 执行mount -o remount /var/lib/ceph/osd/ceph-N
4. 验证ceph-volume lvm activate N <data_uuid>

场景3：ceph-volume元数据损坏

若ceph-volume lvm list无法识别OSD，但LVM存在：

# 手动重建元数据（关键操作需谨慎）
ceph-volume lvm recover --osd-id 0 --device /dev/sdb

# 或指定数据路径
ceph-volume lvm recover --osd-id 0 --data-dev /dev/ceph-vg/osd-data-xxxx

该命令将重新生成/etc/ceph/osd/ceph-0.json并修复systemd单元。

四、自动化恢复流程图

以下为推荐的标准化恢复流程：

graph TD
      A[OSD启动失败] --> B{检查lsblk与lvs}
      B -->|设备存在| C[检查ceph-volume lvm list]
      B -->|设备不存在| D[检查硬件连接与RAID状态]
      C -->|OSD可见| E[检查fstab与挂载点]
      C -->|OSD不可见| F[执行ceph-volume lvm recover]
      E -->|fstab缺失| G[根据blkid补全fstab]
      E -->|已配置| H[手动mount并启动OSD服务]
      G --> H
      F --> H
      H --> I[验证ceph -s中OSD up in cluster]
      I --> J[监控PG状态直至active+clean]

五、预防机制与最佳实践

为避免此类问题反复发生，建议实施以下措施：

• 定期备份/etc/fstab与/etc/ceph/目录
• 使用ceph-volume inventory建立磁盘台账
• 部署配置管理工具（如Ansible/Puppet）同步fstab
• 启用ceph-mgr device health模块监控磁盘状态
• 对关键OSD启用Zabbix或Prometheus告警规则
• 避免手动修改LVM结构，始终通过ceph-volume管理
• 在维护窗口执行重启，并预检ceph osd set-nodown
• 启用systemd-mount自动发现机制作为补充
• 对NVMe设备使用by-disk路径而非UUID
• 建立灾备恢复文档并定期演练