企业官网建设流程全解析

• 存储
• 分布式文件系统
• 对象存储
• 后端
• 高可用

导读

Ceph 是分布式对象、块与文件存储平台，其可靠性高度依赖底层物理存储设备（HDD/SSD）的健康状况。本文围绕 doc/rados/operations/devices.rst 系统讲解 Ceph 的设备管理能力：如何追踪哪些守护进程使用哪些磁盘、如何点亮故障盘指示灯以便现场更换、如何通过 SMART 指标监控设备健康、如何预测设备故障并自动触发数据迁移，以及与之配套的健康告警机制。读完本文，你将掌握ceph device系列命令的完整用法、devicehealth与diskprediction_local两个 mgr 模块的核心配置参数，并能结合源码理解这些能力在集群内部的真实工作方式。

设备管理概述：Ceph 如何应对硬件故障

设备管理（Device Management）是 Ceph 处理硬件故障的基础能力。Ceph 会追踪硬件存储设备（HDD、SSD），记录每个设备被哪些守护进程（daemon）使用，并持续收集这些设备的健康指标。基于这些信息，Ceph 可以提供两类能力：

• 预测硬件故障：根据历史健康指标，推断磁盘的剩余寿命与预期故障时间；
• 自动响应硬件故障：在设备预期即将失效时，自动将相关 OSD 标记为out，把数据迁移到健康设备上。

从实现角度看，设备追踪由ceph-mgr的devicehealth模块（源码位于 src/pybind/mgr/devicehealth/module.py）驱动，它通过读取 OSD 上报的设备元数据（如device_ids）建立"设备 ↔ 守护进程"的映射关系，并将采集到的 SMART 原始数据持久化存储。可以推断，ceph device ls、ceph device info等命令的输出即来源于这一模块维护的设备清单（devices）与 OSDMap/OSD 元数据。

设备追踪与查询

列出集群中的设备

查看当前集群中正在使用的存储设备清单：

ceph device ls

输出会包含每个设备的devid、所在主机、关联的守护进程，以及（启用故障预测后）设备寿命预期（life expectancy）字段。

按守护进程或主机过滤

当需要排查某个 OSD 或某台主机上的磁盘时，可以使用如下过滤形式：

ceph device ls-by-daemon <daemon> ceph device ls-by-host <host>

其中<daemon>形如osd.0、mon.node1，<host>是集群中的主机名（short name）。

查询单台设备的详细信息

查看某个具体设备的位置信息（location）以及它被哪些守护进程消费（daemons）：

ceph device info <devid>

<devid>是设备标识，例如SanDisk_X400_M.2_2280_512GB_162924424784，可通过ceph device ls获取。device info返回的信息还包括设备的路径（如/dev/sda）、SMART 状态摘要与寿命预期区间等，是定位故障盘的第一手资料。

识别物理设备：闪烁硬盘 LED 指示灯

更换故障磁盘时，最怕在几十块盘的机柜中"拔错盘"。Ceph 提供了一条命令，可以在硬件机箱（enclosure）上点亮磁盘的 LED 指示灯：

ceph device light on|off <devid> [ident|fault] [--force]

• <devid>：设备标识，先用ceph device ls获取；
• [ident|fault]：选择闪烁哪种灯，默认为ident（识别灯），fault为故障灯；
• --force：强制执行，绕过某些校验。

前置条件与限制

该命令仅在启用了编排器（orchestrator）模块时可用，当前支持 Cephadm 或 Rook 两种编排器。检查当前启用的编排器：

ceph orch status

另外，文档明确指出：闪烁指示灯可能不生效。是否有效取决于内核版本、SES（SCSI Enclosure Services）固件以及 HBA（主机总线适配器）的配置。也就是说，lsmcli需要能够通过 SES 协议与背板通信，否则命令虽执行但灯不会亮。

自定义闪烁命令（Jinja2 模板）

Ceph 默认调用lsmcli命令来控制 LED，你可以通过ceph config-key自定义其模板：

ceph config-key set mgr/cephadm/blink_device_light_cmd "<template>" ceph config-key set mgr/cephadm/<host>/blink_device_light_cmd "lsmcli local-disk-{{ ident_fault }}-led-{{'on' if on else 'off'}} --path '{{ path or dev }}'"

第二条命令的形式支持按主机（<host>）粒度覆盖，适合不同厂商背板命令不一致的场景。默认模板定义在 src/pybind/mgr/cephadm/templates/blink_device_light_cmd.j2，其内容正是：

lsmcli local-disk-{{ ident_fault }}-led-{{'on' if on else 'off'}} --path '{{ path or dev }}'

模板支持以下参数：

从 src/pybind/mgr/cephadm/module.py 的实现看，blink_device_light会先渲染对应主机（host）的模板，再通过cephadm shell -- <cmd_args>在目标主机上执行渲染后的命令，若执行失败会抛出OrchestratorError。仓库测试 src/pybind/mgr/cephadm/tests/test_cephadm.py 覆盖了默认模板、自定义全局模板以及按主机自定义模板三种场景，验证了该配置键的解析逻辑。

启用健康监控：收集 SMART 指标

Ceph 通过smartctl工具采集设备的健康指标。以 SATA 盘为例，SMART 标准提供了一系列内部指标：累计通电小时数、上下电次数、不可恢复读错误次数等；SAS 与 NVMe 盘通过略有差异的标准暴露类似指标。NVMe 盘还会附加厂商私有数据（例如写入放大、磨损信息）。

开启或关闭健康监控：

ceph device monitoring on ceph device monitoring off

对应的模块选项是mgr/devicehealth/enable_monitoring（默认true）。关闭监控时，模块会同时清空已设置的健康检查（self.set_health_checks({})），避免残留的告警卡住ceph -s状态。

底层采集原理：smartctl 与特权助手

SMART 数据的获取并非由 mgr 直接执行，而是由 OSD 守护进程完成。从 src/common/blkdev.cc 可以看到，OSD 通过一个特权助手/usr/libexec/ceph/block-device-health执行smartctl -x --json=o <dev>（-x输出全部 SMART 信息，--json=o输出 JSON 格式）。该助手是 sudoers.d/ceph-smartctl 中唯一授予ceph用户的 sudo 命令，用于校验设备路径后执行固定的 smartctl 命令行，从而避免任意命令注入。此外，对于识别为 NVMe 的盘，还会调用nvme命令获取厂商附加的 SMART 日志（见block_device_run_vendor_nvme）。

devicehealth模块通过send_command向 OSD/MON 发送smart前缀的命令（do_query_daemon_health_metrics），拿到原始 JSON 后再解析关键字段。例如磨损等级（wear level）的提取逻辑位于 src/pybind/mgr/devicehealth/module.py：

• SATA SSD：从ata_device_statistics的第 7 页（page number == 7）、偏移 8 处读取百分比并除以 100；
• NVMe SSD：读取nvme_smart_health_information_log.percentage_used并除以 100。

指标采集（Scraping）与存储

自动采集周期

启用监控后，设备指标会按固定周期自动采集（scrape）。默认每 24 小时采集一次，可用以下命令调整：

ceph config set mgr mgr/devicehealth/scrape_frequency <seconds>

在源码中scrape_frequency的默认值为86400秒（即 24 小时）。后台线程会按sleep_interval（默认 600 秒）周期性唤醒，将上次采集时间对齐到采集周期，到期后执行scrape_all()并顺带触发一次predict_all_devices()（见 module.py）。

手动采集

需要立即采集时，可以手动触发：

# 手动采集所有设备 ceph device scrape-health-metrics # 采集单台设备 ceph device scrape-health-metrics <device-id> # 采集单个守护进程管辖的设备 ceph device scrape-daemon-health-metrics <who>

其中<who>是osd.<id>或mon.<name>形式的守护进程名。从scrape_all()的实现看，采集会遍历 OSDMap 中的所有 OSD 与 MonMap 中的所有 MON，逐一请求其 SMART 数据，并去重后入库。

查询已存储的指标

ceph device get-health-metrics <devid> [sample-timestamp]

可选参数sample-timestamp用于取特定时间点的采样数据，省略时返回全部历史采样。底层实现中，指标保存在模块的数据库中（Device与DeviceHealthMetrics两张表，raw_smart字段保存原始 JSON），并支持两个相关配置项：

故障预测：评估设备寿命预期

Ceph 能够基于采集到的健康指标预测磁盘寿命与故障时间。预测模式通过以下配置指定：

ceph config set global device_failure_prediction_mode <mode>

支持两种模式：

• none：关闭设备故障预测（默认行为下若未启用任何预测模块即此模式）；
• local：使用ceph-mgr守护进程内置的预训练预测模型。

local模式对应 src/pybind/mgr/diskprediction_local/module.py 中的diskprediction_local模块。该模块的配置项包括：

预测流程为：diskprediction_local通过remote('devicehealth', 'show_device_metrics', ...)拉取设备历史 SMART 数据，累积到至少 6 个采样点后，将数据输入预训练模型（Predictor.create(self.predictor_model)，模型文件位于models/目录下）计算剩余寿命。由于预测是在后台周期进行的，寿命预期值可能需要相当长的时间才会填充——这是正常的。

查看所有设备的寿命预期：

ceph device ls

查看单台设备的元数据与寿命区间：

ceph device info <devid>

手动触发与外部数据导入

显式强制预测某台设备的寿命：

ceph device predict-life-expectancy <devid>

如果集群外已有可靠的故障信息来源（例如厂商诊断工具），也可以直接告知 Ceph 某台设备的寿命预期：

ceph device set-life-expectancy <devid> <from> [<to>]

寿命预期以时间区间表示：<from>为预期失效的最早时间，<to>为最晚时间（可省略，表示区间终点未知）。区间的设计是为了表达预测的不确定性——预测越不可靠，区间越宽。

健康告警：DEVICE_HEALTH 系列

当设备寿命预期进入危险区间时，devicehealth模块会触发健康告警。核心阈值配置为：

ceph config set mgr mgr/devicehealth/warn_threshold <seconds>

若设备预计在warn_threshold秒内失效，则产生DEVICE_HEALTH告警。源码中该选项默认值为86400 * 14 * 6秒（即 84 天）。手动触发生成告警的检查：

ceph device check-health

从check_health()的实现（module.py）看，它会遍历所有带life_expectancy_max的设备，结合 OSDMap 判断其 OSD 是否仍在in状态，并最终调用set_health_checks()发布告警。

与设备健康相关的告警在 doc/rados/operations/health-checks.rst 中有完整定义，共三种：

需要留意：DEVICE_HEALTH仅针对当前仍标记为in的 OSD；若设备已损坏但 OSD 仍up，恢复可能处于降级状态，必要时可考虑强制停止相关 OSD 守护进程以加速恢复——但这必须极其谨慎，注意故障域约束，避免破坏数据可用性。

自动迁移：self_heal 预迁移

mgr/devicehealth/self_heal选项（默认启用）会自动把"预计即将失效"的设备上的数据迁走。启用后，模块会把相关 OSD 标记为out，从而触发数据自动迁移。触发条件由mgr/devicehealth/mark_out_threshold控制：

ceph config set mgr mgr/devicehealth/mark_out_threshold <seconds>

若设备预计在mark_out_threshold秒内失效，就会被自动标记out。源码中该选项默认值为86400 * 14 * 2秒（即 28 天）。

从实现细节看，mark_out_etc()（module.py）不只是执行osd out，还会将相关 OSD 的primary-affinity权重设为0.0，降低它们继续作为主副本承载写入的概率，加速数据迁移收尾。

防止级联失败：mon_osd_min_up_ratio

文档特别强调，mon_osd_min_up_ratio配置项可以防止"自愈"过程级联成整体故障：如果self_heal标记out的 OSD 数量过多，导致in比例跌破阈值，集群会立即停止批量标记，并抛出DEVICE_HEALTH_TOOMANY健康检查（与之配套的还有mon_osd_min_in_ratio，同样是防止过多 OSD 被自动标记out的保护比例）。此时应尽快向集群补充新 OSD 以防数据丢失，或分批替换故障盘。

配置参数速查表

以下汇总设备管理相关核心配置（默认值取自 devicehealth/module.py 与 diskprediction_local/module.py 源码）：

小结

Ceph 的设备管理能力覆盖了硬件生命周期的完整闭环：ceph device ls/info建立设备与守护进程的对应关系；device light借助编排器与lsmcli点亮故障盘 LED，帮助现场精准换盘；devicehealth模块通过smartctl定期采集 SMART 指标并持久化；diskprediction_local用预训练模型预测寿命预期；warn_threshold与self_heal则在磁盘彻底损坏前自动发出告警、迁移数据，把硬件故障对集群可用性的冲击降到最低。结合 devicehealth 模块源码、cephadm 实现 与 health-checks 文档 深入阅读，可以更完整地理解这些能力在集群内部的协作方式。

• 存储
• 分布式文件系统
• 对象存储
• 后端
• 高可用