操作指南

Red Hat Ceph Storage 4

Red Hat Ceph Storage 的操作任务

Red Hat Ceph Storage Documentation Team

摘要

本文档论述了如何为 Red Hat Ceph Storage 执行操作任务。
红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始：master、slave、黑名单和白名单。由于此项工作十分艰巨，这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 信息。

第 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 监控器来建立仲裁。

其它资源

1.2.1. 准备新的 Ceph 监控节点

在为部署准备新的 Ceph 监控节点前，请查看 Red Hat Ceph Storage 安装指南中的安装 Red Hat Ceph Storage 的要求。

重要

在单独的节点上部署每个新的 Ceph 监控器，存储集群中的所有 Ceph 监控节点必须在同一硬件上运行。

先决条件

  • 网络连接。
  • 对新节点的根级访问。

流程

  1. 将新节点添加到服务器机架。
  2. 将新节点连接到网络。

  3. 安装最新版本的 Red Hat Enterprise Linux 7 或 Red Hat Enterprise Linux 8。

    1. 对于 Red Hat Enterprise Linux 7，安装 ntp 并配置可靠的时间源： 

      [root@mon ~]# yum install ntp

    2. 对于 Red Hat Enterprise Linux 8，安装 chrony 并配置可靠的时间源： 

      [root@mon ~]# dnf install chrony

  4. 如果使用防火墙，打开 TCP 端口 6789： 

    [root@mon ~]# firewall-cmd --zone=public --add-port=6789/tcp
[root@mon ~]# firewall-cmd --zone=public --add-port=6789/tcp --permanent

其它资源

1.2.2. 使用 Ansible 添加 Ceph Monitor

红帽建议一次添加两个 Ceph monitor，以维护奇数个 monitor。例如，如果您在存储集群中有三个 Ceph monitor，红帽建议您将 monitor 数量扩展到 5。

先决条件

  • 对新节点的根级访问。
  • Ansible 管理节点.
  • 一个由 Ansible 部署的、正在运行的 Red Hat Ceph Storage 集群。

流程

  1. 将新的 Ceph Monitor 节点添加到 /etc/ansible/hosts Ansible 清单文件的 [mons] 部分下：

    示例

    [mons]
monitor01
monitor02
monitor03
NEW_MONITOR_NODE_NAME
NEW_MONITOR_NODE_NAME

  2. 验证 Ansible 是否可以联系 Ceph 节点： 

    [root@admin ~]# ansible all -m ping

  3. 将目录改为 Ansible 配置目录： 

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

  4. 您可以使用以下任一步骤添加 Ceph Monitor：

    • 对于裸机和容器部署 ，请运行 infrastructure-playbook ： 

      [root@admin ceph-ansible]# ansible-playbook -vvvv -i hosts infrastructure-playbooks/add-mon.yml

    • 以 ansible 用户身份，运行 site playbook 或 site-container playbook：

      • 裸机部署：

        示例

        [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 节点将出现在存储集群中。

  5. 更新配置文件：

    1. 裸机部署：

      示例

      [user@admin ceph-ansible]$ ansible-playbook -vvvv -i hosts site.yml --tags ceph_update_config

    2. 容器部署：

      示例

      [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 级别访问。

流程

  1. 添加 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

  2. 在新的 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

  3. 编辑存储集群中正在运行的节点上 Ceph 配置文件的 [mon] 部分中的 mon_host 设置列表。

    1. 将新 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 的监控器，还要向这两个部分添加新的监控器。

  4. 要使 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

  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

  6. 在新监控节点上创建 monitor 的数据目录：

    语法

    mkdir /var/lib/ceph/mon/CLUSTER_NAME - MONITOR_ID

    示例

    [root@mon ~]# mkdir /var/lib/ceph/mon/ceph-node4

  7. 在运行中的 Ceph 监控节点上和新建监控节点上创建临时目录，并将这个过程所需的文件保留在这些目录中。每个节点上的临时目录应该与节点的默认目录不同。可在所有步骤完成后删除：

    语法

    mkdir TEMP_DIRECTORY_PATH_NAME

    示例

    [root@mon ~]# mkdir /tmp/ceph

  8. 将 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

  9. 从正在运行的 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

  10. 从正在运行的 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

  11. 将收集的 Ceph Monitor 数据复制到新的 Ceph Monitor 节点：

    语法

    scp /tmp/ceph TARGET_NODE_NAME:/tmp/ceph

    示例

    [root@mon ~]# scp /tmp/ceph node4:/tmp/ceph

  12. 为您之前收集的数据准备数据目录。指定 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

  13. 对于具有自定义名称的存储集群，请在 /etc/sysconfig/ceph 文件中添加以下行：

    语法

    echo "CLUSTER=CUSTOM_CLUSTER_NAME" >> /etc/sysconfig/ceph

    示例

    [root@mon ~]# echo "CLUSTER=example" >> /etc/sysconfig/ceph

  14. 更新新监控节点上的所有者和组权限：

    语法

    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

  15. 在新监控节点上启用并启动 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

其它资源

1.2.4. 配置 monitor 选择策略

monitor 选择策略标识了网络分割并处理失败。您可以使用三种不同模式配置选择监控策略：

  1. classic - 默认默认，它是最低等级的监控，根据两个站点之间的选举模块进行投票。
  2. disallow - 此模式可让您将 monitor 标记为禁止，在这种情况下，他们会参与仲裁并服务客户端，但不能是选择的领导者。这样，您可以将 monitor 添加到禁止的领导列表中。如果 monitor 在 disallowed 列表中，它将始终被推迟到另一个 monitor。
  3. 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 集群。

流程

  1. 检查 monitor 是否为 ok-to-stop ：

    语法

    ceph mon ok-to-stop MONITOR_ID

    示例

    [root@mon ~]# ceph mon ok-to-stop node03

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

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

  3. 对于裸机和容器部署，请运行 shrink-mon.yml Ansible 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

  4. 从 ansible 清单主机 /etc/ansible/hosts 中手动删除对应的条目。

  5. 运行 ceph-ansible playbook。

    1. 裸机部署 ：

      示例

      [user@admin ceph-ansible]$ ansible-playbook site.yml --tags ceph_update_config -i hosts

    2. 容器部署 ：

      示例

      [user@admin ceph-ansible]$ ansible-playbook site-container.yml --tags ceph_update_config -i hosts

  6. 确保 Ceph Monitor 已被成功移除： 

    [root@mon ~]# ceph -s

其它资源

1.2.6. 使用命令行界面删除 Ceph Monitor

删除 Ceph Monitor 涉及从存储集群中移除 ceph-mon 守护进程并更新存储集群映射。

先决条件

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

流程

  1. 检查 monitor 是否为 ok-to-stop ：

    语法

    ceph mon ok-to-stop HOSTNAME

    示例

    [root@mon ~]# ceph mon ok-to-stop node03

  2. 停止 Ceph Monitor 服务：

    语法

    systemctl stop ceph-mon@MONITOR_ID

    示例

    [root@mon ~]# systemctl stop ceph-mon@node3

  3. 从存储集群中移除 Ceph Monitor：

    语法

    ceph mon remove MONITOR_ID

    示例

    [root@mon ~]# ceph mon remove node3

  4. 从 Ceph 配置文件移除 Ceph Monitor 条目。配置文件的默认位置为 /etc/ceph/ceph.conf。

  5. 将 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/

  6. 对于容器部署，禁用并删除 Ceph 监控服务：

    1. 禁用 Ceph Monitor 服务：

      语法

      systemctl disable ceph-mon@MONITOR_ID

      示例

      [root@mon ~]# systemctl disable ceph-mon@node3

    2. 从 systemd 中删除服务： 

      [root@mon ~]# rm /etc/systemd/system/ceph-mon@.service

    3. 重新加载 systemd 管理器配置： 

      [root@mon ~]# systemctl daemon-reload

    4. 重置故障 Ceph Monitor 节点的状态： 

      [root@mon ~]# systemctl reset-failed

  7. 可选：归档 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

  8. 可选：删除 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 节点。

流程

  1. 登录到一个 surviving Ceph Monitor 节点：

    语法

    ssh root@MONITOR_NODE_NAME

    示例

    [root@admin ~]# ssh root@mon2

  2. 停止 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

  3. 删除非可见的 Ceph 监控器：

    语法

    monmaptool TEMPORARY_PATH --rm _MONITOR_ID

    示例

    [root@mon2 ~]# monmaptool /tmp/monmap --rm mon1

  4. 将 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

  5. 仅启动 Surviving monitor，并验证 monitor 是否形成仲裁：

    示例

    [root@mon2 ~]# ceph -s

  6. 可选：归档在 /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 管理器守护进程的新或现有节点。

流程

  1. 登录 Ansible 管理节点。

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

    示例

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

  3. 以 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 守护进程的节点的主机名。

  4. 以 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 管理节点的管理员访问权限。

流程

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

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

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

  3. 对于裸机和容器部署，请运行 shrink-mgr.yml Ansible 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

  4. 作为 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

其它资源

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 节点置备的新的或现有服务器。

流程

  1. 登录 Ansible 管理节点

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

    示例

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

  3. 作为 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

  4. 以 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

其它资源

1.4.2. 使用命令行界面添加 Ceph MDS

您可以使用命令行界面手动添加 Ceph 元数据服务器(MDS)。

先决条件

  • 已安装 ceph-common 软件包。
  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 对 MDS 节点的 root 或 sudo 访问权限。
  • 可以作为 MDS 节点置备的新的或现有服务器。

流程

  1. 通过登录到节点并创建 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

  2. 如果这是新的 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 身份验证链接。

  3. 启动 MDS 守护进程：

    语法

    sudo systemctl start ceph-mds@HOST_NAME

    将 HOST_NAME 替换为要启动守护进程的主机的短名称。

    示例

    [admin@node03 ~]$ sudo systemctl start ceph-mds@node03

  4. 启用 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

其它资源

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 访问权限。

流程

  1. 登录 Ansible 管理节点。

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

    示例

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

  3. 运行 Ansible shrink-mds.yml playbook，在提示时输入 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

  4. 作为 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]]

其它资源

1.4.4. 使用命令行界面删除 Ceph MDS

您可以使用命令行界面手动删除 Ceph 元数据服务器(MDS)。

注意

如果在当前 MDS 被删除后没有替代的 MDS 进行接管，客户端无法使用文件系统。如果这不必要，请考虑在删除现有 MDS 前添加 MDS。

先决条件

  • 已安装 ceph-common 软件包。
  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 对 MDS 节点的 root 或 sudo 访问权限。

流程

  1. 登录到您要从中删除 MDS 守护进程的 Ceph MDS 节点。

  2. 停止 Ceph MDS 服务：

    语法

    sudo systemctl stop ceph-mds@HOST_NAME

    将 HOST_NAME 替换为守护进程运行的主机的短名称。

    示例

    [admin@node02 ~]$ sudo systemctl stop ceph-mds@node02

  3. 如果没有将 MDS 重新部署到这个节点，则禁用 MDS 服务：

    语法

    sudo systemctl disable ceph-mds@HOST_NAME

    将 HOST_NAME 替换为要禁用该守护进程的主机的短名称。

    示例

    [admin@node02 ~]$ sudo systemctl disable ceph-mds@node02

  4. 删除 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]]

其它资源

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 的要求章节。

其它资源

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 访问权限。

流程

  1. 查找容器名称。例如，要识别与 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

  2. 使用 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 关联。

其它资源

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 数据驱动器数量。

流程

  1. 将 Ceph OSD 节点添加到 /etc/ansible/hosts 文件的 [osds] 部分下：

    语法

    [osds]
...
osd06
NEW_OSD_NODE_NAME

  2. 验证 Ansible 能否访问 Ceph 节点： 

    [user@admin ~]$ ansible all -m ping

  3. 进入 Ansible 配置目录： 

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

  4. 对于裸机和容器部署，请运行 add-osd.yml Ansible playbook：

    注意

    对于新的 OSD 主机，您需要使用 --limit 选项运行 site.yml 或 site-container.yml playbook，并且 ceph-crash 服务没有部署到使用 osds.yml playbook 的节点上。

    示例

    [user@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/add-osd.yml -i hosts

    对于新的 OSD 主机，请运行 site.yml 或 site-container.yml Ansible 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 访问权限。

流程

  1. 第一种方法

    1. 在 [osds] 部分下，添加新的 Ceph OSD 节点到 /etc/ansible/hosts 文件：

      示例

      [osds]
...
osd06
NEW_OSD_NODE_NAME

    2. 在 /etc/ansible/host_vars/ 目录下，为每个添加到存储集群的每个新 Ceph OSD 节点创建一个新文件：

      语法

      touch /etc/ansible/host_vars/NEW_OSD_NODE_NAME

      示例

      [root@admin ~]# touch /etc/ansible/host_vars/osd07

    3. 编辑新文件，并将 devices: 和 dedicated_devices: 部分添加到该文件中。在每个部分下，添加一个 -、空格，然后添加到这个 OSD 节点的块设备名称的完整路径：

      示例

      devices:
  - /dev/sdc
  - /dev/sdd
  - /dev/sde
  - /dev/sdf

dedicated_devices:
  - /dev/sda
  - /dev/sda
  - /dev/sdb
  - /dev/sdb

    4. 验证 Ansible 是否可以访问所有 Ceph 节点： 

      [user@admin ~]$ ansible all -m ping

    5. 将目录改为 Ansible 配置目录： 

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

    6. 对于裸机和容器部署，请运行 add-osd.yml Ansible playbook：

      注意

      对于新的 OSD 主机，您需要使用 --limit 选项运行 site.yml 或 site-container.yml playbook，并且 ceph-crash 服务没有部署到使用 osds.yml playbook 的节点上。

      示例

      [user@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/add-osd.yml -i hosts

      对于新的 OSD 主机，请运行 site.yml 或 site-container.yml Ansible 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

  2. 第二种方法

    1. 将新 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']"

    2. 验证 Ansible 能否访问所有 Ceph 节点： 

      [user@admin ~]$ ansible all -m ping

    3. 将目录改为 Ansible 配置目录： 

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

  3. 对于裸机和容器部署，请运行 add-osd.yml Ansible playbook：

    注意

    对于新的 OSD 主机，您需要使用 --limit 选项运行 site.yml 或 site-container.yml playbook，并且 ceph-crash 服务没有部署到使用 osds.yml playbook 的节点上。

    示例

    [user@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/add-osd.yml -i hosts

    对于新的 OSD 主机，请运行 site.yml 或 site-container.yml Ansible 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。

流程

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

    语法

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

    示例

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

其它资源

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 级别访问权限。

流程

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

    语法

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

    示例

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

其它资源

1.5.7. 使用命令行界面添加 Ceph OSD

以下是手动将 OSD 添加到 Red Hat Ceph Storage 的高级别工作流：

  1. 安装 ceph-osd 软件包并创建新的 OSD 实例。
  2. 准备并挂载 OSD 数据和日志驱动器。
  3. 创建卷组和逻辑卷。
  4. 添加新 OSD 节点到 CRUSH map。
  5. 更新所有者和组权限。
  6. 启用并启动 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 配置和管理逻辑卷指南。

流程

  1. 启用 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

  2. 创建 /etc/ceph/ 目录： 

    [root@osd ~]# mkdir /etc/ceph

  3. 在新 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/

  4. 在新的 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

  5. 准备 OSD。

    • 使用之前创建的逻辑卷：

      语法

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

    • 为 ceph-volume 指定原始设备以自动创建逻辑卷：

      语法

      ceph-volume lvm prepare --bluestore --data /PATH_TO_DEVICE

      如需了解更多详细信息，请参阅准备 OSD 部分。

  6. 设置 noup 选项： 

    [root@osd ~]# ceph osd set noup

  7. 激活新 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 模式。

  8. 将 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 内。

  9. 取消设置 noup 选项： 

    [root@osd ~]# ceph osd unset noup

  10. 为新创建的目录更新所有者和组权限：

    语法

    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

  11. 如果您使用带有自定义名称的存储集群，请在适当的文件中添加以下行： 

    [root@osd ~]# echo "CLUSTER=CLUSTER_NAME" >> /etc/sysconfig/ceph

    将 CLUSTER_NAME 替换为自定义存储集群名称。

  12. 为确保新 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

其它资源

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 来执行给定的命令。

流程

  1. 要创建单个 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 逻辑卷或分区的路径。

  2. 要创建多个 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 管理节点。

流程

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

    语法

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

  2. 将 Ceph 监控节点上的 /etc/ceph/ 中的 admin keyring 复制到包含您要删除的 OSD 的节点。

  3. 为 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

  4. 验证 OSD 是否已成功移除：

    语法

    [root@mon ~]# ceph osd tree

其它资源

1.5.10. 使用命令行界面删除 Ceph OSD

从存储集群中移除 OSD 涉及这些步骤：* 更新 cluster map。* 删除其验证密钥。* 从 OSD map 移除 OSD。* 从 ceph.conf 文件中删除 OSD。

如果 OSD 节点有多个驱动器，您可能需要为您要删除的每个 OSD 重复此步骤来为每个驱动器移除 OSD。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 有足够的 OSD，使得存储集群不达到接近全满比率。
  • 对 OSD 节点的 root 级别访问。

流程

  1. 禁用和停止 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 停止后，它会 关闭。

  2. 从存储集群中移除 OSD：

    语法

    ceph osd out OSD_ID

    示例

    [root@osd ~]# ceph osd out 4

    重要

    删除 OSD 后，Ceph 会开始重新平衡数据，并将数据复制到存储集群中剩余的 OSD。红帽建议等待存储集群变为 active+clean，然后再继续下一步。要观察数据迁移，请运行以下命令：

    语法

    [root@mon ~]# ceph -w

  3. 从 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 的说明。

  4. 移除 OSD 身份验证密钥：

    语法

    ceph auth del osd.OSD_ID

    示例

    [root@osd ~]# ceph auth del osd.4

  5. 删除 OSD：

    语法

    ceph osd rm OSD_ID

    示例

    [root@osd ~]# ceph osd rm 4

  6. 编辑存储集群的配置文件。文件的默认名称为 /etc/ceph/ceph.conf。如果存在，请删除文件中的 OSD 条目：

    示例

    [osd.4]
host = _HOST_NAME_

  7. 如果手动添加了 OSD，删除对 /etc/fstab 文件中的 OSD 的引用。

  8. 将更新后的配置文件复制到存储集群中所有节点的 /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 集群。
  • 带分区的存储设备。
  • 所有节点的根级别访问权限。

流程

  1. 检查 monitor 节点上的当前 Ceph 集群状态： 

    [root@mon ~]# ceph status
[root@mon ~]# ceph df

  2. 识别要替换的 OSD 失败： 

    [root@mon ~]# ceph osd tree | grep -i down

  3. 在 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

  4. 在监控节点上设置 OSD out：

    语法

    ceph osd out OSD_ID

    示例

    [root@mon ~]# ceph osd out 1

  5. 等待数据从 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

  6. 停止 OSD 节点上的 OSD 守护进程：

    语法

    systemctl kill ceph-osd@OSD_ID

    示例

    [root@osd1 ~]# systemctl kill ceph-osd@1

  7. 记录此 OSD 使用的设备：

    语法

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

    示例

    [root@osd1 ~]# mount | grep /var/lib/ceph/osd/ceph-1

  8. 卸载 OSD 节点上的故障驱动器路径的挂载点：

    语法

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

    示例

    [root@osd1 ~] #umount /var/lib/ceph/osd/ceph-1

  9. 设置 noout 和 norebalance 以避免回填和重新平衡： 

    [root@mon ~]# ceph osd set noout
[root@mon ~]# ceph osd set norebalance
  10. 替换物理驱动器。请参阅硬件厂商的文档。在继续操作前，等待新驱动器出现在 /dev/ 目录下，并记录下驱动器路径。

  11. 销毁 monitor 节点上的 OSD：

    语法

    ceph osd destroy OSD_ID --yes-i-really-mean-it

    示例

    [root@mon ~]# ceph osd destroy 1 --yes-i-really-mean-it

    重要

    此步骤会破坏设备的内容。确保不需要该设备中的数据，且集群处于健康状态。

  12. 删除 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

  13. 在 OSD 节点上 zap OSD 磁盘：

    语法

    ceph-volume lvm zap DEVICE

    示例

    [root@osd1 ~]# ceph-volume lvm zap /dev/sdb

  14. 在 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

  15. 在新的 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 ~]# vgcreate db-vg1 /dev/sdb
[root@osd1 ~]# lvcreate -l 100%FREE -n lv-db1 db-vg1

  16. 在 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。

  17. 在 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

  18. 检查 CRUSH 层次结构以确保 OSD 在集群中： 

    [root@mon ~]# ceph osd tree

  19. 取消设置 noout 和 norebalance： 

    [root@mon ~]# ceph osd unset noout
[root@mon ~]# ceph osd unset norebalance

  20. 监控集群状态，直到 HEALTH_OK 为止： 

    [root@mon ~]# watch -n2 ceph -s

其它资源

1.5.12. 观察数据迁移

将 OSD 添加到 CRUSH map 时，Ceph 开始通过将放置组迁移到新的或现有的 OSD 来重新平衡数据。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 最近添加或删除 OSD。

流程

  1. 观察数据迁移： 

    [root@monitor ~]# ceph -w
  2. 在迁移完成后，观察放置组状态从 active+clean 变为 active, some degraded objects，最终变为 active+clean。
  3. 要退出，请按 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 队列和高延迟渲染存储集群不可用，或者会导致长时间修复时间。

其它资源

  • 请参阅 PG 计算器，以计算给定用例的值。
  • 如需更多信息，请参阅 Red Hat Ceph Storage 策略指南中的 纠删代码池 一章。

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 集群。

流程

  1. 确保 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"
    ],

    1. 如果 balancer 模块没有列在 always_on 或 enabled 模块中，则启用它：

      语法

      ceph mgr module enable balancer

  2. 打开 balancer 模块： 

    [root@mon ~]# ceph balancer on

  3. 默认模式为 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 操作分为几个不同的阶段：

  1. 构建 计划。
  2. 评估数据分发的质量，针对当前的 PG 分发，或在执行一个计划（plan）后生成的 PG 分发。

  3. 执行计划。

    • 评估和分数当前发行版： 

      [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。

先决条件

  • 正在运行的红帽存储集群。
  • 对存储集群中所有节点的根级别访问权限。

流程

  1. 确保 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"
    ],

    1. 如果 balancer 模块没有列在 always_on 或 enabled 模块中，则启用它：

      语法

      ceph mgr module enable balancer

  2. 将负载均衡器模式设置为 upmap ：

    语法

    ceph balancer mode upmap

  3. 关闭 balancer 模块：

    语法

    ceph balancer off

  4. 检查负载均衡器状态：

    示例

    [root@mon ~]# ceph balancer status
{
    "plans": [],
    "active": false,
    "last_optimize_started": "",
    "last_optimize_duration": "",
    "optimize_result": "",
    "mode": "upmap"
}

  5. 为 OSD 设置 norebalance 标志：

    语法

    ceph osd set norebalance

  6. 使用 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

  7. 将 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。

  8. 再次使用 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。

  9. 取消设置 norebalance 标志：

    语法

    ceph osd unset norebalance

  10. 重新打开 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 监控节点的根级别访问权限.

流程

  1. 启用警报模块：

    示例

    [root@host01 ~]# ceph mgr module enable alerts

  2. 确保启用了 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"
    ]

  3. 配置简单邮件传输协议(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

  4. 可选： 默认情况下，警报模块使用 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

  5. 对 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

  6. 可选：默认情况下，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'

  7. 可选：默认情况下，警报模块会每分钟检查存储集群的健康状况，并在集群健康状况有变化时发送消息。要更改频率，请设置 interval 参数：

    语法

    ceph config set mgr mgr/alerts/interval INTERVAL

    示例

    [root@host01 ~]# ceph config set mgr mgr/alerts/interval "5m"

    在本例中，间隔设置为 5 分钟。

  8. 可选：立即发送警报：

    示例

    [root@host01 ~]# ceph alerts send

其它资源

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 集群。

流程

  1. 确定启用了 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"
    ]

  2. 保存崩溃转储：元数据文件是存储在 crash dir 中作为 meta 的 JSON blob。您可以调用 ceph 命令 -i - 选项，该选项会从 stdin 读取。

    示例

    [root@mon ~]# ceph crash post -i meta

  3. 列出所有新的以及归档的崩溃信息的时间戳或 UUID 崩溃 ID：

    示例

    [root@mon ~]# ceph crash ls

  4. 列出所有崩溃信息的时间戳或 UUID 崩溃 ID：

    示例

    [root@mon ~]# ceph crash ls-new

  5. 列出所有崩溃信息的时间戳或 UUID 崩溃 ID：

    示例

    [root@mon ~]# ceph crash ls-new

  6. 列出按年龄分组的崩溃信息概述：

    示例

    [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

  7. 查看保存崩溃的详情：

    语法

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

  8. 删除比 KEEP days 旧的已保存的崩溃：其中 KEEP 必须是一个整数。

    语法

    ceph crash prune KEEP

    示例

    [root@mon ~]# ceph crash prune 60

  9. 对崩溃报告进行归档，使其不再被视为 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

  10. 记录所有崩溃报告：

    示例

    [root@mon ~]# ceph crash archive-all

  11. 删除崩溃转储：

    语法

    ceph crash rm CRASH_ID

    示例

    [root@mon ~]# ceph crash rm 2021-05-24T19:58:42.549073Z_b2382865-ea89-4be2-b46f-9a59af7b7a2d

其它资源

1.11. 迁移 RBD 镜像守护进程

对于使用裸机存储集群中命令行界面配置的双向块设备(RBD)镜像，集群不会迁移 RBD 镜像。在升级存储集群或将集群转换为容器化之前，将 RBD 镜像守护进程从 CLI 迁移到 Ceph-Ansible。

先决条件

  • 正在运行的红帽 Ceph 存储非容器化、裸机、集群。
  • 访问 Ansible 管理节点.
  • ansible 用户帐户。
  • sudo 对 ansible 用户帐户的访问权限。

流程

  1. 在 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

  2. 更改 /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 *"

  3. 导入 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

  4. 检查 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

  5. 将 rbd-mirror 节点添加到 /etc/ansible/hosts 文件中：

    示例

    [rbdmirrors]
ceph.client.rbd-mirror.rbd-client-site-a

1.12. 其它资源

第 2 章 处理磁盘失败

作为存储管理员，在存储集群的整个生命周期内，您必须处理磁盘故障。在发生实际故障前测试并模拟磁盘出现故障的情况，确保在故障实际发生时已做好准备。

以下是替换失败磁盘的高级别工作流：

  1. 查找失败的 OSD。
  2. 将 OSD 出去。
  3. 在节点上停止 OSD 守护进程。
  4. 检查 Ceph 的状态。
  5. 从 CRUSH map 移除 OSD。
  6. 删除 OSD 授权。
  7. 从存储集群移除 OSD。
  8. 卸载节点上的文件系统。
  9. 替换失败的驱动器。
  10. 将 OSD 后端添加到存储集群。
  11. 检查 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 级别访问权限。

流程

  1. 从 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

  2. 查看 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 集群。
  • 一个失败的磁盘。

流程

  1. 检查存储集群健康状况： 

    [root@mon ~]# ceph health

  2. 识别 CRUSH 层次结构中的 OSD 位置： 

    [root@mon ~]# ceph osd tree | grep -i down

  3. 在 OSD 节点上，尝试启动 OSD：

    语法

    systemctl start ceph-osd@OSD_ID

    如果命令显示 OSD 已在运行，则可能存在心跳或网络问题。如果您无法重启 OSD，则驱动器可能会失败。

    注意

    如果 OSD 为 down，则 OSD 最终将被标记为 out。这是 Ceph 存储的正常行为。当 OSD 标记为 out 时，具有故障 OSD 数据副本的其他 OSD 将开始回填，以确保存储集群中存在所需的副本数。当存储集群进行回填时，集群会 处于降级状态。

  4. 对于 Ceph 的容器化部署，请尝试使用 OSD_ID 启动 OSD 容器：

    语法

    systemctl start ceph-osd@OSD_ID

    如果命令显示 OSD 已在运行，则可能存在心跳或网络问题。如果您无法重启 OSD，则驱动器可能会失败。

    注意

    与 OSD 关联的驱动器可以通过将容器 OSD ID 映射到驱动器来确定。

  5. 检查失败的 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

    如果驱动器失败，则需要替换它。

  6. 停止 OSD 进程：

    语法

    systemctl stop ceph-osd@OSD_ID

  7. 对于 Ceph 的容器化部署，请停止 OSD 容器：

    语法

    systemctl stop ceph-osd@OSD_ID

  8. 从存储集群中移除 OSD：

    语法

    ceph osd out OSD_ID

  9. 确保失败的 OSD 正在回填： 

    [root@osd ~]# ceph -w

  10. 从 CRUSH map 移除 OSD：

    语法

    ceph osd crush remove osd.OSD_ID

    注意

    只有在您永久删除 OSD 且没有重新部署时，才需要执行此步骤。

  11. 删除 OSD 的身份验证密钥：

    语法

    ceph auth del osd.OSD_ID

  12. 验证 OSD 的密钥没有被列出：

    示例

    [root@osd ~]# ceph auth list

  13. 从存储集群中移除 OSD：

    语法

    ceph osd rm osd.OSD_ID

  14. 卸载失败的驱动器路径：

    语法

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

    示例

    [root@osd ~]# umount /var/lib/ceph/osd/ceph-0

    注意

    对于 Ceph 容器化部署，如果 OSD 关闭容器，则将卸载 OSD 驱动器。在这种情况下，没有卸载，并可以跳过此步骤。

  15. 替换物理驱动器。请参阅硬件厂商的文档。如果驱动器是热交换的，只需将故障驱动器替换为新驱动器。如果驱动器不热交换，且节点包含多个 OSD，则 MIGHT 需要关闭节点来取代物理驱动器。如果需要临时关闭节点，您可以将集群设置为 noout 以防止回填：

    示例

    [root@osd ~]# ceph osd set noout

    替换驱动器后，您使节点及其 OSD 重新在线，删除 noout 设置：

    示例

    [root@osd ~]# ceph osd unset noout

    在继续操作前，等待新驱动器出现在 /dev/ 目录下，并记录下驱动器路径。

  16. 查找 OSD 驱动器并格式化磁盘。

  17. 重新创建 OSD：

    1. 使用 Ceph Ansible.
    2. 使用命令行界面。

  18. 检查 CRUSH 层次结构以确保其准确：

    示例

    [root@osd ~]# ceph osd tree

    如果您对 OSD 在 CRUSH 层次结构中的位置不满意，您可以使用 move 命令移动它：

    语法

    ceph osd crush move BUCKET_TO_MOVE BUCKET_TYPE=PARENT_BUCKET

  19. 验证 OSD 是否在线。

2.5. 在保留 OSD ID 时替换 OSD 驱动器

在替换失败的 OSD 驱动器时，您可以保留原始 OSD ID 和 CRUSH map 条目。

注意

ceph-volume lvm 命令默认为 OSD 的 BlueStore。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 一个失败的磁盘。

流程

  1. 销毁 OSD：

    语法

    ceph osd destroy OSD_ID --yes-i-really-mean-it

    示例

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

  2. 另外，如果之前使用替换磁盘，则需要 zap 磁盘：

    语法

    ceph-volume lvm zap DEVICE

    示例

    [root@osd ~]# ceph-volume lvm zap /dev/sdb

    注意

    您可以通过比较各种命令的输出（如 ceph osd tree、ceph osd metadata 和 df ）来查找 DEVICE。

  3. 使用现有 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

其它资源

第 3 章 处理节点失败

作为存储管理员，您可以在存储集群中遇到整个节点故障，处理节点故障与处理磁盘故障类似。当节点出现故障时，Ceph 仅为一个磁盘恢复放置组(PG)，则该节点内磁盘上的所有 PG 必须被恢复。Ceph 将检测 OSD 是否都停止，并且自动启动恢复过程，称为自我修复。

有三个节点故障场景。以下是替换节点时每个情境的高级工作流：

  • 替换节点，但使用故障节点的 root 和 Ceph OSD 磁盘。

    1. 禁用回填。
    2. 替换节点，从旧节点获取磁盘，并将它们添加到新节点。
    3. 启用回填。

  • 替换节点，重新安装操作系统，并使用来自故障节点的 Ceph OSD 磁盘。

    1. 禁用回填。
    2. 创建 Ceph 配置的备份。

    3. 替换节点，再添加来自故障节点的 Ceph OSD 磁盘。

      1. 将磁盘配置为 JBOD.
    4. 安装操作系统。
    5. 恢复 Ceph 配置。
    6. 运行 ceph-ansible。
    7. 启用回填。

  • 替换节点、重新安装操作系统和使用所有新的 Ceph OSD 磁盘。

    1. 禁用回填。
    2. 从存储集群中移除故障节点上的所有 OSD。
    3. 创建 Ceph 配置的备份。

    4. 替换节点，再添加来自故障节点的 Ceph OSD 磁盘。

      1. 将磁盘配置为 JBOD.
    5. 安装操作系统。
    6. 运行 ceph-ansible。
    7. 启用回填。

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 的要求。

流程

  1. 通过短主机名验证存储集群中的其他节点是否可以访问新节点。

  2. 临时禁用清理：

    示例

    [root@mon ~]# ceph osd set noscrub
[root@mon ~]# ceph osd set nodeep-scrub

  3. 限制回填和恢复功能：

    语法

    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

  4. 将新节点添加到 CRUSH map：

    语法

    ceph osd crush add-bucket BUCKET_NAME BUCKET_TYPE

    示例

    [root@mon ~]# ceph osd crush add-bucket node2 host

  5. 为节点上的每个磁盘添加一个 OSD 到存储集群。

    • 使用 Ansible.

    • 使用命令行界面。

      重要

      将 OSD 节点添加到 Red Hat Ceph Storage 集群时，红帽建议在该节点中一次添加一个 OSD，并允许集群在继续进入下一个 OSD 前恢复到 active+clean 状态。

  6. 启用清理：

    语法

    ceph osd unset noscrub
ceph osd unset nodeep-scrub

  7. 将回填和恢复功能设置为默认：

    语法

    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 集群。
  • 对存储集群中所有节点的根级别访问权限。

流程

  1. 检查存储集群的容量：

    语法

    ceph df
rados df
ceph osd df

  2. 临时禁用清理：

    语法

    ceph osd set noscrub
ceph osd set nodeep-scrub

  3. 限制回填和恢复功能：

    语法

    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

  4. 从存储集群中移除节点上的每个 OSD：

    • 使用 Ansible。

    • 使用命令行界面。

      重要

      从存储集群中移除 OSD 节点时，红帽建议在节点中一次删除一个 OSD，并允许集群恢复到 active+clean 状态，然后继续移除下一个 OSD。

      1. 移除 OSD 后，检查以验证存储集群是否没有达到 near-full 比率 ：

        语法

        ceph -s
ceph df

      2. 重复此步骤，直到将节点上的所有 OSD 从存储集群中移除。

  5. 移除所有 OSD 后，从 CRUSH map 中删除主机 bucket：

    语法

    ceph osd crush rm BUCKET_NAME

    示例

    [root@mon ~]# ceph osd crush rm node2

  6. 启用清理：

    语法

    ceph osd unset noscrub
ceph osd unset nodeep-scrub

  7. 将回填和恢复功能设置为默认：

    语法

    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 级别访问。

流程

  1. 检查存储集群的容量，以了解删除节点的影响：

    示例

    [root@ceph1 ~]# ceph df
[root@ceph1 ~]# rados df
[root@ceph1 ~]# ceph osd df

  2. （可选）禁用恢复和回填：

    示例

    [root@ceph1 ~]# ceph osd set noout
[root@ceph1 ~]# ceph osd set noscrub
[root@ceph1 ~]# ceph osd set nodeep-scrub

  3. 关闭节点。

  4. 如果要更改主机名，请从 CRUSH 映射中删除节点：

    示例

    [root@ceph1 ~]# ceph osd crush rm ceph3

  5. 检查存储集群的状态：

    示例

    [root@ceph1 ~]# ceph -s

  6. 在节点上重新安装操作系统。

  7. 添加 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

  8. 在 Ansible 管理节点中，在重新安装的节点上复制 ansible 用户的 SSH 密钥： 

    [ansible@admin ~]$ ssh-copy-id ceph3

  9. 在 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

  10. （可选）启用恢复和回填：

    示例

    [root@ceph3 ~]# ceph osd unset noout
[root@ceph3 ~]# ceph osd unset noscrub
[root@ceph3 ~]# ceph osd unset nodeep-scrub

  11. 检查 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

其它资源

第 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 用户帐户的访问权限。

流程

  1. 编辑 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 软件包版本是什么？

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

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

  3. 在 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

    验证集群是否切换到容器化环境。

  4. 在 monitor 节点上列出所有正在运行的容器：

    Red Hat Enterprise Linux 7

    [root@mon ~]$ sudo docker ps

    Red Hat Enterprise Linux 8

    [root@mon ~]$ sudo podman ps

其它资源

法律通告

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.