操作指南
Red Hat Ceph Storage 的操作任务
摘要
第 1 章 管理存储集群大小
作为存储管理员，您可以通过添加或删除 Ceph Monitor 或 OSD 作为存储容量来管理存储集群大小。您可以使用 Ceph Ansible 或使用命令行界面(CLI)来管理存储集群大小。
1.1. 先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 对 Ceph 监视器和 OSD 节点的 root 级别访问权限。
1.2. Ceph Monitor
Ceph Monitor 是轻量型进程，维护存储集群映射的主副本。所有 Ceph 客户端都会联系 Ceph 监控器，并检索存储集群映射的当前副本，使客户端能够绑定到池并读写数据。
Ceph 监控程序使用 Paxos 协议的一种变体来就存储集群之间的映射和其他重要信息建立共识。由于 Paxos 的性质，Ceph 需要大多数 monitor 能够建立仲裁，从而建立共识。
对于生产环境集群，需要在独立的主机上至少有三个监控器才能获得红帽的支持。
红帽建议部署奇数个监控器。Ceph 监控器的数量如果是奇数，则比带有偶数个监控器对故障有更高的抗压性。例如，若要在双监视器部署上维护仲裁，Ceph 无法容忍任何故障；对于四个监视器，可以容忍一个失败，对于五个监视器，可以容忍两个失败。这就是建议为奇数的原因。总结一下，Ceph 需要大多数监控器正在运行，并能够相互通信，另外两个是三个，共三，共 4 个，以此类推。
对于多节点 Ceph 存储集群的初始部署，红帽需要至少三个监视器，当需要多于三个 monitor 的情况，每次需要增加 2 个。
由于 Ceph 监控是轻量级的，因此可以在与 OpenStack 节点相同的主机上运行。但是，红帽建议在独立主机上运行 monitor。
红帽不支持在同一节点上并置 Ceph 监控和 OSD。这样做会对存储集群性能造成负面影响。
红帽仅在容器化环境中支持并置 Ceph 服务。
从存储集群中移除 monitor 时，请考虑 Ceph Monitor 使用 Paxos 协议来建立关于主存储集群映射的共识。您必须有足够的数量的 Ceph 监控器来建立仲裁。
其它资源
- 有关所有支持的 Ceph 配置，请参阅 Red Hat Ceph Storage 支持的配置知识库文章。
1.2.1. 准备新的 Ceph 监控节点
在为部署准备新的 Ceph 监控节点前，请查看 Red Hat Ceph Storage 安装指南中的安装 Red Hat Ceph Storage 的要求。
在单独的节点上部署每个新的 Ceph 监控器，存储集群中的所有 Ceph 监控节点必须在同一硬件上运行。
先决条件
- 网络连接。
- 对新节点的根级访问。
流程
- 将新节点添加到服务器机架。
- 将新节点连接到网络。
安装最新版本的 Red Hat Enterprise Linux 7 或 Red Hat Enterprise Linux 8。
对于 Red Hat Enterprise Linux 7，安装
ntp并配置可靠的时间源：[root@mon ~]# yum install ntp
对于 Red Hat Enterprise Linux 8，安装
chrony并配置可靠的时间源：[root@mon ~]# dnf install chrony
如果使用防火墙，打开 TCP 端口 6789：
[root@mon ~]# firewall-cmd --zone=public --add-port=6789/tcp [root@mon ~]# firewall-cmd --zone=public --add-port=6789/tcp --permanent
其它资源
-
有关
chrony的详情，请参考 Red Hat Enterprise Linux 8 配置基本系统设置。
1.2.2. 使用 Ansible 添加 Ceph Monitor
红帽建议一次添加两个 Ceph monitor，以维护奇数个 monitor。例如，如果您在存储集群中有三个 Ceph monitor，红帽建议您将 monitor 数量扩展到 5。
先决条件
- 对新节点的根级访问。
- Ansible 管理节点.
- 一个由 Ansible 部署的、正在运行的 Red Hat Ceph Storage 集群。
流程
将新的 Ceph Monitor 节点添加到
/etc/ansible/hostsAnsible 清单文件的[mons]部分下：示例
[mons] monitor01 monitor02 monitor03 NEW_MONITOR_NODE_NAME NEW_MONITOR_NODE_NAME
验证 Ansible 是否可以联系 Ceph 节点：
[root@admin ~]# ansible all -m ping
将目录改为 Ansible 配置目录：
[root@admin ~]# cd /usr/share/ceph-ansible
您可以使用以下任一步骤添加 Ceph Monitor：
对于裸机和容器部署 ，请运行
infrastructure-playbook：[root@admin ceph-ansible]# ansible-playbook -vvvv -i hosts infrastructure-playbooks/add-mon.yml
以 ansible 用户身份，运行
siteplaybook 或site-containerplaybook：裸机部署：
示例
[ansible@admin ceph-ansible]$ ansible-playbook -vvvv -i hosts site.yml --limit mons
容器部署：
示例
[ansible@admin ceph-ansible]$ ansible-playbook -vvvv -i hosts site-container.yml --limit mons
在 Ansible playbook 运行后，新的 Ceph Monitor 节点将出现在存储集群中。
更新配置文件：
裸机部署：
示例
[user@admin ceph-ansible]$ ansible-playbook -vvvv -i hosts site.yml --tags ceph_update_config
容器部署：
示例
[user@admin ceph-ansible]$ ansible-playbook -vvvv -i hosts site-container.yml --tags ceph_update_config
其它资源
- 如需了解有关 Ansible 清单配置的更多详细信息，请参阅 {storage_product} 安装指南中的配置 Ansible 清单位置 部分。
1.2.3. 使用命令行界面添加 Ceph monitor
红帽建议一次添加两个 Ceph monitor，以维护奇数个 monitor。例如，如果您在存储集群中有三个 Ceph monitor，红帽建议您将 monitor 数量扩展到 5。
红帽建议每个节点只运行一个 Ceph Monitor 守护进程。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 对正在运行的 Ceph 监控节点以及新的监控节点的 root 级别访问。
流程
添加 Red Hat Ceph Storage 4 监控软件仓库。
Red Hat Enterprise Linux 7
[root@mon ~]# subscription-manager repos --enable=rhel-7-server-rhceph-4-mon-rpms
Red Hat Enterprise Linux 8
[root@mon ~]# subscription-manager repos --enable=rhceph-4-mon-for-rhel-8-x86_64-rpms
在新的 Ceph 监控节点上安装
ceph-mon软件包：Red Hat Enterprise Linux 7
[root@mon ~]# yum install ceph-mon
Red Hat Enterprise Linux 8
[root@mon ~]# dnf install ceph-mon
编辑存储集群中正在运行的节点上 Ceph 配置文件的
[mon]部分中的mon_host设置列表。将新 Ceph Monitor 节点的 IP 地址添加到
mon_host设置列表中：语法
[mon] mon_host = MONITOR_IP : PORT MONITOR_IP : PORT ... NEW_MONITOR_IP : PORT
您可以将新的 Ceph Monitor 的 IP 地址添加到 Ceph 配置文件的 [mon] 部分，而是为新监控器节点创建一个特定部分：
语法
[mon.MONITOR_ID] host = MONITOR_ID mon_addr = MONITOR_IP
注意mon_host设置列表是 DNS 可解析的主机名或 IP 地址的列表，由 "," 或 ";" 分隔。此列表可确保存储集群在启动或停止期间标识新的 monitor 节点。重要mon_initial_members设置列出了 Ceph 监控节点的初始仲裁组。如果该组的成员出现故障，则该组中的另一节点将变成初始监控节点。为确保生产环境存储集群的高可用性，请在 Ceph 配置文件的mon_initial_members和mon_host部分中至少列出三个监控节点。这可防止存储集群在初始监控节点失败时锁定。如果您要添加的 monitor 节点会替换属于mon_initial_members和mon_host的监控器，还要向这两个部分添加新的监控器。
要使 monitor 成为初始仲裁组的成员，请将主机名添加到 Ceph 配置文件的
[global]部分中的mon_initial_members参数。示例
[global] mon_initial_members = node1 node2 node3 node4 node5 ... [mon] mon_host = 192.168.0.1:6789 192.168.0.2:6789 192.168.0.3:6789 192.168.0.4:6789 192.168.0.5:6789 ... [mon.node4] host = node4 mon_addr = 192.168.0.4 [mon.node5] host = node5 mon_addr = 192.168.0.5
将更新的 Ceph 配置文件复制到所有 Ceph 节点和 Ceph 客户端中：
语法
scp /etc/ceph/CLUSTER_NAME.conf TARGET_NODE_NAME:/etc/ceph
示例
[root@mon ~]# scp /etc/ceph/ceph.conf node4:/etc/ceph
在新监控节点上创建 monitor 的数据目录：
语法
mkdir /var/lib/ceph/mon/CLUSTER_NAME - MONITOR_ID
示例
[root@mon ~]# mkdir /var/lib/ceph/mon/ceph-node4
在运行中的 Ceph 监控节点上和新建监控节点上创建临时目录，并将这个过程所需的文件保留在这些目录中。每个节点上的临时目录应该与节点的默认目录不同。可在所有步骤完成后删除：
语法
mkdir TEMP_DIRECTORY_PATH_NAME示例
[root@mon ~]# mkdir /tmp/ceph
将 admin 密钥从正在运行的 Ceph Monitor 节点复制到新的 Ceph 监控节点，以便您可以运行
ceph命令：语法
scp /etc/ceph/CLUSTER_NAME.client.admin.keyring TARGET_NODE_NAME:/etc/ceph
示例
[root@mon ~]# scp /etc/ceph/ceph.client.admin.keyring node4:/etc/ceph
从正在运行的 Ceph 监控节点中，检索 monitor 密钥环：
语法
ceph auth get mon. -o TEMP_DIRECTORY_PATH_NAME/KEY_FILE_NAME
示例
[root@mon ~]# ceph auth get mon. -o /tmp/ceph/ceph_keyring.out
从正在运行的 Ceph 监控节点中，检索 monitor 映射：
语法
ceph mon getmap -o TEMP_DIRECTORY_PATH_NAME/MONITOR_MAP_FILE
示例
[root@mon ~]# ceph mon getmap -o /tmp/ceph/ceph_mon_map.out
将收集的 Ceph Monitor 数据复制到新的 Ceph Monitor 节点：
语法
scp /tmp/ceph TARGET_NODE_NAME:/tmp/ceph示例
[root@mon ~]# scp /tmp/ceph node4:/tmp/ceph
为您之前收集的数据准备数据目录。指定 monitor map 的路径，以便从监控器检索仲裁信息，以及它们的 'fsid'。指定 monitor keyring 的路径：
语法
ceph-mon -i MONITOR_ID --mkfs --monmap TEMP_DIRECTORY_PATH_NAME/MONITOR_MAP_FILE --keyring TEMP_DIRECTORY_PATH_NAME/KEY_FILE_NAME
示例
[root@mon ~]# ceph-mon -i node4 --mkfs --monmap /tmp/ceph/ceph_mon_map.out --keyring /tmp/ceph/ceph_keyring.out
对于具有自定义名称的存储集群，请在
/etc/sysconfig/ceph文件中添加以下行：语法
echo "CLUSTER=CUSTOM_CLUSTER_NAME" >> /etc/sysconfig/ceph示例
[root@mon ~]# echo "CLUSTER=example" >> /etc/sysconfig/ceph
更新新监控节点上的所有者和组权限：
语法
chown -R OWNER : GROUP DIRECTORY_PATH
示例
[root@mon ~]# chown -R ceph:ceph /var/lib/ceph/mon [root@mon ~]# chown -R ceph:ceph /var/log/ceph [root@mon ~]# chown -R ceph:ceph /var/run/ceph [root@mon ~]# chown -R ceph:ceph /etc/ceph
在新监控节点上启用并启动
ceph-mon进程：语法
systemctl enable ceph-mon.target systemctl enable ceph-mon@MONITOR_ID systemctl start ceph-mon@MONITOR_ID
示例
[root@mon ~]# systemctl enable ceph-mon.target [root@mon ~]# systemctl enable ceph-mon@node4 [root@mon ~]# systemctl start ceph-mon@node4
其它资源
- 请参阅 Red Hat Ceph Storage 安装指南中的启用 Red Hat Ceph Storage 仓库 部分。
1.2.4. 配置 monitor 选择策略
monitor 选择策略标识了网络分割并处理失败。您可以使用三种不同模式配置选择监控策略：
-
classic- 默认默认，它是最低等级的监控，根据两个站点之间的选举模块进行投票。 -
disallow- 此模式可让您将 monitor 标记为禁止，在这种情况下，他们会参与仲裁并服务客户端，但不能是选择的领导者。这样，您可以将 monitor 添加到禁止的领导列表中。如果 monitor 在 disallowed 列表中，它将始终被推迟到另一个 monitor。 -
connectivity- 这个模式主要用于解决网络差异。它会为对等点评估由每个监控器提供的连接分数，并选出最佳连接的可靠的监控器作为领导。这个模式旨在处理网络分割，如果您的集群在多个数据中心间扩展或存在影响，则可能会出现这种情况。这个模式包含连接分数评级，并以最佳分数选择监控器。
红帽建议保持在 经典（classic） 模式，除非您需要其他模式的功能。
在构造集群前，将以下命令的 election_strategy 更改为 classic, disallow, 或 connectivity：
语法
ceph mon set election_strategy {classic|disallow|connectivity}
1.2.5. 使用 Ansible 删除 Ceph Monitor
要使用 Ansible 删除 Ceph Monitor，请使用 shrink-mon.yml playbook。
先决条件
- Ansible 管理节点.
- 一个由 Ansible 部署的、正在运行的 Red Hat Ceph Storage 集群。
流程
检查 monitor 是否为
ok-to-stop：语法
ceph mon ok-to-stop MONITOR_ID示例
[root@mon ~]# ceph mon ok-to-stop node03
进入到
/usr/share/ceph-ansible/目录。[user@admin ~]$ cd /usr/share/ceph-ansible
对于裸机和容器部署，请运行
shrink-mon.ymlAnsible playbook：语法
ansible-playbook infrastructure-playbooks/shrink-mon.yml -e mon_to_kill=NODE_NAME -u ANSIBLE_USER_NAME -i hosts
替换：
-
NODE_NAME，其 Ceph 监控节点的短主机名。每次 playbook 运行时只能删除一个 Ceph Monitor。 -
ANSIBLE_USER_NAME，Ansible 用户的名称
示例
[user@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/shrink-mon.yml -e mon_to_kill=node03 -u user -i hosts
-
-
从 ansible 清单主机
/etc/ansible/hosts中手动删除对应的条目。 运行
ceph-ansibleplaybook。裸机部署 ：
示例
[user@admin ceph-ansible]$ ansible-playbook site.yml --tags ceph_update_config -i hosts
容器部署 ：
示例
[user@admin ceph-ansible]$ ansible-playbook site-container.yml --tags ceph_update_config -i hosts
确保 Ceph Monitor 已被成功移除：
[root@mon ~]# ceph -s
其它资源
- 有关安装 Red Hat Ceph Storage 的更多信息，请参阅 Red Hat Ceph Storage 安装指南。
- 如需了解有关 Ansible 清单配置的更多详细信息，请参阅 {storage_product} 安装指南中的配置 Ansible 清单位置 部分。
1.2.6. 使用命令行界面删除 Ceph Monitor
删除 Ceph Monitor 涉及从存储集群中移除 ceph-mon 守护进程并更新存储集群映射。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 监控节点的 root 级别访问权限。
流程
检查 monitor 是否为
ok-to-stop：语法
ceph mon ok-to-stop HOSTNAME示例
[root@mon ~]# ceph mon ok-to-stop node03
停止 Ceph Monitor 服务：
语法
systemctl stop ceph-mon@MONITOR_ID示例
[root@mon ~]# systemctl stop ceph-mon@node3
从存储集群中移除 Ceph Monitor：
语法
ceph mon remove MONITOR_ID示例
[root@mon ~]# ceph mon remove node3
-
从 Ceph 配置文件移除 Ceph Monitor 条目。配置文件的默认位置为
/etc/ceph/ceph.conf。 将 Ceph 配置文件重新分发到存储集群中的所有剩余的 Ceph 节点：
语法
scp /etc/ceph/CLUSTER_NAME.conf USER_NAME @ TARGET_NODE_NAME :/etc/ceph/
示例
[root@mon ~]# scp /etc/ceph/ceph.conf root@node3:/etc/ceph/
对于容器部署，禁用并删除 Ceph 监控服务：
禁用 Ceph Monitor 服务：
语法
systemctl disable ceph-mon@MONITOR_ID示例
[root@mon ~]# systemctl disable ceph-mon@node3
从
systemd中删除服务：[root@mon ~]# rm /etc/systemd/system/ceph-mon@.service
重新加载
systemd管理器配置：[root@mon ~]# systemctl daemon-reload
重置故障 Ceph Monitor 节点的状态：
[root@mon ~]# systemctl reset-failed
可选：归档 Ceph 监控数据：
语法
mv /var/lib/ceph/mon/CLUSTER_NAME - MONITOR_ID /var/lib/ceph/mon/removed- CLUSTER_NAME - MONITOR_ID
示例
[root@mon ~]# mv /var/lib/ceph/mon/ceph-node3 /var/lib/ceph/mon/removed-ceph-node3
可选：删除 Ceph Monitor 数据：
语法
rm -r /var/lib/ceph/mon/CLUSTER_NAME - MONITOR_ID
示例
[root@mon ~]# rm -r /var/lib/ceph/mon/ceph-node3
1.2.7. 从不健康的存储集群中移除 Ceph Monitor
您可以从不健康存储集群中删除 ceph-mon 守护进程，该集群的放置组一直处于不是 active + clean 的状态。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- Ceph 监控节点的根级别访问权限.
- 至少一个运行 Ceph Monitor 节点。
流程
登录到一个 surviving Ceph Monitor 节点：
语法
ssh root@MONITOR_NODE_NAME示例
[root@admin ~]# ssh root@mon2
停止
ceph-mon守护进程并提取monmap文件的副本。语法
systemctl stop ceph-mon@MONITOR_ID ceph-mon -i SHORT_HOSTNAME --extract-monmap TEMP_PATH
示例
[root@mon2 ~]# systemctl stop ceph-mon@mon1 [root@mon2 ~]# ceph-mon -i mon1 --extract-monmap /tmp/monmap
删除非可见的 Ceph 监控器：
语法
monmaptool TEMPORARY_PATH --rm _MONITOR_ID示例
[root@mon2 ~]# monmaptool /tmp/monmap --rm mon1
将 surviving monitor map 与已删除 monitor 注入 surviving Ceph Monitor:
语法
ceph-mon -i SHORT_HOSTNAME --inject-monmap TEMP_PATH
示例
[root@mon2 ~]# ceph-mon -i mon2 --inject-monmap /tmp/monmap
仅启动 Surviving monitor，并验证 monitor 是否形成仲裁：
示例
[root@mon2 ~]# ceph -s
-
可选：归档在
/var/lib/ceph/mon目录中删除的 Ceph Monitor 的数据目录。
1.3. Ceph 管理器
Ceph Manager 守护进程(ceph-mgr)与监控守护进程一起运行，以便为外部监控和管理系统提供额外的监控和接口。正常操作需要 ceph-mgr 守护进程。默认情况下，Ceph Manager 守护进程不需要除了确保它正常运行外的其他配置。如果没有运行 mgr 守护进程，您可以看到对该效果的运行状况警告，并且 ceph status 输出中的一些其他信息将缺失或过时的，直到 Ceph 管理器启动为止。
1.3.1. 使用 Ansible 添加 Ceph Manager
通常，在部署 Red Hat Ceph Storage 集群时，Ansible 自动化实用程序会安装 Ceph Manager 守护进程 (ceph-mgr)。如果 Ceph Manager 服务或守护进程停机，您可以使用 Ansible 重新部署 ceph-mgr 守护进程。您可以移除 manager 守护进程，并添加一个新的或现有节点来部署 Ceph Manager 守护进程。红帽建议在同一节点上定位 Ceph 管理器和 Ceph Monitor 守护进程。
先决条件
- 一个由 Ansible 部署的、正在运行的 Red Hat Ceph Storage 集群。
-
对 Ansible 管理节点的
root或sudo访问权限。 - 部署 Ceph 管理器守护进程的新或现有节点。
流程
- 登录 Ansible 管理节点。
进入
/usr/share/ceph-ansible/目录：示例
[ansible@admin ~]$ cd /usr/share/ceph-ansible/
以
root身份或sudo访问权限，打开并编辑/usr/share/ceph-ansible/hosts清单文件，并将 Ceph Manager 节点添加到[mgrs]部分下：语法
[mgrs] CEPH_MANAGER_NODE_NAME CEPH_MANAGER_NODE_NAME
将 CEPH_MANAGER_NODE_NAME 替换为您要安装 Ceph Manager 守护进程的节点的主机名。
以
ansible用户身份，运行 Ansible playbook:裸机部署：
[ansible@admin ceph-ansible]$ ansible-playbook site.yml --limit mgrs -i hosts
容器部署：
[ansible@admin ceph-ansible]$ ansible-playbook site-container.yml --limit mgrs -i hosts
在 Ansible playbook 运行完成后，新的 Ceph Manager 守护进程节点会出现在存储集群中。
验证
在监控器节点上，检查存储集群的状态：
语法
ceph -s
示例
[root@ceph-2 ~]# ceph -s mgr: ceph-3(active, since 2h), standbys: ceph-1, ceph-2
其它资源
- 有关在裸机存储集群中添加 Ceph Manager 守护进程的详情，请参阅 Red Hat Ceph Storage 安装指南中的 手动安装 Ceph Manager 部分。
- 如需了解更多详细信息，请参阅 Red Hat Ceph Storage Operations 指南中的使用 Ansible 删除 Ceph Manager 部分。
1.3.2. 使用 Ansible 删除 Ceph Manager
您可以使用 shrink-mgr playbook 删除 Ceph Manager 守护进程。此 playbook 从集群中移除 Ceph 管理器。
先决条件
- 一个由 Ansible 部署的、正在运行的 Red Hat Ceph Storage 集群。
-
对 Ansible 管理节点的
root或sudo访问权限。 - 对 Ansible 管理节点的管理员访问权限。
流程
- 以 admin 用户身份登录 Ansible 管理节点。
进入
/usr/share/ceph-ansible/目录。[admin@admin ~]$ cd /usr/share/ceph-ansible/
对于裸机和容器部署，请运行
shrink-mgr.ymlAnsible playbook：语法
ansible-playbook infrastructure-playbooks/shrink-mgr.yml -e mgr_to_kill=NODE_NAME -u ANSIBLE_USER_NAME -i hosts
替换：
-
NODE_NAME，带有 Ceph 管理器节点的短主机名。每次 playbook 运行时，您只能移除一个 Ceph Manager。 -
ANSIBLE_USER_NAME，Ansible 用户的名称
示例
[admin@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/shrink-mgr.yml -e mgr_to_kill=ceph-2 -u admin -i hosts
-
作为
root用户，编辑/usr/share/ceph-ansible/hosts清单文件，并删除[mgrs]部分下的 Ceph Manager 节点：语法
[mgrs] CEPH_MANAGER_NODE_NAME CEPH_MANAGER_NODE_NAME
示例
[mgrs] ceph-1 ceph-3
在本例中，
ceph-2已从[mgrs]列表中删除。
验证
在监控器节点上，检查存储集群的状态：
语法
ceph -s
示例
[root@ceph-2 ~]# ceph -s mgr: ceph-3(active, since 112s), standbys: ceph-1
其它资源
- 有关安装 Red Hat Ceph Storage 的更多信息，请参阅 Red Hat Ceph Storage 安装指南。
- 如需了解有关 Ansible 清单配置的更多详细信息，请参阅 Red Hat Ceph Storage 安装指南中的配置 Ansible 清单位置 部分。
1.4. Ceph MDS
每个元数据服务器 (MDS) 节点运行 MDS 守护进程 (ceph-mds)，后者管理与 Ceph 文件系统 (CephFS) 中存储的文件相关的元数据。MDS 提供兼容 POSIX 的共享文件系统元数据管理，包括所有权、时间戳和模式。MDS 使用 RADOS（可靠的自主分布式对象存储）来存储元数据。
MDS 允许 CephFS 与 Ceph 对象存储交互，将索引节点映射到对象，以及 Ceph 在树中存储数据的位置。访问 CephFS 文件系统的客户端首先向 MDS 发出请求，它提供了从正确 OSD 获取文件内容所需的信息。
1.4.1. 使用 Ansible 添加 Ceph MDS
使用 Ansible playbook 添加 Ceph 元数据服务器(MDS)。
先决条件
- 一个由 Ansible 部署的、正在运行的 Red Hat Ceph Storage 集群。
-
对 Ansible 管理节点的
root或sudo访问权限。 - 可以作为 MDS 节点置备的新的或现有服务器。
流程
- 登录 Ansible 管理节点
进入
/usr/share/ceph-ansible目录：示例
[ansible@admin ~]$ cd /usr/share/ceph-ansible
作为
root用户或具有sudo访问权限，打开并编辑/usr/share/ceph-ansible/hosts清单文件，并在[mdss]部分下添加 MDS 节点：语法
[mdss] MDS_NODE_NAME NEW_MDS_NODE_NAME
将 NEW_MDS_NODE_NAME 替换为您要安装 MDS 服务器的节点的主机名。
或者，您可以通过在
[osds]和[mdss]部分下添加同一节点，将元数据服务器与 OSD 守护进程并置。示例
[mdss] node01 node03
以
ansible用户身份，运行 Ansible playbook 来调配 MDS 节点：裸机部署：
[ansible@admin ceph-ansible]$ ansible-playbook site.yml --limit mdss -i hosts
容器部署：
[ansible@admin ceph-ansible]$ ansible-playbook site-container.yml --limit mdss -i hosts
在 Ansible playbook 运行后，新的 Ceph MDS 节点将出现在存储集群中。
验证
检查 MDS 守护进程的状态：
语法
ceph fs dump
示例
[ansible@admin ceph-ansible]$ ceph fs dump [mds.node01 {0:115304} state up:active seq 5 addr [v2:172.25.250.10:6800/695510951,v1:172.25.250.10:6801/695510951]] Standby daemons: [mds.node03 {-1:144437} state up:standby seq 2 addr [v2:172.25.250.11:6800/172950087,v1:172.25.250.11:6801/172950087]]另外，您可以使用
ceph mds stat命令检查 MDS 是否处于 active 状态：语法
ceph mds stat
示例
[ansible@admin ceph-ansible]$ ceph mds stat cephfs:1 {0=node01=up:active} 1 up:standby
其它资源
- 有关安装 Red Hat Ceph Storage 的更多信息，请参阅 Red Hat Ceph Storage 安装指南。
- 有关使用 Ansible 删除 MDS 的详情，请参阅 Red Hat Ceph Storage 故障排除 指南中的使用 Ansible 删除 Ceph MDS 部分。
1.4.2. 使用命令行界面添加 Ceph MDS
您可以使用命令行界面手动添加 Ceph 元数据服务器(MDS)。
先决条件
-
已安装
ceph-common软件包。 - 一个正在运行的 Red Hat Ceph Storage 集群。
-
对 MDS 节点的
root或sudo访问权限。 - 可以作为 MDS 节点置备的新的或现有服务器。
流程
通过登录到节点并创建 MDS 挂载点来添加新的 MDS 节点：
语法
sudo mkdir /var/lib/ceph/mds/ceph-MDS_ID将 MDS_ID 替换为您要向其添加 MDS 守护进程的 MDS 节点 ID。
示例
[admin@node03 ~]$ sudo mkdir /var/lib/ceph/mds/ceph-node03
如果这是新的 MDS 节点，如果您使用 Cephx 身份验证，请创建身份验证密钥：
语法
sudo ceph auth get-or-create mds.MDS_ID mon 'profile mds' mgr 'profile mds' mds 'allow *' osd 'allow *' > /var/lib/ceph/mds/ceph-MDS_ID/keyring
将 MDS_ID 替换为 MDS 节点 ID，以在其上部署 MDS 守护进程。
示例
[admin@node03 ~]$ sudo ceph auth get-or-create mds.node03 mon 'profile mds' mgr 'profile mds' mds 'allow *' osd 'allow *' > /var/lib/ceph/mds/ceph-node03/keyring
注意Cephx 身份验证被默认启用。有关 Cephx 身份验证的更多信息，请参阅 Additional Resources 部分中的 Cephx 身份验证链接。
启动 MDS 守护进程：
语法
sudo systemctl start ceph-mds@HOST_NAME将 HOST_NAME 替换为要启动守护进程的主机的短名称。
示例
[admin@node03 ~]$ sudo systemctl start ceph-mds@node03
启用 MDS 服务：
语法
systemctl enable ceph-mds@HOST_NAME将 HOST_NAME 替换为要启用该服务的主机的短名称。
示例
[admin@node03 ~]$ sudo systemctl enable ceph-mds@node03
验证
检查 MDS 守护进程的状态：
语法
ceph fs dump
示例
[admin@mon]$ ceph fs dump [mds.node01 {0:115304} state up:active seq 5 addr [v2:172.25.250.10:6800/695510951,v1:172.25.250.10:6801/695510951]] Standby daemons: [mds.node03 {-1:144437} state up:standby seq 2 addr [v2:172.25.250.11:6800/172950087,v1:172.25.250.11:6801/172950087]]另外，您可以使用
ceph mds stat命令检查 MDS 是否处于 active 状态：语法
ceph mds stat
示例
[ansible@admin ceph-ansible]$ ceph mds stat cephfs:1 {0=node01=up:active} 1 up:standby
其它资源
- 有关安装 Red Hat Ceph Storage 的更多信息，请参阅 Red Hat Ceph Storage 安装指南。
- 有关 Cephx 身份验证的更多信息，请参阅 Red Hat Ceph Storage 配置指南。
- 如需有关使用命令行界面删除 MDS 的详情，请参阅 Red Hat Ceph Storage 故障排除指南中的使用命令行界面删除 Ceph MDS。
1.4.3. 使用 Ansible 删除 Ceph MDS
要使用 Ansible 删除 Ceph 元数据服务器(MDS)，请使用 shrink-mds playbook。
如果在 MDS 被删除后没有替换的 MDS 进行接管，对于客户端文件系统会不可用。如果这不必要，请考虑在删除 MDS 之前添加额外的 MDS，以便离线。
先决条件
- 至少一个 MDS 节点。
- 一个由 Ansible 部署的、正在运行的 Red Hat Ceph Storage 集群。
-
对 Ansible 管理节点的
root或sudo访问权限。
流程
- 登录 Ansible 管理节点。
进入
/usr/share/ceph-ansible目录：示例
[ansible@admin ~]$ cd /usr/share/ceph-ansible
运行 Ansible
shrink-mds.ymlplaybook，在提示时输入yes以确认缩减集群：语法
ansible-playbook infrastructure-playbooks/shrink-mds.yml -e mds_to_kill=ID -i hosts使用您要删除的 MDS 节点 ID 替换 ID。每次 playbook 运行时只能删除一个 Ceph MDS。
示例
[ansible @admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/shrink-mds.yml -e mds_to_kill=node02 -i hosts
作为
root用户或具有sudo访问权限，打开并编辑/usr/share/ceph-ansible/hosts清单文件，并在[mdss]部分下删除 MDS 节点：语法
[mdss] MDS_NODE_NAME MDS_NODE_NAME
示例
[mdss] node01 node03
在本例中，
node02已从[mdss]列表中删除。
验证
检查 MDS 守护进程的状态：
语法
ceph fs dump
示例
[ansible@admin ceph-ansible]$ ceph fs dump [mds.node01 {0:115304} state up:active seq 5 addr [v2:172.25.250.10:6800/695510951,v1:172.25.250.10:6801/695510951]] Standby daemons: [mds.node03 {-1:144437} state up:standby seq 2 addr [v2:172.25.250.11:6800/172950087,v1:172.25.250.11:6801/172950087]]
其它资源
- 有关安装 Red Hat Ceph Storage 的更多信息，请参阅 Red Hat Ceph Storage 安装指南。
- 有关使用 Ansible 添加 MDS 的详情，请参阅 Red Hat Ceph Storage 故障排除 指南中的使用 Ansible 添加 Ceph MDS 部分。
1.4.4. 使用命令行界面删除 Ceph MDS
您可以使用命令行界面手动删除 Ceph 元数据服务器(MDS)。
如果在当前 MDS 被删除后没有替代的 MDS 进行接管，客户端无法使用文件系统。如果这不必要，请考虑在删除现有 MDS 前添加 MDS。
先决条件
-
已安装
ceph-common软件包。 - 一个正在运行的 Red Hat Ceph Storage 集群。
-
对 MDS 节点的
root或sudo访问权限。
流程
- 登录到您要从中删除 MDS 守护进程的 Ceph MDS 节点。
停止 Ceph MDS 服务：
语法
sudo systemctl stop ceph-mds@HOST_NAME将 HOST_NAME 替换为守护进程运行的主机的短名称。
示例
[admin@node02 ~]$ sudo systemctl stop ceph-mds@node02
如果没有将 MDS 重新部署到这个节点，则禁用 MDS 服务：
语法
sudo systemctl disable ceph-mds@HOST_NAME将 HOST_NAME 替换为要禁用该守护进程的主机的短名称。
示例
[admin@node02 ~]$ sudo systemctl disable ceph-mds@node02
删除 MDS 节点上的
/var/lib/ceph/mds/ceph-MDS_ID目录：语法
sudo rm -fr /var/lib/ceph/mds/ceph-MDS_ID使用您要从中删除 MDS 守护进程的 MDS 节点 ID 替换 MDS_ID。
示例
[admin@node02 ~]$ sudo rm -fr /var/lib/ceph/mds/ceph-node02
验证
检查 MDS 守护进程的状态：
语法
ceph fs dump
示例
[ansible@admin ceph-ansible]$ ceph fs dump [mds.node01 {0:115304} state up:active seq 5 addr [v2:172.25.250.10:6800/695510951,v1:172.25.250.10:6801/695510951]] Standby daemons: [mds.node03 {-1:144437} state up:standby seq 2 addr [v2:172.25.250.11:6800/172950087,v1:172.25.250.11:6801/172950087]]
其它资源
- 有关安装 Red Hat Ceph Storage 的更多信息，请参阅 Red Hat Ceph Storage 安装指南。
- 如需有关使用命令行界面添加 MDS 的详情，请参阅 Red Hat Ceph Storage 故障排除指南中的使用命令行界面添加 Ceph MDS。
1.5. Ceph OSD
当 Red Hat Ceph Storage 集群启动并运行时，您可以在运行时将 OSD 添加到存储集群中。
Ceph OSD 通常由一个存储驱动器和一个 ceph-osd 守护进程和一个节点中的相关日志组成。如果节点有多个存储驱动器，则为每个驱动器映射一个 ceph-osd 守护进程。
红帽建议定期检查集群的容量，以查看它是否达到其存储容量的上限。当存储集群达到其 近满（near full）比率时，添加一个或多个 OSD 来扩展存储集群的容量。
当您要缩小 Red Hat Ceph Storage 集群大小或替换硬件时，您还可以在运行时移除 OSD。如果节点有多个存储驱动器，您可能还需要为该驱动器删除其中一个 ceph-osd 守护进程。通常，最好检查存储集群的容量，以查看您是否达到其容量的上限。在删除 OSD 后，确保存储集群没有达到接近全满比率。
在添加 OSD 前，不要让存储集群达到全满比率。在存储集群达到接近满比率后发生 OSD 故障可能会导致存储集群超过全满比率。Ceph 会阻止写入访问来保护数据，直到您解决存储容量问题。在删除 OSD 前，需要仔细考虑它对 full 比率的影响。
1.5.1. Ceph OSD 节点配置
配置 Ceph OSD 及其支持的硬件与使用 OSD 的池存储策略类似。Ceph 倾向于在池之间实现一致的性能配置集统一硬件。为了获得最佳性能，请考虑使用相同类型或大小的驱动器的 CRUSH 层次结构。
如果您添加不同大小的驱动器，请相应地调整其权重。将 OSD 添加到 CRUSH map 时，请考虑新 OSD 的权重。硬盘容量每年增长约 40%，因此较新的 OSD 节点可能比存储集群中的旧节点有更大的硬盘驱动器，即它们可能具有更大的权重。
在进行新安装前，请参阅安装指南中的安装 Red Hat Ceph Storage 的要求章节。
其它资源
- 如需了解更多详细信息，请参阅 Red Hat Ceph Storage 策略指南。*
1.5.2. 将容器 OSD ID 映射到驱动器
有时，需要确定容器化 OSD 正在使用哪个驱动器。例如，如果 OSD 有问题，您可能需要知道它用来验证驱动器状态的驱动器。另外，对于非容器化 OSD，您可以引用 OSD ID 来启动和停止它，但要启动和停止容器化 OSD，您要引用它所使用的驱动器。
以下示例在 Red Hat Enterprise Linux 8 上运行。在 Red Hat Enterprise Linux 8 中，podman 是默认服务，并替换了旧的 docker 服务。如果您在 Red Hat Enterprise Linux 7 上运行，则使用 docker 替换 podman 以执行给定的命令。
先决条件
- 在容器化环境中运行的 Red Hat Ceph Storage 集群。
-
具有容器节点的
root访问权限。
流程
查找容器名称。例如，要识别与
osd.5关联的驱动器，请在osd.5正在运行的容器节点上打开终端，然后运行podman ps来列出所有容器：示例
[root@ceph3 ~]# podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 3a866f927b74 registry.redhat.io/rhceph/rhceph-4-rhel8:latest "/entrypoint.sh" About an hour ago Up About an hour ceph-osd-ceph3-sdd 4e242d932c32 registry.redhat.io/rhceph/rhceph-4-rhel8:latest "/entrypoint.sh" About an hour ago Up About an hour ceph-osd-ceph3-sdc 91f3d4829079 registry.redhat.io/rhceph/rhceph-4-rhel8:latest "/entrypoint.sh" 22 hours ago Up 22 hours ceph-osd-ceph3-sdb 73dfe4021a49 registry.redhat.io/rhceph/rhceph-4-rhel8:latest "/entrypoint.sh" 7 days ago Up 7 days ceph-osd-ceph3-sdf 90f6d756af39 registry.redhat.io/rhceph/rhceph-4-rhel8:latest "/entrypoint.sh" 7 days ago Up 7 days ceph-osd-ceph3-sde e66d6e33b306 registry.redhat.io/rhceph/rhceph-4-rhel8:latest "/entrypoint.sh" 7 days ago Up 7 days ceph-mgr-ceph3 733f37aafd23 registry.redhat.io/rhceph/rhceph-4-rhel8:latest "/entrypoint.sh" 7 days ago Up 7 days ceph-mon-ceph3
使用
podman exec在前面输出中任何 OSD 容器名称上运行ceph-volume lvm 列表：示例
[root@ceph3 ~]# podman exec ceph-osd-ceph3-sdb ceph-volume lvm list ====== osd.5 ======= [journal] /dev/journals/journal1 journal uuid C65n7d-B1gy-cqX3-vZKY-ZoE0-IEYM-HnIJzs osd id 1 cluster fsid ce454d91-d748-4751-a318-ff7f7aa18ffd type journal osd fsid 661b24f8-e062-482b-8110-826ffe7f13fa data uuid SlEgHe-jX1H-QBQk-Sce0-RUls-8KlY-g8HgcZ journal device /dev/journals/journal1 data device /dev/test_group/data-lv2 devices /dev/sda [data] /dev/test_group/data-lv2 journal uuid C65n7d-B1gy-cqX3-vZKY-ZoE0-IEYM-HnIJzs osd id 1 cluster fsid ce454d91-d748-4751-a318-ff7f7aa18ffd type data osd fsid 661b24f8-e062-482b-8110-826ffe7f13fa data uuid SlEgHe-jX1H-QBQk-Sce0-RUls-8KlY-g8HgcZ journal device /dev/journals/journal1 data device /dev/test_group/data-lv2 devices /dev/sdb在这个输出中，您可以看到
osd.5与/dev/sdb关联。
其它资源
- 如需更多信息，请参阅重新放置失败的 OSD 磁盘。
1.5.3. 使用 Ansible 添加具有相同磁盘拓扑的 Ceph OSD
对于具有相同磁盘拓扑的 Ceph OSD，Ansible 使用 /usr/share/ceph-ansible/group_vars/osds.yml 文件的 devices: 部分中指定的同一设备路径添加与其他 OSD 节点相同的 OSD 数量。
新的 Ceph OSD 节点具有与 OSD 的其余部分相同的配置。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 请参阅 Red Hat Ceph Storage 安装指南中的安装 Red Hat Ceph Storage 的要求。
-
具有对新节点的
root访问权限。 - 与存储集群中的其他 OSD 节点相同的 OSD 数据驱动器数量。
流程
将 Ceph OSD 节点添加到
/etc/ansible/hosts文件的[osds]部分下：语法
[osds] ... osd06 NEW_OSD_NODE_NAME验证 Ansible 能否访问 Ceph 节点：
[user@admin ~]$ ansible all -m ping
进入 Ansible 配置目录：
[user@admin ~]$ cd /usr/share/ceph-ansible
对于裸机和容器部署，请运行
add-osd.ymlAnsible playbook：注意对于新的 OSD 主机，您需要使用
--limit选项运行site.yml或site-container.ymlplaybook，并且ceph-crash服务没有部署到使用osds.ymlplaybook 的节点上。示例
[user@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/add-osd.yml -i hosts
对于新的 OSD 主机，请运行
site.yml或site-container.ymlAnsible playbook：裸机部署：
语法
ansible-playbook site.yml -i hosts --limit NEW_OSD_NODE_NAME示例
[user@admin ceph-ansible]$ ansible-playbook site.yml -i hosts --limit node03
容器部署：
语法
ansible-playbook site-container.yml -i hosts --limit NEW_OSD_NODE_NAME示例
[user@admin ceph-ansible]$ ansible-playbook site-container.yml -i hosts --limit node03
在添加 OSD 时，如果 playbook 失败（PGs were not reported as active+clean），在 all.yml 文件中配置以下变量来调整重试和延迟：
# OSD handler checks handler_health_osd_check_retries: 50 handler_health_osd_check_delay: 30
其它资源
- 如需了解有关 Ansible 清单配置的更多详细信息，请参阅 {storage_product} 安装指南中的配置 Ansible 清单位置部分。
1.5.4. 使用具有不同磁盘拓扑的 Ansible 添加 Ceph OSD
对于具有不同磁盘拓扑的 Ceph OSD，可通过两种方法将新 OSD 节点添加到现有存储集群中。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 请参阅 Red Hat Ceph Storage 安装指南中的安装 Red Hat Ceph Storage 的要求。
-
具有对新节点的
root访问权限。
流程
第一种方法
在
[osds]部分下，添加新的 Ceph OSD 节点到/etc/ansible/hosts文件：示例
[osds] ... osd06 NEW_OSD_NODE_NAME在
/etc/ansible/host_vars/目录下，为每个添加到存储集群的每个新 Ceph OSD 节点创建一个新文件：语法
touch /etc/ansible/host_vars/NEW_OSD_NODE_NAME示例
[root@admin ~]# touch /etc/ansible/host_vars/osd07
编辑新文件，并将
devices:和dedicated_devices:部分添加到该文件中。在每个部分下，添加一个-、空格，然后添加到这个 OSD 节点的块设备名称的完整路径：示例
devices: - /dev/sdc - /dev/sdd - /dev/sde - /dev/sdf dedicated_devices: - /dev/sda - /dev/sda - /dev/sdb - /dev/sdb
验证 Ansible 是否可以访问所有 Ceph 节点：
[user@admin ~]$ ansible all -m ping
将目录改为 Ansible 配置目录：
[user@admin ~]$ cd /usr/share/ceph-ansible
对于裸机和容器部署，请运行
add-osd.ymlAnsible playbook：注意对于新的 OSD 主机，您需要使用
--limit选项运行site.yml或site-container.ymlplaybook，并且ceph-crash服务没有部署到使用osds.ymlplaybook 的节点上。示例
[user@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/add-osd.yml -i hosts
对于新的 OSD 主机，请运行
site.yml或site-container.ymlAnsible playbook：裸机部署：
语法
ansible-playbook site.yml -i hosts --limit NEW_OSD_NODE_NAME示例
[user@admin ceph-ansible]$ ansible-playbook site.yml -i hosts --limit node03
容器部署：
语法
ansible-playbook site-container.yml -i hosts --limit NEW_OSD_NODE_NAME示例
[user@admin ceph-ansible]$ ansible-playbook site-container.yml -i hosts --limit node03
第二种方法
将新 OSD 节点名称添加到
/etc/ansible/hosts文件，并使用devices和dedicated_devices选项指定不同的磁盘拓扑：示例
[osds] ... osd07 devices="['/dev/sdc', '/dev/sdd', '/dev/sde', '/dev/sdf']" dedicated_devices="['/dev/sda', '/dev/sda', '/dev/sdb', '/dev/sdb']"
验证 Ansible 能否访问所有 Ceph 节点：
[user@admin ~]$ ansible all -m ping
将目录改为 Ansible 配置目录：
[user@admin ~]$ cd /usr/share/ceph-ansible
对于裸机和容器部署，请运行
add-osd.ymlAnsible playbook：注意对于新的 OSD 主机，您需要使用
--limit选项运行site.yml或site-container.ymlplaybook，并且ceph-crash服务没有部署到使用osds.ymlplaybook 的节点上。示例
[user@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/add-osd.yml -i hosts
对于新的 OSD 主机，请运行
site.yml或site-container.ymlAnsible playbook：裸机部署：
语法
ansible-playbook site.yml -i hosts --limit NEW_OSD_NODE_NAME示例
[user@admin ceph-ansible]$ ansible-playbook site.yml -i hosts --limit node03
容器部署：
语法
ansible-playbook site-container.yml -i hosts --limit NEW_OSD_NODE_NAME示例
[user@admin ceph-ansible]$ ansible-playbook site-container.yml -i hosts --limit node03
其它资源
- 如需了解有关 Ansible 清单配置的更多详细信息，请参阅 {storage_product} 安装指南中的配置 Ansible 清单位置部分。
1.5.5. 使用 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。
1.5.6. 将批处理模式与 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]
示例
[root@osd ~]# ceph-volume lvm batch --bluestore /dev/sda /dev/sdb /dev/nvme0n1
其它资源
- 如需更多详细信息，请参阅 Red Hat Ceph Storage 管理指南中的使用 'ceph-volume' 创建 Ceph OSD。
1.5.7. 使用命令行界面添加 Ceph OSD
以下是手动将 OSD 添加到 Red Hat Ceph Storage 的高级别工作流：
-
安装
ceph-osd软件包并创建新的 OSD 实例。 - 准备并挂载 OSD 数据和日志驱动器。
- 创建卷组和逻辑卷。
- 添加新 OSD 节点到 CRUSH map。
- 更新所有者和组权限。
-
启用并启动
ceph-osd守护进程。
ceph-disk 命令已弃用。ceph-volume 命令现在是从命令行界面部署 OSD 的首选方法。目前，ceph-volume 命令只支持 lvm 插件。红帽在整个指南中提供了使用两个命令作为参考的示例，允许存储管理员将依赖 ceph-disk 的任何自定义脚本转换为 ceph-volume。
对于自定义存储集群名称，请将 --cluster CLUSTER_NAME 选项与 ceph 和 ceph-osd 命令搭配使用。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 请参阅 Red Hat Ceph Storage 安装指南中的安装 Red Hat Ceph Storage 的要求。
-
新节点的
root访问权限。 -
可选。如果您不希望
ceph-volume实用程序自动创建卷组和逻辑卷，请手动创建它们。请参阅 Red Hat Enterprise Linux 8 配置和管理逻辑卷指南。
流程
启用 Red Hat Ceph Storage 4 OSD 软件存储库。
Red Hat Enterprise Linux 7
[root@osd ~]# subscription-manager repos --enable=rhel-7-server-rhceph-4-osd-rpms
Red Hat Enterprise Linux 8
[root@osd ~]# subscription-manager repos --enable=rhceph-4-osd-for-rhel-8-x86_64-rpms
创建
/etc/ceph/目录：[root@osd ~]# mkdir /etc/ceph
在新 OSD 节点上，从其中一个 Ceph 监控节点复制 Ceph 管理密钥环和配置文件：
语法
scp USER_NAME @ MONITOR_HOST_NAME :/etc/ceph/CLUSTER_NAME.client.admin.keyring /etc/ceph scp USER_NAME @ MONITOR_HOST_NAME :/etc/ceph/CLUSTER_NAME.conf /etc/ceph
示例
[root@osd ~]# scp root@node1:/etc/ceph/ceph.client.admin.keyring /etc/ceph/ [root@osd ~]# scp root@node1:/etc/ceph/ceph.conf /etc/ceph/
在新的 Ceph OSD 节点上安装
ceph-osd软件包：Red Hat Enterprise Linux 7
[root@osd ~]# yum install ceph-osd
Red Hat Enterprise Linux 8
[root@osd ~]# dnf install ceph-osd
准备 OSD。
使用之前创建的逻辑卷：
语法
ceph-volume lvm prepare --bluestore --data VOLUME_GROUP/LOGICAL_VOLUME
为
ceph-volume指定原始设备以自动创建逻辑卷：语法
ceph-volume lvm prepare --bluestore --data /PATH_TO_DEVICE如需了解更多详细信息，请参阅准备 OSD 部分。
设置
noup选项：[root@osd ~]# ceph osd set noup
激活新 OSD:
语法
ceph-volume lvm activate --bluestore OSD_ID OSD_FSID
示例
[root@osd ~]# ceph-volume lvm activate --bluestore 4 6cc43680-4f6e-4feb-92ff-9c7ba204120e
如需了解更多详细信息，请参阅 激活 OSD 部分。
注意您可以使用一个命令准备并激活 OSD。详情请参阅创建 OSD 部分。或者，您可以使用单个命令指定多个驱动器并创建 OSD。请参阅使用
batch模式。将 OSD 添加到 CRUSH map。如果指定了多个存储桶，命令会将 OSD 放置到您指定的特定存储桶中，并且会将存储桶移到您指定的任何其他 bucket 下。
语法
ceph osd crush add OSD_ID WEIGHT [ BUCKET_TYPE = BUCKET_NAME ...]
示例
[root@osd ~]# ceph osd crush add 4 1 host=node4
注意如果指定了多个存储桶，命令会将 OSD 放置到您指定的特定存储桶中，并且会将存储桶移到您指定的任何其他 bucket 下。
注意您也可以手动编辑 CRUSH map。请参阅 Red Hat Ceph Storage 策略指南中的编辑 CRUSH map 部分。
重要如果您仅指定根存储桶，则 OSD 会直接附加到 root，但 CRUSH 规则预期 OSD 在主机 bucket 内。
取消设置
noup选项：[root@osd ~]# ceph osd unset noup
为新创建的目录更新所有者和组权限：
语法
chown -R OWNER : GROUP PATH_TO_DIRECTORY
示例
[root@osd ~]# chown -R ceph:ceph /var/lib/ceph/osd [root@osd ~]# chown -R ceph:ceph /var/log/ceph [root@osd ~]# chown -R ceph:ceph /var/run/ceph [root@osd ~]# chown -R ceph:ceph /etc/ceph
如果您使用带有自定义名称的存储集群，请在适当的文件中添加以下行：
[root@osd ~]# echo "CLUSTER=CLUSTER_NAME" >> /etc/sysconfig/ceph将
CLUSTER_NAME替换为自定义存储集群名称。为确保新 OSD
已启动并准备好接收数据，请启用并启动 OSD 服务：语法
systemctl enable ceph-osd@OSD_ID systemctl start ceph-osd@OSD_ID
示例
[root@osd ~]# systemctl enable ceph-osd@4 [root@osd ~]# systemctl start ceph-osd@4
其它资源
- 如需更多信息，请参阅 Red Hat Ceph Storage 策略指南中的编辑 CRUSH map 部分。
-
有关使用
ceph-volume命令的更多信息，请参阅 Red Hat Ceph Storage 管理指南。
1.5.8. 使用容器化环境中的命令行界面添加 Ceph OSD
您可以使用容器化 Red Hat Ceph Storage 集群中的命令行界面手动添加一个或多个 Ceph OSD。
红帽建议使用 ceph-ansible 添加 Ceph OSD，除非存在异常或需要手动添加 Ceph OSD 的具体用例。如果您不确定，请联系红帽支持团队。
先决条件
- 在容器化环境中运行的 Red Hat Ceph Storage 集群。
- 具有对容器节点的 root 访问权限。
- 现有的 OSD 节点。
以下示例在 Red Hat Enterprise Linux 8 上运行。在 Red Hat Enterprise Linux 8 中，podman 是默认服务，并替换了旧的 docker 服务。如果您在 Red Hat Enterprise Linux 7 上运行，则使用 docker 替换 podman 来执行给定的命令。
流程
要创建单个 OSD，请执行
lvm prepare命令：语法
podman run --rm --net=host --privileged=true --pid=host --ipc=host -v /dev:/dev -v /etc/localtime:/etc/localtime:ro -v /var/lib/ceph:/var/lib/ceph:z -v /etc/ceph:/etc/ceph:z -v /var/run/ceph:/var/run/ceph:z -v /var/run/udev/:/var/run/udev/ -v /var/log/ceph:/var/log/ceph:z -v /run/lvm/:/run/lvm/ --entrypoint=ceph-volume PATH_TO_IMAGE --cluster CLUSTER_NAME lvm prepare --bluestore --data PATH_TO_DEVICE --no-systemd
示例
[root@osd ~]# podman run --rm --net=host --privileged=true --pid=host --ipc=host -v /dev:/dev -v /etc/localtime:/etc/localtime:ro -v /var/lib/ceph:/var/lib/ceph:z -v /etc/ceph:/etc/ceph:z -v /var/run/ceph:/var/run/ceph:z -v /var/run/udev/:/var/run/udev/ -v /var/log/ceph:/var/log/ceph:z -v /run/lvm/:/run/lvm/ --entrypoint=ceph-volume registry.redhat.io/rhceph/rhceph-4-rhel8:latest --cluster ceph lvm prepare --bluestore --data /dev/sdh --no-systemd
此示例准备一个 Bluestore Ceph OSD，其数据位于
/dev/sdh中。注意要启用并启动 OSD，请执行以下命令：
示例
[root@osd ~]# systemctl enable ceph-osd@4 [root@osd ~]# systemctl start ceph-osd@4
您还可以使用以下可选参数：
- dmcrypt
- 描述
- 为底层 OSD 设备启用加密。
- block.db
- 描述
- 到 bluestore block.db 逻辑卷或分区的路径。
- block.wal
- 描述
- 到 bluestore block.wal 逻辑卷或分区的路径。
要创建多个 Ceph OSD，请执行
lvm batch命令：语法
podman run --rm --net=host --privileged=true --pid=host --ipc=host -v /dev:/dev -v /etc/localtime:/etc/localtime:ro -v /var/lib/ceph:/var/lib/ceph:z -v /etc/ceph:/etc/ceph:z -v /var/run/ceph:/var/run/ceph:z -v /var/run/udev/:/var/run/udev/ -v /var/log/ceph:/var/log/ceph:z -v /run/lvm/:/run/lvm/ --entrypoint=ceph-volume PATH_TO_IMAGE --cluster CLUSTER_NAME lvm batch --bluestore --yes --prepare _PATH_TO_DEVICE PATH_TO_DEVICE --no-systemd
示例
[root@osd ~]# podman run --rm --net=host --privileged=true --pid=host --ipc=host -v /dev:/dev -v /etc/localtime:/etc/localtime:ro -v /var/lib/ceph:/var/lib/ceph:z -v /etc/ceph:/etc/ceph:z -v /var/run/ceph:/var/run/ceph:z -v /var/run/udev/:/var/run/udev/ -v /var/log/ceph:/var/log/ceph:z -v /run/lvm/:/run/lvm/ --entrypoint=ceph-volume registry.redhat.io/rhceph/rhceph-4-rhel8:latest --cluster ceph lvm batch --bluestore --yes --prepare /dev/sde /dev/sdf --no-systemd
这个示例使用
/dev/sde和/dev/sdf中的数据准备多个 Bluestore Ceph OSD。您还可以使用以下可选参数：
- dmcrypt
- 描述
- 为底层 OSD 设备启用加密。
- db-devices
- 描述
- 到 bluestore block.db 逻辑卷或分区的路径。
- wal-devices
- 描述
- 到 bluestore block.wal 逻辑卷或分区的路径。
1.5.9. 使用 Ansible 删除 Ceph OSD
有时，您可能需要缩减 Red Hat Ceph Storage 集群的容量。要使用 Ansible 从 Red Hat Ceph Storage 集群中删除 OSD，请运行 shrink-osd.yml playbook。
从存储集群移除 OSD 将破坏该 OSD 中包含的所有数据。
在移除 OSD 前，请验证集群有足够的空间来重新平衡。
除非您要确保 PG 处于 active+clean 状态，否则 OSD 不会同时删除 OSD，否则 OSD 不包含同一对象的副本或纠删代码分片。如果不确定，请联系红帽支持 团队。
先决条件
- 一个由 Ansible 部署的、正在运行的 Red Hat Ceph Storage。
- 正在运行的 Ansible 管理节点。
流程
进入到
/usr/share/ceph-ansible/目录。语法
[user@admin ~]$ cd /usr/share/ceph-ansible
-
将 Ceph 监控节点上的
/etc/ceph/中的 admin keyring 复制到包含您要删除的 OSD 的节点。 为 Ceph 的正常或容器化部署运行 Ansible playbook：
语法
ansible-playbook infrastructure-playbooks/shrink-osd.yml -e osd_to_kill=ID -u ANSIBLE_USER_NAME -i hosts
替换：
-
带有 OSD 节点的 ID 的
ID。要删除多个 OSD，请将 OSD ID 与逗号分开。 -
ANSIBLE_USER_NAME，Ansible 用户的名称。
示例
[user@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/shrink-osd.yml -e osd_to_kill=1 -u user -i hosts
-
带有 OSD 节点的 ID 的
验证 OSD 是否已成功移除：
语法
[root@mon ~]# ceph osd tree
其它资源
- Red Hat Ceph Storage 安装指南.
- 如需了解有关 Ansible 清单配置的更多详细信息，请参阅 {storage_product} 安装指南中的配置 Ansible 清单位置部分。
1.5.10. 使用命令行界面删除 Ceph OSD
从存储集群中移除 OSD 涉及这些步骤：* 更新 cluster map。* 删除其验证密钥。* 从 OSD map 移除 OSD。* 从 ceph.conf 文件中删除 OSD。
如果 OSD 节点有多个驱动器，您可能需要为您要删除的每个 OSD 重复此步骤来为每个驱动器移除 OSD。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
-
有足够的 OSD，使得存储集群不达到
接近全满比率。 - 对 OSD 节点的 root 级别访问。
流程
禁用和停止 OSD 服务：
语法
systemctl disable ceph-osd@OSD_ID systemctl stop ceph-osd@OSD_ID
示例
[root@osd ~]# systemctl disable ceph-osd@4 [root@osd ~]# systemctl stop ceph-osd@4
OSD 停止后，它会
关闭。从存储集群中移除 OSD：
语法
ceph osd out OSD_ID示例
[root@osd ~]# ceph osd out 4
重要删除 OSD 后，Ceph 会开始重新平衡数据，并将数据复制到存储集群中剩余的 OSD。红帽建议等待存储集群变为
active+clean，然后再继续下一步。要观察数据迁移，请运行以下命令：语法
[root@mon ~]# ceph -w
从 CRUSH map 移除 OSD，使它不再接收数据。
语法
ceph osd crush remove OSD_NAME示例
[root@osd ~]# ceph osd crush remove osd.4
注意要手动删除 OSD 和包含它的存储桶，您还可以解译 CRUSH map，从设备列表中删除 OSD，将设备移除为主机存储桶，或者移除主机存储桶。如果它位于 CRUSH map 中，并且您想要删除主机，则重新编译该映射并设置它。详情请参阅 Storage 策略指南中的反编译 CRUSH map 的说明。
移除 OSD 身份验证密钥：
语法
ceph auth del osd.OSD_ID示例
[root@osd ~]# ceph auth del osd.4
删除 OSD：
语法
ceph osd rm OSD_ID示例
[root@osd ~]# ceph osd rm 4
编辑存储集群的配置文件。文件的默认名称为
/etc/ceph/ceph.conf。如果存在，请删除文件中的 OSD 条目：示例
[osd.4] host = _HOST_NAME_
-
如果手动添加了 OSD，删除对
/etc/fstab文件中的 OSD 的引用。 将更新后的配置文件复制到存储集群中所有节点的
/etc/ceph/目录中。语法
scp /etc/ceph/CLUSTER_NAME.conf USER_NAME@HOST_NAME:/etc/ceph/
示例
[root@osd ~]# scp /etc/ceph/ceph.conf root@node4:/etc/ceph/
1.5.11. 使用命令行界面替换 BlueStore 数据库磁盘
当替换 BlueStore DB 设备 block.db 中包含 BlueStore OSD 的内部元数据时，红帽支持使用 Ansible 和命令行界面 (CLI) 重新部署所有 OSD。一个被破坏的 block.db 文件会影响到包括在那个 block.db 文件包含的所有 OSD。
替换 BlueStore block.db 磁盘的步骤是，标记每个设备，等待数据在集群中复制，替换 OSD，再重新标记它。您可以保留 OSD_ID，并使用所替换磁盘上的新 block.db 分区重新创建 OSD。虽然这只是一个简单的流程，但需要大量数据迁移。
如果 block.db 设备具有多个 OSD，则对 block.db 设备上的每个 OSD 遵循这个步骤。您可以运行 ceph-volume lvm list 来查看 block.db 到块的关系。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 带分区的存储设备。
- 所有节点的根级别访问权限。
流程
检查 monitor 节点上的当前 Ceph 集群状态：
[root@mon ~]# ceph status [root@mon ~]# ceph df
识别要替换的 OSD 失败：
[root@mon ~]# ceph osd tree | grep -i down
在 OSD 节点上停止并禁用 OSD 服务：
语法
systemctl disable ceph-osd@OSD_ID systemctl stop ceph-osd@OSD_ID
示例
[root@osd1 ~]# systemctl stop ceph-osd@1 [root@osd1 ~]# systemctl disable ceph-osd@1
在监控节点上设置 OSD
out：语法
ceph osd out OSD_ID示例
[root@mon ~]# ceph osd out 1
等待数据从 OSD 迁出：
语法
while ! ceph osd safe-to-destroy OSD_ID ; do sleep 60 ; done示例
[root@mon ~]# while ! ceph osd safe-to-destroy 1 ; do sleep 60 ; done
停止 OSD 节点上的 OSD 守护进程：
语法
systemctl kill ceph-osd@OSD_ID示例
[root@osd1 ~]# systemctl kill ceph-osd@1
记录此 OSD 使用的设备：
语法
mount | grep /var/lib/ceph/osd/ceph-OSD_ID示例
[root@osd1 ~]# mount | grep /var/lib/ceph/osd/ceph-1
卸载 OSD 节点上的故障驱动器路径的挂载点：
语法
umount /var/lib/ceph/osd/CLUSTER_NAME-OSD_ID
示例
[root@osd1 ~] #umount /var/lib/ceph/osd/ceph-1
设置
noout和norebalance以避免回填和重新平衡：[root@mon ~]# ceph osd set noout [root@mon ~]# ceph osd set norebalance
-
替换物理驱动器。请参阅硬件厂商的文档。在继续操作前，等待新驱动器出现在
/dev/目录下，并记录下驱动器路径。 销毁 monitor 节点上的 OSD：
语法
ceph osd destroy OSD_ID --yes-i-really-mean-it示例
[root@mon ~]# ceph osd destroy 1 --yes-i-really-mean-it
重要此步骤会破坏设备的内容。确保不需要该设备中的数据，且集群处于健康状态。
删除 OSD 磁盘中的逻辑卷管理器：
语法
lvremove /dev/VOLUME_GROUP/LOGICAL_VOLUME vgremove VOLUME_GROUP pvremove /dev/DEVICE
示例
[root@osd1 ~]# lvremove /dev/data-vg1/data-lv1 [root@osd1 ~]# vgremove data-vg1 [root@osd1 ~]# pvremove /dev/sdb
在 OSD 节点上 zap OSD 磁盘：
语法
ceph-volume lvm zap DEVICE示例
[root@osd1 ~]# ceph-volume lvm zap /dev/sdb
在 OSD 磁盘上重新创建 lvm：
语法
pvcreate /dev/DEVICE vgcreate VOLUME_GROUP /dev/DEVICE lvcreate -l SIZE -n LOGICAL_VOLUME VOLUME_GROUP
示例
[root@osd1 ~]# pvcreate /dev/sdb [root@osd1 ~]# vgcreate data-vg1 /dev/sdb [root@osd1 ~]# lvcreate -l 100%FREE -n data-lv1 data-vg1
在新的
block.db磁盘上创建 lvm：语法
pvcreate /dev/DEVICE vgcreate VOLUME_GROUP_DATABASE /dev/DEVICE lvcreate -Ll SIZE -n LOGICAL_VOLUME_DATABASE VOLUME_GROUP_DATABASE
示例
[root@osd1 ~]# pvcreate /dev/sdb [root@osd1 ~]# db-vg1 vgdata /dev/sdb [root@osd1 ~]# lvcreate -l 100%FREE -n lv-db1 vg-db1
在 OSD 节点上重新创建 OSD：
语法
ceph-volume lvm create --bluestore --osd-id OSD_ID --data VOLUME_GROUP/LOGICAL_VOLUME --block.db VOLUME_GROUP_DATABASE/LOGICAL_VOLUME_DATABASE
示例
[root@osd1 ~]# ceph-volume lvm create --bluestore --osd-id 1 --data data-vg1/data-lv1 --block.db db-vg1/db-lv1
注意红帽建议使用与前面步骤中销毁相同的 OSD_ID。
在 OSD 节点上启动并启用 OSD 服务：
语法
systemctl start ceph-osd@OSD_ID systemctl enable ceph-osd@OSD_ID
示例
[root@osd1 ~]# systemctl start ceph-osd@1 [root@osd1 ~]# systemctl enable ceph-osd@1
检查 CRUSH 层次结构以确保 OSD 在集群中：
[root@mon ~]# ceph osd tree
取消设置 noout 和 norebalance：
[root@mon ~]# ceph osd unset noout [root@mon ~]# ceph osd unset norebalance
监控集群状态，直到
HEALTH_OK为止：[root@mon ~]# watch -n2 ceph -s
其它资源
- 如需更多信息，请参阅 Red Hat Ceph Storage 安装指南中的安装 Red Hat Ceph Storage 集群。
1.5.12. 观察数据迁移
将 OSD 添加到 CRUSH map 时，Ceph 开始通过将放置组迁移到新的或现有的 OSD 来重新平衡数据。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 最近添加或删除 OSD。
流程
观察数据迁移：
[root@monitor ~]# ceph -w
-
在迁移完成后，观察放置组状态从
active+clean变为active, some degraded objects，最终变为active+clean。 -
要退出，请按
Ctrl + C。
1.6. 重新计算放置组
放置组(PG)定义将任何池数据分散到可用的 OSD 中。放置组基于要使用的给定冗余算法构建。对于三向复制，抗压定义冗余来使用 3 个不同的 OSD。对于纠删代码池，要使用的 OSD 数量由块数目定义。
请参阅知识库文章如何在 Ceph 集群中增加放置组(PG)计数以了解更多详细信息。
在定义池数量时，放置组的数量定义了粒度的评分，数据会分散到所有可用的 OSD 中。容量负载相等的数量越高。但是，由于处理放置组在重组数据时也很重要，因此当重新构建数据时，这个数字非常重要。支持计算工具，可生成敏捷环境。
在存储池的生命周期内可能会超过最初的预期限制。当驱动器数量增加时，建议进行重新计算。每个 OSD 的 PG 数量应当大约为 100。向存储集群添加更多 OSD 时，每个 OSD 的 PG 数量会随着时间降低。从存储集群中最初使用 120 个驱动器，将池的 pg_num 设置为 4000 的结果是每个 OSD 有 100 个 PG（复制因子为三）。随着时间的推移，当增加到 OSD 数量的十倍时，每个 OSD 的 PG 数量将仅下降到十个。由于每个 OSD 的 PG 数量较小，因此通常有不均匀地分配容量，因此请考虑调整每个池的 PG。
可以在线调整放置组的数量。重新计算 PG 数值不仅会重新计算 PG 数量，而且会涉及数据重定位，该过程会是一个冗长的过程。但是，任何时候都会维护数据可用性。
应避免每个 OSD 有大量 PG，因为对一个有故障的 OSD 上的所有 PG 进行重新构建将会一次启动。需要及时重新构建方法（可能不可用）执行大量 IOPS。这会导致深度 I/O 队列和高延迟渲染存储集群不可用，或者会导致长时间修复时间。
1.7. 使用 Ceph Manager 负载均衡器模块
balancer 是 Ceph Manager(ceph-mgr)的一个模块，用于优化 OSD 之间放置组(PG)放置，从而实现平衡的分发（可自动或监管方式）。
模式
目前支持的负载均衡器模式有两种：
CRUSH -compat ：CRUSH compat 模式使用 Ceph Luminous 中引入的兼容
weight-set功能来管理 CRUSH 层次结构中设备的备用权重集合。普通权重应保持设置为设备的大小，以反映您要存储在设备上的数据数量。然后，负载均衡器会优化weight-set值，以较小的增量调整它们，以实现与目标分布匹配的发行版。由于 PG 放置是一种伪随机进程，因此放置有自然变化；通过优化权重，平衡平衡器的作用是自然变化。这个模式与旧的客户端完全向后兼容。当 OSDMap 和 CRUSH map 与旧客户端共享时，平衡器会将优化的权重显示为实际权重。
此模式的主要限制是，如果层次结构的子树共享任何 OSD，则均衡器无法处理具有不同放置规则的多个 CRUSH 层次结构。由于此配置使得在共享 OSD 上管理空间利用率比较困难，因此通常不建议这样做。因此，这个限制通常不是问题。
upmap: 从 Luminous 开始，OSDMap 可以存储各个 OSD 的显式映射，如普通的 CRUSH 放置计算例外。这些
upmap条目提供对 PG 映射的精细控制。此 CRUSH 模式将优化各个 PG 的放置，以实现均衡的分发。在大多数情况下，此分布为"完美"，每个 OSD +/-1 PG 上相等的 PG 数量，因为它们可能无法均匀划分。重要要允许使用这个功能，您必须使用以下命令告知集群只需要支持 luminous 或更新的客户端：
[root@admin ~]# ceph osd set-require-min-compat-client luminous
如果任何 pre-luminous 客户端或守护进程连接到 monitor，则此命令会失败。
由于一个已知问题，内核 CephFS 客户端会将自身报告为 jewel 客户端。要临时解决这个问题，请使用
--yes-i-really-mean-it标志：[root@admin ~]# ceph osd set-require-min-compat-client luminous --yes-i-really-mean-it
您可以检查哪些客户端版本被用于：
[root@admin ~]# ceph features
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
流程
确保 balancer 模块位于：
示例
[root@mon ~]# ceph mgr module ls | more { "always_on_modules": [ "balancer", "crash", "devicehealth", "orchestrator_cli", "progress", "rbd_support", "status", "volumes" ], "enabled_modules": [ "dashboard", "pg_autoscaler", "prometheus" ],如果 balancer 模块没有列在
always_on或enabled模块中，则启用它：语法
ceph mgr module enable balancer
打开 balancer 模块：
[root@mon ~]# ceph balancer on
默认模式为
crush-compat。可使用以下方法更改模式：[root@mon ~]# ceph balancer mode upmap
或者
[root@mon ~]# ceph balancer mode crush-compat
状态
balancer 的当前状态可随时检查：
[root@mon ~]# ceph balancer status
自动平衡
默认情况下，在打开 balancer 模块时会使用自动平衡：
[root@mon ~]# ceph balancer on
可以使用以下方法再次关闭：
[root@mon ~]# ceph balancer off
这将使用 crush-compat 模式，它与旧的客户端向后兼容，并且会随着时间的推移对数据分发进行小更改，以确保 OSD 平等地使用。
节流
如果集群已降级，则没有对 PG 分发的调整，例如，如果 OSD 已出现故障，系统尚未修复自身。
当集群处于健康状态时，负载均衡器会节流到其更改，使得 PG 百分比被错误或需要移动，默认低于 5%。可以使用 target_max_misplaced_ratio 设置调整这个百分比。例如，将阈值增加到 7%：
示例
[root@mon ~]# ceph config set mgr target_max_misplaced_ratio .07
用于自动平衡：
- 将自动负载均衡器运行间隔之间的秒数设置为 sleep ：
示例
[root@mon ~]# ceph config set mgr mgr/balancer/sleep_interval 60
- 将天数设置为以 HHMM 格式开始自动平衡：
示例
[root@mon ~]# ceph config set mgr mgr/balancer/begin_time 0000
- 以 HHMM 格式设置一天完成自动平衡的时间：
示例
[root@mon ~]# ceph config set mgr mgr/balancer/end_time 2359
-
将自动平衡限制为一周或之后的这一天。使用与 crontab 相同的惯例，
0代表星期日，1代表星期一，以此类推：
示例
[root@mon ~]# ceph config set mgr mgr/balancer/begin_weekday 0
-
将自动平衡限制为一周或更早的这一天。这使用与 crontab 相同惯例，
0代表星期日，1代表星期一，以此类推：
示例
[root@mon ~]# ceph config set mgr mgr/balancer/end_weekday 6
-
定义自动平衡限制的池 ID。这样做的默认值是一个空字符串，这意味着所有池都是均衡的。可以使用
ceph osd pool ls detail命令获取数字池 ID：
示例
[root@mon ~]# ceph config set mgr mgr/balancer/pool_ids 1,2,3
监控的优化
balancer 操作分为几个不同的阶段：
-
构建
计划。 -
评估数据分发的质量，针对当前的 PG 分发，或在执行一个
计划（plan）后生成的 PG 分发。 执行
计划。评估和分数当前发行版：
[root@mon ~]# ceph balancer eval
评估单个池的分发：
语法
ceph balancer eval POOL_NAME示例
[root@mon ~]# ceph balancer eval rbd
查看更多评估详情：
[root@mon ~]# ceph balancer eval-verbose ...
使用当前配置模式生成计划：
语法
ceph balancer optimize PLAN_NAME使用自定义计划名称替换 PLAN_NAME。
示例
[root@mon ~]# ceph balancer optimize rbd_123
查看计划的内容：
语法
ceph balancer show PLAN_NAME示例
[root@mon ~]# ceph balancer show rbd_123
要丢弃旧计划：
语法
ceph balancer rm PLAN_NAME示例
[root@mon ~]# ceph balancer rm rbd_123
要查看当前记录的计划，请使用 status 命令：
[root@mon ~]# ceph balancer status
要计算执行计划后结果的分发质量：
语法
ceph balancer eval PLAN_NAME示例
[root@mon ~]# ceph balancer eval rbd_123
执行计划：
语法
ceph balancer execute PLAN_NAME示例
[root@mon ~]# ceph balancer execute rbd_123
注意仅在希望改进发行版时执行计划。执行后，计划将被丢弃。
1.8. 使用 upmap 在 OSD 上手动重新平衡数据
作为存储管理员，您可以通过将选定的放置组 (PG) 移到特定的 OSD，在 OSD 上手动重新平衡数据。要执行手动重新平衡，请关闭 Ceph Manager balancer 模块，并使用 upmap 模式来移动 PG。
先决条件
- 正在运行的红帽存储集群。
- 对存储集群中所有节点的根级别访问权限。
流程
确保 balancer 模块位于：
示例
[root@mon ~]# ceph mgr module ls | more { "always_on_modules": [ "balancer", "crash", "devicehealth", "orchestrator_cli", "progress", "rbd_support", "status", "volumes" ], "enabled_modules": [ "dashboard", "pg_autoscaler", "prometheus" ],如果 balancer 模块没有列在
always_on或enabled模块中，则启用它：语法
ceph mgr module enable balancer
将负载均衡器模式设置为
upmap：语法
ceph balancer mode upmap
关闭 balancer 模块：
语法
ceph balancer off
检查负载均衡器状态：
示例
[root@mon ~]# ceph balancer status { "plans": [], "active": false, "last_optimize_started": "", "last_optimize_duration": "", "optimize_result": "", "mode": "upmap" }为 OSD 设置
norebalance标志：语法
ceph osd set norebalance
使用
ceph pg dump pgs_brief命令列出存储集群中的池，各自消耗的空间。使用grep搜索重新映射的池。示例
[root@mon ~]# ceph pg dump pgs_brief PG_STAT STATE UP UP_PRIMARY ACTING ACTING_PRIMARY dumped pgs_brief 7.270 active+remapped+backfilling [8,48,61] 8 [46,48,61] 46 7.1e7 active+remapped+backfilling [73,64,74] 73 [18,64,74] 18 7.1c1 active+remapped+backfilling [29,14,8] 29 [29,14,24] 29 7.17f active+remapped+backfilling [73,71,50] 73 [50,71,69] 50 7.16c active+remapped+backfilling [66,8,4] 66 [66,4,57] 66 7.13d active+remapped+backfilling [73,27,56] 73 [27,56,35] 27 7.130 active+remapped+backfilling [53,47,73] 53 [53,47,72] 53 9.e0 active+remapped+backfilling [8,75,14] 8 [14,75,58] 14 7.db active+remapped+backfilling [10,57,60] 10 [10,60,50] 10 9.7 active+remapped+backfilling [26,69,38] 26 [26,38,41] 26 7.4a active+remapped+backfilling [73,10,76] 73 [10,76,29] 10 9.9a active+remapped+backfilling [20,15,73] 20 [20,15,29] 20 7.ac active+remapped+backfilling [8,74,3] 8 [3,74,37] 3 9.c2 active+remapped+backfilling [57,75,7] 57 [4,75,7] 4 7.34d active+remapped+backfilling [23,46,73] 23 [23,46,56] 23 7.36a active+remapped+backfilling [40,32,8] 40 [40,32,44] 40
将 PG 移到您希望它们所在的 OSD。例如，将 PG 7.ac 从 OSD 8 和 3 移到 OSD 3 和 37:
示例
PG_STAT STATE UP UP_PRIMARY ACTING ACTING_PRIMARY dumped pgs_brief 7.ac active+remapped+backfilling [8,74,3] 8 [3,74,37] 3 [root@mon ~]# ceph osd pg-upmap-items 7.ac 8 3 3 37 7.ac active+clean [3,74,37] 8 [3,74,37] 3
注意重复此步骤，以每次移动每个重新 map 的 PG。
再次使用
ceph pg dump pgs_brief命令检查 PG 是否移至active+clean状态：示例
[root@mon ~]# ceph pg dump pgs_brief PG_STAT STATE UP UP_PRIMARY ACTING ACTING_PRIMARY dumped pgs_brief 7.270 active+clean [8,48,61] 8 [46,48,61] 46 7.1e7 active+clean [73,64,74] 73 [18,64,74] 18 7.1c1 active+clean [29,14,8] 29 [29,14,24] 29 7.17f active+clean [73,71,50] 73 [50,71,69] 50 7.16c active+clean [66,8,4] 66 [66,4,57] 66 7.13d active+clean [73,27,56] 73 [27,56,35] 27 7.130 active+clean [53,47,73] 53 [53,47,72] 53 9.e0 active+clean [8,75,14] 8 [14,75,58] 14 7.db active+clean [10,57,60] 10 [10,60,50] 10 9.7 active+clean [26,69,38] 26 [26,38,41] 26 7.4a active+clean [73,10,76] 73 [10,76,29] 10 9.9a active+clean [20,15,73] 20 [20,15,29] 20 7.ac active+clean [3,74,37] 8 [3,74,37] 3 9.c2 active+clean [57,75,7] 57 [4,75,7] 4 7.34d active+clean [23,46,73] 23 [23,46,56] 23 7.36a active+clean [40,32,8] 40 [40,32,44] 40
PG 移至
active+clean所需的时间取决于 PG 和 OSD 的数量。另外，错误放入的对象数量取决于为mgr target_max_misplaced_ratio设置的值。为target_max_misplaced_ratio设置了一个更高的值，则会导致大量错误替换的对象；因此，所有 PG 都需要较长的时间才能变为active+clean。取消设置
norebalance标志：语法
ceph osd unset norebalance
重新打开 balancer 模块：
语法
ceph balancer on
启用 balancer 模块后，它会逐渐根据存储集群的 CRUSH 规则将 PG 移到其预期的 OSD 中。平衡过程可能需要一些时间，但最终完成。
1.9. 使用 Ceph Manager 警报模块
您可以使用 Ceph 管理器警报模块通过电子邮件发送关于 Red Hat Ceph Storage 集群健康状况的简单警报消息。
这个模块并不是一个可靠的监控解决方案。作为 Ceph 集群本身一部分运行的事实是，在 ceph-mgr 守护进程出现故障时，它完全限制会防止警报被发送。但是，对于没有监控架构的环境中存在的一个独立的集群非常有用。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- Ceph 监控节点的根级别访问权限.
流程
启用警报模块：
示例
[root@host01 ~]# ceph mgr module enable alerts
确保启用了 alert 模块：
示例
[root@host01 ~]# ceph mgr module ls | more { "always_on_modules": [ "balancer", "crash", "devicehealth", "orchestrator_cli", "progress", "rbd_support", "status", "volumes" ], "enabled_modules": [ "alerts", "dashboard", "pg_autoscaler", "nfs", "prometheus", "restful" ]配置简单邮件传输协议(SMTP)：
语法
ceph config set mgr mgr/alerts/smtp_host SMTP_SERVER ceph config set mgr mgr/alerts/smtp_destination RECEIVER_EMAIL_ADDRESS ceph config set mgr mgr/alerts/smtp_sender SENDER_EMAIL_ADDRESS
示例
[root@host01 ~]# ceph config set mgr mgr/alerts/smtp_host smtp.example.com [root@host01 ~]# ceph config set mgr mgr/alerts/smtp_destination example@example.com [root@host01 ~]# ceph config set mgr mgr/alerts/smtp_sender example2@example.com
可选： 默认情况下，警报模块使用 SSL 和端口 465。要更改它，将
smtp_ssl设置为false：语法
ceph config set mgr mgr/alerts/smtp_ssl false ceph config set mgr mgr/alerts/smtp_port PORT_NUMBER示例
[root@host01 ~]# ceph config set mgr mgr/alerts/smtp_ssl false [root@host01 ~]# ceph config set mgr mgr/alerts/smtp_port 587
对 SMTP 服务器进行身份验证：
语法
ceph config set mgr mgr/alerts/smtp_user USERNAME ceph config set mgr mgr/alerts/smtp_password PASSWORD
示例
[root@host01 ~]# ceph config set mgr mgr/alerts/smtp_user admin1234 [root@host01 ~]# ceph config set mgr mgr/alerts/smtp_password admin1234
可选：默认情况下，SMTP
From名称是Ceph。要更改它，请设置smtp_from_name参数：语法
ceph config set mgr mgr/alerts/smtp_from_name CLUSTER_NAME示例
[root@host01 ~]# ceph config set mgr mgr/alerts/smtp_from_name 'Ceph Cluster Test'
可选：默认情况下，警报模块会每分钟检查存储集群的健康状况，并在集群健康状况有变化时发送消息。要更改频率，请设置
interval参数：语法
ceph config set mgr mgr/alerts/interval INTERVAL示例
[root@host01 ~]# ceph config set mgr mgr/alerts/interval "5m"
在本例中，间隔设置为 5 分钟。
可选：立即发送警报：
示例
[root@host01 ~]# ceph alerts send
其它资源
- 有关 Ceph 健康消息的更多信息，请参阅 Red Hat Ceph Storage 故障排除指南中的 Ceph 集群的健康状态信息。
1.10. 使用 Ceph 管理器 crash 模块
通过使用 Ceph 管理器 crash 模块，您可以收集有关守护进程 crashdumps 的信息，并将其存储在 Red Hat Ceph Storage 集群中，以便进一步分析。
默认情况下，守护进程崩溃转储在 /var/lib/ceph/crash 中转储。您可以使用选项 crash dir 配置 crashdump。崩溃目录按时间、日期和随机生成的 UUID 命名，包含元数据文件 meta 和最近日志文件，其具有同样的 crash_id。
您可以使用 ceph-crash.service 自动提交这些崩溃，并在 Ceph 监控器中保留。ceph-crash.service 监视 crashdump 目录，并使用 ceph crash post 上传它们。
RECENT_CRASH heath 消息是 Ceph 集群中最常见的运行状况消息之一。此健康消息表示，一个或多个 Ceph 守护进程最近崩溃，且崩溃尚未存档或被管理员确认。这可能表示软件错误、硬件问题（如磁盘失败）或其它问题。选项 mgr/crash/warn_recent_interval 控制最近一次表示的时间周期，默认为两周。您可以运行以下命令来禁用警告：
示例
[root@mon ~]# ceph config set mgr/crash/warn_recent_interval 0
选项 mgr/crash/retain_interval 控制您要保留崩溃报告的周期，然后再自动清除崩溃报告。这个选项的默认值是一年。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
流程
确定启用了 crash 模块：
示例
[root@mon ~]# ceph mgr module ls | more { "always_on_modules": [ "balancer", "crash", "devicehealth", "orchestrator_cli", "progress", "rbd_support", "status", "volumes" ], "enabled_modules": [ "dashboard", "pg_autoscaler", "prometheus" ]保存崩溃转储：元数据文件是存储在 crash dir 中作为
meta的 JSON blob。您可以调用 ceph 命令-i -选项，该选项会从 stdin 读取。示例
[root@mon ~]# ceph crash post -i meta
列出所有新的以及归档的崩溃信息的时间戳或 UUID 崩溃 ID：
示例
[root@mon ~]# ceph crash ls
列出所有崩溃信息的时间戳或 UUID 崩溃 ID：
示例
[root@mon ~]# ceph crash ls-new
列出所有崩溃信息的时间戳或 UUID 崩溃 ID：
示例
[root@mon ~]# ceph crash ls-new
列出按年龄分组的崩溃信息概述：
示例
[root@mon ~]# ceph crash stat 8 crashes recorded 8 older than 1 days old: 2021-05-20T08:30:14.533316Z_4ea88673-8db6-4959-a8c6-0eea22d305c2 2021-05-20T08:30:14.590789Z_30a8bb92-2147-4e0f-a58b-a12c2c73d4f5 2021-05-20T08:34:42.278648Z_6a91a778-bce6-4ef3-a3fb-84c4276c8297 2021-05-20T08:34:42.801268Z_e5f25c74-c381-46b1-bee3-63d891f9fc2d 2021-05-20T08:34:42.803141Z_96adfc59-be3a-4a38-9981-e71ad3d55e47 2021-05-20T08:34:42.830416Z_e45ed474-550c-44b3-b9bb-283e3f4cc1fe 2021-05-24T19:58:42.549073Z_b2382865-ea89-4be2-b46f-9a59af7b7a2d 2021-05-24T19:58:44.315282Z_1847afbc-f8a9-45da-94e8-5aef0738954e
查看保存崩溃的详情：
语法
ceph crash info CRASH_ID示例
[root@mon ~]# ceph crash info 2021-05-24T19:58:42.549073Z_b2382865-ea89-4be2-b46f-9a59af7b7a2d { "assert_condition": "session_map.sessions.empty()", "assert_file": "/builddir/build/BUILD/ceph-16.1.0-486-g324d7073/src/mon/Monitor.cc", "assert_func": "virtual Monitor::~Monitor()", "assert_line": 287, "assert_msg": "/builddir/build/BUILD/ceph-16.1.0-486-g324d7073/src/mon/Monitor.cc: In function 'virtual Monitor::~Monitor()' thread 7f67a1aeb700 time 2021-05-24T19:58:42.545485+0000\n/builddir/build/BUILD/ceph-16.1.0-486-g324d7073/src/mon/Monitor.cc: 287: FAILED ceph_assert(session_map.sessions.empty())\n", "assert_thread_name": "ceph-mon", "backtrace": [ "/lib64/libpthread.so.0(+0x12b30) [0x7f679678bb30]", "gsignal()", "abort()", "(ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x1a9) [0x7f6798c8d37b]", "/usr/lib64/ceph/libceph-common.so.2(+0x276544) [0x7f6798c8d544]", "(Monitor::~Monitor()+0xe30) [0x561152ed3c80]", "(Monitor::~Monitor()+0xd) [0x561152ed3cdd]", "main()", "__libc_start_main()", "_start()" ], "ceph_version": "14.1.0-486.el8cp", "crash_id": "2021-05-24T19:58:42.549073Z_b2382865-ea89-4be2-b46f-9a59af7b7a2d", "entity_name": "mon.ceph-adm4", "os_id": "rhel", "os_name": "Red Hat Enterprise Linux", "os_version": "8.3 (Ootpa)", "os_version_id": "8.3", "process_name": "ceph-mon", "stack_sig": "957c21d558d0cba4cee9e8aaf9227b3b1b09738b8a4d2c9f4dc26d9233b0d511", "timestamp": "2021-05-24T19:58:42.549073Z", "utsname_hostname": "host02", "utsname_machine": "x86_64", "utsname_release": "4.18.0-240.15.1.el8_3.x86_64", "utsname_sysname": "Linux", "utsname_version": "#1 SMP Wed Feb 3 03:12:15 EST 2021" }删除比 KEEP days 旧的已保存的崩溃：其中 KEEP 必须是一个整数。
语法
ceph crash prune KEEP示例
[root@mon ~]# ceph crash prune 60
对崩溃报告进行归档，使其不再被视为
RECENT_CRASH健康检查，且不会出现在crash ls-new输出中。它会出现在crash ls中。语法
ceph crash archive CRASH_ID示例
[root@mon ~]# ceph crash archive 2021-05-24T19:58:42.549073Z_b2382865-ea89-4be2-b46f-9a59af7b7a2d
记录所有崩溃报告：
示例
[root@mon ~]# ceph crash archive-all
删除崩溃转储：
语法
ceph crash rm CRASH_ID示例
[root@mon ~]# ceph crash rm 2021-05-24T19:58:42.549073Z_b2382865-ea89-4be2-b46f-9a59af7b7a2d
其它资源
- 有关 Ceph 健康消息的更多信息，请参阅 Red Hat Ceph Storage 故障排除指南中的 Ceph 集群的健康状态信息。
1.11. 迁移 RBD 镜像守护进程
对于使用裸机存储集群中命令行界面配置的双向块设备(RBD)镜像，集群不会迁移 RBD 镜像。在升级存储集群或将集群转换为容器化之前，将 RBD 镜像守护进程从 CLI 迁移到 Ceph-Ansible。
先决条件
- 正在运行的红帽 Ceph 存储非容器化、裸机、集群。
- 访问 Ansible 管理节点.
- ansible 用户帐户。
- sudo 对 ansible 用户帐户的访问权限。
流程
在 Ceph 客户端节点上创建一个用户：
语法
ceph auth get client.PRIMARY_CLUSTER_NAME -o /etc/ceph/ceph.PRIMARY_CLUSTER_NAME.keyring
示例
[root@rbd-client-site-a ~]# ceph auth get client.rbd-mirror.site-a -o /etc/ceph/ceph.client.rbd-mirror.site-a.keyring
更改
/etc/ceph目录中的auth文件中的用户名：示例
[client.rbd-mirror.rbd-client-site-a] key = AQCbKbVg+E7POBAA7COSZCodvOrg2LWIFc9+3g== caps mds = "allow *" caps mgr = "allow *" caps mon = "allow *" caps osd = "allow *"导入
auth文件以添加相关权限：语法
ceph auth import -i PATH_TO_KEYRING示例
[root@rbd-client-site-a ~]# ceph auth import -i /etc/ceph/ceph.client.rbd-mirror.rbd-client-site-a.keyring
检查 RBD 镜像节点的服务名称：
示例
[root@rbd-client-site-a ~]# systemctl list-units --all systemctl stop ceph-rbd-mirror@rbd-client-site-a.service systemctl disable ceph-rbd-mirror@rbd-client-site-a.service systemctl reset-failed ceph-rbd-mirror@rbd-client-site-a.service systemctl start ceph-rbd-mirror@rbd-mirror.rbd-client-site-a.service systemctl enable ceph-rbd-mirror@rbd-mirror.rbd-client-site-a.service systemctl status ceph-rbd-mirror@rbd-mirror.rbd-client-site-a.service
将 rbd-mirror 节点添加到
/etc/ansible/hosts文件中：示例
[rbdmirrors] ceph.client.rbd-mirror.rbd-client-site-a
1.12. 其它资源
- 有关安装 Red Hat Ceph Storage 产品的详细信息，请参阅 Red Hat Ceph Storage 安装指南。
- 如需更多信息，请参阅 Red Hat Ceph Storage 策略指南中的 放置组(PG) 一章。
- 详情请查看 Red Hat Enterprise Linux 8 配置和管理逻辑卷指南。
第 2 章 处理磁盘失败
作为存储管理员，在存储集群的整个生命周期内，您必须处理磁盘故障。在发生实际故障前测试并模拟磁盘出现故障的情况，确保在故障实际发生时已做好准备。
以下是替换失败磁盘的高级别工作流：
- 查找失败的 OSD。
- 将 OSD 出去。
- 在节点上停止 OSD 守护进程。
- 检查 Ceph 的状态。
- 从 CRUSH map 移除 OSD。
- 删除 OSD 授权。
- 从存储集群移除 OSD。
- 卸载节点上的文件系统。
- 替换失败的驱动器。
- 将 OSD 后端添加到存储集群。
- 检查 Ceph 的状态。
2.1. 先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 一个失败的磁盘。
2.2. 磁盘故障
Ceph 是为容错而设计的，这意味着 Ceph 可以在不丢失数据的情况下以降级状态运行。即使数据存储驱动器失败，Ceph 仍然可以运行。degraded 状态意味着其他 OSD 上存储的数据的额外副本将自动回填到集群中的其他 OSD。当 OSD 被标记为 down 时，这代表驱动器失败。
当驱动器出现故障时，首先，OSD 状态将 停机，但仍然 在 存储集群中。网络问题也可以将 OSD 标记为 down，即使它实际已经启动。首先检查环境中的任何网络问题。如果网络检查正常，则 OSD 驱动器很可能失败。
现代服务器通常使用热插拔驱动器进行部署，以便您可以将失败的驱动器替换为新的驱动器，而无需关闭节点。但是，在使用 Ceph 时，您还需要删除 OSD 中的软件定义部分。
2.3. 模拟磁盘失败
磁盘故障有两种：硬和软。硬故障意味着需要替换磁盘。软故障可能是设备驱动程序或其它一些软件组件的问题。
如果是软故障，可能不需要替换磁盘。如果替换磁盘，则需要遵循步骤来删除失败的磁盘，并将替换磁盘添加到 Ceph。为了模拟软磁盘失败，最好的操作是删除该设备。选择一个设备并从系统中删除设备。
先决条件
- 一个正常运行的 Red Hat Ceph Storage 集群。
- 对 Ceph OSD 节点的 root 级别访问权限。
流程
从
sysfs中删除块设备：语法
echo 1 > /sys/block/BLOCK_DEVICE/device/delete示例
[root@osd ~]# echo 1 > /sys/block/sdb/device/delete
在 Ceph OSD 日志中，Ceph 会检测到故障，并且自动启动恢复过程。
示例
[root@osd ~]# tail -50 /var/log/ceph/ceph-osd.1.log 2020-09-02 15:50:50.187067 7ff1ce9a8d80 1 bdev(0x563d263d4600 /var/lib/ceph/osd/ceph-2/block) close 2020-09-02 15:50:50.440398 7ff1ce9a8d80 -1 osd.2 0 OSD:init: unable to mount object store 2020-09-02 15:50:50.440416 7ff1ce9a8d80 -1 ^[[0;31m ** ERROR: osd init failed: (5) Input/output error^[[0m 2020-09-02 15:51:10.633738 7f495c44bd80 0 set uid:gid to 167:167 (ceph:ceph) 2020-09-02 15:51:10.633752 7f495c44bd80 0 ceph version 12.2.12-124.el7cp (e8948288b90d312c206301a9fcf80788fbc3b1f8) luminous (stable), process ceph-osd, pid 36209 2020-09-02 15:51:10.634703 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error 2020-09-02 15:51:10.635749 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error 2020-09-02 15:51:10.636642 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error 2020-09-02 15:51:10.637535 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error 2020-09-02 15:51:10.641256 7f495c44bd80 0 pidfile_write: ignore empty --pid-file 2020-09-02 15:51:10.669317 7f495c44bd80 0 load: jerasure load: lrc load: isa 2020-09-02 15:51:10.669387 7f495c44bd80 1 bdev create path /var/lib/ceph/osd/ceph-2/block type kernel 2020-09-02 15:51:10.669395 7f495c44bd80 1 bdev(0x55a423da9200 /var/lib/ceph/osd/ceph-2/block) open path /var/lib/ceph/osd/ceph-2/block 2020-09-02 15:51:10.669611 7f495c44bd80 1 bdev(0x55a423da9200 /var/lib/ceph/osd/ceph-2/block) open size 500103643136 (0x7470800000, 466GiB) block_size 4096 (4KiB) rotational 2020-09-02 15:51:10.670320 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error 2020-09-02 15:51:10.670328 7f495c44bd80 1 bdev(0x55a423da9200 /var/lib/ceph/osd/ceph-2/block) close 2020-09-02 15:51:10.924727 7f495c44bd80 1 bluestore(/var/lib/ceph/osd/ceph-2) _mount path /var/lib/ceph/osd/ceph-2 2020-09-02 15:51:10.925582 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error 2020-09-02 15:51:10.925628 7f495c44bd80 1 bdev create path /var/lib/ceph/osd/ceph-2/block type kernel 2020-09-02 15:51:10.925630 7f495c44bd80 1 bdev(0x55a423da8600 /var/lib/ceph/osd/ceph-2/block) open path /var/lib/ceph/osd/ceph-2/block 2020-09-02 15:51:10.925784 7f495c44bd80 1 bdev(0x55a423da8600 /var/lib/ceph/osd/ceph-2/block) open size 500103643136 (0x7470800000, 466GiB) block_size 4096 (4KiB) rotational 2020-09-02 15:51:10.926549 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error
查看 Ceph OSD 磁盘树，我们也会看到磁盘离线。
示例
[root@osd ~]# ceph osd tree ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY -1 0.28976 root default -2 0.09659 host ceph3 1 0.09659 osd.1 down 1.00000 1.00000 -3 0.09659 host ceph1 2 0.09659 osd.2 up 1.00000 1.00000 -4 0.09659 host ceph2 0 0.09659 osd.0 up 1.00000 1.00000
2.4. 替换失败的 OSD 磁盘
替换 OSD 的一般步骤涉及从存储集群中移除 OSD，替换驱动器，然后重新创建 OSD。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 一个失败的磁盘。
流程
检查存储集群健康状况：
[root@mon ~]# ceph health
识别 CRUSH 层次结构中的 OSD 位置：
[root@mon ~]# ceph osd tree | grep -i down
在 OSD 节点上，尝试启动 OSD：
语法
systemctl start ceph-osd@OSD_ID如果命令显示 OSD 已在运行，则可能存在心跳或网络问题。如果您无法重启 OSD，则驱动器可能会失败。
注意如果 OSD 为
down，则 OSD 最终将被标记为out。这是 Ceph 存储的正常行为。当 OSD 标记为out时，具有故障 OSD 数据副本的其他 OSD 将开始回填，以确保存储集群中存在所需的副本数。当存储集群进行回填时，集群会处于降级状态。对于 Ceph 的容器化部署，请尝试使用 OSD_ID 启动 OSD 容器：
语法
systemctl start ceph-osd@OSD_ID如果命令显示 OSD 已在运行，则可能存在心跳或网络问题。如果您无法重启 OSD，则驱动器可能会失败。
注意与 OSD 关联的驱动器可以通过将容器 OSD ID 映射到驱动器来确定。
检查失败的 OSD 的挂载点：
注意对于 Ceph 的容器化部署，如果 OSD 停机，并且 OSD 驱动器将被卸载，因此您无法运行
df来检查其挂载点。使用另一种方法来确定 OSD 驱动器是否已失败。例如，在容器节点的驱动器上运行smartctl。[root@osd ~]# df -h
如果无法重启 OSD，您可以检查挂载点。如果挂载点不再显示，您可以尝试重新挂载 OSD 驱动器并重新启动 OSD。如果无法恢复挂载点，则可能有一个失败的 OSD 驱动器。
使用
smartctl程序 cab 帮助确定驱动器是否健康：语法
yum install smartmontools smartctl -H /dev/BLOCK_DEVICE示例
[root@osd ~]# smartctl -H /dev/sda
如果驱动器失败，则需要替换它。
停止 OSD 进程：
语法
systemctl stop ceph-osd@OSD_ID对于 Ceph 的容器化部署，请停止 OSD 容器：
语法
systemctl stop ceph-osd@OSD_ID从存储集群中移除 OSD：
语法
ceph osd out OSD_ID确保失败的 OSD 正在回填：
[root@osd ~]# ceph -w
从 CRUSH map 移除 OSD：
语法
ceph osd crush remove osd.OSD_ID注意只有在您永久删除 OSD 且没有重新部署时，才需要执行此步骤。
删除 OSD 的身份验证密钥：
语法
ceph auth del osd.OSD_ID验证 OSD 的密钥没有被列出：
示例
[root@osd ~]# ceph auth list
从存储集群中移除 OSD：
语法
ceph osd rm osd.OSD_ID卸载失败的驱动器路径：
语法
umount /var/lib/ceph/osd/CLUSTER_NAME-OSD_ID
示例
[root@osd ~]# umount /var/lib/ceph/osd/ceph-0
注意对于 Ceph 容器化部署，如果 OSD 关闭容器，则将卸载 OSD 驱动器。在这种情况下，没有卸载，并可以跳过此步骤。
替换物理驱动器。请参阅硬件厂商的文档。如果驱动器是热交换的，只需将故障驱动器替换为新驱动器。如果驱动器不热交换，且节点包含多个 OSD，则 MIGHT 需要关闭节点来取代物理驱动器。如果需要临时关闭节点，您可以将集群设置为
noout以防止回填：示例
[root@osd ~]# ceph osd set noout
替换驱动器后，您使节点及其 OSD 重新在线，删除
noout设置：示例
[root@osd ~]# ceph osd unset noout
在继续操作前，等待新驱动器出现在
/dev/目录下，并记录下驱动器路径。- 查找 OSD 驱动器并格式化磁盘。
重新创建 OSD：
- 使用 Ceph Ansible.
- 使用命令行界面。
检查 CRUSH 层次结构以确保其准确：
示例
[root@osd ~]# ceph osd tree
如果您对 OSD 在 CRUSH 层次结构中的位置不满意，您可以使用
move命令移动它：语法
ceph osd crush move BUCKET_TO_MOVE BUCKET_TYPE=PARENT_BUCKET
- 验证 OSD 是否在线。
2.5. 在保留 OSD ID 时替换 OSD 驱动器
在替换失败的 OSD 驱动器时，您可以保留原始 OSD ID 和 CRUSH map 条目。
ceph-volume lvm 命令默认为 OSD 的 BlueStore。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 一个失败的磁盘。
流程
销毁 OSD：
语法
ceph osd destroy OSD_ID --yes-i-really-mean-it示例
[root@osd ~]# ceph osd destroy 1 --yes-i-really-mean-it
另外，如果之前使用替换磁盘，则需要
zap磁盘：语法
ceph-volume lvm zap DEVICE示例
[root@osd ~]# ceph-volume lvm zap /dev/sdb
注意您可以通过比较各种命令的输出（如
ceph osd tree、ceph osd metadata和df）来查找 DEVICE。使用现有 OSD ID 创建新 OSD：
语法
ceph-volume lvm create --osd-id OSD_ID --data DEVICE
示例
[root@mon ~]# ceph-volume lvm create --osd-id 1 --data /dev/sdb
其它资源
- 如需更多详细信息，请参阅 Red Hat Ceph Storage Operations Guide 中的使用 Ansible 添加具有相同磁盘拓扑的 Ceph OSD 部分。
- 如需更多详细信息，请参阅 Red Hat Ceph Storage Operations Guide 中的使用 Ansible 添加具有不同磁盘拓扑的 Ceph OSD 部分。
- 如需更多详细信息，请参阅 Red Hat Ceph Storage 操作指南中的使用 'ceph-volume' 准备 Ceph OSD。
- 如需更多详细信息，请参阅 Red Hat Ceph Storage 操作指南中的使用 'ceph-volume' 激活 Ceph OSD。
- 如需了解更多详细信息，请参阅 Red Hat Ceph Storage Operations 指南中的使用命令行界面部分来添加 Ceph OSD。
第 3 章 处理节点失败
作为存储管理员，您可以在存储集群中遇到整个节点故障，处理节点故障与处理磁盘故障类似。当节点出现故障时，Ceph 仅为一个磁盘恢复放置组(PG)，则该节点内磁盘上的所有 PG 必须被恢复。Ceph 将检测 OSD 是否都停止，并且自动启动恢复过程，称为自我修复。
有三个节点故障场景。以下是替换节点时每个情境的高级工作流：
替换节点，但使用故障节点的 root 和 Ceph OSD 磁盘。
- 禁用回填。
- 替换节点，从旧节点获取磁盘，并将它们添加到新节点。
- 启用回填。
替换节点，重新安装操作系统，并使用来自故障节点的 Ceph OSD 磁盘。
- 禁用回填。
- 创建 Ceph 配置的备份。
替换节点，再添加来自故障节点的 Ceph OSD 磁盘。
- 将磁盘配置为 JBOD.
- 安装操作系统。
- 恢复 Ceph 配置。
-
运行
ceph-ansible。 - 启用回填。
替换节点、重新安装操作系统和使用所有新的 Ceph OSD 磁盘。
- 禁用回填。
- 从存储集群中移除故障节点上的所有 OSD。
- 创建 Ceph 配置的备份。
替换节点，再添加来自故障节点的 Ceph OSD 磁盘。
- 将磁盘配置为 JBOD.
- 安装操作系统。
-
运行
ceph-ansible。 - 启用回填。
3.1. 先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 失败的节点。
3.2. 在添加或删除节点前的注意事项
Ceph 的一个未完成的功能是能够在运行时添加或删除 Ceph OSD 节点。这意味着，您可以在不关闭存储集群的情况下调整存储集群容量或替换硬件的大小。
在存储集群 处于降级状态 的同时，为 Ceph 客户端提供可操作性的功能。例如，您可以在常规工作时间内添加或删除硬件，而不是在工作时间外或周末操作。但是，添加和删除 Ceph OSD 节点可能会对性能产生重大影响。
在添加或删除 Ceph OSD 节点前，请考虑以下对存储集群性能的影响：
- 无论您要扩展或减少存储容量，添加或删除 Ceph OSD 节点，都会降低回填存储集群重新平衡。在进行重新平衡期间，Ceph 使用额外的资源，这可能会影响存储集群性能。
- 在生产环境的 Ceph 存储集群中，Ceph OSD 节点具有特定的硬件配置，有助于实现特定类型的存储策略。
- 由于 Ceph OSD 节点是 CRUSH 层次结构中的一部分，因此添加或删除节点的性能通常会影响使用 CRUSH 规则集的池的性能。
3.3. 性能考虑
在添加或删除 Ceph OSD 节点时，以下因素通常会影响存储集群的性能：
- Ceph 客户端将负载放到 Ceph 的 I/O 接口上；也就是说，客户端会将负载放入池。池映射到 CRUSH 规则集。底层 CRUSH 层次结构允许 Ceph 在故障域之间放置数据。如果底层 Ceph OSD 节点涉及有高客户端负载的池，客户端负载可能会显著影响恢复时间和降低性能。因为写入操作需要数据复制才能进行持久性，特别是写入密集型客户端负载可能会增加存储集群的时间来恢复。
- 通常，您要添加或删除的容量会影响存储集群恢复的时间。另外，您添加或删除的节点的存储密度也会影响恢复时间。例如，具有 36 个 OSD 的节点通常需要更长的时间来恢复具有 12 个 OSD 的节点。
-
移除节点时，您需要确保有足够的备用容量，以便您的系统不会达到
全满比率或接近满比率。如果存储集群达到全满比率，Ceph 将挂起写操作以防止数据丢失。 - Ceph OSD 节点映射到至少一个 Ceph CRUSH 层次结构，层次结构则映射到至少一个池。在添加或删除 Ceph OSD 节点时，使用 CRUSH 规则集的每个池都会遇到性能影响。
-
复制池往往使用更多网络带宽来复制数据的深度副本，而纠删代码池则倾向于使用更多 CPU 来计算
k+m编码区块。存在数据的副本越多，存储集群需要较长才能恢复。例如，一个大于k+m块的大池或一个要比同一数据副本较少的复制池恢复的时间要更长。 - 驱动器、控制器和网络接口卡都有可能影响恢复时间的吞吐量特征。通常，具有更高吞吐量的节点（如 10 Gbps 和 SSD）可以比具有较低吞吐量的节点快速恢复，如 1 Gbps 和 SATA 驱动器。
3.4. 添加或删除节点的建议
红帽建议在一个节点中逐一添加或删除一个 OSD，并在继续执行下一个 OSD 前恢复存储集群。这有助于最大程度降低对存储集群性能的影响。请注意，如果某个节点失败，您可能需要一次性更改整个节点，而不是一次更改一个 OSD。
移除 OSD：
添加 OSD：
在添加或删除 Ceph OSD 节点时，请考虑其他持续进程也会影响存储集群性能。要减少对客户端 I/O 的影响，红帽向您推荐以下几项：
计算容量
在移除 Ceph OSD 节点之前，请确保存储集群可以回填所有 OSD 的内容，而不会达到全满比率。达到 全满比率 将导致存储集群拒绝写操作。
临时禁用清理
清理是确保存储集群数据的持久性非常重要，但这是资源密集型。在添加或删除 Ceph OSD 节点之前，禁用清理和深度清理，并使当前清理操作在继续之前完成。
ceph osd_set_noscrub ceph osd_set_nodeep-scrub
在添加或删除 Ceph OSD 节点且存储集群返回 active+clean 状态后，取消设置 noscrub 和 nodeep-scrub 设置。
限制回填和恢复
如果您有合理的数据持久性，则处于 degraded 状态应该不会出现问题。例如，您可以使用 osd_pool_default_size = 3 和 osd_pool_default_min_size = 2 来运行存储集群。您可以调整存储集群以最快的恢复时间，但这样做会对 Ceph 客户端 I/O 性能造成重大影响。要保持最高的 Ceph 客户端 I/O 性能，请限制回填和恢复操作，并允许它们花费更长的时间。
osd_max_backfills = 1 osd_recovery_max_active = 1 osd_recovery_op_priority = 1
您还可以考虑设置 sleep 和 delay 参数，如 osd_recovery_sleep。
增加放置组数量
最后，如果您扩展存储集群的大小，可能需要增加放置组的数量。如果您确定需要扩展放置组数量，红帽建议在放置组数量中进行增量增长。通过显著数量增加放置组的数量会导致性能下降。
请参阅知识库文章如何在 Ceph 集群中增加放置组(PG)计数以了解更多详细信息。
3.5. 添加 Ceph OSD 节点
要扩展 Red Hat Ceph Storage 集群的容量，您可以添加 OSD 节点。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 具有网络连接的置备节点。
- 安装 Red Hat Enterprise Linux 8。
- 请参阅 Red Hat Ceph Storage 安装指南中的安装 Red Hat Ceph Storage 的要求。
流程
- 通过短主机名验证存储集群中的其他节点是否可以访问新节点。
临时禁用清理：
示例
[root@mon ~]# ceph osd set noscrub [root@mon ~]# ceph osd set nodeep-scrub
限制回填和恢复功能：
语法
ceph tell DAEMON_TYPE.* injectargs --OPTION_NAME VALUE [--OPTION_NAME VALUE]
示例
[root@mon ~]# ceph tell osd.* injectargs --osd-max-backfills 1 --osd-recovery-max-active 1 --osd-recovery-op-priority 1
将新节点添加到 CRUSH map：
语法
ceph osd crush add-bucket BUCKET_NAME BUCKET_TYPE
示例
[root@mon ~]# ceph osd crush add-bucket node2 host
为节点上的每个磁盘添加一个 OSD 到存储集群。
启用清理：
语法
ceph osd unset noscrub ceph osd unset nodeep-scrub
将回填和恢复功能设置为默认：
语法
ceph tell DAEMON_TYPE.* injectargs --OPTION_NAME VALUE [--OPTION_NAME VALUE]
示例
[root@mon ~]# ceph tell osd.* injectargs --osd-max-backfills 1 --osd-recovery-max-active 3 --osd-recovery-op-priority 3
其它资源
- 如需了解更多详细信息，请参阅 Red Hat Ceph Storage 配置指南中的 运行时 设置特定配置设置部分。
- 如需了解有关将节点放置到 CRUSH 层次结构中的相应位置的详细信息，请参阅 Red Hat Ceph Storage Storage 策略指南中的添加 Bucket 和 Moving a Bucket 部分。
3.6. 删除 Ceph OSD 节点
要减少存储集群的容量，请删除 OSD 节点。
在移除 Ceph OSD 节点之前，请确保存储集群可以回填所有 OSD 的内容，而无需达到全满比率。达到 全满比率 将导致存储集群拒绝写操作。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 对存储集群中所有节点的根级别访问权限。
流程
检查存储集群的容量：
语法
ceph df rados df ceph osd df
临时禁用清理：
语法
ceph osd set noscrub ceph osd set nodeep-scrub
限制回填和恢复功能：
语法
ceph tell DAEMON_TYPE.* injectargs --OPTION_NAME VALUE [--OPTION_NAME VALUE]
示例
[root@mon ~]# ceph tell osd.* injectargs --osd-max-backfills 1 --osd-recovery-max-active 1 --osd-recovery-op-priority 1
从存储集群中移除节点上的每个 OSD：
移除所有 OSD 后，从 CRUSH map 中删除主机 bucket：
语法
ceph osd crush rm BUCKET_NAME示例
[root@mon ~]# ceph osd crush rm node2
启用清理：
语法
ceph osd unset noscrub ceph osd unset nodeep-scrub
将回填和恢复功能设置为默认：
语法
ceph tell DAEMON_TYPE.* injectargs --OPTION_NAME VALUE [--OPTION_NAME VALUE]
示例
[root@mon ~]# ceph tell osd.* injectargs --osd-max-backfills 1 --osd-recovery-max-active 3 --osd-recovery-op-priority 3
其它资源
- 如需了解更多详细信息，请参阅 Red Hat Ceph Storage 配置指南中的 在运行时设置特定 配置设置部分。
3.7. 模拟节点失败
要模拟硬节点故障，请关闭该节点并重新安装操作系统。
先决条件
- 一个正常运行的 Red Hat Ceph Storage 集群。
- 对存储集群中所有节点的 root 级别访问。
流程
检查存储集群的容量，以了解删除节点的影响：
示例
[root@ceph1 ~]# ceph df [root@ceph1 ~]# rados df [root@ceph1 ~]# ceph osd df
（可选）禁用恢复和回填：
示例
[root@ceph1 ~]# ceph osd set noout [root@ceph1 ~]# ceph osd set noscrub [root@ceph1 ~]# ceph osd set nodeep-scrub
- 关闭节点。
如果要更改主机名，请从 CRUSH 映射中删除节点：
示例
[root@ceph1 ~]# ceph osd crush rm ceph3
检查存储集群的状态：
示例
[root@ceph1 ~]# ceph -s
- 在节点上重新安装操作系统。
添加 Ansible 用户并生成 SSH 密钥：
示例
[root@ceph3 ~]# useradd ansible [root@ceph3 ~]# passwd ansible [root@ceph3 ~]# cat << EOF > /etc/sudoers.d/ansible ansible ALL = (root) NOPASSWD:ALL Defaults:ansible !requiretty EOF [root@ceph3 ~]# su - ansible [ansible@ceph3 ~]$ ssh-keygen
在 Ansible 管理节点中，在重新安装的节点上复制
ansible用户的 SSH 密钥：[ansible@admin ~]$ ssh-copy-id ceph3
在 Ansible 管理节点中，再次运行 Ansible playbook：
示例
[ansible@admin ~]$ cd /usr/share/ceph-ansible [ansible@admin ~]$ ansible-playbook site.yml -i hosts PLAY RECAP ******************************************************************** ceph1 : ok=368 changed=2 unreachable=0 failed=0 ceph2 : ok=284 changed=0 unreachable=0 failed=0 ceph3 : ok=284 changed=15 unreachable=0 failed=0
（可选）启用恢复和回填：
示例
[root@ceph3 ~]# ceph osd unset noout [root@ceph3 ~]# ceph osd unset noscrub [root@ceph3 ~]# ceph osd unset nodeep-scrub
检查 Ceph 的健康状况：
示例
[root@ceph3 ~]# ceph -s cluster 1e0c9c34-901d-4b46-8001-0d1f93ca5f4d health HEALTH_OK monmap e1: 3 mons at {ceph1=192.168.122.81:6789/0,ceph2=192.168.122.82:6789/0,ceph3=192.168.122.83:6789/0} election epoch 36, quorum 0,1,2 ceph1,ceph2,ceph3 osdmap e95: 3 osds: 3 up, 3 in flags sortbitwise pgmap v1190: 152 pgs, 12 pools, 1024 MB data, 441 objects 3197 MB used, 293 GB / 296 GB avail 152 active+clean
其它资源
- Red Hat Ceph Storage 安装指南.
- 如需了解有关 Ansible 清单配置的更多详细信息，请参阅 {storage_product} 安装指南中的配置 Ansible 清单位置部分。
第 4 章 处理数据中心故障
作为存储管理员，您可以采取预防措施来避免数据中心故障。这些防止措施包括：
- 配置数据中心基础架构.
- 在 CRUSH map 层次结构中设置故障域。
- 在域中设计故障节点。
4.1. 先决条件
- 一个正常运行的 Red Hat Ceph Storage 集群。
- 对存储集群中所有节点的根级别访问权限。
4.2. 避免数据中心故障
配置数据中心基础架构
扩展集群中的每个数据中心都可以有不同的存储集群配置，以反映本地的功能和依赖项。设置数据中心之间的复制，以帮助保留数据。如果一个数据中心失败，则存储集群中的其他数据中心包含数据的副本。
在 CRUSH map 层次结构中设置故障域
故障或故障转移，域是存储集群中域的冗余副本。如果活动域失败，故障域将变为活动域。
默认情况下，CRUSH map 在扁平层次结构中列出存储群集中所有节点。但是，为获得最佳结果，在 CRUSH map 中创建一个逻辑层次结构。层次结构指定每个节点的域以及存储集群中这些域之间的关系，包括故障域。在层次结构中定义每个域的故障域可提高存储集群的可靠性。
当计划包含多个数据中心的存储集群时，将节点放置在 CRUSH map 层次结构中，以便在一个数据中心停机时，存储集群将保持启动并运行。
在域中设计故障节点
如果您计划在存储集群中使用三路复制数据，请考虑故障域中节点的位置。如果在数据中心内发生中断，某些数据可能只位于一个副本中。当发生这种情况时，有两个选项：
- 将数据保留为只读状态，并将数据保留为标准设置。
- 在停机期间只有一个副本。
使用标准设置，由于数据在节点间的数据放置的随机性，不是所有数据都会受到影响，一些数据只能有一个副本，而存储集群将恢复到只读模式。但是，如果一些数据只存在于一个副本中，则存储集群会恢复到只读模式。
4.3. 处理数据中心故障
Red Hat Ceph Storage 可能会对基础架构造成灾难性故障，例如在扩展集群中丢失一个数据中心。对于标准对象存储用例，可通过之间设置来独立配置所有三个数据中心。在这种情况下，每个数据中心的存储集群配置可能会有所不同，反映本地功能和依赖项。
应考虑放置层次结构的逻辑结构。可以使用适当的 CRUSH map，反映基础架构中故障域的层次结构。使用逻辑分级定义可提高存储集群的可靠性，而不是使用标准分级定义。故障域在 CRUSH 映射中定义。默认 CRUSH map 包含扁平层次结构中的所有节点。在三个数据中心环境中，如扩展集群，节点放置应以一个数据中心停机的方式进行管理，但存储集群可以保持启动并运行。在为数据使用三向复制时，请考虑节点位于哪个故障域中。
在以下示例中，生成的 map 源自存储集群的初始设置，包含 6 个 OSD 节点。在本例中，所有节点都只有一个磁盘，因此有一个 OSD。所有节点在默认 root 下排列，这是层次结构树的标准 root。由于分配给两个 OSD 的权重，这些 OSD 接收比其他 OSD 更少的数据区块。这些节点比初始 OSD 磁盘大于初始 OSD 磁盘而稍后引入。这不会影响到一组节点失败的数据放置。
示例
[root@mon ~]# ceph osd tree ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY -1 0.33554 root default -2 0.04779 host ceph-node3 0 0.04779 osd.0 up 1.00000 1.00000 -3 0.04779 host ceph-node2 1 0.04779 osd.1 up 1.00000 1.00000 -4 0.04779 host ceph-node1 2 0.04779 osd.2 up 1.00000 1.00000 -5 0.04779 host ceph-node4 3 0.04779 osd.3 up 1.00000 1.00000 -6 0.07219 host ceph-node6 4 0.07219 osd.4 up 0.79999 1.00000 -7 0.07219 host ceph-node5 5 0.07219 osd.5 up 0.79999 1.00000
使用逻辑分层定义将节点分组到同一数据中心可以达到数据放置成熟度。可能的定义类型 root, datacenter, rack, row 和 host 可以反映出三个数据中心扩展集群的故障域：
- 节点 ceph-node1 和 ceph-node2 驻留在数据中心 1 (DC1)中
- 节点 ceph-node3 和 ceph-node5 驻留在数据中心 2 (DC2)中。
- 节点 ceph-node4 和 ceph-node6 驻留在数据中心 3 (DC3)中。
- 所有数据中心都属于相同的结构(allDC)
由于主机中的所有 OSD 都属于主机定义，因此不需要更改。所有其他分配可在存储集群的运行时调整：
使用以下命令定义 bucket 结构：
ceph osd crush add-bucket allDC root ceph osd crush add-bucket DC1 datacenter ceph osd crush add-bucket DC2 datacenter ceph osd crush add-bucket DC3 datacenter
通过修改 CRUSH map，将节点移到此结构中的相应位置：
ceph osd crush move DC1 root=allDC ceph osd crush move DC2 root=allDC ceph osd crush move DC3 root=allDC ceph osd crush move ceph-node1 datacenter=DC1 ceph osd crush move ceph-node2 datacenter=DC1 ceph osd crush move ceph-node3 datacenter=DC2 ceph osd crush move ceph-node5 datacenter=DC2 ceph osd crush move ceph-node4 datacenter=DC3 ceph osd crush move ceph-node6 datacenter=DC3
在此结构中，也可以添加任何新主机，以及新磁盘。将 OSD 放置到层次结构中的正确位置，即 CRUSH 算法将冗余部分放入结构中的不同故障域中。
上面的示例会产生以下内容：
示例
[root@mon ~]# ceph osd tree ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY -8 6.00000 root allDC -9 2.00000 datacenter DC1 -4 1.00000 host ceph-node1 2 1.00000 osd.2 up 1.00000 1.00000 -3 1.00000 host ceph-node2 1 1.00000 osd.1 up 1.00000 1.00000 -10 2.00000 datacenter DC2 -2 1.00000 host ceph-node3 0 1.00000 osd.0 up 1.00000 1.00000 -7 1.00000 host ceph-node5 5 1.00000 osd.5 up 0.79999 1.00000 -11 2.00000 datacenter DC3 -6 1.00000 host ceph-node6 4 1.00000 osd.4 up 0.79999 1.00000 -5 1.00000 host ceph-node4 3 1.00000 osd.3 up 1.00000 1.00000 -1 0 root default
以上列表中通过显示 osd 树来显示生成的 CRUSH map。便于查看现在，主机属于数据中心和所有数据中心如何属于相同的顶级结构，但清晰区分位置。
根据映射将数据放在正确的位置，只在健康的集群中正常工作。当某些 OSD 不可用时，misplacement 可能会发生。这些错误替换会在可能这样做后自动更正。
其它资源
- 如需更多信息，请参阅 Red Hat Ceph Storage Storage 策略指南中的 CRUSH 管理一章。
第 5 章 将非容器化 Red Hat Ceph Storage 集群迁移到容器化环境中
要手动将非容器化、裸机、Red Hat Ceph Storage 集群迁移到容器化环境，请使用 ceph-ansible switch-from-non-containerized-to-containerized-ceph-daemons.yml playbook。
如果存储集群有一个不是由 ceph-ansible 部署的 RBD 镜像守护进程，则需要在转换为容器化集群前迁移守护进程。如需了解更多详细信息，请参阅 迁移 RBD 镜像守护进程。
先决条件
- 正在运行的红帽 Ceph 存储非容器化、裸机、集群。
- 访问 Ansible 管理节点.
- ansible 用户帐户。
- sudo 对 ansible 用户帐户的访问权限。
流程
编辑
group_vars/all.yml文件，使其包含容器的配置：ceph_docker_image_tag: "latest" ceph_docker_image: rhceph/rhceph-4-rhel8 containerized_deployment: true ceph_docker_registry: registry.redhat.io
重要对于
ceph_docker_image_tag，如果您的当前存储集群使用latest或使用适当的镜像标签，则使用 latest。有关更多信息，请参阅 Red Hat Ceph Storage 发行版本及相应的 Ceph 软件包版本是什么？进入
/usr/share/ceph-ansible目录：[ansible@admin ~]$ cd /usr/share/ceph-ansible
在 Ansible 管理节点上，运行 Ansible 迁移 playbook：
语法
ansible-playbook ./infrastructure-playbooks/switch-from-non-containerized-to-containerized-ceph-daemons.yml -i INVENTORY_FILE示例
[ansible@admin ceph-ansible]$ ansible-playbook ./infrastructure-playbooks/switch-from-non-containerized-to-containerized-ceph-daemons.yml -i hosts
验证集群是否切换到容器化环境。
在 monitor 节点上列出所有正在运行的容器：
Red Hat Enterprise Linux 7
[root@mon ~]$ sudo docker ps
Red Hat Enterprise Linux 8
[root@mon ~]$ sudo podman ps
其它资源
- 有关安装裸机存储 集群的信息，请参阅 Red Hat Ceph Storage 安装指南中的安装 Red Hat Ceph Storage 集群一章。
-
有关为 ansible 用户提供
sudo访问权限的信息，请参阅 Red Hat Ceph Storage 安装指南中的创建带有 sudo 访问权限的 Ansible 用户部分。 - 如需了解更多详细信息，请参阅 Red Hat Ceph Storage Block Device 指南中的使用命令行界面部分配置双向镜像功能。