其他分享
首页 > 其他分享> > Ceph 健康检查

Ceph 健康检查

作者：互联网

参考：https://docs.ceph.com/en/pacific/rados/operations/health-checks/

概述

Ceph 集群可以发出一组有限的可能的健康消息——这些消息被定义为具有唯一标识符的健康检查。

标识符是一个简洁的伪人类可读（即像变量名）字符串。它旨在使工具（例如 UI）能够理解健康检查，并以反映其含义的方式呈现它们。

此页面列出了监视器和管理器守护程序引发的健康检查。除了这些之外，您还可能会看到源自 MDS 守护进程的健康检查（请参阅CephFS 健康消息），以及由 ceph-mgr python 模块定义的健康检查。

定义

MON

如果旧版本的 Ceph 正在任何守护进程上运行，则发出警告。如果检测到多个版本，它将生成健康错误。此条件必须存在超过 mon_warn_older_version_delay（默认设置为 1 周）才能触发健康状况。这允许大多数升级继续进行而不会错误地看到警告。如果升级暂停很长一段时间，可以使用健康静音，如“ceph health mute DAEMON_OLD_VERSION –sticky”。在这种情况下，升级完成后使用“ceph health unmute DAEMON_OLD_VERSION”。

一个或多个监视器守护程序当前已关闭。集群需要大多数（超过 1/2）的监视器才能运行。当一个或多个监视器关闭时，客户端可能很难建立与集群的初始连接，因为他们可能需要尝试更多地址才能到达正在运行的监视器。

通常应尽快重新启动停机监视器守护程序，以降低后续监视器故障导致服务中断的风险。

运行 ceph-mon 监视器守护进程的主机上的时钟没有充分同步。如果集群检测到时钟偏差大于mon_clock_drift_allowed.

这最好通过使用类似 ntpd 或 chrony 的工具同步时钟来解决。

如果保持时钟紧密同步不切实际， mon_clock_drift_allowed也可以增加阈值，但该值必须保持在显着低于 mon_lease 间隔才能使监视器集群正常运行。

该ms_bind_msgr2选项已启用，但一个或多个监视器未配置为绑定到集群的 monmap 中的 v2 端口。这意味着特定于 msgr2 协议的功能（例如，加密）在某些或所有连接上不可用。

在大多数情况下，这可以通过发出以下命令来纠正：

ceph mon enable-msgr2

该命令将更改为旧默认端口 6789 配置的任何监视器，以继续侦听 6789 上的 v1 连接，并在新的默认 3300 端口上侦听 v2 连接。

如果监视器配置为在非标准端口（不是 6789）上侦听 v1 连接，则需要手动修改 monmap。

一台或多台监视器的磁盘空间不足。如果存储监控数据库的文件系统上的可用空间（通常为 /var/lib/ceph/mon）低于百分比 mon_data_avail_warn（默认值：30%） ，则会触发此警报。

这可能表明系统上的某些其他进程或用户正在填充监视器使用的同一文件系统。它也可能表明监视器数据库很大（见MON_DISK_BIG 下文）。

如果无法释放空间，则可能需要将监视器的数据目录移动到另一个存储设备或文件系统（必须当监视器守护程序没有运行时操作）。

一个或多个监视器的磁盘空间严重不足。如果存储监控数据库的文件系统上的可用空间（通常为 /var/lib/ceph/mon）低于百分比mon_data_avail_crit（默认值：5%） ，则会触发此警报。见MON_DISK_LOW，以上。

一个或多个监视器的数据库大小非常大。如果监视器的数据库大小大于 mon_data_size_warn（默认值：15 GiB），则会触发此警报。

大型数据库不常见，但不一定表示存在问题。当有active+clean长时间未达到状态的归置组时，监控数据库的大小可能会增长。

这也可能表明监视器的数据库没有正确压缩，在一些旧版本的 leveldb 和 Rocksdb 中已经观察到了这种情况。ceph daemon mon. compact强制压缩可能会缩小磁盘大小。

此警告还可能表明监视器存在阻止其修剪其存储的集群元数据的错误。如果问题仍然存在，请报告错误。

可以通过以下方式调整警告阈值：

ceph config set global mon_data_size_warn <size>

一个或多个连接到集群的客户端或守护程序在重新连接到监视器时未安全地回收其 global_id（标识集群中每个实体的唯一编号）。客户端仍然被允许连接，因为该 auth_allow_insecure_global_id_reclaim选项设置为 true（在所有 ceph 客户端升级之前可能是必需的），并且 auth_expose_insecure_global_id_reclaim选项设置为true（在他们第一次进行身份验证之后，允许监视器通过强制重新连接来尽早检测具有不安全回收的客户端）。

您可以通过以下方式识别哪些客户端正在使用未打补丁的 ceph 客户端代码：

ceph health detail

客户端 global_id reclaim rehavior 也可以在 连接到单个监视器的客户端转储中的global_id_status字段中看到（reclaim_insecure意味着客户端未打补丁并且正在促成此健康警报）：

ceph tell mon.\* sessions

我们强烈建议将系统中的所有客户端升级到正确回收 global_id 值的较新版本的 Ceph。更新所有客户端后，您可以通过以下方式停止允许不安全的重新连接：

ceph config set mon auth_allow_insecure_global_id_reclaim false

如果立即升级所有客户端不切实际，您可以使用以下命令暂时消除此警告：

ceph health mute AUTH_INSECURE_GLOBAL_ID_RECLAIM 1w   # 1 week

虽然我们不建议这样做，但您也可以通过以下方式无限期禁用此警告：

ceph config set mon mon_warn_on_insecure_global_id_reclaim false

Ceph 当前配置为允许客户端使用不安全的进程重新连接到监视器，以回收其先前的 global_id，因为该设置 auth_allow_insecure_global_id_reclaim设置为true. 当现有 Ceph 客户端升级到正确且安全地回收其 global_id 的较新版本的 Ceph 时，可能需要启用此设置。

如果AUTH_INSECURE_GLOBAL_ID_RECLAIM还没有引发健康警报并且该auth_expose_insecure_global_id_reclaim设置没有被禁用（默认情况下处于启用状态），那么当前没有连接需要升级的客户端，并且可以安全地禁止不安全的 global_id 回收：

ceph config set mon auth_allow_insecure_global_id_reclaim false

如果仍有客户端需要升级，则可以通过以下方式暂时消除此警报：

ceph health mute AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED 1w   # 1 week

虽然我们不建议这样做，但您也可以通过以下方式无限期禁用此警告：

ceph config set mon mon_warn_on_insecure_global_id_reclaim_allowed false

MGR

所有管理器守护程序当前都已关闭。集群通常应该至少有一个正在运行的管理器 ( ceph-mgr) 守护程序。如果没有管理器守护程序在运行，则集群监控自身的能力将受到影响，并且部分管理 API 将变得不可用（例如，仪表板将无法工作，并且大多数报告指标或运行时状态的 CLI 命令将被阻止）。但是，集群仍然能够执行所有 IO 操作并从故障中恢复。

通常应该尽快重新启动停机管理器守护程序，以确保可以监视集群（例如，以便ceph -s信息是最新的，和/或 Prometheus 可以抓取指标）。

启用的管理器模块未通过其依赖性检查。此运行状况检查应附带来自模块的有关问题的解释性消息。

例如，一个模块可能会报告未安装所需的包：安装所需的包并重新启动管理器守护程序。

此运行状况检查仅适用于启用的模块。如果一个模块没有启用，你可以在ceph module ls的输出中看到它是否报告了依赖问题。

管理器模块遇到意外错误。通常，这意味着模块的服务 函数引发了未处理的异常。如果异常没有提供对自身的有用描述，那么人类可读的错误描述可能会措辞模糊。

此运行状况检查可能表明存在错误：如果您认为遇到错误，请打开 Ceph 错误报告。

如果您认为错误是暂时的，您可以重新启动管理器守护程序，或者在活动守护程序上使用ceph mgr fail来提示故障转移到另一个守护程序。

OSD

一个或多个 OSD 被标记为 down。ceph-osd 守护进程可能已经停止，或者对等 OSD 可能无法通过网络访问 OSD。常见原因包括守护程序停止或崩溃、主机停机或网络中断。

验证主机是否健康、守护程序已启动以及网络是否正常运行。如果守护程序已崩溃，则守护程序日志文件 ( /var/log/ceph/ceph-osd.*) 可能包含调试信息。

（例如 OSD_HOST_DOWN、OSD_ROOT_DOWN）

特定 CRUSH 子树中的所有 OSD 都被标记为 down，例如主机上的所有 OSD。

在 CRUSH 地图层次结构中引用了 OSD，但不存在。

可以通过以下方式从 CRUSH 层次结构中删除 OSD：

ceph osd crush rm osd.<id>

Nearfull、backfillfull、full和/或failsafe_full的利用率阈值没有上升。特别是，我们期望 nearfull < backfillfull、backfillfull < full 和 full < failsafe_full。

可以通过以下方式调整阈值：

ceph osd set-nearfull-ratio <ratio>
ceph osd set-backfillfull-ratio <ratio>
ceph osd set-full-ratio <ratio>

一个或多个 OSD 已超过完整阈值并阻止集群为写入提供服务。

可以通过以下方式检查池的利用率：

ceph df

当前定义的完整比率可以通过以下方式查看：

ceph osd dump | grep full_ratio

恢复写入可用性的短期解决方法是将完整阈值提高少量：

ceph osd set-full-ratio <ratio>

应通过部署更多 OSD 将新存储添加到集群中，或者应删除现有数据以释放空间。

一个或多个 OSD 已超过backfillfull阈值，这将阻止允许数据重新平衡到此设备。这是一个早期警告，表明重新平衡可能无法完成并且集群即将满员。

可以通过以下方式检查池的利用率：

ceph df

一个或多个 OSD 已超过接近满阈值。这是集群即将满员的早期警告。

可以通过以下方式检查池的利用率：

ceph df

已设置一个或多个感兴趣的集群标志。这些标志包括：

full- 集群被标记为已满，无法提供写入服务

pauserd , pausewr - 暂停读取或写入

noup - 不允许启动 OSD

nodown - 忽略 OSD 故障报告，因此监视器不会将 OSD 标记为关闭

noin - 之前标记为out的 OSD在启动时不会被标记回in

noout - 在配置的时间间隔后，关闭的 OSD 不会自动被标记出来

nobackfill , norecover , norebalance - 恢复或数据重新平衡被暂停

noscrub , nodeep_scrub - 清理被禁用

notieragent - 缓存分层活动暂停

除了full，这些标志可以通过以下方式设置或清除：

ceph osd set <flag>
ceph osd unset <flag>

一个或多个 OSD 或 CRUSH {nodes,device classes} 设置了一个感兴趣的标志。这些标志包括：

noup : 这些 OSD 不允许启动

nodown : 这些 OSD 的故障报告将被忽略

noin：如果这些 OSD 之前在失败后被自动标记为out，则它们在启动时不会被标记为in

noout：如果这些 OSD 关闭，它们不会 在配置的时间间隔后自动被标记out

这些标志可以通过以下方式批量设置和清除：

ceph osd set-group <flags> <who>
ceph osd unset-group <flags> <who>

例如，

ceph osd set-group noup,noout osd.0 osd.1
ceph osd unset-group noup,noout osd.0 osd.1
ceph osd set-group noup,noout host-foo
ceph osd unset-group noup,noout host-foo
ceph osd set-group noup,noout class-hdd
ceph osd unset-group noup,noout class-hdd

CRUSH 图使用非常旧的设置，应该更新。在不触发此健康警告的情况下可以使用的最旧的可调参数（即可以连接到集群的最旧的客户端版本）由mon_crush_min_required_version配置选项确定。有关详细信息，请参阅可调参数。

CRUSH 图使用一种较旧的非最佳方法来计算straw存储桶的中间权重值。

应该更新 CRUSH 图以使用更新的方法 ( straw_calc_version=1)。有关详细信息，请参阅 可调参数。

一个或多个缓存池未配置命中集以跟踪利用率，这将阻止分层代理识别冷对象以从缓存中刷新和驱逐。

命中集可以在缓存池上配置：

ceph osd pool set <poolname> hit_set_type <type>
ceph osd pool set <poolname> hit_set_period <period-in-seconds>
ceph osd pool set <poolname> hit_set_count <number-of-hitsets>
ceph osd pool set <poolname> hit_set_fpp <target-false-positive-rate>

没有 pre-luminous v12.y.z OSD 正在运行，但sortbitwise尚未设置标志。

该sortbitwise标志必须在 luminous v12.y.z 或更新的 OSD 可以启动之前设置。您可以通过以下方式安全地设置标志：

ceph osd set sortbitwise

一个或多个池已达到其配额并且不再允许写入。

可以通过以下方式查看池配额和利用率：

ceph df detail

您可以通过以下方式提高池配额：

ceph osd pool set-quota <poolname> max_objects <num-objects>
ceph osd pool set-quota <poolname> max_bytes <num-bytes>

或删除一些现有数据以降低利用率。

一个或多个使用 BlueStore 后端的 OSD 已被分配 db分区（元数据的存储空间，通常在较快的设备上），但该空间已被填满，因此元数据“溢出”到正常的慢速设备上。这不一定是错误情况甚至是意外情况，但如果管理员期望所有元数据都适合更快的设备，则表明没有提供足够的空间。

可以通过以下方式在所有 OSD 上禁用此警告：

ceph config set osd bluestore_warn_on_bluefs_spillover false

或者，可以通过以下方式在特定 OSD 上禁用它：

ceph config set osd.123 bluestore_warn_on_bluefs_spillover false

为了提供更多的元数据空间，可以销毁和重新配置相关 OSD。这将涉及数据迁移和恢复。

也可以扩展支持 数据库存储的 LVM 逻辑卷。如果底层 LV 已经扩展，需要停止 OSD 守护进程，并且 BlueFS 通过以下方式通知设备大小的变化：

ceph-bluestore-tool bluefs-bdev-expand --path /var/lib/ceph/osd/ceph-$ID

要检查 BlueFS 有多少可用空间，请执行以下操作：

ceph daemon osd.123 bluestore bluefs available

这将输出最多 3 个值：BDEV_DB free、BDEV_SLOW free和 available_from_bluestore。BDEV_DB和BDEV_SLOW报告 BlueFS 已获取并被视为空闲的空间量。值available_from_bluestore 表示BlueStore 将更多空间让给BlueFS 的能力。此值与 BlueStore 可用空间量不同是正常的，因为 BlueFS 分配单元通常大于 BlueStore 分配单元。这意味着 BlueFS 只能接受部分 BlueStore 可用空间。

如果 BlueFS 可用空间不足，并且 available_from_bluestore 很少，则可以考虑减少 BlueFS 分配单元的大小。要在分配单元不同时模拟可用空间，请执行以下操作：

ceph daemon osd.123 bluestore bluefs available <alloc-unit-size>

随着 BlueStore 工作，底层存储上的可用空间将变得碎片化。这是正常且不可避免的，但过多的碎片会导致速度变慢。要检查 BlueStore 碎片，可以执行以下操作：

ceph daemon osd.123 bluestore allocator score block

分数在 [0-1] 范围内给出。[0.0 .. 0.4] 微小碎片 [0.4 .. 0.7] 小，可接受的碎片 [0.7 .. 0.9] 相当大，但安全碎片 [0.9 .. 1.0] 严重碎片，可能会影响 BlueFS 从 BlueStore 获取空间的能力。

如果需要碎片的详细报告，请执行以下操作：

ceph daemon osd.123 bluestore allocator dump block

如果在处理没有运行碎片的 OSD 进程时，可以使用ceph-bluestore-tool检查。获取碎片分数：

ceph-bluestore-tool --path /var/lib/ceph/osd/ceph-123 --allocator block free-score

并转储详细的空闲块：

ceph-bluestore-tool --path /var/lib/ceph/osd/ceph-123 --allocator block free-dump

在 Nautilus 版本中，BlueStore 在每个池的粒度基础上跟踪其内部使用统计数据，并且一个或多个 OSD 具有在 Nautilus 之前创建的 BlueStore 卷。如果所有OSD 都比 Nautilus 旧，这仅意味着每个池的指标不可用。但是，如果混合使用了 pre-Nautilus 和 post-Nautilus OSD，则ceph df报告的集群使用情况统计信息将不准确。

可以通过停止每个 OSD、运行修复操作并重新启动它来更新旧的 OSD 以使用新的使用跟踪方案。例如，如果osd.123需要更新：

systemctl stop ceph-osd@123
ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-123
systemctl start ceph-osd@123

可以通过以下方式禁用此警告：

ceph config set global bluestore_warn_on_legacy_statfs false

从 Octopus 版本开始，BlueStore 按池跟踪 omap 空间利用率，并且一个或多个 OSD 具有在 Octopus 之前创建的卷。如果所有 OSD 都没有在启用新跟踪的情况下运行 BlueStore，则集群将根据最近的 deep-scrub 报告每个池的 omap 使用情况和近似值。

可以通过停止每个 OSD、运行修复操作并重新启动它来更新旧 OSD 以按池跟踪。例如，如果 osd.123需要更新：

systemctl stop ceph-osd@123
ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-123
systemctl start ceph-osd@123

可以通过以下方式禁用此警告：

ceph config set global bluestore_warn_on_no_per_pool_omap false

从 Pacific 版本开始，BlueStore 会按 PG 跟踪 omap 空间利用率，并且一个或多个 OSD 具有在 Pacific 之前创建的卷。Per-PG omap 可以在 PG 迁移时更快地删除 PG。

PG 可以通过停止每个 OSD、运行修复操作并重新启动它来更新旧 OSD 以进行跟踪。例如，如果 osd.123需要更新：

systemctl stop ceph-osd@123
ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-123
systemctl start ceph-osd@123

可以通过以下方式禁用此警告：

ceph config set global bluestore_warn_on_no_per_pg_omap false

一个或多个使用 BlueStore 的 OSD 在物理设备的大小和跟踪其大小的元数据之间存在内部不一致。这可能会导致 OSD 将来崩溃。

有问题的 OSD 应该被销毁并重新配置。应注意一次只执行一个 OSD，并且不会使任何数据面临风险。例如，如果 osd$N有错误，则：

ceph osd out osd.$N
while ! ceph osd safe-to-destroy osd.$N ; do sleep 1m ; done
ceph osd destroy osd.$N
ceph-volume lvm zap /path/to/device
ceph-volume lvm create --osd-id $N --data /path/to/device

一个或多个 OSD 无法加载 BlueStore 压缩插件。这可能是由于安装损坏，其中ceph-osd 二进制文件与压缩插件不匹配，或者最近的升级不包括重新启动ceph-osd守护程序。

验证运行相关 OSD 的主机上的软件包是否已正确安装，并且 OSD 守护程序已重新启动。如果问题仍然存在，请检查 OSD 日志以获取有关问题根源的任何线索。

一个或多个使用 BlueStore 的 OSD 检测主设备上的虚假读取错误。BlueStore 通过重试磁盘读取已从这些错误中恢复。虽然这可能会显示底层硬件、I/O 子系统等存在一些问题。理论上这可能会导致永久性数据损坏。关于根本原因的一些观察可以在 https://tracker.ceph.com/issues/22464 找到。

此警报不需要立即响应，但相应的主机可能需要额外注意，例如升级到最新的操作系统/内核版本和硬件资源利用率监控。

可以通过以下方式在所有 OSD 上禁用此警告：

ceph config set osd bluestore_warn_on_spurious_read_errors false

或者，可以通过以下方式在特定 OSD 上禁用它：

ceph config set osd.123 bluestore_warn_on_spurious_read_errors false

设备健康

预计一台或多台设备将很快发生故障，其中警告阈值由mgr/devicehealth/warn_threshold 配置选项控制。

此警告仅适用于当前标记为“in”的 OSD，因此对该故障的预期响应是将设备标记为“out”，以便将数据迁移出设备，然后从系统中删除硬件。请注意，如果mgr/devicehealth/self_heal基于mgr/devicehealth/mark_out_threshold.

可以通过以下方式检查设备运行状况：

ceph device info <device-id>

设备预期寿命由MGR运行的预测模型或外部工具通过以下命令设置：

ceph device set-life-expectancy <device-id> <from> <to>

您可以手动更改存储的预期寿命，但这通常不会完成任何事情，因为最初设置的任何工具都可能会再次设置它，并且更改存储的值不会影响硬件设备的实际运行状况。

一台或多台设备预计很快会发生故障，并已被标记为“out”基于 mgr/devicehealth/mark_out_threshold的集群，但它仍在参与另外一个 PG。这可能是因为它最近才被标记为“out”并且数据仍在迁移，或者因为某些原因无法迁移数据（例如，集群快满了，或者 CRUSH 层次结构中没有另一个合适的OSD 也可以迁移数据）。

可以通过禁用自我修复行为（设置mgr/devicehealth/self_heal为 false）、调整 mgr/devicehealth/mark_out_threshold或解决阻止数据从故障设备迁移的原因来消除此消息。

太多的设备预计很快就会出现故障，并且 mgr/devicehealth/self_heal启用了该行为，这样标记所有出现故障的设备将超过集群 mon_osd_min_in_ratio比例，从而防止太多的 OSD 被自动标记为“out”。

这通常表明您的集群中的太多设备预计很快就会发生故障，您应该采取措施在太多设备发生故障和数据丢失之前添加更新（更健康）的设备。

也可以通过调整参数（如 mon_osd_min_in_ratio或mgr/devicehealth/mark_out_threshold）来使运行状况消息静音，但请注意，这将增加集群中不可恢复的数据丢失的可能性。

数据健康（池和归置组）

数据可用性降低，这意味着集群无法为集群中某些数据的潜在读取或写入请求提供服务。具体来说，一个或多个 PG 处于不允许服务 IO 请求的状态。有问题的 PG 状态包括对等、 陈旧、不完整和缺乏活动（如果这些条件没有迅速清除）。

有关哪些 PG 受到影响的详细信息，请参阅：

ceph health detail

在大多数情况下，根本原因是一个或多个 OSD 当前已关闭；参见OSD_DOWN上面的讨论。

可以通过以下方式查询特定问题 PG 的状态：

ceph tell <pgid> query

某些数据的数据冗余减少了，这意味着集群没有所需数量的所有数据（对于复制池）或纠删码片段（对于纠删码池）的副本。具体来说，一个或多个 PG：

设置了degraded或undersized标志，这意味着集群中没有足够的该归置组实例；

已经有一段时间没有设置clean的标志了。

有关哪些 PG 受到影响的详细信息，请参阅：

ceph health detail

在大多数情况下，根本原因是一个或多个 OSD 当前已关闭；见OSD_DOWN上面的讨论。

可以通过以下方式查询特定问题 PG 的状态：

ceph tell <pgid> query

由于集群中的可用空间不足，某些数据的数据冗余可能会减少或面临风险。具体来说，一个或多个 PG 设置了 recovery_toofull标志，这意味着集群无法迁移或恢复数据，因为一个或多个 OSD 超过了full阈值。

有关解决此情况的步骤，请参阅上面对 OSD_FULL的讨论。

由于集群中的可用空间不足，某些数据的数据冗余可能会减少或面临风险。具体来说，一个或多个 PG 设置了 backfill_toofull标志，这意味着集群无法迁移或恢复数据，因为一个或多个 OSD 高于backfillfull阈值。

有关解决此问题的步骤，请参阅上面对 OSD_BACKFILLFULL的讨论。

数据清洗发现了集群中数据一致性的一些问题。具体来说，一个或多个 PG 具有不一致或 设置了snaptrim_error标志，表示较早的清理操作发现了问题，或者设置了修复标志，这意味着当前正在进行针对此类不一致的修复。

有关详细信息，请参阅修复 PG 不一致。

最近的 OSD 清理发现了不一致之处。此错误通常与PG_DAMAGED配对（见上文）。

有关详细信息，请参阅修复 PG 不一致。

当发生读取错误并且另一个副本可用时，它用于立即修复错误，以便客户端可以获取对象数据。Scrub 处理静态数据的错误。为了识别没有出现擦洗错误的可能故障磁盘，维护了读取修复计数。如果它超过配置值阈值mon_osd_warn_num_repaired默认 10，则会生成此运行状况警告。

一个或多个池包含由 osd_deep_scrub_large_omap_object_key_threshold（用于确定大型 omap 对象的键数的 osd_deep_scrub_large_omap_object_value_sum_threshold阈值）或（用于确定大型 omap 对象的所有键值的总大小（字节）的阈值）或两者确定的大型 omap 对象。可以通过在集群日志中搜索“找到的大型 omap 对象”来找到有关对象名称、键计数和大小（以字节为单位）的更多信息。大型 omap 对象可能是由未启用自动重新分片的 RGW 存储桶索引对象引起的。有关重新分片的更多信息，请参阅RGW 动态存储桶索引重新分片。

可以通过以下方式调整阈值：

ceph config set osd osd_deep_scrub_large_omap_object_key_threshold <keys>
ceph config set osd osd_deep_scrub_large_omap_object_value_sum_threshold <bytes>

缓存层池几乎已满。此上下文中的完整由缓存池上的target_max_bytes和target_max_objects属性确定。一旦池达到目标阈值，对池的写入请求可能会在数据被刷新并从缓存中逐出时阻塞，这种状态通常会导致非常高的延迟和较差的性能。

缓存池目标大小可以通过以下方式调整：

ceph osd pool set <cache-pool-name> target_max_bytes <bytes>
ceph osd pool set <cache-pool-name> target_max_objects <objects>

由于基础层的可用性或性能降低，或整体集群负载降低，正常的缓存刷新和驱逐活动也可能受到限制。

集群中使用的 PG 数量低于mon_pg_warn_min_per_osd每个 OSD 的可配置 PG 阈值。这可能导致集群中 OSD 之间的数据分布和平衡欠佳，同样会降低整体性能。

如果尚未创建数据池，这可能是预期的情况。

可以增加现有池的 PG 计数，也可以创建新池。有关详细信息，请参阅选择归置组的数量。

一个或多个池的pg_num值不是 2 的幂。尽管这并非完全不正确，但它确实会导致数据分布不平衡，因为某些 PG 的数据量大约是其他 PG 的两倍。

pg_num这很容易通过将受影响池的值设置为附近的 2 次方来纠正：

ceph osd pool set <pool-name> pg_num <value>

可以通过以下方式禁用此健康警告：

ceph config set global mon_warn_on_pool_pg_num_not_power_of_two false

根据当前存储在池中的数据量，一个或多个池可能应该有更多的 PG。这可能导致集群中 OSD 之间的数据分布和平衡欠佳，同样会降低整体性能。如果池上 pg_autoscale_mode的属性设置为 warn，则会生成此警告。

要禁用警告，您可以完全禁用池的 PG 自动缩放：

ceph osd pool set <pool-name> pg_autoscale_mode off

要让集群自动调整 PG 的数量，请：

ceph osd pool set <pool-name> pg_autoscale_mode on

您还可以手动将池的 PG 数量设置为推荐数量：

ceph osd pool set <pool-name> pg_num <new-pg-num>

有关详细信息，请参阅选择归置组的数量和 自动缩放归置组。

集群中使用的 PG 数量高于mon_max_pg_per_osd每个 OSD 的可配置 PG 阈值。如果超过此阈值，集群将不允许创建新池、增加池pg_num或增加池副本（其中任何一个都会导致集群中出现更多 PG）。大量的 PG 会导致 OSD 守护进程的内存利用率更高，集群状态更改（如 OSD 重新启动、添加或删除）后的对等连接速度变慢，以及 Manager 和 Monitor 守护进程的负载更高。

缓解该问题的最简单方法是通过添加更多硬件来增加集群中 OSD 的数量。请注意，用于此运行状况检查的 OSD 计数是“in” OSD 的数量，因此将“out” OSD 标记为“in”（如果有）也可以提供帮助：

ceph osd in <osd id(s)>

有关详细信息，请参阅选择归置组的数量。

根据当前存储在池中的数据量，一个或多个池可能应该有更多的 PG。这会导致 OSD 守护进程的内存利用率更高，集群状态更改（如 OSD 重新启动、添加或删除）后的对等连接速度变慢，以及 Manager 和 Monitor 守护进程的负载更高。如果池上pg_autoscale_mode的属性设置为 warn，则会生成此警告 。

要禁用警告，您可以完全禁用池的 PG 自动缩放：

ceph osd pool set <pool-name> pg_autoscale_mode off

要让集群自动调整 PG 的数量，请：

ceph osd pool set <pool-name> pg_autoscale_mode on

您还可以手动将池的 PG 数量设置为推荐数量：

ceph osd pool set <pool-name> pg_num <new-pg-num>

有关详细信息，请参阅选择归置组的数量和 自动缩放归置组。

一个或多个池具有一个target_size_bytes属性集来估计池的预期大小，但该值超过了可用存储总量（单独或与其他池的实际使用情况相结合）。

这通常表明target_size_bytes池的值太大，应通过以下方式减小或设置为零：

ceph osd pool set <pool-name> target_size_bytes 0

有关更多信息，请参阅指定预期池大小。

一个或多个池具有两者target_size_bytes并 target_size_ratio设置为估计池的预期大小。这些属性中只有一个应该是非零的。如果两者都设置， 则target_size_ratio优先并且target_size_bytes被忽略。

要重置target_size_bytes为零：

ceph osd pool set <pool-name> target_size_bytes 0

有关更多信息，请参阅指定预期池大小。

集群中的 OSD 数量低于可配置阈值osd_pool_default_size.

一个或多个池的pgp_num值小于pg_num。这通常表明 PG 计数增加而没有增加放置行为。

有时会故意这样做，以便在调整 PG 计数时将拆分步骤与更改时所需的数据迁移分开pgp_num。

这通常通过设置pgp_num为 match来解决pg_num，触发数据迁移，使用：

ceph osd pool set <pool> pgp_num <pg-num-value>

一个或多个池的每个 PG 的平均对象数明显高于整个集群的平均值。具体阈值由mon_pg_warn_max_object_skew 配置值控制。

这通常表明包含集群中大部分数据的池的 PG 太少，和/或其他不包含那么多数据的池的 PG 太多。请参阅上面对TOO_MANY_PGS的讨论 。

通过调整管理器上的mon_pg_warn_max_object_skew配置选项，可以提高阈值以使健康警告静音。

存在一个包含一个或多个对象但尚未标记为供特定应用程序使用的池。

通过标记池以供应用程序使用来解决此警告。例如，如果池被 RBD 使用，则：

rbd pool init <poolname>

如果自定义应用程序“foo”正在使用该池，您还可以通过低级命令进行标记：

ceph osd pool application enable foo

有关更多信息，请参阅将池关联到应用程序。

一个或多个池已达到（或非常接近）其配额。触发此错误条件的阈值由 mon_pool_quota_crit_threshold 配置选项控制。

池配额可以通过以下方式向上或向下调整（或删除）：

ceph osd pool set-quota <pool> max_bytes <bytes>
ceph osd pool set-quota <pool> max_objects <objects>

将配额值设置为 0 将禁用配额。

ceph osd pool set-quota <pool> max_bytes 0
ceph osd pool set-quota <pool> max_objects 0

一个或多个池正在接近配置的充满度阈值。

可以触发此警告条件的一个阈值是 mon_pool_quota_warn_threshold 配置选项。

池配额可以通过以下方式向上或向下调整（或删除）：

ceph osd pool set-quota <pool> max_bytes <bytes>
ceph osd pool set-quota <pool> max_objects <objects>

将配额值设置为 0 将禁用配额。

可以触发上述两个警告条件的其他阈值是 mon_osd_nearfull_ratio和mon_osd_full_ratio。有关详细信息和解决方案，请访问 存储容量和无可用驱动器空间文档。

集群中的一个或多个对象未存储在集群希望存储的节点上。这表明由于最近的一些集群更改而导致的数据迁移尚未完成。

错位数据本身并不是危险情况；数据一致性永远不会受到威胁，并且在出现所需数量的新副本（在所需位置）之前，永远不会删除对象的旧副本。

找不到集群中的一个或多个对象。具体来说，OSD 知道应该存在一个新的或更新的对象副本，但在当前在线的 OSD 上还没有找到该对象版本的副本。

对未找到对象的读取或写入请求将被阻塞。

理想情况下，可以使具有未找到对象的最新副本的停机 OSD 重新联机。候选 OSD 可以从负责未找到对象的 PG 的对等状态中识别：

ceph tell <pgid> query

如果对象的最新副本不可用，则可以通知集群回滚到对象的先前版本。有关详细信息，请参阅 未找到的对象。

一个或多个 OSD 或监视器请求需要很长时间来处理。这可能表示负载过大、存储设备缓慢或软件错误。

可以使用以下命令查询相关守护程序的请求队列，从守护程序的主机执行：

ceph daemon osd.<id> ops

可以通过以下方式查看最近最慢请求的摘要：

ceph daemon osd.<id> dump_historic_ops

可以通过以下方式找到 OSD 的位置：

ceph osd find osd.<id>

一个或多个 PG 最近没有被擦洗。PG 通常会在 osd_scrub_max_interval全局指定的每个配置间隔内进行清理。这个时间间隔可以在每个池的基础上用 scrub_max_interval 覆盖。当 mon_warn_pg_not_scrubbed_ratio间隔百分比自到期后未进行清理时，将触发警告。

如果 PG 没有被标记为clean ，它们将不会擦洗，如果它们放错位置或降级可能会发生这种情况（参见上面的PG_AVAILABILITY和 PG_DEGRADED）。

您可以手动启动清理 PG 的清理：

ceph pg scrub <pgid>

一个或多个 PG 最近没有被深度擦洗。PG 通常每秒钟清理一次，并且当间隔的osd_deep_scrub_interval百分比自到期后没有清理时触发此mon_warn_pg_not_deep_scrubbed_ratio警告。

如果 PG 没有标记为clean ，它们将不会（深度）擦洗，如果它们放错位置或降级，则可能会发生这种情况（请参阅上面的PG_AVAILABILITY和 PG_DEGRADED）。

您可以手动启动清理 PG 的清理：

ceph pg deep-scrub <pgid>

一个或多个 PG 的快照修剪队列已超过配置的警告阈值。这表明最近删除了大量快照，或者 OSD 无法足够快地修剪快照以跟上新快照删除的速度。

警告阈值由 mon_osd_snap_trim_queue_warn_on选项控制（默认值：32768）。

如果 OSD 负载过大且无法跟上其后台工作，或者如果 OSD 的内部元数据数据库严重碎片化且无法执行，则可能会触发此警告。它还可能表明 OSD 存在其他一些性能问题。

快照修剪队列的确切大小由 ceph pg ls -f json-detail的 snaptrimq_len字段报告。

杂项

一个或多个 Ceph 守护进程最近发生了崩溃，并且该崩溃尚未被管理员存档（确认）。这可能表示软件错误、硬件问题（例如，故障磁盘）或一些其他问题。

可以列出新的崩溃：

ceph crash ls-new

可以通过以下方式检查有关特定崩溃的信息：

ceph crash info <crash-id>

可以通过“归档”崩溃（可能在管理员检查后）来消除此警告，这样它就不会生成此警告：

ceph crash archive <crash-id>

同样，所有新的崩溃都可以存档：

ceph crash archive-all

存档的崩溃仍然可以通过ceph crash ls可见，但ceph crash ls-new不可见。

“recent”表示的时间段由选项mgr/crash/warn_recent_interval控制 （默认值：两周）。

可以通过以下方式完全禁用这些警告：

ceph config set mgr/crash/warn_recent_interval 0

遥测已启用，但遥测报告的内容自那时起已更改，因此不会发送遥测报告。

Ceph 开发人员会定期修改遥测功能以包含新的有用信息，或删除发现无用或敏感的信息。如果报告中包含任何新信息，Ceph 将要求管理员重新启用遥测，以确保他们有机会（重新）查看将共享的信息。

要查看遥测报告的内容，请：

ceph telemetry show

请注意，遥测报告由几个可以独立启用或禁用的可选通道组成。有关详细信息，请参阅 遥测模块。

要重新启用遥测（并使此警告消失），请：

ceph telemetry on

要禁用遥测（并使此警告消失），请：

ceph telemetry off

一个或多个身份验证用户具有监视器无法解析的功能。这通常表明用户将无权使用一种或多种守护程序类型执行任何操作。

如果功能是使用未正确验证其语法的旧版 Ceph 设置的，或者功能的语法已更改，则此错误很可能在升级后发生。

可以通过以下方式删除相关用户：

ceph auth rm <entity-name>

（这将解决健康警报，但显然客户端将无法以该用户身份进行身份验证。）

或者，可以使用以下方式更新用户的功能：

ceph auth <entity-name> <daemon-type> <caps> [<daemon-type> <caps> ...]

有关身份验证功能的更多信息，请参阅用户管理。

mon_osd_down_out_interval选项设置为0，这意味着系统不会在 OSD 发生故障后自动执行任何修复或修复操作。相反，管理员（或其他一些外部实体）需要手动将 OSD 标记为“out”（即 ceph osd out ）以触发恢复。

此选项通常设置为 5 或 10 分钟——足够主机重启或重启的时间。

可以通过将 mon_warn_on_osd_down_out_interval_zero设置为 false 来消除此警告：

ceph config global mon mon_warn_on_osd_down_out_interval_zero false

仪表板调试模式已启用。这意味着，如果在处理 REST API 请求时出现错误，HTTP 错误响应将包含 Python 回溯。在生产环境中应禁用此行为，因为此类回溯可能包含并公开敏感信息。

可以通过以下方式禁用调试模式：

ceph dashboard debug disable

标签：ceph,set,osd,Ceph,集群,PG,健康检查,OSD
来源： https://www.cnblogs.com/varden/p/15937057.html