管理指南

Red Hat Ceph Storage 3

管理 Red Hat Ceph Storage

摘要

本文档描述了如何管理进程、监控集群状态、管理用户，以及添加和删除红帽 Ceph 存储的守护进程。

第 1 章 Ceph 管理概述

红帽 Ceph 存储集群是所有 Ceph 部署的基础。在部署红帽 Ceph 存储集群后，可以通过管理操作保持红帽 Ceph 存储集群正常运行并保持最佳运行。

红帽 Ceph 存储管理指南可帮助存储管理员执行以下任务：

如何检查我的红帽 Ceph 存储群集的健康状态？
如何启动和停止红帽 Ceph 存储群集服务？
如何为正在运行的红帽 Ceph 存储集群添加或删除 OSD？
如何管理红帽 Ceph 存储集群中存储的对象的用户身份验证和访问控制？
我想了解如何通过红帽 Ceph 存储集群使用覆盖。
我想监控红帽 Ceph 存储集群的性能。

基本的 Ceph 存储集群由两种类型的守护进程组成：

Ceph 对象存储设备(OSD)将数据存储为对象存储在分配给 OSD 的 PG 中
Ceph monitor 维护集群映射的主副本

生产系统将具有三个或更多 Ceph 监控器来实现高可用性，通常至少有 50 个 OSD 用于接受的负载平衡、数据重新平衡和数据恢复。

其它资源

Red Hat Ceph Storage 安装指南，适用于：
- Red Hat Enterprise Linux
- Ubuntu

第 2 章了解 Ceph 的进程管理

作为存储管理员，您可以通过多种方式操作 Ceph 守护进程。通过操控这些守护进程，您可以根据需要启动、停止和重新启动所有 Ceph 服务。

启动、停止和重新启动所有 Ceph 守护进程
按类型启动、停止和重新启动 Ceph 守护进程
按实例启动、停止和重新启动 Ceph 守护进程

2.1. 先决条件

正在运行的红帽 Ceph 存储群集.

2.2. Ceph 的进程管理概述

在红帽 Ceph 存储 3 中，所有流程管理都是通过 Systemd 服务完成的。每次您想要 start、restart 和 stop Ceph 守护进程时，您必须指定守护进程类型或守护进程实例。

其它资源

有关使用 Systemd 的更多信息，请参阅 《Red Hat Enterprise Linux 系统管理员指南》的第 9 章。

2.3. 启动、停止和重新启动所有 Ceph 守护进程

若要启动、停止或重新启动节点上运行的所有 Ceph 守护进程，请按照以下步骤操作。

先决条件

对节点具有 root 访问权限。

流程

启动所有 Ceph 守护进程：

[root@admin ~]# systemctl start ceph.target

停止所有 Ceph 守护进程：

[root@admin ~]# systemctl stop ceph.target

重启所有 Ceph 守护进程：

[root@admin ~]# systemctl restart ceph.target

2.4. 按类型启动、停止和重新启动 Ceph 守护进程

若要启动、停止或重新启动特定类型的所有 Ceph 守护进程，请在运行 Ceph 守护进程的节点上遵循以下步骤。

先决条件

对节点具有 root 访问权限。

流程

在 Ceph 监控 节点上：

Starting

[root@mon ~]# systemctl start ceph-mon.target

停止

[root@mon ~]# systemctl stop ceph-mon.target

重启

[root@mon ~]# systemctl restart ceph-mon.target

在 Ceph Manager 节点上：

Starting

[root@mgr ~]# systemctl start ceph-mgr.target

停止

[root@mgr ~]# systemctl stop ceph-mgr.target

重启

[root@mgr ~]# systemctl restart ceph-mgr.target

在 Ceph OSD 节点上：

Starting

[root@osd ~]# systemctl start ceph-osd.target

停止

[root@osd ~]# systemctl stop ceph-osd.target

重启

[root@osd ~]# systemctl restart ceph-osd.target

在 Ceph 对象网关 节点上：

Starting

[root@rgw ~]# systemctl start ceph-radosgw.target

停止

[root@rgw ~]# systemctl stop ceph-radosgw.target

重启

[root@rgw ~]# systemctl restart ceph-radosgw.target

2.5. 按实例启动、停止和重新启动 Ceph 守护进程

若要通过实例启动、停止或重新启动 Ceph 守护进程，请在运行 Ceph 守护进程的节点上遵循下列步骤。

先决条件

对节点具有 root 访问权限。

流程

在 Ceph 监控 节点上：

Starting

[root@mon ~]# systemctl start ceph-mon@$MONITOR_HOST_NAME

停止

[root@mon ~]# systemctl stop ceph-mon@$MONITOR_HOST_NAME

重启

[root@mon ~]# systemctl restart ceph-mon@$MONITOR_HOST_NAME

replace

$MONITOR_HOST_NAME 使用 Ceph 监控节点的名称。

在 Ceph Manager 节点上：

Starting

[root@mgr ~]# systemctl start ceph-mgr@MANAGER_HOST_NAME

停止

[root@mgr ~]# systemctl stop ceph-mgr@MANAGER_HOST_NAME

重启

[root@mgr ~]# systemctl restart ceph-mgr@MANAGER_HOST_NAME

replace

$MANAGER_HOST_NAME 使用 Ceph 管理器节点的名称。

在 Ceph OSD 节点上：

Starting

[root@osd ~]# systemctl start ceph-osd@$OSD_NUMBER

停止

[root@osd ~]# systemctl stop ceph-osd@$OSD_NUMBER

重启

[root@osd ~]# systemctl restart ceph-osd@$OSD_NUMBER

replace

$OSD_NUMBER Ceph OSD 的 ID 数量。
例如，当查看 ceph osd tree 命令输出时，osd.0 的 ID 为 0。

在 Ceph 对象网关 节点上：

Starting

[root@rgw ~]# systemctl start ceph-radosgw@rgw.$OBJ_GATEWAY_HOST_NAME

停止

[root@rgw ~]# systemctl stop ceph-radosgw@rgw.$OBJ_GATEWAY_HOST_NAME

重启

[root@rgw ~]# systemctl restart ceph-radosgw@rgw.$OBJ_GATEWAY_HOST_NAME

replace

$OBJ_GATEWAY_HOST_NAME 使用 Ceph 对象网关节点的名称。

2.6. 关闭并重启 Red Hat Ceph Storage 集群

按照以下步骤关闭并重启 Ceph 集群：

先决条件

具有 root 访问权。

流程

关闭 Red Hat Ceph Storage 集群

停止此群集和任何其他客户端上的 RBD 镜像、NFS-Ganesha 网关和 RADOS 网关。
- 在 NFS-Ganesha 网关节点上：
```
# systemctl stop nfs-ganesha.service
```
- 在 RADOS 网关节点上：
```
# systemctl stop ceph-radosgw.target
```
在继续操作前，集群必须处于健康状态（Health_OK 和所有 PG active+clean）。使用客户端密钥环（如 Ceph 监控器或 OpenStack 控制器节点）在节点上运行 ceph status，以确保集群正常运行。
如果使用 Ceph 文件系统(CephFS)，则必须关闭 CephFS 集群。关闭 CephFS 集群的方法是将等级数量减少到 1，设置 cluster_down 标志，然后失败最后一个等级。例如：
```
#ceph fs set <fs_name> max_mds 1
#ceph mds deactivate <fs_name>:1 # rank 2 of 2
#ceph status # wait for rank 1 to finish stopping
#ceph fs set <fs_name> cluster_down true
#ceph mds fail <fs_name>:0
```
设置 cluster_down 标志可防止待机接管失败的等级。
设置 noout、norecover、norebalance、nobackfill、nodown 和 pause 标志。使用客户端密钥环（如 Ceph 监控器或 OpenStack 控制器节点）在节点上运行以下内容：
```
#ceph osd set noout
#ceph osd set norecover
#ceph osd set norebalance
#ceph osd set nobackfill
#ceph osd set nodown
#ceph osd set pause
```

逐一关闭 OSD 节点：

[root@osd ~]# systemctl stop ceph-osd.target

逐一关闭监控节点：

[root@mon ~]# systemctl stop ceph-mon.target

重启 Red Hat Ceph Storage 集群

打开监控节点：

[root@mon ~]# systemctl start ceph-mon.target

打开 OSD 节点：

[root@osd ~]# systemctl start ceph-osd.target

等待所有节点出现。验证所有服务均已启动，并且节点之间连接正常。
取消设置 noout、norecover、norebalance、nobackfill、nodown 和 pause 标志。使用客户端密钥环（如 Ceph 监控器或 OpenStack 控制器节点）在节点上运行以下内容：
```
#ceph osd unset noout
#ceph osd unset norecover
#ceph osd unset norebalance
#ceph osd unset nobackfill
#ceph osd unset nodown
#ceph osd unset pause
```
如果使用 Ceph 文件系统(CephFS)，则必须通过将 cluster_down 标志设置为 false 来激活 CephFS 集群：
```
[root@admin~]# ceph fs set <fs_name> cluster_down false
```
启动 RADOS 网关和 NFS-Ganesha 网关。
- 在 RADOS 网关节点上：
```
# systemctl start ceph-radosgw.target
```
- 在 NFS-Ganesha 网关节点上：
```
# systemctl start nfs-ganesha.service
```
验证集群处于健康状态（Health_OK 和所有 PG active+clean）。使用客户端密钥环（如 Ceph 监控器或 OpenStack 控制器节点）在节点上运行 ceph status，以确保集群正常运行。

2.7. 其它资源

有关安装 Red Hat Ceph Storage 的更多信息，请参阅：
- Red Hat Enterprise Linux安装指南
- Ubuntu的安装指南

第 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 ratio 和 near 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 守护进程的类型（mon、osd、mds）。
<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 是 down 和 in，则会出现一个问题，集群不会处于健康状态。

如果您执行 ceph health、ceph -s 或 ceph -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 的数量是 z ： in

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>

3.2. 低级监控

较低级别的监控通常涉及确保 OSD 对等。发生故障时，PG 处于降级状态。这可能是由很多因素导致的，如硬件故障、挂起或崩溃守护进程、网络延迟或中断等。

3.2.1. 放置组集

当 CRUSH 将 PG 分配到 OSD 时，它会查看池的副本数量，并将 PG 分配到 OSD，使得 PG 的每一副本分配到不同的 OSD。例如，如果池需要 PG 的三个副本，CRUSH 可以分别将它们分配到 osd.1、osd.2 和 osd.3。CRUSH 实际上寻求伪随机放置，它将考虑您在 CRUSH map 中设置的故障域，因此很少会看到分配给大型集群中最接近邻居 OSD 的放置组。我们引用了应当包含特定放置组副本的 OSD 集合作为操作集合。在某些情况下，Acting Set 中的 OSD 是 down，否则无法服务 PG 中对象的请求。出现这些情况时，请不要 panic。常见示例包括：

您添加了或删除了 OSD。然后，CRUSH 将 PG 重新分配给其他 OSD- 从而更改操作集的构成并通过"回填"进程生成数据迁移。
OSD 曾 down 重启，现在为 recovering。
操作集合中的 OSD 是 down 或无法为请求服务，另一个 OSD 暂时承担了自己的职责。

Ceph 利用 Up Set 处理客户端请求，这是将实际处理请求的 OSD 集合。在大多数情况下，启动集合和操作集几乎相同。如果没有，这可能表明 Ceph 正在迁移数据，或者 OSD 正在恢复，或者存在问题，即 Ceph 通常在这种情况下使用"stuck stale"消息回显 HEALTH WARN 状态。

检索 PG 列表：
```
# ceph pg dump
```
查看操作集合中或给定 PG 的启动集合中有哪些 OSD：
```
# ceph pg map <pg-num>
```
结果应告知您 osdmap epoch、eNNN、PG 号、<pg-num>、Up Set up[] 中的 OSD，以及执行集合中的 OSD acting[] ：
```
osdmap eNNN pg <pg-num> -> up [0,1,2] acting [0,1,2]
```
注意
如果 Up Set 和 Acting Set 不匹配，这可能表示集群重新平衡其自身或集群存在潜在问题。

3.2.2. peering

在将数据写入放置组前，它必须处于 active 状态，它应该 处于 clean 状态。对于 Ceph 而言，若要确定 PG 的当前状态，即 PG 的Primary OSD（即执行集合中的第一个 OSD），则具有次要和第三 OSD 的对等点对等点，就 PG 的当前状态（假设具有 3 个 PG 副本的池）达成一致。

3.2.3. 监控 PG 状态

如果您执行 ceph health、ceph -s 或 ceph -w 等命令，您可能会注意到集群并不总是回显 HEALTH OK。在检查 OSD 是否在运行后，您也应检查 PG 状态。您应预计，在多个与 peering 相关的放置组中，集群不会回显 HEALTH OK ：

您刚刚创建了一个池和放置组，但尚未创建对等组。
PG 正在恢复。
您刚刚将 OSD 添加到集群中或从集群中删除了 OSD。
您刚刚修改过 CRUSH map，而 PG 正在迁移。
放置组的不同副本中的数据不一致。
Ceph 正在清理 PG 的副本。
Ceph 没有足够的存储容量来完成回填操作。

如果其中一个情况导致 Ceph 回显 HEALTH WARN，请不要 panic。在很多情况下，集群会自行恢复。在某些情况下，您可能需要采取行动。监控 PG 的一个重要方面是确保在集群启动并运行时，所有放置组都是 active，最好是处于 clean 状态。要查看所有 PG 的状态，请执行：

# ceph pg stat

结果应该告诉您放置组映射版本 vNNNNNN、放置组总数 x 以及放置组 y 处于特定状态，如 active+clean:

vNNNNNN: x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail

注意

Ceph 通常报告 PG 的多个状态。

快照 Trimming PG 状态

存在快照时，将报告两个额外的 PG 状态。

snaptrim : PG 目前被修剪
snaptrim_wait : PG 等待修剪

输出示例：

244 active+clean+snaptrim_wait
 32 active+clean+snaptrim

注意

如需了解有关快照修剪设置的更多详细信息，请参见《红帽 Ceph 存储 3 配置指南》中的各种 OSD 设置。

除了放置组状态外，Ceph 还将回显所使用的数据量、aa、剩余存储容量量、bb 以及放置组的总存储容量。这些数据在少数情况下可能很重要：

您将到达 near full ratio 或 full ratio。
由于 CRUSH 配置中出现错误，您的数据不会在集群中分布。

放置组 ID

放置组 ID 由池编号而不是池名称组成，后跟句点(.)和放置组 ID-a 十六进制数字。您可以从 ceph osd lspools 的输出中查看池号及其名称。默认池名称 data、metadata 和 rbd 分别对应于池号 0、1 和 2。完全限定 PG ID 具有以下格式：

<pool_num>.<pg_id>

输出示例：

0.1f

检索 PG 列表：
```
# ceph pg dump
```
以 JSON 格式格式化输出并将其保存到文件中：
```
# ceph pg dump -o <file_name> --format=json
```

查询特定放置组：

# ceph pg <pool_num>.<pg_id> query

JSON 格式的输出示例：

{
  "state": "active+clean",
  "up": [
    1,
    0
  ],
  "acting": [
    1,
    0
  ],
  "info": {
    "pgid": "1.e",
    "last_update": "4'1",
    "last_complete": "4'1",
    "log_tail": "0'0",
    "last_backfill": "MAX",
    "purged_snaps": "[]",
    "history": {
      "epoch_created": 1,
      "last_epoch_started": 537,
      "last_epoch_clean": 537,
      "last_epoch_split": 534,
      "same_up_since": 536,
      "same_interval_since": 536,
      "same_primary_since": 536,
      "last_scrub": "4'1",
      "last_scrub_stamp": "2013-01-25 10:12:23.828174"
    },
    "stats": {
      "version": "4'1",
      "reported": "536'782",
      "state": "active+clean",
      "last_fresh": "2013-01-25 10:12:23.828271",
      "last_change": "2013-01-25 10:12:23.828271",
      "last_active": "2013-01-25 10:12:23.828271",
      "last_clean": "2013-01-25 10:12:23.828271",
      "last_unstale": "2013-01-25 10:12:23.828271",
      "mapping_epoch": 535,
      "log_start": "0'0",
      "ondisk_log_start": "0'0",
      "created": 1,
      "last_epoch_clean": 1,
      "parent": "0.0",
      "parent_split_bits": 0,
      "last_scrub": "4'1",
      "last_scrub_stamp": "2013-01-25 10:12:23.828174",
      "log_size": 128,
      "ondisk_log_size": 128,
      "stat_sum": {
        "num_bytes": 205,
        "num_objects": 1,
        "num_object_clones": 0,
        "num_object_copies": 0,
        "num_objects_missing_on_primary": 0,
        "num_objects_degraded": 0,
        "num_objects_unfound": 0,
        "num_read": 1,
        "num_read_kb": 0,
        "num_write": 3,
        "num_write_kb": 1
      },
      "stat_cat_sum": {

      },
      "up": [
        1,
        0
      ],
      "acting": [
        1,
        0
      ]
    },
    "empty": 0,
    "dne": 0,
    "incomplete": 0
  },
  "recovery_state": [
    {
      "name": "Started\/Primary\/Active",
      "enter_time": "2013-01-23 09:35:37.594691",
      "might_have_unfound": [

      ],
      "scrub": {
        "scrub_epoch_start": "536",
        "scrub_active": 0,
        "scrub_block_writes": 0,
        "finalizing_scrub": 0,
        "scrub_waiting_on": 0,
        "scrub_waiting_on_whom": [

        ]
      }
    },
    {
      "name": "Started",
      "enter_time": "2013-01-23 09:35:31.581160"
    }
  ]
}

以下小节更详细地描述了常见状态。

3.2.3.1. Create

创建池时，它将创建您指定的 PG 数量。在创建一个或多个 PG 时，Ceph 将回显 creating。创建之后，属于放置组操作集合一部分的 OSD 将对它们进行对等操作。完成 peering 后，放置组状态应为 active+clean，这意味着 Ceph 客户端可以开始写入 PG。

3.2.3.2. peering

当 Ceph 对 PG 进行对等时，Ceph 将存储 PG 副本的 OSD 放入 关于 PG 中对象状态和元数据状态的协议。当 Ceph 完成对等操作时，这表示存储 PG 的 OSD 同意 PG 的当前状态。但是，完成 peering 进程 并不意味着 每个副本都有最新的内容。

权威历史记录

Ceph 不会确认对客户端的写入操作，直到操作集的所有 OSD 都永久保留写入操作。这种做法可确保自上次成功对等操作以来，操作集合中至少有一个已确认写入操作的记录。

凭借每个已确认的写入操作的准确记录，Ceph 可以构建和重建 PG-a 已完成的新权威历史记录，并且完全排序的操作集合（如果执行）可使 OSD 的副本保持最新状态。

3.2.3.3. Active

当 Ceph 完成 peering 进程后，放置组可能会变为 active。active 状态意味着放置组中的数据通常位于主放置组中，以及用于读写操作的副本。

3.2.3.4. clean

当 PG 处于 clean 状态时，Primary OSD 和副本 OSD 已成功对等，且 PG 没有伪装的副本。Ceph 复制 PG 中所有对象的正确次数。

3.2.3.5. degraded

当客户端将对象写入到Primary OSD 时，Primary OSD 负责将副本写入到副本 OSD。Primary OSD 将对象写入存储后，PG 将保持 degraded 状态，直到 Primary OSD 收到 Ceph 成功创建副本对象的副本 OSD 的确认。

PG 可以是 active+degraded 的原因是 OSD 可能为 active，即使它还没有保存所有对象。如果 OSD 传出 down，Ceph 会将分配给 OSD 的每个 PG 标记为 degraded。OSD 重新上线时，OSD 必须再次对等点。但是，如果客户端是 active，客户端仍然可以将新对象写入 degraded PG。

如果 OSD 是 down，且 degraded 条件仍然存在，Ceph 可以将 down OSD 标记为集群的 out，并将 down OSD 数据从 OSD 重新 map 到另一个 OSD。mon_osd_down_out_interval 控制标记 down 和标记为 out 之间的时间，默认为 600 秒。

PG 也可以是 degraded，因为 Ceph 无法找到 Ceph 认为应在 PG 中的一个或多个对象。虽然您无法读取或写入未找到的对象，但您仍然可以访问 degraded PG 中的所有其他对象。

假设有 9 个 OSD 含有一个对象的三个副本。如果 OSD 编号 9 停机，分配给 OSD 9 的 PG 处于降级状态。如果 OSD 9 没有恢复，它会退出集群和集群重新平衡。在这种情况下，PG 会被降级，然后恢复到活动状态。

3.2.3.6. 恢复

Ceph 专为容错而设计，其规模在于硬件和软件问题持续存在的规模。当 OSD 到达 down 时，其内容可能会低于 PG 中其他副本的当前状态。当 OSD 恢复 up 时，必须更新 PG 的内容来反映当前状态。在该期间内，OSD 可能会反映 recovering 状态。

恢复并不总是简单，因为硬件故障可能会导致多个 OSD 的级联故障。例如，一个机架或机柜的网络交换机可能会失败，这会导致多台主机计算机的 OSD 落于集群的当前状态后。故障解决后，每一 OSD 必须恢复。

Ceph 提供多个设置，以平衡新服务请求与恢复数据对象并将 PG 恢复到当前状态的需要之间的资源争用。osd recovery delay start 设置允许 OSD 在开始恢复过程前重启、重复甚至处理一些请求。osd recovery threads 设置限制恢复过程的线程数量，默认为一个线程。osd recovery thread timeout 设置线程超时，因为多个 OSD 可能会以加号的速度失败、重启和重新创建。osd recovery max active 设置限制 OSD 同时进入的恢复请求数量，以防止 OSD 无法服务。osd recovery max chunk 设置限制恢复的数据块的大小，以防止网络拥塞。

3.2.3.7. 回填

当新 OSD 加入集群时，CRUSH 会将 PG 从集群中的 OSD 重新分配到新添加的 OSD。强制新 OSD 立即接受重新分配的 PG 可能会给新 OSD 带来过多的负载。将 OSD 与 PG 回填可让此过程在后台开始。完成回填后，新 OSD 将在准备好时开始为请求提供服务。

在回填操作中，您可能看到以下状态之一： backfill_wait 表示回填操作处于待处理状态，但还没有在进行中； backfill 表示正在进行回填操作； backfill_too_full 表示请求了回填操作，但因为存储容量不足而无法完成。当无法回填 PG 时，可以将其视为 incomplete。

Ceph 提供了多个设置来管理与将 PG 重新分配到 OSD 相关的负载高峰，特别是新 OSD。默认情况下，osd_max_backfills 将 OSD 的最大并发回填操作数设置为 10。如果 OSD 接近满比率，则 OSD 能够拒绝回填请求，默认为 85%。osd backfill full ratio如果 OSD 拒绝回填请求，osd backfill retry interval 允许 OSD 在 10 秒后默认重试请求。OSD 也可以将 osd backfill scan min 和 osd backfill scan max 设置为管理扫描间隔，默认为 64 和 512。

对于某些工作负载，最好完全避免常规恢复，并使用回填。由于回填操作在后台进行，因此 I/O 能够继续执行 OSD 中的对象。要强制回填而不是恢复，将 osd_min_pg_log_entries 设置为 1，并将 osd_max_pg_log_entries 设置为 2。有关何时适合您的工作负载的详细信息，请联系您的红帽支持客户团队。

3.2.3.8. 强制恢复或回填操作的优先级

您可能会遇到这样的情形：某些放置组(PG)需要恢复和/或回填，其中一些 PG 包含的数据比其他放置组包含更重要的数据。使用 pg force-recovery 或 pg force-backfill 命令，确保优先级较高的 PG 首先进行恢复或回填。

先决条件

正在运行的红帽 Ceph 存储群集.
节点的根级别访问权限。

流程

发出 pg force-recovery 或 pg force-backfill 命令，并为具有较高优先级数据的 PG 指定优先级顺序：
语法
```
# ceph pg force-recovery PG1 [PG2] [PG3 ...]
# ceph pg force-backfill PG1 [PG2] [PG3 ...]
```
示例
```
[root@node]# ceph pg force-recovery group1 group2
[root@node]# ceph pg force-backfill group1 group2
```
此命令可使红帽 Ceph 存储首先在指定放置组(PG)上执行恢复或回填，然后再处理其他放置组。发出命令不会中断当前执行的回填或恢复操作。在当前运行的操作完成后，将针对指定的 PG 尽快执行恢复或回填。

3.2.3.9. 更改或取消恢复或回填操作的优先级

如果您取消了存储集群中某些 PG(PG)上的高优先级 force-recovery 或 force-backfill 操作，这些 PG 的操作将恢复到默认的恢复或回填设置。

先决条件

正在运行的红帽 Ceph 存储群集.
节点的根级别访问权限。

流程

更改或取消指定 PG 上的恢复或回填操作：

语法

ceph pg cancel-force-recovery PG1 [PG2] [PG3 ...]
ceph pg cancel-force-backfill PG1 [PG2] [PG3 ...]

示例

[root@node]# ceph pg cancel-force-recovery group1 group2
[root@node]# ceph pg cancel-force-backfill group1 group2

这会取消 force 标志，并以默认顺序处理 PG。

完成指定 PG 的恢复或回填操作后，处理顺序将恢复为默认值。

3.2.3.10. 为池强制高优先级恢复或回填操作

如果池中的所有 PG 需要高优先级恢复或回填，请使用 force-recovery 或 force-backfill 选项来启动操作。

先决条件

正在运行的红帽 Ceph 存储群集.
节点的根级别访问权限。

流程

对指定池中的所有放置组强制高优先级恢复或回填：
语法
```
ceph osd pool force-recovery POOL_NAME
ceph osd pool force-backfill POOL_NAME
```
示例
```
[root@node]# ceph osd pool force-recovery pool1
[root@node]# ceph osd pool force-backfill pool1
```
注意
请谨慎使用 force-recovery 和 force-backfill 命令。更改这些操作的优先级可能会破坏 Ceph 内部优先级计算的顺序。

3.2.3.11. 取消池的高优先级恢复或回填操作

如果您取消池中所有 PG 的高优先级 force-recovery 或 force-backfill 操作，则池中 PG 的操作将恢复到默认的恢复或回填设置。

先决条件

正在运行的红帽 Ceph 存储群集.
节点的根级别访问权限。

流程

对指定池中所有放置组取消高优先级恢复或回填操作：

语法

ceph osd pool cancel-force-recovery POOL_NAME
ceph osd pool cancel-force-backfill POOL_NAME

示例

[root@node]# ceph osd pool cancel-force-recovery pool1
[root@node]# ceph osd pool cancel-force-backfill pool1

3.2.3.12. 重新安排池的恢复和回填操作的优先级

如果您有多个池当前使用相同的底层 OSD 和某些池包含高优先级数据，您可以重新调整执行操作的顺序。使用 recovery_priority 选项为优先级较高的池分配更高的优先级值。这些池将在优先级较低的池或设置为默认优先级的池之前执行。

先决条件

正在运行的红帽 Ceph 存储群集.
节点的根级别访问权限。

流程

重新排列池的恢复/回填优先级：
语法
```
ceph osd pool set POOL_NAME recovery_priority VALUE
```
VALUE 设置优先级顺序。例如，如果您有 10 个池，优先级为 10 的池会首先被处理，后面是优先级为 9 的池，以此类推。如果只有某些池具有高优先级，您可以仅为这些池设置优先级值。没有设置优先级值的池按照默认顺序处理。
示例
```
ceph osd pool set pool1 recovery_priority 10
```

3.2.3.13. RADOS 中 PG 恢复的优先级

本节介绍 RADOS 中 PG 的恢复和回填的相对优先级值。首先处理更高的值。Inactive PG 的优先级高于活跃或降级 PG。

操作	值	描述
OSD_RECOVERY_PRIORITY_MIN	0	最小恢复值
OSD_BACKFILL_PRIORITY_BASE	100	MBackfillReserve 的回填优先级
OSD_BACKFILL_DEGRADED_PRIORITY_BASE	140	MBackfillReserve（降级 PG）的基础回填优先级.
OSD_RECOVERY_PRIORITY_BASE	180	MBackfillReserve 的基本恢复优先级
OSD_BACKFILL_INACTIVE_PRIORITY_BASE	220	MBackfillReserve（不活跃 PG）的基准回填优先级.
OSD_RECOVERY_INACTIVE_PRIORITY_BASE	220	MRecoveryReserve（不活跃 PG）的基本恢复优先级.
OSD_RECOVERY_PRIORITY_MAX	253	Max 为 MBackfillReserve 手动/自动设置恢复优先级
OSD_BACKFILL_PRIORITY_FORCED	254	手动强制时，MBackfillReserve 的回填优先级
OSD_RECOVERY_PRIORITY_FORCED	255	MRecoveryReserve 恢复优先级，当强制时
OSD_DELETE_PRIORITY_NORMAL	179	OSD 不完整时删除 PG 的优先级
OSD_DELETE_PRIORITY_FULLISH	219	OSD 接近满时删除 PG 的优先级
OSD_DELETE_PRIORITY_FULL	255	OSD 满时删除的优先级

3.2.3.14. remapped

当 Acting Set 为放置组提供服务时，数据将从旧操作集迁移到新的操作集。可能需要过些时间，新的Primary OSD 才能为请求服务。因此，它可能会要求旧主继续服务请求，直到 PG 迁移完成。数据迁移完成后，映射将使用新操作集合的 Primary OSD。

3.2.3.15. stale

虽然 Ceph 使用 heartbeats 来确保主机和守护进程正在运行，但 ceph-osd 守护进程也可能进入 stuck 状态，它们未及时报告统计数据，例如临时网络故障。默认情况下，OSD 守护进程每半秒报告其放置组、thru、引导和失败统计信息，即 0.5，比心跳阈值更频繁。如果 PG 执行集合的 Primary OSD 无法报告给 monitor，或者其他 OSD 报告了Primary OSD down，则 monitor 将标记 PG stale。

当您启动存储集群时，通常会查看 stale 状态，直到对等过程完成为止。在存储集群运行一段时间后，查看处于 stale 状态的 PG 表示这些 PG 的 Primary OSD 为 down 或者没有向 monitor 报告 PG 统计信息。

3.2.3.16. 放置错误

有一些临时的回填方案是 PG 临时映射到 OSD。当 temporary 情况应该不再如此时，PG 可能仍然驻留在临时位置，而不是位于正确的位置。在这种情况下，它们被称为 misplaced。这是因为实际存在正确数量的额外副本，但一个或多个副本位于错误的位置。

我们假设有 3 个 OSD：0、1、2 和所有 PG map 到这三个 OSD 的一些变异。如果添加另一个 OSD(OSD 3)，一些 PG 现在将 map 到 OSD 3，而不是另一个 PG。但是，在 OSD 3 回填之前，PG 将具有一个临时映射，使得 PG 能够继续从旧 map 为 I/O 服务。在该时间里，PG 是 misplaced，因为它有一个临时映射，而非 degraded，因为存在 3 个副本。

示例

pg 1.5: up=acting: [0,1,2]
<add osd 3>
pg 1.5: up: [0,3,1] acting: [0,1,2]

这里的 [0,1,2] 是一个临时映射，因此 up 集不等于 acting 集，而且 PG 为 misplaced，但并非 degraded，因为 [0,1,2] 仍然是三个副本。

示例

pg 1.5: up=acting: [0,3,1]

OSD 3 现已回填，临时映射已被删除，没有降级且不会被错误地放置。

3.2.3.17. 不完整

当内容不完整且 peering 失败时，PG 进入 incomplete 状态，即当没有足够完整的 OSD 来执行恢复时。

我们假设 OSD 1、2 和 3 是活动的 OSD 集，并且它切换到 OSD 1、4 和 3，而 osd.1 将请求在回填 4 时请求 OSD 1、2 和 3 的临时操作集合。在这段时间内，如果 OSD 1、2 和 3 都停机，则 osd.4 是唯一遗留的，可能没有完全回填所有数据。目前，PG 将转到 incomplete，表示没有足够完整的 OSD 来执行恢复。

或者，如果 osd.4 未参与，并且操作的集合只是 OSD 1、2 和 3 时，当 OSD 1、2 和 3 停机时，PG 可能会转到 stale，表示 mons 在该 PG 上因为操作集已更改而没有任何问题。造成不存在向新 OSD 通知的 OSD 的原因。

3.2.4. 识别故障排除 PG

如前文所述，放置组不一定只是一个问题，因为它的状态不是 active+clean。通常，Ceph 自我修复的功能在 PG 卡住时可能无法正常工作。卡住的状态包括：

unclean ：放置组包含不会复制所需次数的对象。它们应该正在恢复。
Inactive ：放置组无法处理读取和写入，因为它们正在等待具有最新数据的 OSD 返回 up。
stale ： PG 处于未知状态，因为托管它们的 OSD 暂时尚未报告给 monitor 集群，并且可以使用 mon osd report timeout 设置进行配置。

要识别卡住的 PG，请执行以下操作：

# ceph pg dump_stuck {inactive|unclean|stale|undersized|degraded [inactive|unclean|stale|undersized|degraded...]} {<int>}

3.2.5. 查找对象位置

要在 Ceph 对象存储中存储对象数据，Ceph 客户端必须：

设置对象名称
指定池

Ceph 客户端检索最新的群集映射，CRUSH 算法计算如何将对象 map 到 PG，然后计算如何将 PG 动态分配到 OSD。若要查找对象位置，您需要的是对象名称和池名称。例如：

# ceph osd map <pool_name> <object_name>

3.3. 使用红帽 Ceph 存储仪表板监控 Ceph 存储集群

红帽 Ceph 存储控制面板提供监控仪表板，以视觉化 Ceph 存储群集的状态。此外，红帽 Ceph 存储控制面板架构为其他模块提供了框架，可以添加功能到存储集群。

要了解仪表板，请参阅第 3.3.1 节 “Red Hat Ceph Storage Dashboard”。
要安装仪表板，请参阅第 3.3.2 节 “安装 Red Hat Ceph Storage Dashboard”。
要访问仪表板，请参阅第 3.3.3 节 “访问 Red Hat Ceph Storage Dashboard”。
要在安装 Dashboard 后更改默认密码，请参阅第 3.3.4 节 “更改默认的 Red Hat Ceph Storage 仪表板密码”。
要了解 Prometheus 插件，请参阅第 3.3.5 节 “Red Hat Ceph Storage 的 Prometheus 插件”。
要了解红帽 Ceph 存储仪表板警报以及如何配置警报，请参阅第 3.3.6 节 “Red Hat Ceph Storage Dashboard 警告”。

先决条件

正在运行的 Red Hat Ceph Storage 集群

3.3.1. Red Hat Ceph Storage Dashboard

红帽 Ceph 存储控制面板为 Ceph 集群提供监控仪表板，以视觉化存储集群状态。控制面板可以从 Web 浏览器访问，提供有关集群状态、监控器、OSD、池或网络的多个指标和图表。

随着之前的 Red Hat Ceph Storage 版本，监控数据通过 collectd 插件提供，该插件将数据发送到 Graphite 监控工具的实例。从 Red Hat Ceph Storage 3.3 开始，使用 ceph-mgr Prometheus 插件直接从 ceph-mgr 守护进程提供监控数据。

Prometheus 作为监控数据源，简化了红帽 Ceph 存储仪表板解决方案的部署和运营管理，同时减少了整体硬件要求。通过直接提供 Ceph 监控数据，红帽 Ceph 存储仪表板解决方案能更好地支持容器中部署的 Ceph 集群。

注意

随着架构的这一改变，监控数据从红帽 Ceph 存储 2.x 和 3.0 到红帽 Ceph 存储 3.3 没有迁移路径。

Red Hat Ceph Storage 控制面板使用以下实用程序：

用于部署的 Ansible 自动化应用。
嵌入的 Prometheus ceph-mgr 插件。
在存储集群的每个节点中运行的 Prometheus node-exporter 守护进程。
用于提供用户界面和警报的 Grafana 平台。

Red Hat Ceph Storage Dashboard 支持以下功能：

常规功能

支持 Red Hat Ceph Storage 3.1 或更高版本
SELinux 支持
支持 FileStore 和 BlueStore OSD 后端
支持加密和非加密的 OSD
支持 monitor、OSD、Ceph 对象网关和 iSCSI 角色
初始支持元数据服务器(MDS)
深度和仪表板链接
15 秒粒度
支持硬盘驱动器(HDD)、固态驱动器(SSD)、非易失性内存 Express(NVMe)接口和 Intel® 缓存加速软件(Intel® CAS)

节点指标

CPU 和 RAM 使用量
网络负载

可配置警报

不使用(OOB)警报和触发器
通知频道在安装过程中自动定义
默认情况下创建的 Ceph Health Summary 仪表板
详情请参阅 Red Hat Ceph Storage Dashboard Alerts 部分。

集群摘要

OSD 配置摘要
OSD FileStore 和 BlueStore 概述
按角色分类的集群版本
磁盘大小摘要
按容量和磁盘数量的主机大小
放置组(PG)状态分类
池数
设备类摘要、HDD 与.SSD

集群详情

集群标志状态（noout、nodown 及其他）
OSD 或 Ceph 对象网关主机 up 和 down 状态
每个池容量使用量
原始容量利用率
活跃的清理和恢复过程的指标
增长跟踪和预测（原始容量）
有关 down 或 near full 的 OSD 的信息，包括 OSD 主机和磁盘
每个 OSD 的 PG 分布
OSD 按 PG 计数，突出显示已使用 OSD 的 over over 或 under 下

OSD 性能

有关每秒 I/O 操作(IOPS)和池吞吐量的信息
OSD 性能指标
每个 OSD 的磁盘统计信息
集群范围磁盘吞吐量
读/写比率（客户端 IOPS）
磁盘使用率 Heat 映射
Ceph 角色的网络负载

Ceph 对象网关详情

聚合的负载视图
每个主机延迟和吞吐量
按 HTTP 操作划分的工作负载

Ceph iSCSI 网关详情

聚合视图
配置
performance
每个网关资源使用率
每个客户端负载和配置
每个 Ceph 块设备镜像性能

3.3.2. 安装 Red Hat Ceph Storage Dashboard

红帽 Ceph 存储控制面板提供了一个可视化控制面板，可用于监控正在运行的 Ceph 存储集群中的各种指标。

注意

有关升级 Red Hat Ceph Storage Dashboard 的详情，请参阅 Red Hat Enterprise Linux 安装指南中的升级 Red Hat Ceph Storage Dashboard。

先决条件

存储群集节点使用红帽企业 Linux 7。
一个单独的节点 Red Hat Ceph Storage Dashboard 节点，用于从集群节点接收数据并提供红帽 Ceph 存储仪表板。

准备 Red Hat Ceph Storage Dashboard 节点：

在所有节点上启用 Tools 存储库。
详情请参阅红帽企业 Linux 红帽 Ceph 存储 3 安装指南中的启用红帽 Ceph 存储存储库 一节。

如果使用防火墙，请确定打开以下 TCP 端口：

表 3.1. TCP 端口要求
端口	使用	在哪里？
`3000`	grafana	红帽 Ceph 存储仪表板节点.
`9090`	基本 Prometheus 图表	红帽 Ceph 存储仪表板节点.
`9100`	Prometheus 的 `node-exporter` 守护进程	所有存储群集节点.
`9283`	收集 Ceph 数据	所有 `ceph-mgr` 节点。
`9287`	Ceph iSCSI 网关数据	所有 Ceph iSCSI 网关节点.

如需了解更多详细信息，请参阅《红帽企业 Linux 7 安全指南》 中的使用 防火墙章节。

流程

在 Ansible 管理节点上以 root 用户身份运行以下命令。

安装 cephmetrics-ansible 软件包。

[root@admin ~]# yum install cephmetrics-ansible

将 Ceph Ansible 清单用作基础，将红帽 Ceph 存储仪表板节点添加到 Ansible 清单文件的 [ceph-grafana] 部分下，默认位于 /etc/ansible/hosts。
```
[ceph-grafana]
$HOST_NAME
```
替换：
- $HOST_NAME 使用 Red Hat Ceph Storage Dashboard 节点的名称
例如：
```
[ceph-grafana]
node0
```

更改到 /usr/share/cephmetrics-ansible/ 目录。

[root@admin ~]# cd /usr/share/cephmetrics-ansible

运行 Ansible playbook。
```
[root@admin cephmetrics-ansible]# ansible-playbook -v playbook.yml
```
重要
每次更新集群配置时，例如，您添加或删除 MON 或 OSD 节点时，您必须重新运行 cephmetrics Ansible playbook。
注意
cephmetrics Ansible playbook 执行以下操作：
- 更新 ceph-mgr 实例，以启用 prometheus 插件并打开 TCP 端口 9283。
- 将 Prometheus node-exporter 守护进程部署到存储集群中的每个节点。
  打开 TCP 端口 9100。
  启动 node-exporter 守护进程。
- 在 Red Hat Ceph Storage Dashboard 节点上在 Docker/systemd 下部署 Grafana 和 Prometheus 容器。
  Prometheus 配置为从 ceph-mgr 节点和每个 ceph 主机上运行的 node-exporters 收集数据
  打开 TCP 端口 3000。
  仪表板、主题和用户帐户均在 Grafana 中创建。
  为管理员输出 Grafana 的 URL。

3.3.3. 访问 Red Hat Ceph Storage Dashboard

通过访问红帽 Ceph 存储控制面板，您可以访问用于管理红帽 Ceph 存储集群的基于 Web 的管理工具。

先决条件

安装红帽 Ceph 存储仪表板.
确保 NTP 正确同步时钟，因为当节点未正确同步时，Ceph 存储控制面板节点、集群节点和浏览器之间可能会出现时间滞后的问题。请参阅 Red Hat Enterprise Linux 或 Ubuntu 《红帽 Ceph 存储 3 安装指南》中的为红帽 Ceph 存储配置网络时间 协议一节。

流程

在网页浏览器中输入以下 URL：
```
http://$HOST_NAME:3000
```
替换：
- $HOST_NAME 使用 Red Hat Ceph Storage Dashboard 节点的名称
例如：
```
http://cephmetrics:3000
```
输入 admin 用户的密码。如果您在安装过程中没有设置密码，请使用 admin，这是默认密码。
登录后，您将在 Glance 控制面板的 Ceph 上自动放置。Ceph At a Glance 控制面板提供容量、性能和节点级性能信息的高级概述。
示例

其它资源

请参阅《红帽 Ceph 存储管理指南》中的更改默认红帽 Ceph 存储仪表板密码章节。

3.3.4. 更改默认的 Red Hat Ceph Storage 仪表板密码

访问 Red Hat Ceph Storage Dashboard 的默认用户名和密码被设置为 admin 和 admin。出于安全考虑，您可能希望在安装后更改密码。

注意

要防止密码重置为默认值，更新 /usr/share/cephmetrics-ansible/group_vars/all.yml 文件中的自定义密码。

先决条件

流程

点击左上角的 Grafana 图标。
将鼠标悬停在您想要修改密码的用户名上。本例中为 admin。
点击 Profile。
点击 Change Password。
输入新密码两次并点击 Change Password。

其他资源

如果您忘记了密码，请遵循 Grafana 网页中的 Reset admin 密码流程。

3.3.5. Red Hat Ceph Storage 的 Prometheus 插件

作为存储管理员，您可以收集性能数据，使用红帽 Ceph 存储仪表板的 Prometheus 插件模块导出这些数据，然后对此数据执行查询。Prometheus 模块允许 ceph-mgr 向 Prometheus 服务器公开 Ceph 相关的状态和性能数据。

3.3.5.1. 先决条件

运行红帽 Ceph 存储 3.1 或更高版本.
安装红帽 Ceph 存储仪表板.

3.3.5.2. Prometheus 插件

Prometheus 插件提供了一个导出器，用于从 ceph-mgr 中的收集点传递 Ceph 性能计数器。红帽 Ceph 存储仪表板从所有 MgrClient 进程（如 Ceph monitor 和 OSD）接收 MMgrReport 信息。最后一个样本数的循环缓冲区包含性能计数器模式数据和实际计数器数据。此插件会创建一个 HTTP 端点，并在轮询时检索每个计数器的最新示例。HTTP 路径和查询参数被忽略；所有报告实体的所有扩展计数器都以文本表示格式返回。

其它资源

有关文本扩展格式的详情，请参阅 Prometheus 文档。

3.3.5.3. 管理 Prometheus 环境

若要使用 Prometheus 监控 Ceph 存储集群，您可以配置和启用 Prometheus 导出器，以便收集 Ceph 存储集群的元数据信息。

先决条件

正在运行的 Red Hat Ceph Storage 3.1 集群
安装 Red Hat Ceph Storage Dashboard

流程

以 root 用户身份，打开并编辑 /etc/prometheus/prometheus.yml 文件。
1. 在 global 部分下，将 scrape_interval 和 evaluation_interval 选项设置为 15 秒。
  示例
```
global:
  scrape_interval:     15s
  evaluation_interval: 15s
```
2. 在 scrape_configs 部分下，添加 honor_labels: true 选项，并为每个 ceph-mgr 节点编辑 targets 和 instance 选项。
  示例
```
scrape_configs:
  - job_name: 'node'
    honor_labels: true
    static_configs:
    - targets: [ 'node1.example.com:9100' ]
      labels:
        instance: "node1.example.com"
    - targets: ['node2.example.com:9100']
      labels:
        instance: "node2.example.com"
```
  注意
  利用 honor_labels 选项，Ceph 可以输出与 Ceph 存储集群中任何节点相关的正确标记数据。这使得 Ceph 可以在没有 Prometheus 覆盖的情况下导出正确的 instance 标签。
3. 要添加新节点，只需使用以下格式添加 targets 和 instance 选项：
  示例
```
- targets: [ 'new-node.example.com:9100' ]
  labels:
    instance: "new-node"
```
  注意
  instance 标签必须与 Ceph OSD 元数据 instance 字段中显示的内容匹配，这是节点的短主机名。这有助于将 Ceph 统计数据与节点的统计信息相关联。

以以下格式将 Ceph 目标添加到 /etc/prometheus/ceph_targets.yml 文件中：

示例

[
    {
        "targets": [ "cephnode1.example.com:9283" ],
        "labels": {}
    }
]

启用 Prometheus 模块：
```
# ceph mgr module enable prometheus
```

3.3.5.4. 使用 Prometheus 表达式浏览器

使用内置 Prometheus 表达式浏览器针对收集的数据运行查询。

先决条件

正在运行的 Red Hat Ceph Storage 3.1 集群
安装 Red Hat Ceph Storage Dashboard

流程

输入 web 浏览器的 Prometh URL：
```
http://$DASHBOARD_SEVER_NAME:9090/graph
```
replace…
- $DASHBOARD_SEVER_NAME 使用红帽 Ceph 存储仪表板服务器的名称。
单击 Graph，然后键入或将查询粘贴到查询窗口，然后按 Execute 按钮。
1. 在控制台窗口中查看结果。
单击 Graph 以查看呈现的数据。

其它资源

如需更多信息，请参阅 Prometheus 网站上的 Prometheus 表达式浏览器文档。

3.3.5.5. 使用 Prometheus 数据和查询

统计数据名称与 Ceph 名称完全相同，非法字符转换为下划线，ceph_ 则为所有名称加上前缀。所有 Ceph 守护进程统计数据都有一个 ceph_daemon 标签，标识它们来自的守护进程的类型和 ID，例如： osd.123。某些统计信息可能来自不同类型的守护进程，因此在查询 Ceph 守护进程时，您希望从 osd 开始过滤 Ceph 守护进程，以避免在 Ceph monitor 和 RocksDB stats 中混合使用。全局 Ceph 存储集群统计数据具有与其报告内容相应的标签。例如，与池相关的指标具有 pool_id 标签。代表来自核心 Ceph 的直方图的长运行平均值以一对和数性能指标表示。

以下示例查询可以在 Prometheus 表达式浏览器中使用：

显示 OSD 的物理磁盘利用率

(irate(node_disk_io_time_ms[1m]) /10) and on(device,instance) ceph_disk_occupation{ceph_daemon="osd.1"}

显示从操作系统中看到的 OSD 的物理 IOPS

irate(node_disk_reads_completed[1m]) + irate(node_disk_writes_completed[1m]) and on (device, instance) ceph_disk_occupation{ceph_daemon="osd.1"}

池和 OSD 元数据系列

特殊数据序列是输出，以启用特定元数据字段的显示和查询。池有一个 ceph_pool_metadata 字段，例如：

ceph_pool_metadata{pool_id="2",name="cephfs_metadata_a"} 1.0

OSD 具有 ceph_osd_metadata 字段，例如：

ceph_osd_metadata{cluster_addr="172.21.9.34:6802/19096",device_class="ssd",ceph_daemon="osd.0",public_addr="172.21.9.34:6801/19096",weight="1.0"} 1.0

使用关联驱动器统计信息 node_exporter

Ceph 的 Prometheus 输出旨在与 Prometheus 节点导出器的通用节点监控一起使用。Ceph OSD 统计数据与通用节点监控驱动器统计的关联，特殊数据序列是输出的，例如：

ceph_disk_occupation{ceph_daemon="osd.0",device="sdd", exported_instance="node1"}

要根据 OSD ID 获取磁盘统计信息，请在 Prometheus 查询中使用 and 操作器或星号(*)操作器。所有元数据指标的值都是 1，因此它们与星号运算符是中立的。使用星号运算符允许使用 group_left 和 group_right 分组修饰符，以便生成的指标有来自查询的一侧的额外标签。例如：

rate(node_disk_bytes_written[30s]) and on (device,instance) ceph_disk_occupation{ceph_daemon="osd.0"}

使用 label_replace

label_replace 功能可以在查询中为指标添加标签或修改标签。要关联 OSD 及其磁盘写入速率，可以使用以下查询：

label_replace(rate(node_disk_bytes_written[30s]), "exported_instance", "$1", "instance", "(.*):.*") and on (device,exported_instance) ceph_disk_occupation{ceph_daemon="osd.0"}

其它资源

有关构建查询的更多信息，请参阅 Prometheus 查询基础知识。
如需更多信息，请参阅 Prometheus 的 label_replace 文档。

3.3.5.6. 其它资源

Prometheus 网站

3.3.6. Red Hat Ceph Storage Dashboard 警告

本节包含有关红帽 Ceph 存储控制面板中警报的信息。

要了解有关红帽 Ceph 存储仪表板警报的信息，请参阅第 3.3.6.2 节 “关于警报”。
要查看警报，请查看第 3.3.6.3 节 “访问 Alert Status 仪表板”。
要配置通知目标，请参阅第 3.3.6.4 节 “配置通知目标”。
要更改默认警报或添加新警报，请参阅第 3.3.6.5 节 “更改默认警报和添加新警报”。

3.3.6.2. 关于警报

Red Hat Ceph Storage 控制面板支持由 Grafana 平台提供的警报机制。您可以配置仪表板，以在您有兴趣达到特定值的指标时向您发送通知。此类指标位于 Alert Status 控制面板中。

默认情况下，Alerting Status 已包含某些指标，如 Overall Ceph Health、OSD Down 或 Pool Capacity。您可以添加您感兴趣的指标到此仪表板中，或更改它们的触发器值。

以下是 Red Hat Ceph Storage Dashboard 中包含的预定义警报列表：

Ceph 总体健康状况
磁盘近乎完全的(>85%)
OSD Down
OSD 主机关闭
PG 的 Stuck Inactive
OSD 主机减少 - 可用容量检查
OSD 具有高响应时间
网络错误
池容量高
monitor Down
整体集群容量低
具有高 PG Count 的 OSD

3.3.6.3. 访问 Alert Status 仪表板

在 Alert Status 控制面板中默认配置特定的 Red Hat Ceph Storage Dashboard 警报。本节介绍访问它的两种方式。

流程

访问仪表板：

在主 At the Glance 控制面板中，单击右上角的 Active Alerts 面板。

或.

点击 Grafana 图标旁边的左上角的仪表板菜单。选择 Alert Status。

3.3.6.4. 配置通知目标

安装过程中会自动创建一个名为 cephmetrics 的通知频道。所有预配置的警报都引用 cephmetrics 频道，但在收到警报前，通过选择所需的通知类型来完成通知频道定义。Grafana 平台支持多种不同的通知类型，包括电子邮件、Slack 和 PagerDuty。

流程

要配置通知频道，请按照 Grafana 网页上的 Alert Notifications 部分中的说明进行操作。

3.3.6.5. 更改默认警报和添加新警报

本节介绍如何更改已配置的警报上的触发器值，以及如何向 Alert Status 仪表板添加新警报。

流程

要更改警报上的触发器值或添加新警报，请遵循 Grafana 网页上的 Alerting Engine & Rules 指南。
重要
为防止覆盖自定义警报，当您更改触发器值或添加新警报时，升级 Red Hat Ceph Storage Dashboard 软件包时不会更新 Alert Status 控制面板。

其它资源

Grafana 网页

3.4. 使用 `ceph-medic` 诊断 Ceph 存储集群

ceph-medic 实用程序针对正在运行的 Ceph 存储集群执行检查，以识别潜在问题。

示例检查的 ceph-medics 工具：

文件和目录的正确所有权
如果 fsid 对于存储集群中的所有节点都相同
如果密钥环中的 secret 密钥与存储集群中的其他节点不同

3.4.1. 先决条件

正常工作的 Red Hat Ceph Storage 集群
SSH 和 sudo 访问存储节点

3.4.2. 安装 `ceph-medic` 实用程序

先决条件

访问 Red Hat Ceph Storage 3 软件存储库

流程

以 root 用户身份在 Ansible 管理节点上执行下列步骤。

安装 ceph-medic 软件包：
```
[root@admin ~]# yum install ceph-medic
```
验证 ceph-medic 的安装：
```
[root@admin ~]# ceph-medic --help
```

其它资源

《 适用于 Red Hat Enterprise Linux 的红帽 Ceph 存储 3 安装指南》中的启用红帽 Ceph 存储存储库 一节

3.4.3. 运行诊断检查

Ceph 存储群集潜在问题的基本检查。

先决条件

正常工作的 Red Hat Ceph Storage 集群
SSH 和 sudo 访问存储节点

流程

以普通用户身份，从 Ansible 管理节点执行以下步骤。

使用 ceph-medic check 命令：

[admin@admin ~]$ ceph-medic check
Host: mon0                  connection: [connected  ]
Host: mon1                  connection: [connected  ]
Host: mon2                  connection: [connected  ]
Host: osd0                  connection: [connected  ]
Host: osd1                  connection: [connected  ]
Host: osd2                  connection: [connected  ]
Collection completed!

=======================  Starting remote check session  ========================
Version: 1.0.2    Cluster Name: "example"
Total hosts: [6]
OSDs:    3    MONs:    3     Clients:    0
MDSs:    0    RGWs:    0     MGRs:       0

================================================================================

------------ osds ------------
 osd0
 osd1
 osd2

------------ mons ------------
 mon0
 mon1
 mon2

17 passed, 0 errors, on 6 hosts

其它资源

附录 A, 错误代码定义 ceph-medic
Red Hat Enterprise Linux Red Hat Ceph Storage 3 安装指南中的 为 Ansible 启用免密码 SSH 部分

3.4.4. 使用自定义清单文件

ceph-medic 工具必须知道存储集群拓扑。默认情况下，ceph-medic 使用 Ansible 清单文件(/etc/ansible/hosts)来检测节点。

先决条件

正常工作的 Red Hat Ceph Storage 集群
SSH 和 sudo 访问存储节点

流程

若要使用自定义清单文件，请以用户身份在 Ansible 管理节点上执行下列步骤。

创建自定义 hosts 文件：
```
[admin@admin ~]$ touch ~/example/hosts
```
打开 hosts 文件进行编辑。将存储集群中的节点添加到适当的节点组类型下。ceph-medic 工具支持以下节点组类型： mons、osds、rgws、mdss、mgrs 和 clients。
例如：
```
[mons]
mon0
mon1
mon2

[osds]
osd0
osd1
osd2
```
在进行诊断检查时，要指定自定义清单文件，请使用 --inventory 选项：
```
ceph-medic --inventory $PATH_TO_HOSTS_FILE check
```
replace
$PATH_TO_HOSTS_FILE 使用到 hosts 文件的完整路径。
例如：
[admin@admin ~]$ ceph-medic --inventory ~/example/hosts check

其它资源

附录 A, 错误代码定义 ceph-medic
Red Hat Enterprise Linux Red Hat Ceph Storage 3 安装指南中的 为 Ansible 启用免密码 SSH 部分

3.4.5. 配置自定义日志记录路径

ceph-medic 日志文件包含比终端命令输出更多的详细程度。ceph-medic 工具默认将日志写入当前工作目录中。

先决条件

正常工作的 Red Hat Ceph Storage 集群
SSH 和 sudo 访问存储节点

流程

若要更改这些日志的编写位置，请以普通用户身份在 Ansible 管理节点上执行以下步骤。

打开 ~/.cephmedic.conf 文件进行编辑。
将 --log-path 选项从 . 改为自定义日志位置。
例如：
```
--log-path = /var/log/ceph-medic/
```

其它资源

附录 A, 错误代码定义 ceph-medic
Red Hat Enterprise Linux Red Hat Ceph Storage 3 安装指南中的 为 Ansible 启用免密码 SSH 部分

第 4 章 overrides

默认情况下，Ceph 将反映 OSD 的当前状态并执行常规操作，如重新平衡、恢复和清理。有时候，覆盖 Ceph 的默认行为可能会有一定优势。

4.1. 设置和取消设置覆盖

要覆盖 Ceph 的默认行为，请使用 ceph osd set 命令和您要覆盖的行为。例如：

# ceph osd set <flag>

设置行为后，ceph health 将反映您为集群设置的覆盖。

要停止覆盖 Ceph 的默认行为，请使用 ceph osd unset 命令和您要停止的覆盖。例如：

# ceph osd unset <flag>

标志	描述
`noin`	防止 OSD 被视为 `in` 集群。
`noout`	防止 OSD 被视为集群的 `out`。
`noup`	防止 OSD 被视为 `up` 并在运行。
`nodown`	防止 OSD 被视为 `down`。
`full`	使集群似乎已到达其 `full_ratio`，从而防止写入操作。
`pause`	Ceph 将停止处理读写操作，但不会影响 OSD `in`、`out`、`up` 或 `down` 状态。
`nobackfill`	Ceph 将阻止新的回填操作。
`norebalance`	Ceph 将阻止新的重新平衡操作。
`norecover`	Ceph 将阻止新的恢复操作。
`noscrub`	Ceph 将阻止新的清理操作。
`nodeep-scrub`	Ceph 将防止新的深度清理操作。
`notieragent`	Ceph 将禁用正在寻找冷/脏对象来清空和驱除的进程。

4.2. 使用案例

noin：通常与 noout 搭配使用，以解决闪烁 OSD。
noout: 如果超过 mon osd report timeout 并且 OSD 没有向 monitor 报告，则 OSD 将获得标记为 out。如果出现错误，您可以设置 noout 来防止 OSD 在您对问题进行故障排除时被标记为 out。
noup：通常与 nodown 搭配使用，以解决闪烁 OSD。
nodown: 网络问题可能会中断 Ceph 'heartbeat' 进程，而 OSD 可能是 up，但仍被标记为 down。您可以设置 nodown 来防止 OSD 在进行故障排除时被标记为 down。
full: 如果集群要到达其 full_ratio，您可以抢占地将集群设置为 full 并扩展容量。注意：将集群设置为 full 将阻止写入操作。
pause: 如果您需要在没有客户端读写数据的情况下对正在运行的 Ceph 集群进行故障排除，您可以将集群设置为 pause，以防止客户端操作。
nobackfill: 如果您需要临时取用 OSD 或节点 down （如升级守护进程），您可以设置 nobackfill，以便 Ceph 不会在 OSD 为 down 时回填。
norecover：如果您需要替换 OSD 磁盘，并且不希望 PG 在热插拔磁盘期间恢复到另一个 OSD，您可以设置 norecover 以防止其他 OSD 将新 PG 复制到其他 OSD。
noscrub 和 nodeep-scrubb ：如果要防止清理（例如，减少高负载、恢复、回填、重新平衡等）期间的开销，您可以设置 noscrub 和/或 nodeep-scrub 来防止集群清理 OSD。
notieragent: 如果您要停止层代理进程，从查找冷对象到清除到后备存储层，您可以设置 notieragent。

第 5 章用户管理

本节介绍 Ceph 客户端用户，以及他们通过红帽 Ceph 存储集群的身份验证和授权。用户可以是个人或系统执行者，如应用，它们使用 Ceph 客户端与红帽 Ceph 存储集群守护进程交互。

当 Ceph 在运行时启用身份验证和授权（默认为启用）时，您必须指定包含指定用户的 secret key（通常使用命令行）的用户名和密钥环。如果不指定用户名，Ceph 将使用 client.admin 管理用户作为默认用户名。如果没有指定密钥环，Ceph 将使用 Ceph 配置中的 keyring 设置来查找密钥环。例如：如果您在没有指定用户或密钥环的情况下执行 ceph health 命令：

# ceph health

Ceph 将该命令解释如下：

# ceph -n client.admin --keyring=/etc/ceph/ceph.client.admin.keyring health

另外，您可以使用 CEPH_ARGS 环境变量以避免重新输入用户名和 secret。

有关将红帽 Ceph 存储集群配置为使用身份验证的详细信息，请参阅红帽 Ceph 存储 3 的配置指南。

5.1. 背景信息

无论 Ceph 客户端的类型如何，如块设备、对象存储、文件系统、原生 API 或 Ceph 命令行，Ceph 将所有数据存储为池内的对象。Ceph 用户必须有权访问池，才能读取和写入数据。此外，管理 Ceph 用户必须具有执行 Ceph 管理命令的权限。以下概念将帮助您了解 Ceph 用户管理：

5.1.1. 用户

红帽 Ceph 存储集群的用户是一个或多个个人或系统操作程序，如应用程序。通过创建用户，您可以控制谁（或什么）可以访问存储集群、其池和池中的数据。

Ceph 具有用户 type 的概念。出于用户管理的目的，类型将始终为 client。Ceph 以句点(.)分隔形式标识用户，其由用户类型和用户 ID 组成：例如 TYPE.ID、client.admin 或 client.user1。用户调用的原因在于 Ceph 监视器和 OSD 也使用 Cephx 协议，但它们不是客户端。区分用户类型有助于区分客户端用户和其他用户 - 提取访问控制、用户监控和可追溯性。

有时，Ceph 的用户类型可能会看上去有些混淆，因为 Ceph 命令行允许您根据命令行使用情况来指定包含或不使用类型的用户。如果指定了 --user 或 --id，您可以省略类型。因此 client.user1 只需输入为 user1。如果指定了 --name 或 -n，您必须指定类型和名称，如 client.user1。我们建议尽可能将类型和名称用作最佳做法。

注意

红帽 Ceph 存储集群用户与 Ceph 对象存储用户不同。对象网关使用红帽 Ceph 存储集群用户在网关守护进程和存储集群之间进行通信，但该网关对其最终用户有自己的用户管理功能。

5.1.2. 授权（功能）

Ceph 使用术语"功能"（容量）来描述授权经过身份验证的用户来练习 monitor 和 OSD 的功能。功能还可以限制对池中数据或池中命名空间的数据的访问。Ceph 管理用户在创建或更新用户时设置用户的功能。

功能语法采用以下形式：

<daemon_type> 'allow <capability>' [<daemon_type> 'allow <capability>']

monitor Caps： 监控器功能包括 r、w、x、allow profile <cap> 和 profile rbd。例如：
```
mon 'allow rwx`
mon 'allow profile osd'
```
OSDCaps： OSD 功能包括 r、w、x、class-read、class-write、profile osd、profile rbd 和 profile rbd-read-only。此外，OSD 功能也允许对池和命名空间设置。
```
osd 'allow <capability>' [pool=<pool_name>] [namespace=<namespace_name>]
```

注意

Ceph 对象网关守护进程(radosgw)是 Ceph 存储集群的客户端，因此它不表示为 Ceph 存储集群守护进程类型。

以下条目描述了每种功能：

`allow`	在守护进程的访问设置之前。
`r`	授予用户读取访问权限。需要使用 monitor 来检索 CRUSH map。
`w`	授予用户对对象的写入访问权限。
`x`	为用户提供调用类方法（即读取和写入）并对 monitor 执行 `auth` 操作的功能。
`class-read`	赋予用户调用类读取方法的功能。`x` 的子集。
`class-write`	赋予用户调用类写入方法的功能。`x` 的子集。
`*`	授予用户特定守护进程或池的读取、写入和执行权限，以及执行 admin 命令的功能。
`profile osd`	授予用户权限，以 OSD 身份连接到其他 OSD 或 monitor。调用 OSD，使 OSD 能够处理复制心跳流量和状态报告。
`profile bootstrap-osd`	为用户授予引导 OSD 的权限，以便他们在引导 OSD 时具有添加密钥的权限。
`profile rbd`	授予用户对 Ceph 块设备的读写访问权限。
`profile rbd-read-only`	授予用户对 Ceph 块设备的只读访问权限。

5.1.3. 池

池为 Ceph 客户端定义存储策略，并充当该策略的逻辑分区。

在 Ceph 部署中，通常要创建一个池来支持不同类型的用例，如云卷/镜像、对象存储、热存储、冷存储等。将 Ceph 部署为 OpenStack 的后端时，典型的部署具有卷、镜像、备份和虚拟机等用户的池，以及 client.glance、client.cinder 等用户。

5.1.4. 命名空间

池中的对象可以关联到池中的 namespace-a 逻辑对象组。用户对池的访问权限可以与命名空间关联，这样用户的读取和写入只能在命名空间内进行。写入到池中命名空间的对象只能由有权访问命名空间的用户访问。

注意

目前，命名空间仅适用于在 librados 上写入的应用程序。块设备和对象存储等 Ceph 客户端目前不支持此功能。

命名空间的理由是池可以是按用例分隔数据的计算方式，因为每个池都会创建一组映射到 OSD 的 PG。如果多个池使用相同的 CRUSH 层次结构和规则集，OSD 性能可能会随着负载的增加而降级。

例如，池应当为每个 OSD 拥有大约 100 个 PG。因此，具有 1000 个 OSD 的示范集群将具有 100,000 个池的放置组。映射到同一 CRUSH 层次结构和规则集的每个池都会在示例集群中再创建 100,000 个放置组。相比之下，将对象写入命名空间只是将命名空间与对象名称关联，与单独池的计算开销无关。您可以使用命名空间，而不是为用户或一组用户创建单独的池。

注意

目前只能使用 librados。

5.2. 管理用户

用户管理功能使系统管理员能够创建、更新和删除红帽 Ceph 存储集群用户。

在红帽 Ceph 存储集群中创建或删除用户时，您可能需要向客户端分发密钥，以便将其添加到密钥环。详情请参阅 keyring Management。

5.2.1. 列出用户

要列出存储集群中的用户，请执行以下操作：

# ceph auth list

Ceph 将列出存储群集中的所有用户。例如，在一个双节点示例存储集群中，ceph auth list 将输出类似如下的内容：

installed auth entries:

osd.0
    key: AQCvCbtToC6MDhAATtuT70Sl+DymPCfDSsyV4w==
    caps: [mon] allow profile osd
    caps: [osd] allow *
osd.1
    key: AQC4CbtTCFJBChAAVq5spj0ff4eHZICxIOVZeA==
    caps: [mon] allow profile osd
    caps: [osd] allow *
client.admin
    key: AQBHCbtT6APDHhAA5W00cBchwkQjh3dkKsyPjw==
    caps: [mds] allow
    caps: [mon] allow *
    caps: [osd] allow *
client.bootstrap-mds
    key: AQBICbtTOK9uGBAAdbe5zcIGHZL3T/u2g6EBww==
    caps: [mon] allow profile bootstrap-mds
client.bootstrap-osd
    key: AQBHCbtT4GxqORAADE5u7RkpCN/oo4e5W0uBtw==
    caps: [mon] allow profile bootstrap-osd

请注意，用户的 TYPE.ID 表示法应用 osd.0 是类型为 osd 的用户，其 ID 为 0，client.admin 是类型为 client 的用户，其 ID 为 admin，即默认的 client.admin 用户。另请注意，每个条目都有 key: <value> 条目，以及一个或多个 caps: 条目。

您可以在 ceph auth list 中使用 -o <file_name> 选项将输出保存到文件中。

5.2.2. 获取用户

要检索特定用户、密钥和功能，请执行以下操作：

语法

# ceph auth get <TYPE.ID>

示例

# ceph auth get client.admin

您还可以在 ceph auth get 中使用 -o <file_name> 选项将输出保存到文件中。开发人员也可以执行以下操作：

语法

# ceph auth export <TYPE.ID>

示例

# ceph auth export client.admin

auth export 命令与 auth get 相同，但也会打印出与最终用户无关的内部 auid。

5.2.3. 添加用户

添加用户会创建一个用户名，即 TYPE.ID，这是 secret 密钥以及您用来创建用户的命令中包含的任何功能。

用户的密钥使用户能够通过 Ceph 存储群集进行身份验证。用户的功能授权用户读取、写入或执行 Ceph 监视器(mon)、Ceph OSD(osd)或 Ceph 元数据服务器(mds)。

添加用户有几个方法：

ceph auth add：此命令是添加用户的规范方式。它将创建用户，生成密钥并添加任何指定的功能。
ceph auth get-or-create：此命令通常是创建用户的最简便方式，因为它返回了含有用户名（括在方括号中）和密钥的密钥文件格式。如果用户已存在，此命令只需以 keyfile 格式返回用户名和密钥。您可以使用 -o <file_name> 选项将输出保存到文件中。
ceph auth get-or-create-key: 此命令是创建用户并仅返回用户的密钥的一种便捷方式。这只对只需要密钥的客户端有用，例如 libvirt。如果用户已存在，此命令只需返回密钥。您可以使用 -o <file_name> 选项将输出保存到文件中。

在创建客户端用户时，您可以创建没有能力的用户。除了仅仅通过身份验证外，没有功能的用户是无用的，因为客户端无法从监控器检索集群映射。但是，如果您希望以后使用 ceph auth caps 命令延迟添加功能，您可以创建没有功能的用户。

典型的用户至少具有 Ceph 监控器的读取功能，以及 Ceph OSD 的读取和写入功能。此外，用户的 OSD 权限通常仅限于访问特定的池。

# ceph auth add client.john mon 'allow r' osd 'allow rw pool=liverpool'
# ceph auth get-or-create client.paul mon 'allow r' osd 'allow rw pool=liverpool'
# ceph auth get-or-create client.george mon 'allow r' osd 'allow rw pool=liverpool' -o george.keyring
# ceph auth get-or-create-key client.ringo mon 'allow r' osd 'allow rw pool=liverpool' -o ringo.key

重要

如果您为用户提供 OSD 的功能，但您不限制对特定池的访问，该用户将有权访问集群中的 ALL 池！

5.2.4. 修改用户功能

ceph auth caps 命令允许您指定用户并更改用户功能。要添加功能，请使用表单：

语法

# ceph auth caps <USERTYPE.USERID> <daemon> 'allow [r|w|x|*|...] [pool=<pool_name>] [namespace=<namespace_name>]'

示例

# ceph auth caps client.john mon 'allow r' osd 'allow rw pool=liverpool'
# ceph auth caps client.paul mon 'allow rw' osd 'allow rwx pool=liverpool'
# ceph auth caps client.brian-manager mon 'allow *' osd 'allow *'

要删除某一功能，您可以重置该能力。如果您希望用户无法访问之前设置的特定守护进程，请指定一个空字符串。例如：

# ceph auth caps client.ringo mon 'allow r' osd ' '

有关功能的更多详细信息，请参阅第 5.1.2 节 “授权（功能）”。

5.2.5. 删除用户

要删除用户，请使用 ceph auth del ：

# ceph auth del {TYPE}.{ID}

其中 {TYPE} 是 client、osd、mon 或 mds 之一，{ID} 是守护进程的用户名或 ID。

5.2.6. 打印用户的密钥

要将用户的身份验证密钥打印到标准输出，请执行以下操作：

# ceph auth print-key <TYPE>.<ID>

其中 <TYPE> 是 client、osd、mon 或 mds 之一，<ID> 是守护进程的用户名或 ID。

当您需要使用用户的密钥（例如 libvirt ）填充客户端软件时，打印用户的密钥非常有用。

# mount -t ceph <hostname>:/<mount_point> -o name=client.user,secret=`ceph auth print-key client.user`

5.2.7. 导入用户

要导入一个或多个用户，请使用 ceph auth import 并指定一个密钥环：

语法

# ceph auth import -i </path/to/keyring>

示例

# ceph auth import -i /etc/ceph/ceph.keyring

注意

ceph 存储集群将添加新用户、其密钥和功能，并将更新现有用户、其密钥及其功能。

5.3. 密钥环管理

当您使用 Ceph 客户端访问 Ceph 时，Ceph 客户端将查找本地密钥环。Ceph 默认使用以下四个密钥环名称预设置 keyring 设置，因此您不必在 Ceph 配置文件中设置它们，除非您要覆盖默认值，我们不建议这样做：

/etc/ceph/$cluster.$name.keyring
/etc/ceph/$cluster.keyring
/etc/ceph/keyring
/etc/ceph/keyring.bin

$cluster metavariable 是 Ceph 存储集群名称（由 Ceph 配置文件的名称定义），即 ceph.conf 表示集群名称为 ceph，因此 ceph.keyring。$name metavariable 是用户类型和用户 ID，如 client.admin，因此为 ceph.client.admin.keyring。

注意

当执行读取或写入 /etc/ceph 的命令时，您可能需要使用 sudo 以 root 身份执行该命令。

在创建用户后，例如 client.ringo，您必须获取密钥并将其添加到 Ceph 客户端的密钥环中，以便用户可以访问 Ceph 存储集群。

如需有关如何直接在 Ceph 存储集群中列出、获取、添加、修改和删除用户的详细信息，请参阅第 5 章 用户管理。但是，Ceph 也提供 ceph-authtool 实用程序，供您从 Ceph 客户端管理密钥环。

5.3.1. 创建密钥环

当您使用管理用户_ 部分中的步骤创建用户时，您需要向 Ceph 客户端提供用户密钥，以便 Ceph 客户端能够检索指定用户的密钥并与 Ceph 存储集群进行身份验证。Ceph 客户端通过访问密钥环来查找用户名并检索用户的密钥。

ceph-authtool 工具允许您创建密钥环。要创建空密钥环，请使用 --create-keyring 或 -C。例如：

# ceph-authtool --create-keyring /path/to/keyring

当使用多个用户创建密钥环时，我们建议使用集群名称，例如 $cluster.keyring 作为密钥环文件名，并将其保存到 /etc/ceph/ 目录中，以便 keyring 配置默认设置选取文件名，而无需您在 Ceph 配置文件的本地副本中指定它。例如，使用以下命令创建 ceph.keyring ：

# ceph-authtool -C /etc/ceph/ceph.keyring

当使用单个用户创建密钥环时，我们建议使用集群名称、用户类型和用户名，并将其保存在 /etc/ceph/ 目录中。例如，client.admin 用户的 ceph.client.admin.keyring。

要在 /etc/ceph/ 中创建密钥环，您必须使用 root。这意味着该文件将只为 root 用户具有 rw 权限，这在密钥环包含管理员密钥时适用。但是，如果您要为特定用户或用户组使用密钥环，请确保执行 chown 或 chmod 来建立适当的密钥环所有权和访问权限。

5.3.2. 将用户添加到密钥环

当您向 Ceph 存储集群中添加用户时，您可以使用 get 流程检索用户、密钥和功能，然后将用户保存到密钥环文件中。

当您只想在每个密钥环使用一个用户时，带有 -o 选项的获取 User_ 过程将以 keyring 文件格式保存输出。例如，要为 client.admin 用户创建密钥环，请执行以下操作：

# ceph auth get client.admin -o /etc/ceph/ceph.client.admin.keyring

请注意，我们为单个用户使用推荐的文件格式。

当您要将用户导入到密钥环时，您可以使用 ceph-authtool 指定目标密钥环和源密钥环。例如：

# ceph-authtool /etc/ceph/ceph.keyring --import-keyring /etc/ceph/ceph.client.admin.keyring

5.3.3. 创建用户

Ceph 提供了 Add a User_ 功能，用于直接在 Ceph 存储群集中创建用户。但是，您也可以直接在 Ceph 客户端密钥环上创建用户、密钥和功能。然后，您可以将该用户导入到 Ceph 存储集群。例如：

# ceph-authtool -n client.ringo --cap osd 'allow rwx' --cap mon 'allow rwx' /etc/ceph/ceph.keyring

有关功能的更多详细信息，请参阅第 5.1.2 节 “授权（功能）”。

您还可以创建密钥环，同时添加新用户到密钥环。例如：

# ceph-authtool -C /etc/ceph/ceph.keyring -n client.ringo --cap osd 'allow rwx' --cap mon 'allow rwx' --gen-key

在以下情况下，新用户 client.ringo 只在密钥环中。要将新用户添加到 Ceph 存储集群，您仍然必须将新用户添加到 Ceph 存储集群。

# ceph auth add client.ringo -i /etc/ceph/ceph.keyring

5.3.4. 修改用户

要在密钥环中修改用户记录的功能，请指定密钥环和用户后面的功能，例如：

# ceph-authtool /etc/ceph/ceph.keyring -n client.ringo --cap osd 'allow rwx' --cap mon 'allow rwx'

要将用户更新至 Ceph 存储集群，您必须将密钥环中的用户条目更新为 Ceph 存储集群中的用户条目：

# ceph auth import -i /etc/ceph/ceph.keyring

有关从密钥环更新 Ceph 存储集群用户的详细信息，请参阅第 5.2.7 节 “导入用户”。

您还可以直接在存储集群中修改用户功能，将结果保存到密钥环文件中，然后将密钥环导入到主 ceph.keyring 文件中。

5.4. 命令行使用

Ceph 支持将以下用户名和 secret 用于用户名和 secret：

--id | --user

描述: Ceph 使用类型和 ID（如 TYPE.ID 或 client.admin、client.user1）识别用户。id、name 和 -n 选项允许您指定用户名的 ID 部分（如 admin、user1、foo 等）。您可以使用 --id 指定用户并省略类型。例如，要指定用户 client.foo，请输入以下内容： +

# ceph --id foo --keyring /path/to/keyring health
# ceph --user foo --keyring /path/to/keyring health

--name | -n

描述: Ceph 使用类型和 ID（如 TYPE.ID 或 client.admin、client.user1）识别用户。--name 和 -n 选项允许您指定完全限定用户名。您必须使用用户 ID 指定用户类型（通常为 client）。例如：+

# ceph --name client.foo --keyring /path/to/keyring health
# ceph -n client.foo --keyring /path/to/keyring health

--keyring

描述: 包含一个或多个用户名和 secret 的密钥环的路径。--secret 选项提供相同的功能，但它不适用于 Ceph RADOS 网关，它使用 --secret 来满足另一个目的。您可以使用 ceph auth get-or-create 检索密钥环，并将其存储在本地。这是首选的方法，因为您可以切换用户名而不切换密钥环路径。例如：+

# rbd map foo --pool rbd myimage --id client.foo --keyring /path/to/keyring

5.5. 限制

cephx 协议相互验证 Ceph 客户端和服务器。它不是为了处理人工用户或应用程序程序代表他们运行的验证。如果需要这种效果才能处理访问控制需求，您必须有另一种机制，这可能特定于用于访问 Ceph 对象存储的前端。这种其他机制的作用是确保只有可接受的用户和程序才能在 Ceph 允许访问其对象存储的计算机上运行。

用于对 Ceph 客户端和服务器进行身份验证的密钥通常存储在具有受信任主机中适当权限的纯文本文件中。

重要

将密钥存储在纯文本文件中存在安全缺点，但是考虑到 Ceph 在后台使用的基本身份验证方法，它们很难避免。这些设置 Ceph 系统应清楚这些缺点。

特别是，任意用户计算机（尤其是便携式计算机）不应配置为直接与 Ceph 交互，因为使用模式需要在不安全的计算机上存储纯文本身份验证密钥。欺骗该计算机或获取对其无与伦比的访问的任何人都可以获取允许其自己的计算机身份验证到 Ceph 的密钥。

用户不必允许潜在的不安全计算机直接访问 Ceph 对象存储，而是要求用户使用为这些用途提供足够安全性的方法登录环境中受信任的计算机。该可信计算机将存储人类用户的纯文本 Ceph 密钥。Ceph 的未来版本可能会更加彻底地解决这些特定的身份验证问题。

目前，任何 Ceph 身份验证协议都没有为传输中的消息提供保密。因此，窃听线路可以听到和理解 Ceph 中客户端和服务器之间发送的所有数据，即使他无法创建或更改它们。在 Ceph 中存储敏感数据的用户应考虑加密其数据，然后将其提供给 Ceph 系统。

例如，Ceph 对象网关提供 S3 API 服务器端加密，它将加密从 Ceph 对象网关客户端接收的未加密数据，然后再将它存储在 Ceph 存储集群中，并且类似地解密从 Ceph 存储集群检索的数据，再将其发回到客户端。为确保客户端和 Ceph 对象网关之间的传输加密，Ceph 对象网关应配置为使用 SSL。

第 6 章使用 `ceph-volume` 实用程序部署 OSD

ceph-volume 工具是一个目的命令行工具，用于将逻辑卷部署为 OSD。它使用插件类型框架来部署具有不同设备技术的 OSD。ceph-volume 实用程序遵循与 ceph-disk 实用程序类似的工作流，用于部署 OSD，采用可预测且强大的方法来准备、激活和启动 OSD。目前，ceph-volume 工具只支持 lvm 插件，并计划将来支持其他技术。

重要

ceph-disk 命令已弃用。

6.1. 使用 `ceph-volume` LVM 插件

通过使用 LVM 标签，lvm 子命令可以通过查询与 OSD 关联的设备来存储和重新发现它们，以便激活它们。这包括对基于 lvm 的技术（如 dm-cache ）的支持。

使用 ceph-volume 时，使用 dm-cache 是透明的，把 dm-cache 视为逻辑卷。使用 dm-cache 时的性能增益和损失取决于特定工作负载。通常，随机和顺序读取将以较小的块大小显示性能增长；而随机和顺序写入的性能在更大块大小下的性能会下降。

要使用 LVM 插件，在 ceph-volume 命令中添加 lvm 作为子命令：

ceph-volume lvm

lvm 子命令有三个子命令，如下所示：

prepare
activate
create
batch

注意

使用 create 子命令，将 prepare 和 activate 子命令组合为一个子命令。详情请查看 create 子命令部分。

6.1.1. 准备 OSD

prepare 子命令为 OSD 后端对象存储准备一个 OSD 后端对象存储，并为 OSD 数据和日志使用逻辑卷。没有默认的对象存储类型。对象存储类型需要在准备时设置 --filestore 或 --bluestore 选项。从 Red Hat Ceph Storage 3.2 开始，支持 BlueStore 对象存储类型。prepare 子命令将不会创建或修改逻辑卷，除非使用 LVM 标签添加一些额外的元数据。

LVM 标签使卷更易于以后发现，并帮助将卷识别为 Ceph 系统的一部分，以及它们具有的角色。ceph-volume lvm prepare 命令添加以下 LVM 标签列表：

cluster_fsid
data_device
journal_device
encrypted
osd_fsid
osd_id
journal_uuid

prepare 进程非常严格，它需要两个可供使用的逻辑卷，并且需要 OSD 数据和日志的最小大小。日志设备可以是逻辑卷或分区。

以下是 prepare 工作流过程：

为数据和日志接受逻辑卷
为 OSD 生成 UUID
要求 Ceph monitor 获取重复使用生成的 UUID 的 OSD 标识符
OSD 数据目录已创建，数据卷被挂载
日志从数据卷到日志位置进行符号链接
monmap 为激活获取
设备挂载，数据目录由填充 ceph-osd
LVM 标签分配给OSD 数据和日志卷

在 OSD 节点上执行以下步骤，并以 root 用户身份使用 LVM 准备简单的 OSD 部署：

ceph-volume lvm prepare --bluestore --data $VG_NAME/$LV_NAME

例如：

# ceph-volume lvm prepare --bluestore --data example_vg/data_lv

对于 BlueStore，如果您要为 RocksDB 使用单独的设备，您还可以指定 --block.db 和 --block.wal 选项。

以下是使用分区作为日志设备的 FileStore 示例：

# ceph-volume lvm prepare --filestore --data example_vg/data_lv --journal /dev/sdc1

当使用分区时，它必须包含可由 blkid 命令发现的 PARTUUID，这样无论设备名称或路径是什么，都可以正确识别它。

重要

ceph-volume LVM 插件不会在原始磁盘设备中创建分区。必须先创建此分区，然后才能将分区用于 OSD 日志设备。

6.1.2. 激活 OSD

完成准备过程后，OSD 已准备好激活。激活过程可在启动时启用 Systemd 单元，允许启用和挂载正确的 OSD 标识符及其 UUID。

以下是 activate 工作流过程：

需要 OSD ID 和 OSD uuid
启用与 OSD id 和 OSD uuid匹配的 systemd 单元
systemd 单元将确保所有设备已就绪并挂载
匹配的 ceph-osd systemd 单元将开始

在 OSD 节点上执行以下步骤，并以 root 用户身份激活 OSD：

ceph-volume lvm activate --filestore $OSD_ID $OSD_UUID

例如：

# ceph-volume lvm activate --filestore 0 0263644D-0BF1-4D6D-BC34-28BD98AE3BC8

注意

运行此命令时多次没有副作用。

6.1.3. 创建 OSD

create 子命令将部署新 OSD 的两步流程打包为：调用 prepare 子命令，然后将 activate 子命令调用到单个子命令。单独使用 prepare 和 activate 的原因是，逐步将新 OSD 引入存储集群中，并避免重新平衡大量数据。进程没有区别，但 OSD 会在完成后 立即启动和 进入。

对 FileStore、OSD 节点上并以 root 用户身份执行以下步骤：

ceph-volume lvm create --filestore --data $VG_NAME/$LV_NAME --journal $JOURNAL_DEVICE

例如：

# ceph-volume lvm create --filestore --data example_vg/data_lv --journal example_vg/journal_lv

对 BlueStore、OSD 节点上并以 root 用户身份执行以下步骤：

# ceph-volume lvm create --bluestore --data <device>

例如：

# ceph-volume lvm create --bluestore --data /dev/sda

6.1.4. 使用 `batch` 模式

在提供单一设备时，batch 子命令可自动创建多个 OSD。ceph-volume 命令决定基于驱动器类型创建 OSD 的最佳方法。这种最佳方式取决于对象存储格式、蓝牙或 FileStore。

BlueStore 是 OSD 的默认对象存储类型。在使用 BlueStore 时，OSD 优化取决于三个不同的情景，具体取决于所使用的设备。如果所有设备都是传统的硬盘驱动器，则每个设备创建一个 OSD。如果所有设备都是固态状态驱动器，则每个设备都会创建两个 OSD。如果混合了传统的硬盘驱动器和固态驱动器，则数据会放置在传统的硬盘上，block.db 会尽可能在固态硬盘上创建。

注意

batch 子命令不支持为 write-ahead-log(block.wal)设备创建单独的逻辑卷。

BlusStore 示例

# ceph-volume lvm batch --bluestore /dev/sda /dev/sdb /dev/nvme0n1

在使用 FileStore 时，OSD 优化取决于所使用的设备两种不同的情景。如果所有设备都是传统的硬盘驱动器或是固态硬盘，则为每个设备创建一个 OSD，将日志整合到同一设备上。如果混合了传统的硬盘驱动器和固态驱动器，则数据将放置在传统的硬盘驱动器上，并使用 Ceph 配置文件中指定的大小调整参数在固态驱动器上创建日志，默认日志大小为 5 GB。ceph.conf

FileStore 示例

# ceph-volume lvm batch --filestore /dev/sda /dev/sdb

第 7 章基准测试性能

本节的目的是让 Ceph 管理员能够基本了解 Ceph 的原生基准测试工具。通过这些工具，可以部分了解 Ceph 存储群集的运行状况。这不是 Ceph 性能基准测试的最终指南，也是有关如何相应地调优 Ceph 的指南。

7.1. 性能基线

OSD（包括日志）磁盘和网络吞吐量都应具有可比较的性能基准。您可以通过比较基准性能数据与 Ceph 原生工具中的数据，确定潜在的调优机会。红帽企业 Linux 有许多内置工具，以及大量开源社区工具，可用于帮助完成这些任务。有关一些可用工具的详情，请查看知识库文章。

7.2. 存储集群

Ceph 包含 rados bench 命令，用于对 RADOS 存储集群执行性能基准测试。命令将执行写入测试和两种类型的读取测试。在测试读写性能时使用 --no-cleanup 选项。默认情况下，rados bench 命令将删除它写入存储池中的对象。离开这些对象后，有两个读取测试可以测量顺序和随机读取性能。

注意

在运行这些性能测试前，运行以下命令丢弃所有文件系统缓存：

# echo 3 | sudo tee /proc/sys/vm/drop_caches && sudo sync

创建新存储池：

# ceph osd pool create testbench 100 100

对新创建的存储池执行 10 秒写入测试：

# rados bench -p testbench 10 write --no-cleanup

输出示例

Maintaining 16 concurrent writes of 4194304 bytes for up to 10 seconds or 0 objects
 Object prefix: benchmark_data_cephn1.home.network_10510
   sec Cur ops   started  finished  avg MB/s  cur MB/s  last lat   avg lat
     0       0         0         0         0         0         -         0
     1      16        16         0         0         0         -         0
     2      16        16         0         0         0         -         0
     3      16        16         0         0         0         -         0
     4      16        17         1  0.998879         1   3.19824   3.19824
     5      16        18         2   1.59849         4   4.56163   3.87993
     6      16        18         2   1.33222         0         -   3.87993
     7      16        19         3   1.71239         2   6.90712     4.889
     8      16        25         9   4.49551        24   7.75362   6.71216
     9      16        25         9   3.99636         0         -   6.71216
    10      16        27        11   4.39632         4   9.65085   7.18999
    11      16        27        11   3.99685         0         -   7.18999
    12      16        27        11   3.66397         0         -   7.18999
    13      16        28        12   3.68975   1.33333   12.8124   7.65853
    14      16        28        12   3.42617         0         -   7.65853
    15      16        28        12   3.19785         0         -   7.65853
    16      11        28        17   4.24726   6.66667   12.5302   9.27548
    17      11        28        17   3.99751         0         -   9.27548
    18      11        28        17   3.77546         0         -   9.27548
    19      11        28        17   3.57683         0         -   9.27548
 Total time run:         19.505620
Total writes made:      28
Write size:             4194304
Bandwidth (MB/sec):     5.742

Stddev Bandwidth:       5.4617
Max bandwidth (MB/sec): 24
Min bandwidth (MB/sec): 0
Average Latency:        10.4064
Stddev Latency:         3.80038
Max latency:            19.503
Min latency:            3.19824

对存储池执行 10 秒的后续读取测试：

# rados bench -p testbench 10 seq

输出示例

sec Cur ops   started  finished  avg MB/s  cur MB/s  last lat   avg lat
  0       0         0         0         0         0         -         0
Total time run:        0.804869
Total reads made:      28
Read size:             4194304
Bandwidth (MB/sec):    139.153

Average Latency:       0.420841
Max latency:           0.706133
Min latency:           0.0816332

对存储池执行 10 秒随机读取测试：

# rados bench -p testbench 10 rand

输出示例

sec Cur ops   started  finished  avg MB/s  cur MB/s  last lat   avg lat
  0       0         0         0         0         0         -         0
  1      16        46        30   119.801       120  0.440184  0.388125
  2      16        81        65   129.408       140  0.577359  0.417461
  3      16       120       104   138.175       156  0.597435  0.409318
  4      15       157       142   141.485       152  0.683111  0.419964
  5      16       206       190   151.553       192  0.310578  0.408343
  6      16       253       237   157.608       188 0.0745175  0.387207
  7      16       287       271   154.412       136  0.792774   0.39043
  8      16       325       309   154.044       152  0.314254   0.39876
  9      16       362       346   153.245       148  0.355576  0.406032
 10      16       405       389   155.092       172   0.64734  0.398372
Total time run:        10.302229
Total reads made:      405
Read size:             4194304
Bandwidth (MB/sec):    157.248

Average Latency:       0.405976
Max latency:           1.00869
Min latency:           0.0378431

要增加并发读写的数量，使用 -t 选项，默认是 16 个线程。另外，-b 参数可以调整要写入的对象的大小。默认对象大小为 4MB。安全的最大对象大小为 16MB。红帽建议在不同的池中运行这些基准测试的多个副本。这样做可显示多个客户端的性能变化。

添加 --run-name <label> 选项来控制在基准测试过程中写入的对象的名称。通过更改每个正在运行的命令实例的 --run-name 标签，可以同时运行多个 rados bench 命令。这可以防止多个客户端尝试访问同一对象并允许不同的客户端访问不同的对象时可能会出现 I/O 错误。--run-name 选项在尝试模拟实际工作负载时也很有用。例如：

# rados bench -p testbench 10 write -t 4 --run-name client1

输出示例

Maintaining 4 concurrent writes of 4194304 bytes for up to 10 seconds or 0 objects
 Object prefix: benchmark_data_node1_12631
   sec Cur ops   started  finished  avg MB/s  cur MB/s  last lat   avg lat
     0       0         0         0         0         0         -         0
     1       4         4         0         0         0         -         0
     2       4         6         2   3.99099         4   1.94755   1.93361
     3       4         8         4   5.32498         8     2.978   2.44034
     4       4         8         4   3.99504         0         -   2.44034
     5       4        10         6   4.79504         4   2.92419    2.4629
     6       3        10         7   4.64471         4   3.02498    2.5432
     7       4        12         8   4.55287         4   3.12204   2.61555
     8       4        14        10    4.9821         8   2.55901   2.68396
     9       4        16        12   5.31621         8   2.68769   2.68081
    10       4        17        13   5.18488         4   2.11937   2.63763
    11       4        17        13   4.71431         0         -   2.63763
    12       4        18        14   4.65486         2    2.4836   2.62662
    13       4        18        14   4.29757         0         -   2.62662
Total time run:         13.123548
Total writes made:      18
Write size:             4194304
Bandwidth (MB/sec):     5.486

Stddev Bandwidth:       3.0991
Max bandwidth (MB/sec): 8
Min bandwidth (MB/sec): 0
Average Latency:        2.91578
Stddev Latency:         0.956993
Max latency:            5.72685
Min latency:            1.91967

删除 rados bench 命令创建的数据：
```
# rados -p testbench cleanup
```

7.3. 块设备

Ceph 包含 rbd bench-write 命令，用于测试后续写入到块设备的吞吐量和延迟。默认字节大小为 4096，默认 I/O 线程数为 16，写入的默认字节总数为 1 GB。这些默认值可分别通过 --io-size、--io-threads 和 --io-total 选项进行修改。有关 rbd 命令的更多信息，请参阅 Red Hat Ceph Storage 3 Ceph 块设备指南中的块设备命令部分。

创建 Ceph 块设备

作为 root，加载 rbd 内核模块（如果还没有载入）:
```
# modprobe rbd
```
作为 root，在 testbench 池中创建一个 1 GB rbd 镜像文件：
```
# rbd create image01 --size 1024 --pool testbench
```
注意
在创建块设备镜像时，这些功能会被默认启用： layering、object-map、deep-flatten、journaling、exclusive-lock 和 fast-diff。
在红帽企业 Linux 7.2 和 Ubuntu 16.04 上，利用内核 RBD 客户端的用户将无法映射块设备映像。您必须首先禁用所有这些功能，但 layering 除外。
语法
```
# rbd feature disable <image_name> <feature_name>
```
示例
```
# rbd feature disable image1 journaling deep-flatten exclusive-lock fast-diff object-map
```
在 rbd create 命令中使用 --image-feature layering 选项只会在新创建的块设备镜像中启用 layering。
这是一个已知问题，请参阅 Red Hat Ceph Storage 3.3 发行注记. 以了解更多详细信息。
所有这些功能适用于利用用户空间 RBD 客户端访问块设备镜像的用户。

作为 root，将镜像文件映射到设备文件：

# rbd map image01 --pool testbench --name client.admin

作为 root，在块设备中创建 ext4 文件系统：
```
# mkfs.ext4 /dev/rbd/testbench/image01
```
作为 root，创建新目录：
```
# mkdir /mnt/ceph-block-device
```
作为 root，将块设备挂载到 /mnt/ceph-block-device/ 下：
```
# mount /dev/rbd/testbench/image01 /mnt/ceph-block-device
```

针对块设备执行写入性能测试

# rbd bench-write image01 --pool=testbench

示例

bench-write  io_size 4096 io_threads 16 bytes 1073741824 pattern seq
  SEC       OPS   OPS/SEC   BYTES/SEC
    2     11127   5479.59  22444382.79
    3     11692   3901.91  15982220.33
    4     12372   2953.34  12096895.42
    5     12580   2300.05  9421008.60
    6     13141   2101.80  8608975.15
    7     13195    356.07  1458459.94
    8     13820    390.35  1598876.60
    9     14124    325.46  1333066.62
    ..

第 8 章性能计数器

Ceph 性能计数器是内部基础架构指标的集合。此指标数据的收集、聚合和图表可通过工具分类来完成，对于性能分析非常有用。

8.1. 权限

性能计数器通过 Ceph 监控器和 OSD 的套接字接口提供。默认情况下，每个守护进程的套接字文件位于 /var/run/ceph 下。性能计数器被分组为集合名称。这些集合名称代表子系统或子系统的实例。

以下是 monitor 和 OSD 集合名称类别的完整列表，其中含有每个的简短描述：

监控集合名称类别

Cluster Metrics - 显示存储集群的信息：监控器、OSD、池和 PG
级别数据库指标 - 显示后端 KeyValueStore 数据库的信息
monitor Metrics - 显示常规监控器信息
Paxos Metrics - 显示集群仲裁管理的信息
throttle Metrics - 显示有关 monitor 如何节流的统计信息

OSD 集合名称类别

写回 Throttle Metrics - 显示有关写回节流如何跟踪未清空 IO 的统计信息
FileStore Metrics - 显示所有相关文件存储统计信息
级别数据库指标 - 显示后端 KeyValueStore 数据库的信息
Objecter Metrics - 显示有关各种基于对象的操作的信息
读取和写入操作指标 - 显示有关各种读写操作的信息
恢复状态指标 - 显示 - 显示各种恢复状态上的延迟
OSD Throttle Metrics - 显示有关 OSD 如何节流的统计信息

RADOS 网关集合名称类别

对象网关客户端指标 - 显示 GET 和 PUT 请求的统计信息
Objecter Metrics - 显示有关各种基于对象的操作的信息
对象网关 Throttle Metrics - 显示有关 OSD 如何节流的统计信息

8.2. 模式

ceph daemon .. perf schema 命令输出可用的指标。每个指标都有关联的位字段值类型。

查看指标的 schema：

# ceph daemon <daemon_name> perf schema

注意

您必须从运行守护进程的节点运行 ceph daemon 命令。

从 monitor 节点执行 ceph daemon .. perf schema 命令：

# ceph daemon mon.`hostname -s` perf schema

示例

{
    "cluster": {
        "num_mon": {
            "type": 2
        },
        "num_mon_quorum": {
            "type": 2
        },
        "num_osd": {
            "type": 2
        },
        "num_osd_up": {
            "type": 2
        },
        "num_osd_in": {
            "type": 2
        },
...

从 OSD 节点执行 ceph daemon .. perf schema 命令：

# ceph daemon osd.0 perf schema

示例

...
"filestore": {
        "journal_queue_max_ops": {
            "type": 2
        },
        "journal_queue_ops": {
            "type": 2
        },
        "journal_ops": {
            "type": 10
        },
        "journal_queue_max_bytes": {
            "type": 2
        },
        "journal_queue_bytes": {
            "type": 2
        },
        "journal_bytes": {
            "type": 10
        },
        "journal_latency": {
            "type": 5
        },
...

表 8.1. 位字段值定义
位	含义
1	浮点值
2	未签名 64 位整数值
4	平均（已 + 计数）
8	计数

每个值的位 1 或 2 设置来指示类型，可以是浮动点，也可以是整数值。设置位 4 时，读取有两个值，即 sum 和 count。详情请查看第 8.3.1 节 “平均数量和 Sum”。设定位 8 时，先前间隔的平均时间间隔为总和 delta，因为上一读取后，除以计数 delta 即可。或者，分隔直销的值可以提供生命周期平均值。它们通常用于测量延迟、请求数和请求延迟总和。某些位值被组合使用，如 5、6 和 10。位值 5 是 1 位和位 4 的组合。这意味着平均值为浮动点值。位值 6 是 2 位和位 4 的组合。这意味着平均值是一个整数。位值 10 是 2 位和位 8 的组合。这意味着计数器值是一个整数值。

8.3. dump

ceph daemon .. perf dump 命令输出当前的值，并将指标分组到各个子系统的集合名称下。

查看当前的指标数据：

# ceph daemon {daemon_name} perf dump

注意

您必须从运行守护进程的节点运行 ceph daemon 命令。

从 monitor 节点执行 ceph daemon .. perf dump 命令：

# ceph daemon mon.`hostname -s` perf dump

示例

{
    "cluster": {
        "num_mon": 1,
        "num_mon_quorum": 1,
        "num_osd": 2,
        "num_osd_up": 2,
        "num_osd_in": 2,
...

要查看每个可用的 monitor 指标的简短描述，请参见下表。

从 OSD 节点执行 ceph daemon .. perf dump 命令：

# ceph daemon osd.0 perf dump

示例

...
"filestore": {
        "journal_queue_max_ops": 300,
        "journal_queue_ops": 0,
        "journal_ops": 992,
        "journal_queue_max_bytes": 33554432,
        "journal_queue_bytes": 0,
        "journal_bytes": 934537,
        "journal_latency": {
            "avgcount": 992,
            "sum": 254.975925772
        },
...

8.3.1. 平均数量和 Sum

所有延迟数字的位字段值为 5。此字段包含平均计数和总和的浮动点值。avgcount 是这个范围内的操作数量，sum 是总延迟（以秒为单位）。当使用 avgcount 分隔 sum 时，这将让您了解每个操作的延迟。

若要查看可用各个 OSD 指标的简短描述，请参见下方 OSD 表。

8.3.2. 监控指标描述表

集群指标表
级别数据库指标表
常规监控指标表
Paxos 指标表
节流指标表

表 8.2. 集群指标表
集合名称	指标名称	位字段值	简短描述
`cluster`	`num_mon`	2	monitor 数量
	`num_mon_quorum`	2	仲裁中的监视器数量
	`num_osd`	2	OSD 总数
	`num_osd_up`	2	正常运行的 OSD 数量
	`num_osd_in`	2	集群中的 OSD 数量
	`osd_epoch`	2	OSD map 的当前 epoch
	`osd_bytes`	2	以字节为单位的集群总容量
	`osd_bytes_used`	2	集群中使用的字节数
	`osd_bytes_avail`	2	集群中可用字节数
	`num_pool`	2	池数量
	`num_pg`	2	放置组总数
	`num_pg_active_clean`	2	处于 active+clean 状态的 PG 数量
	`num_pg_active`	2	处于活跃状态的 PG 数量
	`num_pg_peering`	2	处于 peering 状态的放置组数量
	`num_object`	2	集群中的对象总数
	`num_object_degraded`	2	降级（缺少副本）对象的数量
	`num_object_misplaced`	2	错误放置（群集中的 Grong 位置）对象数
	`num_object_unfound`	2	未找到的对象数量
	`num_bytes`	2	所有对象的字节总数
	`num_mds_up`	2	在线 MDS 的数量
	`num_mds_in`	2	集群中 MDS 的数量
	`num_mds_failed`	2	失败的 MDS 数
	`mds_epoch`	2	MDS 映射的当前时期

表 8.3. 级别数据库指标表
集合名称	指标名称	位字段值	简短描述
`leveldb`	`leveldb_get`	10	get
	`leveldb_transaction`	10	事务
	`leveldb_compact`	10	紧凑
	`leveldb_compact_range`	10	按范围划分的紧凑
	`leveldb_compact_queue_merge`	10	紧凑队列中的范围合并
	`leveldb_compact_queue_len`	2	压缩队列的长度

表 8.4. 常规监控指标表
集合名称	指标名称	位字段值	简短描述
`mon`	`num_sessions`	2	当前打开的监控会话数量
	`session_add`	10	创建的监控会话数量
	`session_rm`	10	monitor 中的 remove_session 调用数
	`session_trim`	10	修剪监控会话数量
	`num_elections`	10	参加的选举监控器数量
	`election_call`	10	由 monitor 启动的选举数
	`election_win`	10	监控器赢得的选举数
	`election_lose`	10	监控器丢失的选举数

表 8.5. Paxos 指标表
集合名称	指标名称	位字段值	简短描述
`paxos`	`start_leader`	10	在领导角色中启动
	`start_peon`	10	以 peon 角色开始
	`restart`	10	重启
	`refresh`	10	refreshes
	`refresh_latency`	5	刷新延迟
	`begin`	10	已启动并处理
	`begin_keys`	6	开始事务中的密钥
	`begin_bytes`	6	开始事务中的数据
	`begin_latency`	5	延迟开始操作
	`commit`	10	commits
	`commit_keys`	6	提交时事务中的键
	`commit_bytes`	6	提交时事务中的数据
	`commit_latency`	5	提交延迟
	`collect`	10	Ppeon 收集
	`collect_keys`	6	peon 收集事务中的密钥
	`collect_bytes`	6	有关 peon 收集的数据
	`collect_latency`	5	peon 收集延迟
	`collect_uncommitted`	10	已启动和处理中的未提交值
	`collect_timeout`	10	收集超时
	`accept_timeout`	10	接受超时
	`lease_ack_timeout`	10	租期确认超时
	`lease_timeout`	10	租期超时
	`store_state`	10	在磁盘上存储共享状态
	`store_state_keys`	6	处于存储状态的事务键
	`store_state_bytes`	6	处于存储状态的数据
	`store_state_latency`	5	存储状态延迟
	`share_state`	10	共享状态
	`share_state_keys`	6	处于共享状态的密钥
	`share_state_bytes`	6	处于共享状态的数据
	`new_pn`	10	新提议号查询
	`new_pn_latency`	5	新推荐数量获得延迟

表 8.6. 节流指标表
集合名称	指标名称	位字段值	简短描述
`throttle-*`	`val`	10	当前可用的节流
	`max`	10	throttle 的最大值
	`get`	10	get
	`get_sum`	10	获取数据
	`get_or_fail_fail`	10	get_or_fail 期间被阻止
	`get_or_fail_success`	10	get_or_fail 期间成功获得
	`take`	10	参加
	`take_sum`	10	捕获的数据
	`put`	10	PUT
	`put_sum`	10	放置数据
	`wait`	5	等待延迟

8.3.3. OSD 指标描述表

写回 Throttle 指标表
FileStore 指标表
级别数据库指标表
Objecter 指标表
读取和写入操作指标表
恢复状态指标表
OSD Throttle 指标表

表 8.7. 写回 Throttle 指标表
集合名称	指标名称	位字段值	简短描述
`WBThrottle`	`bytes_dirtied`	2	脏数据
	`bytes_wb`	2	写入数据
	`ios_dirtied`	2	脏操作
	`ios_wb`	2	写入操作
	`inodes_dirtied`	2	等待写入的条目
	`inodes_wb`	2	写入条目

表 8.8. FileStore 指标表
集合名称	指标名称	位字段值	简短描述
`filestore`	`journal_queue_max_ops`	2	日志队列中的最大操作
	`journal_queue_ops`	2	日志队列中的操作
	`journal_ops`	10	写入的日志条目总数
	`journal_queue_max_bytes`	2	日志队列中的最大数据
	`journal_queue_bytes`	2	日志队列的大小
	`journal_bytes`	10	日志中操作大小总数
	`journal_latency`	5	平均日志队列完成延迟
	`journal_wr`	10	日志写入 IO
	`journal_wr_bytes`	6	写入的日志数据
	`journal_full`	10	日志写入时完整
	`committing`	2	当前提交
	`commitcycle`	10	提交周期
	`commitcycle_interval`	5	提交之间的平均间隔
	`commitcycle_latency`	5	提交的平均延迟
	`op_queue_max_ops`	2	队列中的最大操作数
	`op_queue_ops`	2	队列中的操作计数
	`ops`	10	操作
	`op_queue_max_bytes`	2	最大队列大小
	`op_queue_bytes`	2	队列大小
	`bytes`	10	写入存储的数据
	`apply_latency`	5	应用延迟
	`queue_transaction_latency_avg`	5	存储操作队列延迟

表 8.9. 级别数据库指标表
集合名称	指标名称	位字段值	简短描述
`leveldb`	`leveldb_get`	10	get
	`leveldb_transaction`	10	事务
	`leveldb_compact`	10	紧凑
	`leveldb_compact_range`	10	按范围划分的紧凑
	`leveldb_compact_queue_merge`	10	紧凑队列中的范围合并
	`leveldb_compact_queue_len`	2	压缩队列的长度

表 8.10. Objecter 指标表
集合名称	指标名称	位字段值	简短描述
`objecter`	`op_active`	2	活跃操作
	`op_laggy`	2	Laggy 操作
	`op_send`	10	发送的操作
	`op_send_bytes`	10	发送的数据
	`op_resend`	10	resent 操作
	`op_ack`	10	提交回调
	`op_commit`	10	操作提交
	`op`	10	操作
	`op_r`	10	读取操作
	`op_w`	10	写入操作
	`op_rmw`	10	read-modify-write 操作
	`op_pg`	10	PG 操作
	`osdop_stat`	10	stat 操作
	`osdop_create`	10	创建对象操作
	`osdop_read`	10	读取操作
	`osdop_write`	10	写入操作
	`osdop_writefull`	10	编写完整的对象操作
	`osdop_append`	10	附加操作
	`osdop_zero`	10	将对象设置为零操作
	`osdop_truncate`	10	中继对象操作
	`osdop_delete`	10	删除对象操作
	`osdop_mapext`	10	映射扩展操作
	`osdop_sparse_read`	10	稀疏读操作
	`osdop_clonerange`	10	克隆范围操作
	`osdop_getxattr`	10	获取 xattr 操作
	`osdop_setxattr`	10	设置 xattr 操作
	`osdop_cmpxattr`	10	xattr 比较操作
	`osdop_rmxattr`	10	删除 xattr 操作
	`osdop_resetxattrs`	10	重置 xattr 操作
	`osdop_tmap_up`	10	TMAP 更新操作
	`osdop_tmap_put`	10	TMAP 推出操作
	`osdop_tmap_get`	10	TMAP get 操作
	`osdop_call`	10	调用（执行）操作
	`osdop_watch`	10	通过对象操作监控
	`osdop_notify`	10	通知对象操作
	`osdop_src_cmpxattr`	10	多操作中的扩展属性比较
	`osdop_other`	10	其他操作
	`linger_active`	2	活跃的闲置操作
	`linger_send`	10	已发送的闲置操作
	`linger_resend`	10	重新闲置操作
	`linger_ping`	10	发送 ping 以闲置操作
	`poolop_active`	2	活跃池操作
	`poolop_send`	10	发送的池操作
	`poolop_resend`	10	重新池操作
	`poolstat_active`	2	Active get pool stat 操作
	`poolstat_send`	10	已发送池统计信息操作
	`poolstat_resend`	10	Resent 池统计信息
	`statfs_active`	2	statfs 操作
	`statfs_send`	10	发送的 FS 统计
	`statfs_resend`	10	Resent FS stats
	`command_active`	2	活动命令
	`command_send`	10	发送的命令
	`command_resend`	10	resent 命令
	`map_epoch`	2	OSD map epoch
	`map_full`	10	接收的完整 OSD map
	`map_inc`	10	收到增量 OSD map
	`osd_sessions`	2	开放会话
	`osd_session_open`	10	已打开会话
	`osd_session_close`	10	会话已关闭
	`osd_laggy`	2	Laggy OSD 会话

表 8.11. 读取和写入操作指标表
集合名称	指标名称	位字段值	简短描述
`osd`	`op_wip`	2	当前正在处理的复制操作（主要）
	`op_in_bytes`	10	客户端操作总写入大小
	`op_out_bytes`	10	客户端操作总读取大小
	`op_latency`	5	客户端操作的延迟（包括队列时间）
	`op_process_latency`	5	客户端操作的延迟（不包括队列时间）
	`op_r`	10	客户端读取操作
	`op_r_out_bytes`	10	客户端数据读取
	`op_r_latency`	5	读取操作的延迟（包括队列时间）
	`op_r_process_latency`	5	读取操作的延迟（队列时间除外）
	`op_w`	10	客户端写入操作
	`op_w_in_bytes`	10	写入的客户端数据
	`op_w_rlat`	5	客户端写入操作可读/应用延迟
	`op_w_latency`	5	写入操作的延迟（包括队列时间）
	`op_w_process_latency`	5	写入操作的延迟（队列时间除外）
	`op_rw`	10	客户端读-modify-write操作
	`op_rw_in_bytes`	10	客户端读写操作写入
	`op_rw_out_bytes`	10	客户端读写操作读取出
	`op_rw_rlat`	5	客户端 read-modify-write 操作可读/应用延迟
	`op_rw_latency`	5	读写操作的延迟（包括队列时间）
	`op_rw_process_latency`	5	读-modify-write 操作的延迟（不包括队列时间）
	`subop`	10	Suboperations
	`subop_in_bytes`	10	子操作总大小
	`subop_latency`	5	Suboperations 延迟
	`subop_w`	10	复制的写入
	`subop_w_in_bytes`	10	复制写入数据大小
	`subop_w_latency`	5	复制的写入延迟
	`subop_pull`	10	子操作拉取请求
	`subop_pull_latency`	5	Suboperations pull latency
	`subop_push`	10	Suboperations push 消息
	`subop_push_in_bytes`	10	Suboperations push size
	`subop_push_latency`	5	Suboperations push latency
	`pull`	10	发送的拉取请求
	`push`	10	发送的推送消息
	`push_out_bytes`	10	推送的大小
	`push_in`	10	入站推送消息
	`push_in_bytes`	10	入站推送大小
	`recovery_ops`	10	开始恢复操作
	`loadavg`	2	CPU 负载
	`buffer_bytes`	2	分配的缓冲区大小总数
	`numpg`	2	放置组
	`numpg_primary`	2	此 osd 的主要 PG
	`numpg_replica`	2	此 osd 是副本的 PG
	`numpg_stray`	2	准备好从这个 osd 删除的 PG
	`heartbeat_to_peers`	2	心跳(ping)对等点发送至
	`heartbeat_from_peers`	2	心跳(ping)对等点，
	`map_messages`	10	OSD map 消息
	`map_message_epochs`	10	OSD map epoch
	`map_message_epoch_dups`	10	OSD map 重复
	`stat_bytes`	2	OSD 大小
	`stat_bytes_used`	2	已使用空间
	`stat_bytes_avail`	2	可用空间
	`copyfrom`	10	RADOS 'copy-from' 操作
	`tier_promote`	10	级别提升
	`tier_flush`	10	等级清除
	`tier_flush_fail`	10	失败的层次清除
	`tier_try_flush`	10	分层刷新尝试
	`tier_try_flush_fail`	10	层刷新尝试失败
	`tier_evict`	10	等级驱除
	`tier_whiteout`	10	层次白皮书
	`tier_dirty`	10	脏层标志集
	`tier_clean`	10	脏层标志已清理
	`tier_delay`	10	层次延迟（代理等待）
	`tier_proxy_read`	10	分层代理读取
	`agent_wake`	10	分层代理唤醒
	`agent_skip`	10	代理跳过的对象
	`agent_flush`	10	分层代理清除
	`agent_evict`	10	分层代理驱除
	`object_ctx_cache_hit`	10	对象上下文缓存命中
	`object_ctx_cache_total`	10	对象上下文缓存查找

表 8.12. 恢复状态指标表
集合名称	指标名称	位字段值	简短描述
`recoverystate_perf`	`initial_latency`	5	初始恢复状态延迟
	`started_latency`	5	开始恢复状态延迟
	`reset_latency`	5	重置恢复状态延迟
	`start_latency`	5	启动恢复状态延迟
	`primary_latency`	5	主要恢复状态延迟
	`peering_latency`	5	对等恢复状态延迟
	`backfilling_latency`	5	回填恢复状态延迟
	`waitremotebackfillreserved_latency`	5	等待远程回填保留恢复状态延迟
	`waitlocalbackfillreserved_latency`	5	等待本地回填保留恢复状态延迟
	`notbackfilling_latency`	5	Notbackfilling 恢复状态延迟
	`repnotrecovering_latency`	5	Repnotrecovering 恢复状态延迟
	`repwaitrecoveryreserved_latency`	5	REP 等待恢复保留的恢复状态延迟
	`repwaitbackfillreserved_latency`	5	REP 等待回填保留恢复状态延迟
	`RepRecovering_latency`	5	RepRecovering 恢复状态延迟
	`activating_latency`	5	激活恢复状态延迟
	`waitlocalrecoveryreserved_latency`	5	等待本地恢复保留恢复状态延迟
	`waitremoterecoveryreserved_latency`	5	等待远程恢复保留恢复状态延迟
	`recovering_latency`	5	恢复恢复状态延迟
	`recovered_latency`	5	恢复恢复状态延迟
	`clean_latency`	5	清理恢复状态延迟
	`active_latency`	5	活跃恢复状态延迟
	`replicaactive_latency`	5	Replicaactive 恢复状态延迟
	`stray_latency`	5	低延迟恢复状态延迟
	`getinfo_latency`	5	Getinfo 恢复状态延迟
	`getlog_latency`	5	Getlog 恢复状态延迟
	`waitactingchange_latency`	5	Waitactingchange 恢复状态延迟
	`incomplete_latency`	5	不完整的恢复状态延迟
	`getmissing_latency`	5	Getmissing 恢复状态延迟
	`waitupthru_latency`	5	Waitupthru 恢复状态延迟

表 8.13. OSD Throttle 指标表
集合名称	指标名称	位字段值	简短描述
`throttle-*`	`val`	10	当前可用的节流
	`max`	10	throttle 的最大值
	`get`	10	get
	`get_sum`	10	获取数据
	`get_or_fail_fail`	10	get_or_fail 期间被阻止
	`get_or_fail_success`	10	get_or_fail 期间成功获得
	`take`	10	参加
	`take_sum`	10	捕获的数据
	`put`	10	PUT
	`put_sum`	10	放置数据
	`wait`	5	等待延迟

8.3.4. Ceph 对象网关指标表

RADOS 网关客户端表
Objecter 指标表
RADOS 网关 Throttle Metrics Table

表 8.14. RADOS 客户端指标表
集合名称	指标名称	位字段值	简短描述
`client.rgw.<rgw_node_name>`	`req`	10	requests
	`failed_req`	10	中止的请求
	`get`	10	get
	`get_b`	10	得到的大小
	`get_initial_lat`	5	获取延迟
	`put`	10	PUT
	`put_b`	10	放置大小
	`put_initial_lat`	5	将延迟
	`qlen`	2	队列长度
	`qactive`	2	活跃请求队列
	`cache_hit`	10	缓存点击
	`cache_miss`	10	缓存未命中
	`keystone_token_cache_hit`	10	Keystone 令牌缓存命中
	`keystone_token_cache_miss`	10	Keystone 令牌缓存未命中

表 8.15. Objecter 指标表
集合名称	指标名称	位字段值	简短描述
`objecter`	`op_active`	2	活跃操作
	`op_laggy`	2	Laggy 操作
	`op_send`	10	发送的操作
	`op_send_bytes`	10	发送的数据
	`op_resend`	10	resent 操作
	`op_ack`	10	提交回调
	`op_commit`	10	操作提交
	`op`	10	操作
	`op_r`	10	读取操作
	`op_w`	10	写入操作
	`op_rmw`	10	read-modify-write 操作
	`op_pg`	10	PG 操作
	`osdop_stat`	10	stat 操作
	`osdop_create`	10	创建对象操作
	`osdop_read`	10	读取操作
	`osdop_write`	10	写入操作
	`osdop_writefull`	10	编写完整的对象操作
	`osdop_append`	10	附加操作
	`osdop_zero`	10	将对象设置为零操作
	`osdop_truncate`	10	中继对象操作
	`osdop_delete`	10	删除对象操作
	`osdop_mapext`	10	映射扩展操作
	`osdop_sparse_read`	10	稀疏读操作
	`osdop_clonerange`	10	克隆范围操作
	`osdop_getxattr`	10	获取 xattr 操作
	`osdop_setxattr`	10	设置 xattr 操作
	`osdop_cmpxattr`	10	xattr 比较操作
	`osdop_rmxattr`	10	删除 xattr 操作
	`osdop_resetxattrs`	10	重置 xattr 操作
	`osdop_tmap_up`	10	TMAP 更新操作
	`osdop_tmap_put`	10	TMAP 推出操作
	`osdop_tmap_get`	10	TMAP get 操作
	`osdop_call`	10	调用（执行）操作
	`osdop_watch`	10	通过对象操作监控
	`osdop_notify`	10	通知对象操作
	`osdop_src_cmpxattr`	10	多操作中的扩展属性比较
	`osdop_other`	10	其他操作
	`linger_active`	2	活跃的闲置操作
	`linger_send`	10	已发送的闲置操作
	`linger_resend`	10	重新闲置操作
	`linger_ping`	10	发送 ping 以闲置操作
	`poolop_active`	2	活跃池操作
	`poolop_send`	10	发送的池操作
	`poolop_resend`	10	重新池操作
	`poolstat_active`	2	Active get pool stat 操作
	`poolstat_send`	10	已发送池统计信息操作
	`poolstat_resend`	10	Resent 池统计信息
	`statfs_active`	2	statfs 操作
	`statfs_send`	10	发送的 FS 统计
	`statfs_resend`	10	Resent FS stats
	`command_active`	2	活动命令
	`command_send`	10	发送的命令
	`command_resend`	10	resent 命令
	`map_epoch`	2	OSD map epoch
	`map_full`	10	接收的完整 OSD map
	`map_inc`	10	收到增量 OSD map
	`osd_sessions`	2	开放会话
	`osd_session_open`	10	已打开会话
	`osd_session_close`	10	会话已关闭
	`osd_laggy`	2	Laggy OSD 会话

表 8.16. RADOS 网关 Throttle Metrics Table
集合名称	指标名称	位字段值	简短描述
`throttle-*`	`val`	10	当前可用的节流
	`max`	10	throttle 的最大值
	`get`	10	get
	`get_sum`	10	获取数据
	`get_or_fail_fail`	10	get_or_fail 期间被阻止
	`get_or_fail_success`	10	get_or_fail 期间成功获得
	`take`	10	参加
	`take_sum`	10	捕获的数据
	`put`	10	PUT
	`put_sum`	10	放置数据
	`wait`	5	等待延迟

第 9 章 BlueStore

BlueStore 是 OSD 守护进程的新后端对象存储。原始对象存储 FileStore 需要在原始块设备之上使用文件系统。然后，对象写入文件系统。BlueStore 不需要初始文件系统，因为 BlueStore 将对象直接放置在块设备中。

重要

BlueStore 为生产环境中的 OSD 守护进程提供高性能后端。默认情况下，BlueStore 配置为自我调节。如果您确定手动调优的蓝卡环境性能更好，请联系红帽支持并共享您的配置详情，以帮助我们提高自动调节功能。红帽期待您的反馈并感谢您的建议。

9.1. About BlueStore

BlueStore 是 OSD 守护进程的新后端。与原始 FileStore 后端不同，BlueStore 直接将对象存储在块设备中，而没有任何文件系统接口，这会提高集群的性能。

以下是使用 BlueStore 的一些主要功能：

直接管理存储设备: BlueStore 使用原始块设备或分区。这可避免任何可能会限制性能或增加复杂性的本地文件系统（如 XFS）的抽象层。
使用 RocksDB 进行元数据管理: BlueStore 使用 RocksDB 的键值数据库来管理内部元数据，如从对象名称到磁盘上块位置的映射。
完整数据和元数据校验和: 默认情况下，写入 BlueStore 的所有数据和元数据都受到一个或多个校验和的保护。不进行验证，不会从磁盘读取数据或元数据，也不会返回到用户。
写时高效复制: Ceph 块设备和 Ceph 文件系统快照依赖于一种写时复制克隆机制，该克隆机制在 BlueStore 中有效地实施。这会为常规快照和纠删代码池带来高效的 I/O，依靠克隆来实现高效的双阶段提交。
没有大型重复写入: BlueStore 首先将任何新数据写入块设备上的未分配空间，然后提交 RocksDB 事务，该事务更新对象元数据以引用磁盘的新区域。只有写入操作低于可配置的大小阈值时，它才会返回到写入日志方案，类似于 FileStore 的运行方式。
多设备支持: BlueStore 可以使用多个块设备来存储不同的数据，例如：硬盘驱动器(HDD)用于数据，Solid-state Drive(SSD)用于元数据、非易失性内存(NVM)或非易失性随机访问内存(NVRAM)或 RocksDB 写入日志(WAL)的持久内存。详情请查看第 9.2 节 “BlueStore Devices”。
注意
ceph-disk 工具还没有置备多个设备。若要使用多个设备，必须手动设置 OSD。
有效的块设备使用: 由于 BlueStore 不使用任何文件系统，因此可以最大程度减少清除存储设备缓存的需要。

9.2. BlueStore Devices

本节解释了 BlueStore 后端使用的块设备。

BlueStore 管理一个、两个或（在某些情况下）三个存储设备。

主要
WAL
DB

在最简单的情形中，BlueStore 会消耗一个（主要）存储设备。存储设备被分区为包含以下内容的两个部分：

OSD 元数据 ：使用 XFS 格式化的小型分区，其中包含 OSD 的基本元数据。此数据目录包含有关 OSD 的信息，如其标识符、它所属的集群及其私钥环。
数据：一个大型分区，用于巩固直接由 BlueStore 管理且包含所有 OSD 数据的设备的其余部分。此主设备通过数据目录中的块符号链接来标识。

您还可以使用两个额外的设备：

WAL(write-ahead-log)设备 ：存储 BlueStore 内部日志或写入日志的设备。它由数据目录中的 block.wal 符号链接标识。只有在设备比主设备快时才会考虑使用 WAL 设备，例如 WAL 设备使用 SSD 磁盘且主设备使用 HDD 磁盘时。
DB 设备 ：存储 BlueStore 内部元数据的设备。嵌入的 RocksDB 数据库将元数据放置在 DB 设备中，而不是放置到主设备上，以提高性能。如果 DB 设备已满，它开始向主设备添加元数据。只有在设备比主设备快时才考虑使用 DB 设备。

如果您在快速设备中只有 GB 存储，红帽建议将其用作 WAL 设备。如果您有更快的设备可用，请考虑将其用作 DB 设备。BlueStore 日志始终放在最快的设备上，因此使用 DB 设备可以获得与 WAL 设备相同的益处，同时也允许存储额外的元数据。

9.3. BlueStore 缓存

BlueStore 缓存是缓冲区的集合，可以根据配置填充，如 OSD 守护进程从磁盘读取或写入到磁盘时一样。默认情况下，在 Red Hat Ceph Storage 中，BlueStore 会在读取时缓存，但不进行写入。这是因为 bluestore_default_buffered_write 选项被设置为 false，以避免与缓存驱除相关的潜在开销。

如果 bluestore_default_buffered_write 选项被设置为 true，数据会首先写入缓冲区，然后提交到磁盘。之后，会向客户端发送写入确认，以便后续读取缓存中已有数据的速度，直到该数据被驱除。

读取密集型工作负载不会立即从 BlueStore 缓存中受益。随着更多的读取完成，缓存将随着时间增加，后续读取的性能也会得到提升。缓存填充的速度取决于 BlueStore 块和数据库磁盘类型，以及客户端的工作负载要求。

重要

在启用 bluestore_default_buffered_write 选项前，请联系红帽支持。

9.4. BlueStore 的大小注意事项

使用 BlueStore OSD 混合传统和固态硬盘时，适当调整 RocksDB 逻辑卷(block.db)大小非常重要。红帽建议 RocksDB 逻辑卷不少于块大小的 4% 和对象、文件和混合工作负载。红帽支持 1% 的 BlueStore 块大小及 RocksDB 和 OpenStack 块工作负载。例如，如果对象工作负载的块大小为 1 TB，则至少创建一个 40 GB RocksDB 逻辑卷。

如果没有混合驱动器类型，则无需使用单独的 RocksDB 逻辑卷。BlueStore 将自动管理 RocksDB 的大小。

BlueStore 的缓存内存用于 RocksDB、BlueStore 元数据和对象数据的键值对元数据。

注意

BlueStore 缓存内存值是 OSD 已消耗的内存足迹之外的。

9.5. 添加使用 BlueStore 的 OSD

本节介绍如何使用 BlueStore 后端安装新的 Ceph OSD 节点。

先决条件

个正常工作的 Ceph 群集。请参阅 Red Hat Enterprise Linux 或 Ubuntu 安装指南。

流程

在 Ansible 管理节点上使用以下命令：

将新的 OSD 节点添加到 Ansible 清单文件中的 [osds] 部分中，默认位于 /etc/ansible/hosts。
```
[osds]
node1
node2
node3
<hostname>
```
替换：
- <hostname> OSD 节点的名称
例如：
```
[osds]
node1
node2
node3
node4
```

进入 /usr/share/ceph-ansible/ 目录。

[user@admin ~]$ cd /usr/share/ceph-ansible

创建 host_vars 目录。

[root@admin ceph-ansible] mkdir host_vars

在 host_vars 中为新添加的 OSD 创建配置文件。
```
[root@admin ceph-ansible] touch host_vars/<hostname>.yml
```
替换：
- <hostname> 新添加的 OSD 的主机名
例如：
```
[root@admin ceph-ansible] touch host_vars/node4.yml
```
在新创建的文件中添加以下设置：
```
osd_objectstore: bluestore
```
注意
要将 BlueStore 用于所有 OSD，请将 osd_objectstore:bluestore 添加到 group_vars/all.yml 文件中。
可选。如果要将 block.wal 和 block.db 分区存储在专用设备中，请按如下所示编辑 host_vars/<hostname>.yml 文件。
1. 要将专用设备用于 block.wal ：
```
osd_scenario: non-collocated

bluestore_wal_devices:
   - <device>
   - <device>
```
  替换：
  - <device> 使用到该设备的路径
  例如：
```
osd_scenario: non-collocated

bluestore_wal_devices:
   - /dev/sdf
   - /dev/sdg
```
2. 要将专用设备用于 block.db ：
```
osd_scenario: non-collocated

dedicated_devices:
   - <device>
   - <device>
```
  替换：
  - <device> 使用到该设备的路径
  例如：
```
osd_scenario: non-collocated

dedicated_devices:
   - /dev/sdh
   - /dev/sdi
```
  注意
  如果您使用 osd_scenario: collocated 参数，block.wal 和 block.db 分区将使用与 devices 参数相同的设备。详情请参阅 Red Hat Enterprise Linux 或 Ubuntu 的 Red Hat Ceph Storage 3 l 安装指南中的安装 Red Hat Ceph Storage Cluster 部分。
  注意
  要将 BlueStore 用于所有 OSD，请将上述参数添加到 group_vars/osds.yml 文件中。
3. 覆盖 group_vars/all.yml 文件中的 block.db 和 block.wal 默认大小：
```
ceph_conf_overrides:
  osd:
    bluestore_block_db_size: <value>
    bluestore_block_wal_size: <value>
```
  替换：
  - <value> 以字节为单位的大小。
  例如：
```
ceph_conf_overrides:
  osd:
    bluestore_block_db_size: 14336000000
    bluestore_block_wal_size: 2048000000
```
要配置基于 LVM 的 BlueStore OSD，在 host_vars/<hostname>.yml 中使用 osd_scenario: lvm ：
```
osd_scenario: lvm
lvm_volumes:
  - data: <datalv>
    data_vg: <datavg>
```
替换：
- <datalv> 使用数据逻辑卷名称
- <datavg> 使用数据逻辑卷组群名称
例如：
```
osd_scenario: lvm
lvm_volumes:
  - data: data-lv1
    data_vg: vg1
```
可选。如果要将 block.wal 和 block.db 存储在专用逻辑卷中，请按如下方式编辑 host_vars/<hostname>.yml 文件：
```
osd_scenario: lvm
lvm_volumes:
  - data: <datalv>
    wal: <wallv>
    wal_vg: <vg>
    db: <dblv>
    db_vg: <vg>
```
替换：
- <datalv> 带有应包含数据的逻辑卷
- 带有 write-ahead-log 的逻辑卷的 <wallv>
- WAL 和/或 DB 设备 LV 的卷组 <vg>
- 应包含 BlueStore 内部元数据的逻辑卷的 <dblv>
例如：
```
osd_scenario: lvm
lvm_volumes:
  - data: data-lv3
    wal: wal-lv1
    wal_vg: vg3
    db: db-lv3
    db_vg: vg3
```
注意
当将 lvm_volumes: 与 osd_objectstore: bluestore 搭配使用时，lvm_volumes YAML 字典必须至少包含 data。定义 wal 或 db 时，它必须同时具有 LV 名称和 VG 名称（db 和 wal 不需要）。这允许四个组合：仅数据、数据和 wal、数据和 wal 和 wal 和 db，或者数据和 db。数据可以是裸设备、lv 或分区。wal 和 db 可以是 lv 或分区。当指定原始设备或者分区 ceph-volume 时，会在其上面放置逻辑卷。
注意
目前，ceph-ansible 不会创建卷组或者逻辑卷。这必须在运行 Anisble playbook 之前完成。
打开并编辑 group_vars/all.yml 文件，并取消注释 osd_memory_target 选项。调整您希望 OSD 使用的内存量的值。
注意
osd_memory_target 选项的默认值是 4000000000，即 4 GB。这个选项将 BlueStore 缓存固定在内存中。
重要
osd_memory_target 选项只适用于由 BlueStore 支持的 OSD。

使用 ansible-playbook ：

[user@admin ceph-ansible]$ ansible-playbook site.yml

从 monitor 节点，验证新 OSD 是否已成功添加：
```
[root@monitor ~]# ceph osd tree
```

其它资源

使用 Ansible 添加 OSD

9.6. 使用以下方法调优 BlueStore 以实现小写操作 `bluestore_min_alloc_size`

在 BlueStore 中，原始分区以 bluestore_min_alloc_size 的块的形式进行配置和管理。默认情况下，bluestore_min_alloc_size 用于 HDD，16 KB 代表 SSD。当每个块中的未写入区域写入原始分区时，它会被填充为零。如果工作负载没有正确定义未使用空间（例如编写小对象时），这会导致浪费空间。

最佳实践是将 bluestore_min_alloc_size 设置为与最小写入操作相匹配，从而避免产生放大的罚款。

例如，如果您的客户端频繁写入 4 KB 对象，请使用 ceph-ansible 在 OSD 节点上配置以下设置：

bluestore_min_alloc_size = 4096

注意

bluestore_min_alloc_size_ssd 和 bluestore_min_alloc_size_hdd 的设置分别特定于 SSD 和 HDD，但不需要设置它们，因为设置 bluestore_min_alloc_size 会覆盖它们。

先决条件

正在运行的 {storage-product} 集群。
新服务器可以重新调配为 OSD 节点，或者：
可以重新部署的 OSD 节点。

流程

可选：如果重新部署现有的 OSD 节点，请将 Ceph 监控节点上的 /etc/ceph/ 管理密钥环复制到您要从中删除 OSD 的节点。

可选：如果重新部署现有的 OSD 节点，请使用 shrink-osd.yml Ansible playbook 从集群中删除该 OSD。

ansible-playbook -v infrastructure-playbooks/shrink-osd.yml -e osd_to_kill=OSD_ID

示例

[admin@admin ceph-ansible]$ ansible-playbook -v infrastructure-playbooks/shrink-osd.yml -e osd_to_kill=1

如果重新部署现有的 OSD 节点，请擦除 OSD 驱动器并重新安装操作系统。
利用 Ansible，为节点做好 OSD 调配准备。例如，启用 {storage-product} 存储库，添加 Ansible 用户并启用免密码 SSH 登录。
将 bluestore_min_alloc_size 添加到 group_vars/all.yml Ansible playbook 的 ceph_conf_overrides 部分：
```
ceph_conf_overrides:
  osd:
    bluestore_min_alloc_size: 4096
```
如果部署新节点，将其添加到 Ansible 清单文件中，通常： /etc/ansible/hosts
```
[osds]
OSD_NODE_NAME
```
示例
```
[osds]
osd1 devices="[ '/dev/sdb' ]"
```

使用 Ansible 置备 OSD 节点：

ansible-playbook -v site.yml -l OSD_NODE_NAME

示例

[admin@admin ceph-ansible]$ ansible-playbook -v site.yml -l osd1

playbook 完成后，使用 ceph daemon 命令验证设置：

ceph daemon OSD.ID config get bluestore_min_alloc_size

示例

[root@osd1 ~]# ceph daemon osd.1 config get bluestore_min_alloc_size
{
    "bluestore_min_alloc_size": "4096"
}

您可以看到 bluestore_min_alloc_size 设置为 4096 字节，相当于 4 KB。

其它资源

如需更多信息，请参阅 {storage-product} 安装指南。

9.7. BlueStore 分段工具

作为存储管理员，您需要定期检查 BlueStore OSD 的碎片级别。您可以通过一个简单的命令检查碎片级别，以查看离线或在线 OSD。

9.7.1. 先决条件

正在运行的红帽 Ceph 存储 3.3 或更高版本的存储集群。
BlueStore OSDs.

9.7.2. 什么是 BlueStore 碎片工具？

对于 BlueStore OSD，可用空间随时间分散到底层存储设备上。有些碎片通常是正常的，但是当过度碎片化时，这会导致性能下降。

BlueStore 碎片工具会在 BlueStore OSD 的碎片级别生成分数。此分段分数以范围 0 到 1 的形式指定。0 分表示没有碎片，1 分数表示严重碎片。

表 9.1. 分段分数的含义
分数	碎片量
0.0 - 0.4	无可减少碎片.
0.4 - 0.7	小且可接受的碎片.
0.7 - 0.9	相当大，但安全碎片.
0.9 - 1.0	严重碎片，导致性能问题.

重要

如果您有严重的碎片，并且需要某些帮助来解决此问题，请联系红帽支持团队。

9.7.3. 检查碎片

可以在线或脱机检查 BlueStore OSD 的碎片级别。

先决条件

正在运行的红帽 Ceph 存储 3.3 或更高版本的存储集群。
BlueStore OSDs.

在线 BlueStore 分段分数

检查正在运行的 BlueStore OSD 进程：

简单报告：

语法

ceph daemon OSD_ID bluestore allocator score block

示例

[root@osd ~]# ceph daemon osd.123 bluestore allocator score block

更详细的报告：

语法

ceph daemon OSD_ID bluestore allocator dump block

示例

[root@osd ~]# ceph daemon osd.123 bluestore allocator dump block

offline BlueStore 分段分数

检查非运行的 BlueStore OSD 进程：

简单报告：

语法

ceph-bluestore-tool --path PATH_TO_OSD_DATA_DIRECTORY --allocator block free-score

示例

[root@osd ~]# ceph-bluestore-tool --path /var/lib/ceph/osd/ceph-123 --allocator block free-score

更详细的报告：

语法

ceph-bluestore-tool --path PATH_TO_OSD_DATA_DIRECTORY --allocator block free-dump

示例

[root@osd ~]# ceph-bluestore-tool --path /var/lib/ceph/osd/ceph-123 --allocator block free-dump

其它资源

如需了解碎片分数的详细信息，请参阅红帽 Ceph 存储 3.3 BlueStore 片段工具。

附录 A. 错误代码定义 `ceph-medic`

ceph-medic 工具为任何失败的检查显示错误代码和消息。这些错误代码是警告或错误，应用到 Ceph 守护进程特定的常见问题。错误代码以 E 和 warning 代码开头，以 W 开头。

常见错误信息

ECOM1: 无法在 /etc/ceph/$CLUSTER_NAME.conf 找到 Ceph 配置文件。
ECOM2: 未找到 ceph 可执行文件。
ECOM3: /var/lib/ceph/ 目录不存在或无法访问。
ECOM4: /var/lib/ceph/ 目录不归 ceph 用户所有。
ECOM5: Ceph 配置中的 fsid 在存储集群中的节点之间有所不同。
ECOM6: 安装的 Ceph 版本与存储集群中的节点不同。
ECOM7: 安装的 Ceph 版本与正在运行的套接字的不同。
ECOM8: Ceph 配置中没有找到 fsid。
ECOM9: 来自运行套接字的集群 FSID 与存储集群中的节点不同。
ECOM10: 有多个运行中的监视器。

监控错误信息

EMON1: 密钥环中使用的 secret 密钥在存储集群中的节点之间有所不同。

监控警告消息

WMON1: 同一节点上可以找到多个 monitor 目录。
WMON2: 在 monitor 节点上找到的位置并置 OSD。

OSD Warning 消息

WOSD1: 在 /var/lib/ceph/osd/ 目录中找到多个 ceph_fsid 值。

管理指南

管理 Red Hat Ceph Storage

第 1 章 Ceph 管理概述

其它资源

第 2 章 了解 Ceph 的进程管理

2.1. 先决条件

2.2. Ceph 的进程管理概述

其它资源

2.3. 启动、停止和重新启动所有 Ceph 守护进程

先决条件

流程

2.4. 按类型启动、停止和重新启动 Ceph 守护进程

先决条件

流程

2.5. 按实例启动、停止和重新启动 Ceph 守护进程

先决条件

流程

2.6. 关闭并重启 Red Hat Ceph Storage 集群

2.7. 其它资源

第 3 章 监控

3.1. 高级监控

3.1.1. 互动模式

3.1.2. 检查集群健康状况

3.1.3. 监控集群

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

3.1.5. 检查集群状态

3.1.6. 检查 monitor 状态

3.1.7. 使用管理套接字

3.1.8. 检查 OSD 状态

3.2. 低级监控

3.2.1. 放置组集

3.2.2. peering

3.2.3. 监控 PG 状态

3.2.3.1. Create

3.2.3.2. peering

3.2.3.3. Active

3.2.3.4. clean

3.2.3.5. degraded

3.2.3.6. 恢复

3.2.3.7. 回填

3.2.3.8. 强制恢复或回填操作的优先级

3.2.3.9. 更改或取消恢复或回填操作的优先级

3.2.3.10. 为池强制高优先级恢复或回填操作

3.2.3.11. 取消池的高优先级恢复或回填操作

3.2.3.12. 重新安排池的恢复和回填操作的优先级

3.2.3.13. RADOS 中 PG 恢复的优先级

3.2.3.14. remapped

3.2.3.15. stale

3.2.3.16. 放置错误

3.2.3.17. 不完整

3.2.4. 识别故障排除 PG

3.2.5. 查找对象位置

3.3. 使用红帽 Ceph 存储仪表板监控 Ceph 存储集群

先决条件

3.3.1. Red Hat Ceph Storage Dashboard

3.3.2. 安装 Red Hat Ceph Storage Dashboard

3.3.3. 访问 Red Hat Ceph Storage Dashboard

先决条件

流程

其它资源

3.3.4. 更改默认的 Red Hat Ceph Storage 仪表板密码

3.3.5. Red Hat Ceph Storage 的 Prometheus 插件

3.3.5.1. 先决条件

3.3.5.2. Prometheus 插件

3.3.5.3. 管理 Prometheus 环境

3.3.5.4. 使用 Prometheus 表达式浏览器

3.3.5.5. 使用 Prometheus 数据和查询

3.3.5.6. 其它资源

3.3.6. Red Hat Ceph Storage Dashboard 警告

3.3.6.1. 先决条件

3.3.6.2. 关于警报

3.3.6.3. 访问 Alert Status 仪表板

流程

3.3.6.4. 配置通知目标

流程

3.3.6.5. 更改默认警报和添加新警报

流程

其它资源

3.4. 使用 ceph-medic 诊断 Ceph 存储集群

3.4.1. 先决条件

第 2 章了解 Ceph 的进程管理

第 3 章监控

3.4. 使用 `ceph-medic` 诊断 Ceph 存储集群

3.4.2. 安装 `ceph-medic` 实用程序

第 5 章用户管理

第 6 章使用 `ceph-volume` 实用程序部署 OSD

6.1. 使用 `ceph-volume` LVM 插件

6.1.4. 使用 `batch` 模式

第 7 章基准测试性能

第 8 章性能计数器

9.6. 使用以下方法调优 BlueStore 以实现小写操作 `bluestore_min_alloc_size`