支持控制台（Console）开发人员开始试用联系人

管理指南

Red Hat Ceph Storage 4

管理 Red Hat Ceph Storage

摘要

本文档论述了如何管理进程、监控集群状态、管理用户以及添加和删除 Red Hat Ceph Storage 的守护进程。
红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始：master、slave、黑名单和白名单。由于此项工作十分艰巨，这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 信息。

第 1 章 Ceph 管理

Red Hat Ceph Storage 集群是所有 Ceph 部署的基础。部署 Red Hat Ceph Storage 集群后，相关的管理操作可以保持 Red Hat Ceph Storage 集群运行正常且处于最佳状态。

Red Hat Ceph Storage 管理指南可帮助存储管理员执行这些任务，例如：

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

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

  • Ceph Object Storage Device (OSD) 将数据存储在分配给 OSD 的 PG 内
  • Ceph Monitor 维护集群映射的一个主（master）副本

生产系统具有三个或更多 Ceph 监控功能，以实现高可用性，一般最少 50 个 OSD 用于可接受的负载平衡、数据重新平衡和数据恢复。

其它资源

第 2 章 了解 Ceph 的进程管理

作为存储管理员，您可以按裸机或容器中的类型或实例来操作各种 Ceph 守护进程。通过操作这些守护进程，您可以根据需要启动、停止和重启所有 Ceph 服务。

2.1. 先决条件

  • 安装 Red Hat Ceph Storage 软件。

2.2. Ceph 进程管理

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

其它资源

  • 有关使用 Systemd 的更多信息，请参阅 Red Hat Enterprise Linux 系统管理员指南中的使用 systemd 管理服务的章节。

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

以 admin 用户身份启动、停止和重启所有 Ceph 守护进程。

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 具有对节点的 root 访问权限。

流程

  1. 启动所有 Ceph 守护进程： 

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

  2. 停止所有 Ceph 守护进程： 

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

  3. 重启所有 Ceph 守护进程： 

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

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

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

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 具有对节点的 root 访问权限。

流程

  • 在 Ceph 监控 节点上：

    启动：

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

    停止：

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

    重启：

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

  • 在 Ceph Manager 节点上：

    启动：

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

    停止：

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

    重启：

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

  • 在 Ceph OSD 节点上：

    启动：

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

    停止：

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

    重启：

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

  • 在 Ceph 对象网关 节点上：

    启动：

    [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 守护进程的节点上按照以下步骤操作。

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 具有对节点的 root 访问权限。

流程

  • 在 Ceph 监控 节点上：

    启动：

    [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

    替换

    • MONITOR_HOST_NAME，名称为 Ceph Monitor 节点。

  • 在 Ceph Manager 节点上：

    启动：

    [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

    替换

    • MANAGER_HOST_NAME，名称为 Ceph Manager 节点。

  • 在 Ceph OSD 节点上：

    启动：

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

    停止：

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

    重启：

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

    替换

    • OSD_NUMBER 为 Ceph OSD 的 ID 数。

      例如，当查看 ceph osd tree 命令输出时，osd.0 的 ID 为 0。

  • 在 Ceph 对象网关 节点上：

    启动：

    [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

    替换

    • OBJ_GATEWAY_HOST_NAME，名称为 Ceph 对象网关节点。

2.6. 启动、停止和重启容器中运行的 Ceph 守护进程

使用 systemctl 命令启动、停止或重启容器中运行的 Ceph 守护进程。

前提条件

  • 安装 Red Hat Ceph Storage 软件。
  • 节点的根级别访问权限。

流程

  1. 要启动、停止或重启容器中运行的 Ceph 守护进程，请以以下格式组成的 root 命令运行 systemctl 命令： 

    systemctl ACTION ceph-DAEMON@ID
    替换
    • ACTION 是要执行的操作；start, stop, 或 restart。
    • DAEMON 是守护进程； osd、mon、mds 或 rgw。

    • ID 是其中之一：

      • 运行 ceph-mon、ceph-mds 或 ceph-rgw 守护进程的短主机名。
      • ceph-osd 守护进程的 ID （如果部署）。

    例如，要重启 ID 为 osd01 的 ceph-osd 守护进程： 

    [root@osd ~]# systemctl restart ceph-osd@osd01

    要启动 ceph-mon demon，在 ceph-monitor01 主机上运行： 

    [root@mon ~]# systemctl start ceph-mon@ceph-monitor01

    停止在 ceph-rgw01 主机上运行的 ceph-rgw 守护进程： 

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

  2. 验证操作是否已成功完成。 

    systemctl status ceph-DAEMON@ID

    例如： 

    [root@mon ~]# systemctl status ceph-mon@ceph-monitor01

其它资源

2.7. 查看容器中运行的 Ceph 守护进程的日志

使用容器主机中的 journald 守护进程，从容器中查看 Ceph 守护进程的日志。

前提条件

  • 安装 Red Hat Ceph Storage 软件。
  • 节点的根级别访问权限。

流程

  1. 要查看整个 Ceph 日志，请以以下格式组成的 root 用户身份运行 journalctl 命令： 

    journalctl -u ceph-DAEMON@ID
    替换
    • DAEMON 是 Ceph 守护进程； osd、mon 或 rgw。

    • ID 是其中之一：

      • 运行 ceph-mon、ceph-mds 或 ceph-rgw 守护进程的短主机名。
      • ceph-osd 守护进程的 ID （如果部署）。

    例如，使用 ID osd01 查看 ceph-osd 守护进程的完整日志： 

    [root@osd ~]# journalctl -u ceph-osd@osd01

  2. 要只显示最新的日志条目，请使用 -f 选项。 

    journalctl -fu ceph-DAEMON@ID

    例如，仅查看 ceph-mon 守护进程最近在 ceph-monitor01 主机上运行的日志条目： 

    [root@mon ~]# journalctl -fu ceph-mon@ceph-monitor01
注意

您还可以使用 sosreport 实用程序查看 journald 日志。有关 SOS 报告的详情，请查看 什么是 sosreport 以及如何在 Red Hat Enterprise Linux 中创建它？ 红帽客户门户网站上的解决方案。

其它资源

  • journalctl (1) 手册页。

2.8. 为容器化 Ceph 守护进程启用日志记录到文件

默认情况下，容器化 Ceph 守护进程不记录到文件。您可以使用集中式配置管理，使容器化 Ceph 守护进程能够记录到文件。

前提条件

  • 安装 Red Hat Ceph Storage 软件。
  • 根级别访问运行容器化守护进程的节点。

流程

  1. 进入 var/log/ceph 目录：

    Example

    [root@host01 ~]# cd /var/log/ceph

  2. 记录任何现有日志文件。

    语法

    ls -l /var/log/ceph/

    Example

    [root@host01 ceph]# ls -l /var/log/ceph/
total 396
-rw-r--r--. 1 ceph ceph 107230 Feb  5 14:42 ceph-osd.0.log
-rw-r--r--. 1 ceph ceph 107230 Feb  5 14:42 ceph-osd.3.log
-rw-r--r--. 1 root root 181641 Feb  5 14:42 ceph-volume.log

    在示例中，登录 OSD.0 和 OSD.3 的文件已经启用。

  3. 获取您要启用日志记录的守护进程的容器名称：

    Red Hat Enterprise Linux 7

    [root@host01 ceph]# docker ps -a

    Red Hat Enterprise Linux 8

    [root@host01 ceph]# podman ps -a

  4. 使用集中式配置管理，为 Ceph 守护进程启用文件日志记录。

    Red Hat Enterprise Linux 7

    docker exec CONTAINER_NAME ceph config set DAEMON_NAME log_to_file true

    Red Hat Enterprise Linux 8

    podman exec CONTAINER_NAME ceph config set DAEMON_NAME log_to_file true

    DAEMON_NAME 由 CONTAINER_NAME 派生而来。删除 ceph-，并将守护进程和守护进程 ID 之间的连字符替换为一个句点。

    Red Hat Enterprise Linux 7

    [root@host01 ceph]# docker exec ceph-mon-host01 ceph config set mon.host01 log_to_file true

    Red Hat Enterprise Linux 8

    [root@host01 ceph]# podman exec ceph-mon-host01 ceph config set mon.host01 log_to_file true

  5. 可选：要为集群日志启用日志日志，请使用 mon_cluster_log_to_file 选项：

    Red Hat Enterprise Linux 7

    docker exec CONTAINER_NAME ceph config set DAEMON_NAME mon_cluster_log_to_file true

    Red Hat Enterprise Linux 8

    podman exec CONTAINER_NAME ceph config set DAEMON_NAME mon_cluster_log_to_file true

    Red Hat Enterprise Linux 7

    [root@host01 ceph]# docker exec ceph-mon-host01 ceph config set mon.host01 mon_cluster_log_to_file true

    Red Hat Enterprise Linux 8

    [root@host01 ceph]# podman exec ceph-mon-host01 ceph config set mon.host01 mon_cluster_log_to_file true

  6. 验证更新的配置：

    Red Hat Enterprise Linux 7

    docker exec CONTAINER_NAME ceph config show-with-defaults DAEMON_NAME | grep log_to_file

    Red Hat Enterprise Linux 8

    podman exec CONTAINER_NAME ceph config show-with-defaults DAEMON_NAME | grep log_to_file

    Example

    [root@host01 ceph]# podman exec ceph-mon-host01 ceph config show-with-defaults mon.host01 | grep log_to_file
log_to_file                                                true                                                                                                                                                                                                                                      mon      default[false]
mon_cluster_log_to_file                                    true                                                                                                                                                                                                                                      mon      default[false]

  7. 可选：重启 Ceph 守护进程：

    语法

    systemctl restart ceph-DAEMON@DAEMON_ID

    Example

    [root@host01 ceph]# systemctl restart ceph-mon@host01

  8. 验证新日志文件是否存在：

    语法

    ls -l /var/log/ceph/

    Example

    [root@host01 ceph]# ls -l /var/log/ceph/
total 408
-rw-------. 1 ceph ceph    202 Feb  5 16:06 ceph.audit.log
-rw-------. 1 ceph ceph   3182 Feb  5 16:06 ceph.log
-rw-r--r--. 1 ceph ceph   2049 Feb  5 16:06 ceph-mon.host01.log
-rw-r--r--. 1 ceph ceph 107230 Feb  5 14:42 ceph-osd.0.log
-rw-r--r--. 1 ceph ceph 107230 Feb  5 14:42 ceph-osd.3.log
-rw-r--r--. 1 root root 181641 Feb  5 14:42 ceph-volume.log

    创建了两个新文件，ceph-mon.host01.log 用于 monitor 守护进程和 ceph.log，用于集群日志。

其它资源

  • 有关更多信息，请参阅 Red Hat Ceph Storage 故障排除指南中的 配置日志记录 部分。

2.9. 收集 Ceph 守护进程的日志文件

若要收集 Ceph 守护进程的日志文件，请运行 gather-ceph-logs.yml Ansible playbook。目前，Red Hat Ceph Storage 仅支持为非容器化部署收集日志。

前提条件

  • 已部署正在运行的 Red Hat Ceph Storage 集群。
  • 对 Ansible 节点的管理员级访问。

流程

  1. 进入 /usr/share/ceph-ansible 目录： 

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

  2. 运行 playbook： 

    [ansible@admin ~]# ansible-playbook infrastructure-playbooks/gather-ceph-logs.yml -i hosts
  3. 等待在 Ansible 管理节点上收集日志。

其它资源

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

按照以下步骤关闭和重新引导 Ceph 集群。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 具有 root 访问权限。

流程

关闭 Red Hat Ceph Storage 集群

  1. 停止使用该集群上的 RBD 镜像和 RADOS 网关以及任何其他客户端的客户端。
  2. 在继续操作前，集群必须处于健康状态（Health_OK 以及所有的 PG 为 active+clean）。在具有客户端密钥环的节点上运行 ceph 状态，如 Ceph 监控器或 OpenStack 控制器节点，以确保集群健康。

  3. 如果使用 Ceph 文件系统(CephFS)，则必须关闭 CephFS 集群。缩减 CephFS 集群是通过将排名数量减少到 1 来完成，设置 cluster_down 标志，然后对最后的等级失败。

    例如：

    [root@osd ~]# ceph fs set FS_NAME max_mds 1
[root@osd ~]# ceph mds deactivate FS_NAME:1 # rank 2 of 2
[root@osd ~]# ceph status # wait for rank 1 to finish stopping
[root@osd ~]# ceph fs set FS_NAME cluster_down true
[root@osd ~]# ceph mds fail FS_NAME:0

    设置 cluster_down 标志可防止待机使用失败的等级。

  4. 设置 noout、norecover、norebalance、nobackfill、nodown 和 pause 标志。在具有客户端密钥环的节点上运行以下命令：例如，Ceph Monitor 或 OpenStack 控制器节点： 

    [root@mon ~]# ceph osd set noout
[root@mon ~]# ceph osd set norecover
[root@mon ~]# ceph osd set norebalance
[root@mon ~]# ceph osd set nobackfill
[root@mon ~]# ceph osd set nodown
[root@mon ~]# ceph osd set pause

  5. 逐一关闭 OSD 节点： 

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

  6. 逐一关闭 monitor 节点： 

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

重新引导 Red Hat Ceph Storage 集群

  1. 启动管理节点。

  2. 打开监控节点： 

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

  3. 打开 OSD 节点： 

    [root@osd ~]# systemctl start ceph-osd.target
  4. 等待所有节点上线。验证所有服务都已启动，且节点之间的连接是正常的。

  5. 取消设置 noout、norecover、norebalance、nobackfill、nodown 和 pause 标志。在具有客户端密钥环的节点上运行以下命令：例如，Ceph Monitor 或 OpenStack 控制器节点： 

    [root@mon ~]# ceph osd unset noout
[root@mon ~]# ceph osd unset norecover
[root@mon ~]# ceph osd unset norebalance
[root@mon ~]# ceph osd unset nobackfill
[root@mon ~]# ceph osd unset nodown
[root@mon ~]# ceph osd unset pause

  6. 如果使用 Ceph 文件系统(CephFS)，则必须通过将 cluster_down 标志设置为 false 来备份 CephFS 集群： 

    [root@admin~]# ceph fs set FS_NAME cluster_down false
  7. 验证集群处于健康状态（Health_OK 和所有 PG active+clean）。在具有客户端密钥环的节点中运行 ceph status。例如，Ceph Monitor 或 OpenStack 控制器节点确保集群运行正常。

2.11. 其它资源

第 3 章 监控 Ceph 存储集群

作为存储管理员，您可以监控 Red Hat Ceph Storage 集群的整体健康状况，以及监控 Ceph 各个组件的健康状态。

运行 Red Hat Ceph Storage 集群后，您可以开始监控存储集群，以确保 Ceph 监控器和 Ceph OSD 守护进程在高级别中运行。Ceph 存储集群客户端连接到 Ceph Monitor 并接收最新版本的存储集群映射，然后才能将数据读取和写入到存储集群中的 Ceph 池。因此，在 Ceph 客户端可以读取和写入数据之前，监控器集群必须拥有集群状态的协议。

Ceph OSD 必须将主 OSD 上的放置组与次要 OSD 上的 PG 的副本进行对等（peer）。如果出现错误，则 peering 将处于 active + clean 以外的状态。

3.1. 先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。

3.2. Ceph 存储集群的高级别监控

作为存储管理员，您可以监控 Ceph 守护进程的健康状况，以确保它们已启动并在运行。高级别监控还涉及检查存储集群容量，以确保存储集群不会超过其全满比率（full ratio）。Red Hat Ceph Storage 控制面板 是进行高级别监控的最常见方法。但是，您也可以使用命令行界面、Ceph 管理 socket 或 Ceph API 来监控存储集群。

3.2.1. 先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。

3.2.2. 以互动方式使用 Ceph 命令行界面

您可以使用 ceph 命令行工具与 Ceph 存储集群进行交互。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 以交互模式运行 ceph 实用程序。

    1. 裸机部署：

      示例

      [root@mon ~]# ceph
ceph> health
ceph> status
ceph> quorum_status
ceph> mon_status

    2. 容器部署：

      Red Hat Enterprise Linux 7

      docker exec -it ceph-mon-MONITOR_NAME /bin/bash

      Red Hat Enterprise Linux 8

      podman exec -it ceph-mon-MONITOR_NAME /bin/bash

      替换

      • MONITOR_NAME 使用 Ceph Monitor 容器的名称，分别通过分别运行 docker ps 或 podman ps 命令找到。

        Example

        [root@container-host ~]# podman exec -it ceph-mon-mon01 /bin/bash

        本例在 mon01 上打开一个交互式终端会话，您可以在其中启动 Ceph 交互式 shell。

3.2.3. 检查存储集群健康状况

启动 Ceph 存储集群后，在开始读取或写入数据前，首先检查存储集群的健康状态。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 您可以使用以下方法检查 Ceph 存储集群的运行状况： 

    [root@mon ~]# ceph health

  2. 如果您为配置或密钥环指定了非默认位置，您可以指定它们的位置： 

    [root@mon ~]# ceph -c /path/to/conf -k /path/to/keyring health

在启动 Ceph 集群时，您可能会遇到运行状况警告，如 HEALTH_WARN XXX num placement groups stale。等待几分钟，然后再次检查。当存储集群就绪时，ceph health 应返回一个如 HEALTH_OK 的消息。此时，可以开始使用群集。

3.2.4. 监视存储集群事件

您可以使用命令行界面观察 Ceph 存储集群发生的事件。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 要在命令行中监控集群的持续事件，请打开一个新终端，然后输入： 

    [root@mon ~]# ceph -w

    Ceph 将打印每个事件。例如，一个由一个 monitor 和两个 OSD 组成的小型 Ceph 集群可能会打印以下内容： 

    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 的状态
    • 放置组映射版本
    • 放置组和池的数量
    • 存储的 数据数量和存储的对象数量
    • 保存的数据总量

3.2.5. Ceph 如何计算数据使用量

used 值反映了使用的实际原始存储量。xxx GB / xxx GB 代表可用的存储（其中较小的数字）和总存储容量。总容量反映了在复制、克隆或快照前存储数据的大小。因此，实际存储的数据量通常会超过名义上的存储量。这是因为 Ceph 会创建数据的副本，进行克隆和快照也需要使用存储。

3.2.6. 了解存储集群用量统计

要检查集群的数据使用量和数据分布在池间，请使用 df 选项。它类似于 Linux df 命令。您可以运行 ceph df 命令或 ceph df detail 命令。

示例

[root@mon ~]# ceph df
RAW STORAGE:
    CLASS     SIZE       AVAIL      USED        RAW USED     %RAW USED
    hdd       90 GiB     84 GiB     100 MiB      6.1 GiB          6.78
    TOTAL     90 GiB     84 GiB     100 MiB      6.1 GiB          6.78

POOLS:
    POOL                          ID     STORED      OBJECTS     USED        %USED     MAX AVAIL
    .rgw.root                      1     1.3 KiB           4     768 KiB         0        26 GiB
    default.rgw.control            2         0 B           8         0 B         0        26 GiB
    default.rgw.meta               3     2.5 KiB          12     2.1 MiB         0        26 GiB
    default.rgw.log                4     3.5 KiB         208     6.2 MiB         0        26 GiB
    default.rgw.buckets.index      5     2.4 KiB          33     2.4 KiB         0        26 GiB
    default.rgw.buckets.data       6     9.6 KiB          15     1.7 MiB         0        26 GiB
    testpool                      10       231 B           5     384 KiB         0        40 GiB

ceph df detail 命令提供了更多关于其他池统计数据的详细信息，如配额对象、配额字节、压缩状态等。

示例

[root@mon ~]# ceph df detail
RAW STORAGE:
    CLASS     SIZE       AVAIL      USED        RAW USED     %RAW USED
    hdd       90 GiB     84 GiB     100 MiB      6.1 GiB          6.78
    TOTAL     90 GiB     84 GiB     100 MiB      6.1 GiB          6.78

POOLS:
    POOL                          ID     STORED      OBJECTS     USED        %USED     MAX AVAIL     QUOTA OBJECTS     QUOTA BYTES     DIRTY     USED COMPR     UNDER COMPR
    .rgw.root                      1     1.3 KiB           4     768 KiB         0        26 GiB     N/A               N/A                 4            0 B             0 B
    default.rgw.control            2         0 B           8         0 B         0        26 GiB     N/A               N/A                 8            0 B             0 B
    default.rgw.meta               3     2.5 KiB          12     2.1 MiB         0        26 GiB     N/A               N/A                12            0 B             0 B
    default.rgw.log                4     3.5 KiB         208     6.2 MiB         0        26 GiB     N/A               N/A               208            0 B             0 B
    default.rgw.buckets.index      5     2.4 KiB          33     2.4 KiB         0        26 GiB     N/A               N/A                33            0 B             0 B
    default.rgw.buckets.data       6     9.6 KiB          15     1.7 MiB         0        26 GiB     N/A               N/A                15            0 B             0 B
    testpool                      10       231 B           5     384 KiB         0        40 GiB     N/A               N/A                 5            0 B             0 B

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

  • CLASS： 所用的设备类型。

  • SIZE： 由存储集群管理的整体存储容量。

    在上例中，如果 SIZE 是 90 GiB，它是不包括复制因子（默认为三）的总大小。带有复制因子的可用的总容量为 30 GiB（90 GiB/3）。根据全满比率（默认为 0.85%），最大可用空间为 30 GiB * 0.85 = 25.5 GiB

  • AVAIL： 存储集群中可用空间的数量。

    在上例中，如果 SIZE 是 90 GiB，而 USED 空间为 6 GiB，则 AVAIL 空间为 84 GiB。带有复制因素的总可用空间（默认为 84 GiB/3 = 28 GiB）

  • USED： 存储集群中的已用空间由用户数据、内部开销或保留容量使用。

    在上例中，100 MiB 是在考虑了复制因子后的总可用空间。实际可用大小为 33 MiB。

  • RAW USED ：USED 以及分配给 db 和 wal BlueStore 分区的空间的总和。
  • % RAW USED： RAW USED 的百分比 .使用这个数值以及 full ratio 和 near full ratio，以确保您没有消耗倒所有的存储集群容量。

输出的 POOLS 部分提供了池列表以及每个池的使用情况。本节的输出不会反映副本、克隆或快照的情况。例如，如果您存储 1 MB 的数据的对象，名义的使用量为 1 MB，但实际使用量可能为 3 MB 或更多。具体的实际使用量取决于副本的数量（例如： size = 3）、克隆和快照。

  • POOL：池的名称。
  • ID: 池 ID。
  • STORED: 用户存储在池中的实际数据量。
  • OBJECTS: 每个池存储的名义数量。
  • USED: 存储以 KB 为单位的数据数量，除非数字带有 M（megabyte）或 G（gigabytes）。它是 STORED 大小 * 复制因素。
  • %USED: 每个池使用的名义存储的百分比。

  • MAX AVAIL: 可以写入这个池的数据数量的估计值。它是在第一个 OSD 变为满之前可以使用的数据量。它考虑了 CRUSH map 中跨磁盘的项目分布数据，并使用第一个 OSD 来填充作为目标。

    在上例中，MAX AVAIL 为 153.85，而不考虑复制因素，默认为三。

    如需 简单的复制池，请参阅知识库文章 ceph df AVAIL，以计算 MAX AVAIL 的值。

  • QUOTA OBJECTS： 配额对象的数量。
  • QUOTA BYTES： 配额对象中的字节数。
  • USED COMPR： 为压缩数据分配的空间量，包括其压缩数据、分配、复制和擦除编码开销。
  • UNDER COMPR: 通过压缩格式传输的数据量，以压缩形式存储有更多益处。
注意

POOLS 部分中的数字是估算的。它们不包括副本数、快照或克隆的数量。因此，USED 和 %USED 数值的总和可能会与输出的 GLOBAL 部分中的 RAW USED 和 %RAW USED 不同。

注意

MAX AVAIL 值是所用的复制或纠删代码的一个复杂功能，CRUSH 规则将存储映射到设备、这些设备的使用以及配置的 mon_osd_full_ratio。

其它资源

3.2.7. 了解 OSD 使用统计

使用 ceph osd df 命令查看 OSD 使用率统计。 

[root@mon]# ceph osd df
ID CLASS WEIGHT  REWEIGHT SIZE    USE     DATA    OMAP    META    AVAIL   %USE VAR  PGS
 3   hdd 0.90959  1.00000  931GiB 70.1GiB 69.1GiB      0B    1GiB  861GiB 7.53 2.93  66
 4   hdd 0.90959  1.00000  931GiB 1.30GiB  308MiB      0B    1GiB  930GiB 0.14 0.05  59
 0   hdd 0.90959  1.00000  931GiB 18.1GiB 17.1GiB      0B    1GiB  913GiB 1.94 0.76  57
MIN/MAX VAR: 0.02/2.98  STDDEV: 2.91
  • ID: OSD 的名称。
  • CLASS: OSD 使用的设备类型。
  • WEIGHT: CRUSH 映射中的 OSD 权重。
  • REWEIGHT： 默认的重新加权值。
  • SIZE： OSD 的整体存储容量。
  • USE： OSD 容量。
  • DATA: 用户数据使用的 OSD 容量量。
  • OMAP： 用于存储对象映射(omap)数据（rocksdb 中存储的键值对）的 bluefs 存储的估算值。
  • META： 分配的 bluefs 空间或在 bluestore_bluefs_min 参数中设置的值（取决于哪个值更大），对于内部元数据，它的值是在 bluefs 中分配的总空间减去预计的 omap 数据大小。
  • AVAIL： OSD 上可用的空间量。
  • %USE： OSD 使用的存储百分比
  • VAR： 高于或低于平均利用率的差异。
  • PGS： OSD 中的置放组数量。
  • MIN/MAX VAR： 所有 OSD 的最小和最大变化。

其它资源

3.2.8. 检查 Red Hat Ceph Storage 集群状态

您可以从命令行界面查看 Red Hat Ceph Storage 集群的状态。status 子命令或 -s 参数将显示存储集群的当前状态。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 要检查存储集群的状态，请执行以下操作： 

    [root@mon ~]# ceph status

    或者： 

    [root@mon ~]# ceph -s

  2. 在互动模式中，键入 status 并按 Enter ： 

    [root@mon ~]# ceph> status

    例如，一个由一个 monitor 组成的 tiny Ceph 集群，两个 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.2.9. 检查 Ceph Monitor 状态

如果存储集群有多个 Ceph Monitor，这是生产环境 Red Hat Ceph Storage 集群的要求，然后在启动存储集群后检查 Ceph monitor 仲裁状态，然后再执行任何读取或写入数据。

当多个 monitor 正在运行时，必须存在仲裁。

定期检查 Ceph Monitor 状态，以确保它们正在运行。如果 Ceph Monitor 存在问题，这可以防止存储集群的状态存在协议，则故障可能会阻止 Ceph 客户端读取和写入数据。

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 要显示 monitor map，请执行以下操作： 

    [root@mon ~]# ceph mon stat

    或者 

    [root@mon ~]# ceph mon dump

  2. 要检查存储集群的仲裁状态，请执行以下操作： 

    [root@mon ~]# ceph quorum_status -f json-pretty

    Ceph 将返回仲裁状态。由三个监控器组成的 Red Hat Ceph Storage 集群可能会返回以下内容：

    Example

    { "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.2.10. 使用 Ceph 管理 socket

使用管理套接字可以通过 UNIX 套接字文件直接与给定守护进程交互。例如，这个套接字可以：

  • 在运行时列出 Ceph 配置
  • 在运行时直接设置配置值，而不依赖 Monitor。当 Monitor 停机时，这非常有用。
  • 转储历史操作
  • 转储操作优先级队列状态
  • 在不重启的情况下转储操作
  • 转储性能计数器

另外，在对 monitor 或 OSD 相关的问题进行故障排除时，使用 socket 很有用。

重要

管理套接字仅在守护进程正在运行时才可用。当您正确关闭守护进程时，管理套接字会被删除。但是，如果守护进程意外终止，管理套接字可能仍然会被保留。

无论如何，如果守护进程没有运行，在尝试使用管理套接字时会返回以下错误： 

Error 111: Connection Refused

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 使用套接字：

    语法

    [root@mon ~]# ceph daemon TYPE.ID COMMAND

    替换：

    • 使用 Ceph 守护进程类型 TYPE (mon、osd、mds)。
    • 带有守护进程 ID 的 ID

    • 带有要运行的命令的 COMMAND。使用 help 列出给定守护进程的可用命令。

      Example

      要查看名为 mon.0 的 Ceph monitor 的 monitor 状态： 

      [root@mon ~]# ceph daemon mon.0 mon_status

  2. 或者，使用其套接字文件指定 Ceph 守护进程： 

    ceph daemon /var/run/ceph/SOCKET_FILE COMMAND

  3. 查看名为 osd.2 的 Ceph OSD 的状态： 

    [root@mon ~]# ceph daemon /var/run/ceph/ceph-osd.2.asok status

  4. 列出 Ceph 进程的所有套接字文件： 

    [root@mon ~]# ls /var/run/ceph

其它资源

3.2.11. 了解 Ceph OSD 状态

OSD 的状态在集群中是，位于，或从集群 之外。它是 up 和 running、up up 或 down。如果 OSD 为 up，它可以 位于 存储集群中，其中可以读取和写入数据，或者存储集群 之外。如果 集群中有 它，并且最近从集群中 移出，Ceph 会将放置组迁移到其他 OSD。如果 OSD 超出 集群，CRUSH 不会将 PG 分配给 OSD。如果 OSD 为 down，它也应为 out。

注意

如果 OSD 为 down 和 in，则代表有一个问题，集群也不会处于健康状态。

OSD 状态

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

  • 还没有启动集群，它不会响应。
  • 您刚启动或重启集群，但还没有就绪，因为 PG 已创建，并且 OSD 在 peering 过程中。
  • 您刚添加或删除 OSD。
  • 您刚刚修改 cluster map。

监控 OSD 的一个重要方面是，确保集群在启动和运行，所有 in 集群中的 OSD 都为 up 且在运行。

要查看所有 OSD 是否在运行，请执行： 

[root@mon ~]# ceph osd stat

或者 

[root@mon ~]# ceph osd dump

结果应该提供了映射的 epoch, eNNNN, OSD 的总数， x, 多少 y 为e up，多少 z, 为 in： 

eNNNN: x osds: y up, z in

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

[root@mon ~]# ceph osd tree

Example

# 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 节点，或者您可以使用命令行。

Example

[root@mon ~]# systemctl start ceph-osd@OSD_ID

3.2.12. 其它资源

3.3. Ceph 存储集群的低级别监控

作为存储管理员，您可以从低级角度监控 Red Hat Ceph Storage 集群的健康状态。低级监控通常涉及确保 Ceph OSD 正确对等。当发生对等错误时，放置组将处于降级状态。这种降级状态可能是许多不同的事情，如硬件故障、挂起或崩溃的 Ceph 守护进程、网络延迟或完整的站点中断。

3.3.1. 先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。

3.3.2. 监控放置组设置

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

  • 添加或删除 OSD。然后，CRUSH 将 PG 重新分配给其他 OSD，从而更改操作集合的组成，并使用"回填"过程生成数据的迁移。
  • OSD 已停机，已经重启，现在正在 恢复。
  • Acting Set 中的 OSD 为 down 或 unable to service requests，另一个 OSD 暂时假定其职责。

Ceph 使用 Up Set 处理客户端请求，这是实际处理请求的 OSD 集合。在大多数情况下，Up Set 和 Acting Set 几乎是相同的。当它们不是时，这可能表示 Ceph 正在迁移数据，或者 OSD 正在恢复，或者存在问题，Ceph 通常会在这样的场景中以"stuck stale"消息来回显 HEALTH WARN 状态。

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 检索放置组列表： 

    [root@mon ~]# ceph pg dump

  2. 查看在 Acting Set 或一个给定放置组的 Up Set 中哪些 OSD： 

    [root@mon ~]# ceph pg map PG_NUM

    结果应该告诉您 osdmap epoch、eNNN、放置组号、PG_NUM、在 Up Set up[] 中的 OSD，以及操作集合 acting[] 中的 OSD： 

    [root@mon ~]# ceph osdmap eNNN pg PG_NUM-> up [0,1,2] acting [0,1,2]
    注意

    如果 Up Set 和 Acting Set 没有匹配，这可能代表集群重新平衡本身或集群中的潜在问题。

3.3.3. Ceph OSD 对等

在将数据写入放置组之前，它必须处于 active 状态，且应该处于 clean 状态。若要让 Ceph 确定放置组的当前状态，PG 的 Primary OSD（活跃集中的第一个 OSD）与二级和三级 OSD 为对等，以变为放置组的当前状态建立协议。假设 PG 具有 3 个副本的池。

对等（peering）

3.3.4. 放置组状态

如果执行诸如 ceph health, ceph -s 或 ceph -w 等命令，您可能会注意到集群并不总是回显 HEALTH OK。检查 OSD 是否在运行后，您也应检查放置组状态。您应该可以预计，在与放置组对等相关的一些情况下，集群不会反映 HEALTH OK ：

  • 您刚刚创建了一个池，放置组还没有对等。
  • 放置组正在恢复。
  • 您刚刚向集群添加一个 OSD 或从集群中移除一个 OSD。
  • 您刚修改了 CRUSH map，并且已迁移了放置组。
  • 在放置组的不同副本中，数据不一致。
  • Ceph 清理放置组的副本。
  • Ceph 没有足够存储容量来完成回填操作。

如果一个预期的情况导致 Ceph 反映了 HEALTH WARN，请不要紧张。在很多情况下，集群将自行恢复。在某些情况下，您可能需要采取措施。监控放置组的一个重要方面是确保在集群启动并运行所有放置组处于 active 状态，并且最好处于 clean 状态。

要查看所有放置组的状态，请执行： 

[root@mon ~]# 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 通常会报告放置组的多个状态。

Snapshot Trimming PG States

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

  • snaptrim ：PG 目前被修剪
  • snaptrim_wait ：PG 等待被修剪

输出示例： 

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

除了放置组状态外，Ceph 还会回显所使用的数据量，aa(剩余存储容量)，bb（放置组的总存储容量）。在一些情况下，这些数字非常重要：

  • 您达到了几乎全满比率或全满比率。
  • 由于 CRUSH 配置中的一个错误，您的数据不会分散到集群中。

放置组 ID

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

POOL_NUM.PG_ID

输出示例： 

0.1f

  • 检索放置组列表： 

    [root@mon ~]# ceph pg dump

  • 以 JSON 格式格式化输出并将其保存到文件中： 

    [root@mon ~]# ceph pg dump -o FILE_NAME --format=json

  • 查询特定的放置组： 

    [root@mon ~]# 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"
    }
  ]
}

其它资源

  • 有关快照修剪设置的详情，请参阅 Red Hat Ceph Storage 4 配置指南中的 章节 Object Storage Daemon (OSD)配置选项。

3.3.5. 放置组创建状态

在创建池时，将创建您指定的 PG 数量。Ceph 将在创建一个或多个放置组时回显 creating。创建之后，作为 PG Acting 设置一部分的 OSD 将会被对等点。对等点完成后，PG 状态应当为 active+clean，即 Ceph 客户端可以开始写入到 PG。

创建 PG

3.3.6. 放置组对等状态

当 Ceph 对等一个放置组时，Ceph 会将存储放置组副本的 OSD 变为与放置组中的对象和元数据的同意状态。当 Ceph 完成对等时，这意味着存储放置组的 OSD 同意该放置组的当前状态。但是，完成 peering 的进程并不表示每个副本都有最新的内容。

权威历史

Ceph 将不会确认对客户端的写操作，直到该工作集合的所有 OSD 都会保留这个写入操作。这种做法可确保，自上一次成功的对等操作，至少有一个成员具有每个确认的写操作的记录。

通过使用对每个已确认的写入操作的准确记录，Ceph 可以构建并分离 PG 的新权威历史记录。执行后，一组完全排序的操作（如果执行）会将使 OSD 的副本保持最新状态。

3.3.7. 放置组激活状态

Ceph 完成对等进程后，PG 可能会变为 active 状态。Active 状态表示放置组中的数据通常在主放置组中可用，而副本用于读取和写入操作。

3.3.8. 放置组清理状态

当放置组处于 clean 状态时，主 OSD 和副本 OSD 已成功对等，并且放置组没有预先复制。Ceph 复制 PG 中正确次数的所有对象。

3.3.9. 放置组降级状态

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

PG 可以是 active+degraded 的原因是，OSD 可以处于 active 状态，尽管它还没有保存所有对象。如果 OSD 停机，Ceph 会将分配到 OSD 的每个 PG 标记为 degraded。当 OSD 重新上线时，OSD 必须再次对等。但是，如果客户端处于 active 状态，客户端仍然可以将新对象写入到一个降级的（degraded） PG。

如果 OSD 为 down 并且一直处于 degraded 状况，Ceph 可能会将 down OSD 标记为集群 out，并将 down OSD 的数据重新映射到另一个 OSD。在标记为 down 和标记为 out 之间的时间由 mon_osd_down_out_interval 控制。它被默认设置为 600 秒。

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

假设有 9 个 OSD，即副本池。如果 OSD 数量 9 停机，分配给 OSD 9 的 PG 会处于降级状态。如果 OSD 9 没有被恢复，它会退出集群，集群会重新平衡。在这种情况下，PG 被降级，然后恢复到 active 状态。

3.3.10. 放置组恢复状态

Ceph 设计为容错性，可以大规模地出现硬件和软件问题持续发展的问题。当 OSD 为 down 时，其内容可能落后于 PG 中其他副本的当前状态。当 OSD 变为 up，必须更新放置组的内容，以反映当前状态。在该时间段内，OSD 可能会处于 recovering 状态。

恢复并非始终正常，因为硬件故障可能会导致多个 OSD 的级联故障。例如，一个 rack 或 cabinet 的网络交换机可能会失败，这可能会导致大量主机机器的 OSD 不在集群的当前状态后。在错误解决后，每个 OSD 必须恢复。

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

3.3.11. Back fill 状态

当新的 OSD 加入集群时，CRUSH 会将集群中的 OSD 重新分配给新添加的 OSD。强制新 OSD 接受重新分配的 PG，可立即对新 OSD 进行过度负载。使用放置组回填 OSD 使此过程在后台开始。回填完成后，新 OSD 会在请求就绪时开始提供请求。

在回填操作中，您可能会看到状态中的一个：* backfill_wait 表示回填操作处于待处理状态，但没有发生 * backfill 表示回填操作处于路上去 * backfill_too_full 表示请求回填操作，但可能会因为存储容量不足而无法完成。

当 PG 无法回填时，它可能被视为 不完整。

Ceph 提供了一些设置，用于管理与 PG 相关的负载高峰，特别是新 OSD。默认情况下，osd_max_backfills 将最大并发回填数量（来自或到一个 OSD）设置为 10。如果 OSD 接近全满比率，则 osd 回填比率 可让 OSD 拒绝回填请求，默认为 85%。如果 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_en 则设为 2。当这个情况与您的工作负载相符，请联系您的红帽支持团队。

3.3.12. 更改恢复或回填操作的优先级

当某些放置组(PG)需要恢复和/或回填时，您可能会遇到一个情况，其中一些放置组包含比其他目的更重要的数据。使用 pg-recovery 或 pg-backfill 命令，确保具有较高优先级数据的 PG 先恢复或回填。

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 发出 pg-recovery 或 pg force-backfill 命令，并使用较高优先级数据为 PG 指定优先级顺序：

    语法

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

    Example

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

    此命令会导致 Red Hat Ceph Storage 在处理其他放置组(PG)之前首先对指定的放置组(PG)执行恢复或回填。发出 命令不会中断当前执行的回填或恢复操作。在当前运行的操作完成后，可以指定的 PG 尽快进行恢复或回填。

3.3.13. 在指定的放置组上更改或取消恢复或回填操作

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

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 在指定的放置组上更改或取消恢复或回填操作：

    语法

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

    Example

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

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

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

其它资源

3.3.14. 对池强制进行高优先级恢复或回填操作

如果池中的所有放置组都需要高优先级恢复或回填，请使用 force-recovery 或 force-backfill 选项来发起操作。

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 在指定池中所有 PG 上强制进行高优先级恢复或回填：

    语法

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

    Example

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

    注意

    请谨慎使用 force-recovery 和 force-backfill 命令。更改这些操作的优先级可能会破坏 Ceph 内部优先级计算的顺序。

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

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

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 在指定池中所有 PG 上取消高优先级恢复或回填操作：

    语法

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

    Example

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

3.3.16. 为池重新排序恢复或回填操作的优先级

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

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 重新排列池的恢复/回填优先级：

    语法

    ceph osd pool set POOL_NAME recovery_priority VALUE

    Example

    ceph osd pool set pool1 recovery_priority 10

    VALUE 设置优先级顺序。例如，如果您有 10 个池，优先级值为 10 的池首先会处理，然后处理优先级为 9 的池，以此类推。如果只有某些池具有高优先级，您可以仅为这些池设置优先级值。没有设置优先级的池按默认顺序处理。

3.3.17. RADOS 中的放置组恢复的优先级

本节介绍了 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.3.18. PG 重新映射状态

当决定服务设置放置组更改时，数据会从旧操作集迁移到新行为集。这可能需要经过一定时间后，新的 Primary OSD 才会处理服务请求。因此，可能需要旧的主系统继续服务请求，直到放置组迁移完成为止。数据迁移完成后，映射将使用新操作集合的 Primary OSD。

3.3.19. 放置组已过时状态

虽然 Ceph 使用心跳来确保主机和守护进程正在运行，ceph-osd 守护进程也会在没有及时报告统计数据的情况下变为 stuck 状态。例如，临时网络故障。默认情况下，OSD 守护进程每半秒钟报告其放置组、启动和失败统计，即 0.5，它比心跳阈值更频繁。如果放置组所采取集合的 Primary OSD 报告监控器失败，或者其他 OSD 报告了 Primary OSD down，则监视器会将 PG 标记为 stale。

当您启动存储集群时，通常会看到 stale 状态，直到对等进程完成为止。在存储集群运行一段时间后，如果放置组处于 stale 状态则代表这些放置组的主 OSD 的状态为 down 或者没有向监控器报告放置组统计信息。

3.3.20. 放置组错误替换状态

当 PG 临时映射到一个 OSD 时会有一些临时回填情况。当这个临时状态已不存在时，PG 可能仍然位于临时位置，而没有位于正确的位置。在这种情况下，它们被认为是 misplaced。这是因为实际上存在正确的额外副本数量，但一个或多个副本位于错误的地方。

例如，有 3 个 OSD：0、1,2 和所有 PG 映射到这三个。如果您添加了另一个 OSD(OSD 3)，一些 PG 现在将映射到 OSD 3，而不是另一个 OSD 3。但是，在 OSD 3 回填之前，PG 有一个临时映射，允许它继续从旧映射提供 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.3.21. 放置组不完整状态

当内容不完整且对等失败（没有足够完整的 OSD 来执行恢复），PG 就会变为 incomplete 状态。

假设 OSD 1、2 和 3 是活跃的 OSD 集，它切换到 OSD 1、4 和 3，然后 osd.1 将请求一个临时活跃集包括 OSD 1、2 和 3，同时对 OSD 4 进行回填。在此期间，如果 OSD 1、2 和 3 都停机，则 osd.4 将是唯一没有完全回填所有数据的 OSD。此时，PG 会变为 incomplete，表明没有足够完整的 OSD 来执行恢复。

另外，如果没有涉及 osd.4，并且在 OSD 1、2 和 3 停机时，如果 osd.4 没有被涉及到，并且当 OSD 1、2 和 3 停机时，PG 就有可能变为 stale，这代表 mons 没有在这个 PG 上听到任何信息，因为执行集发生了变化。没有 OSD 以通知新的 OSD 的原因。

3.3.22. 找出卡住的 PG

如前所述，放置组不一定存在问题，因为它的状态不是 活动+clean。通常，当放置组卡时，Ceph 自助修复的能力可能无法工作。卡住状态包括：

  • Unclean: 放置组包含不会复制所需次数的对象。它们应该正在进行恢复。
  • Inactive ：放置组无法处理读取或写入，因为它们正在等待具有最新数据的 OSD 返回到 up 状态。
  • Stale：放置组处于未知状态，因为托管它们的 OSD 在一段时间内未报告到监控集群，并可使用 mon osd report timeout 配置。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 要识别卡的放置组，请执行以下操作： 

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

3.3.23. 查找对象的位置

Ceph 客户端检索最新的集群映射，并且 CRUSH 算法计算如何将对象映射到放置组，然后计算如何动态将 PG 分配给 OSD。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 要查找对象位置，您需要对象名称和池名称： 

    ceph osd map POOL_NAME OBJECT_NAME

第 4 章 覆盖 Ceph 行为

作为存储管理员，您需要了解如何对 Red Hat Ceph Storage 集群使用覆盖，以便在运行时更改 Ceph 选项。

4.1. 先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。

4.2. 设置和取消设置 Ceph 覆盖选项

您可以设置和取消设置 Ceph 选项来覆盖 Ceph 的默认行为。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

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

    ceph osd set FLAG

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

  2. 要覆盖 Ceph 的默认行为，请使用 ceph osd unset 命令以及您想要的覆盖。 

    ceph osd unset FLAG
标记描述

noin

防止 OSD 被视为在集群 in。

noout

防止 OSD 被视在集群外。

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 将禁用正在查找 cold/dirty 对象以清空和驱除的进程。

4.3. Ceph 覆盖用例

  • 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 在对问题进行故障排除时处于标记状态。

  • 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 用户管理

作为存储管理员，您可以通过为 Red Hat Ceph Storage 集群中的对象提供身份验证、密钥环管理和访问控制来管理 Ceph 用户基础。

OSD 状态

5.1. 先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 访问 Ceph monitor 或 Ceph 客户端节点。

5.2. Ceph 用户管理背景

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

# ceph health

Ceph 会解释如下命令： 

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

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

无论 Ceph 客户端的类型（例如块设备、对象存储、文件系统、原生 API 或 Ceph 命令行），Ceph 都会将所有数据在池中作为对象保存。Ceph 用户必须有权访问池才能读取和写入数据。此外，管理 Ceph 用户必须具有执行 Ceph 管理命令的权限。

以下概念可帮助您理解 Ceph 用户管理。

存储集群用户

Red Hat Ceph Storage 集群的用户是个人或一个应用程序。通过创建用户，您可以控制谁可以访问存储集群、池以及这些池中的数据。

Ceph 具有用户类型的概念。对于用户管理而言，类型将始终是 客户端。Ceph 使用带有句点(.)作为分隔符的名称来标识用户，它由用户类型和用户 ID 组成。例如，TYPE.ID、client.admin 或 client.user1。用户需要键入的原因是 Ceph 监控器和 OSD 也使用 Cephx 协议，但它们并不是客户端。区分用户类型有助于区分客户端用户和其他用户精简访问控制、用户监控和可追溯性。

有时，Ceph 的用户类型似乎比较混乱，因为 Ceph 命令行允许您根据命令行使用而指定具有或没有类型的用户。如果指定了 --user 或 --id，可以省略该类型。因此，输入 user1 可以代表 client.user1。如果指定 --name 或 -n，您必须指定类型和名称，如 client.user1。作为最佳做法，红帽建议尽可能使用类型和名称。

注意

Red Hat Ceph Storage 集群用户与 Ceph Object Gateway 用户不同。对象网关使用 Red Hat Ceph Storage 集群用户在网关守护进程和存储集群间进行通信，但网关具有自己的用户管理功能。

授权功能

Ceph 使用术语"capabilities（功能）"（大写）描述授权经过身份验证的用户来练习 Ceph 监控器和 OSD 的功能。功能也可以限制对池或池中命名空间中的数据的访问。Ceph 管理用户在创建或更新用户时设置用户的功能。功能语法遵循以下形式：

语法

DAEMON_TYPE 'allow CAPABILITY' [DAEMON_TYPE 'allow CAPABILITY']

  • monitor Caps: Monitor 功能包括 r, w, x, allow profile CAP, 和 profile rbd。

    示例

    mon 'allow rwx`
mon 'allow profile osd'

  • OSD Caps: 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 命令的能力。

配置集 osd

授予用户权限以 OSD 连接到其他 OSD 或 monitor。在 OSD 上延迟，使 OSD 能够处理复制心跳流量和状态报告。

配置集 bootstrap-osd

授予用户引导 OSD 的权限，以便在引导 OSD 时具有添加密钥的权限。

profile rbd

授予用户对 Ceph 块设备的读写访问权限。

profile rbd-read-only

授予用户对 Ceph 块设备的只读访问权限。

pool

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

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

命名空间

池中的对象可以关联到池中命名空间的逻辑对象组。用户对池的访问可以关联到命名空间，以便用户读取和写入仅在命名空间内进行。写入到池中的一个命名空间的对象只能由有权访问该命名空间的用户访问。

注意

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

命名空间的比率是池可以根据用例来计算聚合数据的计算方法，因为每个池创建了一组映射到 OSD 的放置组。如果多个池使用相同的 CRUSH 层次结构和规则集，OSD 性能可能会随着负载增加而降级。

例如，一个池对于每个 OSD 应有大约 100 个 PG。因此，有 1000 个 OSD 的集群对于一个池有 100,000 个 PG。映射到同一 CRUSH 层次结构的每个池将在 exemplary 集群中创建另一个 100,000 个放置组。相反，将对象写入命名空间只是将命名空间与对象名称关联的对象名称与单独池的计算开销相关联。您可以使用命名空间，而不是为用户或一组用户创建单独的池。

注意

目前仅在使用 librados 时才可用。

其它资源

5.3. 管理 Ceph 用户

作为存储管理员，您可以通过创建、修改、删除和导入用户来管理 Ceph 用户。Ceph 客户端用户可以是个人或应用程序，它们使用 Ceph 客户端与红帽 Ceph Storage 集群守护进程交互。

5.3.1. 先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 访问 Ceph monitor 或 Ceph 客户端节点。

5.3.2. 列出 Ceph 用户

您可以使用命令行界面列出存储集群中的用户。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

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

    [root@mon ~]# ceph auth list

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

    Example

    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: 条目。

您可以将 -o FILE_NAME 选项与 ceph auth list 一起使用，以将输出保存到文件中。

5.3.3. 显示 Ceph 用户信息

您可以使用命令行界面显示 Ceph 的用户信息。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

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

    ceph auth export TYPE.ID

    Example

    [root@mon ~]# ceph auth get client.admin

  2. 您还可以将 -o FILE_NAME选项与 ceph auth get 搭配使用，以将输出保存到文件中。开发人员也可以执行以下操作： 

    ceph auth export TYPE.ID

    Example

    [root@mon ~]# ceph auth export client.admin

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

5.3.4. 添加新的 Ceph 用户

添加用户的用户名，即 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 选项将输出保存到文件中。

在创建客户端用户时，您可以创建没有功能的用户。对于一个没有带有任何能力的用户，除进行身份验证之外没有任何用处，因为客户端无法从监控器检索 cluster map。但是，如果您想要以后使用 ceph auth caps 命令添加新的能力，则可以先创建一个没有权限的用户。

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

[root@mon ~]# ceph auth add client.john mon 'allow r' osd 'allow rw pool=liverpool'
[root@mon ~]# ceph auth get-or-create client.paul mon 'allow r' osd 'allow rw pool=liverpool'
[root@mon ~]# ceph auth get-or-create client.george mon 'allow r' osd 'allow rw pool=liverpool' -o george.keyring
[root@mon ~]# ceph auth get-or-create-key client.ringo mon 'allow r' osd 'allow rw pool=liverpool' -o ringo.key
重要

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

5.3.5. 修改 Ceph 用户

ceph auth caps 命令允许您指定用户并更改用户的能力。设置新功能将覆盖当前功能。因此，首先查看当前功能，并在您添加新功能时包括它们。

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 查看当前功能： 

    ceph auth get USERTYPE.USERID

    Example

    [root@mon ~]# ceph auth get client.john
exported keyring for client.john
[client.john]
	key = AQAHjy1gkxhIMBAAxsaoFNuxlUhr/zKsmnAZOA==
	caps mon = "allow r"
	caps osd = "allow rw pool=liverpool"

  2. 要添加能力，请使用表单： 

    ceph auth caps USERTYPE.USERID DAEMON 'allow [r|w|x|*|...] [pool=POOL_NAME] [namespace=NAMESPACE_NAME]'

    Example

    [root@mon ~]# ceph auth caps client.john mon 'allow r' osd 'allow rwx pool=liverpool'

    在示例中，添加对 OSD 执行功能。

  3. 验证添加的功能： 

    ceph auth get _USERTYPE_._USERID_

    Example

    [root@mon ~]# ceph auth get client.john
exported keyring for client.john
[client.john]
	key = AQAHjy1gkxhIMBAAxsaoFNuxlUhr/zKsmnAZOA==
	caps mon = "allow r"
	caps osd = "allow rwx pool=liverpool"

    在示例中，可以看到对 OSD 执行功能。

  4. 要删除功能，请设置您要删除的所有功能。 

    ceph auth caps USERTYPE.USERID DAEMON 'allow [r|w|x|*|...] [pool=POOL_NAME] [namespace=NAMESPACE_NAME]'

    Example

    [root@mon ~]# ceph auth caps client.john mon 'allow r' osd 'allow rw pool=liverpool'

    在示例中，不包含在 OSD 上执行功能，因此会被删除。

  5. 验证删除的功能： 

    ceph auth get _USERTYPE_._USERID_

    Example

    [root@mon ~]# ceph auth get client.john
exported keyring for client.john
[client.john]
	key = AQAHjy1gkxhIMBAAxsaoFNuxlUhr/zKsmnAZOA==
	caps mon = "allow r"
	caps osd = "allow rw pool=liverpool"

    在示例中，不再列出对 OSD 执行功能。

其它资源

5.3.6. 删除 Ceph 用户

您可以使用命令行界面从 Ceph 存储集群中删除用户。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 要删除用户，请使用 ceph auth del: 

    [root@mon ~]# ceph auth del TYPE.ID

    其中 TYPE 是客户端、osd、mon 或 mds 之一，而 ID 是守护进程的用户名或 ID。

5.3.8. 导入 Ceph 用户

您可以使用命令行界面导入 Ceph 用户。

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

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

    ceph auth import -i /PATH/TO/KEYRING

    Example

    [root@mon ~]# ceph auth import -i /etc/ceph/ceph.keyring

注意

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

5.4. 管理 Ceph 密钥环

作为存储管理员，管理 Ceph 用户密钥对于访问 Red Hat Ceph Storage 集群非常重要。您可以创建密钥环，将用户添加到密钥环中，然后使用密钥环修改用户。

5.4.1. 前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 访问 Ceph monitor 或 Ceph 客户端节点。

5.4.2. 创建密钥环

您需要向 Ceph 客户端提供用户密钥，以便 Ceph 客户端能够检索指定用户的密钥并使用 Ceph Storage 集群进行身份验证。用于查找用户名并检索用户密钥的 Ceph 客户端访问密钥环。

ceph-authtool 工具允许您创建密钥环。

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 要创建空密钥环，请使用 --create-keyring 或 -C。

    Example

    [root@mon ~]# ceph-authtool --create-keyring /path/to/keyring

    当使用多个用户创建密钥环时，我们建议使用集群名称。例如，针对密钥环文件名的 CLUSTER_NAME.keyring' 并将其保存在 /etc/ceph/ 目录中，以便 密钥环 配置默认设置会获取文件名，而无需在 Ceph 配置文件的本地副本中指定该文件。

  2. 通过执行以下操作来创建 ceph.keyring ： 

    [root@mon ~]# ceph-authtool -C /etc/ceph/ceph.keyring

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

要在 /etc/ceph/ 中创建密钥环，您必须以 root 用户身份执行此操作。这意味着，该文件仅针对 root 用户具有 rw 权限，这在密钥环包含管理员密钥时合适。但是，如果您打算将密钥环用于特定用户或一组用户，请确保执行 chown 或 chmod 来建立适当的密钥环所有权和访问权限。

5.4.3. 将用户添加到密钥环

当您将用户添加到 Ceph 存储集群时，您可以使用 get 过程来检索用户、密钥和功能，然后将用户保存到密钥环文件中。当您只想为每个密钥环使用一个用户时，使用 -o 选项的 Display Ceph 用户信息 过程会将输出保存为密钥环文件格式。

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 要为 client.admin 用户创建密钥环，请执行以下操作： 

    [root@mon ~]# ceph auth get client.admin -o /etc/ceph/ceph.client.admin.keyring

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

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

    [root@mon ~]# ceph-authtool /etc/ceph/ceph.keyring --import-keyring /etc/ceph/ceph.client.admin.keyring

5.4.4. 创建具有密钥环的 Ceph 用户

Ceph 提供了在 Red Hat Ceph Storage 集群中直接创建用户的功能。但是，您还可以直接在 Ceph 客户端密钥环中创建用户、密钥和功能。

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 将用户导入到密钥环中：

    Example

    [root@mon ~]# ceph-authtool -n client.ringo --cap osd 'allow rwx' --cap mon 'allow rwx' /etc/ceph/ceph.keyring

  2. 创建密钥环并同时向密钥环中添加新用户：

    例如：

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

    在忘记情景中，新用户 client.ringo 只是在密钥环中。

  3. 将新用户添加到 Ceph 存储集群中： 

    [root@mon ~]# ceph auth add client.ringo -i /etc/ceph/ceph.keyring

其它资源

5.4.5. 使用密钥环修改 Ceph 用户

您可以使用命令行界面修改 Ceph 用户及其密钥环。

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 要修改密钥环中用户记录的功能，请指定密钥环，然后用户以及相应的功能，例如： 
[root@mon ~]# ceph-authtool /etc/ceph/ceph.keyring -n client.ringo --cap osd 'allow rwx' --cap mon 'allow rwx'
  1. 要将用户更新至 Red Hat Ceph Storage 集群，您必须将密钥环中的用户更新至 Red Hat Ceph Storage 集群中的用户条目： 
[root@mon ~]# ceph auth import -i /etc/ceph/ceph.keyring

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

其它资源

5.4.6. Ceph 用户的命令行用法

Ceph 支持以下使用用户名和 secret：

--id | --user

描述
Ceph 识别具有类型和 ID 的用户。例如，TYPE.ID 或 client.admin，client.user1。id、name 和 -n 选项允许您指定用户名的 ID 部分。例如，管理员、user1 或 foo。您可以使用 --id 指定用户，省略 类型。例如，要指定用户 client.foo，请输入以下内容： 
[root@mon ~]# ceph --id foo --keyring /path/to/keyring health
[root@mon ~]# ceph --user foo --keyring /path/to/keyring health

--name | -n

描述
Ceph 识别具有类型和 ID 的用户。例如，TYPE.ID 或 client.admin，client.user1。name 和 -n 选项允许您指定完全限定的用户名。您必须使用用户 ID 指定用户类型（通常是 客户端）。例如： 
[root@mon ~]# ceph --name client.foo --keyring /path/to/keyring health
[root@mon ~]# ceph -n client.foo --keyring /path/to/keyring health

--keyring

描述
包含一个或多个用户名和 secret 的密钥环路径。--secret 选项提供相同的功能，但它无法用于 Ceph RADOS 网关，网关使用 --secret 来另一用途。您可以使用 ceph auth get-or-create 检索密钥环，并将其存储在本地。这是首选的方法，因为您可以在不切换密钥环路径的情况下切换用户名。例如： 
[root@mon ~]# rbd map foo --pool rbd myimage --id client.foo --keyring /path/to/keyring

5.4.7. Ceph 用户管理限制

cephx 协议相互验证 Ceph 客户端和服务器。它并不适用于处理代表其运行的人用户或应用程序程序的身份验证。如果需要该效果来处理访问控制需求，则您必须有另一种机制，该机制可能特定于用于访问 Ceph 对象存储的前端。这种其他机制具有确保 Ceph 允许访问其对象存储的计算机上只有可接受的用户和程序能够运行的角色。

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

重要

在纯文本文件中存储密钥具有安全性不足，但难以避免，因为 Ceph 在后台使用的基本身份验证方法。设置 Ceph 系统应该了解这些不足的问题。

特别是任意用户计算机（特别是便携式计算机）应配置为直接与 Ceph 交互，因为这种模式需要在不安全的计算机上存储纯文本验证密钥。对机器造成破坏或获取访问权限的任何人都可以获取允许他们向 Ceph 验证自己机器的密钥。

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

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

例如，Ceph 对象网关提供 S3 API Serverside Encryption，它在将 Ceph Object Gateway 客户端中存储并类似地解密从 Ceph Storage 集群发送之前从 Ceph Storage 集群接收的数据加密。为确保在客户端和 Ceph 对象网关之间传输加密，Ceph 对象网关应配置为使用 SSL。

第 6 章 ceph-volume 工具

作为存储管理员，您可以使用 ceph-volume 实用程序准备、创建和激活 Ceph OSD。ceph-volume 实用程序是单一目的命令行工具，可将逻辑卷部署为 OSD。它使用插件类型框架来部署使用不同设备技术的 OSD。ceph-volume 实用程序遵循 ceph-disk 实用程序的类似工作流，用于部署 OSD，具有可预测的、可靠的准备、激活和启动 OSD 的方法。目前，ceph-volume 实用程序只支持 lvm 插件，计划以后支持其他技术。

重要

ceph-disk 命令已弃用。

6.1. 先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。

6.2. Ceph 卷 lvm 插件

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

使用 ceph-volume 时，dm-cache 的使用是透明的，并像逻辑卷一样对待 dm-cache。使用 dm-cache 时性能提升和丢失将取决于特定工作负载。通常，随机的读取和顺序的读取将以较小的块大小来提高性能。对于大的块大小，随机和顺序写入的性能会降低。

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

[root@osd ~]# ceph-volume lvm

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

注意

create 子命令将 prepare 和 activate 子命令合并到一个子命令中。

其它资源

  • 如需了解更多详细信息，请参阅 create 子命令 部分。

6.3. 为什么 ceph-volume 替换 ceph-disk？

以前的 Red Hat Ceph Storage 版本使用 ceph-disk 实用程序来准备、激活和创建 OSD。从 Red Hat Ceph Storage 4 开始，ceph-disk 被 ceph-volume 实用程序替代，该实用程序旨在作为 OSD 部署逻辑卷，同时在准备、激活和创建 OSD 时维护类似的 API 到 ceph-disk。

ceph-volume 的工作原理？

ceph-volume 是一个模块化工具，目前支持置备硬件设备、传统的 ceph-disk 设备和 LVM（逻辑卷管理器）设备的方法。ceph-volume lvm 命令使用 LVM 标签存储特定于 Ceph 的设备及其与 OSD 的关系信息。它使用这些标签来稍后重新发现和查询与 OSDs 关联的设备，以便它可以激活它们。它还支持基于 LVM 和 dm-cache 的技术。

ceph-volume 实用程序以透明方式使用 dm-cache，并将其视为逻辑卷。根据您要处理的特定工作负载，您可能会考虑使用 dm-cache 时的性能提升和丢失。通常，随机和顺序读取操作的性能会提高较小的块大小；而随机和顺序写入操作的性能则降低更大的块大小。使用 ceph-volume 不会导致任何明显的性能下降。

重要

ceph-disk 实用程序已弃用。

注意

如果这些设备仍在使用，ceph-volume simple 命令可处理旧的 ceph-disk 设备。

ceph-disk 的工作原理？

需要 ceph-disk 工具来支持许多不同类型的 init 系统，如 upstart 或 sysvinit，同时能够发现设备。因此，ceph-disk 只会专注于 GUID 分区表 (GPT) 分区。具体在 GPT GUID 中，以独特的方式标记设备，以如下方式回答问题：

  • 此设备是否为 journal？
  • 该设备是否是加密的数据分区？
  • 设备是否部分准备了吗？

为解决这些问题，ceph-disk 使用 UDEV 规则与 GUID 匹配。

使用 ceph-disk 有什么缺点？

使用 UDEV 规则调用 ceph-disk 可能会导致在 ceph-disk systemd 单元和 ceph-disk 间的相互往来。整个过程非常不可靠且消耗时间，可能会导致 OSD 在节点启动过程中根本不会出现。此外，由于 UDEV 的异步行为，很难调试甚至复制这些问题。

由于 ceph-disk 只能用于 GPT 分区，所以它不支持其他技术，如逻辑卷管理器(LVM)卷或类似的设备映射器设备。

为确保 GPT 分区能与设备发现工作流正常工作，ceph-disk 需要大量特殊的标志。此外，这些分区需要设备完全归 Ceph 所有。

6.4. 使用 ceph-volume准备 Ceph OSD

prepare 子命令准备 OSD 后端对象存储，并消耗 OSD 数据和日志的逻辑卷(LV)。它不会修改逻辑卷，但使用 LVM 添加额外的元数据标签。这些标签使卷更容易发现，它们也会将卷识别为 Ceph Storage 集群的一部分，以及存储集群中这些卷的角色。

BlueStore OSD 后端支持以下配置：

  • 块设备，block.wal 设备和 block.db 设备
  • 块设备和一个 block.wal 设备
  • 块设备和 block.db 设备
  • 单个块设备

prepare 子命令接受整个设备或分区，或者用于 块 的逻辑卷。

先决条件

  • 对 OSD 节点的 root 级别访问。
  • （可选）创建逻辑卷。如果您提供到物理设备的路径，子命令会将设备转换为逻辑卷。这种方法更为简单，但是您无法配置或更改创建逻辑卷的方式。

流程

  1. 准备 LVM 卷：

    语法

    ceph-volume lvm prepare --bluestore --data VOLUME_GROUP/LOGICAL_VOLUME

    示例

    [root@osd ~]# ceph-volume lvm prepare --bluestore --data example_vg/data_lv

    1. 另外，如果您要将单独的设备用于 RocksDB，请指定 --block.db 和 --block.wal 选项：

      语法

      ceph-volume lvm prepare --bluestore --block.db --block.wal --data VOLUME_GROUP/LOGICAL_VOLUME

      示例

      [root@osd ~]# ceph-volume lvm prepare --bluestore --block.db --block.wal --data example_vg/data_lv

    2. 另外，要加密数据，请使用 --dmcrypt 标志：

      语法

      ceph-volume lvm prepare --bluestore --dmcrypt --data VOLUME_GROUP/LOGICAL_VOLUME

      示例

      [root@osd ~]# ceph-volume lvm prepare --bluestore --dmcrypt --data example_vg/data_lv

其它资源

6.5. 使用 ceph-volume 激活 Ceph OSD

激活过程在引导时启用 systemd 单元，允许启用和挂载正确的 OSD 标识符及其 UUID。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 对 Ceph OSD 节点的 root 级别访问权限。
  • Ceph OSD 由 ceph-volume 实用程序准备。

流程

  1. 从 OSD 节点获取 OSD ID 和 UUID： 

    [root@osd ~]# ceph-volume lvm list

  2. 激活 OSD：

    语法

    ceph-volume lvm activate --bluestore OSD_ID OSD_UUID

    示例

    [root@osd ~]# ceph-volume lvm activate --bluestore 0 0263644D-0BF1-4D6D-BC34-28BD98AE3BC8

    要激活为激活准备的所有 OSD，请使用 --all 选项：

    Example

    [root@osd ~]# ceph-volume lvm activate --all

其它资源

6.6. 使用 ceph-volume 创建 Ceph OSD

create 子命令调用 prepare 子命令，然后调用 activate 子命令。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 对 Ceph OSD 节点的 root 级别访问权限。
注意

如果您希望对创建过程拥有更多控制，可以单独使用 prepare 和 activate 子命令来创建 OSD，而不必使用 create。您可以使用两个子命令逐步将新的 OSD 引入到存储集群中，同时避免重新平衡大量数据。这两种方法的工作方式相同，唯一的不同是使用 create 子命令会使 OSD 在完成后立即变为 up 和 in。

流程

  1. 要创建新 OSD，请执行以下操作：

    语法

    ceph-volume lvm create --bluestore --data VOLUME_GROUP/LOGICAL_VOLUME

    示例

    [root@osd ~]# ceph-volume lvm create --bluestore --data example_vg/data_lv

其它资源

6.7. 将批处理模式与 ceph-volume搭配使用

当提供单一设备时，batch 子命令可自动创建多个 OSD。

ceph-volume 命令根据驱动器类型决定使用创建 OSD 的最佳方法。Ceph OSD 优化取决于可用的设备：

  • 如果所有设备都是传统的硬盘驱动器，batch 会为每个设备创建一个 OSD。
  • 如果所有设备都是固态硬盘，则 batch 会为每个设备创建两个 OSD。
  • 如果混合使用传统硬盘驱动器和固态驱动器，batch 使用传统的硬盘驱动器用于数据，并在固态硬盘上创建最大可能的日志(block.db)。
注意

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

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 对 Ceph OSD 节点的 root 级别访问权限。

流程

  1. 在几个驱动器中创建 OSD：

    语法

    ceph-volume lvm batch --bluestore PATH_TO_DEVICE [PATH_TO_DEVICE]

    示例

    [root@osd ~]# ceph-volume lvm batch --bluestore /dev/sda /dev/sdb /dev/nvme0n1

其它资源

第 7 章 Ceph 性能基准

作为存储管理员，您可以对 Red Hat Ceph Storage 集群的基准测试性能进行基准测试。本节的目的是让 Ceph 管理员能够了解 Ceph 的原生基准工具。这些工具将深入探讨 Ceph 存储集群的运行情况。这不是 Ceph 性能基准的确定指南，也不是一个有关如何相应地调整 Ceph 的指南。

7.1. 先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。

7.2. 性能基准

OSD（包括日志、磁盘和网络吞吐量）应具有一个用于比较的性能基准。您可以通过将基准性能数据与 Ceph 原生工具中的数据进行比较来识别潜在的调优机会。Red Hat Enterprise Linux 具有许多内置工具，以及开源社区工具的 plethora，可用于帮助完成这些任务。

其它资源

7.3. Ceph 性能基准

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

注意

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

[root@mon~ ]# echo 3 | sudo tee /proc/sys/vm/drop_caches && sudo sync

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 创建新存储池： 

    [root@osd~ ]# ceph osd pool create testbench 100 100

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

    [root@osd~ ]# 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

  3. 为存储池执行一次10 秒的连续读测试 ： 

    [root@osd~ ]## 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

  4. 为存储池执行一次 10 秒的随机读取测试 ： 

    [root@osd ~]# 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

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

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

    [root@osd ~]# 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

  6. 删除 rados bench 命令创建的数据： 

    [root@osd ~]# rados -p testbench cleanup

7.4. 基准测试 Ceph 块性能

Ceph 包含 rbd bench-write 命令，以测试对块设备测量吞吐量和延迟情况的连续写入。默认字节大小为 4096，默认 I/O 线程数为 16，默认的写入字节数为 1 GB。这些默认值可通过 --io-size, --io-threads 和 --io-total 选项分别进行修改。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 如果还没有加载，载入 rbd 内核模块： 

    [root@mon ~]# modprobe rbd

  2. 在 testbench 池中创建一个 1 GB 的 rbd 镜像文件： 

    [root@mon ~]# rbd create image01 --size 1024 --pool testbench

  3. 将镜像文件映射到设备文件中： 

    [root@mon ~]# rbd map image01 --pool testbench --name client.admin

  4. 在块设备中创建 ext4 文件系统： 

    [root@mon ~]# mkfs.ext4 /dev/rbd/testbench/image01

  5. 创建新目录： 

    [root@mon ~]# mkdir /mnt/ceph-block-device

  6. 将块设备挂载到 /mnt/ceph-block-device/ 下： 

    [root@mon ~]# mount /dev/rbd/testbench/image01 /mnt/ceph-block-device

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

    [root@mon ~]# rbd bench --io-type 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
    ..

其它资源

  • 有关 rbd 命令 的更多信息，请参阅 Red Hat Ceph Storage Block Device Device Guide 中的块设备命令部分。

第 8 章 Ceph 性能计数器

作为存储管理员，您可以收集 Red Hat Ceph Storage 集群的性能指标。Ceph 性能计数器是内部基础架构指标的集合。此指标数据的集合、聚合和图表可以通过一组工具进行，并可用于性能分析。

8.1. 先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。

8.2. 访问 Ceph 性能计数器

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

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

Monitor 集合名称目录

  • Cluster Metrics - 显示存储集群的信息：监控、OSD、池和 PG
  • Level Database Metrics - 显示后端 KeyValueStore 数据库的信息
  • Monitor Metrics - 显示常规监控信息
  • Paxos Metrics - 显示集群仲裁管理的信息
  • Throttle Metrics - 显示监控器节流的统计信息

OSD 集合名称目录

  • Write Back Throttle Metrics - 显示写入后节流的统计是如何跟踪未清空的 IO
  • Level Database Metrics - 显示后端 KeyValueStore 数据库的信息
  • Objecter Metrics - 显示各种基于对象的操作的信息
  • 读和写操作指标 - 显示各种读写操作的信息
  • 恢复状态指标 - 显示 - 显示各种恢复状态的延迟
  • OSD Throttle Metrics - 显示 OSD 节流的统计

RADOS 网关集合名称 Categories

  • Object Gateway Client Metrics - 显示 GET 和 PUT 请求的统计信息
  • Objecter Metrics - 显示各种基于对象的操作的信息
  • Object Gateway Throttle Metrics - 显示 OSD 节流方式的统计信息

8.3. 显示 Ceph 性能计数器

ceph 守护进程 .. perf 模式 命令会输出可用的指标。每个指标都有一个关联的位字段值类型。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 查看指标的 schema： 

    ceph daemon DAEMON_NAME perf schema
    注意

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

  2. 从 monitor 节点执行 ceph 守护进程 .. perf 模式 命令： 

    [root@mon ~]# ceph daemon mon.`hostname -s` perf schema

    Example

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

  3. 从 OSD 节点执行 ceph 守护进程 .. perf 模式 命令： 

    [root@mon ~]# ceph daemon osd.0 perf schema

    Example

    ...
"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

平均(Sum + Count)

8

计数

每个值都将有位 1 或 2 设置来表示类型，可以是浮点或整数值。当位 4 被设置时，将有两个值可供读取，分别是 sum 和 count。当设置了第 8 位时，以前间隔的平均间隔值为总 delta 值（自上一次读取以来）除以 delta 的数量。另外，从右边的值分离会提供生命周期平均值值。通常，这用于衡量延迟、请求数和请求延迟总和。一些位的值会被合并，如 5、6 和 10。位值 5 是位 1 和位 4 的组合。这意味着平均值将是一个浮点值。位值 6 是位 2 和位 4 的组合。这意味着平均值为一个整数。位值 10 是位 2 和位 8 的组合。这意味着计数器值将是整数值。

其它资源

8.4. 转储 Ceph 性能计数器

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

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 查看当前的指标数据： 

    # ceph daemon DAEMON_NAME perf dump
    注意

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

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

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

    Example

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

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

    # ceph daemon osd.0 perf dump

    Example

    ...
"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.5. 平均计数和总和

所有延迟数量都有一个 bit 字段值 5。此字段包含平均计数和 sum 的浮点值。avgcount 是这个范围内的操作数，sum 是总延迟（以秒为单位）。将 sum 除以 avgcount 的值为您提供了关于每个操作的延迟理念。

其它资源

  • 要查看每个可用 OSD 指标的简短描述，请参阅 Ceph OSD 表。

8.6. Ceph 监控指标

表 8.2. 集群指标表
集合名称指标名称位字段值简短描述

cluster

num_mon

2

监控器数

 

num_mon_quorum

2

仲裁中的 monitor 数量

 

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 状态的放置组数量

 

num_pg_active

2

处于活跃状态的放置组数量

 

num_pg_peering

2

处于 peering 状态的放置组数量

 

num_object

2

集群中的对象总数

 

num_object_degraded

2

降级数量（减少副本）对象

 

num_object_misplaced

2

对象中错误的原位（集群位置）数

 

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 映射的当前 epoch

表 8.3. 级别数据库指标表
集合名称指标名称位字段值简短描述

leveldb

leveldb_get

10

Gets

 

leveldb_transaction

10

Transactions

 

leveldb_compact

10

Compactions

 

leveldb_compact_range

10

按范围完成

 

leveldb_compact_queue_merge

10

在压缩队列中合并范围

 

leveldb_compact_queue_len

2

压缩队列长度

表 8.4. 常规监控指标表
集合名称指标名称位字段值简短描述

mon

num_sessions

2

当前打开的 monitor 会话数量

 

session_add

10

创建的 monitor 会话数量

 

session_rm

10

monitor 中的 remove_session 调用数量

 

session_trim

10

修剪监控会话的数量

 

num_elections

10

参与的 elections monitor 数量

 

election_call

10

有 monitor 启动的选举数

 

election_win

10

监控可享受的选举数量

 

election_lose

10

监控丢失的选举数量

表 8.5. Paxos Metrics Table
集合名称指标名称位字段值简短描述

paxos

start_leader

10

以领导角色开始

 

start_peon

10

以 peon 角色启动

 

restart

10

重启

 

refresh

10

刷新

 

refresh_latency

5

刷新延迟

 

begin

10

启动和处理开始

 

begin_keys

6

开始时事务中的键

 

begin_bytes

6

开始时事务中的数据

 

begin_latency

5

开始操作的延迟

 

commit

10

提交

 

commit_keys

6

提交时事务中的键

 

commit_bytes

6

提交时事务中的数据

 

commit_latency

5

提交延迟

 

collect

10

peon 收集

 

collect_keys

6

peon collect 时事务中的键

 

collect_bytes

6

peon collect 时事务中的数据

 

collect_latency

5

peon 收集延迟

 

collect_uncommitted

10

在开始的和处理的 collect 中未提交的值

 

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 Metrics Table
集合名称指标名称位字段值简短描述

throttle-*

val

10

目前可用节流

 

max

10

最大值 throttle

 

get

10

Gets

 

get_sum

10

获取数据

 

get_or_fail_fail

10

在 get_or_fail 时被阻断

 

get_or_fail_success

10

在 get_or_fail 期间获得成功

 

take

10

Takes

 

take_sum

10

获取的数据

 

put

10

Puts

 

put_sum

10

放置数据

 

wait

5

等待延迟

其它资源

8.7. Ceph OSD 指标

表 8.7. 写回 Throttle Metrics Table
集合名称指标名称位字段值简短描述

WBThrottle

bytes_dirtied

2

脏数据

 

bytes_wb

2

写入数据

 

ios_dirtied

2

脏操作

 

ios_wb

2

写入操作

 

inodes_dirtied

2

等待写入的条目

 

inodes_wb

2

写入条目

表 8.8. 级别数据库指标表
集合名称指标名称位字段值简短描述

leveldb

leveldb_get

10

Gets

 

leveldb_transaction

10

Transactions

 

leveldb_compact

10

Compactions

 

leveldb_compact_range

10

按范围完成

 

leveldb_compact_queue_merge

10

在压缩队列中合并范围

 

leveldb_compact_queue_len

2

压缩队列长度

表 8.9. Objecter Metrics Table
集合名称指标名称位字段值简短描述

objecter

op_active

2

活跃操作

 

op_laggy

2

Laggy 操作

 

op_send

10

发送的操作

 

op_send_bytes

10

发送的数据

 

op_resend

10

重新发送操作

 

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

Get 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 put 操作

 

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

池 stat 操作发送

 

poolstat_resend

10

重新设置池统计

 

statfs_active

2

statfs 操作

 

statfs_send

10

发送的 FS stats

 

statfs_resend

10

重新发送的 FS stats

 

command_active

2

活跃命令

 

command_send

10

发送命令

 

command_resend

10

重新发送命令

 

map_epoch

2

OSD map epoch

 

map_full

10

收到的完整 OSD 映射

 

map_inc

10

接收的增量 OSD map

 

osd_sessions

2

开放会话

 

osd_session_open

10

会话已打开

 

osd_session_close

10

会话关闭

 

osd_laggy

2

Laggy OSD 会话

表 8.10. 读和写操作指标表
集合名称指标名称位字段值简短描述

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

客户端 read-modify-write 操作

 

op_rw_in_bytes

10

客户端 read-modify-write 操作写入

 

op_rw_out_bytes

10

客户端 read-modify-write 操作读出

 

op_rw_rlat

5

客户端 read-modify-write 操作可读/应用延迟

 

op_rw_latency

5

读写操作的延迟（包括队列时间）

 

op_rw_process_latency

5

读写操作的延迟（不包括队列时间）

 

subop

10

Suboperations

 

subop_in_bytes

10

Suboperations 总数

 

subop_latency

5

Suboperations 延迟

 

subop_w

10

复制写入

 

subop_w_in_bytes

10

复制的写入数据大小

 

subop_w_latency

5

复制的写入延迟

 

subop_pull

10

Suboperations pull 请求

 

subop_pull_latency

5

Suboperations pull 延迟

 

subop_push

10

Suboperations push 消息

 

subop_push_in_bytes

10

Suboperations 推送的大小

 

subop_push_latency

5

Suboperations push 延迟

 

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 是主的放置组

 

numpg_replica

2

此 osd 是副本的放置组

 

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 epochs

 

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 flushes

 

tier_flush_fail

10

失败的分层清除

 

tier_try_flush

10

tier flush 尝试

 

tier_try_flush_fail

10

失败的分层清除尝试

 

tier_evict

10

等级驱除

 

tier_whiteout

10

Tier whiteouts

 

tier_dirty

10

设定脏层标志

 

tier_clean

10

清理脏层标志

 

tier_delay

10

Tier delays (agent waiting)

 

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.11. 恢复状态指标表
集合名称指标名称位字段值简短描述

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

重新恢复恢复状态延迟

 

repwaitrecoveryreserved_latency

5

rep 等待恢复保留恢复状态延迟

 

repwaitbackfillreserved_latency

5

Rep 等待回填保留的恢复状态

 

RepRecovering_latency

5

重新恢复恢复状态延迟

 

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

stray 恢复状态延迟

 

getinfo_latency

5

Getinfo 恢复状态延迟

 

getlog_latency

5

Getlog 恢复状态延迟

 

waitactingchange_latency

5

Waitactingchange 恢复状态延迟

 

incomplete_latency

5

恢复状态延迟不完整

 

getmissing_latency

5

获取恢复状态延迟

 

waitupthru_latency

5

Waitupthru 恢复状态延迟

表 8.12. OSD Throttle Metrics Table
集合名称指标名称位字段值简短描述

throttle-*

val

10

目前可用节流

 

max

10

最大值 throttle

 

get

10

Gets

 

get_sum

10

获取数据

 

get_or_fail_fail

10

在 get_or_fail 时被阻断

 

get_or_fail_success

10

在 get_or_fail 期间获得成功

 

take

10

Takes

 

take_sum

10

获取的数据

 

put

10

Puts

 

put_sum

10

放置数据

 

wait

5

等待延迟

其它资源

8.8. Ceph 对象网关指标

表 8.13. RADOS 客户端指标表
集合名称指标名称位字段值简短描述

client.rgw.<rgw_node_name>

req

10

Requests

 

failed_req

10

中止的请求

 

get

10

Gets

 

get_b

10

gets 的大小

 

get_initial_lat

5

获取延迟

 

put

10

Puts

 

put_b

10

puts 的大小

 

put_initial_lat

5

Put 延迟

 

qlen

2

队列长度

 

qactive

2

活跃请求队列

 

cache_hit

10

缓存命中

 

cache_miss

10

缓存未命中

 

keystone_token_cache_hit

10

Keystone 令牌缓存命

 

keystone_token_cache_miss

10

Keystone 令牌缓存未命中

 

gc_retire_object

10

自上次重启 Ceph 对象网关后，已停用的对象计数

表 8.14. Objecter Metrics Table
集合名称指标名称位字段值简短描述

objecter

op_active

2

活跃操作

 

op_laggy

2

Laggy 操作

 

op_send

10

发送的操作

 

op_send_bytes

10

发送的数据

 

op_resend

10

重新发送操作

 

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

Get 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 put 操作

 

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

池 stat 操作发送

 

poolstat_resend

10

重新设置池统计

 

statfs_active

2

statfs 操作

 

statfs_send

10

发送的 FS stats

 

statfs_resend

10

重新发送的 FS stats

 

command_active

2

活跃命令

 

command_send

10

发送命令

 

command_resend

10

重新发送命令

 

map_epoch

2

OSD map epoch

 

map_full

10

收到的完整 OSD 映射

 

map_inc

10

接收的增量 OSD map

 

osd_sessions

2

开放会话

 

osd_session_open

10

会话已打开

 

osd_session_close

10

会话关闭

 

osd_laggy

2

Laggy OSD 会话

表 8.15. RADOS 网关 Throttle Metrics Table
集合名称指标名称位字段值简短描述

throttle-*

val

10

目前可用节流

 

max

10

最大值 throttle

 

get

10

Gets

 

get_sum

10

获取数据

 

get_or_fail_fail

10

在 get_or_fail 时被阻断

 

get_or_fail_success

10

在 get_or_fail 期间获得成功

 

take

10

Takes

 

take_sum

10

获取的数据

 

put

10

Puts

 

put_sum

10

放置数据

 

wait

5

等待延迟

其它资源

第 9 章 BlueStore

从 Red Hat Ceph Storage 4 开始，BlueStore 是 OSD 守护进程的默认对象存储。较早的对象存储 FileStore 需要在原始块设备之上创建一个文件系统。对象然后写入文件系统。BlueStore 不需要初始文件系统，因为 BlueStore 会将对象直接放在块设备上。

重要

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

9.1. Ceph BlueStore

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

直接管理存储设备
BlueStore 使用原始块设备或分区。这可避免任何抽象层的抽象层，如 XFS 等本地文件系统，这可能会限制性能或增加复杂性。
使用 RocksDB 进行元数据管理
BlueStore 使用 RocksDB 的键值数据库来管理内部元数据，如从对象名称映射到磁盘上的块位置。
完整数据和元数据校验和
默认情况下，写入 BlueStore 的所有数据和元数据都受到一个或多个校验和的保护。在不验证的情况下，不会从磁盘或返回给用户读取数据或元数据。
高效的 copy-on-write 功能
Ceph 块设备和 Ceph 文件系统快照依赖于在 BlueStore 中高效实施的写时复制克隆机制。这可以提高常规快照以及依赖克隆来实现高效的两阶段提交的纠删代码池的 I/O 效率。
没有大型的双写方式
BlueStore 首先将任何新数据写入块设备上未分配空间，然后提交 RocksDB 事务来更新对象元数据以引用磁盘的新区域。只有写入操作低于可配置的大小阈值时，它才会回退到写出日志方案，这与 FileStore 的运行方式类似。
支持多设备

BlueStore 可以使用多个块设备来存储不同的数据。例如：用于数据的硬盘驱动器(HDD)，用于元数据的 Solid-state Drive(SSD)，即 Non-volatile Memory(NVM)或 Non-volatile random-access memory(NVRAM)或 RocksDB write-ahead 日志的持久性内存。详情请查看 Ceph BlueStore 设备。

注意

ceph-disk 实用程序尚未置备多个设备。若要使用多个设备，必须手动设置 OSD。

高效的块设备使用
因为 BlueStore 不使用任何文件系统，所以它将尽可能减少需要清除存储设备缓存的需要。

9.2. Ceph BlueStore 设备

本节介绍 BlueStore 后端使用哪些块设备。

BlueStore 可以管理一个、两个或三个存储设备。

  • 主
  • WAL
  • DB

在最简单的情形中，BlueStore 使用一个（主）存储设备。存储设备分为两个部分，其中包括：

  • OSD 元数据 ：使用 XFS 格式化的小分区，其中包含 OSD 的基本元数据。此数据目录包含 OSD 的信息，如其标识符、所属集群及其专用密钥环。
  • 数据 ：一个大型分区，占据由 BlueStore 直接管理的设备的其余部分，其中包含所有 OSD 数据。这个主要设备由数据目录中的块符号链接识别。

您还可以使用两个附加设备：

  • WAL(write-ahead-log)设备 ：存储 BlueStore 内部日志或 write-ahead 日志的设备。它通过数据目录中的 block.wal 符号链接来识别。只有在设备比主设备更快时才请考虑使用 WAL 设备。例如，当 WAL 设备使用 SSD 磁盘且主设备使用 HDD 磁盘时。
  • DB 设备 ：存储 BlueStore 内部元数据的设备。嵌入式 RocksDB 数据库包含尽可能多的元数据，因为它可以在 DB 设备上而不是主设备上的元数据来提高性能。如果 DB 设备已满，它开始向主设备添加元数据。只有在设备比主设备更快时才考虑使用 DB 设备。
警告

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

9.3. Ceph 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. Ceph BlueStore 的大小考虑

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

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

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

注意

除了 OSD 已消耗的内存占用空间外，BlueStore 缓存内存值也除外。

9.5. 添加 Ceph BlueStore OSD

这部分论述了如何使用 BlueStore 后端对象存储安装新的 Ceph OSD 节点。

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 节点的根级别访问权限。

流程

  1. 添加新的 OSD 节点到 Ansible 清单文件中的 [osds] 部分，默认为位于 /etc/ansible/hosts。 

    [osds]
node1
node2
node3
HOST_NAME

    替换：

    • HOST_NAME 为 OSD 节点的名称

    Example

    [osds]
node1
node2
node3
node4

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

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

  3. 创建 host_vars 目录。 

    [root@admin ceph-ansible] mkdir host_vars

  4. 在 host_vars 中为新添加的 OSD 创建配置文件。 

    [root@admin ceph-ansible] touch host_vars/HOST_NAME.yml

    替换：

    • 带有新添加 OSD 的主机名的 HOST_NAME

    Example

    [root@admin ceph-ansible] touch host_vars/node4.yml

  5. 在新创建的文件中添加以下设置： 

    osd_objectstore: bluestore
    注意

    要将 BlueStore 用于所有 OSD，请将 osd_objectstore:bluestore 添加到 group_vars/all.yml 文件中。

  6. 在 host_vars/HOST_NAME.yml 中配置 BlueStore OSD：

    语法

    lvm_volumes:
  - data: DATALV
    data_vg: DATAVG

    替换：

    • 带有数据逻辑卷名称的 DATALV
    • 带有数据逻辑卷组名称的 DATAVG

    Example

    lvm_volumes:
  - data: data-lv1
    data_vg: vg1

  7. 可选。如果要将 block.wal 和 block.db 存储在专用逻辑卷中，请编辑 host_vars/HOST_NAME.yml 文件，如下所示： 

    lvm_volumes:
  - data: DATALV
    wal: WALLV
    wal_vg: VG
    db: DBLV
    db_vg: VG

    替换：

    • 带有数据逻辑卷的 DATALV
    • WALLV 及应该包含 write-ahead-log 的逻辑卷
    • 带有 WAL 和/或 DB 设备 LV 所在卷组的 VG
    • 包含 BlueStore 内部元数据的 DBLV

    Example

    lvm_volumes:
  - data: data-lv3
    wal: wal-lv1
    wal_vg: vg3
    db: db-lv3
    db_vg: vg3

    注意

    当使用 lvm_volumes: with osd_objectstore: bluestore 时，LVM_volumes YAML 字典中必须至少包含 数据。定义 wal 或 db 时，它必须同时具有 LV 名称和 VG 名称（不需要db 和 wal ）。这允许四个组合：只包括数据、数据和 wal、数据和 Wal 和 db，或者 data 和 db。数据可以是裸设备、lv 或分区。wal 和 db 可以是 lv 或 partition。当指定裸设备或分区 ceph-volume 时，会将逻辑卷放在其中。

    注意

    目前，ceph-ansible 不会创建卷组或逻辑卷。这必须在运行 Anisble playbook 之前完成。

  8. 可选：您可以在 group_vars/all.yml 文件中覆盖 block.db 默认大小：

    语法

    ceph_conf_overrides:
  osd:
    bluestore_block_db_size: VALUE

    Example

    ceph_conf_overrides:
  osd:
    bluestore_block_db_size: 24336000000

    注意

    bluestore_block_db_size 的值应大于 2 GB。

  9. 打开并编辑 group_vars/all.yml 文件，然后取消注释 osd_memory_target 选项。调整 OSD 要消耗的内存数量。

    注意

    osd_memory_target 选项的默认值为 4000000000，即 4 GB。这个选项在内存中固定 BlueStore 缓存。

    重要

    osd_memory_target 选项仅适用于 BlueStore 支持的 OSD。

  10. 运行以下 Ansible playbook： 

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

  11. 在 Ceph 监控节点中，验证新 OSD 是否已成功添加： 

    [root@mon ~]# ceph osd tree

9.6. 为小写入调优 Ceph BlueStore

在 BlueStore 中，原始分区在 bluestore_min_alloc_size 的块中分配和管理。默认情况下，蓝色store_min_alloc_size 是 64 KB ( HDD)和 4 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 覆盖它们。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 可重新置备为 OSD 节点的新服务器，或者：
  • 可以重新部署的 OSD 节点。
  • 如果您要重新部署现有的 Ceph OSD 节点，Ceph 监控节点的管理密钥环。

流程

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

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

    Example

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

  2. 如果重新部署现有的 OSD 节点，请擦除 OSD 驱动器并重新安装操作系统。
  3. 使用 Ansible 为 OSD 调配准备节点。准备任务示例包括启用 Red Hat Ceph Storage 存储库、添加 Ansible 用户以及启用无密码 SSH 登录。

  4. 将 bluestore_min_alloc_size 添加到 group_vars/all.yml Ansible playbook 的 ceph_conf_overrides 部分： 

    ceph_conf_overrides:
  osd:
    bluestore_min_alloc_size: 4096

  5. 如果部署新节点，请将其添加到 Ansible 清单文件中，通常为 /etc/ansible/hosts ： 

    [osds]
OSD_NODE_NAME

    Example

    [osds]
osd1 devices="[ '/dev/sdb' ]"

  6. 如果重新部署现有的 OSD，请将 Ceph Monitor 节点上的 admin keyring 文件复制到您要部署 OSD 的节点。

  7. 使用 Ansible 置备 OSD 节点： 

    ansible-playbook -v site.yml -l OSD_NODE_NAME

    Example

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

  8. playbook 完成后，使用 ceph 守护进程 命令验证设置： 

    ceph daemon OSD.ID config get bluestore_min_alloc_size

    Example

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

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

其它资源

9.7. BlueStore 碎片工具

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

9.7.1. 前提条件

  • 正在运行的 Red Hat Ceph Storage 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 的碎片级别。

前提条件

  • 正在运行的 Red Hat Ceph Storage 3.3 或更高版本的存储集群。
  • BlueStore OSDs.

在线 BlueStore 碎片得分

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

    1. 简单报告：

      语法

      ceph daemon OSD_ID bluestore allocator score block

      示例

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

    2. 详细的报告：

      语法

      ceph daemon OSD_ID bluestore allocator dump block

      示例

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

离线 BlueStore 碎片得分

  1. 检查非运行 BlueStore OSD 进程：

    1. 简单报告：

      语法

      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

    2. 详细的报告：

      语法

      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

其它资源

9.8. 如何将对象存储从 FileStore 迁移到 BlueStore

作为存储管理员，您可以从传统对象存储 FileStore 迁移到新的对象存储 BlueStore。

9.8.1. 前提条件

  • 一个健康且运行 Red Hat Ceph Storage 集群。

9.8.2. 从 FileStore 迁移到 BlueStore

与传统的 FileStore 相比，BlueStore 提高了性能和稳健性。单个 Red Hat Ceph Storage 集群可以包含 FileStore 和 BlueStore 设备的组合。

转换单个 OSD 无法进行，或者隔离。转换过程将依赖于存储集群的常规复制和修复过程或将 OSD 内容从旧(FileStore)设备复制到新的(BlueStore)设备的工具和策略。有两种方法可以从 FileStore 迁移到 BlueStore。

第一种方法

第一种方法是依次标记每个设备，等待数据在存储集群中复制，重新置备 OSD，并将它重新标记为"in"。这个方法的优点和缺点：

优点
  • 简单.
  • 可以在设备基础上完成。
  • 不需要备用设备或节点。
缺点

  • 在网络上复制数据两次。

    注意

    一个副本到存储集群中的其他 OSD，允许您维护所需的副本数，然后将另一个副本重新复制到重新置备的 BlueStore OSD。

第二种方法

第二种方法是进行整个节点替换。您需要有一个没有数据的空节点。

有两种方法可以做到这一点：* 从不是存储集群一部分的一个新空节点开始。* 通过从存储集群中现有节点卸载数据。

优点
  • 数据仅通过网络复制。
  • 可一次性转换整个节点的 OSD。
  • 可以并行转换多个节点。
  • 每个节点不需要备用设备。
缺点
  • 需要一个备用节点。
  • 整个节点需要 OSD 将一次迁移数据。这可能会影响整个集群性能。
  • 所有迁移的数据仍通过网络进行一个完整的跃点。

9.8.3. 使用 Ansible 从 FileStore 迁移到 BlueStore

使用 Ansible 从 FileStore 迁移到 BlueStore，将缩小并重新部署节点上的所有 OSD。在开始迁移前，Ansible playbook 会执行容量检查。然后，ceph-volume 程序重新部署 OSD。

前提条件

  • 正常运行的 Red Hat Ceph Storage 4 集群。
  • 用于 Ansible 应用的 ansible 用户帐户。

流程

  1. 以 ansible 用户身份登录 Ansible 管理节点。

  2. 编辑 group_vars/osd.yml 文件，添加和设置以下选项： 

    nb_retry_wait_osd_up: 50
delay_wait_osd_up: 30

  3. 运行以下 Ansible playbook：

    语法

    ansible-playbook infrastructure-playbooks/filestore-to-bluestore.yml --limit OSD_NODE_TO_MIGRATE

    Example

    [ansible@admin ~]$ ansible-playbook infrastructure-playbooks/filestore-to-bluestore.yml --limit osd1

    警告

    如果您在 Ceph 配置文件中明确设置了 osd_crush_update_on_start = False，则转换会失败。它将创建具有不同 ID 的新 OSD，并在 CRUSH 规则中写出它。另外，它无法清除旧的 OSD 数据目录。

  4. 等待迁移完成，然后再在存储集群中的下一个 OSD 节点上启动。

9.8.4. 使用标记和替换方法从 FileStore 迁移到 BlueStore

从 FileStore 迁移到 BlueStore 最简单的方法是依次标记每个设备，等待数据在存储集群中复制，重新置备 OSD，然后再次将其标记为"in"。

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 根 访问节点。

流程

将下列变量 OSD_ID 替换为 ODS 标识号。

  1. 找到要替换的 FileStore OSD。

    1. 获取 OSD 标识号： 

      [root@ceph-client ~]# ceph osd tree

    2. 确定 OSD 是否使用 FileStore 还是 BlueStore：

      语法

      ceph osd metadata OSD_ID | grep osd_objectstore

      Example

      [root@ceph-client ~]# ceph osd metadata 0 | grep osd_objectstore
    "osd_objectstore": "filestore",

    3. 查看 FileStore 设备与 BlueStore 设备的当前计数： 

      [root@ceph-client ~]# ceph osd count-metadata osd_objectstore

  2. 将 FileStore OSD 标记为 out： 

    ceph osd out OSD_ID

  3. 等待数据从 OSD 迁出： 

    while ! ceph osd safe-to-destroy OSD_ID ; do sleep 60 ; done

  4. 停止 OSD： 

    systemctl stop ceph-osd@OSD_ID

  5. 捕获此 OSD 正在使用的设备： 

    mount | grep /var/lib/ceph/osd/ceph-OSD_ID

  6. 卸载 OSD： 

    umount /var/lib/ceph/osd/ceph-OSD_ID

  7. 使用第 5 步的值作为 DEVICE 销毁 OSD 数据： 

    ceph-volume lvm zap DEVICE
    重要

    成为 EXTREMELY CAREFUL，因为这会销毁设备的内容。在继续之前，不需要在该设备上使用这些数据，即存储集群处于健康状态。

    注意

    如果 OSD 被加密，则卸载 osd-lockbox 并在使用 dmsetup 删除 OSD 前删除加密。

    注意

    如果 OSD 包含逻辑卷，则在 ceph-volume lvm zap 命令中使用 --destroy 选项。

  8. 使存储集群知道 OSD 已销毁： 

    [root@ceph-client ~]# ceph osd destroy OSD_ID --yes-i-really-mean-it

  9. 使用 DEVICE 从第 5 步和相同的 OSD_ID 将 OSD 重新置备为 BlueStore OSD： 

    [root@ceph-client ~]# ceph-volume lvm create --bluestore --data DEVICE --osd-id OSD_ID

  10. 重复此步骤。

    注意

    只要您确保存储集群在销毁任何 OSD 之前存储集群为 HEALTH_OK，新的 BlueStore OSD 的重填操作可以与排空下一个 FileStore OSD 同时进行。如果不这样做，将降低数据的冗余，并增加风险，或者降低数据丢失。

9.8.5. 使用整个节点替换方法从 FileStore 迁移到 BlueStore

通过将每个存储的数据副本从 FileStore 迁移到 BlueStore，可以逐个节点执行。此迁移可以使用存储集群中的备用节点完成，或者有足够的可用空间从存储集群中清空整个节点，以便将其用作备用节点。理想情况下，节点必须与您要迁移的其他节点大致相同。

前提条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 根 访问节点。
  • 没有数据的空节点。

流程

  • 将下面的变量 NEWNODE 替换为新节点名称。
  • 将以下变量 EXISTING_NODE_TO_CONVERT 替换为存储集群中已存在的节点名称。

  • 将下列变量 OSD_ID 替换为 OSD 标识号。

    1. 使用不在存储集群中的新节点。对于在存储集群中使用现有节点，请跳至第 3 步。

      1. 将节点添加到 CRUSH 层次结构中： 

        [root@mon ~]# ceph osd crush add-bucket NEWNODE node
        重要

        不要将它附加到 root 用户。

      2. 安装 Ceph 软件包： 

        [root@mon ~]# yum install ceph-osd
        注意

        将 Ceph 配置文件（默认为 /etc/ceph/ceph.conf ）和密钥环复制到新节点。

    2. 跳至第 5 步。

    3. 如果您使用已在存储集群中已存在的节点，请使用以下命令： 

      [root@mon ~]# ceph osd crush unlink EXISTING_NODE_TO_CONVERT default
      注意

      其中 default 是 CRUSH map 中的即时维护器。

    4. 跳至第 8 步。

    5. 为所有设备置备新的 BlueStore OSD： 

      [root@mon ~]# ceph-volume lvm create --bluestore --data /dev/DEVICE

    6. 验证 OSD 是否加入集群： 

      [root@mon ~]# ceph osd tree

      您应当会在节点名称下看到新节点名称及所有 OSD，但 不得将 节点嵌套在层次结构中任何其他节点。

      Example

      [root@mon ~]# ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-5             0 node newnode
10   ssd 1.00000     osd.10        up  1.00000 1.00000
11   ssd 1.00000     osd.11        up  1.00000 1.00000
12   ssd 1.00000     osd.12        up  1.00000 1.00000
-1       3.00000 root default
-2       3.00000     node oldnode1
0   ssd 1.00000         osd.0     up  1.00000 1.00000
1   ssd 1.00000         osd.1     up  1.00000 1.00000
2   ssd 1.00000         osd.2     up  1.00000 1.00000

    7. 将新节点交换到集群中的旧节点位置： 

      [root@mon ~]# ceph osd crush swap-bucket NEWNODE EXISTING_NODE_TO_CONVERT

      此时，EXISTING_NODE_TO_CONVERT 上的所有数据都将开始迁移到 NEWNODE 上的 OSD。

      注意

      如果旧节点和新节点的总量不同，您可能还会看到一些数据迁移到存储集群中的其他节点，但只要节点的大小类似，这就是一个相对较小的数据。

    8. 等待数据迁移完成： 

      while ! ceph osd safe-to-destroy $(ceph osd ls-tree EXISTING_NODE_TO_CONVERT); do sleep 60 ; done

    9. 登录到 EXISTING_NODE_TO_CONVERT，停止并卸载 now-empty EXISTING_NODE_TO_CONVERT 上的所有旧 OSD： 

      [root@mon ~]# systemctl stop ceph-osd@OSD_ID
[root@mon ~]# umount /var/lib/ceph/osd/ceph-OSD_ID

    10. 销毁并清除旧的 OSD： 

      for osd in ceph osd ls-tree EXISTING_NODE_TO_CONVERT; do ceph osd purge $osd --yes-i-really-mean-it ; done

    11. 擦除旧的 OSD 设备。这要求您确定手动擦除哪些设备。为每个设备执行以下命令： 

      [root@mon ~]# ceph-volume lvm zap DEVICE
      重要

      成为 EXTREMELY CAREFUL，因为这会销毁设备的内容。在继续之前，不需要在该设备上使用这些数据，即存储集群处于健康状态。

      注意

      如果 OSD 被加密，则卸载 osd-lockbox 并在使用 dmsetup 删除 OSD 前删除加密。

      注意

      如果 OSD 包含逻辑卷，则在 ceph-volume lvm zap 命令中使用 --destroy 选项。

    12. 使用 now-empty 旧节点作为新节点，再重复这个过程。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.