4.2. 大多数常见 Ceph 监控错误
下表列出了 ceph 运行状况详细信息 命令返回或包含在 Ceph 日志中的最常见错误消息：这些表中提供了相应的部分的链接，这些部分解释了错误并指向修复问题的特定程序。
4.2.1. 先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
4.2.2. Ceph 监控错误消息
常见 Ceph monitor 错误消息和可能的修复表。
| 错误消息 | 请查看 |
|---|---|
|
| |
|
| |
|
| |
|
| |
4.2.3. Ceph 日志中的通用 Ceph monitor 错误消息
Ceph 日志中找到的常见 Ceph monitor 错误消息表，以及指向潜在修复的链接。
| 错误消息 | 日志文件 | 请查看 |
|---|---|---|
|
| 主集群日志 | |
|
| 主集群日志 | |
|
| 监控日志 | |
|
| 监控日志 | |
|
| 监控日志 |
4.2.4. Ceph monitor 超出仲裁数
个或多个 Ceph 监控器已标记为 down，但其他 Ceph 监控器仍然能够形成仲裁。此外，ceph 运行状况详情 命令返回类似如下的错误消息：
HEALTH_WARN 1 mons down, quorum 1,2 mon.b,mon.c mon.a (rank 0) addr 127.0.0.1:6789/0 is down (out of quorum)
此 Means 是什么
Ceph 将 Ceph monitor 标记为 down，原因有多种。
如果 ceph-mon 守护进程未在运行，它可能具有损坏的存储或者其他一些错误阻止守护进程启动。另外，/var/ 分区可能已满。因此，ceph -mon 无法对位于 /var/lib/ceph/mon-SHORT_HOST_NAME/store.db 的存储执行任何操作，并终止。
如果 ceph-mon 守护进程正在运行，但 Ceph monitor 没有仲裁并标记为 down，问题的原因取决于 Ceph monitor 状态：
-
如果 Ceph 监控器处于 探测 状态超过预期，则无法找到其他 Ceph 监控器。此问题可能是由网络问题造成的，或者 Ceph monitor 可以具有过时的 Ceph monitor map(
monmap)，并尝试访问错误的 IP 地址上的其他 Ceph 监控器。另外，如果monmap是最新的，Ceph monitor 的时钟可能无法同步。 - 如果 Ceph monitor 处于超过预期 状态的选择状态，Ceph 监控器的时钟可能无法同步。
- 如果 Ceph monitor 将自己的状态从 同步 更改为开 机和 返回，集群状态将会发展。这意味着，它生成的新 map 的速度要快于同步进程可以处理的速度。
- 如果 Ceph 监控器将自身标记为 领导 机或工作台， 那么它将确信它处于仲裁状态，而剩余的集群则确定它不是。此问题可能是时钟同步失败造成的。
要排除这个问题，请执行以下操作
验证
ceph-mon守护进程正在运行。如果没有，请启动它：[root@mon ~]# systemctl status ceph-mon@HOST_NAME [root@mon ~]# systemctl start ceph-mon@HOST_NAME
将
HOST_NAME替换为正在运行 守护进程的主机的短名称。不确定时使用 hostname -s命令。-
如果您无法启动
ceph-mon守护进程，请按照ceph-mon守护进程中的步骤启动。 -
如果您能够启动
ceph-mon守护进程但标记为down，请按照ceph-mon守护进程中的步骤运行，但标记为"down"。
ceph-mon Daemon 无法启动
-
默认情况下，检查位于
/var/log/ceph/ceph-mon.HOST_NAME.log的对应的 Ceph Monitor 日志。 如果日志中包含类似于下列错误消息的错误消息，Ceph monitor 可能具有损坏的存储：
Corruption: error in middle of record Corruption: 1 missing files; e.g.: /var/lib/ceph/mon/mon.0/store.db/1234567.ldb
若要修复此问题，可替换 Ceph monitor。请参阅 替换失败的 monitor。
如果日志包含类似如下的错误消息，
/var/分区可能已满。从/var/删除任何不必要的数据。Caught signal (Bus error)
重要不要手动从 monitor 目录中删除任何数据。而应使用
ceph-monstore-tool将它压缩。详情请参阅 紧凑 Ceph monitor 存储。- 如果您看到任何其他错误消息，请打开支持票据。有关 详细信息，请参阅联系红帽支持团队。
ceph-mon Daemon 运行，但 Still Marked 为 down
在超出仲裁的 Ceph Monitor 主机中，使用
mon_status命令检查其状态：[root@mon ~]# ceph daemon ID mon_status使用 Ceph monitor 的
ID替换 ID，例如：[root@mon ~]# ceph daemon mon.a mon_status
如果状态为 probing ， 请验证
mon_status输出中其他 Ceph monitor 的位置。-
如果地址不正确，Ceph monitor 具有不正确的 Ceph monitor map(
monmap)。若要修复此问题，请参阅注入 Ceph monitor map。 - 如果地址正确，请验证 Ceph 监控时钟是否已同步。详情请查看 Clock skew。另外，对任何网络问题进行故障排除，请参阅 对网络进行故障排除以了解详细信息。
-
如果地址不正确，Ceph monitor 具有不正确的 Ceph monitor map(
- 如果状态为选中状态 ， 请验证 Ceph 监控时钟是否已同步。详情请查看 Clock skew。
- 如果状态从 选择 同步变为 同步，请打开支持票据。有关 详细信息，请参阅联系红帽支持团队。
- 如果 Ceph monitor 是 领导 机或工作 机， 请验证 Ceph 监控时钟是否已同步。详情请查看 Clock skew。如果同步时钟无法解决问题，请打开支持问题单。有关 详细信息，请参阅联系红帽支持团队。
其它资源
- 请参阅 了解 Ceph Monitor 状态
- 《红帽 Ceph 存储 4 管理指南 》中的按实例启动 Ceph 守护进程一节中的启动、停止和重新启动 Ceph 守护进程部分
- 《红帽 Ceph 存储 4 管理指南 》中的使用 Ceph 管理套接字 一节
4.2.5. 时钟偏移
Ceph monitor 超出仲裁数，ceph 运行状况详情 命令输出包含类似于如下的错误消息：
mon.a (rank 0) addr 127.0.0.1:6789/0 is down (out of quorum) mon.a addr 127.0.0.1:6789/0 clock skew 0.08235s > max 0.05s (latency 0.0045s)
此外，Ceph 日志包含类似如下的错误消息：
2015-06-04 07:28:32.035795 7f806062e700 0 log [WRN] : mon.a 127.0.0.1:6789/0 clock skew 0.14s > max 0.05s 2015-06-04 04:31:25.773235 7f4997663700 0 log [WRN] : message from mon.1 was stamped 0.186257s in the future, clocks not synchronized
此 Means 是什么
时钟偏移 错误消息表示 Ceph 监控器的时钟没有同步。时钟同步很重要，因为 Ceph monitor 依赖于时间精度，如果时钟不同步，其行为不可预知。
mon_clock_drift_allowed 参数决定时钟之间的差别是 tolerated。默认情况下，此参数设置为 0.05 秒。
在未进行之前测试的情况下，请勿更改 mon_clock_drift_allowed 的默认值。更改此值可能会影响 Ceph 监控器和 Ceph 存储群集的稳定性。
时钟偏移错误的 可能原因包括网络时间协议(NTP)同步问题（如果已配置）。此外，时间同步无法在虚拟机上部署的 Ceph 监控器上正常工作。
要排除这个问题，请执行以下操作
验证您的网络是否正常工作。详情请参阅对 网络问题进行故障排除。特别是，如果您使用 NTP，则对 NTP 客户端的任何问题进行故障排除。
- 如果您使用 chrony 作为 NTP，请参阅 基本 chrony NTP 故障排除部分。
-
如果使用
ntpd，请参阅 基本 NTP 故障排除。
如果您使用远程 NTP 服务器，请考虑在网络上部署您自己的 NTP 服务器。
- 详情请参阅为 Red Hat Enterprise Linux 8 配置基本系统设置 中的使用 Chrony 套件配置 NTP 章节。
- 请参见《Red Hat Enterprise Linux 7 系统管理员指南》 中的" 配置 NTP 使用 ntpd "一章。
Ceph 仅评估每五分钟的时间同步，因此修复问题与清除 时钟偏移 消息之间会有一个延迟。
4.2.6. Ceph 监控器存储太大
ceph health 命令返回类似如下的错误消息：
mon.ceph1 store is getting too big! 48031 MB >= 15360 MB -- 62% avail
此 Means 是什么
Ceph 监控存储实际上是一个 LevelDB 数据库，将条目存储为键值对。该数据库包含一个集群映射，默认位于 /var/lib/ceph/mon/CLUSTER_NAME-SHORT_HOST_NAME/store.db。
查询大型 monitor 存储可能需要时间。因此，Ceph monitor 在响应客户端查询时可能会延迟。
此外，如果 /var/ 分区已满，Ceph monitor 无法对存储执行任何写入操作并终止。如需了解对此问题进行故障排除的详细信息 ，请参阅 Ceph monitor 仲裁。
要排除这个问题，请执行以下操作
检查数据库的大小：
du -sch /var/lib/ceph/mon/CLUSTER_NAME-SHORT_HOST_NAME/store.db
指定集群的名称，以及运行
ceph-mon的主机的短主机名。示例
# du -sch /var/lib/ceph/mon/ceph-host1/store.db 47G /var/lib/ceph/mon/ceph-ceph1/store.db/ 47G total
- 紧凑 Ceph 监控存储.详情请参阅 紧凑 Ceph monitor 存储。
其它资源
4.2.7. 了解 Ceph 监控状态
mon_status 命令返回 Ceph monitor 的信息，例如：
- 状态
- 等级
- 选举时期
-
monitor map(
monmap)
如果 Ceph monitor 能够形成仲裁，请使用 mon_status 和 ceph 命令行实用程序。
如果 Ceph monitor 无法形成仲裁，但 ceph-mon 守护进程正在运行，请使用管理 socket 来执行 mon_status。
mon_status输出示例
{
"name": "mon.3",
"rank": 2,
"state": "peon",
"election_epoch": 96,
"quorum": [
1,
2
],
"outside_quorum": [],
"extra_probe_peers": [],
"sync_provider": [],
"monmap": {
"epoch": 1,
"fsid": "d5552d32-9d1d-436c-8db1-ab5fc2c63cd0",
"modified": "0.000000",
"created": "0.000000",
"mons": [
{
"rank": 0,
"name": "mon.1",
"addr": "172.25.1.10:6789\/0"
},
{
"rank": 1,
"name": "mon.2",
"addr": "172.25.1.12:6789\/0"
},
{
"rank": 2,
"name": "mon.3",
"addr": "172.25.1.13:6789\/0"
}
]
}
}
Ceph monitor 状态
- leader
-
在选择阶段，Ceph 监控器正在选举领导机。领导机是具有最高等级的 Ceph monitor，即值最低的排名。在上例中，领导机是
mon.1。 - Ppeon
- Ppeons 是仲裁中的 Ceph monitor，而不是领导。如果领导失败，则排名最高的学员将成为新的领导。
- Probing
-
如果 Ceph 监控器正在寻找其他 Ceph 监控器，则 Ceph 监控器处于探测状态。例如，在启动 Ceph 监控后，它们正在 探测，直到它们找到 Ceph monitor map(
monmap)中指定的足够 Ceph monitor 来组成仲裁。 - 选择
- 如果 Ceph 监控器正在选择领导机，则 Ceph 监控器处于选择状态。通常，此状态会快速变化。
- 同步
- 如果 Ceph monitor 正在与其他 Ceph 监控器同步以加入仲裁，则 Ceph monitor 处于同步状态。Ceph 监控器存储容量越小，同步过程越快。因此，如果您有大量的存储，同步需要更长的时间。
其它资源
- 详情请参阅《红帽 Ceph 存储 4 管理指南 》中的"使用 Ceph 管理套接字 "一节。
4.2.8. 其它资源
- 请参阅《 红帽 Ceph 存储故障排除指南》 中的 第 4.2.2 节 “Ceph 监控错误消息”。
- 请参阅《 红帽 Ceph 存储故障排除指南》 中的 第 4.2.3 节 “Ceph 日志中的通用 Ceph monitor 错误消息”。
