管理指南
管理 Red Hat Ceph Storage
摘要
第 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 的进程管理
作为存储管理员，您可以按照 Red Hat Ceph Storage 集群中的类型或实例来操作各种 Ceph 守护进程。通过操作这些守护进程，您可以根据需要启动、停止和重启所有 Ceph 服务。
2.1. 先决条件
- 安装 Red Hat Ceph Storage 软件。
2.2. Ceph 进程管理
在红帽 Ceph 存储中，所有流程管理都通过 Systemd 服务完成。在每次 start, restart, 和 stop Ceph 守护进程时，必须指定守护进程类型或守护进程实例。
其它资源
- 有关使用 systemd 的更多信息，请参阅 Red Hat Enterprise Linux 8 配置基本系统设置指南中的使用 systemctl以及使用 systemctl 管理系统章节的内容。
2.3. 启动、停止和重启所有 Ceph 守护进程
您可以作为您要停止 Ceph 守护进程的主机中的 root 用户启动、停止和重启所有 Ceph 守护进程。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
-
具有对节点的
root访问权限。
流程
在您要启动、停止和重启守护进程的主机上，运行 systemctl 服务来获取服务的 SERVICE_ID。
示例
[root@host01 ~]# systemctl --type=service ceph-499829b4-832f-11eb-8d6d-001a4a000635@mon.host01.service
启动所有 Ceph 守护进程：
语法
systemctl start SERVICE_ID示例
[root@host01 ~]# systemctl start ceph-499829b4-832f-11eb-8d6d-001a4a000635@mon.host01.service
停止所有 Ceph 守护进程：
语法
systemctl stop SERVICE_ID示例
[root@host01 ~]# systemctl stop ceph-499829b4-832f-11eb-8d6d-001a4a000635@mon.host01.service
重启所有 Ceph 守护进程：
语法
systemctl restart SERVICE_ID示例
[root@host01 ~]# systemctl restart ceph-499829b4-832f-11eb-8d6d-001a4a000635@mon.host01.service
2.4. 启动、停止和重启所有 Ceph 服务
Ceph 服务是具有相同类型的 Ceph 守护进程的逻辑组，它们配置为在同一 Red Hat Ceph Storage 集群中运行。Ceph 中的编配层允许用户以集中的方式管理这些服务，从而可以轻松地执行影响到同一逻辑服务的所有 Ceph 守护进程的操作。每个主机中运行的 Ceph 守护进程通过 Systemd 服务进行管理。您可以从要管理 Ceph 服务的主机启动、停止和重新启动所有 Ceph 服务。
如果要在特定主机中启动、停止或重启特定的 Ceph 守护进程，您需要使用 SystemD 服务。要获取在特定主机中运行的 SystemD 服务列表，连接到主机，并运行以下命令：
示例
[root@host01 ~]# systemctl list-units “ceph*”
输出将为您提供可用于管理每个 Ceph 守护进程的服务名称的列表。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
-
具有对节点的
root访问权限。
流程
登录到 Cephadm shell：
示例
[root@host01 ~]# cephadm shell
运行
ceph orch ls命令，以获取 Red Hat Ceph Storage 集群中配置的 Ceph 服务列表，并获取特定的服务 ID。示例
[ceph: root@host01 /]# ceph orch ls NAME RUNNING REFRESHED AGE PLACEMENT IMAGE NAME IMAGE ID alertmanager 1/1 4m ago 4M count:1 registry.redhat.io/openshift4/ose-prometheus-alertmanager:v4.5 b7bae610cd46 crash 3/3 4m ago 4M * registry.redhat.io/rhceph-alpha/rhceph-5-rhel8:latest c88a5d60f510 grafana 1/1 4m ago 4M count:1 registry.redhat.io/rhceph-alpha/rhceph-5-dashboard-rhel8:latest bd3d7748747b mgr 2/2 4m ago 4M count:2 registry.redhat.io/rhceph-alpha/rhceph-5-rhel8:latest c88a5d60f510 mon 2/2 4m ago 10w count:2 registry.redhat.io/rhceph-alpha/rhceph-5-rhel8:latest c88a5d60f510 nfs.foo 0/1 - - count:1 <unknown> <unknown> node-exporter 1/3 4m ago 4M * registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.5 mix osd.all-available-devices 5/5 4m ago 3M * registry.redhat.io/rhceph-alpha/rhceph-5-rhel8:latest c88a5d60f510 prometheus 1/1 4m ago 4M count:1 registry.redhat.io/openshift4/ose-prometheus:v4.6 bebb0ddef7f0 rgw.test_realm.test_zone 2/2 4m ago 3M count:2 registry.redhat.io/rhceph-alpha/rhceph-5-rhel8:latest c88a5d60f510
要启动特定的服务，请运行以下命令：
语法
ceph orch start SERVICE_ID示例
[ceph: root@host01 /]# ceph orch start node-exporter
要停止特定的服务，请运行以下命令：
重要ceph orch stop SERVICE_ID命令会导致 Red Hat Ceph Storage 集群无法访问，仅适用于 MON 和 MGR 服务。建议您使用systemctl stop SERVICE_ID命令来停止主机上的特定守护进程。语法
ceph orch stop SERVICE_ID示例
[ceph: root@host01 /]# ceph orch stop node-exporter
在
ceph 或ch stop node-exporter命令中，删除node exporter服务的所有守护进程。要重启特定的服务，请运行以下命令：
语法
ceph orch restart SERVICE_ID示例
[ceph: root@host01 /]# ceph orch restart node-exporter
2.5. 查看在容器中运行的 Ceph 守护进程的日志文件
使用容器主机中的 journald 守护进程，从容器查看 Ceph 守护进程的日志文件。
先决条件
- 安装 Red Hat Ceph Storage 软件。
- 节点的根级别访问权限。
流程
要查看整个 Ceph 日志文件，请以
root身份运行一个journalctl命令，其格式如下：语法
journalctl -u ceph SERVICE_ID[root@host01 ~]# journalctl -u ceph-499829b4-832f-11eb-8d6d-001a4a000635@osd.8.service
在上例中，您可以查看 OSD 的整个日志，其 ID 为
osd.8。要只显示最新的日志条目，请使用
-f选项。语法
journalctl -fu SERVICE_ID示例
[root@host01 ~]# journalctl -fu ceph-499829b4-832f-11eb-8d6d-001a4a000635@osd.8.service
您还可以使用 sosreport 实用程序查看 journald 日志。有关 SOS 报告的详情，请查看 什么是 sosreport 以及如何在 Red Hat Enterprise Linux 中创建它？ 红帽客户门户网站上的解决方案。
其它资源
-
journalctl手册页。
2.6. 关闭并重启 Red Hat Ceph Storage 集群
您可以使用两种不同的方法关闭并重启 Red Hat Ceph Storage 集群： systemctl 命令和 Ceph Orchestrator。您可以选择关闭并重启集群的方法。
2.6.1. 使用 systemctl 命令关闭并重启集群
您可以使用 systemctl 命令来关闭并重启 Red Hat Ceph Storage 集群。此方法遵循 Linux 停止服务的方式。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 根级别访问权限.
流程
关闭 Red Hat Ceph Storage 集群
- 停止使用块设备镜像 RADOS 网关 - 此集群上的 Ceph 对象网关以及任何其他客户端的客户端。
登录到 Cephadm shell：
示例
[root@host01 ~]# cephadm shell
在继续操作前，集群必须处于健康状态（
Health_OK以及所有的 PG 为active+clean）。使用客户端密钥环在主机上（如 Ceph 监控器或 OpenStack 控制器节点）运行ceph status，以确保集群健康。示例
[ceph: root@host01 /]# ceph -s
如果使用 Ceph 文件系统 (
CephFS)，请关闭CephFS集群：语法
ceph fs set FS_NAME max_mds 1 ceph fs fail FS_NAME ceph status ceph fs set FS_NAME joinable false
示例
[ceph: root@host01 /]# ceph fs set cephfs max_mds 1 [ceph: root@host01 /]# ceph fs fail cephfs [ceph: root@host01 /]# ceph status [ceph: root@host01 /]# ceph fs set cephfs joinable false
设置
noout、norecover、norebalance、nobackfill、nodown和pause标志。在使用客户端密钥环的节点上运行以下命令，如 Ceph 监控器或 OpenStack 控制器节点：示例
[ceph: root@host01 /]# ceph osd set noout [ceph: root@host01 /]# ceph osd set norecover [ceph: root@host01 /]# ceph osd set norebalance [ceph: root@host01 /]# ceph osd set nobackfill [ceph: root@host01 /]# ceph osd set nodown [ceph: root@host01 /]# ceph osd set pause
重要上例仅用于停止服务和 OSD 节点上的每个 OSD，需要在每个 OSD 节点上重复。
- 如果 MDS 和 Ceph 对象网关节点位于自己的专用节点上，请将其关闭。
获取守护进程的 systemd 目标：
示例
[root@host01 ~]# systemctl list-units --type target | grep ceph ceph-0b007564-ec48-11ee-b736-525400fd02f8.target loaded active active Ceph cluster 0b007564-ec48-11ee-b736-525400fd02f8 ceph.target loaded active active All Ceph clusters and services
禁用包含集群 FSID 的目标：
示例
[root@host01 ~]# systemctl disable ceph-0b007564-ec48-11ee-b736-525400fd02f8.target Removed "/etc/systemd/system/multi-user.target.wants/ceph-0b007564-ec48-11ee-b736-525400fd02f8.target". Removed "/etc/systemd/system/ceph.target.wants/ceph-0b007564-ec48-11ee-b736-525400fd02f8.target".
停止目标：
示例
[root@host01 ~]# systemctl stop ceph-0b007564-ec48-11ee-b736-525400fd02f8.target
这将停止主机上需要停止的所有守护进程。
关闭该节点：
示例
[root@host01 ~]# shutdown Shutdown scheduled for Wed 2024-03-27 11:47:19 EDT, use 'shutdown -c' to cancel.
- 对集群的所有节点重复上述步骤。
重新引导 Red Hat Ceph Storage 集群
- 如果涉及网络设备，请确保在打开任何 Ceph 主机或节点之前将其开机和稳定。
- 打开管理节点。
启用 systemd 目标以获取所有正在运行的守护进程：
示例
[root@host01 ~]# systemctl enable ceph-0b007564-ec48-11ee-b736-525400fd02f8.target Created symlink /etc/systemd/system/multi-user.target.wants/ceph-0b007564-ec48-11ee-b736-525400fd02f8.target → /etc/systemd/system/ceph-0b007564-ec48-11ee-b736-525400fd02f8.target. Created symlink /etc/systemd/system/ceph.target.wants/ceph-0b007564-ec48-11ee-b736-525400fd02f8.target → /etc/systemd/system/ceph-0b007564-ec48-11ee-b736-525400fd02f8.target.
启动 systemd 目标：
示例
[root@host01 ~]# systemctl start ceph-0b007564-ec48-11ee-b736-525400fd02f8.target
- 等待所有节点上线。验证所有服务都已启动，且节点之间没有网络连接的问题。
取消设置
noout、norecover、norebalance、nobackfill、nodown和pause标志。在使用客户端密钥环的节点上运行以下命令，如 Ceph 监控器或 OpenStack 控制器节点：示例
[ceph: root@host01 /]# ceph osd unset noout [ceph: root@host01 /]# ceph osd unset norecover [ceph: root@host01 /]# ceph osd unset norebalance [ceph: root@host01 /]# ceph osd unset nobackfill [ceph: root@host01 /]# ceph osd unset nodown [ceph: root@host01 /]# ceph osd unset pause
如果使用 Ceph 文件系统 (
CephFS)，请通过将joinable标记设置为true来使CephFS集群重新启动：语法
ceph fs set FS_NAME joinable true示例
[ceph: root@host01 /]# ceph fs set cephfs joinable true
验证
-
验证集群处于健康状态（
Health_OK和所有 PGactive+clean）。在具有客户端密钥环的节点上运行ceph 状态，如 Ceph 监控器或 OpenStack 控制器节点，以确保集群健康。
示例
[ceph: root@host01 /]# ceph -s
其它资源
- 有关安装 Ceph 的更多信息，请参阅 Red Hat Ceph Storage 安装指南。
2.6.2. 使用 Ceph Orchestrator 关闭并重新引导集群
您还可以使用 Ceph Orchestrator 的功能来关闭并重启 Red Hat Ceph Storage 集群。在大多数情况下，它是一个单个系统登录，可以帮助关闭集群。
Ceph 编排器支持若干操作，如 start, stop, 和 restart。您可以将这些命令与 systemctl 搭配使用，在某些情况下可以关闭或重新引导集群。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
流程
关闭 Red Hat Ceph Storage 集群
- 停止使用该集群上的用户 Block Device Image 和 Ceph 对象网关以及任何其他客户端的客户端。
登录到 Cephadm shell：
示例
[root@host01 ~]# cephadm shell
在继续操作前，集群必须处于健康状态（
Health_OK以及所有的 PG 为active+clean）。使用客户端密钥环在主机上（如 Ceph 监控器或 OpenStack 控制器节点）运行ceph status，以确保集群健康。示例
[ceph: root@host01 /]# ceph -s
如果使用 Ceph 文件系统 (
CephFS)，请关闭CephFS集群：语法
ceph fs set FS_NAME max_mds 1 ceph fs fail FS_NAME ceph status ceph fs set FS_NAME joinable false ceph mds fail FS_NAME:N
示例
[ceph: root@host01 /]# ceph fs set cephfs max_mds 1 [ceph: root@host01 /]# ceph fs fail cephfs [ceph: root@host01 /]# ceph status [ceph: root@host01 /]# ceph fs set cephfs joinable false [ceph: root@host01 /]# ceph mds fail cephfs:1
设置
noout、norecover、norebalance、nobackfill、nodown和pause标志。在使用客户端密钥环的节点上运行以下命令，如 Ceph 监控器或 OpenStack 控制器节点：示例
[ceph: root@host01 /]# ceph osd set noout [ceph: root@host01 /]# ceph osd set norecover [ceph: root@host01 /]# ceph osd set norebalance [ceph: root@host01 /]# ceph osd set nobackfill [ceph: root@host01 /]# ceph osd set nodown [ceph: root@host01 /]# ceph osd set pause
停止 MDS 服务。
获取 MDS 服务名称：
示例
[ceph: root@host01 /]# ceph orch ls --service-type mds
使用上一步中获取的名称停止 MDS 服务：
语法
ceph orch stop SERVICE-NAME
停止 Ceph 对象网关服务。对部署的每个服务重复此操作。
获取 Ceph 对象网关服务名称：
示例
[ceph: root@host01 /]# ceph orch ls --service-type rgw
使用获取的名称停止 Ceph 对象网关服务：
语法
ceph orch stop SERVICE-NAME
停止 Alertmanager 服务：
示例
[ceph: root@host01 /]# ceph orch stop alertmanager
停止 node-exporter 服务，该服务是监控堆栈的一部分：
示例
[ceph: root@host01 /]# ceph orch stop node-exporter
停止 Prometheus 服务：
示例
[ceph: root@host01 /]# ceph orch stop prometheus
停止 Grafana 仪表板服务：
示例
[ceph: root@host01 /]# ceph orch stop grafana
停止崩溃的服务：
示例
[ceph: root@host01 /]# ceph orch stop crash
将 OSD 节点从 cephadm 节点关闭，每次关闭一个。对集群中的所有 OSD 重复此步骤。
获取 OSD ID：
示例
[ceph: root@host01 /]# ceph orch ps --daemon-type=osd
使用您获取的 OSD ID 关闭 OSD 节点：
示例
[ceph: root@host01 /]# ceph orch daemon stop osd.1 Scheduled to stop osd.1 on host 'host02'
逐一停止监视器。
识别托管该监控器的主机：
示例
[ceph: root@host01 /]# ceph orch ps --daemon-type mon
在每个主机上，停止该监控器。
确定
systemctl单元名称：示例
[ceph: root@host01 /]# systemctl list-units ceph-* | grep mon
停止该服务：
语法
systemct stop SERVICE-NAME
- 关闭所有主机。
重新引导 Red Hat Ceph Storage 集群
- 如果涉及网络设备，请确保在打开任何 Ceph 主机或节点之前将其开机和稳定。
- 打开所有 Ceph 主机。
从 Cephadm shell 登录管理节点：
示例
[root@host01 ~]# cephadm shell
验证所有服务都处于运行状态：
示例
[ceph: root@host01 /]# ceph orch ls
确保集群健康状态为 'Health_OK'status：
示例
[ceph: root@host01 /]# ceph -s
取消设置
noout、norecover、norebalance、nobackfill、nodown和pause标志。在使用客户端密钥环的节点上运行以下命令，如 Ceph 监控器或 OpenStack 控制器节点：示例
[ceph: root@host01 /]# ceph osd unset noout [ceph: root@host01 /]# ceph osd unset norecover [ceph: root@host01 /]# ceph osd unset norebalance [ceph: root@host01 /]# ceph osd unset nobackfill [ceph: root@host01 /]# ceph osd unset nodown [ceph: root@host01 /]# ceph osd unset pause
如果使用 Ceph 文件系统 (
CephFS)，请通过将joinable标记设置为true来使CephFS集群重新启动：语法
ceph fs set FS_NAME joinable true示例
[ceph: root@host01 /]# ceph fs set cephfs joinable true
验证
-
验证集群处于健康状态（
Health_OK和所有 PGactive+clean）。在具有客户端密钥环的节点上运行ceph 状态，如 Ceph 监控器或 OpenStack 控制器节点，以确保集群健康。
示例
[ceph: root@host01 /]# ceph -s
其它资源
- 有关安装 Ceph 的更多信息，请参阅 Red Hat Ceph Storage 安装指南。
第 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 集群。
- 节点的根级别访问权限。
流程
以交互模式运行
ceph实用程序。语法
podman exec -it ceph-mon-MONITOR_NAME /bin/bash- 替换
-
通过运行
podman ps命令找到带有 Ceph Monitor 容器的名称 MONITOR_NAME。
-
通过运行
示例
[root@host01 ~]# podman exec -it ceph-499829b4-832f-11eb-8d6d-001a4a000635-mon.host01 /bin/bash
本例在 mon.host01 上打开一个交互式终端会话，您可以在其中启动 Ceph 互动 shell。
3.2.3. 检查存储集群健康状况
启动 Ceph 存储集群后，在开始读取或写入数据前，首先检查存储集群的健康状态。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
流程
登录到 Cephadm shell：
示例
root@host01 ~]# cephadm shell
您可以使用以下命令来检查 Ceph 存储集群的健康状态：
示例
[ceph: root@host01 /]# ceph health HEALTH_OK
您可以通过运行
ceph status命令检查 Ceph 存储集群的状态：示例
[ceph: root@host01 /]# ceph status
输出提供以下信息：
- 集群 ID
- 集群健康状态
- monitor map epoch 和 monitor 仲裁的状态。
- OSD map epoch 和 OSD 状态。
- Ceph 管理器的状态。
- 对象网关的状态。
- 放置组映射版本。
- 放置组和池的数量。
- 存储的数据数量和所存储的对象数量。
存储的数据总量。
在启动 Ceph 集群时，您可能会遇到运行状况警告，如
HEALTH_WARN XXX num placement groups stale。等待几分钟，然后再次检查。当存储集群就绪时，ceph health应返回一个如HEALTH_OK的消息。此时，可以开始使用群集。
3.2.4. 监视存储集群事件
您可以使用命令行界面观察 Ceph 存储集群发生的事件。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
流程
登录到 Cephadm shell：
示例
root@host01 ~]# cephadm shell
要监控集群的持续事件，请运行以下命令：
示例
[ceph: root@host01 /]# ceph -w cluster: id: 8c9b0072-67ca-11eb-af06-001a4a0002a0 health: HEALTH_OK services: mon: 2 daemons, quorum Ceph5-2,Ceph5-adm (age 3d) mgr: Ceph5-1.nqikfh(active, since 3w), standbys: Ceph5-adm.meckej osd: 5 osds: 5 up (since 2d), 5 in (since 8w) rgw: 2 daemons active (test_realm.test_zone.Ceph5-2.bfdwcn, test_realm.test_zone.Ceph5-adm.acndrh) data: pools: 11 pools, 273 pgs objects: 459 objects, 32 KiB usage: 2.6 GiB used, 72 GiB / 75 GiB avail pgs: 273 active+clean io: client: 170 B/s rd, 730 KiB/s wr, 0 op/s rd, 729 op/s wr 2021-06-02 15:45:21.655871 osd.0 [INF] 17.71 deep-scrub ok 2021-06-02 15:45:47.880608 osd.1 [INF] 1.0 scrub ok 2021-06-02 15:45:48.865375 osd.1 [INF] 1.3 scrub ok 2021-06-02 15:45:50.866479 osd.1 [INF] 1.4 scrub ok 2021-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 2021-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 2021-06-02 15:45:53.997726 osd.1 [INF] 1.5 scrub ok 2021-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 2021-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 2021-06-02 15:46:06.836430 osd.0 [INF] 17.75 deep-scrub ok 2021-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
3.2.5. Ceph 如何计算数据使用量
used 值反映了使用的实际原始存储量。xxx GB / xxx GB 代表可用的存储（其中较小的数字）和总存储容量。总容量反映了在复制、克隆或快照前存储数据的大小。因此，实际存储的数据量通常会超过名义上的存储量。这是因为 Ceph 会创建数据的副本，进行克隆和快照也需要使用存储。
3.2.6. 了解存储集群用量统计
要检查集群的数据使用量和数据分布在池间，请使用 df 选项。它类似于 Linux df 命令。
如果某些 OSD 标记为 IN，则 ceph df 和 ceph status 命令的输出中的 SIZE/AVAIL/RAW USED 会有所不同。SIZE/AVAIL/RAW USED 从 SIZE （最大磁盘大小）、RAW USE （磁盘上使用的空间）和 AVAIL （所有处于 IN 状态的 OSD）计算。您可以在 ceph osd df tree 命令的输出中看到 SIZE/AVAIL/RAW USED 的总 OSD。
示例
[ceph: root@host01 /]#ceph df --- RAW STORAGE --- CLASS SIZE AVAIL USED RAW USED %RAW USED hdd 5 TiB 2.9 TiB 2.1 TiB 2.1 TiB 42.98 TOTAL 5 TiB 2.9 TiB 2.1 TiB 2.1 TiB 42.98 --- POOLS --- POOL ID PGS STORED OBJECTS USED %USED MAX AVAIL .mgr 1 1 5.3 MiB 3 16 MiB 0 629 GiB .rgw.root 2 32 1.3 KiB 4 48 KiB 0 629 GiB default.rgw.log 3 32 3.6 KiB 209 408 KiB 0 629 GiB default.rgw.control 4 32 0 B 8 0 B 0 629 GiB default.rgw.meta 5 32 1.7 KiB 10 96 KiB 0 629 GiB default.rgw.buckets.index 7 32 5.5 MiB 22 17 MiB 0 629 GiB default.rgw.buckets.data 8 32 807 KiB 3 2.4 MiB 0 629 GiB default.rgw.buckets.non-ec 9 32 1.0 MiB 1 3.1 MiB 0 629 GiB source-ecpool-86 11 32 1.2 TiB 391.13k 2.1 TiB 53.49 1.1 TiB
ceph df detail 命令提供了更多关于其他池统计数据的详细信息，如配额对象、配额字节、压缩状态等。
输出的 RAW STORAGE 部分概述了存储集群用于存储数据的存储量。
- CLASS: OSD 设备的类。
SIZE： 由存储集群管理的存储容量量。
在上例中，如果
SIZE是 90 GiB，它是不包括复制因子（默认为三）的总大小。带有复制因子的可用的总容量为 30 GiB（90 GiB/3）。根据全满比率（默认为 0.85%），最大可用空间为 30 GiB * 0.85 = 25.5 GiBAVAIL： 存储集群中可用空间的数量。
在上例中，如果
SIZE是 90 GiB，而USED空间为 6 GiB，则AVAIL空间为 84 GiB。带有复制因素的总可用空间（默认为 84 GiB/3 = 28 GiB）USED： 用户数据使用的原始存储量。
在上例中，100 MiB 是在考虑了复制因子后的总可用空间。实际可用大小为 33 MiB。
- RAW USED： 用户数据、内部开销或保留容量消耗的原始存储量。
-
% RAW USED： RAW USED 的百分比。使用这个数值以及
full ratio和near full ratio，以确保您没有消耗倒所有的存储集群容量。
输出的 POOLS 部分提供了池列表以及每个池的不利使用情况。本节的输出不会反映副本、克隆或快照的情况。例如，如果您存储 1 MB 的数据的对象，名义的使用量为 1 MB，但实际使用量可能为 3 MB 或更多。具体的实际使用量取决于副本的数量（例如： size = 3）、克隆和快照。
- POOL：池的名称。
- id： 池 ID。
- STORED: 用户存储在池中的实际数据量。这个值会根据(k+M)/K 值、对象副本数以及池统计计算时降级的对象数量更改。
-
OBJECTS: 每个池存储的名义数量。它是
STORED大小 * 复制因素。 - USED: 存储以 KB 为单位的数据数量，除非数字带有 M（megabyte）或 G（gigabytes）。
- %USED: 每个池使用的名义存储的百分比。
MAX AVAIL: 可以写入这个池的数据数量的估计值。它是在第一个 OSD 变为满之前可以使用的数据量。它考虑了 CRUSH map 中跨磁盘的项目分布数据，并使用第一个 OSD 来填充作为目标。
在上例中，
MAX AVAIL为 153.85 MB（没有考虑复制因子，默认为三）。请参阅红帽知识库中的 ceph df MAX AVAIL is incorrect for simple replicated pool 以计算
MAX AVAIL的值。- QUOTA OBJECTS： 配额对象的数量。
- QUOTA BYTES： 配额对象中的字节数。
- USED COMPR： 为压缩数据分配的空间量，包括其压缩数据、分配、复制和擦除编码开销。
- UNDER COMPR: 通过压缩格式传输的数据量，以压缩形式存储有更多益处。
POOLS 部分中的数字是估算的。它们不包括副本数、快照或克隆的数量。因此，USED 和 %USED 数值的总和可能会与输出的 GLOBAL 部分中的 RAW USED 和 %RAW USED 不同。
MAX AVAIL 值是使用复制或退出代码的复杂功能，即将存储映射到设备、这些设备的利用率以及配置的 mon_osd_full_ratio。
其它资源
- 详情请参阅 Ceph 如何计算数据使用量。
- 详情请参阅 了解 OSD 用量统计。
3.2.7. 了解 OSD 使用量统计
使用 ceph osd df 命令查看 OSD 使用率统计。
示例
[ceph: root@host01 /]# 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 的最小和最大变化。
其它资源
- 详情请参阅 Ceph 如何计算数据使用量。
- 详情请参阅 了解 OSD 用量统计。
- 详情请参阅 Red Hat Ceph Storage Storage 策略指南中的 CRUSH Weights。
3.2.8. 检查存储集群状态
您可以从命令行界面查看 Red Hat Ceph Storage 集群的状态。status 子命令或 -s 参数将显示存储集群的当前状态。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
流程
登录到 Cephadm shell：
示例
[root@host01 ~]# cephadm shell
要检查存储集群的状态，请执行以下操作：
示例
[ceph: root@host01 /]# ceph status
或者
示例
[ceph: root@host01 /]# ceph -s
在交互模式中，键入
ceph并按 Enter 键：示例
[ceph: root@host01 /]# ceph ceph> status cluster: id: 499829b4-832f-11eb-8d6d-001a4a000635 health: HEALTH_WARN 1 stray daemon(s) not managed by cephadm 1/3 mons down, quorum host03,host02 too many PGs per OSD (261 > max 250) services: mon: 3 daemons, quorum host03,host02 (age 3d), out of quorum: host01 mgr: host01.hdhzwn(active, since 9d), standbys: host05.eobuuv, host06.wquwpj osd: 12 osds: 11 up (since 2w), 11 in (since 5w) rgw: 2 daemons active (test_realm.test_zone.host04.hgbvnq, test_realm.test_zone.host05.yqqilm) rgw-nfs: 1 daemon active (nfs.foo.host06-rgw) data: pools: 8 pools, 960 pgs objects: 414 objects, 1.0 MiB usage: 5.7 GiB used, 214 GiB / 220 GiB avail pgs: 960 active+clean io: client: 41 KiB/s rd, 0 B/s wr, 41 op/s rd, 27 op/s wr ceph> health HEALTH_WARN 1 stray daemon(s) not managed by cephadm; 1/3 mons down, quorum host03,host02; too many PGs per OSD (261 > max 250) ceph> mon stat e3: 3 mons at {host01=[v2:10.74.255.0:3300/0,v1:10.74.255.0:6789/0],host02=[v2:10.74.249.253:3300/0,v1:10.74.249.253:6789/0],host03=[v2:10.74.251.164:3300/0,v1:10.74.251.164:6789/0]}, election epoch 6688, leader 1 host03, quorum 1,2 host03,host02
3.2.9. 检查 Ceph Monitor 状态
如果存储集群有多个 Ceph Monitor（这是生产环境 Red Hat Ceph Storage 集群的要求），您可以在开始存储集群后检查 Ceph Monitor 仲裁状态，并在执行任何读取或写入数据前检查 Ceph Monitor 仲裁状态。
当运行了多个 Ceph monitor 时，必须存在仲裁。
定期检查 Ceph 监控状态以确保它们正在运行。如果 Ceph Monitor 出现问题，这会防止达成存储集群状态协议，因此会阻止 Ceph 客户端读取和写入数据。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
流程
登录到 Cephadm shell：
示例
[root@host01 ~]# cephadm shell
要显示 Ceph Monitor 映射，请执行以下操作：
示例
[ceph: root@host01 /]# ceph mon stat
或者
示例
[ceph: root@host01 /]# ceph mon dump
要检查存储集群的仲裁状态，请执行以下操作：
[ceph: root@host01 /]# ceph quorum_status -f json-pretty
Ceph 返回仲裁状态。
示例
{ "election_epoch": 6686, "quorum": [ 0, 1, 2 ], "quorum_names": [ "host01", "host03", "host02" ], "quorum_leader_name": "host01", "quorum_age": 424884, "features": { "quorum_con": "4540138297136906239", "quorum_mon": [ "kraken", "luminous", "mimic", "osdmap-prune", "nautilus", "octopus", "pacific", "elector-pinging" ] }, "monmap": { "epoch": 3, "fsid": "499829b4-832f-11eb-8d6d-001a4a000635", "modified": "2021-03-15T04:51:38.621737Z", "created": "2021-03-12T12:35:16.911339Z", "min_mon_release": 16, "min_mon_release_name": "pacific", "election_strategy": 1, "disallowed_leaders: ": "", "stretch_mode": false, "features": { "persistent": [ "kraken", "luminous", "mimic", "osdmap-prune", "nautilus", "octopus", "pacific", "elector-pinging" ], "optional": [] }, "mons": [ { "rank": 0, "name": "host01", "public_addrs": { "addrvec": [ { "type": "v2", "addr": "10.74.255.0:3300", "nonce": 0 }, { "type": "v1", "addr": "10.74.255.0:6789", "nonce": 0 } ] }, "addr": "10.74.255.0:6789/0", "public_addr": "10.74.255.0:6789/0", "priority": 0, "weight": 0, "crush_location": "{}" }, { "rank": 1, "name": "host03", "public_addrs": { "addrvec": [ { "type": "v2", "addr": "10.74.251.164:3300", "nonce": 0 }, { "type": "v1", "addr": "10.74.251.164:6789", "nonce": 0 } ] }, "addr": "10.74.251.164:6789/0", "public_addr": "10.74.251.164:6789/0", "priority": 0, "weight": 0, "crush_location": "{}" }, { "rank": 2, "name": "host02", "public_addrs": { "addrvec": [ { "type": "v2", "addr": "10.74.249.253:3300", "nonce": 0 }, { "type": "v1", "addr": "10.74.249.253:6789", "nonce": 0 } ] }, "addr": "10.74.249.253:6789/0", "public_addr": "10.74.249.253:6789/0", "priority": 0, "weight": 0, "crush_location": "{}" } ] } }
3.2.10. 使用 Ceph 管理 socket
使用管理套接字可以通过 UNIX 套接字文件直接与给定守护进程交互。例如，这个套接字可以：
- 在运行时列出 Ceph 配置
-
在运行时直接设置配置值，而不依赖 Monitor。当 Monitor
停机时，这非常有用。 - 转储历史操作
- 转储操作优先级队列状态
- 在不重启的情况下转储操作
- 转储性能计数器
此外，在对 Ceph monitor 或 OSD 相关的问题进行故障排除时，使用 socket 非常有用。
无论如何，如果守护进程没有运行，在尝试使用管理套接字时会返回以下错误：
Error 111: Connection Refused
管理套接字仅在守护进程正在运行时才可用。当您正确关闭守护进程时，管理套接字会被删除。但是，如果守护进程意外终止，管理套接字可能仍然会被保留。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
流程
登录到 Cephadm shell：
示例
[root@host01 ~]# cephadm shell
使用套接字：
语法
ceph daemon MONITOR_ID COMMAND
替换：
-
守护进程的
MONITOR_ID 带有要运行的命令的
COMMAND。使用help列出给定守护进程的可用命令。查看 Ceph Monitor 的状态：
示例
[ceph: root@host01 /]# ceph daemon mon.host01 help { "add_bootstrap_peer_hint": "add peer address as potential bootstrap peer for cluster bringup", "add_bootstrap_peer_hintv": "add peer address vector as potential bootstrap peer for cluster bringup", "compact": "cause compaction of monitor's leveldb/rocksdb storage", "config diff": "dump diff of current config and default config", "config diff get": "dump diff get <field>: dump diff of current and default config setting <field>", "config get": "config get <field>: get the config value", "config help": "get config setting schema and descriptions", "config set": "config set <field> <val> [<val> ...]: set a config variable", "config show": "dump current config settings", "config unset": "config unset <field>: unset a config variable", "connection scores dump": "show the scores used in connectivity-based elections", "connection scores reset": "reset the scores used in connectivity-based elections", "dump_historic_ops": "dump_historic_ops", "dump_mempools": "get mempool stats", "get_command_descriptions": "list available commands", "git_version": "get git sha1", "heap": "show heap usage info (available only if compiled with tcmalloc)", "help": "list available commands", "injectargs": "inject configuration arguments into running daemon", "log dump": "dump recent log entries to log file", "log flush": "flush log entries to log file", "log reopen": "reopen log file", "mon_status": "report status of monitors", "ops": "show the ops currently in flight", "perf dump": "dump perfcounters value", "perf histogram dump": "dump perf histogram values", "perf histogram schema": "dump perf histogram schema", "perf reset": "perf reset <name>: perf reset all or one perfcounter name", "perf schema": "dump perfcounters schema", "quorum enter": "force monitor back into quorum", "quorum exit": "force monitor out of the quorum", "sessions": "list existing sessions", "smart": "Query health metrics for underlying device", "sync_force": "force sync of and clear monitor store", "version": "get ceph version" }示例
[ceph: root@host01 /]# ceph daemon mon.host01 mon_status { "name": "host01", "rank": 0, "state": "leader", "election_epoch": 120, "quorum": [ 0, 1, 2 ], "quorum_age": 206358, "features": { "required_con": "2449958747317026820", "required_mon": [ "kraken", "luminous", "mimic", "osdmap-prune", "nautilus", "octopus", "pacific", "elector-pinging" ], "quorum_con": "4540138297136906239", "quorum_mon": [ "kraken", "luminous", "mimic", "osdmap-prune", "nautilus", "octopus", "pacific", "elector-pinging" ] }, "outside_quorum": [], "extra_probe_peers": [], "sync_provider": [], "monmap": { "epoch": 3, "fsid": "81a4597a-b711-11eb-8cb8-001a4a000740", "modified": "2021-05-18T05:50:17.782128Z", "created": "2021-05-17T13:13:13.383313Z", "min_mon_release": 16, "min_mon_release_name": "pacific", "election_strategy": 1, "disallowed_leaders: ": "", "stretch_mode": false, "features": { "persistent": [ "kraken", "luminous", "mimic", "osdmap-prune", "nautilus", "octopus", "pacific", "elector-pinging" ], "optional": [] }, "mons": [ { "rank": 0, "name": "host01", "public_addrs": { "addrvec": [ { "type": "v2", "addr": "10.74.249.41:3300", "nonce": 0 }, { "type": "v1", "addr": "10.74.249.41:6789", "nonce": 0 } ] }, "addr": "10.74.249.41:6789/0", "public_addr": "10.74.249.41:6789/0", "priority": 0, "weight": 0, "crush_location": "{}" }, { "rank": 1, "name": "host02", "public_addrs": { "addrvec": [ { "type": "v2", "addr": "10.74.249.55:3300", "nonce": 0 }, { "type": "v1", "addr": "10.74.249.55:6789", "nonce": 0 } ] }, "addr": "10.74.249.55:6789/0", "public_addr": "10.74.249.55:6789/0", "priority": 0, "weight": 0, "crush_location": "{}" }, { "rank": 2, "name": "host03", "public_addrs": { "addrvec": [ { "type": "v2", "addr": "10.74.249.49:3300", "nonce": 0 }, { "type": "v1", "addr": "10.74.249.49:6789", "nonce": 0 } ] }, "addr": "10.74.249.49:6789/0", "public_addr": "10.74.249.49:6789/0", "priority": 0, "weight": 0, "crush_location": "{}" } ] }, "feature_map": { "mon": [ { "features": "0x3f01cfb9fffdffff", "release": "luminous", "num": 1 } ], "osd": [ { "features": "0x3f01cfb9fffdffff", "release": "luminous", "num": 3 } ] }, "stretch_mode": false }
-
守护进程的
或者，使用其套接字文件指定 Ceph 守护进程：
语法
ceph daemon /var/run/ceph/SOCKET_FILE COMMAND
查看名为
osd.2的 Ceph OSD 的状态：示例
[ceph: root@host01 /]# ceph daemon /var/run/ceph/ceph-osd.2.asok status
列出 Ceph 进程的所有套接字文件：
示例
[ceph: root@host01 /]# ls /var/run/ceph
其它资源
- 如需更多信息，请参阅 Red Hat Ceph Storage 故障排除指南。
3.2.11. 了解 Ceph OSD 状态
Ceph OSD 的状态可以是 in 存储集群，或 out 存储集群。它可以是 up 并运行，或 down 并没有运行。如果 Ceph OSD 为 up，它可以在存储集群内，可以在其中读取和写入数据，或者在存储集群外。如果它以前位于存储集群中，并最近从存储集群中移出，Ceph 将开始将放置组迁移到其他 Ceph OSD。如果 Ceph OSD 不在存储集群中，CRUSH 不会将放置组分配到 Ceph OSD。如果 Ceph OSD 是 down，它应该也是 out。
如果 Ceph OSD 处于 down 和 中，则存在问题，而存储集群不处于健康状态。
如果执行诸如 ceph health, ceph -s 或 ceph -w 等命令，您可能会注意到存储集群并不总是回显 HEALTH OK。不要 panic。对于 Ceph OSD，您可以预计在一些预期情况下，存储集群不会 反映 HEALTH OK ：
- 还没有启动存储集群，且没有响应。
- 您刚启动或重启了存储集群，当还没有就绪，因为放置组正在被创建，Ceph OSD 正在进行对等处理。
- 您刚添加或删除 Ceph OSD。
- 您刚修改了存储集群映射。
监控 Ceph OSD 的一个重要方面是，当存储集群启动并正在运行，所有存在于存储集群中的所有 Ceph OSD 的状态为up 并在正常运行。
要查看所有 OSD 是否在运行，请执行：
示例
[ceph: root@host01 /]# ceph osd stat
或者
示例
[ceph: root@host01 /]# ceph osd dump
结果应该显示 map epoch, eNNNN, OSD 的总数量, x, 多少个, y, 是 up, 多少个, z, 是 in:
eNNNN: x osds: y up, z in
如果存在于存储集群中的 Ceph OSD 数量超过了状态为 up 的数量。执行以下命令来标识没有运行的 ceph-osd 守护进程：
示例
[ceph: root@host01 /]# ceph osd tree # id weight type name up/down reweight -1 3 pool default -3 3 rack mainrack -2 3 host osd-host 0 1 osd.0 up 1 1 1 osd.1 up 1 2 1 osd.2 up 1
通过设计好的 CRUSH 层次结构进行搜索的功能可以帮助您更快地识别存储位置对存储集群进行故障排除。
如果 Ceph OSD 为 down，连接到该节点并启动它。您可以使用 Red Hat Storage Console 重启 Ceph OSD 守护进程，或者通过命令行。
语法
systemctl start CEPH_OSD_SERVICE_ID
示例
[root@host01 ~]# systemctl start ceph-499829b4-832f-11eb-8d6d-001a4a000635@osd.6.service
其它资源
- 如需了解更多详细信息，请参阅 Red Hat Ceph Storage Dashboard 指南。
3.3. Ceph 存储集群的低级别监控
作为存储管理员，您可以从低级角度监控 Red Hat Ceph Storage 集群的健康状态。低级监控通常涉及确保 Ceph OSD 正确对等。当发生对等错误时，放置组将处于降级状态。这种降级状态可能是许多不同的事情，如硬件故障、挂起或崩溃的 Ceph 守护进程、网络延迟或完整的站点中断。
3.3.1. 先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
3.3.2. 监控放置组集合
当 CRUSH 分配放置组到 Ceph OSD 时，它会查看池的副本数，并将放置组分配到 Ceph OSD，使得放置组的每个副本分配到不同的 Ceph OSD。例如，如果池需要三个放置组副本，则 CRUSH 可以分别分配给 osd.1、 osd.2 和 osd.3。CRUSH 实际上寻求伪随机放置，这会考虑您在 CRUSH 映射中设置的故障域，因此您很少会在大型集群中看到放置组被分配给最接近的邻居 Ceph OSD。对于包含特定放置组的 Ceph OSD 集合被称为活跃集（Acting Set）。在某些情况下，Acting Set 中的 OSD 为 down，否则无法在放置组中对对象进行服务请求。当出现这些情况时，不需要紧张。常见示例包括：
- 添加或删除 OSD。然后，CRUSH 将放置组重新分配到其他 Ceph OSD，从而改变了活跃集的组成，并使用 "backfill" 进程生成数据的迁移。
-
Ceph OSD 过去为
down并被重启，现在正在恢复。 -
在活跃集合中的一个 Ceph OSD 为
down，或无法服务请求时，另一个 Ceph OSD 会暂时担负其职责。
Ceph 使用 Up Set 处理客户端请求，这是实际处理请求的 Ceph OSD 集合。在大多数情况下，在线集和活跃集是相同的。如果它们不同，则表明 Ceph 正在迁移数据、Ceph OSD 正在恢复，或出现了问题，Ceph 通常会在此类情形中出现带有 "stuck stale" 消息的 HEALTH WARN 状态。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
流程
登录到 Cephadm shell：
示例
[root@host01 ~]# cephadm shell
检索放置组列表：
示例
[ceph: root@host01 /]# ceph pg dump
查看对于一个给定的放置组，哪些 Ceph OSD 在 Acting Set 中或在 Up Set 中：
语法
ceph pg map PG_NUM示例
[ceph: root@host01 /]# ceph pg map 128
注意如果设置与 Up Set 和 Acting 设置不匹配，这可能表明存储集群对自身或存储集群潜在的问题进行负载平衡。
3.3.3. Ceph OSD 对等
在将数据写入放置组之前，它必须处于 active 状态，且应该处于 clean 状态。若要让 Ceph 确定放置组的当前状态，PG 的 Primary OSD（活跃集中的第一个 OSD）与二级和三级 OSD 为对等，以变为放置组的当前状态建立协议。假设有三个 PG 副本的池。
图 3.1. 对等（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 状态。
要查看所有放置组的状态，请执行：
示例
[ceph: root@host01 /]# 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
检索放置组列表：
示例
[ceph: root@host01 /]# ceph pg dump
以 JSON 格式格式化输出并将其保存到文件中：
语法
ceph pg dump -o FILE_NAME --format=json示例
[ceph: root@host01 /]# ceph pg dump -o test --format=json
查询特定放置组：
语法
ceph pg POOL_NUM.PG_ID query
示例
[ceph: root@host01 /]# ceph pg 5.fe query { "snap_trimq": "[]", "snap_trimq_len": 0, "state": "active+clean", "epoch": 2449, "up": [ 3, 8, 10 ], "acting": [ 3, 8, 10 ], "acting_recovery_backfill": [ "3", "8", "10" ], "info": { "pgid": "5.ff", "last_update": "0'0", "last_complete": "0'0", "log_tail": "0'0", "last_user_version": 0, "last_backfill": "MAX", "purged_snaps": [], "history": { "epoch_created": 114, "epoch_pool_created": 82, "last_epoch_started": 2402, "last_interval_started": 2401, "last_epoch_clean": 2402, "last_interval_clean": 2401, "last_epoch_split": 114, "last_epoch_marked_full": 0, "same_up_since": 2401, "same_interval_since": 2401, "same_primary_since": 2086, "last_scrub": "0'0", "last_scrub_stamp": "2021-06-17T01:32:03.763988+0000", "last_deep_scrub": "0'0", "last_deep_scrub_stamp": "2021-06-17T01:32:03.763988+0000", "last_clean_scrub_stamp": "2021-06-17T01:32:03.763988+0000", "prior_readable_until_ub": 0 }, "stats": { "version": "0'0", "reported_seq": "2989", "reported_epoch": "2449", "state": "active+clean", "last_fresh": "2021-06-18T05:16:59.401080+0000", "last_change": "2021-06-17T01:32:03.764162+0000", "last_active": "2021-06-18T05:16:59.401080+0000", ....
其它资源
- 有关快照修剪设置的更多详情，请参阅 Red Hat Ceph Storage Configuration Guide 中的 OSD Object storage daemon configuratopn options 部分的章节 Object Storage Daemon (OSD) configuration options。
3.3.5. 放置组创建状态
在创建池时，将创建您指定的 PG 数量。Ceph 将在创建一个或多个放置组时回显 creating。创建之后，作为 PG Acting 设置一部分的 OSD 将会被对等点。对等点完成后，PG 状态应当为 active+clean，即 Ceph 客户端可以开始写入到 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 的每个放置组标记为 degraded。当 Ceph OSD 重新上线时，Ceph 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 中所有其他对象。
例如，如果在三方副本池中有九个 OSD：如果 OSD 数量 9 停机，分配给 OSD 9 的 PG 会进入降级状态。如果 OSD 9 没有恢复，则会退出存储集群和存储集群会重新平衡。在这种情况下，PG 被降级，然后恢复到 active 状态。
3.3.10. 放置组恢复状态
Ceph 设计为具有故障容错能力，以持续处理硬件和软件问题的规模。当 OSD 为 down 时，其内容可能落后于 PG 中其他副本的当前状态。当 OSD 变为 up，必须更新放置组的内容，以反映当前状态。在该时间段内，OSD 可能会处于 recovering 状态。
恢复并不总是不重要，因为硬件故障可能会导致多个 Ceph OSD 的级联故障。例如，一个机箱中的网络交换机可能会失败，这可能会导致多个主机机器的 OSD 落后于存储集群的当前状态。在错误解决后，每个 OSD 必须恢复。
Ceph 提供了多个设置，用于在新服务请求和恢复数据对象之间平衡资源争用，并将放置组恢复到当前状态。osd recovery delay start 设置允许 OSD 重新启动、重复操作，甚至在开始恢复过程前处理一些重播请求。osd recovery threads 设置限制恢复过程的线程数量，默认为一个线程。osd recovery thread timeout 设置一个线程超时，因为多个 Ceph OSD 失败，会以不同的频率重启和重新对等。osd recovery max active 设置限制了 Ceph OSD 同时工作的恢复请求数量，以防止 Ceph OSD 无法服务。osd recovery max chunk 设置限制了恢复的数据块的大小，以防止网络拥塞。
3.3.11. Back fill 状态
当新的 Ceph OSD 加入存储集群时，libvirt 会将放置组从集群中的 OSD 重新分配到新添加的 Ceph OSD。强制新的 OSD 接受重新分配的放置组，立即对新的 Ceph OSD 造成过量负载。使用放置组回填 OSD 使此过程在后台开始。回填完成后，新 OSD 会在请求就绪时开始提供请求。
在回填操作中，您可能会看到多个状态之一：
-
backfill_wait表示回填操作是待处理，但还没有进行。 -
backfill表示回填操作正在进行 -
back_too_full表示请求回填操作，但可能会因为存储容量不足而无法完成。
当无法回填放置组时，它被视为不完整。
Ceph 提供了多个设置，以管理与将放置组重新分配给 Ceph OSD（特别是新的 Ceph OSD）关联的负载激增。默认情况下，osd_max_backfills 将最大并发回填数量（来自或到一个 Ceph OSD）设置为 10。osd backfill full ratio 可让 Ceph OSD 在 OSD 接近其完整比率时拒绝回填请求，默认为 85%。如果 OSD 拒绝回填请求，osd backfill retry interval 可让 OSD 在 10 秒后重试请求。OSD 也可以将 osd 回填扫描 min 和 osd backfill scan max 设置为管理扫描间隔，默认为 64 和 512。
对于某些工作负载，避免定期恢复并改为使用回填是有益的。由于回填在后台发生，因此这允许 I/O 继续进行 OSD 中的对象。您可以通过将 osd_min_pg_log_entries 选项设置为 1，并将 osd_max_pg_log_entries 选项设置为 2 来强制进行回填，而不是恢复。当这个情况与您的工作负载相符，请联系您的红帽支持团队。
3.3.12. 放置组重新映射状态
当决定服务设置放置组更改时，数据会从旧操作集迁移到新行为集。这可能需要经过一定时间后，新的 Primary OSD 才会处理服务请求。因此，可能需要旧的主系统继续服务请求，直到放置组迁移完成为止。数据迁移完成后，映射将使用新操作集合的 Primary OSD。
3.3.13. 放置组过时状态
虽然 Ceph 使用心跳来确保主机和守护进程正在运行，ceph-osd 守护进程也会在没有及时报告统计数据的情况下变为 stuck 状态。例如，临时网络故障。默认情况下，OSD 守护进程每半秒钟报告其放置组、启动和失败统计，即 0.5，它比心跳阈值更频繁。如果 PG 的执行集合的 Primary OSD 无法报告 monitor，或者其他 OSD 报告了 Primary OSD down，则 monitor 将标记 PG stale。
当您启动存储集群时，通常会看到 stale 状态，直到对等进程完成为止。在存储集群运行一段时间后，如果放置组处于 stale 状态则代表这些放置组的主 OSD 的状态为 down 或者没有向监控器报告放置组统计信息。
3.3.14. 放置组被原位状态
当 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.15. 放置组不完整状态
当内容不完整且对等失败（没有足够完整的 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.16. 识别卡住的放置组
仅仅因为放置组没有处于 active+clean 状态，并不一定代表它存在问题。通常，当 PG 卡住时，Ceph 无法进行自我修复。卡住状态包括：
- Unclean: 放置组包含不会复制所需次数的对象。它们应该是恢复。
-
Inactive ：放置组无法处理读取或写入，因为它们正在等待具有最新数据的 OSD 返回到
up状态。 -
Stale：放置组处于未知状态，因为托管它们的 OSD 在一段时间内未报告到监控集群，并可使用
mon osd report timeout配置。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
流程
要识别卡的放置组，请执行以下操作：
语法
ceph pg dump_stuck {inactive|unclean|stale|undersized|degraded [inactive|unclean|stale|undersized|degraded...]} {<int>}示例
[ceph: root@host01 /]# ceph pg dump_stuck stale OK
3.3.17. 查找对象的位置
Ceph 客户端检索最新的集群映射，并且 CRUSH 算法计算如何将对象映射到放置组，然后计算如何动态将 PG 分配给 OSD。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
流程
要查找对象位置，您需要对象名称和池名称：
语法
ceph osd map POOL_NAME OBJECT_NAME
示例
[ceph: root@host01 /]# ceph osd map mypool myobject
第 4 章 为 Ceph 存储扩展集群
作为存储管理员，您可以通过使用 2 个站点集群进入扩展模式来配置扩展集群。
Red Hat Ceph Storage 能够因为网络和集群而丢失 Ceph OSD，这同样可靠，并在 CRUSH map 中随机分布失败。如果有多个 OSD 关闭，则剩余的 OSD 和 monitor 仍然管理来运行。
但是，这可能不是某些扩展群集配置的最佳解决方案，因为 Ceph 集群的一部分只能使用单一网络组件。这个示例是位于多个数据中心的单个集群，用户希望保持丢失完整数据中心。
标准配置有两个数据中心。其他配置位于云或可用区中。每个站点都包含两个数据副本，复制大小为 4。与主站点相比，第三个站点应具有 tiebreaker 监控器，这可能是虚拟机或高延迟。如果网络连接失败，且两个数据中心仍处于活动状态，这个监控器会选择其中一个站点来恢复数据。
标准 Ceph 配置会保留网络或数据中心的很多故障，永远不会破坏数据一致性。如果您在失败后恢复足够的 Ceph 服务器，它会恢复。如果您丢失了数据中心，但仍然可以组成仲裁，并且具有足够副本的所有可用数据，以满足池的 min_size 或 CRUSH 规则，或者 CRUSH 规则可以再次保持可用性，以满足大小。
没有额外的步骤可以关闭扩展集群。如需更多信息，请参阅 关闭和重新引导 Red Hat Ceph Storage 集群。
扩展集群失败
Red Hat Ceph Storage 永远不会破坏数据完整性和一致性。如果网络故障或节点丢失，并且仍可以恢复服务，Ceph 会自行返回到正常功能。
然而，在有些情况下，即使您有足够的服务器来满足 Ceph 的一致性和大小限制，或者意外无法满足限制。
第一个重要故障类型是由网络不一致造成的。如果存在网络分割，Ceph 可能无法将 OSD 标记为 down，使其从活跃放置组(PG)设置中移除，尽管 Primary OSD 无法复制数据。发生这种情况时，不允许 I/O，因为 Ceph 无法满足其持久性保证。
第二个故障类别是，当您在数据间复制数据时，但约束不足以保证这一点。例如，您可能具有数据中心 A 和 B，CRUSH 规则以三个副本为目标，并将副本放在每个数据中心，min_size 为 2。PG 可能会与站点 A 中的两个副本活跃，站点 B 中没有副本。这意味着，如果您丢失站点 A，则丢失数据，Ceph 无法操作。这种情形很难避免使用标准 CRUSH 规则。
4.1. 存储集群的扩展模式
要配置扩展集群，您必须进入扩展模式。启用扩展模式时，Ceph OSD 仅在数据中心对等点或您指定的其他 CRUSH 存储桶类型时才处于活动状态，假设两者都处于活动状态。池大小从默认的三个增加到四个，每个站点有两个副本。
在扩展模式中，Ceph OSD 仅允许在同一数据中心内连接到监控器。在没有指定位置的情况下，不允许新的 monitor 加入集群。
如果数据中心中的所有 OSD 和 monitor 都无法被访问，则存活数据中心将进入 降级 扩展模式。此问题会发出警告，将 min_size 减少到 1，并允许集群使用剩余的站点的数据访问 活动状态。
degraded 状态也会触发池太小的警告，因为池大小不会改变。但是，一个特殊的扩展模式标志可防止 OSD 在剩余的数据中心中创建额外的副本，因此仍然保留 2 个副本。
当缺少的数据中心再次变为不可访问时，集群进入 恢复 扩展模式。这会更改警告并允许对等点，但仍只需要数据中心中的 OSD，这是整个时间的。
当所有 PG 都处于已知状态且没有降级或不完整时，集群会返回常规扩展模式，结束警告，并将 min_size 恢复到其起始值 2。集群再次要求两个站点对等，而不仅仅是保持整个时间的站点，因此在需要时，可以切换到其他站点。
扩展模式限制
- 输入后无法从扩展模式退出。
- 您不能以扩展模式将纠删代码池与集群一起使用。您不能使用纠删代码池进入扩展模式，在扩展模式处于活跃状态时创建纠删代码池。
- 支持没有多于两个站点的扩展模式。
两个站点的权重应该相同。如果没有，您会收到以下错误：
示例
[ceph: root@host01 /]# ceph mon enable_stretch_mode host05 stretch_rule datacenter Error EINVAL: the 2 datacenter instances in the cluster have differing weights 25947 and 15728 but stretch mode currently requires they be the same!
为在两个站点上达到相同的权重，在两个站点上部署的 Ceph OSD 应该是相等的大小，即第一个站点的存储容量等同于第二个站点的存储容量。
- 虽然它不强制执行，但您应该在每个站点上运行两个 Ceph 监视器，以及一个 tiebreaker，共 5 个。这是因为，在扩展模式中，OSD 只能连接到自己的站点中的监控器。
- 您必须创建自己的 CRUSH 规则，该规则在每个站点上提供两个副本，总计在两个站点上有四个副本。
-
如果您有具有非默认大小或
min_size的现有池，则无法启用扩展模式。 -
由于集群在降级时使用
min_size 1运行，因此您应该仅将扩展模式与 all-flash OSD 搭配使用。这可减少在恢复连接后恢复所需的时间，并最小化数据丢失的可能性。
其它资源
- 有关故障排除步骤 ，请参阅以扩展模式对集群进行故障排除。
4.1.1. 为守护进程设置 crush 位置
在进入扩展模式前，您需要通过将 crush 位置设置为 Red Hat Ceph Storage 集群中的守护进程来准备集群。执行此操作的方法有两种：
- 通过服务配置文件引导集群，其中位置作为部署的一部分添加到主机中。
-
在部署集群后，通过
ceph osd crush add-bucket和ceph osd crush move命令手动设置位置。
方法 1：引导集群
先决条件
- 对节点的根级别访问权限。
流程
如果要引导新存储集群，您可以创建服务配置
.yaml文件，将节点添加到 Red Hat Ceph Storage 集群中，并为应运行服务设置特定的标签：示例
service_type: host addr: host01 hostname: host01 location: root: default datacenter: DC1 labels: - osd - mon - mgr --- service_type: host addr: host02 hostname: host02 location: datacenter: DC1 labels: - osd - mon --- service_type: host addr: host03 hostname: host03 location: datacenter: DC1 labels: - osd - mds - rgw --- service_type: host addr: host04 hostname: host04 location: root: default datacenter: DC2 labels: - osd - mon - mgr --- service_type: host addr: host05 hostname: host05 location: datacenter: DC2 labels: - osd - mon --- service_type: host addr: host06 hostname: host06 location: datacenter: DC2 labels: - osd - mds - rgw --- service_type: host addr: host07 hostname: host07 labels: - mon --- service_type: mon placement: label: "mon" --- service_id: cephfs placement: label: "mds" --- service_type: mgr service_name: mgr placement: label: "mgr" --- service_type: osd service_id: all-available-devices service_name: osd.all-available-devices placement: label: "osd" spec: data_devices: all: true --- service_type: rgw service_id: objectgw service_name: rgw.objectgw placement: count: 2 label: "rgw" spec: rgw_frontend_port: 8080使用
--apply-spec选项引导存储集群：语法
cephadm bootstrap --apply-spec CONFIGURATION_FILE_NAME --mon-ip MONITOR_IP_ADDRESS --ssh-private-key PRIVATE_KEY --ssh-public-key PUBLIC_KEY --registry-url REGISTRY_URL --registry-username USER_NAME --registry-password PASSWORD
示例
[root@host01 ~]# cephadm bootstrap --apply-spec initial-config.yaml --mon-ip 10.10.128.68 --ssh-private-key /home/ceph/.ssh/id_rsa --ssh-public-key /home/ceph/.ssh/id_rsa.pub --registry-url registry.redhat.io --registry-username myuser1 --registry-password mypassword1
重要您可以在
cephadm bootstrap命令中使用不同的命令选项。但是，始终包含--apply-spec选项，以使用服务配置文件并配置主机位置。
其它资源
-
如需有关 Ceph bootstrap 和不同的
cephadm bootstrap命令选项的更多信息，请参阅引导新存储集群。
方法 2：在部署后设置位置
先决条件
- 对节点的根级别访问权限。
流程
添加两个存储桶，您要将非tiebreaker 监视器的位置设置为 CRUSH map，将存储桶类型指定为
datacenter：语法
ceph osd crush add-bucket BUCKET_NAME BUCKET_TYPE
示例
[ceph: root@host01 /]# ceph osd crush add-bucket DC1 datacenter [ceph: root@host01 /]# ceph osd crush add-bucket DC2 datacenter
将存储桶移到
root=default下：语法
ceph osd crush move BUCKET_NAME root=default示例
[ceph: root@host01 /]# ceph osd crush move DC1 root=default [ceph: root@host01 /]# ceph osd crush move DC2 root=default
根据所需的 CRUSH 放置，移动 OSD 主机：
语法
ceph osd crush move HOST datacenter=DATACENTER
示例
[ceph: root@host01 /]# ceph osd crush move host01 datacenter=DC1
4.1.2. 进入扩展模式
新的扩展模式旨在处理两个站点。对于 2 个站点集群，组件可用性中断的风险较低。
先决条件
- 对节点的根级别访问权限。
- crush 位置设置为主机。
流程
设置每个 monitor 的位置，与 CRUSH 映射匹配：
语法
ceph mon set_location HOST datacenter=DATACENTER
示例
[ceph: root@host01 /]# ceph mon set_location host01 datacenter=DC1 [ceph: root@host01 /]# ceph mon set_location host02 datacenter=DC1 [ceph: root@host01 /]# ceph mon set_location host04 datacenter=DC2 [ceph: root@host01 /]# ceph mon set_location host05 datacenter=DC2 [ceph: root@host01 /]# ceph mon set_location host07 datacenter=DC3
生成 CRUSH 规则，它将两个副本放在每个数据中心上：
语法
ceph osd getcrushmap > COMPILED_CRUSHMAP_FILENAME crushtool -d COMPILED_CRUSHMAP_FILENAME -o DECOMPILED_CRUSHMAP_FILENAME
示例
[ceph: root@host01 /]# ceph osd getcrushmap > crush.map.bin [ceph: root@host01 /]# crushtool -d crush.map.bin -o crush.map.txt
编辑已编译的 CRUSH 映射文件，以添加新规则：
示例
rule stretch_rule { id 1 1 type replicated min_size 1 max_size 10 step take DC1 2 step chooseleaf firstn 2 type host step emit step take DC2 3 step chooseleaf firstn 2 type host step emit }注意此规则使集群具有数据中心
DC1的读取权限。因此，所有读取或写入都通过放置在DC1中的 Ceph OSD 进行。如果这不必要，在区间平均分配读取或写入，则 crush 规则如下：
示例
rule stretch_rule { id 1 type replicated min_size 1 max_size 10 step take default step choose firstn 0 type datacenter step chooseleaf firstn 2 type host step emit }在此规则中，数据中心会被随机选择并自动选择。
如需有关
firstn和indep选项的更多信息，请参阅 CRUSH 规则。
注入 CRUSH map，使规则可供集群使用：
语法
crushtool -c DECOMPILED_CRUSHMAP_FILENAME -o COMPILED_CRUSHMAP_FILENAME ceph osd setcrushmap -i COMPILED_CRUSHMAP_FILENAME
示例
[ceph: root@host01 /]# crushtool -c crush.map.txt -o crush2.map.bin [ceph: root@host01 /]# ceph osd setcrushmap -i crush2.map.bin
如果您没有以连接模式运行监控器，请将选择策略设置为
connectivity：示例
[ceph: root@host01 /]# ceph mon set election_strategy connectivity
通过将 tiebreaker monitor 的位置设置为数据中心，进入扩展模式：
语法
ceph mon set_location HOST datacenter=DATACENTER ceph mon enable_stretch_mode HOST stretch_rule datacenter
示例
[ceph: root@host01 /]# ceph mon set_location host07 datacenter=DC3 [ceph: root@host01 /]# ceph mon enable_stretch_mode host07 stretch_rule datacenter
在本例中，monitor
mon.host07是 tiebreaker。重要tiebreaker 监控器的位置应与之前设置非tiebreaker 监视器的数据中心不同。在上例中，它是数据中心
DC3。重要不要将此数据中心添加到 CRUSH map 中，因为它会在尝试进入扩展模式时产生以下错误：
Error EINVAL: there are 3 datacenters in the cluster but stretch mode currently only works with 2!
注意如果要编写自己的工具来部署 Ceph，您可以在引导监视器时使用新的
--set-crush-location选项，而不是运行ceph mon set_location命令。此选项只接受单个bucket=location对，如ceph-mon --set-crush-location 'datacenter=DC1'，它必须与运行enable_stretch_mode命令时指定的存储桶类型匹配。验证扩展模式是否已成功启用：
示例
[ceph: root@host01 /]# ceph osd dump epoch 361 fsid 1234ab78-1234-11ed-b1b1-de456ef0a89d created 2023-01-16T05:47:28.482717+0000 modified 2023-01-17T17:36:50.066183+0000 flags sortbitwise,recovery_deletes,purged_snapdirs,pglog_hardlimit crush_version 31 full_ratio 0.95 backfillfull_ratio 0.92 nearfull_ratio 0.85 require_min_compat_client luminous min_compat_client luminous require_osd_release quincy stretch_mode_enabled true stretch_bucket_count 2 degraded_stretch_mode 0 recovering_stretch_mode 0 stretch_mode_bucket 8
stretch_mode_enabled应设为true。您还可以查看扩展存储桶、扩展模式存储桶的数量，以及扩展模式是否降级或恢复。验证监控器是否位于适当的位置：
示例
[ceph: root@host01 /]# ceph mon dump epoch 19 fsid 1234ab78-1234-11ed-b1b1-de456ef0a89d last_changed 2023-01-17T04:12:05.709475+0000 created 2023-01-16T05:47:25.631684+0000 min_mon_release 16 (pacific) election_strategy: 3 stretch_mode_enabled 1 tiebreaker_mon host07 disallowed_leaders host07 0: [v2:132.224.169.63:3300/0,v1:132.224.169.63:6789/0] mon.host07; crush_location {datacenter=DC3} 1: [v2:220.141.179.34:3300/0,v1:220.141.179.34:6789/0] mon.host04; crush_location {datacenter=DC2} 2: [v2:40.90.220.224:3300/0,v1:40.90.220.224:6789/0] mon.host01; crush_location {datacenter=DC1} 3: [v2:60.140.141.144:3300/0,v1:60.140.141.144:6789/0] mon.host02; crush_location {datacenter=DC1} 4: [v2:186.184.61.92:3300/0,v1:186.184.61.92:6789/0] mon.host05; crush_location {datacenter=DC2} dumped monmap epoch 19您还可以查看哪个 monitor 是 tiebreaker，以及 monitor 选择策略。
其它资源
- 如需有关 监控选择 策略的更多信息，请参阅配置监控选择策略。
4.1.3. 以扩展模式添加 OSD 主机
您可以在扩展模式下添加 Ceph OSD。该流程与在没有启用扩展模式的集群中添加 OSD 主机类似。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 在集群中启用的扩展模式。
- 对节点的根级别访问权限。
流程
列出可用的设备来部署 OSD：
语法
ceph orch device ls [--hostname=HOST_1 HOST_2] [--wide] [--refresh]
示例
[ceph: root@host01 /]# ceph orch device ls
在特定主机或所有可用设备上部署 OSD：
从特定主机上的特定设备创建 OSD：
语法
ceph orch daemon add osd HOST:DEVICE_PATH
示例
[ceph: root@host01 /]# ceph orch daemon add osd host03:/dev/sdb
在任何可用的和未使用的设备上部署 OSD：
重要这个命令会创建并置 WAL 和 DB 设备。如果要创建非并置设备，请不要使用这个命令。
示例
[ceph: root@host01 /]# ceph orch apply osd --all-available-devices
将 OSD 主机移到 CRUSH 存储桶下：
语法
ceph osd crush move HOST datacenter=DATACENTER
示例
[ceph: root@host01 /]# ceph osd crush move host03 datacenter=DC1 [ceph: root@host01 /]# ceph osd crush move host06 datacenter=DC2
注意确保在两个站点中添加相同的拓扑节点。如果主机只在一个站点中添加，则可能会出现问题。
其它资源
- 如需有关 添加 Ceph OSD 的更多信息，请参阅添加 OSD。
第 5 章 覆盖 Ceph 行为
作为存储管理员，您需要了解如何在 Red Hat Ceph Storage 集群中使用覆盖来在运行时更改 Ceph 选项。
5.1. 先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
5.2. 设置和取消设置 Ceph 覆盖选项
您可以通过设置和取消设置 Ceph 选项来覆盖 Ceph 的默认行为。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
流程
要覆盖 Ceph 的默认行为，请使用
ceph osd set命令和您要覆盖的行为：语法
ceph osd set FLAG设置行为后，
ceph health将反映您为集群设定的覆盖。示例
[ceph: root@host01 /]# ceph osd set noout
要覆盖 Ceph 的默认行为，请使用
ceph osd unset命令以及您想要的覆盖。语法
ceph osd unset FLAG示例
[ceph: root@host01 /]# ceph osd unset noout
| 标记 | 描述 |
|---|---|
|
|
防止 OSD 被视为在集群 |
|
|
防止 OSD 被视在集群 |
|
|
防止 OSD 被视为 |
|
|
防止 OSD 被视为 |
|
|
集群已达到其 |
|
|
Ceph 将会停止处理读和写操作，但并不会影响 OSD |
|
| Ceph 将阻止新的回填操作。 |
|
| Ceph 将阻止新的重新平衡操作。 |
|
| Ceph 将阻止新的恢复操作。 |
|
| Ceph 将阻止新的清理操作。 |
|
| Ceph 将阻止新的深度清理操作。 |
|
| Ceph 将禁用正在查找 cold/dirty 对象以清空和驱除的进程。 |
5.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。
第 6 章 Ceph 用户管理
作为存储管理员，您可以通过向 Red Hat Ceph Storage 集群中的对象提供身份验证和访问控制来管理 Ceph 用户。
6.1. 先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 访问 Ceph monitor 或 Ceph 客户端节点。
只要客户端在 Cephadm 范围内，Cephadm 管理 Red Hat Ceph Storage 集群的客户端密钥环。用户不应修改 Cephadm 管理的密钥环，除非需要进行故障排除。
6.2. Ceph 用户管理背景
当 Ceph 在启用身份验证和授权的情况下运行时，您必须指定一个用户名。如果没有指定用户名，Ceph 将使用 client.admin 管理用户作为默认用户名。
或者，您可以使用 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 集群用户在网关守护进程和存储集群间进行通信，但网关具有自己的用户管理功能。
语法
DAEMON_TYPE 'allow CAPABILITY' [DAEMON_TYPE 'allow CAPABILITY']
monitor Caps： 监控功能包括
r、w、x、允许配置集 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 存储集群守护进程类型。
以下条目描述了每个功能。
|
| 守护进程的以前访问设置。 |
|
| 授予用户读取访问权限。需要 monitor 来检索 CRUSH map。 |
|
| 授予用户对对象的写入访问权限。 |
|
|
为用户提供调用类方法（即读写）的能力，并在 monitor 上执行 |
|
|
授予用户调用类读取方法的能力。 |
|
|
授予用户调用类写入方法的能力。 |
|
| 授予用户对特定守护进程或池的读取、写入和执行权限，以及执行 admin 命令的能力。 |
|
| 授予用户作为 OSD 连接到其他 OSD 或监视器的权限。在 OSD 上延迟，使 OSD 能够处理复制心跳流量和状态报告。 |
|
| 授予用户引导 OSD 的权限，以便在引导 OSD 时具有添加密钥的权限。 |
|
| 授予用户对 Ceph 块设备的读写访问权限。 |
|
| 授予用户对 Ceph 块设备的只读访问权限。 |
池
池为 Ceph 客户端定义存储策略，并充当该策略的逻辑分区。
在 Ceph 部署中，创建池来支持不同类型的用例是很常见的。例如，云卷或镜像、对象存储、热存储、冷存储等。将 Ceph 部署为 OpenStack 的后端时，典型的部署会具有卷、镜像、备份和虚拟机以及诸如 client.glance、client.cinder 等用户的池。
命名空间
池中的对象可以与池中的对象关联，与 namespace-a 逻辑组关联。用户对池的访问可以关联到命名空间，以便用户读取和写入仅在命名空间内进行。写入到池中的一个命名空间的对象只能由有权访问该命名空间的用户访问。
目前，命名空间仅适用于在 librados 之上编写的应用。块设备和对象存储等 Ceph 客户端目前不支持此功能。
命名空间的比率是池可以根据用例来计算聚合数据的计算方法，因为每个池创建了一组映射到 OSD 的放置组。如果多个池使用相同的 CRUSH 层次结构和规则集，OSD 性能可能会随着负载增加而降级。
例如，一个池对于每个 OSD 应有大约 100 个 PG。因此，有 1000 个 OSD 的集群对于一个池有 100,000 个 PG。映射到同一 CRUSH 层次结构的每个池将在 exemplary 集群中创建另一个 100,000 个放置组。相反，将对象写入命名空间只是将命名空间与对象名称关联的对象名称与单独池的计算开销相关联。除了为用户或一组用户创建单独的池外，您可以使用命名空间。
目前仅在使用 librados 时才可用。
其它资源
- 有关配置使用身份验证的详细信息，请参阅 Red Hat Ceph Storage 配置指南。
6.3. 管理 Ceph 用户
作为存储管理员，您可以通过创建、修改、删除和导入用户来管理 Ceph 用户。Ceph 客户端用户可以是个人或应用程序，它们使用 Ceph 客户端与红帽 Ceph Storage 集群守护进程交互。
6.3.1. 先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 访问 Ceph monitor 或 Ceph 客户端节点。
6.3.2. 列出 Ceph 用户
您可以使用命令行界面列出存储集群中的用户。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
流程
要列出存储集群中的用户，请执行以下操作：
示例
[ceph: root@host01 /]# ceph auth list installed auth entries: osd.10 key: AQBW7U5gqOsEExAAg/CxSwZ/gSh8iOsDV3iQOA== caps: [mgr] allow profile osd caps: [mon] allow profile osd caps: [osd] allow * osd.11 key: AQBX7U5gtj/JIhAAPsLBNG+SfC2eMVEFkl3vfA== caps: [mgr] allow profile osd caps: [mon] allow profile osd caps: [osd] allow * osd.9 key: AQBV7U5g1XDULhAAKo2tw6ZhH1jki5aVui2v7g== caps: [mgr] allow profile osd caps: [mon] allow profile osd caps: [osd] allow * client.admin key: AQADYEtgFfD3ExAAwH+C1qO7MSLE4TWRfD2g6g== caps: [mds] allow * caps: [mgr] allow * caps: [mon] allow * caps: [osd] allow * client.bootstrap-mds key: AQAHYEtgpbkANBAANqoFlvzEXFwD8oB0w3TF4Q== caps: [mon] allow profile bootstrap-mds client.bootstrap-mgr key: AQAHYEtg3dcANBAAVQf6brq3sxTSrCrPe0pKVQ== caps: [mon] allow profile bootstrap-mgr client.bootstrap-osd key: AQAHYEtgD/QANBAATS9DuP3DbxEl86MTyKEmdw== caps: [mon] allow profile bootstrap-osd client.bootstrap-rbd key: AQAHYEtgjxEBNBAANho25V9tWNNvIKnHknW59A== caps: [mon] allow profile bootstrap-rbd client.bootstrap-rbd-mirror key: AQAHYEtgdE8BNBAAr6rLYxZci0b2hoIgH9GXYw== caps: [mon] allow profile bootstrap-rbd-mirror client.bootstrap-rgw key: AQAHYEtgwGkBNBAAuRzI4WSrnowBhZxr2XtTFg== caps: [mon] allow profile bootstrap-rgw client.crash.host04 key: AQCQYEtgz8lGGhAAy5bJS8VH9fMdxuAZ3CqX5Q== caps: [mgr] profile crash caps: [mon] profile crash client.crash.host02 key: AQDuYUtgqgfdOhAAsyX+Mo35M+HFpURGad7nJA== caps: [mgr] profile crash caps: [mon] profile crash client.crash.host03 key: AQB98E5g5jHZAxAAklWSvmDsh2JaL5G7FvMrrA== caps: [mgr] profile crash caps: [mon] profile crash client.nfs.foo.host03 key: AQCgTk9gm+HvMxAAHbjG+XpdwL6prM/uMcdPdQ== caps: [mon] allow r caps: [osd] allow rw pool=nfs-ganesha namespace=foo client.nfs.foo.host03-rgw key: AQCgTk9g8sJQNhAAPykcoYUuPc7IjubaFx09HQ== caps: [mon] allow r caps: [osd] allow rwx tag rgw *=* client.rgw.test_realm.test_zone.host01.hgbvnq key: AQD5RE9gAQKdCRAAJzxDwD/dJObbInp9J95sXw== caps: [mgr] allow rw caps: [mon] allow * caps: [osd] allow rwx tag rgw *=* client.rgw.test_realm.test_zone.host02.yqqilm key: AQD0RE9gkxA4ExAAFXp3pLJWdIhsyTe2ZR6Ilw== caps: [mgr] allow rw caps: [mon] allow * caps: [osd] allow rwx tag rgw *=* mgr.host01.hdhzwn key: AQAEYEtg3lhIBxAAmHodoIpdvnxK0llWF80ltQ== caps: [mds] allow * caps: [mon] profile mgr caps: [osd] allow * mgr.host02.eobuuv key: AQAn6U5gzUuiABAA2Fed+jPM1xwb4XDYtrQxaQ== caps: [mds] allow * caps: [mon] profile mgr caps: [osd] allow * mgr.host03.wquwpj key: AQAd6U5gIzWsLBAAbOKUKZlUcAVe9kBLfajMKw== caps: [mds] allow * caps: [mon] profile mgr caps: [osd] allow *
用户使用 TYPE.ID 的形式代表，例如 osd.0 代表一个用户，类型为 osd，ID 是 0；client.admin 是一个用户，类型是 client，ID 为 admin，这是默认的 client.admin 用户。另请注意，每个条目都有一个 key: VALUE 条目，以及一个或多个 caps: 条目。
您可以将 -o FILE_NAME 选项与 ceph auth list 一起使用，以将输出保存到文件中。
6.3.3. 显示 Ceph 用户信息
您可以使用命令行界面显示 Ceph 的用户信息。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
流程
要检索特定用户、密钥和功能，请执行以下操作：
语法
ceph auth export TYPE.ID
示例
[ceph: root@host01 /]# ceph auth export mgr.host02.eobuuv
您也可以使用
-o FILE_NAME选项。语法
ceph auth export TYPE.ID -o FILE_NAME
示例
[ceph: root@host01 /]# ceph auth export osd.9 -o filename export auth(key=AQBV7U5g1XDULhAAKo2tw6ZhH1jki5aVui2v7g==)
auth export 命令与 auth get 相同，但也打印出内部 auid，但与最终用户无关。
6.3.4. 添加新的 Ceph 用户
添加用户会创建一个用户名，即 TYPE.ID、一个 secret key 和您用于创建用户的命令中包含的任何功能。
用户密钥可让用户与 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 权限通常仅限于访问特定池。
[ceph: root@host01 /]# ceph auth add client.john mon 'allow r' osd 'allow rw pool=mypool' [ceph: root@host01 /]# ceph auth get-or-create client.paul mon 'allow r' osd 'allow rw pool=mypool' [ceph: root@host01 /]# ceph auth get-or-create client.george mon 'allow r' osd 'allow rw pool=mypool' -o george.keyring [ceph: root@host01 /]# ceph auth get-or-create-key client.ringo mon 'allow r' osd 'allow rw pool=mypool' -o ringo.key
如果您为用户提供 OSD 的功能，但没有限制特定池的访问权限，则该用户将能够访问集群中的所有池！
6.3.5. 修改 Ceph 用户
ceph auth caps 命令允许您指定用户并更改用户的能力。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
流程
要添加能力，请使用表单：
语法
ceph auth caps USERTYPE.USERID DAEMON 'allow [r|w|x|*|...] [pool=POOL_NAME] [namespace=NAMESPACE_NAME]'
示例
[ceph: root@host01 /]# ceph auth caps client.john mon 'allow r' osd 'allow rw pool=mypool' [ceph: root@host01 /]# ceph auth caps client.paul mon 'allow rw' osd 'allow rwx pool=mypool' [ceph: root@host01 /]# ceph auth caps client.brian-manager mon 'allow *' osd 'allow *'
要删除功能，您可以重置能力。如果您希望用户无法访问之前设置的特定守护进程，请指定空字符串：
示例
[ceph: root@host01 /]# ceph auth caps client.ringo mon ' ' osd ' '
其它资源
- 如需更多与能力能相关的信息，请参阅授权能力。
6.3.6. 删除 Ceph 用户
您可以使用命令行界面从 Ceph 存储集群中删除用户。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
流程
要删除用户，请使用
ceph auth del:语法
ceph auth del TYPE.ID
示例
[ceph: root@host01 /]# ceph auth del osd.6
6.3.7. 输出 Ceph 用户密钥
您可以使用命令行界面显示 Ceph 用户的密钥信息。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
流程
要将用户的验证密钥输出到标准输出，请执行以下操作：
语法
ceph auth print-key TYPE.ID
示例
[ceph: root@host01 /]# ceph auth print-key osd.6 AQBQ7U5gAry3JRAA3NoPrqBBThpFMcRL6Sr+5w==[ceph: root@host01 /]#
当您需要使用用户的密钥填充客户端软件时，打印用户的密钥会很有用，例如
libvirt。语法
mount -t ceph HOSTNAME:/MOUNT_POINT -o name=client.user,secret=
ceph auth print-key client.user示例
[ceph: root@host01 /]# mount -t ceph host02:/ceph -o name=client.user,secret=`ceph auth print-key client.user`
第 7 章 ceph-volume 工具
作为存储管理员，您可以使用 ceph-volume 实用程序准备、列出、创建、激活、停用、批量、触发器、zap 和迁移 Ceph OSD。ceph-volume 实用程序是一个单一用途的命令行工具，用于将逻辑卷部署为 OSD。它使用插件类型框架来部署具有不同设备技术的 OSD。ceph-volume 实用程序遵循 ceph-disk 实用程序的类似工作流，用于部署 OSD，具有可预测的、可靠的准备、激活和启动 OSD 的方法。目前，ceph-volume 实用程序只支持 lvm 插件，计划以后支持其他技术。
ceph-disk 命令已弃用。
7.1. 先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
7.2. Ceph 卷 lvm 插件
通过使用 LVM 标签，lvm 子命令可以通过查询与 OSD 关联的设备来存储和重新发现它们，以便可以激活它们。这包括对基于 lvm 的技术（如 dm-cache ）的支持。
使用 ceph-volume 时，dm-cache 的使用是透明的，并像逻辑卷一样对待 dm-cache。使用 dm-cache 时性能提升和丢失将取决于特定工作负载。通常，随机和顺序读取会在较小的块大小中看到性能增加。对于大的块大小，随机和顺序写入的性能会降低。
要使用 LVM 插件，请在 cephadm shell 中将 lvm 作为子命令添加到 ceph-volume 命令：
[ceph: root@host01 /]# ceph-volume lvm
以下是 lvm 子命令：
-
prepare- 格式化 LVM 设备并将其与 OSD 关联。 -
激活- 发现并挂载与 OSD ID 关联的 LVM 设备，并启动 Ceph OSD。 -
list- 列出与 Ceph 关联的逻辑卷和设备。 -
batch- 通过最少的交互为多 OSD 置备自动设置设备大小。 -
deactivate- 取消激活 OSD。 -
create- 从 LVM 设备创建新 OSD。 -
trigger- 激活 OSD 的 systemd 帮助程序。 -
zap- 从逻辑卷或分区中删除所有数据和文件系统。 -
migrate- 将 BlueFS 数据迁移到另一个 LVM 设备。 -
new-wal- 为指定逻辑卷上的 OSD 分配新的 WAL 卷。 -
new-db- 在指定逻辑卷中为 OSD 分配新的 DB 卷。
create 子命令将 prepare 和 activate 子命令合并到一个子命令中。
其它资源
-
详情请查看
create子命令 部分。
7.3. 为什么 ceph-volume 取代了 ceph-disk？
以前的 Red Hat Ceph Storage 版本使用 ceph-disk 实用程序来准备、激活和创建 OSD。从 Red Hat Ceph Storage 5 开始，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 中，以独特的方式标记设备，以如下方式回答问题：
-
此设备是否为
日志？ - 该设备是否是加密的数据分区？
- 设备是否部分准备了吗？
为解决这些问题，ceph-disk 使用 UDEV 规则与 GUID 匹配。
使用 ceph-disk 有什么缺点？
使用 UDEV 规则调用 ceph-disk 可能会导致在 ceph-disk systemd 单元和 ceph-disk 间的相互往来。整个过程非常不可靠且消耗时间，可能会导致 OSD 在节点启动过程中根本不会出现。此外，由于 UDEV 的异步行为，很难调试甚至复制这些问题。
由于 ceph-disk 只能用于 GPT 分区，所以它不支持其他技术，如逻辑卷管理器(LVM)卷或类似的设备映射器设备。
为确保 GPT 分区能与设备发现工作流正常工作，ceph-disk 需要大量特殊的标志。此外，这些分区需要设备完全归 Ceph 所有。
7.4. 使用 ceph-volume准备 Ceph OSD
prepare 子命令准备了 OSD 后端对象存储，并为 OSD 数据和日志消耗逻辑卷(LV)。除了使用 LVM 添加一些额外元数据标签外，它不会修改逻辑卷。这些标签使卷更容易发现，它们也会将卷识别为 Ceph Storage 集群的一部分，以及存储集群中这些卷的角色。
BlueStore OSD 后端支持以下配置：
-
块设备，
block.wal设备和block.db设备 -
块设备和
block.wal设备 -
块设备和
block.db设备 - 单个块设备
prepare 子命令接受整个设备或分区，或者用于 块 的逻辑卷。
先决条件
- OSD 节点的根级别访问权限。
- （可选）创建逻辑卷。如果您提供到物理设备的路径，子命令会将设备转换为逻辑卷。这个方法简单，但您不能配置或更改逻辑卷的创建方式。
流程
提取 Ceph 密钥环：
语法
ceph auth get client.ID -o ceph.client.ID.keyring
示例
[ceph: root@host01 /]# ceph auth get client.bootstrap-osd -o /var/lib/ceph/bootstrap-osd/ceph.keyring
准备 LVM 卷：
语法
ceph-volume lvm prepare --bluestore --data VOLUME_GROUP/LOGICAL_VOLUME
示例
[ceph: root@host01 /]# ceph-volume lvm prepare --bluestore --data example_vg/data_lv
另外，如果要为 RocksDB 使用单独的设备，请指定
--block.db和--block.wal选项：语法
ceph-volume lvm prepare --bluestore --block.db BLOCK_DB_DEVICE --block.wal BLOCK_WAL_DEVICE --data DATA_DEVICE
示例
[ceph: root@host01 /]# ceph-volume lvm prepare --bluestore --block.db /dev/sda --block.wal /dev/sdb --data /dev/sdc
另外，要加密数据，请使用
--dmcrypt标志：语法
ceph-volume lvm prepare --bluestore --dmcrypt --data VOLUME_GROUP/LOGICAL_VOLUME
示例
[ceph: root@host01 /]# ceph-volume lvm prepare --bluestore --dmcrypt --data example_vg/data_lv
其它资源
- 如需更多详细信息，请参阅 Red Hat Ceph Storage 管理指南中的使用 'ceph-volume' 激活 Ceph OSD。
- 如需更多详细信息，请参阅 Red Hat Ceph Storage 管理指南中的使用 'ceph-volume' 创建 Ceph OSD。
7.5. 使用 ceph-volume列出设备
您可以使用 ceph-volume lvm list 子命令列出与 Ceph 集群关联的逻辑卷和设备，只要它们包含足够的元数据来允许该发现。输出会根据与设备关联的 OSD ID 进行分组。对于逻辑卷，设备密钥 会填充到与逻辑卷关联的物理设备。
在某些情况下，ceph -s 命令的输出会显示以下出错信息：
1 devices have fault light turned on
在这种情况下，您可以使用 ceph device ls-lights 命令列出设备，该命令详细介绍了设备上的信息。根据信息，您可以关闭该设备的光盘。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 对 Ceph OSD 节点的 root 级别访问权限。
流程
列出 Ceph 集群中的设备：
示例
[ceph: root@host01 /]# ceph-volume lvm list ====== osd.6 ======= [block] /dev/ceph-83909f70-95e9-4273-880e-5851612cbe53/osd-block-7ce687d9-07e7-4f8f-a34e-d1b0efb89920 block device /dev/ceph-83909f70-95e9-4273-880e-5851612cbe53/osd-block-7ce687d9-07e7-4f8f-a34e-d1b0efb89920 block uuid 4d7gzX-Nzxp-UUG0-bNxQ-Jacr-l0mP-IPD8cX cephx lockbox secret cluster fsid 1ca9f6a8-d036-11ec-8263-fa163ee967ad cluster name ceph crush device class None encrypted 0 osd fsid 7ce687d9-07e7-4f8f-a34e-d1b0efb89920 osd id 6 osdspec affinity all-available-devices type block vdo 0 devices /dev/vdc可选：使用 lights 列出存储集群中的设备：
示例
[ceph: root@host01 /]# ceph device ls-lights { "fault": [ "SEAGATE_ST12000NM002G_ZL2KTGCK0000C149" ], "ident": [] }可选：关闭该设备中的打印机：
语法
ceph device light off DEVICE_NAME FAULT/INDENT --force
示例
[ceph: root@host01 /]# ceph device light off SEAGATE_ST12000NM002G_ZL2KTGCK0000C149 fault --force
7.6. 使用 ceph-volume激活 Ceph OSD
激活过程在引导时启用 systemd 单元，允许启用和挂载正确的 OSD 标识符及其 UUID。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 对 Ceph OSD 节点的 root 级别访问权限。
-
Ceph OSD 由
ceph-volume实用程序准备。
流程
从 OSD 节点获取 OSD ID 和 OSD FSID：
[ceph: root@host01 /]# ceph-volume lvm list
激活 OSD：
语法
ceph-volume lvm activate --bluestore OSD_ID OSD_FSID
示例
[ceph: root@host01 /]# ceph-volume lvm activate --bluestore 10 7ce687d9-07e7-4f8f-a34e-d1b0efb89920
要激活为激活准备的所有 OSD，请使用
--all选项：示例
[ceph: root@host01 /]# ceph-volume lvm activate --all
另外，您还可以使用
trigger子命令。此命令不能直接使用，并由systemd使用，以便它将输入代理到ceph-volume lvm activate。这会解析来自 systemd 和启动的元数据，并检测与 OSD 关联的 UUID 和 ID。语法
ceph-volume lvm trigger SYSTEMD_DATA此处的 SYSTEMD_DATA 是 OSD_ID-OSD_FSID 格式。
示例
[ceph: root@host01 /]# ceph-volume lvm trigger 10 7ce687d9-07e7-4f8f-a34e-d1b0efb89920
其它资源
- 如需更多详细信息，请参阅 Red Hat Ceph Storage 管理指南中的使用 'ceph-volume' 准备 Ceph OSD。
- 如需更多详细信息，请参阅 Red Hat Ceph Storage 管理指南中的使用 'ceph-volume' 创建 Ceph OSD。
7.7. 使用 ceph-volume取消激活 Ceph OSD
您可以使用 ceph-volume lvm 子命令停用 Ceph OSD。这个子命令会删除卷组和逻辑卷。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 对 Ceph OSD 节点的 root 级别访问权限。
-
Ceph OSD 通过
ceph-volume实用程序激活。
流程
从 OSD 节点获取 OSD ID：
[ceph: root@host01 /]# ceph-volume lvm list
取消激活 OSD：
语法
ceph-volume lvm deactivate OSD_ID示例
[ceph: root@host01 /]# ceph-volume lvm deactivate 16
其它资源
- 如需更多详细信息，请参阅 Red Hat Ceph Storage 管理指南中的使用 'ceph-volume' 激活 Ceph OSD。
- 如需更多详细信息，请参阅 Red Hat Ceph Storage 管理指南中的使用 'ceph-volume' 准备 Ceph OSD。
- 如需更多详细信息，请参阅 Red Hat Ceph Storage 管理指南中的使用 'ceph-volume' 创建 Ceph OSD。
7.8. 使用 ceph-volume创建 Ceph OSD
create 子命令调用 prepare 子命令，然后调用 activate 子命令。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 对 Ceph OSD 节点的 root 级别访问权限。
如果您希望对创建过程拥有更多控制，可以单独使用 prepare 和 activate 子命令来创建 OSD，而不必使用 create。您可以使用两个子命令逐渐将新 OSD 引入到存储集群中，同时避免重新平衡大量数据。这两种方法的工作方式相同，唯一的不同是使用 create 子命令会使 OSD 在完成后立即变为 up 和 in。
流程
要创建新 OSD，请执行以下操作：
语法
ceph-volume lvm create --bluestore --data VOLUME_GROUP/LOGICAL_VOLUME
示例
[root@osd ~]# ceph-volume lvm create --bluestore --data example_vg/data_lv
其它资源
- 如需更多详细信息，请参阅 Red Hat Ceph Storage 管理指南中的使用 'ceph-volume' 准备 Ceph OSD。
- 如需更多详细信息，请参阅 Red Hat Ceph Storage 管理指南中的使用 'ceph-volume' 激活 Ceph OSD。
7.9. 迁移 BlueFS 数据
您可以使用 migrate LVM 子命令将 BlueStore 文件系统(BlueFS)数据（即 RocksDB 数据）迁移到目标卷。源卷（除主卷）被成功删除。
LVM 卷主要用于目标。
新卷附加到 OSD，替换其中一个源驱动器。
以下是 LVM 卷的放置规则：
- 如果源列表有 DB 或 WAL 卷，则目标设备会替换它。
-
如果源列表仅具有较慢的卷，则需要使用
new-db或new-wal命令显式分配。
new-db 和 new-wal 命令分别将给定逻辑卷作为 DB 或 WAL 卷附加到给定的 OSD。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 对 Ceph OSD 节点的 root 级别访问权限。
-
Ceph OSD 由
ceph-volume实用程序准备。 - 创建卷组和逻辑卷。
流程
登录到
cephadmshell：示例
[root@host01 ~]# cephadm shell
停止需要添加 DB 或 WAL 设备的 OSD：
示例
[ceph: root@host01 /]# ceph orch daemon stop osd.1
将新设备挂载到容器：
示例
[root@host01 ~]# cephadm shell --mount /var/lib/ceph/72436d46-ca06-11ec-9809-ac1f6b5635ee/osd.1:/var/lib/ceph/osd/ceph-1
将给定的逻辑卷作为 DB/WAL 设备附加到 OSD 中：
注意如果 OSD 附加了 DB，则此命令会失败。
语法
ceph-volume lvm new-db --osd-id OSD_ID --osd-fsid OSD_FSID --target VOLUME_GROUP_NAME/LOGICAL_VOLUME_NAME
示例
[ceph: root@host01 /]# ceph-volume lvm new-db --osd-id 1 --osd-fsid 7ce687d9-07e7-4f8f-a34e-d1b0efb89921 --target vgname/new_db [ceph: root@host01 /]# ceph-volume lvm new-wal --osd-id 1 --osd-fsid 7ce687d9-07e7-4f8f-a34e-d1b0efb89921 --target vgname/new_wal
您可以使用以下方法迁移 BlueFS 数据：
将 BlueFS 数据从主设备移动到已附加到 DB 的 LV：
语法
ceph-volume lvm migrate --osd-id OSD_ID --osd-fsid OSD_UUID --from data --target VOLUME_GROUP_NAME/LOGICAL_VOLUME_NAME
示例
[ceph: root@host01 /]# ceph-volume lvm migrate --osd-id 1 --osd-fsid 0263644D-0BF1-4D6D-BC34-28BD98AE3BC8 --from data --target vgname/db
将 BlueFS 数据从共享主设备移动到 LV，应该作为新数据库附加：
语法
ceph-volume lvm migrate --osd-id OSD_ID --osd-fsid OSD_UUID --from data --target VOLUME_GROUP_NAME/LOGICAL_VOLUME_NAME
示例
[ceph: root@host01 /]# ceph-volume lvm migrate --osd-id 1 --osd-fsid 0263644D-0BF1-4D6D-BC34-28BD98AE3BC8 --from data --target vgname/new_db
将 BlueFS 数据从 DB 设备移到新 LV，并替换 DB 设备：
语法
ceph-volume lvm migrate --osd-id OSD_ID --osd-fsid OSD_UUID --from db --target VOLUME_GROUP_NAME/LOGICAL_VOLUME_NAME
示例
[ceph: root@host01 /]# ceph-volume lvm migrate --osd-id 1 --osd-fsid 0263644D-0BF1-4D6D-BC34-28BD98AE3BC8 --from db --target vgname/new_db
将 BlueFS 数据从主设备和 DB 设备移动到新 LV，并替换 DB 设备：
语法
ceph-volume lvm migrate --osd-id OSD_ID --osd-fsid OSD_UUID --from data db --target VOLUME_GROUP_NAME/LOGICAL_VOLUME_NAME
示例
[ceph: root@host01 /]# ceph-volume lvm migrate --osd-id 1 --osd-fsid 0263644D-0BF1-4D6D-BC34-28BD98AE3BC8 --from data db --target vgname/new_db
将 BlueFS 数据从 main、DB 和 WAL 设备移到新的 LV，删除 WAL 设备并替换 DB 设备：
语法
ceph-volume lvm migrate --osd-id OSD_ID --osd-fsid OSD_UUID --from data db wal --target VOLUME_GROUP_NAME/LOGICAL_VOLUME_NAME
示例
[ceph: root@host01 /]# ceph-volume lvm migrate --osd-id 1 --osd-fsid 0263644D-0BF1-4D6D-BC34-28BD98AE3BC8 --from data db --target vgname/new_db
将 BlueFS 数据从 main、DB 和 WAL 设备移动到主设备中，删除 WAL 和 DB 设备：
语法
ceph-volume lvm migrate --osd-id OSD_ID --osd-fsid OSD_UUID --from db wal --target VOLUME_GROUP_NAME/LOGICAL_VOLUME_NAME
示例
[ceph: root@host01 /]# ceph-volume lvm migrate --osd-id 1 --osd-fsid 0263644D-0BF1-4D6D-BC34-28BD98AE3BC8 --from db wal --target vgname/data
7.10. 扩展 BlueFS DB 设备
您可以扩展 BlueStore 文件系统(BlueFS)数据的存储，这是 ceph-volume 创建的 OSD 的 RocksDB 数据。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
-
Ceph OSD 由
ceph-volume实用程序准备。 - 创建卷组和逻辑卷。
在部署 OSD 的主机上运行这些步骤。
流程
可选：在
cephadmshell 中，列出 Red Hat Ceph Storage 集群中的设备。示例
[ceph: root@host01 /]# ceph-volume lvm list ====== osd.3 ======= [db] /dev/db-test/db1 block device /dev/test/lv1 block uuid N5zoix-FePe-uExe-UngY-D9YG-BMs0-1tTDyB cephx lockbox secret cluster fsid 1a6112da-ed05-11ee-bacd-525400565cda cluster name ceph crush device class db device /dev/db-test/db1 db uuid 1TUaDY-3mEt-fReP-cyB2-JyZ1-oUPa-hKPfo6 encrypted 0 osd fsid 94ff742c-7bfd-4fb5-8dc4-843d10ac6731 osd id 3 osdspec affinity None type db vdo 0 devices /dev/vdh [block] /dev/test/lv1 block device /dev/test/lv1 block uuid N5zoix-FePe-uExe-UngY-D9YG-BMs0-1tTDyB cephx lockbox secret cluster fsid 1a6112da-ed05-11ee-bacd-525400565cda cluster name ceph crush device class db device /dev/db-test/db1 db uuid 1TUaDY-3mEt-fReP-cyB2-JyZ1-oUPa-hKPfo6 encrypted 0 osd fsid 94ff742c-7bfd-4fb5-8dc4-843d10ac6731 osd id 3 osdspec affinity None type block vdo 0 devices /dev/vdg获取卷组信息：
示例
[root@host01 ~]# vgs VG #PV #LV #SN Attr VSize VFree db-test 1 1 0 wz--n- <200.00g <160.00g test 1 1 0 wz--n- <200.00g <170.00g
停止 Ceph OSD 服务：
示例
[root@host01 ~]# systemctl stop host01a6112da-ed05-11ee-bacd-525400565cda@osd.3.service
重新定义、缩小并扩展逻辑卷：
示例
[root@host01 ~]# lvresize -l 100%FREE /dev/db-test/db1 Size of logical volume db-test/db1 changed from 40.00 GiB (10240 extents) to <160.00 GiB (40959 extents). Logical volume db-test/db1 successfully resized.
启动
cephadmshell：语法
cephadm shell -m /var/lib/ceph/CLUSTER_FSID/osd.OSD_ID:/var/lib/ceph/osd/ceph-OSD_ID:z
示例
[root@host01 ~]# cephadm shell -m /var/lib/ceph/1a6112da-ed05-11ee-bacd-525400565cda/osd.3:/var/lib/ceph/osd/ceph-3:z
ceph-bluestore-tool需要从cephadmshell 容器中访问 BlueStore 数据，因此必须绑定挂载。使用-m选项使 BlueStore 数据可用。在扩展前检查 Rocks DB 的大小：
语法
ceph-bluestore-tool show-label --path OSD_DIRECTORY_PATH示例
[ceph: root@host01 /]# ceph-bluestore-tool show-label --path /var/lib/ceph/osd/ceph-3/ inferring bluefs devices from bluestore path { "/var/lib/ceph/osd/ceph-3/block": { "osd_uuid": "94ff742c-7bfd-4fb5-8dc4-843d10ac6731", "size": 32212254720, "btime": "2024-04-03T08:34:12.742848+0000", "description": "main", "bfm_blocks": "7864320", "bfm_blocks_per_key": "128", "bfm_bytes_per_block": "4096", "bfm_size": "32212254720", "bluefs": "1", "ceph_fsid": "1a6112da-ed05-11ee-bacd-525400565cda", "ceph_version_when_created": "ceph version 19.0.0-2493-gd82c9aa1 (d82c9aa17f09785fe698d262f9601d87bb79f962) squid (dev)", "created_at": "2024-04-03T08:34:15.637253Z", "elastic_shared_blobs": "1", "kv_backend": "rocksdb", "magic": "ceph osd volume v026", "mkfs_done": "yes", "osd_key": "AQCEFA1m9xuwABAAwKEHkASVbgB1GVt5jYC2Sg==", "osdspec_affinity": "None", "ready": "ready", "require_osd_release": "19", "whoami": "3" }, "/var/lib/ceph/osd/ceph-3/block.db": { "osd_uuid": "94ff742c-7bfd-4fb5-8dc4-843d10ac6731", "size": 40794497536, "btime": "2024-04-03T08:34:12.748816+0000", "description": "bluefs db" } }扩展 BlueStore 设备：
语法
ceph-bluestore-tool bluefs-bdev-expand --path OSD_DIRECTORY_PATH示例
[ceph: root@host01 /]# ceph-bluestore-tool bluefs-bdev-expand --path /var/lib/ceph/osd/ceph-3/ inferring bluefs devices from bluestore path 1 : device size 0x27ffbfe000 : using 0x2300000(35 MiB) 2 : device size 0x780000000 : using 0x52000(328 KiB) Expanding DB/WAL... 1 : expanding to 0x171794497536 1 : size label updated to 171794497536
验证
block.db是否已扩展：语法
ceph-bluestore-tool show-label --path OSD_DIRECTORY_PATH示例
[ceph: root@host01 /]# ceph-bluestore-tool show-label --path /var/lib/ceph/osd/ceph-3/ inferring bluefs devices from bluestore path { "/var/lib/ceph/osd/ceph-3/block": { "osd_uuid": "94ff742c-7bfd-4fb5-8dc4-843d10ac6731", "size": 32212254720, "btime": "2024-04-03T08:34:12.742848+0000", "description": "main", "bfm_blocks": "7864320", "bfm_blocks_per_key": "128", "bfm_bytes_per_block": "4096", "bfm_size": "32212254720", "bluefs": "1", "ceph_fsid": "1a6112da-ed05-11ee-bacd-525400565cda", "ceph_version_when_created": "ceph version 19.0.0-2493-gd82c9aa1 (d82c9aa17f09785fe698d262f9601d87bb79f962) squid (dev)", "created_at": "2024-04-03T08:34:15.637253Z", "elastic_shared_blobs": "1", "kv_backend": "rocksdb", "magic": "ceph osd volume v026", "mkfs_done": "yes", "osd_key": "AQCEFA1m9xuwABAAwKEHkASVbgB1GVt5jYC2Sg==", "osdspec_affinity": "None", "ready": "ready", "require_osd_release": "19", "whoami": "3" }, "/var/lib/ceph/osd/ceph-3/block.db": { "osd_uuid": "94ff742c-7bfd-4fb5-8dc4-843d10ac6731", "size": 171794497536, "btime": "2024-04-03T08:34:12.748816+0000", "description": "bluefs db" } }退出 shell 并重启 OSD：
示例
[root@host01 ~]# systemctl start host01a6112da-ed05-11ee-bacd-525400565cda@osd.3.service osd.3 host01 running (15s) 0s ago 13m 46.9M 4096M 19.0.0-2493-gd82c9aa1 3714003597ec 02150b3b6877
7.11. 使用 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 级别访问权限。
流程
在多个驱动器上创建 OSD：
语法
ceph-volume lvm batch --bluestore PATH_TO_DEVICE [PATH_TO_DEVICE]
示例
[ceph: root@host01 /]# ceph-volume lvm batch --bluestore /dev/sda /dev/sdb /dev/nvme0n1
其它资源
- 如需更多详细信息，请参阅 Red Hat Ceph Storage 管理指南中的使用 'ceph-volume' 创建 Ceph OSD。
7.12. 使用 ceph-volume打包数据
zap 子命令从逻辑卷或分区中删除所有数据和文件系统。
您可以使用 zap 子命令来 zap 逻辑卷、分区或 Ceph OSD 使用的原始设备来重复使用。删除给定逻辑卷或分区上的任何文件系统都会被删除，且所有数据都会被清除。
另外，您还可以使用 --destroy 标志完成逻辑卷、分区或者物理设备删除。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 对 Ceph OSD 节点的 root 级别访问权限。
流程
zap 逻辑卷：
语法
ceph-volume lvm zap VOLUME_GROUP_NAME/LOGICAL_VOLUME_NAME [--destroy]
示例
[ceph: root@host01 /]# ceph-volume lvm zap osd-vg/data-lv
zap 分区：
语法
ceph-volume lvm zap DEVICE_PATH_PARTITION [--destroy]示例
[ceph: root@host01 /]# ceph-volume lvm zap /dev/sdc1
zap 原始设备：
语法
ceph-volume lvm zap DEVICE_PATH --destroy示例
[ceph: root@host01 /]# ceph-volume lvm zap /dev/sdc --destroy
清除具有 OSD ID 的多个设备：
语法
ceph-volume lvm zap --destroy --osd-id OSD_ID示例
[ceph: root@host01 /]# ceph-volume lvm zap --destroy --osd-id 16
注意所有相对设备都是 zapped。
清除带有 FSID 的 OSD：
语法
ceph-volume lvm zap --destroy --osd-fsid OSD_FSID示例
[ceph: root@host01 /]# ceph-volume lvm zap --destroy --osd-fsid 65d7b6b1-e41a-4a3c-b363-83ade63cb32b
注意所有相对设备都是 zapped。
第 8 章 Ceph 性能基准
作为存储管理员，您可以对 Red Hat Ceph Storage 集群的基准测试性能进行基准测试。本节的目的是让 Ceph 管理员对 Ceph 的原生基准测试工具进行基本了解。这些工具将深入了解 Ceph 存储集群的运行情况。这不是 Ceph 性能基准的确定指南，也不是一个有关如何相应地调整 Ceph 的指南。
8.1. 先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
8.2. 性能基准
OSD（包括日志、磁盘和网络吞吐量）应具有一个用于比较的性能基准。您可以通过将基准性能数据与 Ceph 原生工具中的数据进行比较来识别潜在的调优机会。Red Hat Enterprise Linux 具有许多内置工具，以及开源社区工具的 plethora，可用于帮助完成这些任务。
其它资源
- 有关一些可用工具的详情，请查看知识库文章。
8.3. Ceph 性能基准
Ceph 包含 rados bench 命令，用于在 RADOS 存储群集上执行性能基准测试。命令将执行写入测试，以及两种类型的读测试。在测试读取和写入性能时，--no-cleanup 选项非常重要。默认情况下，rados bench 命令会删除它写入存储池的对象。保留这些对象后，可以使用两个读取测试来测量顺序读取和随机读取的性能。
在运行这些性能测试前，运行以下命令丢弃所有文件系统缓存：
示例
[ceph: root@host01 /]# echo 3 | sudo tee /proc/sys/vm/drop_caches && sudo sync
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
流程
创建新存储池：
示例
[ceph: root@host01 /]# ceph osd pool create testbench 100 100
对新创建的存储池执行 10 秒的写入测试：
示例
[ceph: root@host01 /]# rados bench -p testbench 10 write --no-cleanup Maintaining 16 concurrent writes of 4194304 bytes for up to 10 seconds or 0 objects Object prefix: benchmark_data_cephn1.home.network_10510 sec Cur ops started finished avg MB/s cur MB/s last lat avg lat 0 0 0 0 0 0 - 0 1 16 16 0 0 0 - 0 2 16 16 0 0 0 - 0 3 16 16 0 0 0 - 0 4 16 17 1 0.998879 1 3.19824 3.19824 5 16 18 2 1.59849 4 4.56163 3.87993 6 16 18 2 1.33222 0 - 3.87993 7 16 19 3 1.71239 2 6.90712 4.889 8 16 25 9 4.49551 24 7.75362 6.71216 9 16 25 9 3.99636 0 - 6.71216 10 16 27 11 4.39632 4 9.65085 7.18999 11 16 27 11 3.99685 0 - 7.18999 12 16 27 11 3.66397 0 - 7.18999 13 16 28 12 3.68975 1.33333 12.8124 7.65853 14 16 28 12 3.42617 0 - 7.65853 15 16 28 12 3.19785 0 - 7.65853 16 11 28 17 4.24726 6.66667 12.5302 9.27548 17 11 28 17 3.99751 0 - 9.27548 18 11 28 17 3.77546 0 - 9.27548 19 11 28 17 3.57683 0 - 9.27548 Total time run: 19.505620 Total writes made: 28 Write size: 4194304 Bandwidth (MB/sec): 5.742 Stddev Bandwidth: 5.4617 Max bandwidth (MB/sec): 24 Min bandwidth (MB/sec): 0 Average Latency: 10.4064 Stddev Latency: 3.80038 Max latency: 19.503 Min latency: 3.19824为存储池执行一次10 秒的连续读测试 ：
示例
[ceph: root@host01 /]# rados bench -p testbench 10 seq sec Cur ops started finished avg MB/s cur MB/s last lat avg lat 0 0 0 0 0 0 - 0 Total time run: 0.804869 Total reads made: 28 Read size: 4194304 Bandwidth (MB/sec): 139.153 Average Latency: 0.420841 Max latency: 0.706133 Min latency: 0.0816332
为存储池执行一次 10 秒的随机读取测试 ：
示例
[ceph: root@host01 /]# rados bench -p testbench 10 rand sec Cur ops started finished avg MB/s cur MB/s last lat avg lat 0 0 0 0 0 0 - 0 1 16 46 30 119.801 120 0.440184 0.388125 2 16 81 65 129.408 140 0.577359 0.417461 3 16 120 104 138.175 156 0.597435 0.409318 4 15 157 142 141.485 152 0.683111 0.419964 5 16 206 190 151.553 192 0.310578 0.408343 6 16 253 237 157.608 188 0.0745175 0.387207 7 16 287 271 154.412 136 0.792774 0.39043 8 16 325 309 154.044 152 0.314254 0.39876 9 16 362 346 153.245 148 0.355576 0.406032 10 16 405 389 155.092 172 0.64734 0.398372 Total time run: 10.302229 Total reads made: 405 Read size: 4194304 Bandwidth (MB/sec): 157.248 Average Latency: 0.405976 Max latency: 1.00869 Min latency: 0.0378431
要增加并发读取和写入的数量，请使用
-t选项，默认为 16 个线程。另外，-b参数可以调整所写入对象的大小。默认对象大小为 4 MB。安全最大对象大小为 16 MB。红帽建议将这些基准测试中的多个副本运行到不同的池。这样做显示与多个客户端的性能更改。添加
--run-name LABEL选项以控制在基准测试过程中写入的对象名称。通过更改每个运行命令实例的--run-name标签，可以同时运行多个rados bench命令。这可防止当多个客户端试图访问同一对象时可能会出现潜在的 I/O 错误，并允许不同的客户端访问不同的对象。在尝试模拟真实工作负载时，--run-name选项也很有用。示例
[ceph: root@host01 /]# rados bench -p testbench 10 write -t 4 --run-name client1 Maintaining 4 concurrent writes of 4194304 bytes for up to 10 seconds or 0 objects Object prefix: benchmark_data_node1_12631 sec Cur ops started finished avg MB/s cur MB/s last lat avg lat 0 0 0 0 0 0 - 0 1 4 4 0 0 0 - 0 2 4 6 2 3.99099 4 1.94755 1.93361 3 4 8 4 5.32498 8 2.978 2.44034 4 4 8 4 3.99504 0 - 2.44034 5 4 10 6 4.79504 4 2.92419 2.4629 6 3 10 7 4.64471 4 3.02498 2.5432 7 4 12 8 4.55287 4 3.12204 2.61555 8 4 14 10 4.9821 8 2.55901 2.68396 9 4 16 12 5.31621 8 2.68769 2.68081 10 4 17 13 5.18488 4 2.11937 2.63763 11 4 17 13 4.71431 0 - 2.63763 12 4 18 14 4.65486 2 2.4836 2.62662 13 4 18 14 4.29757 0 - 2.62662 Total time run: 13.123548 Total writes made: 18 Write size: 4194304 Bandwidth (MB/sec): 5.486 Stddev Bandwidth: 3.0991 Max bandwidth (MB/sec): 8 Min bandwidth (MB/sec): 0 Average Latency: 2.91578 Stddev Latency: 0.956993 Max latency: 5.72685 Min latency: 1.91967删除
rados bench命令创建的数据：示例
[ceph: root@host01 /]# rados -p testbench cleanup
8.4. Ceph 块性能基准
Ceph 包含 rbd bench-write 命令，以测试对块设备测量吞吐量和延迟情况的连续写入。默认字节大小为 4096，默认 I/O 线程数为 16，默认的写入字节数为 1 GB。这些默认设置可以通过 --io-size、--io-threads 和 --io-total 选项来修改。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
流程
如果还没有加载，载入
rbd内核模块：示例
[root@host01 ~]# modprobe rbd
在
testbench池中创建一个 1 GB 的rbd镜像文件：示例
[root@host01 ~]# rbd create image01 --size 1024 --pool testbench
将镜像文件映射到设备文件中：
示例
[root@host01 ~]# rbd map image01 --pool testbench --name client.admin
在块设备中创建
ext4文件系统：示例
[root@host01 ~]# mkfs.ext4 /dev/rbd/testbench/image01
创建新目录：
示例
[root@host01 ~]# mkdir /mnt/ceph-block-device
将块设备挂载到
/mnt/ceph-block-device/下：示例
[root@host01 ~]# mount /dev/rbd/testbench/image01 /mnt/ceph-block-device
针对块设备执行写入性能测试
示例
[root@host01 ~]# 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 块设备指南中的 Ceph 块设备章节。
8.5. 基准测试 CephFS 性能
您可以使用 FIO 工具来基准测试 Ceph 文件系统(CephFS)性能。此工具也可用于对 Ceph 块设备进行基准测试。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
- FIO 工具安装在节点上。如需了解更多详细信息，请参阅 KCS 如何安装 Flexible I/O Tester (fio)性能基准工具。
- 挂载到节点上的块设备或 Ceph 文件系统。
流程
导航到挂载 Block Device 或 CephFS 的应用：
示例
[root@host01 ~]# cd /mnt/ceph-block-device [root@host01 ~]# cd /mnt/ceph-file-system
运行 FIO 命令。从 4k 启动
bs值并重复 2 增量的指数(4k, 8k, 16k, 32k … 128k… 512k, 1m, 2m, 2m, 4m)，使用不同的iodepth设置。您还应在预期的工作负载操作大小中运行测试。带有不同 iodepth 值的 4K 测试示例
fio --name=randwrite --rw=randwrite --direct=1 --ioengine=libaio --bs=4k --iodepth=32 --size=5G --runtime=60 --group_reporting=1
带有不同 iodepth 值的 8K 测试示例
fio --name=randwrite --rw=randwrite --direct=1 --ioengine=libaio --bs=8k --iodepth=32 --size=5G --runtime=60 --group_reporting=1
注意有关使用
fio命令的详情，请参考fioman page。
8.6. Ceph 对象网关性能基准测试
您可以使用 s3cmd 工具来对 Ceph 对象网关的性能进行基准测试。
使用 get 和 put 请求来确定性能。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
-
在节点上安装
s3cmd。
流程
上传文件并测量速度。
time命令测量上传的持续时间。语法
time s3cmd put PATH_OF_SOURCE_FILE PATH_OF_DESTINATION_FILE
示例
time s3cmd put /path-to-local-file s3://bucket-name/remote/file
将
/path-to-local-file替换为您要上传的文件，将s3://bucket-name/remote/file替换为 S3 存储桶中的目的地。下载文件并测量速度。
time命令测量下载持续时间。语法
time s3cmd get PATH_OF_DESTINATION_FILE DESTINATION_PATH
示例
time s3cmd get s3://bucket-name/remote/file /path-to-local-destination
将
s3://bucket-name/remote/file替换为您要下载的 S3 对象，并将/path-to-local-destination替换为您要保存文件的本地目录。列出指定存储桶中的所有对象，并测量响应时间。
语法
time s3cmd ls s3://BUCKET_NAME示例
time s3cmd ls s3://bucket-name
-
分析输出，以根据
time命令报告的持续时间计算上传/下载速度并测量响应时间。
第 9 章 Ceph 性能计数器
作为存储管理员，您可以收集 Red Hat Ceph Storage 集群的性能指标。Ceph 性能计数器是内部基础架构指标的集合。此指标数据的集合、聚合和图表可以通过一组工具进行，并可用于性能分析。
9.1. 先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
9.2. 访问 Ceph 性能计数器
性能计数器通过用于 Ceph 监控器和 OSD 的套接字接口提供。每个对应守护进程的套接字文件默认位于 /var/run/ceph 下。性能计数器被分成集合名称。这些集合名称代表子系统或子系统实例。
以下是 monitor 和 OSD 集合名称类别的完整列表，其中包含每个的简短描述信息：
监控集合名称类别
- 集群指标 - 显示存储集群的信息：监控、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 网关集合名称类别
- Object Gateway Client Metrics - 显示 GET 和 PUT 请求的统计信息
- Objecter Metrics - 显示各种基于对象的操作的信息
- Object Gateway Throttle Metrics - 显示 OSD 节流方式的统计信息
9.3. 显示 Ceph 性能计数器
ceph daemon DAEMON_NAME perf schema 命令输出可用的指标。每个指标都有一个关联的位字段值类型。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
流程
要查看指标的模式，您可以使用以下命令之一：
Synatx
ceph daemon DAEMON_NAME perf schema ceph tell DAEMON_NAME perf schema
注意您必须从节点运行
ceph daemon命令来运行守护进程。示例
[ceph: root@host01 /]# ceph tell mon.host01 perf schema
从监控节点执行
ceph daemon DAEMON_NAME perf schema命令：示例
[ceph: root@host01 /]# ceph daemon mon.host01 perf schema
从 OSD 节点执行
ceph daemon DAEMON_NAME perf schema命令：示例
[ceph: root@host01 /]# ceph daemon osd.11 perf schema
| bit | 含义 |
|---|---|
| 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 的组合。这意味着计数器值将是一个整数值。
其它资源
- 如需更多详细信息，请参阅 Red Hat Ceph Storage 管理指南中的平均数和总和部分。
9.4. 转储 Ceph 性能计数器
ceph daemon .. perf dump 命令会输出当前值，并将指标分组到各个子系统的集合名称下。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 节点的根级别访问权限。
流程
查看当前的指标数据：
语法
ceph daemon DAEMON_NAME perf dump注意您必须从节点运行
ceph daemon命令来运行守护进程。从 monitor 节点执行
ceph daemon .. perf dump命令：[ceph: root@host01 /]# ceph daemon mon.host01 perf dump
从 OSD
节点执行 ceph 守护进程 .. perf dump命令：[ceph: root@host01 /]# ceph daemon osd.11 perf dump
其它资源
- 要查看每个可用的 monitor 指标的简短描述，请参阅 Ceph 监控指标表。
9.5. 平均计数和总和
所有延迟号的位字段值为 5。此字段包含平均计数和 sum 的浮点值。avgcount 是这个范围内的操作数，sum 是总延迟（以秒为单位）。将 sum 除以 avgcount 的值为您提供了关于每个操作的延迟理念。
其它资源
- 要查看每个 OSD 指标的简短描述，请参见 Ceph OSD 表。
9.6. Ceph 监控指标
| 集合名称 | 指标名称 | 位字段值 | 简短描述 |
|---|---|---|---|
|
|
| 2 | 监控器数 |
|
| 2 | 仲裁中的 monitor 数量 | |
|
| 2 | OSD 的总数 | |
|
| 2 | 已启动的 OSD 数量 | |
|
| 2 | 集群中的 OSD 数量 | |
|
| 2 | OSD map 的当前 epoch | |
|
| 2 | 集群总容量（以字节为单位） | |
|
| 2 | 集群中的已用字节数 | |
|
| 2 | 集群中的可用字节数 | |
|
| 2 | 池数量 | |
|
| 2 | 放置组总数 | |
|
| 2 | active+clean 状态的放置组数量 | |
|
| 2 | 处于活跃状态的放置组数量 | |
|
| 2 | 处于 peering 状态的放置组数量 | |
|
| 2 | 集群中的对象总数 | |
|
| 2 | 降级数量（减少副本）对象 | |
|
| 2 | 拼写错误的数量（集群中的长位置）对象 | |
|
| 2 | unfound 对象的数量 | |
|
| 2 | 所有对象的字节数 | |
|
| 2 | 启动的 MDS 数量 | |
|
| 2 | 集群中的 MDS 数量 | |
|
| 2 | 失败的 MDS 数量 | |
|
| 2 | MDS 映射的当前 epoch |
| 集合名称 | 指标名称 | 位字段值 | 简短描述 |
|---|---|---|---|
|
|
| 10 | Gets |
|
| 10 | Transactions | |
|
| 10 | Compactions | |
|
| 10 | 按范围编程（按范围） | |
|
| 10 | 在压缩队列中合并范围 | |
|
| 2 | 压缩队列的长度 |
| 集合名称 | 指标名称 | 位字段值 | 简短描述 |
|---|---|---|---|
|
|
| 2 | 当前打开的 monitor 会话数量 |
|
| 10 | 创建的 monitor 会话数量 | |
|
| 10 | monitor 中的 remove_session 调用数量 | |
|
| 10 | 修剪监控会话的数量 | |
|
| 10 | 参与的 elections monitor 数量 | |
|
| 10 | 有 monitor 启动的选举数 | |
|
| 10 | 监控可享受的选举数量 | |
|
| 10 | 监控丢失的选举数量 |
| 集合名称 | 指标名称 | 位字段值 | 简短描述 |
|---|---|---|---|
|
|
| 10 | 从领导角色开始 |
|
| 10 | 以 peon 角色启动 | |
|
| 10 | 重启 | |
|
| 10 | 刷新 | |
|
| 5 | 刷新延迟 | |
|
| 10 | 启动和处理开始 | |
|
| 6 | 开始时事务中的键 | |
|
| 6 | 开始时事务中的数据 | |
|
| 5 | 开始操作的延迟 | |
|
| 10 | 提交 | |
|
| 6 | 提交时事务中的键 | |
|
| 6 | 提交时事务中的数据 | |
|
| 5 | 提交延迟 | |
|
| 10 | peon 收集 | |
|
| 6 | peon collect 时事务中的键 | |
|
| 6 | peon collect 时事务中的数据 | |
|
| 5 | peon 收集延迟 | |
|
| 10 | 在开始的和处理的 collect 中未提交的值 | |
|
| 10 | 收集超时 | |
|
| 10 | 接受超时 | |
|
| 10 | 租期确认超时 | |
|
| 10 | 租期超时 | |
|
| 10 | 在磁盘上存储共享状态 | |
|
| 6 | 存储在事务中的密钥 | |
|
| 6 | 存储在存储状态下的事务中的数据 | |
|
| 5 | 存储状态延迟 | |
|
| 10 | 状态共享 | |
|
| 6 | 处于共享状态的密钥 | |
|
| 6 | 处于共享状态的数据 | |
|
| 10 | 新的推荐号查询 | |
|
| 5 | 新的提议号获得延迟 |
| 集合名称 | 指标名称 | 位字段值 | 简短描述 |
|---|---|---|---|
|
|
| 10 | 当前可用的节流 |
|
| 10 | 最大值 throttle | |
|
| 10 | Gets | |
|
| 10 | 获取数据 | |
|
| 10 | 在 get_or_fail 时被阻断 | |
|
| 10 | get_or_fail 的过程中成功 | |
|
| 10 | Takes | |
|
| 10 | 获取的数据 | |
|
| 10 | Puts | |
|
| 10 | 放置数据 | |
|
| 5 | 等待延迟 |
9.7. Ceph OSD 指标
| 集合名称 | 指标名称 | 位字段值 | 简短描述 |
|---|---|---|---|
|
|
| 2 | 脏数据 |
|
| 2 | 写入数据 | |
|
| 2 | 脏操作 | |
|
| 2 | 写入操作 | |
|
| 2 | 等待写入的条目 | |
|
| 2 | 写入条目 |
| 集合名称 | 指标名称 | 位字段值 | 简短描述 |
|---|---|---|---|
|
|
| 10 | Gets |
|
| 10 | Transactions | |
|
| 10 | Compactions | |
|
| 10 | 按范围编程（按范围） | |
|
| 10 | 在压缩队列中合并范围 | |
|
| 2 | 压缩队列的长度 |
| 集合名称 | 指标名称 | 位字段值 | 简短描述 |
|---|---|---|---|
|
|
| 2 | 活跃操作 |
|
| 2 | Laggy 操作 | |
|
| 10 | 发送的操作 | |
|
| 10 | 发送的数据 | |
|
| 10 | 重新发送操作 | |
|
| 10 | 提交回调 | |
|
| 10 | 操作提交 | |
|
| 10 | 操作 | |
|
| 10 | 读取操作 | |
|
| 10 | 写操作 | |
|
| 10 | Read-modify-write 操作 | |
|
| 10 | PG 操作 | |
|
| 10 | Stat 操作 | |
|
| 10 | 创建对象操作 | |
|
| 10 | 读取操作 | |
|
| 10 | 写操作 | |
|
| 10 | 写入完整对象操作 | |
|
| 10 | 附加操作 | |
|
| 10 | 将对象设置为零操作 | |
|
| 10 | 截断对象操作 | |
|
| 10 | 删除对象操作 | |
|
| 10 | 映射扩展操作 | |
|
| 10 | 稀疏读取操作 | |
|
| 10 | 克隆范围操作 | |
|
| 10 | get xattr 操作 | |
|
| 10 | 设置 xattr 操作 | |
|
| 10 | xattr 比较操作 | |
|
| 10 | 删除 xattr 操作 | |
|
| 10 | 重置 xattr 操作 | |
|
| 10 | TMAP 更新操作 | |
|
| 10 | TMAP put 操作 | |
|
| 10 | TMAP get 操作 | |
|
| 10 | 调用（执行）操作 | |
|
| 10 | 通过对象操作监视 | |
|
| 10 | 通知对象操作 | |
|
| 10 | 多操作中的扩展属性比较 | |
|
| 10 | 其他操作 | |
|
| 2 | 活跃的闲置操作 | |
|
| 10 | 发送闲置操作 | |
|
| 10 | 重新控制操作 | |
|
| 10 | 发送 ping 进行闲置操作 | |
|
| 2 | 活跃池操作 | |
|
| 10 | 发送的池操作 | |
|
| 10 | 重新执行池操作 | |
|
| 2 | Active get pool stat 操作 | |
|
| 10 | 池 stat 操作发送 | |
|
| 10 | 重新分配池统计信息 | |
|
| 2 | statfs 操作 | |
|
| 10 | 发送的 FS stats | |
|
| 10 | 重新发送的 FS stats | |
|
| 2 | 活跃命令 | |
|
| 10 | 发送命令 | |
|
| 10 | 重新发送命令 | |
|
| 2 | OSD map epoch | |
|
| 10 | 收到的完整 OSD 映射 | |
|
| 10 | 接收的增量 OSD map | |
|
| 2 | 开放会话 | |
|
| 10 | 会话已打开 | |
|
| 10 | 会话关闭 | |
|
| 2 | Laggy OSD 会话 |
| 集合名称 | 指标名称 | 位字段值 | 简短描述 |
|---|---|---|---|
|
|
| 2 | 复制当前正在被处理的操作（主） |
|
| 10 | 客户端操作总写入大小 | |
|
| 10 | 客户端操作总读取大小 | |
|
| 5 | 客户端操作的延迟（包括队列时间） | |
|
| 5 | 客户端操作的延迟（不包括队列时间） | |
|
| 10 | 客户端读操作 | |
|
| 10 | 读取客户端数据 | |
|
| 5 | 读取操作的延迟（包括队列时间） | |
|
| 5 | 读取操作的延迟（不包括队列时间） | |
|
| 10 | 客户端写操作 | |
|
| 10 | 写入的客户端数据 | |
|
| 5 | 客户端写入操作可读/应用延迟 | |
|
| 5 | 写入操作的延迟（包括队列时间） | |
|
| 5 | 写入操作的延迟（不包括队列时间） | |
|
| 10 | 客户端 read-modify-write 操作 | |
|
| 10 | 客户端读-modify-write 操作写入 | |
|
| 10 | 客户端读-modify-write 操作可读取 | |
|
| 5 | 客户端 read-modify-write 操作可读/应用延迟 | |
|
| 5 | 读写操作的延迟（包括队列时间） | |
|
| 5 | 读写操作的延迟（不包括队列时间） | |
|
| 10 | Suboperations | |
|
| 10 | Suboperations 总数 | |
|
| 5 | Suboperations 延迟 | |
|
| 10 | 复制写入 | |
|
| 10 | 复制写入的数据大小 | |
|
| 5 | 复制写入延迟 | |
|
| 10 | Suboperations pull 请求 | |
|
| 5 | Suboperations pull 延迟 | |
|
| 10 | Suboperations push 消息 | |
|
| 10 | Suboperations 推送的大小 | |
|
| 5 | Suboperations push 延迟 | |
|
| 10 | 发送的拉取请求 | |
|
| 10 | 发送的推送消息 | |
|
| 10 | 推送的大小 | |
|
| 10 | 入站推送消息 | |
|
| 10 | 入站推送的大小 | |
|
| 10 | 开始恢复操作 | |
|
| 2 | CPU 负载 | |
|
| 2 | 分配的缓冲区大小总数 | |
|
| 2 | 放置组 | |
|
| 2 | 此 osd 是主的放置组 | |
|
| 2 | 此 osd 是副本的放置组 | |
|
| 2 | 准备好从此 osd 删除 PG | |
|
| 2 | 发送给对等点的心跳(ping) | |
|
| 2 | 接收来自其中的心跳(ping)对等点 | |
|
| 10 | OSD map 消息 | |
|
| 10 | OSD map epochs | |
|
| 10 | OSD map 副本 | |
|
| 2 | OSD 大小 | |
|
| 2 | 使用的空间 | |
|
| 2 | 可用空间 | |
|
| 10 | RADOS 'copy-from' 操作 | |
|
| 10 | 等级提升 | |
|
| 10 | Tier flushes | |
|
| 10 | 失败的层冲刷 | |
|
| 10 | 等级冲刷尝试 | |
|
| 10 | 失败的层冲刷尝试 | |
|
| 10 | 等级驱除 | |
|
| 10 | Tier whiteouts | |
|
| 10 | 脏层标志集 | |
|
| 10 | 清理脏层标志 | |
|
| 10 | Tier delays (agent waiting) | |
|
| 10 | 等级代理读取 | |
|
| 10 | 设置代理的分层代理 | |
|
| 10 | 代理跳过的对象 | |
|
| 10 | 分层代理刷新 | |
|
| 10 | 分层代理驱除 | |
|
| 10 | 对象上下文缓存点击 | |
|
| 10 | 对象上下文缓存查找 |
| 集合名称 | 指标名称 | 位字段值 | 简短描述 |
|---|---|---|---|
|
|
| 5 | 初始恢复状态延迟 |
|
| 5 | 启动恢复状态延迟 | |
|
| 5 | 重置恢复状态延迟 | |
|
| 5 | 启动恢复状态延迟 | |
|
| 5 | 主恢复状态延迟 | |
|
| 5 | 对等恢复状态延迟 | |
|
| 5 | 回填恢复状态延迟 | |
|
| 5 | 等待远程回填保留恢复状态延迟 | |
|
| 5 | 等待本地回填保留恢复状态延迟 | |
|
| 5 | 取消回填恢复状态延迟 | |
|
| 5 | 恢复恢复状态延迟 | |
|
| 5 | rep 等待恢复保留恢复状态延迟 | |
|
| 5 | Rep 等待回填保留的恢复状态 | |
|
| 5 | 恢复恢复状态延迟 | |
|
| 5 | 激活恢复状态延迟 | |
|
| 5 | 等待本地恢复状态延迟 | |
|
| 5 | 等待远程恢复保留状态延迟 | |
|
| 5 | 恢复恢复状态延迟 | |
|
| 5 | 恢复恢复状态延迟 | |
|
| 5 | 清理恢复状态延迟 | |
|
| 5 | 主动恢复状态延迟 | |
|
| 5 | Replicaactive 恢复状态延迟 | |
|
| 5 | stray 恢复状态延迟 | |
|
| 5 | Getinfo 恢复状态延迟 | |
|
| 5 | Getlog 恢复状态延迟 | |
|
| 5 | Waitactingchange 恢复状态延迟 | |
|
| 5 | 恢复状态延迟不完整 | |
|
| 5 | 获得恢复状态延迟 | |
|
| 5 | Waitupthru 恢复状态延迟 |
| 集合名称 | 指标名称 | 位字段值 | 简短描述 |
|---|---|---|---|
|
|
| 10 | 当前可用的节流 |
|
| 10 | 最大值 throttle | |
|
| 10 | Gets | |
|
| 10 | 获取数据 | |
|
| 10 | 在 get_or_fail 时被阻断 | |
|
| 10 | get_or_fail 的过程中成功 | |
|
| 10 | Takes | |
|
| 10 | 获取的数据 | |
|
| 10 | Puts | |
|
| 10 | 放置数据 | |
|
| 5 | 等待延迟 |
9.8. Ceph 对象网关指标
| 集合名称 | 指标名称 | 位字段值 | 简短描述 |
|---|---|---|---|
|
|
| 10 | Requests |
|
| 10 | 中止的请求 | |
|
| 10 | Gets | |
|
| 10 | 获取的大小 | |
|
| 5 | 获取延迟 | |
|
| 10 | Puts | |
|
| 10 | 放置的大小 | |
|
| 5 | Put 延迟 | |
|
| 2 | 队列长度 | |
|
| 2 | 活跃请求队列 | |
|
| 10 | 缓存命中 | |
|
| 10 | 缓存未命中 | |
|
| 10 | Keystone 令牌缓存命中 | |
|
| 10 | Keystone 令牌缓存丢失 |
| 集合名称 | 指标名称 | 位字段值 | 简短描述 |
|---|---|---|---|
|
|
| 2 | 活跃操作 |
|
| 2 | Laggy 操作 | |
|
| 10 | 发送的操作 | |
|
| 10 | 发送的数据 | |
|
| 10 | 重新发送操作 | |
|
| 10 | 提交回调 | |
|
| 10 | 操作提交 | |
|
| 10 | 操作 | |
|
| 10 | 读取操作 | |
|
| 10 | 写操作 | |
|
| 10 | Read-modify-write 操作 | |
|
| 10 | PG 操作 | |
|
| 10 | Stat 操作 | |
|
| 10 | 创建对象操作 | |
|
| 10 | 读取操作 | |
|
| 10 | 写操作 | |
|
| 10 | 写入完整对象操作 | |
|
| 10 | 附加操作 | |
|
| 10 | 将对象设置为零操作 | |
|
| 10 | 截断对象操作 | |
|
| 10 | 删除对象操作 | |
|
| 10 | 映射扩展操作 | |
|
| 10 | 稀疏读取操作 | |
|
| 10 | 克隆范围操作 | |
|
| 10 | get xattr 操作 | |
|
| 10 | 设置 xattr 操作 | |
|
| 10 | xattr 比较操作 | |
|
| 10 | 删除 xattr 操作 | |
|
| 10 | 重置 xattr 操作 | |
|
| 10 | TMAP 更新操作 | |
|
| 10 | TMAP put 操作 | |
|
| 10 | TMAP get 操作 | |
|
| 10 | 调用（执行）操作 | |
|
| 10 | 通过对象操作监视 | |
|
| 10 | 通知对象操作 | |
|
| 10 | 多操作中的扩展属性比较 | |
|
| 10 | 其他操作 | |
|
| 2 | 活跃的闲置操作 | |
|
| 10 | 发送闲置操作 | |
|
| 10 | 重新控制操作 | |
|
| 10 | 发送 ping 进行闲置操作 | |
|
| 2 | 活跃池操作 | |
|
| 10 | 发送的池操作 | |
|
| 10 | 重新执行池操作 | |
|
| 2 | Active get pool stat 操作 | |
|
| 10 | 池 stat 操作发送 | |
|
| 10 | 重新分配池统计信息 | |
|
| 2 | statfs 操作 | |
|
| 10 | 发送的 FS stats | |
|
| 10 | 重新发送的 FS stats | |
|
| 2 | 活跃命令 | |
|
| 10 | 发送命令 | |
|
| 10 | 重新发送命令 | |
|
| 2 | OSD map epoch | |
|
| 10 | 收到的完整 OSD 映射 | |
|
| 10 | 接收的增量 OSD map | |
|
| 2 | 开放会话 | |
|
| 10 | 会话已打开 | |
|
| 10 | 会话关闭 | |
|
| 2 | Laggy OSD 会话 |
| 集合名称 | 指标名称 | 位字段值 | 简短描述 |
|---|---|---|---|
|
|
| 10 | 当前可用的节流 |
|
| 10 | 最大值 throttle | |
|
| 10 | Gets | |
|
| 10 | 获取数据 | |
|
| 10 | 在 get_or_fail 时被阻断 | |
|
| 10 | get_or_fail 的过程中成功 | |
|
| 10 | Takes | |
|
| 10 | 获取的数据 | |
|
| 10 | Puts | |
|
| 10 | 放置数据 | |
|
| 5 | 等待延迟 |
第 10 章 BlueStore
BlueStore 是 OSD 守护进程的后端对象存储，直接在块设备上放置对象。
BlueStore 为生产环境中的 OSD 守护进程提供了高性能后端。默认情况下，BlueStore 配置为自我调整。如果您确定您的环境使用手动调优的 BlueStore 的性能更好，请联系红帽支持并共享您的配置详情，以帮助我们改进自动调整功能。红帽期待您的反馈意见并感谢您的建议。
10.1. Ceph BlueStore
以下是使用 BlueStore 的一些主要功能：
- 直接管理存储设备
- BlueStore 使用原始块设备或分区。这可避免任何抽象层的抽象层，如 XFS 等本地文件系统，这可能会限制性能或增加复杂性。
- 使用 RocksDB 进行元数据管理
- BlueStore 使用 RocksDB key-value 数据库来管理内部元数据，如从对象名称到磁盘上的块位置的映射。
- 完整数据和元数据校验和
- 默认情况下，写入 BlueStore 的所有数据和元数据都受到一个或多个校验和的保护。在不验证的情况下，不会从磁盘或返回给用户读取数据或元数据。
- 高效的 copy-on-write 功能
- Ceph 块设备和 Ceph 文件系统快照依赖于以 BlueStore 高效实施的写时复制克隆机制。这为常规快照和依赖克隆的池实现了高效 I/O 的 I/O 效率。
- 没有大型的双写方式
- BlueStore 首先将任何新数据写入块设备上未分配空间，然后提交 RocksDB 事务来更新对象元数据以引用磁盘的新区域。只有在写入操作低于可配置的大小阈值时，它会返回 write-ahead 日志方案。
- 支持多设备
- BlueStore 可以使用多个块设备来存储不同的数据。例如：用于数据的硬盘驱动器(HDD)，用于元数据的 Solid-state Drive(SSD)，即 Non-volatile Memory(NVM)或 Non-volatile random-access memory(NVRAM)或 RocksDB write-ahead 日志的持久性内存。详情请参阅 Ceph BlueStore 设备。
- 有效的块设备使用
- 因为 BlueStore 不使用任何文件系统，所以它将尽可能减少需要清除存储设备缓存的需要。
10.2. Ceph BlueStore 设备
本节介绍 BlueStore 后端使用哪些块设备。
BlueStore 可以管理一个、两个或三个存储设备。
- 主
- WAL
- DB
在最简单的情形中，BlueStore 使用一个（主）存储设备。存储设备分区分为两个部分：
- OSD 元数据 ：使用 XFS 格式化的小分区，其中包含 OSD 的基本元数据。此数据目录包含 OSD 的信息，如其标识符、所属集群及其专用密钥环。
- 数据 ：一个大型分区，占据由 BlueStore 直接管理的设备的其余部分，其中包含所有 OSD 数据。这个主设备由 data 目录中的块符号链接识别。
您还可以使用两个附加设备：
-
WAL(write-ahead-log)设备 ：存储 BlueStore 内部日志或 write-ahead 日志的设备。它通过数据目录中的
block.wal符号链接来识别。只有在设备比主设备更快时才请考虑使用 WAL 设备。例如，当 WAL 设备使用 SSD 磁盘且主设备使用 HDD 磁盘时。 - DB 设备 ：存储 BlueStore 内部元数据的设备。嵌入式 RocksDB 数据库包含尽可能多的元数据，因为它可以在 DB 设备上而不是主设备上的元数据来提高性能。如果 DB 设备已满，它会开始将元数据添加到主设备中。只有在设备比主设备更快时才考虑使用 DB 设备。
如果您在快速设备中只有 1GB 的存储。红帽建议将其用作 WAL 设备。如果您使用更快速的设备可用，请考虑将其用作 DB 设备。BlueStore 日志始终放在最快的设备上，因此使用 DB 设备提供相同的好处，同时允许存储额外的元数据。
10.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 选项前，请联系红帽支持。
10.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 缓存内存值也除外。
10.5. 使用 bluestore_min_alloc_size 参数调优 Ceph BlueStore
此过程适用于新的或全新部署的 OSD。
在 BlueStore 中，原始分区在 bluestore_min_alloc_size 的块中分配和管理。默认情况下，bluestore_min_alloc_size 为 4096，相当于 4 KiB 用于 HDD 和 SSD。当每个块中的未写入区域写入原始分区时，会用零填充。当您没有针对的工作负载正确配置大小时，这可能会导致浪费掉未使用的空间（例如，当编写小对象时）。
最佳实践是将 bluestore_min_alloc_size 设置为与最小写入匹配，以便避免写法。
不建议更改 bluestore_min_alloc_size 的值。如需任何帮助，请联系红帽支持。
设置 bluestore_min_alloc_size_ssd 和 bluestore_min_alloc_size_hdd 分别特定于 SSD 和 HDD，但设置它们是必需的，因为设置 bluestore_min_alloc_size 覆盖它们。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- Ceph 监视器和管理器已在集群中部署。
- 可以重新置备为 OSD 节点的服务器或节点
- 如果您要重新部署现有的 Ceph OSD 节点，Ceph 监控节点的管理密钥环。
流程
在 bootstrapped 节点上，更改
bluestore_min_alloc_size参数的值：语法
ceph config set osd.OSD_ID bluestore_min_alloc_size_DEVICE_NAME_ VALUE
示例
[ceph: root@host01 /]# ceph config set osd.4 bluestore_min_alloc_size_hdd 8192
您可以看到
bluestore_min_alloc_size设置为 8192 字节，相当于 8 KiB。注意所选值应该与 2 的指数相对应。
重新启动 OSD 的服务。
语法
systemctl restart SERVICE_ID
示例
[ceph: root@host01 /]# systemctl restart ceph-499829b4-832f-11eb-8d6d-001a4a000635@osd.4.service
验证
使用
ceph 守护进程命令验证设置：语法
ceph daemon osd.OSD_ID config get bluestore_min_alloc_size__DEVICE_示例
[ceph: root@host01 /]# ceph daemon osd.4 config get bluestore_min_alloc_size_hdd ceph daemon osd.4 config get bluestore_min_alloc_size { "bluestore_min_alloc_size": "8192" }
其它资源
-
对于 OSD 移除和添加，请参阅 Red Hat Ceph Storage Operations Guide 中的使用 Ceph Orchestrator 管理 OSD一章以及以下链接。对于已部署的 OSD，您将无法修改
bluestore_min_alloc_size参数，因此您必须移除 OSD 并再次部署它们。
10.6. 使用 BlueStore 管理工具重新划分 RocksDB 数据库
您可以使用 BlueStore 管理工具重新划分数据库。它将 BlueStore 的 RocksDB 数据库从一形转换为几列的系列，而无需重新部署 OSD。列系列的功能与整个数据库相同，但允许用户在较小的数据集上运行并应用不同的选项。它利用存储的不同密钥的预期生命周期。密钥会在转换过程中移动，而不会创建新密钥或删除现有密钥。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 对象存储配置为 BlueStore。
- 部署在主机上的 OSD 节点。
- 对所有主机的 root 级别访问。
-
ceph-common和cephadm软件包在所有主机上都存在。
流程
登录
cephadmshell：示例
[root@host01 ~]# cephadm shell
从管理节点获取 OSD_ID 和主机详情：
示例
[ceph: root@host01 /]# ceph orch ps
以
root用户身份登录对应的主机，再停止 OSD：语法
cephadm unit --name OSD_ID stop示例
[root@host02 ~]# cephadm unit --name osd.0 stop
进入已停止的 OSD 守护进程容器：
语法
cephadm shell --name OSD_ID示例
[root@host02 ~]# cephadm shell --name osd.0
登录到
cephadm shell并检查文件系统一致性：语法
ceph-bluestore-tool --path/var/lib/ceph/osd/ceph-OSD_ID/ fsck示例
[ceph: root@host02 /]# ceph-bluestore-tool --path /var/lib/ceph/osd/ceph-0/ fsck fsck success
检查 OSD 节点的分片状态：
语法
ceph-bluestore-tool --path /var/lib/ceph/osd/ceph-OSD_ID/ show-sharding示例
[ceph: root@host02 /]# ceph-bluestore-tool --path /var/lib/ceph/osd/ceph-6/ show-sharding m(3) p(3,0-12) O(3,0-13) L P
运行
ceph-bluestore-tool命令来重新划分。红帽建议使用命令中的参数：语法
ceph-bluestore-tool --log-level 10 -l log.txt --path /var/lib/ceph/osd/ceph-OSD_ID/ --sharding="m(3) p(3,0-12) O(3,0-13)=block_cache={type=binned_lru} L P" reshard示例
[ceph: root@host02 /]# ceph-bluestore-tool --path /var/lib/ceph/osd/ceph-6/ --sharding="m(3) p(3,0-12) O(3,0-13)=block_cache={type=binned_lru} L P" reshard reshard success要检查 OSD 节点的分片状态，请运行
show-sharding命令：语法
ceph-bluestore-tool --path /var/lib/ceph/osd/ceph-OSD_ID/ show-sharding示例
[ceph: root@host02 /]# ceph-bluestore-tool --path /var/lib/ceph/osd/ceph-6/ show-sharding m(3) p(3,0-12) O(3,0-13)=block_cache={type=binned_lru} L P从
cephadmshell 退出：[ceph: root@host02 /]# exit
以
root用户身份登录对应的主机，再启动 OSD：语法
cephadm unit --name OSD_ID start示例
[root@host02 ~]# cephadm unit --name osd.0 start
其它资源
- 如需更多信息，请参阅 Red Hat Ceph Storage 安装指南。
10.7. BlueStore 碎片工具
作为存储管理员，您要定期检查 BlueStore OSD 的碎片级别。您可以使用一个简单命令来检查碎片级别，以用于离线或在线 OSD。
10.7.1. 先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- BlueStore OSD.
10.7.2. BlueStore 碎片工具是什么？
对于 BlueStore OSD，可用空间随时间在底层存储设备上发生碎片。有些碎片是正常的，但在出现过量碎片时会导致性能降低。
BlueStore 碎片工具在 BlueStore OSD 的碎片级别生成分数。此碎片分数指定为范围 0 到 1。分数为 0 表示没有碎片，1 分代表严重碎片。
| 分数 | 碎片挂载 |
|---|---|
| 0.0 - 0.4 | 无小的碎片。 |
| 0.4 - 0.7 | 小和可接受的碎片。 |
| 0.7 - 0.9 | 需要考虑但安全的碎片。 |
| 0.9 - 1.0 | 严重碎片会导致性能问题。 |
如果您存在严重碎片，且需要一些有助于解决问题，请联络红帽支持。
10.7.3. 检查碎片
可以在线或离线检查 BlueStore OSD 的碎片级别。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- BlueStore OSD.
在线 BlueStore 碎片得分
检查正在运行的 BlueStore OSD 进程：
简单报告：
语法
ceph daemon OSD_ID bluestore allocator score block示例
[ceph: root@host01 /]# ceph daemon osd.123 bluestore allocator score block
详细的报告：
语法
ceph daemon OSD_ID bluestore allocator dump block示例
[ceph: root@host01 /]# ceph daemon osd.123 bluestore allocator dump block
离线 BlueStore 碎片得分
停止 OSD 服务。
语法
systemctl stop SERVICE_ID示例
[root@host01 ~]# systemctl stop ceph-110bad0a-bc57-11ee-8138-fa163eb9ffc2@osd.2.service
重新划分以检查离线 BlueStore OSD。
语法
[root@host01 ~]# cephadm shell --name osd.ID示例
[root@host01 ~]# cephadm shell --name osd.2 Inferring fsid 110bad0a-bc57-11ee-8138-fa163eb9ffc2 Inferring config /var/lib/ceph/110bad0a-bc57-11ee-8138-fa163eb9ffc2/osd.2/config Using recent ceph image registry.redhat.io/rhceph/rhceph-5-rhel8@sha256:09fc3e5baf198614d70669a106eb87dbebee16d4e91484375778d4adbccadacd
检查非运行的 BlueStore OSD 进程：
对于简单的报告，运行以下命令：
语法
ceph-bluestore-tool --path PATH_TO_OSD_DATA_DIRECTORY --allocator block free-score示例
[root@7fbd6c6293c0 /]# ceph-bluestore-tool --path /var/lib/ceph/osd/ceph-123 --allocator block free-score
如需更详细的报告，请运行以下命令：
语法
ceph-bluestore-tool --path PATH_TO_OSD_DATA_DIRECTORY --allocator block free-dump block: { "fragmentation_rating": 0.018290238194701977 }示例
[root@7fbd6c6293c0 /]# ceph-bluestore-tool --path /var/lib/ceph/osd/ceph-123 --allocator block free-dump block: { "capacity": 21470642176, "alloc_unit": 4096, "alloc_type": "hybrid", "alloc_name": "block", "extents": [ { "offset": "0x370000", "length": "0x20000" }, { "offset": "0x3a0000", "length": "0x10000" }, { "offset": "0x3f0000", "length": "0x20000" }, { "offset": "0x460000", "length": "0x10000" },
其它资源
- 有关碎片分数的详细信息，请参阅 BlueStore Fragation Tool。
- 如需了解更多有关重新划分的详细信息 ，请参阅使用 BlueStore 管理工具重新划分 RocskDB 数据库。
10.8. Ceph BlueStore BlueFS
BlueStore 块数据库将元数据作为键值对存储在 RocksDB 数据库中。块数据库驻留在存储设备上的一个小型 BlueFS 分区。BlueFS 是一个最小的文件系统，旨在存放 RocksDB 文件。
BlueFS 文件
RocksDB 生成的文件有 3 个类型：
-
控制文件，如
CURRENT、IDENTITY和MANIFEST-000011。 -
DB 表文件，如
004112.sst。 -
编写前一个日志，如
000038.log。
此外，还有一个内部隐藏的文件，它充当 BlueFS 重播日志( ino 1)， 它充当目录结构、文件映射和操作日志。
回退层次结构
使用 BlueFS 时，可以将任何文件放在任何设备上。文件的部分甚至可以驻留在不同的设备上，即 WAL、DB 和 SLOW。例如，BlueFS 会放置文件。只有在主存储耗尽时才会将文件放在次要存储中，只有在次要存储耗尽时，文件才会被放入次要存储。
特定文件的顺序是：
- 提前写入日志：WAL、DB、SLOW
-
Replay log
ino 1: DB, SLOW 控制和 DB 文件：DB、SLOW
控制和 DB 文件顺序（以耗尽空间）：SLOW
重要控制和 DB 文件顺序有一个例外。当 RocksDB 检测到您在 DB 文件中耗尽空间时，它会直接通知您将文件放在 SLOW 设备。
10.8.1. 查看 bluefs_buffered_io 设置
作为存储管理员，您可以查看 bluefs_buffered_io 参数的当前设置。
对于 Red Hat Ceph Storage，默认将 bluefs_buffered_io 选项设为 True。这个选项使 BlueFS 能够在某些情况下执行缓冲的读取，并允许内核页面缓存作为辅助缓存进行读取，如 RocksDB 块读取。
不建议更改 bluefs_buffered_io 的值。在更改 bluefs_buffered_io 参数前，请联系您的红帽支持团队。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- Ceph 监控节点的根级别访问权限.
流程
登录到 Cephadm shell：
示例
[root@host01 ~]# cephadm shell
-
您可以通过三种不同的方式查看
bluefs_buffered_io参数的当前值：
方法 1
查看存储在配置数据库中的值：
示例
[ceph: root@host01 /]# ceph config get osd bluefs_buffered_io
方法 2
查看特定 OSD 的配置数据库中存储的值：
语法
ceph config get OSD_ID bluefs_buffered_io示例
[ceph: root@host01 /]# ceph config get osd.2 bluefs_buffered_io
方法 3
查看运行值的 OSD 的运行值与配置数据库中存储的值不同：
语法
ceph config show OSD_ID bluefs_buffered_io示例
[ceph: root@host01 /]# ceph config show osd.3 bluefs_buffered_io
10.8.2. 查看 Ceph OSD 的 Ceph BlueFS 统计信息
使用 bluefs stats 命令查看并置和非并置 Ceph OSD 的与 BluesFS 相关的信息。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 对象存储配置为 BlueStore。
- 对 OSD 节点的 root 级别访问权限。
流程
登录到 Cephadm shell：
示例
[root@host01 ~]# cephadm shell
查看 BlueStore OSD 统计信息：
语法
ceph daemon osd.OSD_ID bluefs stats并置 OSD 的示例
[ceph: root@host01 /]# ceph daemon osd.1 bluefs stats 1 : device size 0x3bfc00000 : using 0x1a428000(420 MiB) wal_total:0, db_total:15296836403, slow_total:0
非并置 OSD 示例
[ceph: root@host01 /]# ceph daemon osd.1 bluefs stats 0 : 1 : device size 0x1dfbfe000 : using 0x1100000(17 MiB) 2 : device size 0x27fc00000 : using 0x248000(2.3 MiB) RocksDBBlueFSVolumeSelector: wal_total:0, db_total:7646425907, slow_total:10196562739, db_avail:935539507 Usage matrix: DEV/LEV WAL DB SLOW * * REAL FILES LOG 0 B 4 MiB 0 B 0 B 0 B 756 KiB 1 WAL 0 B 4 MiB 0 B 0 B 0 B 3.3 MiB 1 DB 0 B 9 MiB 0 B 0 B 0 B 76 KiB 10 SLOW 0 B 0 B 0 B 0 B 0 B 0 B 0 TOTALS 0 B 17 MiB 0 B 0 B 0 B 0 B 12 MAXIMUMS: LOG 0 B 4 MiB 0 B 0 B 0 B 756 KiB WAL 0 B 4 MiB 0 B 0 B 0 B 3.3 MiB DB 0 B 11 MiB 0 B 0 B 0 B 112 KiB SLOW 0 B 0 B 0 B 0 B 0 B 0 B TOTALS 0 B 17 MiB 0 B 0 B 0 B 0 B
其中：
0：这指的是专用 WAL 设备，即block.wal。1：这指的是专用 DB 设备，即block.db。2：这指的是主块设备，即block或slow。设备大小：代表设备的实际大小。使用：它代表总使用量。它不仅限于 BlueFS。注意DB 和 WAL 设备仅由 BlueFS 使用。对于主设备，也包含了存储的 BlueStore 数据的使用。在上例中，
2.3 MiB是 BlueStore 中的数据。wal_total,db_total,slow_total：这些值会重新迭代上述设备值。db_avail：这个值代表可以从 SLOW 设备获取多少字节（如果需要）。使用列表-
行
WAL、DB、SLOW: 描述要放置特定文件的位置。 -
行
LOG：描述 BlueFS replay logino 1。 -
列
WAL、DB、SLOW：描述数据实际放置的位置。该值以分配单元为单位。由于性能的原因，WAL 和 DB 具有较大的分配单元。 -
列
* / *：与虚拟设备new-db和new-wal相关的虚拟设备，它们用于ceph-bluestore-tool。它应该始终显示0 B。 -
列
REAL：显示实际使用量（以字节为单位）。 -
列
FILES：显示文件计数。
-
行
MAXIMUMS：此表从使用列表中捕获每个条目的最大值。
其它资源
- 有关 BlueFS 文件的更多信息，请参阅 Ceph BlueStore BlueFS。
- 有关 BlueStore 设备的更多信息，请参阅 Ceph BlueStore 设备。
第 11 章 Cephadm 故障排除
作为存储管理员，您可以对 Red Hat Ceph Storage 集群进行故障排除。有时需要调查 Cephadm 命令失败的原因，或者为何特定的服务未正确运行。
11.1. 先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
11.2. 暂停或禁用 cephadm
如果 Cephadm 没有按预期工作，您可以使用以下命令暂停大多数后台活动：
示例
[ceph: root@host01 /]# ceph orch pause
这将停止任何更改，但 Cephadm 定期检查主机以刷新守护进程和设备的清单。
如果要完全禁用 Cephadm，请运行以下命令：
示例
[ceph: root@host01 /]# ceph orch set backend '' [ceph: root@host01 /]# ceph mgr module disable cephadm
请注意，之前部署的守护进程容器仍然存在，并在之前启动它们。
要在集群中重新启用 Cephadm，请运行以下命令：
示例
[ceph: root@host01 /]# ceph mgr module enable cephadm [ceph: root@host01 /]# ceph orch set backend cephadm
11.3. 每个服务和每个守护进程事件
Cephadm 在每个服务以及每个守护进程之间存储事件，以帮助调试失败的守护进程部署。这些事件通常包含相关信息：
针对每个服务
语法
ceph orch ls --service_name SERVICE_NAME --format yaml
示例
[ceph: root@host01 /]# ceph orch ls --service_name alertmanager --format yaml service_type: alertmanager service_name: alertmanager placement: hosts: - unknown_host status: ... running: 1 size: 1 events: - 2021-02-01T08:58:02.741162 service:alertmanager [INFO] "service was created" - '2021-02-01T12:09:25.264584 service:alertmanager [ERROR] "Failed to apply: Cannot place <AlertManagerSpec for service_name=alertmanager> on unknown_host: Unknown hosts"'
针对每个守护进程
语法
ceph orch ps --service-name SERVICE_NAME --daemon-id DAEMON_ID --format yaml
示例
[ceph: root@host01 /]# ceph orch ps --service-name mds --daemon-id cephfs.hostname.ppdhsz --format yaml daemon_type: mds daemon_id: cephfs.hostname.ppdhsz hostname: hostname status_desc: running ... events: - 2021-02-01T08:59:43.845866 daemon:mds.cephfs.hostname.ppdhsz [INFO] "Reconfigured mds.cephfs.hostname.ppdhsz on host 'hostname'"
11.4. 检查 cephadm 日志
您可以使用以下命令实时监控 Cephadm 日志：
示例
[ceph: root@host01 /]# ceph -W cephadm
您可以使用以下命令看到最后的几个信息：
示例
[ceph: root@host01 /]# ceph log last cephadm
如果您启用了对文件的日志，则可以查看 monitor 主机上名为 ceph.cephadm.log 的 Cephadm 日志文件。
11.5. 收集日志文件
您可以使用 journalctl 命令为所有守护进程收集日志文件。
您必须在 cephadm shell 之外运行所有这些命令。
默认情况下，Cephadm 将日志存储在 journald 中，这意味着守护进程日志在 /var/log/ceph 中不再可用。
要读取特定守护进程的日志文件，请运行以下命令：
语法
cephadm logs --name DAEMON_NAME示例
[root@host01 ~]# cephadm logs --name cephfs.hostname.ppdhsz
在运行守护进程的同一主机上运行时，此命令可以正常工作。
要读取在不同主机上运行的特定守护进程的日志文件，请运行以下命令：
语法
cephadm logs --fsid FSID --name DAEMON_NAME
示例
[root@host01 ~]# cephadm logs --fsid 2d2fd136-6df1-11ea-ae74-002590e526e8 --name cephfs.hostname.ppdhsz
其中
fsid是ceph status命令提供的集群 ID。要获取给定主机上所有守护进程的所有日志文件，请运行以下命令：
语法
for name in $(cephadm ls | python3 -c "import sys, json; [print(i['name']) for i in json.load(sys.stdin)]") ; do cephadm logs --fsid FSID_OF_CLUSTER --name "$name" > $name; done示例
[root@host01 ~]# for name in $(cephadm ls | python3 -c "import sys, json; [print(i['name']) for i in json.load(sys.stdin)]") ; do cephadm logs --fsid 57bddb48-ee04-11eb-9962-001a4a000672 --name "$name" > $name; done
11.6. 收集 systemd 状态
要输出 systemd 单元的状态，请运行以下命令：
示例
[root@host01 ~]$ systemctl status ceph-a538d494-fb2a-48e4-82c8-b91c37bb0684@mon.host01.service
11.7. 列出所有下载的容器镜像
要列出主机上下载的所有容器镜像，请运行以下命令：
示例
[ceph: root@host01 /]# podman ps -a --format json | jq '.[].Image' "docker.io/library/rhel8" "registry.redhat.io/rhceph-alpha/rhceph-5-rhel8@sha256:9aaea414e2c263216f3cdcb7a096f57c3adf6125ec9f4b0f5f65fa8c43987155"
11.8. 手动运行容器
Cephadm 编写运行容器的小型打包程序。请参阅 /var/lib/ceph/CLUSTER_FSID/SERVICE_NAME/unit 来运行容器执行命令。
SSH 错误
如果遇到以下错误：
示例
execnet.gateway_bootstrap.HostNotFound: -F /tmp/cephadm-conf-73z09u6g -i /tmp/cephadm-identity-ky7ahp_5 root@10.10.1.2 ... raise OrchestratorError(msg) from e orchestrator._interface.OrchestratorError: Failed to connect to 10.10.1.2 (10.10.1.2). Please make sure that the host is reachable and accepts connections using the cephadm SSH key
尝试排除这个问题的选项：
为确保 Cephadm 具有 SSH 身份密钥，请运行以下命令：
示例
[ceph: root@host01 /]# ceph config-key get mgr/cephadm/ssh_identity_key > ~/cephadm_private_key INFO:cephadm:Inferring fsid f8edc08a-7f17-11ea-8707-000c2915dd98 INFO:cephadm:Using recent ceph image docker.io/ceph/ceph:v15 obtained 'mgr/cephadm/ssh_identity_key' [root@mon1 ~] # chmod 0600 ~/cephadm_private_key
如果上述命令失败，Cephadm 没有密钥。要生成 SSH 密钥，请运行以下命令：
示例
[ceph: root@host01 /]# chmod 0600 ~/cephadm_private_key
或者
示例
[ceph: root@host01 /]# cat ~/cephadm_private_key | ceph cephadm set-ssk-key -i-
要确保 SSH 配置正确，请运行以下命令：
示例
[ceph: root@host01 /]# ceph cephadm get-ssh-config
要验证与主机的连接，请运行以下命令：
示例
[ceph: root@host01 /]# ssh -F config -i ~/cephadm_private_key root@host01
验证公钥是否在 authorized_keys 中。
要验证公钥是否在 authorized_keys 文件中，请运行以下命令：
示例
[ceph: root@host01 /]# ceph cephadm get-pub-key [ceph: root@host01 /]# grep "`cat ~/ceph.pub`" /root/.ssh/authorized_keys
11.9. CIDR 网络错误
无类别域路由(CIDR)也称为超级网络域路由，是一种分配互联网协议(IP)地址的方法，Fthe Cephadm 日志条目显示当前状态，以基于类 A、类 B 和 Class C 网络来提高了地址分发效率，并替换之前系统。如果您看到以下错误之一：
ERROR: Failed to infer CIDR network for mon ip *; pass --skip-mon-network to configure it later
或者
Must set public_network config option or specify a CIDR network, ceph addrvec, or plain IP
您需要运行以下命令：
示例
[ceph: root@host01 /]# ceph config set host public_network hostnetwork
11.10. 访问管理 socket
每个 Ceph 守护进程都提供一个可绕过 MON 的管理 socket。
要访问管理套接字，请输入主机上的守护进程容器：
示例
[ceph: root@host01 /]# cephadm enter --name cephfs.hostname.ppdhsz [ceph: root@mon1 /]# ceph --admin-daemon /var/run/ceph/ceph-cephfs.hostname.ppdhsz.asok config show
11.11. 手动部署 mgr 守护进程
Cephadm 需要 mgr 守护进程来管理 Red Hat Ceph Storage 集群。如果删除了 Red Hat Ceph Storage 集群的最后一个 mgr 守护进程，您可以在 Red Hat Ceph Storage 集群随机主机上手动部署 mgr 守护进程。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 所有节点的根级别访问权限。
- 主机添加到集群中。
流程
登录到 Cephadm shell：
示例
[root@host01 ~]# cephadm shell
禁用 Cephadm 调度程序，以使用以下命令防止 Cephadm 删除新的 MGR 守护进程：
示例
[ceph: root@host01 /]# ceph config-key set mgr/cephadm/pause true
获取或为新 MGR 守护进程创建
auth条目：示例
[ceph: root@host01 /]# ceph auth get-or-create mgr.host01.smfvfd1 mon "profile mgr" osd "allow *" mds "allow *" [mgr.host01.smfvfd1] key = AQDhcORgW8toCRAAlMzlqWXnh3cGRjqYEa9ikw==
打开
ceph.conf文件：示例
[ceph: root@host01 /]# ceph config generate-minimal-conf # minimal ceph.conf for 8c9b0072-67ca-11eb-af06-001a4a0002a0 [global] fsid = 8c9b0072-67ca-11eb-af06-001a4a0002a0 mon_host = [v2:10.10.200.10:3300/0,v1:10.10.200.10:6789/0] [v2:10.10.10.100:3300/0,v1:10.10.200.100:6789/0]
获取容器镜像：
示例
[ceph: root@host01 /]# ceph config get "mgr.host01.smfvfd1" container_image
创建
config-json.json文件并添加以下内容：注意使用
ceph config generate-minimal-conf命令的输出中的值。示例
{ { "config": "# minimal ceph.conf for 8c9b0072-67ca-11eb-af06-001a4a0002a0\n[global]\n\tfsid = 8c9b0072-67ca-11eb-af06-001a4a0002a0\n\tmon_host = [v2:10.10.200.10:3300/0,v1:10.10.200.10:6789/0] [v2:10.10.10.100:3300/0,v1:10.10.200.100:6789/0]\n", "keyring": "[mgr.Ceph5-2.smfvfd1]\n\tkey = AQDhcORgW8toCRAAlMzlqWXnh3cGRjqYEa9ikw==\n" } }从 Cephadm shell 退出：
示例
[ceph: root@host01 /]# exit
部署 MGR 守护进程：
示例
[root@host01 ~]# cephadm --image registry.redhat.io/rhceph-alpha/rhceph-5-rhel8:latest deploy --fsid 8c9b0072-67ca-11eb-af06-001a4a0002a0 --name mgr.host01.smfvfd1 --config-json config-json.json
验证
在 Cephadm shell 中，运行以下命令：
示例
[ceph: root@host01 /]# ceph -s
您可以看到新的 mgr 守护进程已被添加。
第 12 章 Cephadm 操作
作为存储管理员，您可以在 Red Hat Ceph Storage 集群中执行 Cephadm 操作。
12.1. 先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
12.2. 监控 cephadm 日志消息
Cephadm 日志到 cephadm 集群日志频道，以便您可以实时监控进度。
要实时监控进度，请运行以下命令：
示例
[ceph: root@host01 /]# ceph -W cephadm
示例
2022-06-10T17:51:36.335728+0000 mgr.Ceph5-1.nqikfh [INF] refreshing Ceph5-adm facts 2022-06-10T17:51:37.170982+0000 mgr.Ceph5-1.nqikfh [INF] deploying 1 monitor(s) instead of 2 so monitors may achieve consensus 2022-06-10T17:51:37.173487+0000 mgr.Ceph5-1.nqikfh [ERR] It is NOT safe to stop ['mon.Ceph5-adm']: not enough monitors would be available (Ceph5-2) after stopping mons [Ceph5-adm] 2022-06-10T17:51:37.174415+0000 mgr.Ceph5-1.nqikfh [INF] Checking pool "nfs-ganesha" exists for service nfs.foo 2022-06-10T17:51:37.176389+0000 mgr.Ceph5-1.nqikfh [ERR] Failed to apply nfs.foo spec NFSServiceSpec({'placement': PlacementSpec(count=1), 'service_type': 'nfs', 'service_id': 'foo', 'unmanaged': False, 'preview_only': False, 'pool': 'nfs-ganesha', 'namespace': 'nfs-ns'}): Cannot find pool "nfs-ganesha" for service nfs.foo Traceback (most recent call last): File "/usr/share/ceph/mgr/cephadm/serve.py", line 408, in _apply_all_services if self._apply_service(spec): File "/usr/share/ceph/mgr/cephadm/serve.py", line 509, in _apply_service config_func(spec) File "/usr/share/ceph/mgr/cephadm/services/nfs.py", line 23, in config self.mgr._check_pool_exists(spec.pool, spec.service_name()) File "/usr/share/ceph/mgr/cephadm/module.py", line 1840, in _check_pool_exists raise OrchestratorError(f'Cannot find pool "{pool}" for ' orchestrator._interface.OrchestratorError: Cannot find pool "nfs-ganesha" for service nfs.foo 2022-06-10T17:51:37.179658+0000 mgr.Ceph5-1.nqikfh [INF] Found osd claims -> {} 2022-06-10T17:51:37.180116+0000 mgr.Ceph5-1.nqikfh [INF] Found osd claims for drivegroup all-available-devices -> {} 2022-06-10T17:51:37.182138+0000 mgr.Ceph5-1.nqikfh [INF] Applying all-available-devices on host Ceph5-adm... 2022-06-10T17:51:37.182987+0000 mgr.Ceph5-1.nqikfh [INF] Applying all-available-devices on host Ceph5-1... 2022-06-10T17:51:37.183395+0000 mgr.Ceph5-1.nqikfh [INF] Applying all-available-devices on host Ceph5-2... 2022-06-10T17:51:43.373570+0000 mgr.Ceph5-1.nqikfh [INF] Reconfiguring node-exporter.Ceph5-1 (unknown last config time)... 2022-06-10T17:51:43.373840+0000 mgr.Ceph5-1.nqikfh [INF] Reconfiguring daemon node-exporter.Ceph5-1 on Ceph5-1默认情况下，日志会显示信息级事件及更高版本。要查看调试级别信息，请运行以下命令：
示例
[ceph: root@host01 /]# ceph config set mgr mgr/cephadm/log_to_cluster_level debug [ceph: root@host01 /]# ceph -W cephadm --watch-debug [ceph: root@host01 /]# ceph -W cephadm --verbose
将调试级别恢复为默认
信息：示例
[ceph: root@host01 /]# ceph config set mgr mgr/cephadm/log_to_cluster_level info
要查看最近的事件，请运行以下命令：
示例
[ceph: root@host01 /]# ceph log last cephadm
这些事件也记录到监控器主机上的 ceph.cephadm.log 文件，以及 monitor 守护进程的 stderr
12.3. Ceph 守护进程日志
您可以通过 stderr 或文件查看 Ceph 守护进程日志。
将日志输出到 stdout
传统上，Ceph 守护进程已记录到 /var/log/ceph。默认情况下，Cephadm 守护进程将日志记录到 stderr，日志由容器运行时环境捕获。对于大多数系统，默认情况下，这些日志发送到 journald，并可通过 journalctl 命令访问。
例如，为 ID 为 5c5a50ae-272a-455d-99e9-32c6a013e694 的存储集群查看 host01 上守护进程的日志：
示例
[ceph: root@host01 /]# journalctl -u ceph-5c5a50ae-272a-455d-99e9-32c6a013e694@host01
这在日志级别较低时，这适用于正常的 Cephadm 操作。
要禁用日志记录到
stderr，请设置以下值：示例
[ceph: root@host01 /]# ceph config set global log_to_stderr false [ceph: root@host01 /]# ceph config set global mon_cluster_log_to_stderr false
登录到文件
您也可以将 Ceph 守护进程配置为记录到文件，而非 stderr。在登录到文件时，Ceph 日志位于 /var/log/ceph/CLUSTER_FSID 中。
要启用日志记录到文件，设置以下值：
示例
[ceph: root@host01 /]# ceph config set global log_to_file true [ceph: root@host01 /]# ceph config set global mon_cluster_log_to_file true
红帽建议禁用日志记录到 stderr，以避免重复日志。
目前不支持将轮转日志到非默认路径。
默认情况下，Cephadm 在每一主机上设置日志轮转，以轮换这些文件。您可以通过修改 /etc/logrotate.d/ceph.CLUSTER_FSID 来配置日志记录保留调度。
12.4. 数据位置
Cephadm 守护进程数据和日志位于与较旧版本的 Ceph 相比稍有不同的位置：
-
/var/log/ceph/CLUSTER_FSID包含所有存储集群日志。请注意，默认情况下，Cephadm 日志会导向stderr和容器运行时，因此通常不会保存这些日志。 -
/var/lib/ceph/CLUSTER_FSID包含所有集群守护进程数据，除了日志之外。 -
var/lib/ceph/CLUSTER_FSID/DAEMON_NAME包含特定守护进程的所有数据。 -
/var/lib/ceph/CLUSTER_FSID/crash包含存储集群的崩溃报告。 -
/var/lib/ceph/CLUSTER_FSID/removed包含有状态守护进程的旧守护进程数据目录，如 monitor 或 Prometheus，已被 Cephadm 删除。
磁盘用量
一些 Ceph 守护进程可能会将大量数据存储在 /var/lib/ceph 中，特别是 monitor 和 Prometheus 守护进程，因此红帽建议将该目录移到自己的磁盘、分区或逻辑卷中，以便 root 文件系统不会被填充。
12.5. Cephadm 健康检查
作为存储管理员，您可以使用 Cephadm 模块提供的额外健康检查来监控 Red Hat Ceph Storage 集群。这是存储集群提供的默认健康检查补充。
12.5.1. 先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
12.5.2. Cephadm 操作健康检查
当 Cephadm 模块激活时，将执行健康检查。您可获取以下健康警告：
CEPHADM_PAUSED
Cephadm 后台工作可以使用 ceph orch pause 命令暂停。Cephadm 继续执行被动监控活动，如检查主机和守护进程状态，但它不会像部署或移除守护进程一样进行任何更改。您可以使用 ceph orch resume 命令恢复 Cephadm 工作。
CEPHADM_STRAY_HOST
一个或多个主机正在运行 Ceph 守护进程，但没有作为由 Cephadm 模块管理的主机注册。这意味着这些服务目前不由 Cephadm 管理，例如，ceph orch ps 命令中包含的重启和升级。您可以使用 ceph orch host add HOST_NAME 命令来管理主机，但请确保已配置了对远程主机的 SSH 访问。或者，您可以手动连接到主机，并确保该主机上的服务被删除或迁移到由 Cephadm 管理的主机。您还可以使用设置 ceph config set mgr/cephadm/warn_on_stray_hosts false来禁用这一警告
CEPHADM_STRAY_DAEMON
一个或多个 Ceph 守护进程正在运行，但不由 Cephadm 模块管理。这可能是因为使用其他工具部署，或者因为手动启动它们。这些服务目前不由 Cephadm 管理，例如，ceph orch ps 命令中包含的重启和升级。
如果守护进程是 monitor 或 OSD 守护进程的有状态，则 Cephadm 应该采用这些守护进程。对于无状态守护进程，您可以使用 ceph orch apply 命令置备新的守护进程，然后停止非受管守护进程。
您可以通过设置 ceph config set mgr/cephadm/warn_on_stray_daemons false 来禁用此运行状况警告。
CEPHADM_HOST_CHECK_FAILED
对一个或多个主机的基本 Cephadm 主机检查（验证 that:name: 值）失败。
- 主机可以访问，您可以执行 Cephadm。
- 主机满足基本先决条件，如作为 Podman 的工作容器运行时和工作时间同步。如果测试失败，Cephadm 将无法管理该主机上的服务。
您可以使用 ceph cephadm check-host HOST_NAME 命令手动运行此检查。您可以使用 ceph orch host rm HOST_NAME 命令从管理中删除损坏的主机。您可以通过设置 ceph config set mgr/cephadm/warn_on_failed_host_check false 来禁用此运行状况警告。
12.5.3. Cephadm 配置健康检查
Cephadm 定期扫描存储集群中的每个主机，以了解操作系统、磁盘和 NIC 的状态。这些事实分析为存储集群中主机的一致性，以识别任何配置。配置检查是一个可选功能。
您可以使用以下命令启用此功能：
示例
[ceph: root@host01 /]# ceph config set mgr mgr/cephadm/config_checks_enabled true
配置检查会在每个主机扫描后触发，这是一分钟的持续时间。
ceph -W cephadm命令显示配置检查的当前状态和结果，如下所示：禁用状态
示例
ALL cephadm checks are disabled, use 'ceph config set mgr mgr/cephadm/config_checks_enabled true' to enable
启用状态
示例
CEPHADM 8/8 checks enabled and executed (0 bypassed, 0 disabled). No issues detected
配置检查本身通过多个
cephadm子命令进行管理。要确定配置检查是否已启用，请运行以下命令：
示例
[ceph: root@host01 /]# ceph cephadm config-check status
此命令将配置检查器的状态返回为 Enabled 或 Disabled。
要列出所有配置检查及其状态，请运行以下命令：
示例
[ceph: root@host01 /]# ceph cephadm config-check ls NAME HEALTHCHECK STATUS DESCRIPTION kernel_security CEPHADM_CHECK_KERNEL_LSM enabled checks SELINUX/Apparmor profiles are consistent across cluster hosts os_subscription CEPHADM_CHECK_SUBSCRIPTION enabled checks subscription states are consistent for all cluster hosts public_network CEPHADM_CHECK_PUBLIC_MEMBERSHIP enabled check that all hosts have a NIC on the Ceph public_netork osd_mtu_size CEPHADM_CHECK_MTU enabled check that OSD hosts share a common MTU setting osd_linkspeed CEPHADM_CHECK_LINKSPEED enabled check that OSD hosts share a common linkspeed network_missing CEPHADM_CHECK_NETWORK_MISSING enabled checks that the cluster/public networks defined exist on the Ceph hosts ceph_release CEPHADM_CHECK_CEPH_RELEASE enabled check for Ceph version consistency - ceph daemons should be on the same release (unless upgrade is active) kernel_version CEPHADM_CHECK_KERNEL_VERSION enabled checks that the MAJ.MIN of the kernel on Ceph hosts is consistent
每个配置检查都如下所述：
CEPHADM_CHECK_KERNEL_LSM
存储集群中的每个主机预期在同一 Linux 安全模块(LSM)状态内。例如，如果大多数主机以 enforcing 模式使用 SELINUX 运行，则任何没有在这个模式下运行的主机都将标记为 anomaly，并且会引发警告状态的健康检查。
CEPHADM_CHECK_SUBSCRIPTION
此检查与供应商订阅的状态相关。此检查仅针对使用 Red Hat Enterprise Linux 的主机执行，但有助于确认所有主机都由有效订阅涵盖，以便可以使用补丁和更新。
CEPHADM_CHECK_PUBLIC_MEMBERSHIP
集群的所有成员都应该在至少一个公共网络子网上配置了 NIC。没有处于公共网络上的主机将会依赖于路由，这可能会影响性能。
CEPHADM_CHECK_MTU
OSD 上 NIC 的最大传输单元(MTU)可以是一致性能的关键因素。此检查检查运行 OSD 服务的主机，以确保该 MTU 在集群内一致配置。这通过建立大多数主机正在使用的 MTU 设置来确定，任何异常情况会导致 Ceph 健康检查。
CEPHADM_CHECK_LINKSPEED
与 MTU 检查类似，链接速度一致性也是集群性能的因素。此检查决定了大多数 OSD 主机共享的链路速度，从而对以较低链接速度设置的主机进行健康检查。
CEPHADM_CHECK_NETWORK_MISSING
public_network 和 cluster_network 设置支持 IPv4 和 IPv6 的子网定义。如果在存储集群的任何主机上找不到这些设置，则会引发健康检查。
CEPHADM_CHECK_CEPH_RELEASE
在正常操作下，Ceph 集群应在相同的 Ceph 发行版本中运行守护进程，如所有 Red Hat Ceph Storage 集群 5 版本。此检查将查看每个守护进程的活动发行版本，并报告任何异常情况作为健康检查。如果升级过程在集群内处于活跃状态，则会绕过这个检查。
CEPHADM_CHECK_KERNEL_VERSION
检查 OS 内核版本，以实现主机之间的一致性。再次使用大多数主机来识别异常情况。
第 13 章 使用 cephadm-ansible 模块管理 Red Hat Ceph Storage 集群
作为存储管理员，您可以在 Ansible playbook 中使用 cephadm-ansible 模块来管理 Red Hat Ceph Storage 集群。cephadm-ansible 软件包提供了几个模块，可换行 cephadm 调用，以便您编写自己的 Ansible playbook 来管理集群。
目前，cephadm-ansible 模块仅支持最重要的任务。cephadm-ansible 模块未涵盖的任何操作都必须通过在 playbook 中使用 命令或 shell Ansible 模块来完成。
13.1. cephadm-ansible 模块
cephadm-ansible 模块是模块的集合，通过提供围绕 cephadm 和 ceph orch 命令的打包程序来简化 Ansible playbook 的编写。您可以使用模块自行编写 Ansible playbook，以通过一个或多个模块来管理集群。
cephadm-ansible 软件包包括以下模块：
-
cephadm_bootstrap -
ceph_orch_host -
ceph_config -
ceph_orch_apply -
ceph_orch_daemon -
cephadm_registry_login
13.2. cephadm-ansible 模块选项
下表列出了 cephadm-ansible 模块的可用选项。在使用 Ansible playbook 中的模块时，需要设置列出的选项。带有默认值 true 中列出的选项表示在使用模块时会自动设置该选项，而您不需要在 playbook 中指定该选项。例如，对于 cephadm_bootstrap 模块，将安装 Ceph 仪表板，除非设置了 dashboard: false。
cephadm_bootstrap | 描述 | 必填 | 默认 |
|---|---|---|---|
|
| Ceph 监控 IP 地址。 | true | |
|
| Ceph 容器镜像。 | false | |
|
|
使用 | false | |
|
| 定义 Ceph FSID。 | false | |
|
| 拉取 Ceph 容器镜像。 | false | true |
|
| 部署 Ceph 仪表板。 | false | true |
|
| 指定特定的 Ceph Dashboard 用户。 | false | |
|
| Ceph 仪表板密码。 | false | |
|
| 部署监控堆栈。 | false | true |
|
| 使用 firewalld 管理防火墙规则。 | false | true |
|
| 允许覆盖现有 --output-config、--output-keyring 或 --output-pub-ssh-key 文件。 | false | false |
|
| 自定义 registry 的 URL。 | false | |
|
| 自定义 registry 的用户名。 | false | |
|
| 自定义 registry 的密码。 | false | |
|
| 具有自定义 registry 登录信息的 JSON 文件。 | false | |
|
|
用于 | false | |
|
|
| false | |
|
| allow hostname，它是一个完全限定域名(FQDN)。 | false | false |
|
| 用于集群复制、恢复和心跳的子网。 | false |
ceph_orch_host | 描述 | 必填 | 默认 |
|---|---|---|---|
|
| 要与之交互的 Ceph 集群的 FSID。 | false | |
|
| 要使用的 Ceph 容器镜像。 | false | |
|
| 要添加、删除或更新的主机的名称。 | true | |
|
| 主机的 IP 地址。 |
真（当 | |
|
|
在指定主机上设置 | false | false |
|
| 要应用到主机的标签列表。 | false | [] |
|
|
如果设为 | false | 存在 |
ceph_config | 描述 | 必填 | 默认 |
|---|---|---|---|
|
| 要与之交互的 Ceph 集群的 FSID。 | false | |
|
| 要使用的 Ceph 容器镜像。 | false | |
|
|
是否 | false | set |
|
| 哪个守护进程将配置设置为。 | true | |
|
|
要进行 | true | |
|
| 要设置的参数值。 |
|
ceph_orch_apply | 描述 | 必填 |
|---|---|---|
|
| 要与之交互的 Ceph 集群的 FSID。 | false |
|
| 要使用的 Ceph 容器镜像。 | false |
|
| 要应用的服务规格。 | true |
ceph_orch_daemon | 描述 | 必填 |
|---|---|---|
|
| 要与之交互的 Ceph 集群的 FSID。 | false |
|
| 要使用的 Ceph 容器镜像。 | false |
|
|
在 | true
如果
如果
如果 |
|
| 服务的 ID。 | true |
|
| 服务的类型。 | true |
cephadm_registry_login | 描述 | 必填 | 默认 |
|---|---|---|---|
|
| 登录或注销 registry。 | false | login |
|
|
使用 | false | |
|
| 自定义 registry 的 URL。 | false | |
|
| 自定义 registry 的用户名。 |
当 | |
|
| 自定义 registry 的密码。 |
当 | |
|
| JSON 文件的路径。在运行此任务前，该文件必须存在于远程主机上。目前不支持这个选项。 |
13.3. 使用 cephadm_bootstrap 和 cephadm_registry_login 模块引导存储集群
作为存储管理员，您可以使用 Ansible 中的 cephadm_bootstrap 和 cephadm_registry_login 模块来引导存储集群。
先决条件
- 第一个 Ceph 监控容器的 IP 地址，也是存储集群中第一个节点的 IP 地址。
-
登录到
registry.redhat.io。 -
至少 10 GB 的可用空间用于
/var/lib/containers/。 - Red Hat Enterprise Linux 8.4 EUS 或 Red Hat Enterprise Linux 8.5。
-
在 Ansible 管理节点上安装
cephadm-ansible软件包。 - 在存储集群的所有主机上设置免密码 SSH。
- 主机通过 CDN 注册。
流程
- 登录 Ansible 管理节点。
进入 Ansible 管理节点上的
/usr/share/cephadm-ansible目录：示例
[ceph-admin@admin ~]$ cd /usr/share/cephadm-ansible
创建
hosts文件并添加主机、标签和监控存储集群中第一个主机的 IP 地址：语法
sudo vi INVENTORY_FILE HOST1 labels="['LABEL1', 'LABEL2']" HOST2 labels="['LABEL1', 'LABEL2']" HOST3 labels="['LABEL1']" [admin] ADMIN_HOST monitor_address=MONITOR_IP_ADDRESS labels="['ADMIN_LABEL', 'LABEL1', 'LABEL2']"
示例
[ceph-admin@admin cephadm-ansible]$ sudo vi hosts host02 labels="['mon', 'mgr']" host03 labels="['mon', 'mgr']" host04 labels="['osd']" host05 labels="['osd']" host06 labels="['osd']" [admin] host01 monitor_address=10.10.128.68 labels="['_admin', 'mon', 'mgr']"
运行 preflight playbook：
语法
ansible-playbook -i INVENTORY_FILE cephadm-preflight.yml --extra-vars "ceph_origin=rhcs"示例
[ceph-admin@admin cephadm-ansible]$ ansible-playbook -i hosts cephadm-preflight.yml --extra-vars "ceph_origin=rhcs"
创建用于引导集群的 playbook：
语法
sudo vi PLAYBOOK_FILENAME.yml --- - name: NAME_OF_PLAY hosts: BOOTSTRAP_HOST become: USE_ELEVATED_PRIVILEGES gather_facts: GATHER_FACTS_ABOUT_REMOTE_HOSTS tasks: -name: NAME_OF_TASK cephadm_registry_login: state: STATE registry_url: REGISTRY_URL registry_username: REGISTRY_USER_NAME registry_password: REGISTRY_PASSWORD - name: NAME_OF_TASK cephadm_bootstrap: mon_ip: "{{ monitor_address }}" dashboard_user: DASHBOARD_USER dashboard_password: DASHBOARD_PASSWORD allow_fqdn_hostname: ALLOW_FQDN_HOSTNAME cluster_network: NETWORK_CIDR
示例
[ceph-admin@admin cephadm-ansible]$ sudo vi bootstrap.yml --- - name: bootstrap the cluster hosts: host01 become: true gather_facts: false tasks: - name: login to registry cephadm_registry_login: state: login registry_url: registry.redhat.io registry_username: user1 registry_password: mypassword1 - name: bootstrap initial cluster cephadm_bootstrap: mon_ip: "{{ monitor_address }}" dashboard_user: mydashboarduser dashboard_password: mydashboardpassword allow_fqdn_hostname: true cluster_network: 10.10.128.0/28运行 playbook：
语法
ansible-playbook -i INVENTORY_FILE PLAYBOOK_FILENAME.yml -vvv
示例
[ceph-admin@admin cephadm-ansible]$ ansible-playbook -i hosts bootstrap.yml -vvv
验证
- 运行 playbook 后检查 Ansible 输出。
13.4. 使用 ceph_orch_host 模块添加或删除主机
作为存储管理员，您可以使用 Ansible playbook 中的 ceph_orch_host 模块来添加和删除存储集群中的主机。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 将节点注册到 CDN 并附加订阅。
- 具有 sudo 的 Ansible 用户，对存储集群中的所有节点进行免密码 SSH 访问。
-
在 Ansible 管理节点上安装
cephadm-ansible软件包。 - 新主机具有存储集群的公共 SSH 密钥。有关将存储集群的公共 SSH 密钥复制到新主机的更多信息，请参阅 Red Hat Ceph Storage 安装指南中的 添加主机。
流程
使用以下步骤在集群中添加新主机：
- 登录 Ansible 管理节点。
进入 Ansible 管理节点上的
/usr/share/cephadm-ansible目录：示例
[ceph-admin@admin ~]$ cd /usr/share/cephadm-ansible
将新主机和标签添加到 Ansible 清单文件。
语法
sudo vi INVENTORY_FILE NEW_HOST1 labels="['LABEL1', 'LABEL2']" NEW_HOST2 labels="['LABEL1', 'LABEL2']" NEW_HOST3 labels="['LABEL1']" [admin] ADMIN_HOST monitor_address=MONITOR_IP_ADDRESS labels="['ADMIN_LABEL', 'LABEL1', 'LABEL2']"
示例
[ceph-admin@admin cephadm-ansible]$ sudo vi hosts host02 labels="['mon', 'mgr']" host03 labels="['mon', 'mgr']" host04 labels="['osd']" host05 labels="['osd']" host06 labels="['osd']" [admin] host01 monitor_address= 10.10.128.68 labels="['_admin', 'mon', 'mgr']"
注意如果您之前已将新主机添加到 Ansible 清单文件，并在主机上运行 preflight playbook，请跳至第 3 步。
使用
--limit选项运行 preflight playbook：语法
ansible-playbook -i INVENTORY_FILE cephadm-preflight.yml --extra-vars "ceph_origin=rhcs" --limit NEWHOST
示例
[ceph-admin@admin cephadm-ansible]$ ansible-playbook -i hosts cephadm-preflight.yml --extra-vars "ceph_origin=rhcs" --limit host02
preflight playbook 在新主机上安装
podman、lvm2、chronyd和cephadm。安装完成后，cephadm驻留在/usr/sbin/目录中。创建一个 playbook，将新主机添加到集群中：
语法
sudo vi PLAYBOOK_FILENAME.yml --- - name: PLAY_NAME hosts: HOSTS_OR_HOST_GROUPS become: USE_ELEVATED_PRIVILEGES gather_facts: GATHER_FACTS_ABOUT_REMOTE_HOSTS tasks: - name: NAME_OF_TASK ceph_orch_host: name: "{{ ansible_facts['hostname'] }}" address: "{{ ansible_facts['default_ipv4']['address'] }}" labels: "{{ labels }}" delegate_to: HOST_TO_DELEGATE_TASK_TO - name: NAME_OF_TASK when: inventory_hostname in groups['admin'] ansible.builtin.shell: cmd: CEPH_COMMAND_TO_RUN register: REGISTER_NAME - name: NAME_OF_TASK when: inventory_hostname in groups['admin'] debug: msg: "{{ REGISTER_NAME.stdout }}"
注意默认情况下，Ansible 在与 playbook 的
hosts行匹配的主机上执行所有任务。ceph orch命令必须在包含 admin keyring 和 Ceph 配置文件的主机上运行。使用delegate_to关键字指定集群中的 admin 主机。示例
[ceph-admin@admin cephadm-ansible]$ sudo vi add-hosts.yml --- - name: add additional hosts to the cluster hosts: all become: true gather_facts: true tasks: - name: add hosts to the cluster ceph_orch_host: name: "{{ ansible_facts['hostname'] }}" address: "{{ ansible_facts['default_ipv4']['address'] }}" labels: "{{ labels }}" delegate_to: host01 - name: list hosts in the cluster when: inventory_hostname in groups['admin'] ansible.builtin.shell: cmd: ceph orch host ls register: host_list - name: print current list of hosts when: inventory_hostname in groups['admin'] debug: msg: "{{ host_list.stdout }}"在本例中，playbook 将新主机添加到集群中，并显示当前的主机列表。
运行 playbook，向集群添加额外的主机：
语法
ansible-playbook -i INVENTORY_FILE PLAYBOOK_FILENAME.yml
示例
[ceph-admin@admin cephadm-ansible]$ ansible-playbook -i hosts add-hosts.yml
使用以下步骤从集群中删除主机：
- 登录 Ansible 管理节点。
进入 Ansible 管理节点上的
/usr/share/cephadm-ansible目录：示例
[ceph-admin@admin ~]$ cd /usr/share/cephadm-ansible
创建 playbook 以从集群中删除主机或主机：
语法
sudo vi PLAYBOOK_FILENAME.yml --- - name: NAME_OF_PLAY hosts: ADMIN_HOST become: USE_ELEVATED_PRIVILEGES gather_facts: GATHER_FACTS_ABOUT_REMOTE_HOSTS tasks: - name: NAME_OF_TASK ceph_orch_host: name: HOST_TO_REMOVE state: STATE - name: NAME_OF_TASK ceph_orch_host: name: HOST_TO_REMOVE state: STATE retries: NUMBER_OF_RETRIES delay: DELAY until: CONTINUE_UNTIL register: REGISTER_NAME - name: NAME_OF_TASK ansible.builtin.shell: cmd: ceph orch host ls register: REGISTER_NAME - name: NAME_OF_TASK debug: msg: "{{ REGISTER_NAME.stdout }}"
示例
[ceph-admin@admin cephadm-ansible]$ sudo vi remove-hosts.yml --- - name: remove host hosts: host01 become: true gather_facts: true tasks: - name: drain host07 ceph_orch_host: name: host07 state: drain - name: remove host from the cluster ceph_orch_host: name: host07 state: absent retries: 20 delay: 1 until: result is succeeded register: result - name: list hosts in the cluster ansible.builtin.shell: cmd: ceph orch host ls register: host_list - name: print current list of hosts debug: msg: "{{ host_list.stdout }}"在本例中，playbook 任务排空
host07上的所有守护进程，从集群中移除主机，并显示当前的主机列表。运行 playbook，从集群中删除主机：
语法
ansible-playbook -i INVENTORY_FILE PLAYBOOK_FILENAME.yml
示例
[ceph-admin@admin cephadm-ansible]$ ansible-playbook -i hosts remove-hosts.yml
验证
查看 Ansible 任务输出，显示集群中的当前主机列表：
示例
TASK [print current hosts] ****************************************************************************************************** Friday 24 June 2022 14:52:40 -0400 (0:00:03.365) 0:02:31.702 *********** ok: [host01] => msg: |- HOST ADDR LABELS STATUS host01 10.10.128.68 _admin mon mgr host02 10.10.128.69 mon mgr host03 10.10.128.70 mon mgr host04 10.10.128.71 osd host05 10.10.128.72 osd host06 10.10.128.73 osd
13.5. 使用 ceph_config 模块设置配置选项
作为存储管理员，您可以使用 ceph_config 模块设置或获取 Red Hat Ceph Storage 配置选项。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 具有 sudo 的 Ansible 用户，对存储集群中的所有节点进行免密码 SSH 访问。
-
在 Ansible 管理节点上安装
cephadm-ansible软件包。 - Ansible 清单文件包含集群和 admin 主机。
流程
- 登录 Ansible 管理节点。
进入 Ansible 管理节点上的
/usr/share/cephadm-ansible目录：示例
[ceph-admin@admin ~]$ cd /usr/share/cephadm-ansible
创建带有配置更改的 playbook：
语法
sudo vi PLAYBOOK_FILENAME.yml --- - name: PLAY_NAME hosts: ADMIN_HOST become: USE_ELEVATED_PRIVILEGES gather_facts: GATHER_FACTS_ABOUT_REMOTE_HOSTS tasks: - name: NAME_OF_TASK ceph_config: action: GET_OR_SET who: DAEMON_TO_SET_CONFIGURATION_TO option: CEPH_CONFIGURATION_OPTION value: VALUE_OF_PARAMETER_TO_SET - name: NAME_OF_TASK ceph_config: action: GET_OR_SET who: DAEMON_TO_SET_CONFIGURATION_TO option: CEPH_CONFIGURATION_OPTION register: REGISTER_NAME - name: NAME_OF_TASK debug: msg: "MESSAGE_TO_DISPLAY {{ REGISTER_NAME.stdout }}"
示例
[ceph-admin@admin cephadm-ansible]$ sudo vi change_configuration.yml --- - name: set pool delete hosts: host01 become: true gather_facts: false tasks: - name: set the allow pool delete option ceph_config: action: set who: mon option: mon_allow_pool_delete value: true - name: get the allow pool delete setting ceph_config: action: get who: mon option: mon_allow_pool_delete register: verify_mon_allow_pool_delete - name: print current mon_allow_pool_delete setting debug: msg: "the value of 'mon_allow_pool_delete' is {{ verify_mon_allow_pool_delete.stdout }}"在本例中，playbook 首先将
mon_allow_pool_delete选项设置为false。然后，playbook 获取当前的mon_allow_pool_delete设置，并在 Ansible 输出中显示值。运行 playbook：
语法
ansible-playbook -i INVENTORY_FILE _PLAYBOOK_FILENAME.yml示例
[ceph-admin@admin cephadm-ansible]$ ansible-playbook -i hosts change_configuration.yml
验证
检查 playbook 任务的输出。
示例
TASK [print current mon_allow_pool_delete setting] ************************************************************* Wednesday 29 June 2022 13:51:41 -0400 (0:00:05.523) 0:00:17.953 ******** ok: [host01] => msg: the value of 'mon_allow_pool_delete' is true
其它资源
- 如需更多配置选项的详细信息，请参阅 Red Hat Ceph Storage 配置指南。
13.6. 使用 ceph_orch_apply 模块应用服务规格
作为存储管理员，您可以使用 Ansible playbook 中的 ceph_orch_apply 模块将服务规格应用到存储集群。服务规格是一个数据结构，它指定用于部署 Ceph 服务的服务属性和配置设置。您可以使用服务规格来部署 Ceph 服务类型，如 mon、crash、mds、mgr、osd、rdb 或 rbd-mirror。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 具有 sudo 的 Ansible 用户，对存储集群中的所有节点进行免密码 SSH 访问。
-
在 Ansible 管理节点上安装
cephadm-ansible软件包。 - Ansible 清单文件包含集群和 admin 主机。
流程
- 登录 Ansible 管理节点。
进入 Ansible 管理节点上的
/usr/share/cephadm-ansible目录：示例
[ceph-admin@admin ~]$ cd /usr/share/cephadm-ansible
使用服务规格创建 playbook：
语法
sudo vi PLAYBOOK_FILENAME.yml --- - name: PLAY_NAME hosts: HOSTS_OR_HOST_GROUPS become: USE_ELEVATED_PRIVILEGES gather_facts: GATHER_FACTS_ABOUT_REMOTE_HOSTS tasks: - name: NAME_OF_TASK ceph_orch_apply: spec: | service_type: SERVICE_TYPE service_id: UNIQUE_NAME_OF_SERVICE placement: host_pattern: 'HOST_PATTERN_TO_SELECT_HOSTS' label: LABEL spec: SPECIFICATION_OPTIONS:
示例
[ceph-admin@admin cephadm-ansible]$ sudo vi deploy_osd_service.yml --- - name: deploy osd service hosts: host01 become: true gather_facts: true tasks: - name: apply osd spec ceph_orch_apply: spec: | service_type: osd service_id: osd placement: host_pattern: '*' label: osd spec: data_devices: all: true在本例中，playbook 将 Ceph OSD 服务部署到所有具有标签
osd的主机。运行 playbook：
语法
ansible-playbook -i INVENTORY_FILE _PLAYBOOK_FILENAME.yml示例
[ceph-admin@admin cephadm-ansible]$ ansible-playbook -i hosts deploy_osd_service.yml
验证
- 检查 playbook 任务的输出。
其它资源
- 如需了解更多有关服务规格选项的详细信息，请参阅 Red Hat Ceph Storage Operations 指南。
13.7. 使用 ceph_orch_daemon 模块管理 Ceph 守护进程状态
作为存储管理员，您可以使用 Ansible playbook 中的 ceph_orch_daemon 模块在主机上启动、停止和重启 Ceph 守护进程。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 具有 sudo 的 Ansible 用户，对存储集群中的所有节点进行免密码 SSH 访问。
-
在 Ansible 管理节点上安装
cephadm-ansible软件包。 - Ansible 清单文件包含集群和 admin 主机。
流程
- 登录 Ansible 管理节点。
进入 Ansible 管理节点上的
/usr/share/cephadm-ansible目录：示例
[ceph-admin@admin ~]$ cd /usr/share/cephadm-ansible
创建带有守护进程状态更改的 playbook：
语法
sudo vi PLAYBOOK_FILENAME.yml --- - name: PLAY_NAME hosts: ADMIN_HOST become: USE_ELEVATED_PRIVILEGES gather_facts: GATHER_FACTS_ABOUT_REMOTE_HOSTS tasks: - name: NAME_OF_TASK ceph_orch_daemon: state: STATE_OF_SERVICE daemon_id: DAEMON_ID daemon_type: TYPE_OF_SERVICE
示例
[ceph-admin@admin cephadm-ansible]$ sudo vi restart_services.yml --- - name: start and stop services hosts: host01 become: true gather_facts: false tasks: - name: start osd.0 ceph_orch_daemon: state: started daemon_id: 0 daemon_type: osd - name: stop mon.host02 ceph_orch_daemon: state: stopped daemon_id: host02 daemon_type: mon在本例中，playbook 启动 ID 为
0的 OSD，并停止 Ceph monitor 的 id 为host02。运行 playbook：
语法
ansible-playbook -i INVENTORY_FILE _PLAYBOOK_FILENAME.yml示例
[ceph-admin@admin cephadm-ansible]$ ansible-playbook -i hosts restart_services.yml
验证
- 检查 playbook 任务的输出。
