Menu Close

Red Hat Training

A Red Hat training course is available for Red Hat Ceph Storage

第 3 章 监控

拥有正在运行的集群后,您可以开始监控存储集群,以确保 Ceph monitor 和 OSD 守护进程正在运行。Ceph 存储集群客户端必须连接到 Ceph 监控器,并接收 Ceph 集群映射的最新版本,然后才能将数据读取和写入到存储集群的 Ceph 池。因此,监控集群必须在 Ceph 客户端可以读取和写入数据之前就群集状态达成一致。

Ceph OSD 必须对Primary OSD 上的放置组进行对等,以及次要 OSD 上的 PG 副本。如果出现故障,对等将反映 active + clean 状态以外的内容。

3.1. 高级监控

存储集群的高级别监控通常涉及检查 Ceph OSD 和 monitor 守护进程的状态,以确保它们已启动并在运行。高级别监控还需要检查存储集群容量,以确保集群没有超过其 full ratio。Ansible Tower 或红帽存储控制台节点上的 Calamari 实例是执行高级别监控的最常见方式。不过,您也可以使用命令行、管理 socket 或 Ceph API 来监控存储集群。

3.1.1. 互动模式

要在互动模式下运行 ceph 工具,请在不带参数的命令行输入 ceph,例如:

# ceph
ceph> health
ceph> status
ceph> quorum_status
ceph> mon_status

3.1.2. 检查集群健康状况

启动 Ceph 存储集群后,在开始阅读和/或写入数据之前,请先检查存储集群的运行状况。您可以使用以下命令检查 Ceph 存储集群的健康状况:

# ceph health

如果您为配置或密钥环指定了非默认位置,您可以指定它们的位置:

# ceph -c /path/to/conf -k /path/to/keyring health

启动 Ceph 集群后,您可能会遇到 HEALTH_WARN XXX num placement groups stale 等健康警告。等待几分钟,然后再次检查。当存储集群就绪时,ceph health 应该返回信息,如 HEALTH_OK。此时,开始使用集群没有问题。

3.1.3. 监控集群

要在命令行上观察集群持续事件,请打开一个新终端。然后输入:

# ceph -w

Ceph 将打印每个事件。例如,一个 tiny Ceph 集群由一个 monitor 组成,两个 OSD 可能会打印以下内容:

cluster b370a29d-9287-4ca3-ab57-3d824f65e339
 health HEALTH_OK
 monmap e1: 1 mons at {ceph1=10.0.0.8:6789/0}, election epoch 2, quorum 0 ceph1
 osdmap e63: 2 osds: 2 up, 2 in
  pgmap v41338: 952 pgs, 20 pools, 17130 MB data, 2199 objects
        115 GB used, 167 GB / 297 GB avail
             952 active+clean

2014-06-02 15:45:21.655871 osd.0 [INF] 17.71 deep-scrub ok
2014-06-02 15:45:47.880608 osd.1 [INF] 1.0 scrub ok
2014-06-02 15:45:48.865375 osd.1 [INF] 1.3 scrub ok
2014-06-02 15:45:50.866479 osd.1 [INF] 1.4 scrub ok
2014-06-02 15:45:01.345821 mon.0 [INF] pgmap v41339: 952 pgs: 952 active+clean; 17130 MB data, 115 GB used, 167 GB / 297 GB avail
2014-06-02 15:45:05.718640 mon.0 [INF] pgmap v41340: 952 pgs: 1 active+clean+scrubbing+deep, 951 active+clean; 17130 MB data, 115 GB used, 167 GB / 297 GB avail
2014-06-02 15:45:53.997726 osd.1 [INF] 1.5 scrub ok
2014-06-02 15:45:06.734270 mon.0 [INF] pgmap v41341: 952 pgs: 1 active+clean+scrubbing+deep, 951 active+clean; 17130 MB data, 115 GB used, 167 GB / 297 GB avail
2014-06-02 15:45:15.722456 mon.0 [INF] pgmap v41342: 952 pgs: 952 active+clean; 17130 MB data, 115 GB used, 167 GB / 297 GB avail
2014-06-02 15:46:06.836430 osd.0 [INF] 17.75 deep-scrub ok
2014-06-02 15:45:55.720929 mon.0 [INF] pgmap v41343: 952 pgs: 1 active+clean+scrubbing+deep, 951 active+clean; 17130 MB data, 115 GB used, 167 GB / 297 GB avail

输出提供:

  • 集群 ID
  • 集群健康状态
  • monitor map epoch 以及 monitor 仲裁的状态
  • OSD map epoch 以及 OSD 的状态
  • 放置组映射版本
  • 放置组和池的数量
  • 存储的数据 的概念量 和存储的对象数量
  • 存储的数据总数

Ceph 如何计算数据使用情况

used 值反映了使用的原始存储 的实际 数量。xxx GB / xxx GB 值表示集群总存储容量的可用数量(两个数字越小)。概念数反映了数据在复制、克隆或快照之前的大小。因此,实际存储的数据量通常超过存储的概念量,因为 Ceph 会创建数据副本,也可能会使用存储容量进行克隆和快照。

3.1.4. 检查集群的使用情况统计信息

要检查集群的数据使用情况和数据分布,您可以使用 df 选项。它与 Linux df 类似。执行以下命令:

# ceph df

输出的 GLOBAL 部分概述了存储集群用于数据的存储量。

  • SIZE: 存储集群的总体存储容量。
  • AVAIL: 存储集群中可用的可用空间量。
  • RAW USED:使用 的原始存储量。
  • % RAW USED: 使用的原始存储的百分比。将此号码与 full rationear full ratio 一起使用,以确保您没有达到存储集群的容量。

输出的 POOLS 部分提供了池列表以及每个池的概念用法。本节的输出 反映副本、克隆或快照。例如,如果您存储了 1MB 的数据,其概念性使用将是 1MB,但实际使用量可能根据副本数量(如 size = 3、克隆和快照)数量而定。

  • NAME: 池的名称。
  • id: 池 ID。
  • USED: 以 KB 为单位存储的数据概念量,除非该数字附加 M 代表兆字节或 G (千兆字节)。
  • %USED: 每个池使用的存储的理念百分比。
  • 对象: 每个池存储的对象的理念数量。
注意

POOLS 部分中的数字是概念性的。它们不包含在副本、shashots 或克隆的数量中。因此,USED 和 %USED 金额的总和不会计入输出的 GLOBAL 部分中的 RAW USED%RAW USED 金额。详情请查看 Ceph 如何计算数据使用情况

3.1.5. 检查集群状态

要检查集群的状态,请执行以下操作:

# ceph status

或者:

# ceph -s

在互动模式中,输入 status 并按 Enter

ceph> status

Ceph 将打印群集状态。例如,一个 tiny Ceph 集群由一个 monitor 组成,两个 OSD 可能会打印以下内容:

cluster b370a29d-9287-4ca3-ab57-3d824f65e339
 health HEALTH_OK
 monmap e1: 1 mons at {ceph1=10.0.0.8:6789/0}, election epoch 2, quorum 0 ceph1
 osdmap e63: 2 osds: 2 up, 2 in
  pgmap v41332: 952 pgs, 20 pools, 17130 MB data, 2199 objects
        115 GB used, 167 GB / 297 GB avail
               1 active+clean+scrubbing+deep
             951 active+clean

3.1.6. 检查 monitor 状态

如果存储集群具有多个 monitor,这是生产 Ceph 存储集群高可用性所需的。在读取和/或写入数据之前,您应该在启动 Ceph 存储集群后检查 Ceph monitor 仲裁状态。当多个监视器正在运行时,必须存在仲裁。您还应定期检查 Ceph monitor 状态,以确保它们正在运行。如果 monitor 出现问题,阻止对存储集群状态达成一致,则故障可能会阻止 Ceph 客户端读取和写入数据。

  • 要显示 monitor map,请执行以下操作:

    # ceph mon stat

    或者

    # ceph mon dump
  • 要检查存储集群的仲裁状态,请执行以下操作:

    # ceph quorum_status -f json-pretty

    Ceph 将返回仲裁状态。例如,由三个监视器组成的 Ceph 存储集群可能会返回以下内容:

    { "election_epoch": 10,
      "quorum": [
            0,
            1,
            2],
      "monmap": { "epoch": 1,
          "fsid": "444b489c-4f16-4b75-83f0-cb8097468898",
          "modified": "2011-12-12 13:28:27.505520",
          "created": "2011-12-12 13:28:27.505520",
          "mons": [
                { "rank": 0,
                  "name": "a",
                  "addr": "127.0.0.1:6789\/0"},
                { "rank": 1,
                  "name": "b",
                  "addr": "127.0.0.1:6790\/0"},
                { "rank": 2,
                  "name": "c",
                  "addr": "127.0.0.1:6791\/0"}
               ]
        }
    }

3.1.7. 使用管理套接字

使用管理 socket 文件直接与给定守护进程交互。例如,套接字可让您:

  • 在运行时列出 Ceph 配置
  • 在运行时直接设置配置值,而不在 monitor 上中继。这在监控器为 down 时非常有用。
  • 转储历史操作
  • 转储操作优先级队列状态
  • 在不重启的情况下转储操作
  • 转储性能计数器

此外,在对 monitor 或 OSD 相关的问题进行故障排除时,使用套接字也很有帮助。详情请参阅红帽 Ceph 存储 3 故障排除指南

使用套接字:

ceph daemon <type>.<id> <command>

替换:

  • <type> 使用 Ceph 守护进程的类型(monosdmds)。
  • <id> 使用守护进程 ID
  • <command> 使用 命令来运行。使用 help 列出给定守护进程的可用命令。

例如,要查看名为 mon.0 的 monitor 状态:

# ceph daemon mon.0 mon_status

或者,也可使用守护进程的套接字文件来指定 守护进程。

ceph daemon /var/run/ceph/<socket-file> <command>

例如,要查看名为 osd.2 的 OSD 的状态:

# ceph daemon /var/run/ceph/ceph-osd.2.asok status

列出 Ceph 进程的所有套接字文件:

$ ls /var/run/ceph

3.1.8. 检查 OSD 状态

OSD 的状态可以是集群中的 in,或者来自集群 out,它的状态为 up 和 running、up 或它已停机且未在运行,或者 down。如果 OSD 是 up,则可以是 in 存储集群,数据可以被读取和写入,或者是存储集群的 out。如果是 in 集群,并且最近移动了集群的 out,Ceph 会将放置组迁移到其他 OSD。如果 OSD 是集群的 out,CRUSH 不会分配 PG 到 OSD。如果 OSD 是 down,它也应是 out

注意

如果 OSD 是 downin,则会出现一个问题,集群不会处于健康状态。

OSD States

如果您执行 ceph healthceph -sceph -w 等命令,您可能会注意到集群并不总是回显 HEALTH OK。不要 panic。对于 OSD,您应该预计集群 不会 在几个预期情况下回显 HEALTH OK

  • 您尚未启动集群,也不会响应。
  • 您刚刚启动或重新启动集群,但还没有就绪,因为 PG 已创建好,并且 OSD 正在对等。
  • 您刚刚添加或删除了 OSD。
  • 您刚刚修改了 cluster map。

监控 OSD 的一个重要方面是确保集群启动并运行 in 集群的所有 OSD 都为 up 并运行。要查看所有 OSD 是否都在运行,请执行:

# ceph osd stat

或者

# ceph osd dump

结果应该告诉您 map epoch eNNNN、OSD 总数 x、数量为 y、以及 up 的数量是 zin

eNNNN: x osds: y up, z in

如果 in 集群的 OSD 数量超过 up OSD 的数量,请执行以下命令来识别未运行的 ceph-osd 守护进程:

# ceph osd tree

输出示例:

# id    weight  type name   up/down reweight
-1  3   pool default
-3  3       rack mainrack
-2  3           host osd-host
0   1               osd.0   up  1
1   1               osd.1   up  1
2   1               osd.2   up  1
提示

通过能够按照设计良好的 CRUSH 层次结构搜索,可以帮助您更快地识别物理位置,从而对存储集群进行故障排除。

如果 OSD 为 down,请连接到节点并启动它。您可以使用红帽存储控制台重启 OSD 节点,也可以使用命令行,例如:

# systemctl start ceph-osd@<osd_id>