附录 B. Ceph 集群的健康消息
Red Hat Ceph Storage 集群可以引发的健康信息是有限的。它们定义为具有唯一标识符的健康检查。标识符是一个制表伪可读字符串,旨在使工具能够理解健康检查,并以反应其含义的方式呈现它们。
健康代码 | 描述 |
---|---|
| 如果旧版本的 Ceph 在任何守护进程上运行,则警告。如果检测到多个版本,它将生成一个健康错误。 |
| 一个或多个 Ceph 监控守护进程当前为 down。 |
|
运行 |
|
|
| 一个或多个 Ceph 监控器在磁盘空间上较低。 |
| 一个或多个 Ceph 监控器在磁盘空间上至关重要。 |
| 一个或多个 Ceph 监控器的数据库大小非常大。 |
|
一个或多个客户端或守护进程连接到存储集群,在重新连接到 Ceph monitor 时,这些集群不会安全地回收其 |
|
Ceph 目前配置为允许客户端使用不安全的进程重新连接到监控器,以回收其之前的 |
健康代码 | 描述 |
---|---|
| 所有 Ceph Manager 守护进程当前都处于停机状态。 |
| 启用的 Ceph Manager 模块失败其依赖项检查。 |
| Ceph Manager 模块会出现意外错误。通常,这意味着从模块的服务函数中引发未处理的异常。 |
健康代码 | 描述 |
---|---|
| 一个或多个 OSD 已标记为 down。 |
| 特定 CRUSH 子树中的所有 OSD 都标记为 down,如主机上的所有 OSD。例如,OSD_HOST_DOWN 和 OSD_ROOT_DOWN |
|
OSD 在 CRUSH map 层次结构中引用,但不存在。运行 |
|
nearfull, backfillfull, full, 或, failsafefull 的利用阈值不是升序。通过运行 |
|
一个或多个 OSD 已超过完整阈值,导致存储集群无法提供写入服务。通过一个小的 |
| 一个或多个 OSD 已超过 backfillfull 阈值,这将防止数据重新平衡到这个设备。 |
| 一个或多个 OSD 已超过 nearfull 阈值。 |
|
设置了一个或多个感兴趣的存储集群标志。这些标志包括 full,pauserd,pausewr,noup,nodown,noin,noout,nobackfill,norecover,norebalance,noscrub,nodeep_scrub, 和 notieragent。除了 full,标记可以通过 |
| 一个或多个 OSD 或 CRUSH 设置了所需的标记。这些标志包括 noup、nodown、noin 和 noout。 |
| CRUSH map 使用非常旧的设置,应更新。 |
|
CRUSH 映射使用旧的、非最佳方法计算 |
|
一个或多个缓存池没有配置为跟踪利用率,这会阻止分层代理识别冷对象以清空并从缓存中驱除。使用 |
|
|
|
一个或多个池已达到其配额,不再允许写入。使用 |
|
使用 BlueStore 后端的一个或多个 OSD 被分配 db 分区,但空间已填满,因此元数据已"中断"到正常较慢的设备。使用 |
| 此输出提供了三个值,即 BDEV_DB free、BDEV_SLOW free 和 available_from_bluestore。 |
|
如果 BlueStore 文件系统(BlueFS)在可用的空闲空间上运行较低,且有些 |
| 因为 BlueStore 在底层存储上工作可释放空间。这是正常现象,但过度的碎片将导致减慢。 |
|
BlueStore 根据每个池粒度跟踪其内部使用量统计信息,一个或多个 OSD 有 BlueStore 卷。使用 |
|
BlueStore 按池跟踪 omap 空间利用率。使用 |
|
BlueStore 跟踪 PG 的 omap 空间利用率。使用 |
| 使用 BlueStore 的一个或多个 OSD 在物理设备的大小和元数据跟踪其大小之间存在内部不一致。 |
|
一个或多个 OSD 无法加载 BlueStore 压缩插件。这可能是由安装中断造成的,其中 |
| 使用 BlueStore 的一个或多个 OSD 在主设备上检测到错误的读错误。BlueStore 已通过重试磁盘读取从这些错误中恢复。 |
健康代码 | 描述 |
---|---|
|
应该很快失败一个或多个设备,其中警告阈值由 |
|
应该很快失败一个或多个设备,并根据 |
|
应该很快失败太多设备,并且启用了 |
健康代码 | 描述 |
---|---|
| 数据可用性会降低,这意味着存储集群无法为集群中的某些数据提供潜在的读写请求。 |
| 一些数据的数据冗余会降低,这意味着存储集群没有复制池或纠删代码片段所需的副本数。 |
|
由于存储集群中缺少可用空间,数据冗余可能会减少或面临风险,特别是一个或多个 PG 设置了 |
|
由于存储集群中缺少可用空间,数据冗余可能会减少或面临风险,特别是一个或多个 PG 设置了 |
|
数据清理在存储集群中发现了一些数据一致性问题,特别是一个或多个 PG 设置了不一致或 |
| 最近的 OSD 清理存在未发生不一致的情况。 |
| 当出现读取错误并存在另一个副本时,可使用它立即修复错误,以便客户端可以获取对象数据。 |
|
一个或多个池包括大量 omap 对象,由 |
|
缓存层池几乎已满。使用 |
|
存储集群中使用的 PG 数量低于每个 OSD 的 |
|
一个或多个池带有值不是二的指数的 |
|
一个或多个池可能具有更多 PG,具体取决于池中当前存储的数据量。您可以使用 |
|
存储集群中使用的 PG 数量高于每个 OSD 的可配置阈值 |
|
一个或多个池可能具有更多 PG,具体取决于池中当前存储的数据量。您可以使用 |
|
一个或多个池将 |
|
一个或多个池同时设置了 |
|
存储集群中的 OSD 数量低于 |
|
一个或多个池带有值小于 |
|
一个或多个池每个 PG 的平均对象数量显著大于整个存储集群平均值。具体阈值由 |
|
存在一个池,其中包含一个或多个对象,但尚未标记供特定应用使用。通过标记具有 |
|
一个或多个池已达到其配额。触发此错误条件的阈值由 |
|
一个或多个池正在接近配置的全度阈值。使用 |
| 存储群集中的一个或多个对象不存储在存储器集群希望它存储的节点上。这表明,由于最近一些存储集群更改,数据迁移尚未完成。 |
| 存储集群中无法找到一个或多个对象,特别是 OSD 知道对象应存在新的或更新的副本,但当前在线的 OSD 上尚未找到该对象版本的副本。 |
| 一个或多个 OSD 或 monitor 的请求需要很长时间进行处理。这可能代表了极端负载、存储设备缓慢或软件漏洞。 |
|
最近没有清理一个或多个 PG。PG 通常会在全局范围内由 |
|
一个或多个 PG 最近没有深度清理。使用 |
| 一个或多个 PG 的快照修剪队列已超过配置的警告阈值。这表明最近删除了大量的快照,或者 OSD 无法足够快速地修剪快照,以跟上新快照删除的速度。 |
健康代码 | 描述 |
---|---|
| 一个或多个 Ceph 守护进程最近崩溃,并且管理员还没有确认崩溃。 |
| 遥测已经启用,但遥测报告的内容从那时起发生了变化,因此将不会发送遥测报告。 |
|
一个或多个身份验证用户具有不能被监控器解析的功能。使用 |
|
|
|
启用 Dashboard 调试模式。这意味着,如果在处理 REST API 请求时出现错误,HTTP 错误响应包含 Python 回溯。使用 |