Nautilus 中的新功能：设备管理和故障预测

2019 年 4 月 12 日 sage

Ceph 存储集群最终依赖于物理硬件设备——HDD 或 SSD，这些设备可能会发生故障。从 Nautilus 开始，Ceph 现在处理物理设备的管理和跟踪。此外，我们还添加了基础设施来收集设备健康指标（例如 SMART），并通过内置的预训练预测模型或通过 SaaS 服务来预测设备故障，从而在故障发生之前预测设备故障。

管理设备 ¶

Ceph 一直以来都认为存储设备只是可能发生故障的众多物理组件之一，而是将注意力集中在存储守护进程本身的故障上。无论是坏的 CPU、网络链路、内存、电源还是存储设备发生故障，结果都是存储守护进程进程停止，系统必须应对。通常，这效果很好，除了当发生故障时，将守护进程（例如 osd.123）的故障追溯到需要更换的故障硬件通常很繁琐。通常是硬盘或 SSD 发生故障，所以我们是时候让集群管理的一部分变得更容易了。

从 Nautilus 开始，Ceph 通过 $vendor_$model_$serial 识别物理设备。例如，WDC_WD40EFRX-68N32N0_WD-WCC7K2ZL0V6K 或 Micron_MTFDHBG800MCG-1AN1ZABYY_ZF1000DQ。OSD 和 Monitor 都收集有关它们正在使用的物理设备（无论它们是直接使用还是分层在 devicemapper 或 LVM 之上）的元数据，并将其报告给 monitor 和 manager。您可以使用新的 ceph device ls 命令查看消耗的设备的完整清单

$ ceph device ls DEVICE HOST:DEV DAEMONS LIFE EXPECTANCY Crucial_CT1024M550SSD1_14160C164100 stud:sdd osd.40
Crucial_CT1024M550SSD1_14210C25F933 stud:sdc osd.39
Crucial_CT1024M550SSD1_14210C25F936 stud:sde osd.41
INTEL_SSDPE2ME400G4_CVMD5442003M400FGN cpach:nvme0n1 osd.10
INTEL_SSDPE2MX012T4_CVPD6185002R1P2QGN stud:nvme0n1 osd.1
ST2000NX0253_S4608PDF cpach:sdo osd.7
ST2000NX0253_S46097S2 cpach:sdr osd.4
ST2000NX0253_S460TMFE eutow:sdl osd.32
Samsung_SSD_850_EVO_1TB_S2RENX0J500066T cpach:sdb osd.17
Samsung_SSD_850_EVO_1TB_S2RENX0J504842Z stud:sdt osd.23
WDC_WDS200T2B0A-00SM50_183503800168 cpach:sdn osd.56
WDC_WDS200T2B0A-00SM50_183503800398 stud:sdg osd.62
WDC_WDS200T2B0A-00SM50_183503800843 stud:sdf osd.61

您还可以将结果限制为由特定守护进程或主机使用的设备

$ ceph device ls-by-daemon$ ceph device ls-by-host

您可以使用以下命令获取有关特定设备的信息

$ ceph device info Seagate_ST31000524AS_5VP8JLY4 device Seagate_ST31000524AS_5VP8JLY4 attachment mira116:sdf daemons osd.53

这将具体告诉您哪些守护进程报告了该设备的消耗，以及它上次在哪些主机上持有的设备名称。虽然多路径设备未经测试，但 Ceph 应该报告设备在所有主机上被消耗的情况。

健康指标 ¶

Nautilus 还可以监控这些设备的健康指标。对于 SATA 设备，这是通过 SMART 完成的，对于 SAS 和 NVMe 设备，存在类似的标准，人类通常统称为 SMART（尽管 SMART 技术上是 SATA 标准）。

每个抓取的內容来自 smartctl 命令。要使其工作，需要 smartmontools 的 7.0 版本（于 2018 年 12 月 30 日发布），因为该版本添加了我们的抓取程序使用的 JSON 输出模式。此版本尚未进入各种下游 Linux 发行版或 ceph-container 镜像，但这些部分应该很快到位。目前，您可能需要从源代码构建并手动在您的集群上安装 smartctl。

要启用设备监控，

$ ceph device monitoring on

要禁用监控，

$ ceph device monitoring off

启用后，Ceph 默认每 24 小时抓取一次指标。这些指标存储在名为 device_health_metrics 的 RADOS 池中，可以使用 ceph device get-health-metrics 命令转储。例如，

$ ceph device get-health-metrics Micron_MTFDHBG800MCG-1AN1ZABYY_ZF1000DQ | head { "20190402-000812": { "nvme_controller_id": 0, "power_on_time": { "hours": 10120 }, "nvme_smart_health_information_log": { "controller_busy_time": 15126, "host_writes": 4622443474, "temperature": 55,

您还可以使用以下命令强制立即抓取指标

ceph device scrape-health-metrics $ ceph device scrape-health-metrics$ ceph device scrape-daemon-health-metrics

默认情况下，指标保留两周后被丢弃。您可以使用以下命令进行调整

$ ceph config set mgr mgr/devicehealth/scrape_frequency

其中持续时间可以指定为秒，或使用 h、d、w 等后缀（例如，3w 表示三周）。

故障预测 ¶

收集指标的主要目标是在故障发生之前预测故障。目前，Ceph 支持几种模式

none：禁用故障预测（默认值）
local：使用预训练模型，在 ceph-mgr 守护进程上运行，以预测每个设备的剩余寿命。该模型由 ProphetStor 训练并贡献，一家 AIOps 公司。
cloud：使用 ProphetStor 的基于云的预测服务。可以免费启用，如果您愿意与第三方共享您的故障数据（以及其他一些与性能相关的指标），您将获得更准确的寿命预测。ProphetStor 还提供具有最准确模型的商业云计划，以及在本地部署其服务的选项。有关 ProphetStor 为 Ceph 提供的故障预测服务的更多信息，您可以访问他们的网站。

您可以使用以下命令设置预测模式

$ ceph config set global device_failure_prediction_mode

启用预测后，集群最终会收到有关每个设备的寿命的信息，该寿命指定为一个时间间隔，描述设备预计何时发生故障。该间隔的宽度旨在提供对预测确定性的某种指示，尽管该范围在统计学意义上没有严格定义为置信区间或其他正式概念。如果您知道，您将在 ceph device ls 输出中看到此寿命（如果已知），但对于大多数设备，预计不会发生故障，该字段将保持为空

$ ceph device ls DEVICE HOST:DEV DAEMONS LIFE EXPECTANCY Crucial_CT1024M550SSD1_14160C164100 stud:sdd osd.40 3m
Crucial_CT1024M550SSD1_14210C25B79E eutow:sds osd.19
Crucial_CT1024M550SSD1_14210C25B79F eutow:sdq osd.21

需要记住的一件事是，故障预测是新的，我们没有很多实际经验来告诉我们它的准确性如何。请考虑启用预测，关注它告诉您的内容，并让我们知道您看到的内容，但请谨慎对待这些寿命值。

响应预测 ¶

默认情况下，集群对预计很快发生故障的设备的回应是引发健康警告。我们生成了几个不同的警报

DEVICE_HEALTH：一个或多个设备预计很快会发生故障。阈值由 mgr/devicehealth/warn_threshold 配置选项控制，默认为三个月。
DEVICE_HEALTH_TOOMANY：很多设备预计很快会发生故障——足以如果全部标记为故障，它将使集群低于配置的 mon_osd_min_in_ratio。
DEVICE_HEALTH_IN_USE：一个或多个设备预计很快会发生故障，已被标记为故障，但数据尚未完全迁移。

当启用此功能时，mgr/devicehealth/mark_out_threshold 控制设备寿命必须有多短，然后我们才会标记 OSD。

$ ceph config set global mgr/devicehealth/self_heal true

默认值为四周。

感谢 ¶

收集和存储健康指标的工作由 Outreachy 实习生 Yaarit Hatuka 推动。ProphetStor 的 Rick Chen 贡献了用于本地和云模式的故障预测代码。非常感谢他们两位将这项工作完成！

接下来是什么：闪烁的灯 ¶

现在 Ceph 终于有一些关于我们正在使用的物理设备的信息，以及检查它们的界面，我们就有机会在硬件外壳上闪烁灯光，使故障磁盘的更换变得容易且不易出错！这仍然是一个正在进行中的工作，并且需要一些来自 Nautilus 中引入但仍处于早期阶段的新编排层的支持，但想法是您很快可以执行类似的操作

$ ceph device light fault在 $ ceph device light fault关闭

第一个将支持此功能的编排器是 DeepSea 和 Rook，一旦可用，我们预计它将被回溯到 Nautilus。

接下来是什么：提高预测准确性 ¶

当前故障预测的一个挑战是它作为一个黑盒子工作。ProphetStor 贡献的预训练预测模型使用他们自己的私有故障数据进行训练，并且开源社区不清楚哪些设备覆盖良好，训练参数是什么等等。

有一个相关的项目旨在创建一个开放的设备健康指标数据集，可用于基于完全开放的数据训练开源预测模型。目前，唯一可用的数据是 BackBlaze 发布的数据（顺便说一下，他们值得赞扬，因为他们这样做——几家云提供商已经发布了关于设备故障预测的学术论文，但据我所知，没有一家分享过他们的数据）。项目启动后，目标是允许 Ceph 用户（和其他用户！）选择共享他们的设备健康指标，其中包括集群当前收集的大部分指标，减去设备序列号和其他引起隐私问题字段。随着时间的推移，我们将能够构建一个更大、更全面的数据集，并使用该数据集来训练更准确的故障预测模型。敬请期待！