Rook Ceph集群中OSD设备无法重新添加的问题分析与解决

问题背景

在使用Rook Ceph存储系统时，管理员可能会遇到一个常见但棘手的问题：当尝试将之前从集群中移除的OSD设备重新添加回集群时，这些设备无法被识别和重新加入。这种情况通常发生在设备被手动清理后，即使按照官方文档执行了完整的清理流程，设备仍然无法被重新利用。

问题现象

在本次案例中，管理员按照Rook官方文档执行了OSD的清理流程，包括：

1. 手动清除OSD
2. 验证OSD已从CRUSH map中移除
3. 确认集群状态健康
4. 从Helm配置中移除了相关节点和设备
5. 对设备进行了彻底的擦除（使用dd和wipefs命令）

然而，当尝试重新添加这些设备时，Rook Operator似乎完全忽略了这些设备，没有创建任何相关的prepare pod或OSD pod。

根本原因分析

经过深入排查，发现问题根源在于残留的认证密钥。即使设备被彻底擦除，Ceph集群中可能仍然保留着与这些设备相关的认证信息。这些残留的认证密钥会阻止Rook Operator重新准备和添加这些设备。

详细解决方案

1. 启用Discovery Daemon

首先，通过修改Helm values文件启用discovery daemon：

enableDiscoveryDaemon: true

这一步骤会创建一个daemonset，负责在集群所有节点上发现存储设备。虽然这不是最终解决方案，但它可以帮助触发prepare pod的创建，从而获取更多调试信息。

2. 检查prepare pod日志

启用discovery daemon后，可以观察到prepare pod的创建和失败。通过检查pod日志，能够看到类似以下的错误信息：

failed to configure devices: failed to initialize osd: failed to get ceph volume info: failed to get ceph volume info for osd: auth key already exists

这表明系统中存在残留的认证信息。

3. 清理残留认证

进入Ceph toolbox执行以下命令，删除所有残留的OSD认证信息：

ceph auth rm osd.<osd-id>

对于不确定的OSD ID，可以先列出所有认证信息：

ceph auth ls

4. 完整清理流程

确保执行了完整的清理流程：

1. 删除prepare pod
2. 重启Rook Operator以触发重新协调
3. 确认/var/lib/rook目录已被清空
4. 再次验证设备已被完全擦除

5. 恢复配置

问题解决后，可以禁用discovery daemon：

enableDiscoveryDaemon: false

预防措施

为了避免类似问题再次发生，建议：

1. 在执行OSD移除操作时，同时清理认证信息
2. 在重新添加设备前，使用ceph auth ls命令验证没有残留认证
3. 考虑使用Rook的自动清理策略，在集群删除时自动清理设备
4. 维护详细的变更记录，包括所有执行过的清理操作

技术要点总结

1. Rook对OSD设备的管理不仅依赖于物理设备状态，还与Ceph集群的认证系统紧密相关
2. Discovery daemon可以作为诊断工具，帮助识别设备添加问题
3. 认证信息的清理是设备重新添加过程中的关键步骤
4. Operator的重启可以触发集群状态的重新评估和协调

通过系统性的排查和正确的操作流程，可以有效解决OSD设备无法重新添加的问题，确保Ceph集群的存储容量得到充分利用。