第 4 章 监控器故障排除


本章包含关于如何修复与 Ceph 监控器相关的最常见错误的信息。

开始前

4.1. 与 monitor 相关的大多数通用错误信息

下表列出了 ceph health detail 命令返回或 Ceph 日志中最常包含的错误消息。这些表中提供了相应的部分的链接,这些部分解释了错误并指向修复问题的特定程序。

表 4.1. 与 monitor 相关的错误消息
错误消息请查看

HEALTH_WARN

mon.X is down (out of quorum)

第 4.1.1 节 “Quorum 以外的 monitor”

clock skew

第 4.1.2 节 “时钟偏移”

store is getting too big!

第 4.1.3 节 “monitor 存储正在获取 Too Big”

表 4.2. Ceph 日志中与 monitor 相关的常见错误消息
错误消息日志文件请查看

clock skew

主集群日志

第 4.1.2 节 “时钟偏移”

clocks not synchronized

主集群日志

第 4.1.2 节 “时钟偏移”

Corruption: error in middle of record

监控日志

第 4.1.1 节 “Quorum 以外的 monitor”

第 4.3 节 “恢复 monitor 存储”

Corruption: 1 missing files

监控日志

第 4.1.1 节 “Quorum 以外的 monitor”

第 4.3 节 “恢复 monitor 存储”

Caught signal (Bus error)

监控日志

第 4.1.1 节 “Quorum 以外的 monitor”

4.1.1. Quorum 以外的 monitor

一个或多个 monitor 标记为 down,但其他 monitor 仍然能够形成仲裁。另外,ceph health detail 命令返回类似如下的错误消息:

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 由于各种原因将 monitor 标记为 down

如果 ceph-mon 守护进程没有运行,它可能会有损坏的存储或者其它错误阻止守护进程启动。另外,/var/ 分区可能已满。因此,ceph-mon 无法对默认位于 /var/lib/ceph/mon-<short-host-name>/store.db 的存储执行任何操作,并终止。

如果 ceph-mon 守护进程正在运行,但 monitor 没有仲裁并标记为 down,问题的原因取决于 monitor 状态:

  • 如果 monitor 处于 探测 状态超过预期,则无法找到其他 monitor。这个问题可能是由网络问题造成的,或者 monitor 可能会有一个过时的 monitor map(monmap),并尝试访问错误的 IP 地址上的其他 monitor。另外,如果 monmap 是最新的,则 monitor 的时钟可能无法同步。
  • 如果 monitor 处于 选择 状态超过预期,则 monitor 的时钟可能无法同步。
  • 如果 monitor 将自己的状态从 同步 变为开 机和 返回,集群状态将会发展。这意味着,它生成的新 map 的速度要快于同步进程可以处理的速度。
  • 如果 monitor 将自身标记为 领导或 工作 ,则它认为自己处于仲裁状态,而剩余的集群则确定它不会处于仲裁状态。此问题可能是时钟同步失败造成的。
要排除这个问题,请执行以下操作
  1. 验证 ceph-mon 守护进程是否正在运行。如果没有,请启动它:

    systemctl status ceph-mon@<host-name>
    systemctl start ceph-mon@<host-name>

    使用运行守护进程的主机的短名称替换 <host-name>。不确定时使用 hostname -s 命令。

  2. 如果您无法启动 ceph-mon,请按照 ceph-mon 守护进程中的步骤启动
  3. 如果您能够启动 ceph-mon 守护进程,但标记为 down,请按照 ceph-mon 守护进程运行中的步骤进行操作,但 Still Marked 为 down
ceph-mon 守护进程无法启动
  1. 检查对应的 monitor 日志,默认位于 /var/log/ceph/ceph-mon.<host-name>.log
  2. 如果日志包含类似于下列错误消息的错误消息,monitor 可能具有损坏的存储:

    Corruption: error in middle of record
    Corruption: 1 missing files; e.g.: /var/lib/ceph/mon/mon.0/store.db/1234567.ldb

    要解决这个问题,请替换 monitor。请参阅 第 4.4 节 “替换失败的 monitor”

  3. 如果日志包含类似如下的错误消息,/var/ 分区可能已满。从 /var/ 删除任何不必要的数据。

    Caught signal (Bus error)
    重要

    不要手动从 monitor 目录中删除任何数据。反之,使用 ceph-monstore-tool 紧凑它。详情请查看 第 4.5 节 “压缩 monitor 存储”

  4. 如果您看到任何其他错误消息,请打开支持票据。详情请查看 第 9 章 联系红帽支持服务
ceph-mon Daemon 运行,但 Still Marked 作为 down
  1. 在没有仲裁的 monitor 主机中,使用 mon_status 命令检查其状态:

    ceph daemon <id> mon_status

    使用 monitor ID 替换 <id>,例如:

    # ceph daemon mon.a mon_status
  2. 如果状态为 探测,请验证 mon_status 输出中其他 monitor 的位置。

    1. 如果地址不正确,monitor 带有不正确的 monitor 映射(monmap)。要解决这个问题,请参阅 第 4.2 节 “注入 monitor map”
    2. 如果地址正确,请验证 monitor 时钟是否已同步。详情请查看 第 4.1.2 节 “时钟偏移”。另外,对任何网络问题进行故障排除,请参阅 第 3 章 网络问题故障排除
  3. 如果状态为选中状态 请验证 monitor 时钟是否同步。请参阅 第 4.1.2 节 “时钟偏移”
  4. 如果状态从 选择 同步变为 同步,请打开支持票据。详情请查看 第 9 章 联系红帽支持服务
  5. 如果 monitor 是 领导 机或工作 机, 请验证 monitor 时钟是否已同步。请参阅 第 4.1.2 节 “时钟偏移”。如果同步时钟无法解决问题,请打开支持问题单。详情请查看 第 9 章 联系红帽支持服务
另请参阅

4.1.2. 时钟偏移

Ceph 监控器没有仲裁,ceph health detail 命令输出包含类似如下的错误消息:

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 是什么

clock skew 错误消息表示 monitor 的时钟没有同步。时钟同步很重要,因为 monitor 依赖于时间精度,如果时钟不同步,则行为不可预测。

mon_clock_drift_allowed 参数决定时钟之间的差别是容许的。默认情况下,此参数设置为 0.05 秒。

重要

在未进行之前测试的情况下,不要更改 mon_clock_drift_allowed 的默认值。更改此值可能会影响 monitor 和 Ceph 存储群集的稳定性。

clock skew 错误的原因可能包括网络问题或者网络时间协议(NTP)同步问题(如果已配置)。此外,时间同步无法在虚拟机上部署的 monitor 上正常工作。

要排除这个问题,请执行以下操作
  1. 验证您的网络是否正常工作。详情请查看 第 3 章 网络问题故障排除。特别是,如果您使用 NTP,则对 NTP 客户端的任何问题进行故障排除。如需更多信息,请参阅 第 3.2 节 “基本 NTP 故障排除”
  2. 如果您使用远程 NTP 服务器,请考虑在网络上部署您自己的 NTP 服务器。详情请查看 Red Hat Enterprise Linux 7 的《系统管理员指南》 中的使用 ntpd 配置 NTP 一章。
  3. 如果您不使用 NTP 客户端,请设置一个。详情请参阅 Red Hat Enterprise Linux 或 Ubuntu 的红帽 Ceph 存储 3 安装指南中的为 红帽 Ceph 存储配置网络时间协议 一节。
  4. 如果您使用虚拟机托管 monitor,请将其移至裸机主机。不支持使用虚拟机托管 monitor。详情请查看红帽客户门户网站中的 Red Hat Ceph Storage: 支持的配置 文章。
注意

Ceph 仅评估每五分钟的时间同步,因此修复问题与清除 clock skew 信息之间会有一个延迟。

另请参阅

4.1.3. monitor 存储正在获取 Too Big

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 存储可能需要时间。因此,在响应客户端查询时可能会延迟 monitor。

另外,如果 /var/ 分区已满,monitor 无法对存储执行任何写入操作并终止。有关此问题故障排除的详情,请查看 第 4.1.1 节 “Quorum 以外的 monitor”

要排除这个问题,请执行以下操作
  1. 检查数据库的大小:

    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
  2. 紧凑 monitor 存储.详情请查看 第 4.5 节 “压缩 monitor 存储”
另请参阅

4.1.4. 了解 monitor 状态

mon_status 命令返回有关 monitor 的信息,例如:

  • 状态
  • 等级
  • 选举时期
  • monitor map(monmap)

如果 monitor 能够形成仲裁,请在 ceph 命令行工具中使用 mon_status

如果 monitor 无法形成仲裁,但 ceph-mon 守护进程正在运行,请使用管理套接字来执行 mon_status。详情请参阅《红帽 Ceph 存储 3 管理指南 》中的"使用管理套接字 "一节。

输出示例 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"
            }
        ]
    }
}

monitor 状态
leader
在选择阶段,monitor 会选举领导。领导机是等级最高的 monitor,即最低值的排名。在上例中,领导机是 mon.1
Ppeon
Cpeons 是仲裁中的 monitor,而不是领导。如果领导失败,则排名最高的学员将成为新的领导。
Probing
如果 monitor 正在寻找其他 monitor,则 monitor 处于探测状态。例如,在启动 monitor 后,它们会被 探测到 在 monitor map(monmap)中指定的足够 monitor 组成仲裁为止。
选择
如果 monitor 处于选择领导状态,则它处于选举状态。通常,此状态会快速变化。
同步
如果正在与其他 monitor 同步以加入仲裁,则 monitor 处于同步状态。监控器存储容量越小,同步过程越快。因此,如果您有大量的存储,同步需要更长的时间。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.