故障排除指南

Red Hat Ceph Storage 4

Red Hat Ceph Storage 故障排除

Red Hat Ceph Storage Documentation Team

摘要

本文档描述了如何使用 Red Hat Ceph Storage 解决常见问题。
红帽承诺替换我们的代码、文档和网页属性中存在问题的语言。我们从这四个术语开始: master、slave、blacklist 和 whitelist。这些更改将在即将发行的几个发行本中逐渐实施。详情请查看 CTO Chris Wright 信息

第 1 章 初始故障排除

本章包含以下内容的信息:

1.1. 先决条件

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

1.2. 识别问题

要确定 Red Hat Ceph Storage 集群的错误可能的原因,请回答流程部分中的问题。

先决条件

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

流程

  1. 使用不受支持的配置时可能会产生某些问题。确保您的配置被支持。
  2. 您知道哪个 Ceph 组件导致了此问题吗?

    1. 否。红帽 Ceph 存储故障排除指南中诊断 Ceph 存储群集流程的运行状况
    2. Ceph 监控器.请参阅《 红帽 Ceph 存储故障排除指南》中的 Ceph monitor 故障排除 章节。
    3. Ceph OSD.请参阅《 红帽 Ceph 存储故障排除指南》中的 Ceph OSD 故障排除 章节。
    4. Ceph 放置组.请参阅《 红帽 Ceph 存储故障排除指南》中的 Ceph 放置组 故障排除 章节。
    5. 多站点 Ceph 对象网关.请参阅《 红帽 Ceph 存储故障排除指南》中的对多站点 Ceph对象网关 进行故障排除章节。

其它资源

1.2.1. 诊断存储集群的健康状况

此流程列出了诊断 Red Hat Ceph Storage 集群健康状况的基本步骤。

先决条件

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

流程

  1. 检查存储集群的整体状态:

    [root@mon ~]# ceph health detail

    如果命令返回 HEALTH_WARN 或 HEALTH_ERR,请参见 了解 Ceph 健康状况 以了解详细信息。

  2. 检查 Ceph 日志中是否存在 Understanding Ceph 日志 中列出的任何错误消息。日志默认位于 /var/log/ceph/ 目录中。
  3. 如果日志没有包含足够数量的信息,提高调试级别并尝试重现失败的操作。详情请参阅 配置日志

1.3. 了解 Ceph 健康

ceph health 命令返回有关 Red Hat Ceph Storage 集群状态的信息:

  • HEALTH_OK 表示集群处于健康状态。
  • HEALTH_WARN 表示警告。在某些情况下,Ceph 状态会自动返回到 HEALTH_OK。例如,当红帽 Ceph 存储集群完成重新平衡过程时。但是,如果集群处于 HEALTH_WARN 状态,请考虑进一步故障排除。
  • HEALTH_ERR 表示需要您立即关注的更严重的问题。

使用 ceph 运行状况详细信息ceph -s 命令获取更详细的输出。

其它资源

1.4. 了解 Ceph 日志

1.4.1. 非容器化部署

默认情况下,Ceph 将其日志存储在 /var/log/ceph/ 目录中。

The CLUSTER_NAME.log 是包含全局事件的主存储集群日志文件。默认情况下,日志文件名称为 ceph.log。只有 Ceph 监控节点包含主要的存储集群日志。

每个 Ceph OSD 和 monitor 具有自己的日志文件,名为 CLUSTER_NAME-osd。NUMBER. logCLUSTER_NAME-mon.HOSTNAME.log.

当您提高 Ceph 子系统的调试级别时,Ceph 也为这些子系统生成新的日志文件。

1.4.2. 基于容器的部署

对于基于容器的部署,默认情况下,Ceph 日志指向 journald,可使用 journactl 命令访问。但是,您可以将 Ceph 配置为记录到配置设置中的 /var/log/ceph 中的文件。

  1. 要启用日志记录 Ceph Monitor、Ceph Manager、Ceph 对象网关和任何其他守护进程,请在 [global] 设置下将 log_to_file 设置为 true

    示例

    [ceph: root@host01 ~]# ceph config set global log_to_file true

  2. 要为 Ceph 监控集群和审计日志启用日志记录,请将 mon_cluster_log_to_file 设置为 true

    示例

    [ceph: root@host01 ~]# ceph config set mon mon_cluster_log_to_file true

注意

如果您选择登录到文件,则建议禁用日志记录到 journald,否则一切都会记录两次。运行以下命令禁用 journald 的日志记录:

# ceph config set global log_to_journald false
# ceph config set global mon_cluster_log_to_journald false

其它资源

1.5. 使用 Ansible 从 Ceph 集群中的多个主机收集日志

从 Red Hat Ceph Storage 4.2 开始,您可以使用 ceph-ansible 从 Ceph 集群中的多个主机收集日志。它从 Ceph 节点捕获 etc/ceph/var/log/ceph 目录。此 playbook 可用于收集裸机和容器化存储集群的日志。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 对节点的根级别访问权限。
  • ceph-ansible 软件包安装在节点上。

流程

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

    注意

    确保节点有足够的空间从主机收集日志。

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

    示例

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

  3. 运行 Ansible playbook 以收集日志:

    示例

    ansible@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/gather-ceph-logs.yml -i hosts

    日志存储在 Ansible 节点的 /tmp 目录中。

第 2 章 配置日志记录

本章介绍如何为各种 Ceph 子系统配置日志记录。

重要

日志记录非常耗费资源。另外,详细日志记录可以在相对较短的时间内生成大量数据。如果您在集群的特定子系统中遇到问题,请仅启用该子系统的日志记录。如需更多信息,请参阅 第 2.2 节 “Ceph 子系统”

此外,还要考虑设置日志文件轮转。详情请查看 第 2.5 节 “加快日志轮转”

修复遇到的任何问题后,将子系统日志和内存级别更改为默认值。有关所有 Ceph 子系统及其默认值的列表,请参见 附录 A, Ceph 子系统默认日志记录级别值

您可以通过以下方法配置 Ceph 日志:

2.1. 先决条件

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

2.2. Ceph 子系统

本节包含 Ceph 子系统及其日志记录级别的信息。

了解 Ceph 子系统及其日志记录级别

Ceph 由多个子系统组成:

每个子系统都有其日志记录级别:

  • 默认情况下存储在 /var/log/ceph/ 目录中的输出日志(日志级别)
  • 存储在内存缓存中的日志(内存级别)

通常,Ceph 不会将内存中存储的日志发送到输出日志,除非:

  • 引发致命信号
  • 源代码中触发了 assert
  • 您请求它

您可以为每个子系统设置不同的值。Ceph 日志记录级别按 1 到 20 级运行 其中 1 是 terse,20 是详细。

对日志级别和内存级别使用单个值,以将它们都设置为相同的值。例如,debug _osd = 5ceph-osd 守护进程的 debug 级别设置为 5

要将不同的值用于输出日志级别和内存级别,请使用正斜杠(/)分隔值。例如,debug _mon = 1/5ceph-mon 守护进程的调试日志级别设置为 1,并将其内存日志级别设置为 5

注意

对于基于容器的部署,Ceph 会生成日志到 journald。您可以通过在 Ceph 配置文件中 [global] 下将 log_to_file 参数设置为 true,以启用记录到 /var/log/ceph 中的文件。如需了解更多详细信息 ,请参阅了解 ceph 日志

表 2.1. Ceph 子系统和日志记录默认值

子系统日志级别内存级别描述

asok

1

5

管理套接字

auth

1

5

身份验证

客户端

0

5

使用 librados 连接到集群的任何应用程序或库

bluestore

1

5

BlueStore OSD 后端

journal

1

5

OSD 日志

mds

1

5

元数据服务器

monc

0

5

monitor 客户端处理大部分 Ceph 守护进程和 monitor 之间的通信

周一

1

5

monitor

ms

0

5

Ceph 组件之间的消息传递系统

osd

0

5

OSD 守护进程

paxos

0

5

监控用于建立共识的算法

rados

0

5

可靠的自主分布式对象存储,Ceph 的核心组件

rbd

0

5

Ceph 块设备

rgw

1

5

Ceph 对象网关

日志输出示例

下例演示了当您提高 monitor 和 OSD 的详细程度时,日志中的消息类型。

监控调试设置

debug_ms = 5
debug_mon = 20
debug_paxos = 20
debug_auth = 20

monitor 调试设置的日志输出示例

2016-02-12 12:37:04.278761 7f45a9afc700 10 mon.cephn2@0(leader).osd e322 e322: 2 osds: 2 up, 2 in
2016-02-12 12:37:04.278792 7f45a9afc700 10 mon.cephn2@0(leader).osd e322  min_last_epoch_clean 322
2016-02-12 12:37:04.278795 7f45a9afc700 10 mon.cephn2@0(leader).log v1010106 log
2016-02-12 12:37:04.278799 7f45a9afc700 10 mon.cephn2@0(leader).auth v2877 auth
2016-02-12 12:37:04.278811 7f45a9afc700 20 mon.cephn2@0(leader) e1 sync_trim_providers
2016-02-12 12:37:09.278914 7f45a9afc700 11 mon.cephn2@0(leader) e1 tick
2016-02-12 12:37:09.278949 7f45a9afc700 10 mon.cephn2@0(leader).pg v8126 v8126: 64 pgs: 64 active+clean; 60168 kB data, 172 MB used, 20285 MB / 20457 MB avail
2016-02-12 12:37:09.278975 7f45a9afc700 10 mon.cephn2@0(leader).paxosservice(pgmap 7511..8126) maybe_trim trim_to 7626 would only trim 115 < paxos_service_trim_min 250
2016-02-12 12:37:09.278982 7f45a9afc700 10 mon.cephn2@0(leader).osd e322 e322: 2 osds: 2 up, 2 in
2016-02-12 12:37:09.278989 7f45a9afc700  5 mon.cephn2@0(leader).paxos(paxos active c 1028850..1029466) is_readable = 1 - now=2016-02-12 12:37:09.278990 lease_expire=0.000000 has v0 lc 1029466
....
2016-02-12 12:59:18.769963 7f45a92fb700  1 -- 192.168.0.112:6789/0 <== osd.1 192.168.0.114:6800/2801 5724 ==== pg_stats(0 pgs tid 3045 v 0) v1 ==== 124+0+0 (2380105412 0 0) 0x5d96300 con 0x4d5bf40
2016-02-12 12:59:18.770053 7f45a92fb700  1 -- 192.168.0.112:6789/0 --> 192.168.0.114:6800/2801 -- pg_stats_ack(0 pgs tid 3045) v1 -- ?+0 0x550ae00 con 0x4d5bf40
2016-02-12 12:59:32.916397 7f45a9afc700  0 mon.cephn2@0(leader).data_health(1) update_stats avail 53% total 1951 MB, used 780 MB, avail 1053 MB
....
2016-02-12 13:01:05.256263 7f45a92fb700  1 -- 192.168.0.112:6789/0 --> 192.168.0.113:6800/2410 -- mon_subscribe_ack(300s) v1 -- ?+0 0x4f283c0 con 0x4d5b440

OSD 调试设置

debug_ms = 5
debug_osd = 20

OSD 调试设置的日志输出示例

2016-02-12 11:27:53.869151 7f5d55d84700  1 -- 192.168.17.3:0/2410 --> 192.168.17.4:6801/2801 -- osd_ping(ping e322 stamp 2016-02-12 11:27:53.869147) v2 -- ?+0 0x63baa00 con 0x578dee0
2016-02-12 11:27:53.869214 7f5d55d84700  1 -- 192.168.17.3:0/2410 --> 192.168.0.114:6801/2801 -- osd_ping(ping e322 stamp 2016-02-12 11:27:53.869147) v2 -- ?+0 0x638f200 con 0x578e040
2016-02-12 11:27:53.870215 7f5d6359f700  1 -- 192.168.17.3:0/2410 <== osd.1 192.168.0.114:6801/2801 109210 ==== osd_ping(ping_reply e322 stamp 2016-02-12 11:27:53.869147) v2 ==== 47+0+0 (261193640 0 0) 0x63c1a00 con 0x578e040
2016-02-12 11:27:53.870698 7f5d6359f700  1 -- 192.168.17.3:0/2410 <== osd.1 192.168.17.4:6801/2801 109210 ==== osd_ping(ping_reply e322 stamp 2016-02-12 11:27:53.869147) v2 ==== 47+0+0 (261193640 0 0) 0x6313200 con 0x578dee0
....
2016-02-12 11:28:10.432313 7f5d6e71f700  5 osd.0 322 tick
2016-02-12 11:28:10.432375 7f5d6e71f700 20 osd.0 322 scrub_random_backoff lost coin flip, randomly backing off
2016-02-12 11:28:10.432381 7f5d6e71f700 10 osd.0 322 do_waiters -- start
2016-02-12 11:28:10.432383 7f5d6e71f700 10 osd.0 322 do_waiters -- finish

2.3. 在运行时配置日志记录

您可以在系统运行时配置 Ceph 子系统日志记录,以帮助对可能出现的任何问题进行故障排除。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • Ceph 调试器访问权限.

流程

  1. 要在运行时激活 Ceph 调试输出,dout()

    ceph tell TYPE.ID injectargs --debug-SUBSYSTEM VALUE [--NAME VALUE]
  2. 替换:

    • TYPE,它具有 Ceph 守护进程的类型(osdmonmds
    • ID,具有 Ceph 守护进程的特定 ID。或者,使用 * 将运行时设置应用到特定类型的所有守护进程。
    • 带有特定子系统的 SUBSYSTEM.
    • VALUE,数字介于 1 到 20 之间, 其中 1 为 terse,20 为详细。

      例如,将名为 osd.0 的 OSD 子系统的日志级别设置为 0,将内存级别设置为 5:

      # ceph tell osd.0 injectargs --debug-osd 0/5

要在运行时查看配置设置:

  1. 使用运行中的 Ceph 守护进程登录主机,如 ceph-osd 或 ceph-mon
  2. 显示配置:

    ceph daemon NAME config show | less

    示例

    # ceph daemon osd.0 config show | less

2.4. 配置登录配置文件

配置 Ceph 子系统,以将信息、警告和错误消息记录到 日志文件。您可以在 Ceph 配置文件中指定调试级别,默认为 /etc/ceph/ceph.conf

先决条件

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

流程

  1. 若要激活 Ceph 调试输出,可在启动时 dout() 添加调试设置到 Ceph 配置文件。

    1. 对于每个守护进程常见的子系统,请在 [global] 部分下添加设置。
    2. 对于特定守护进程的子系统,请在守护进程部分中添加设置,如 [mon][osd][mds]

      示例

      [global]
              debug_ms = 1/5
      
      [mon]
              debug_mon = 20
              debug_paxos = 1/5
              debug_auth = 2
      
      [osd]
              debug_osd = 1/5
              debug_monc = 5/20
      
      [mds]
              debug_mds = 1

2.5. 加快日志轮转

提高 Ceph 组件的调试级别可能会产生大量数据。如果您几乎有完整的磁盘,可以通过修改 /etc/logrotate.d/ceph 中的 Ceph 日志轮转文件来加快日志轮转。Cron 作业调度程序使用此文件来调度日志轮转。

先决条件

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

流程

  1. 在轮转频率后向日志轮转文件中添加大小设置:

    rotate 7
    weekly
    size SIZE
    compress
    sharedscripts

    例如,在日志文件达到 500 MB 时轮转日志文件:

    rotate 7
    weekly
    size 500 MB
    compress
    sharedscripts
    size 500M
  2. 打开 crontab 编辑器:

    [root@mon ~]# crontab -e
  3. 添加条目以检查 /etc/logrotate.d/ceph 文件。例如,指示 Cron 每 30 分钟检查 /etc/logrotate.d/ceph

    30 * * * * /usr/sbin/logrotate /etc/logrotate.d/ceph >/dev/null 2>&1

第 3 章 网络问题故障排除

本章列出了与网络和网络时间协议(NTP)连接的基本故障排除步骤。

3.1. 先决条件

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

3.2. 基本网络故障排除

红帽 Ceph 存储很大程度上依赖于可靠的网络连接。红帽 Ceph 存储节点使用网络相互通信。网络问题可能会导致 Ceph OSD 出现很多问题,如断路,或者错误地报告为 down。网络问题也可能导致 Ceph monitor 的时钟偏移错误。此外,数据包丢失、高延迟或有限带宽可能会影响集群性能和稳定性。

先决条件

  • 节点的根级别访问权限。

流程

  1. 在对 Ceph 存储集群中可能发生的网络问题进行故障排除时,安装 net-toolstelnet 软件包会有所帮助:

    Red Hat Enterprise Linux 7

    [root@mon ~]# yum install net-tools
    [root@mon ~]# yum install telnet

    Red Hat Enterprise Linux 8

    [root@mon ~]# dnf install net-tools
    [root@mon ~]# dnf install telnet

  2. 验证 Ceph 配置文件中的 cluster _network 和 public_network 参数是否包含正确的值:

    示例

    [root@mon ~]# cat /etc/ceph/ceph.conf | grep net
    cluster_network = 192.168.1.0/24
    public_network = 192.168.0.0/24

  3. 验证网络接口是否已启动:

    示例

    [root@mon ~]# ip link list
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    2: enp22s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
        link/ether 40:f2:e9:b8:a0:48 brd ff:ff:ff:ff:ff:ff

  4. 验证 Ceph 节点能够使用它们的短主机名互相访问。在存储集群的每个节点上验证它:

    语法

    ping SHORT_HOST_NAME

    示例

    [root@mon ~]# ping osd01

  5. 如果使用防火墙,请确保 Ceph 节点能够在其适当的端口上访问其他节点。firewall-cmdtelnet 工具可以验证端口状态,以及端口是否分别打开:

    语法

    firewall-cmd --info-zone=ZONE
    telnet IP_ADDRESS PORT

    示例

    [root@mon ~]# firewall-cmd --info-zone=public
    public (active)
      target: default
      icmp-block-inversion: no
      interfaces: enp1s0
      sources: 192.168.0.0/24
      services: ceph ceph-mon cockpit dhcpv6-client ssh
      ports: 9100/tcp 8443/tcp 9283/tcp 3000/tcp 9092/tcp 9093/tcp 9094/tcp 9094/udp
      protocols:
      masquerade: no
      forward-ports:
      source-ports:
      icmp-blocks:
      rich rules:
    
    [root@mon ~]# telnet 192.168.0.22 9100

  6. 验证接口计数器上没有错误。验证节点之间的网络连接具有预期的延迟,并且没有数据包丢失。

    1. 使用 ethtool 命令:

      语法

      ethtool -S INTERFACE

      示例

      [root@mon ~]# ethtool -S enp22s0f0 | grep errors
      NIC statistics:
           rx_fcs_errors: 0
           rx_align_errors: 0
           rx_frame_too_long_errors: 0
           rx_in_length_errors: 0
           rx_out_length_errors: 0
           tx_mac_errors: 0
           tx_carrier_sense_errors: 0
           tx_errors: 0
           rx_errors: 0

    2. 使用 ifconfig 命令:

      示例

      [root@mon ~]# ifconfig
      enp22s0f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
      inet 10.8.222.13  netmask 255.255.254.0  broadcast 10.8.223.255
      inet6 2620:52:0:8de:42f2:e9ff:feb8:a048  prefixlen 64  scopeid 0x0<global>
      inet6 fe80::42f2:e9ff:feb8:a048  prefixlen 64  scopeid 0x20<link>
      ether 40:f2:e9:b8:a0:48  txqueuelen 1000  (Ethernet)
      RX packets 4219130  bytes 2704255777 (2.5 GiB)
      RX errors 0  dropped 0  overruns 0  frame 0 1
      TX packets 1418329  bytes 738664259 (704.4 MiB)
      TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 2
      device interrupt 16

    3. 使用 netstat 命令:

      示例

      [root@mon ~]# netstat -ai
      Kernel Interface table
      Iface          MTU   RX-OK RX-ERR RX-DRP RX-OVR  TX-OK TX-ERR TX-DRP TX-OVR Flg
      docker0       1500       0      0      0 0           0      0      0      0 BMU
      eno2          1500       0      0      0 0           0      0      0      0 BMU
      eno3          1500       0      0      0 0           0      0      0      0 BMU
      eno4          1500       0      0      0 0           0      0      0      0 BMU
      enp0s20u13u5  1500  253277      0      0 0           0      0      0      0 BMRU
      enp22s0f0     9000  234160      0      0 0      432326      0      0      0 BMRU 1
      lo           65536   10366      0      0 0       10366      0      0      0 LRU

  7. 对于性能问题,除了延迟检查和验证存储集群所有节点之间的网络带宽外,使用 iperf3 工具。iperf3 工具在服务器和客户端之间进行简单的点对点网络带宽测试。

    1. 在您要检查带宽的 Red Hat Ceph Storage 节点上安装 iperf3 软件包:

      Red Hat Enterprise Linux 7

      [root@mon ~]# yum install iperf3

      Red Hat Enterprise Linux 8

      [root@mon ~]# dnf install iperf3

    2. 在 Red Hat Ceph Storage 节点上启动 iperf3 服务器:

      示例

      [root@mon ~]# iperf3 -s
      -----------------------------------------------------------
      Server listening on 5201
      -----------------------------------------------------------

      注意

      默认端口为 5201,但可使用 -P 命令参数设置。

    3. 在不同的 Red Hat Ceph Storage 节点上,启动 iperf3 客户端:

      示例

      [root@osd ~]# iperf3 -c mon
      Connecting to host mon, port 5201
      [  4] local xx.x.xxx.xx port 52270 connected to xx.x.xxx.xx port 5201
      [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
      [  4]   0.00-1.00   sec   114 MBytes   954 Mbits/sec    0    409 KBytes
      [  4]   1.00-2.00   sec   113 MBytes   945 Mbits/sec    0    409 KBytes
      [  4]   2.00-3.00   sec   112 MBytes   943 Mbits/sec    0    454 KBytes
      [  4]   3.00-4.00   sec   112 MBytes   941 Mbits/sec    0    471 KBytes
      [  4]   4.00-5.00   sec   112 MBytes   940 Mbits/sec    0    471 KBytes
      [  4]   5.00-6.00   sec   113 MBytes   945 Mbits/sec    0    471 KBytes
      [  4]   6.00-7.00   sec   112 MBytes   937 Mbits/sec    0    488 KBytes
      [  4]   7.00-8.00   sec   113 MBytes   947 Mbits/sec    0    520 KBytes
      [  4]   8.00-9.00   sec   112 MBytes   939 Mbits/sec    0    520 KBytes
      [  4]   9.00-10.00  sec   112 MBytes   939 Mbits/sec    0    520 KBytes
      - - - - - - - - - - - - - - - - - - - - - - - - -
      [ ID] Interval           Transfer     Bandwidth       Retr
      [  4]   0.00-10.00  sec  1.10 GBytes   943 Mbits/sec    0             sender
      [  4]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec                  receiver
      
      iperf Done.

      此输出显示红帽 Ceph 存储节点之间的网络带宽 1.1 Gbits/秒,测试期间不会再传输(Retr)。

      红帽建议您验证存储集群中所有节点之间的网络带宽。

  8. 确保所有节点具有相同的网络互连速度。连接较慢的节点可能会减慢连接速度更快的节点。另外,确保间隔交换机链接可以处理附加节点的聚合带宽:

    语法

    ethtool INTERFACE

    示例

    [root@mon ~]# ethtool enp22s0f0
    Settings for enp22s0f0:
    Supported ports: [ TP ]
    Supported link modes:   10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Half 1000baseT/Full
    Supported pause frame use: No
    Supports auto-negotiation: Yes
    Supported FEC modes: Not reported
    Advertised link modes:  10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Half 1000baseT/Full
    Advertised pause frame use: Symmetric
    Advertised auto-negotiation: Yes
    Advertised FEC modes: Not reported
    Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                         100baseT/Half 100baseT/Full
                                         1000baseT/Full
    Link partner advertised pause frame use: Symmetric
    Link partner advertised auto-negotiation: Yes
    Link partner advertised FEC modes: Not reported
    Speed: 1000Mb/s 1
    Duplex: Full 2
    Port: Twisted Pair
    PHYAD: 1
    Transceiver: internal
    Auto-negotiation: on
    MDI-X: off
    Supports Wake-on: g
    Wake-on: d
    Current message level: 0x000000ff (255)
           drv probe link timer ifdown ifup rx_err tx_err
    Link detected: yes 3

其它资源

3.3. 基本 chrony NTP 故障排除

本节包含基本的 chrony 故障排除步骤。

先决条件

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

流程

  1. 验证 chronyd 守护进程是否在 Ceph Monitor 主机上运行:

    示例

    [root@mon ~]# systemctl status chronyd

  2. 如果 chronyd 未运行,请启用并启动它:

    示例

    [root@mon ~]# systemctl enable chronyd
    [root@mon ~]# systemctl start chronyd

  3. 确定 chronyd 正确同步时钟:

    示例

    [root@mon ~]# chronyc sources
    [root@mon ~]# chronyc sourcestats
    [root@mon ~]# chronyc tracking

其它资源

  • 如需了解高级 chrony NTP 故障排除步骤,请参阅红帽客户门户网站中的 chrony 问题解决方案。
  • 详情请查看 Red Hat Ceph Storage 故障排除指南中的 Clock skew 部分。
  • 详情请查看 检查是否同步 chrony 部分。

3.4. 基本 NTP 故障排除

本节介绍基本的 NTP 故障排除步骤。

先决条件

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

流程

  1. 验证 ntpd 守护进程是否在 Ceph 监控主机上运行:

    示例

    [root@mon ~]# systemctl status ntpd

  2. 如果 ntpd 没有运行,启用并启动它:

    示例

    [root@mon ~]# systemctl enable ntpd
    [root@mon ~]# systemctl start ntpd

  3. 确保 ntpd 正确同步时钟:

    示例

    [root@mon ~]# ntpq -p

其它资源

第 4 章 Ceph 监控器故障排除

本章包含关于如何修复与 Ceph 监控器相关的最常见错误的信息。

4.1. 先决条件

  • 验证网络连接。

4.2. 大多数常见 Ceph 监控错误

下表列出了 ceph 运行状况详细信息 命令返回或包含在 Ceph 日志中的最常见错误消息:这些表中提供了相应的部分的链接,这些部分解释了错误并指向修复问题的特定程序。

4.2.1. 先决条件

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

4.2.2. Ceph 监控错误消息

常见 Ceph monitor 错误消息和可能的修复表。

错误消息请查看

HEALTH_WARN

mon.X 停机(超出仲裁数)

Ceph monitor 超出仲裁数

时钟偏移

时钟偏移

存储太大了!

Ceph 监控器存储太大

4.2.3. Ceph 日志中的通用 Ceph monitor 错误消息

Ceph 日志中找到的常见 Ceph monitor 错误消息表,以及指向潜在修复的链接。

错误消息日志文件请查看

时钟偏移

主集群日志

时钟偏移

时钟不同步

主集群日志

时钟偏移

损坏:记录中存在错误

监控日志

Ceph monitor 超出仲裁数

恢复 Ceph 监控存储

损坏:1 缺少文件

监控日志

Ceph monitor 超出仲裁数

恢复 Ceph 监控存储

捕获的信号(Bus 错误)

监控日志

Ceph monitor 超出仲裁数

4.2.4. Ceph monitor 超出仲裁数

个或多个 Ceph 监控器已标记为 down,但其他 Ceph 监控器仍然能够形成仲裁。此外,ceph 运行状况详情 命令返回类似如下的错误消息:

HEALTH_WARN 1 mons down, quorum 1,2 mon.b,mon.c
mon.a (rank 0) addr 127.0.0.1:6789/0 is down (out of quorum)

此 Means 是什么

Ceph 将 Ceph monitor 标记为 down,原因有多种。

如果 ceph-mon 守护进程未在运行,它可能具有损坏的存储或者其他一些错误阻止守护进程启动。另外,/var/ 分区可能已满。因此,ceph -mon 无法对位于 /var/lib/ceph/mon-SHORT_HOST_NAME/store.db 的存储执行任何操作,并终止。

如果 ceph-mon 守护进程正在运行,但 Ceph monitor 没有仲裁并标记为 down,问题的原因取决于 Ceph monitor 状态:

  • 如果 Ceph 监控器处于 探测 状态超过预期,则无法找到其他 Ceph 监控器。此问题可能是由网络问题造成的,或者 Ceph monitor 可以具有过时的 Ceph monitor map(monmap),并尝试访问错误的 IP 地址上的其他 Ceph 监控器。另外,如果 monmap 是最新的,Ceph monitor 的时钟可能无法同步。
  • 如果 Ceph monitor 处于超过预期 状态的选择状态,Ceph 监控器的时钟可能无法同步。
  • 如果 Ceph monitor 将自己的状态从 同步 更改为开 机和 返回,集群状态将会发展。这意味着,它生成的新 map 的速度要快于同步进程可以处理的速度。
  • 如果 Ceph 监控器将自身标记为 领导 机或工作台, 那么它将确信它处于仲裁状态,而剩余的集群则确定它不是。此问题可能是时钟同步失败造成的。

要排除这个问题,请执行以下操作

  1. 验证 ceph-mon 守护进程正在运行。如果没有,请启动它:

    [root@mon ~]# systemctl status ceph-mon@HOST_NAME
    [root@mon ~]# systemctl start ceph-mon@HOST_NAME

    HOST_NAME 替换为正在运行 守护进程的主机的短名称。不确定 时使用 hostname -s 命令。

  2. 如果您无法启动 ceph-mon 守护进程,请按照 ceph-mon 守护进程中的步骤启动
  3. 如果您能够启动 ceph-mon 守护进程但标记为 down,请按照 ceph-mon 守护进程中的步骤运行,但标记为"down"。

ceph-mon Daemon 无法启动

  1. 默认情况下,检查位于 /var/log/ceph/ceph-mon.HOST_NAME.log 的对应的 Ceph Monitor 日志。
  2. 如果日志中包含类似于下列错误消息的错误消息,Ceph monitor 可能具有损坏的存储:

    Corruption: error in middle of record
    Corruption: 1 missing files; e.g.: /var/lib/ceph/mon/mon.0/store.db/1234567.ldb

    若要修复此问题,可替换 Ceph monitor。请参阅 替换失败的 monitor

  3. 如果日志包含类似如下的错误消息,/var/ 分区可能已满。从 /var/ 删除任何不必要的数据。

    Caught signal (Bus error)
    重要

    不要手动从 monitor 目录中删除任何数据。而应使用 ceph-monstore-tool 将它压缩。详情请参阅 紧凑 Ceph monitor 存储

  4. 如果您看到任何其他错误消息,请打开支持票据。有关 详细信息,请参阅联系红帽支持团队

ceph-mon Daemon 运行,但 Still Marked 为 down

  1. 在超出仲裁的 Ceph Monitor 主机中,使用 mon_status 命令检查其状态:

    [root@mon ~]# ceph daemon ID mon_status

    使用 Ceph monitor 的 ID 替换 ID,例如:

    [root@mon ~]# ceph daemon mon.a mon_status
  2. 如果状态为 probing 请验证 mon_status 输出中其他 Ceph monitor 的位置。

    1. 如果地址不正确,Ceph monitor 具有不正确的 Ceph monitor map(monmap)。若要修复此问题,请参阅注入 Ceph monitor map
    2. 如果地址正确,请验证 Ceph 监控时钟是否已同步。详情请查看 Clock skew。另外,对任何网络问题进行故障排除,请参阅 对网络进行故障排除以了解详细信息
  3. 如果状态为选中状态 请验证 Ceph 监控时钟是否已同步。详情请查看 Clock skew
  4. 如果状态从 选择 同步变为 同步,请打开支持票据。有关 详细信息,请参阅联系红帽支持团队
  5. 如果 Ceph monitor 是 领导 机或工作 机, 请验证 Ceph 监控时钟是否已同步。详情请查看 Clock skew。如果同步时钟无法解决问题,请打开支持问题单。有关 详细信息,请参阅联系红帽支持团队

4.2.5. 时钟偏移

Ceph monitor 超出仲裁数,ceph 运行状况详情 命令输出包含类似于如下的错误消息:

mon.a (rank 0) addr 127.0.0.1:6789/0 is down (out of quorum)
mon.a addr 127.0.0.1:6789/0 clock skew 0.08235s > max 0.05s (latency 0.0045s)

此外,Ceph 日志包含类似如下的错误消息:

2015-06-04 07:28:32.035795 7f806062e700 0 log [WRN] : mon.a 127.0.0.1:6789/0 clock skew 0.14s > max 0.05s
2015-06-04 04:31:25.773235 7f4997663700 0 log [WRN] : message from mon.1 was stamped 0.186257s in the future, clocks not synchronized

此 Means 是什么

时钟偏移 错误消息表示 Ceph 监控器的时钟没有同步。时钟同步很重要,因为 Ceph monitor 依赖于时间精度,如果时钟不同步,其行为不可预知。

mon_clock_drift_allowed 参数决定时钟之间的差别是 tolerated。默认情况下,此参数设置为 0.05 秒。

重要

在未进行之前测试的情况下,请勿更改 mon_clock_drift_allowed 的默认值。更改此值可能会影响 Ceph 监控器和 Ceph 存储群集的稳定性。

时钟偏移错误的 可能原因包括网络时间协议(NTP)同步问题(如果已配置)。此外,时间同步无法在虚拟机上部署的 Ceph 监控器上正常工作。

要排除这个问题,请执行以下操作

  1. 验证您的网络是否正常工作。详情请参阅对 网络问题进行故障排除。特别是,如果您使用 NTP,则对 NTP 客户端的任何问题进行故障排除。

    1. 如果您使用 chrony 作为 NTP,请参阅 基本 chrony NTP 故障排除部分
    2. 如果使用 ntpd,请参阅 基本 NTP 故障排除
  2. 如果您使用远程 NTP 服务器,请考虑在网络上部署您自己的 NTP 服务器。

    1. 详情请参阅为 Red Hat Enterprise Linux 8 配置基本系统设置 中的使用 Chrony 套件配置 NTP 章节。
    2. 请参见《Red Hat Enterprise Linux 7 系统管理员指南》 中的" 配置 NTP 使用 ntpd "一章。
注意

Ceph 仅评估每五分钟的时间同步,因此修复问题与清除 时钟偏移 消息之间会有一个延迟。

4.2.6. Ceph 监控器存储太大

ceph health 命令返回类似如下的错误消息:

mon.ceph1 store is getting too big! 48031 MB >= 15360 MB -- 62% avail

此 Means 是什么

Ceph 监控存储实际上是一个 LevelDB 数据库,将条目存储为键值对。该数据库包含一个集群映射,默认位于 /var/lib/ceph/mon/CLUSTER_NAME-SHORT_HOST_NAME/store.db

查询大型 monitor 存储可能需要时间。因此,Ceph monitor 在响应客户端查询时可能会延迟。

此外,如果 /var/ 分区已满,Ceph monitor 无法对存储执行任何写入操作并终止。如需了解对此问题进行故障排除的详细信息 ,请参阅 Ceph monitor 仲裁

要排除这个问题,请执行以下操作

  1. 检查数据库的大小:

    du -sch /var/lib/ceph/mon/CLUSTER_NAME-SHORT_HOST_NAME/store.db

    指定集群的名称,以及运行 ceph-mon 的主机的短主机名。

    示例

    # du -sch /var/lib/ceph/mon/ceph-host1/store.db
    47G     /var/lib/ceph/mon/ceph-ceph1/store.db/
    47G     total

  2. 紧凑 Ceph 监控存储.详情请参阅 紧凑 Ceph monitor 存储

4.2.7. 了解 Ceph 监控状态

mon_status 命令返回 Ceph monitor 的信息,例如:

  • 状态
  • 等级
  • 选举时期
  • monitor map(monmap)

如果 Ceph monitor 能够形成仲裁,请使用 mon_statusceph 命令行实用程序。

如果 Ceph monitor 无法形成仲裁,但 ceph-mon 守护进程正在运行,请使用管理 socket 来执行 mon_status

mon_status输出示例

{
    "name": "mon.3",
    "rank": 2,
    "state": "peon",
    "election_epoch": 96,
    "quorum": [
        1,
        2
    ],
    "outside_quorum": [],
    "extra_probe_peers": [],
    "sync_provider": [],
    "monmap": {
        "epoch": 1,
        "fsid": "d5552d32-9d1d-436c-8db1-ab5fc2c63cd0",
        "modified": "0.000000",
        "created": "0.000000",
        "mons": [
            {
                "rank": 0,
                "name": "mon.1",
                "addr": "172.25.1.10:6789\/0"
            },
            {
                "rank": 1,
                "name": "mon.2",
                "addr": "172.25.1.12:6789\/0"
            },
            {
                "rank": 2,
                "name": "mon.3",
                "addr": "172.25.1.13:6789\/0"
            }
        ]
    }
}

Ceph monitor 状态

leader
在选择阶段,Ceph 监控器正在选举领导机。领导机是具有最高等级的 Ceph monitor,即值最低的排名。在上例中,领导机是 mon.1
Ppeon
Ppeons 是仲裁中的 Ceph monitor,而不是领导。如果领导失败,则排名最高的学员将成为新的领导。
Probing
如果 Ceph 监控器正在寻找其他 Ceph 监控器,则 Ceph 监控器处于探测状态。例如,在启动 Ceph 监控后,它们正在 探测,直到它们找到 Ceph monitor map(monmap)中指定的足够 Ceph monitor 来组成仲裁。
选择
如果 Ceph 监控器正在选择领导机,则 Ceph 监控器处于选择状态。通常,此状态会快速变化。
同步
如果 Ceph monitor 正在与其他 Ceph 监控器同步以加入仲裁,则 Ceph monitor 处于同步状态。Ceph 监控器存储容量越小,同步过程越快。因此,如果您有大量的存储,同步需要更长的时间。

其它资源

4.2.8. 其它资源

4.3. 注入 monmap

如果 Ceph monitor 具有过时或损坏的 Ceph monitor map(monmap),它就无法加入仲裁,因为它正在尝试访问错误的 IP 地址上的其他 Ceph monitor。

解决这个问题的最安全方法是从其他 Ceph 监控器获取并注入实际的 Ceph monitor map。

注意

此操作将覆盖 Ceph monitor 保存的现有 Ceph monitor map。

此流程演示了如何在其他 Ceph monitor 组成仲裁或至少一个 Ceph monitor 具有正确的 Ceph monitor map 时注入 Ceph monitor map。如果所有 Ceph 监控器都损坏存储,因此也包含 Ceph monitor map,请参阅恢复 Ceph monitor 存储

先决条件

  • 访问 Ceph monitor map.
  • Ceph 监控节点的根级别访问权限.

流程

  1. 如果剩余的 Ceph 监控器能够形成仲裁,请使用 ceph mon getmap 命令获取 Ceph monitor map:

    [root@mon ~]# ceph mon getmap -o /tmp/monmap
  2. 如果剩余的 Ceph 监控器无法形成仲裁,并且至少有一个 Ceph monitor 带有正确的 Ceph monitor map,请从该 Ceph 监控器复制它:

    1. 停止您要复制 Ceph monitor map 的 Ceph 监控器:

      [root@mon ~]# systemctl stop ceph-mon@<host-name>

      例如,停止在带有 host1 短主机名的主机上运行的 Ceph 监控器:

      [root@mon ~]# systemctl stop ceph-mon@host1
    2. 复制 Ceph monitor map:

      [root@mon ~]# ceph-mon -i ID --extract-monmap /tmp/monmap

      使用您要从中复制 Ceph monitor 映射的 Ceph monitor ID 替换 ID:

      [root@mon ~]# ceph-mon -i mon.a  --extract-monmap /tmp/monmap
  3. 使用损坏或过时的 Ceph monitor map 停止 Ceph monitor:

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

    例如,停止在带有 host2 短主机名的主机上运行的 Ceph 监控器:

    [root@mon ~]# systemctl stop ceph-mon@host2
  4. 您可以通过两种不同的方式,以 ceph 用户身份注入 Ceph Monitor 映射:

    • ceph 用户身份运行该命令:

      语法

      su - ceph -c 'ceph-mon -i ID --inject-monmap /tmp/monmap'

      使用 Ceph monitor 的 ID 替换为损坏或过期的 Ceph monitor map:

      示例

      [root@mon ~]# su - ceph -c 'ceph-mon -i mon.c --inject-monmap /tmp/monmap'

    • root 用户身份运行该命令,然后运行 chown 以更改权限:

      1. 以 root 用户身份运行该命令:

        语法

        ceph-mon -i ID --inject-monmap /tmp/monmap

        使用 Ceph monitor 的 ID 替换为损坏或过期的 Ceph monitor map:

        示例

        [root@mon ~]# ceph-mon -i mon.c --inject-monmap /tmp/monmap

      2. 更改文件权限:

        示例

        [root@mon ~]# chown -R ceph:ceph /var/lib/ceph/mon/ceph-c/

  5. 启动 Ceph 监控器:

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

    如果您从另一个 Ceph 监控器复制了 Ceph monitor map,请也启动该 Ceph monitor:

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

4.4. 替换失败的 monitor

当 monitor 具有损坏的存储时,建议通过利用 Ansible 自动化应用来替换 monitor。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 能够形成仲裁.
  • Ceph 监控节点的根级别访问权限.

流程

  1. 从 monitor 主机,默认删除位于 /var/lib/ceph/mon/CLUSTER_NAME -SHORT_HOST_NAME 的 monitor 存储:

    rm -rf /var/lib/ceph/mon/CLUSTER_NAME-SHORT_HOST_NAME

    指定 monitor 主机的简短主机名和集群名称。例如,要从名为 remote 的集群中删除在 host1 上运行的 monitor 存储:

    [root@mon ~]# rm -rf /var/lib/ceph/mon/remote-host1
  2. 从 monitor map 中删除 monitor(monmap):

    ceph mon remove SHORT_HOST_NAME --cluster CLUSTER_NAME

    指定 monitor 主机的简短主机名和集群名称。例如,要从名为 remote 的集群中移除 host1 上运行的 monitor:

    [root@mon ~]# ceph mon remove host1 --cluster remote
  3. 排除故障并修复与 monitor 主机底层文件系统或硬件相关的问题。
  4. 从 Ansible 管理节点,通过运行 ceph-ansible playbook 来重新部署 monitor:

    $ /usr/share/ceph-ansible/ansible-playbook site.yml

其它资源

4.5. 压缩 monitor 存储

当 monitor 存储的大小增大时,您可以对其进行压缩:

  • 使用 ceph inform 命令动态 使用。
  • ceph-mon 守护进程启动后
  • ceph-mon 守护进程没有运行时,使用 ceph-mon store-tool。当前面提到的方法无法压缩 monitor 存储或者 monitor 超出仲裁并且其日志包含 Caught 信号(Bus 错误)错误消息 时,可使用此方法。
重要

当集群不处于 active+clean 状态或重新平衡过程中,监控存储大小更改。因此,在完成重新平衡时,压缩 monitor 存储。此外,确保 PG 处于 active+clean 状态。

先决条件

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

流程

  1. ceph-mon 守护进程运行时压缩 monitor 存储:

    ceph tell mon.HOST_NAME compact
  2. HOST_NAME 替换为运行 ceph-mon 的主机的短主机名。不确定 时使用 hostname -s 命令。

    # ceph tell mon.host1 compact
  3. 将以下参数添加到 Ceph 配置的 [mon] 部分下:

    [mon]
    mon_compact_on_start = true
  4. 重启 ceph-mon 守护进程:

    [root@mon ~]# systemctl restart ceph-mon@_HOST_NAME_

    HOST_NAME 替换为正在运行 守护进程的主机的短名称。不确定 时使用 hostname -s 命令。

    [root@mon ~]# systemctl restart ceph-mon@host1
  5. 确保 monitor 创建了仲裁:

    [root@mon ~]# ceph mon stat
  6. 如果需要,在其他 monitor 上重复这些步骤。

    注意

    在您开始之前,请确保已安装了 ceph-test 软件包。

  7. 验证具有大存储 的 ceph-mon 守护进程未在运行。如果需要,请停止 后台程序。

    [root@mon ~]# systemctl status ceph-mon@HOST_NAME
    [root@mon ~]# systemctl stop ceph-mon@HOST_NAME

    HOST_NAME 替换为正在运行 守护进程的主机的短名称。不确定 时使用 hostname -s 命令。

    [root@mon ~]# systemctl status ceph-mon@host1
    [root@mon ~]# systemctl stop ceph-mon@host1
  8. ceph 用户身份通过两种不同的方式对 monitor 存储进行压缩:

    • ceph 用户身份运行该命令:

      语法

      su - ceph -c 'ceph-monstore-tool /var/lib/ceph/mon/mon.HOST_NAME compact'

      示例

      [root@mon ~]# su - ceph -c 'ceph-monstore-tool /var/lib/ceph/mon/mon.node1 compact'

    • root 用户身份运行该命令,然后运行 chown 以更改权限:

      1. 以 root 用户身份运行该命令:

        语法

        ceph-monstore-tool /var/lib/ceph/mon/mon.HOST_NAME compact

        示例

        [root@mon ~]# ceph-monstore-tool /var/lib/ceph/mon/mon.node1 compact

      2. 更改文件权限:

        示例

        [root@mon ~]# chown -R ceph:ceph /var/lib/ceph/mon/mon.node1

  9. 再次启动 ceph-mon

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

    示例

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

4.6. 为 Ceph Manager 打开端口

ceph-mgr 守护进程从与 ceph-osd 守护进程相同的端口范围的 OSD 接收 PG 信息。如果没有打开这些端口,集群将从 HEALTH_OK 转移到 HEALTH_WARN并且指出 PG 百分比数为 unknown。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • Ceph 管理器的根级别访问权限.

流程

  1. 要解决这种情况,对于运行 ceph-mgr 守护进程的每个主机,打开端口 6800-7300

    示例

    [root@ceph-mgr] # firewall-cmd --add-port 6800-7300/tcp
    [root@ceph-mgr] # firewall-cmd --add-port 6800-7300/tcp --permanent

  2. 重新启动 ceph-mgr 守护进程。

4.7. 为裸机部署恢复 Ceph 监控

如果所有 monitor 都在红帽 Ceph 存储集群中停机,并且 ceph -s 命令不会如预期执行,您可以使用 monmaptool 命令恢复 monitor。monmaptool 命令从守护进程的密钥环文件中重建 Ceph 监控器存储。

注意

这个过程只适用于 裸机 Red Hat Ceph Storage 部署。对于 容器化 Red Hat Ceph Storage 部署,请参阅知识库文章 Red Hat Ceph Storage 容器化部署的 MON 恢复过程。

先决条件

  • 裸机部署了红帽 Ceph 存储集群。
  • 所有节点的根级别访问权限。
  • 所有 Ceph 监视器都为 down。

流程

  1. 登录 monitor 节点。
  2. 从监控节点,如果您在不成为 root 用户的情况下无法访问 OSD 节点,请将公钥对复制到 OSD 节点:

    1. 生成 SSH 密钥对,接受默认文件名,并保留密语为空:

      示例

      [root@mons-1 ~]# ssh-keygen

    2. 将公钥复制到存储 集群中所有 OSD 节点:

      示例

      [root@mons-1 ~]#  ssh-copy-id root@osds-1
      [root@mons-1 ~]#  ssh-copy-id root@osds-2
      [root@mons-1 ~]#  ssh-copy-id root@osds-3

  3. 在所有 OSD 节点上停止 OSD 守护进程服务:

    示例

    [root@osds-1 ~]#  sudo systemctl stop ceph-osd\*.service ceph-osd.target

  4. 要从所有 OSD 节点收集 cluster map,请创建恢复文件并执行该脚本:

    1. 创建恢复文件:

      示例

      [root@mons-1 ~]# touch recover.sh

    2. 将以下内容添加到 文件中,并将 OSD_NODES 替换为所有 OSD 节点的 IP 地址或 Red Hat Ceph Storage 集群中所有 OSD 节点的主机名:

      语法

       --------------------------------------------------------------------------  NOTE: The directory names specified by 'ms', 'db', and 'db_slow' must end
       with a trailing / otherwise rsync will not operate properly.  --------------------------------------------------------------------------
      ms=/tmp/monstore/
      db=/root/db/
      db_slow=/root/db.slow/
      
      mkdir -p $ms $db $db_slow
      
       --------------------------------------------------------------------------  NOTE: Replace the contents inside double quotes for 'osd_nodes' below with
       the list of OSD nodes in the environment.  --------------------------------------------------------------------------
      osd_nodes="OSD_NODES_1 OSD_NODES_2 OSD_NODES_3..."
      
      for osd_node in $osd_nodes; do
      echo "Operating on $osd_node"
      rsync -avz --delete $ms $osd_node:$ms
      rsync -avz --delete $db $osd_node:$db
      rsync -avz --delete $db_slow $osd_node:$db_slow
      
      ssh -t $osd_node <<EOF
      for osd in /var/lib/ceph/osd/ceph-*; do
          ceph-objectstore-tool --type bluestore --data-path \$osd --op update-mon-db --no-mon-config --mon-store-path $ms
          if [ -e \$osd/keyring ]; then
              cat \$osd/keyring >> $ms/keyring
              echo '    caps mgr = "allow profile osd"' >> $ms/keyring
              echo '    caps mon = "allow profile osd"' >> $ms/keyring
              echo '    caps osd = "allow *"' >> $ms/keyring
          else
              echo WARNING: \$osd on $osd_node does not have a local keyring.
          fi
      done
      EOF
      
      rsync -avz --delete --remove-source-files $osd_node:$ms $ms
      rsync -avz --delete --remove-source-files $osd_node:$db $db
      rsync -avz --delete --remove-source-files $osd_node:$db_slow $db_slow
      done
       --------------------------------------------------------------------------  End of script
      ## --------------------------------------------------------------------------

    3. 对文件提供可执行权限:

      示例

      [root@mons-1 ~]# chmod 755 recover.sh

    4. 执行该文件,从存储集群中的所有 OSD 节点收集所有 OSD 的密钥环:

      示例

      [root@mons-1 ~]# ./recovery.sh

  5. 从对应节点获取其他守护进程的密钥环:

    1. 对于 Ceph Monitor,所有 Ceph 监视器的密钥环都是相同的。

      语法

      cat /var/lib/ceph/mon/ceph-MONITOR_NODE/keyring

      示例

      [root@mons-1 ~]# cat /var/lib/ceph/mon/ceph-mons-1/keyring

    2. 对于 Ceph Manager,从所有管理器节点获取密钥环:

      语法

      cat /var/lib/ceph/mgr/ceph-MANAGER_NODE/keyring

      示例

      [root@mons-1 ~]# cat /var/lib/ceph/mgr/ceph-mons-1/keyring

    3. 对于 Ceph OSD,密钥环由上述脚本生成,并存储在临时路径中:

      在本例中,OSD 密钥环保存在 /tmp/monstore/keyring 文件中。

    4. 对于客户端,从所有客户端节点获取密钥环:

      语法

      cat /etc/ceph/CLIENT_KEYRING

      示例

      [root@client ~]# cat /etc/ceph/ceph.client.admin.keyring

    5. 对于元数据数据服务器(MDS),请从所有 Ceph MDS 节点获取密钥环:

      语法

      cat /var/lib/ceph/mds/ceph-MDS_NODE/keyring

      示例

      [root@mons-2 ~]# cat /var/lib/ceph/mds/ceph-mds-1/keyring

      对于这个密钥环,如果不存在,会附加以下 caps:

      caps mds =  "allow"
      caps mon = "allow profile mds"
      caps osd = "allow *"
    6. 对于 Ceph 对象网关,请从所有 Ceph 对象网关节点获取密钥环:

      语法

      cat /var/lib/ceph/radosgw/ceph-CEPH_OBJECT_GATEWAY_NODE/keyring

      示例

      [root@mons-3 ~]# cat /var/lib/ceph/radosgw/ceph-rgw-1/keyring

      对于这个密钥环,如果不存在,会附加以下 caps:

      caps mon = "allow rw"
      caps osd = "allow *"
  6. 在 Ansible 管理节点上,创建带有上一步中获取的所有密钥环的文件:

    示例

    [root@admin ~]# cat /tmp/monstore/keyring
    
    [mon.]
    	key = AQAa+RxhAAAAABAApmwud0GQHX0raMBc9zTAYQ==
    	caps mon = "allow *"
    [client.admin]
    	key = AQAo+RxhcYWtGBAAiY4kKltMGnAXqPLM2A+B8w==
    	caps mds = "allow *"
    	caps mgr = "allow *"
    	caps mon = "allow *"
    	caps osd = "allow *"
    [mgr.mons-1]
    	key = AQA++RxhAAAAABAAKdG1ETTEMR8KPa9ZpfcIzw==
    	caps mds = "allow *"
    	caps mon = "allow profile mgr"
    	caps osd = "allow *"
    [mgr.mons-2]
    	key = AQA9+RxhAAAAABAAcCBxsoaIl0sdHTz3dqX4SQ==
    	caps mds = "allow *"
    	caps mon = "allow profile mgr"
    	caps osd = "allow *"
    [mgr.mons-3]
    	key = AQA/+RxhAAAAABAAwe/mwv0hS79fWP+00W6ypQ==
    	caps mds = "allow *"
    	caps mon = "allow profile mgr"
    	caps osd = "allow *"
    [osd.1]
    key = AQB/+RxhlH8rFxAAL3mb8Kdb+QuWWdJi+RvwGw==
        caps mgr = "allow profile osd"
        caps mon = "allow profile osd"
        caps osd = "allow *"
    [osd.5]
    key = AQCE+RxhKSNsHRAAIyLO5g75tqFVsl6MEEzwXw==
        caps mgr = "allow profile osd"
        caps mon = "allow profile osd"
        caps osd = "allow *"
    [osd.8]
    key = AQCJ+Rxhc0wHJhAA5Bb2kU9Nadpm3UCLASnCfw==
        caps mgr = "allow profile osd"
        caps mon = "allow profile osd"
        caps osd = "allow *"
    [osd.2]
    key = AQB/+RxhhrQCGRAAUhh77gIVhN8zsTbaKMJuHw==
        caps mgr = "allow profile osd"
        caps mon = "allow profile osd"
        caps osd = "allow *"
    [osd.4]
    key = AQCE+Rxh0mDxDRAApAeqKOJycW5bpP3IuAhSMw==
        caps mgr = "allow profile osd"
        caps mon = "allow profile osd"
        caps osd = "allow *"
    [osd.7]
    key = AQCJ+Rxhn+RAIhAAp1ImK1jiazBsDpmTQvVEVw==
        caps mgr = "allow profile osd"
        caps mon = "allow profile osd"
        caps osd = "allow *"
    [osd.0]
    key = AQB/+RxhPhh+FRAAc5b0nwiuK6o1AIbjVc6tQg==
        caps mgr = "allow profile osd"
        caps mon = "allow profile osd"
        caps osd = "allow *"
    [osd.3]
    key = AQCE+RxhJv8PARAAqCzH2br1xJmMTNnqH3I9mA==
        caps mgr = "allow profile osd"
        caps mon = "allow profile osd"
        caps osd = "allow *"
    [osd.6]
    key = AQCI+RxhAt4eIhAAYQEJqSNRT7l2WNl/rYQcKQ==
        caps mgr = "allow profile osd"
        caps mon = "allow profile osd"
        caps osd = "allow *"
    [osd.1]
    key = AQB/+RxhlH8rFxAAL3mb8Kdb+QuWWdJi+RvwGw==
        caps mgr = "allow profile osd"
        caps mon = "allow profile osd"
        caps osd = "allow *"
    [osd.5]
    key = AQCE+RxhKSNsHRAAIyLO5g75tqFVsl6MEEzwXw==
        caps mgr = "allow profile osd"
        caps mon = "allow profile osd"
        caps osd = "allow *"
    [osd.8]
    key = AQCJ+Rxhc0wHJhAA5Bb2kU9Nadpm3UCLASnCfw==
        caps mgr = "allow profile osd"
        caps mon = "allow profile osd"
        caps osd = "allow *"
    [osd.2]
    key = AQB/+RxhhrQCGRAAUhh77gIVhN8zsTbaKMJuHw==
        caps mgr = "allow profile osd"
        caps mon = "allow profile osd"
        caps osd = "allow *"
    [osd.0]
    key = AQB/+RxhPhh+FRAAc5b0nwiuK6o1AIbjVc6tQg==
        caps mgr = "allow profile osd"
        caps mon = "allow profile osd"
        caps osd = "allow *"
    [osd.3]
    key = AQCE+RxhJv8PARAAqCzH2br1xJmMTNnqH3I9mA==
        caps mgr = "allow profile osd"
        caps mon = "allow profile osd"
        caps osd = "allow *"
    [osd.6]
    key = AQCI+RxhAt4eIhAAYQEJqSNRT7l2WNl/rYQcKQ==
        caps mgr = "allow profile osd"
        caps mon = "allow profile osd"
        caps osd = "allow *"
    [mds.mds-1]
    	key = AQDs+RxhAF9vERAAdn6ArdUJ31RLr2sBVkzp3A==
            caps mds = "allow"
            caps mon = "allow profile mds"
            caps osd = "allow *"
    [mds.mds-2]
    	key = AQDs+RxhROoAFxAALAgMfM45wC5ht/vSFN2EzQ==
            caps mds = "allow"
            caps mon = "allow profile mds"
            caps osd = "allow *"
    [mds.mds-3]
    	key = AQDs+Rxhd092FRAArXLIHAhMp2z9zcWDCSoIDQ==
            caps mds = "allow"
            caps mon = "allow profile mds"
            caps osd = "allow *"
    [client.rgw.rgws-1.rgw0]
    	key = AQD9+Rxh0iP2MxAAYY76Js1AaZhzFG44cvcyOw==
            caps mon = "allow rw"
            caps osd = "allow *"

  7. 可选: 在每个 Ceph Monitor 节点上,确保 monitor map 不可用:

    示例

    [root@mons-1 ~]# ceph-monstore-tool /tmp/monstore get monmap -- --out /tmp/monmap
    [root@mons-1 ~]# monmaptool /tmp/monmap --print
    
    monmaptool: monmap file /tmp/monmap
    monmaptool: couldn't open /tmp/monmap: (2) No such file or directory
    
    Notice theNo such file or directory  error message if monmap is missed
    
    Notice that the “No such file or directory”  error message if monmap is missed

  8. 在每个 Ceph Monitor 节点中,从 etc/ceph/ceph.conf 文件获取 MONITOR_IDIP_ADDRESS_OF_MONITORFSID

    示例

    [global]
    cluster network = 10.0.208.0/22
    fsid = 9877bde8-ccb2-4758-89c3-90ca9550ffea
    mon host = [v2:10.0.211.00:3300,v1:10.0.211.00:6789],[v2:10.0.211.13:3300,v1:10.0.211.13:6789],[v2:10.0.210.13:3300,v1:10.0.210.13:6789]
    mon initial members = ceph-mons-1, ceph-mons-2, ceph-mons-3

  9. 在 Ceph Monitor 节点上,重建 monitor 映射:

    语法

    monmaptool --create --addv MONITOR_ID IP_ADDRESS_OF_MONITOR --enable-all-features --clobber PATH_OF_MONITOR_MAP --fsid FSID

    示例

    [root@mons-1 ~]# monmaptool --create --addv mons-1 [v2:10.74.177.30:3300,v1:10.74.177.30:6789] --addv mons-2 [v2:10.74.179.197:3300,v1:10.74.179.197:6789] --addv mons-3 [v2:10.74.182.123:3300,v1:10.74.182.123:6789] --enable-all-features --clobber /root/monmap.mons-1 --fsid 6c01cb34-33bf-44d0-9aec-3432276f6be8
    
    monmaptool: monmap file /root/monmap.mons-1
    monmaptool: set fsid to 6c01cb34-33bf-44d0-9aec-3432276f6be8
    monmaptool: writing epoch 0 to /root/monmap.mon-a (3 monitors)

  10. 在 Ceph Monitor 节点上,检查生成的 monitor 映射:

    语法

    monmaptool PATH_OF_MONITOR_MAP --print

    示例

    [root@mons-1 ~]# monmaptool /root/monmap.mons-1 --print
    
    monmaptool: monmap file /root/monmap.mons-1
    epoch 0
    fsid 6c01cb34-33bf-44d0-9aec-3432276f6be8
    last_changed 2021-11-23 02:57:23.235505
    created 2021-11-23 02:57:23.235505
    min_mon_release 0 (unknown)
    election_strategy: 1
    0: [v2:10.74.177.30:3300/0,v1:10.74.177.30:6789/0] mon.mons-1
    1: [v2:10.74.179.197:3300/0,v1:10.74.179.197:6789/0] mon.mons-2
    2: [v2:10.74.182.123:3300/0,v1:10.74.182.123:6789/0] mon.mons-3

  11. 在我们恢复 monitor 的 Ceph 监控节点上,从所收集的映射中重建 Ceph Monitor 存储:

    语法

    ceph-monstore-tool /tmp/monstore rebuild -- --keyring KEYRING_PATH  --monmap PATH_OF_MONITOR_MAP

    在本例中,恢复在 mons-1 节点上运行。

    示例

    [root@mons-1 ~]# ceph-monstore-tool /tmp/monstore rebuild -- --keyring /tmp/monstore/keyring  --monmap /root/monmap.mons-1

  12. 将 monstore 目录的所有权更改为 ceph:

    示例

    [root@mons-1 ~]# chown -R ceph:ceph /tmp/monstore

  13. 在所有 Ceph Monitor 节点上,对损坏的存储进行备份:

    示例

    [root@mons-1 ~]# mv /var/lib/ceph/mon/ceph-mons-1/store.db /var/lib/ceph/mon/ceph-mons-1/store.db.corrupted

  14. 在所有 Ceph Monitor 节点上,替换损坏的存储:

    示例

    [root@mons-1 ~]# scp -r /tmp/monstore/store.db mons-1:/var/lib/ceph/mon/ceph-mons-1/

  15. 在所有 Ceph Monitor 节点上,更改新存储的所有者:

    示例

    [root@mons-1 ~]# chown -R ceph:ceph /var/lib/ceph/mon/ceph-HOSTNAME/store.db

  16. 在所有 Ceph OSD 节点上,启动 OSD:

    示例

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

  17. 在所有 Ceph Monitor 节点上,启动 monitor

    示例

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

4.8. 恢复 Ceph 监控存储

Ceph 监控器将 cluster map 存储在 LevelDB 等键值存储中。如果存储在 monitor 上损坏,monitor 会意外终止,无法再次启动。Ceph 日志可能包括以下错误:

Corruption: error in middle of record
Corruption: 1 missing files; e.g.: /var/lib/ceph/mon/mon.0/store.db/1234567.ldb

生产用红帽 Ceph 存储集群至少使用三个 Ceph 监控器,以便在出现故障时可以替换为另一个监控器。然而,在某些情况下,所有 Ceph 监控器可能会损坏存储。例如,当 Ceph 监控节点配置错误的磁盘或文件系统设置时,断电可能会破坏底层文件系统。

如果所有 Ceph 监控上都存在损坏,则可以使用名为 ceph-monstore-tool 和 ceph- objectstore-tool 的实用程序,通过 OSD 节点上存储的信息来恢复它。

重要

这些步骤无法恢复以下信息:

  • 元数据守护进程服务器(MDS)密钥环和映射
  • 放置组设置:

    • 使用 ceph pg set_full_ratio 命令设置 完整比率
    • 使用 ceph pg set_nearfull_ratio 命令设置的 nearfull 比率
重要

切勿从旧备份恢复 Ceph 监控存储。使用下列步骤从当前集群状态重建 Ceph monitor 存储,并从中恢复。

4.8.1. 使用 BlueStore 时恢复 Ceph monitor 存储

如果 Ceph monitor 存储在所有 Ceph 监控上损坏并且您使用 BlueStore 后端,请按照以下步骤操作。

在容器化环境中,此方法需要附加 Ceph 存储库并首先恢复到非容器化 Ceph monitor。

警告

这个过程可能会导致数据丢失。如果您不确定此流程中的任何步骤,请联络红帽技术支持以获取恢复过程的帮助。

先决条件

  • 裸机部署

    • 安装 rsyncceph-test 软件包。
  • 容器部署

    • 所有 OSD 容器都已停止。
    • 根据 Ceph 节点上的角色,启用 Ceph 存储库。
    • ceph-testrsync 软件包安装在 OSD 和 monitor 节点上。
    • ceph-mon 软件包安装在 monitor 节点上。
    • ceph-osd 软件包安装在 OSD 节点上。

流程

  1. 如果在容器中使用 Ceph ,请将 带有 Ceph 数据的所有磁盘挂载到临时位置。对所有 OSD 节点重复此步骤。

    1. 列出数据分区。根据您用来设置设备的实用程序,使用 ceph-volume 或 ceph-disk

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

      [root@osd ~]# ceph-disk list
    2. 将数据分区挂载到临时位置:

      mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-$i
    3. 恢复 SELinux 上下文:

      for i in {OSD_ID}; do restorecon /var/lib/ceph/osd/ceph-$i; done

      使用 OSD 节点上以空格分隔的 Ceph OSD ID 列表替换 OSD_ID

    4. 将所有者和组更改为 ceph:ceph

      for i in {OSD_ID}; do chown -R ceph:ceph /var/lib/ceph/osd/ceph-$i; done

      使用 OSD 节点上以空格分隔的 Ceph OSD ID 列表替换 OSD_ID

      重要

      由于一个导致 update-mon-db 命令使用 monitor 数据库的其他 dbdb.slow 目录的错误,您还必须复制这些目录。要做到这一点:

      1. 准备容器外部的临时位置,以挂载和访问 OSD 数据库,并提取恢复 Ceph 监控所需的 OSD map:

        ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev OSD-DATA --path /var/lib/ceph/osd/ceph-OSD-ID

        OSD-DATA 替换为 OSD 数据和 OSD-ID 的卷组(VG)或逻辑卷(LV)路径。

      2. 在 BlueStore 数据库和 block.db 之间创建一个符号链接:

        ln -snf BLUESTORE DATABASE /var/lib/ceph/osd/ceph-OSD-ID/block.db

        BLUESTORE-DATABASE 替换为 BlueStore 数据库和 OSD-ID 的卷组(VG)或逻辑卷(LV)路径。

  2. 从具有损坏存储的 Ceph 监控节点使用以下命令:对所有节点上的所有 OSD 重复它们。

    1. 从所有 OSD 节点收集 cluster map:

      [root@ mon~]# cd /root/
      [root@mon ~]# ms=/tmp/monstore/
      [root@mon ~]# db=/root/db/
      [root@mon ~]# db_slow=/root/db.slow/
      
      [root@mon ~]# mkdir $ms
      [root@mon ~]# for host in $osd_nodes; do
                      echo "$host"
                      rsync -avz $ms $host:$ms
                      rsync -avz $db $host:$db
                      rsync -avz $db_slow $host:$db_slow
      
                      rm -rf $ms
                      rm -rf $db
                      rm -rf $db_slow
      
                      sh -t $host <<EOF
                        for osd in /var/lib/ceph/osd/ceph-*; do
                          ceph-objectstore-tool --type bluestore --data-path \$osd --op update-mon-db --mon-store-path $ms
      
                         done
                      EOF
      
                            rsync -avz $host:$ms $ms
                            rsync -avz $host:$db $db
                            rsync -avz $host:$db_slow $db_slow
                      done
    2. 设置适当的功能:

      [root@mon ~]# ceph-authtool /etc/ceph/ceph.client.admin.keyring -n mon. --cap mon 'allow *' --gen-key
      [root@mon ~]# cat /etc/ceph/ceph.client.admin.keyring
        [mon.]
          key = AQCleqldWqm5IhAAgZQbEzoShkZV42RiQVffnA==
          caps mon = "allow *"
        [client.admin]
          key = AQCmAKld8J05KxAArOWeRAw63gAwwZO5o75ZNQ==
          auid = 0
          caps mds = "allow *"
          caps mgr = "allow *"
          caps mon = "allow *"
          caps osd = "allow *"
    3. 将所有 sst 文件从 dbdb.slow 目录移动到临时位置:

      [root@mon ~]# mv /root/db/*.sst /root/db.slow/*.sst /tmp/monstore/store.db
    4. 从收集的 map 重建 monitor 存储:

      [root@mon ~]# ceph-monstore-tool /tmp/monstore rebuild -- --keyring /etc/ceph/ceph.client.admin
      注意

      使用此命令后,Ceph 身份验证数据库中仅存在从 OSD 提取的密钥环 和 ceph-monstore-tool 命令行中指定的密钥环。您必须重新创建或导入所有其他密钥环,如客户端、Ceph 管理器和 Ceph 对象网关等,以便这些客户端可以访问集群。

    5. 备份损坏的存储。对所有 Ceph 监控节点重复此步骤:

      mv /var/lib/ceph/mon/ceph-HOSTNAME/store.db /var/lib/ceph/mon/ceph-HOSTNAME/store.db.corrupted

      使用 Ceph 监控节点的主机名替换 HOSTNAME

    6. 替换损坏的存储。对所有 Ceph 监控节点重复此步骤:

      scp -r /tmp/monstore/store.db HOSTNAME:/var/lib/ceph/mon/ceph-HOSTNAME/

      使用 monitor 节点的主机名替换 HOSTNAME

    7. 更改新存储的所有者。对所有 Ceph 监控节点重复此步骤:

      chown -R ceph:ceph /var/lib/ceph/mon/ceph-HOSTNAME/store.db

      使用 Ceph 监控节点的主机名替换 HOSTNAME

  3. 如果在容器中使用 Ceph 则在所有节点上卸载所有临时挂载的 OSD:

    [root@osd ~]# umount /var/lib/ceph/osd/ceph-*
  4. 启动所有 Ceph 监控守护进程:

    [root@mon ~]# systemctl start ceph-mon *
  5. 确保 monitor 能够形成仲裁:

    • 裸机部署

      [root@mon ~]# ceph -s
    • 容器

      [user@admin ~]$ docker exec ceph-mon-_HOSTNAME_ ceph -s

      使用 Ceph 监控节点的主机名替换 HOSTNAME

  6. 导入 Ceph Manager 密钥环并启动所有 Ceph Manager 进程:

    ceph auth import -i /etc/ceph/ceph.mgr.HOSTNAME.keyring
    systemctl start ceph-mgr@HOSTNAME

    使用 Ceph 管理器节点的主机名替换 HOSTNAME

  7. 在所有 OSD 节点中启动所有 OSD 进程:

    [root@osd ~]# systemctl start ceph-osd *
  8. 确保 OSD 返回到服务:

    • 裸机部署

      [root@mon ~]# ceph -s
    • 容器

      [user@admin ~]$ docker exec ceph-mon-_HOSTNAME_ ceph -s

      使用 Ceph 监控节点的主机名替换 HOSTNAME

其它资源

4.9. 其它资源

第 5 章 Ceph OSD 故障排除

本章包含关于如何修复与 Ceph OSD 相关的最常见错误的信息。

5.1. 先决条件

  • 验证您的网络连接。详情请参阅 对网络进行故障排除
  • 使用 ceph health 命令,验证 monitor 具有仲裁。如果命令返回健康状态(HEALTH_OKHEALTH_WARNHEALTH_ERR),则 monitor 能够形成仲裁。如果没有,请首先解决任何 monitor 问题。详情请参阅 Ceph 监控器故障排除。如需有关 ceph 健康状态 的详细信息,请参阅 了解 Ceph 健康状态
  • (可选)停止重新平衡过程,以节省时间和资源。详情请参阅 停止和启动重新平衡

5.2. 大多数常见 Ceph OSD 错误

下表列出了 ceph 运行状况详细信息 命令返回或包含在 Ceph 日志中的最常见错误消息:这些表中提供了相应的部分的链接,这些部分解释了错误并指向修复问题的特定程序。

5.2.1. 先决条件

  • 对 Ceph OSD 节点的根级别访问权限.

5.2.2. Ceph OSD 错误消息

常见 Ceph OSD 错误消息和可能的修复表。

错误消息请查看

HEALTH_ERR

full osds

完整 OSD

HEALTH_WARN

backfillfull osds

backfillfull OSDS

nearfull osds

nearfull OSDS

OSD 已停机

OSDS 已停机

Flaning OSDS

请求被阻塞

请求或请求速度较慢

请求速度慢

请求或请求速度较慢

5.2.3. Ceph 日志中的常见 Ceph OSD 错误消息

Ceph 日志中常见 Ceph OSD 错误消息的列表,以及可能的修复链接。

错误消息日志文件请查看

heartbeat_check:没有来自 osd.X 的回复

主集群日志

Flaning OSDS

错误地标记我被关闭

主集群日志

Flaning OSDS

OSD 的请求速度较慢

主集群日志

请求或请求速度较慢

FAILED assert(0 == "hit suicide timeout")

OSD 日志

故障 OSD

5.2.4. 完整 OSD

ceph 运行状况详情 命令返回类似如下的错误消息:

HEALTH_ERR 1 full osds
osd.3 is full at 95%

此 Means 是什么

Ceph 可以防止客户端在完整的 OSD 节点上执行 I/O 操作,以避免数据丢失。当集群达到 mon _osd_full_ratio 参数设定的容量时,它会返回 HEALTH_ ERR full osds 消息。默认情况下,此参数设置为 0.95,即集群容量的 95%。

要排除这个问题,请执行以下操作

确定使用原始存储的百分比(%RAW USED):

# ceph df

如果 %RAW USED 超过 70-75%,您可以:

  • 删除不必要的数据.这是避免生产停机时间的短期解决方案。
  • 通过添加新 OSD 节点来扩展集群。这是红帽推荐的长期解决方案。

其它资源

5.2.5. 回填 full OSD

ceph 运行状况详情 命令返回类似如下的错误消息:

health: HEALTH_WARN
3 backfillfull osd(s)
Low space hindering backfill (add storage if this doesn't resolve itself): 32 pgs backfill_toofull

这意味着

当一个或多个 OSD 超过 backfillfull 阈值时,Ceph 会阻止数据重新平衡此设备。这是一个早期警告,重新平衡可能无法完成,集群正在完全接近。默认的 backfullfull 阈值为 90%。

要排除这个问题,请执行以下操作

按池检查使用量:

ceph df

如果 %RAW USED 超过 70-75%,您可以执行以下操作之一:

  • 删除不必要的数据.这是避免生产停机时间的短期解决方案。
  • 通过添加新 OSD 节点来扩展集群。这是红帽推荐的长期解决方案。
  • 增加包含 back full _toofull 的 OSD 的回填 full 比率,以允许恢复过程继续。尽快在集群中添加新存储,或移除数据以防止填充更多 OSD。

    语法

    ceph osd set-backfillfull-ratio VALUE

    VALUE 的范围为 0.0 到 1.0。

    示例

    [ceph: root@host01/]# ceph osd set-backfillfull-ratio 0.92

其它资源

5.2.6. nearfull OSD

ceph 运行状况详情 命令返回类似如下的错误消息:

HEALTH_WARN 1 nearfull osds
osd.2 is near full at 85%

此 Means 是什么

当集群达到 mon osd nearfull 比率 defaults 参数所设置的容量时,Ceph 会返回 nearfull osd s 消息。默认情况下,此参数设置为 0.85,即集群容量的 85%。

Ceph 以尽可能最佳的方式分发基于 CRUSH 层次结构的数据,但它不能保证均匀分布。数据分布不均匀nearfull osds 信息的主要原因是:

  • OSD 在集群中的 OSD 节点之间没有平衡。也就是说,一些 OSD 节点托管的 OSD 比其他 OSD 高得多,或者 CRUSH map 中部分 OSD 的权重不足以满足其容量要求。
  • PG 计数与 OSD 数量、用例、每个 OSD 目标 PG 和 OSD 利用率不同。
  • 集群使用不当的 CRUSH 可调项。
  • OSD 的后端存储几乎已满。

排除此问题,请执行以下操作:

  1. 验证 PG 计数是否足够,并在需要时增加。
  2. 验证您是否使用最优于集群版本的 CRUSH 可调项,如果不是,请进行调整。
  3. 根据利用率更改 OSD 的权重。
  4. 启用 Ceph 管理器均衡器模块,优化 OSD 之间的 PG 放置,从而实现均衡分布

    示例

    [root@mon ~]# ceph mgr module enable balancer

  5. 确定 OSD 使用的磁盘上保留多少空间。

    1. 查看 OSD 一般使用的空间量:

      [root@mon ~]# ceph osd df
    2. 查看 OSD 在特定节点上使用的空间:从包含 接近ful OSD 的节点运行以下命令:

      $ df
    3. 如果需要,添加新 OSD 节点。

5.2.7. 故障 OSD

ceph health 命令返回类似如下的错误:

HEALTH_WARN 1/3 in osds are down

此 Means 是什么

由于服务故障或与其他 OSD 通信存在问题,其中一个 ceph-osd 进程不可用。因此,存活的 ceph-osd 守护进程会向 monitor 报告此故障。

如果 ceph-osd 守护进程未在运行,则底层 OSD 驱动器或文件系统已损坏,或者存在一些其他错误(如缺少密钥环)会阻止守护进程启动。

在大多数情况下,网络问题会导致 ceph-osd 守护进程正在运行但依然标记为 down 时的情况。

要排除这个问题,请执行以下操作

  1. 确定哪个 OSD 处于 down 状态

    [root@mon ~]# ceph health detail
    HEALTH_WARN 1/3 in osds are down
    osd.0 is down since epoch 23, last address 192.168.106.220:6800/11080
  2. 尝试重启 ceph-osd 守护进程:

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

    OSD_NUMBER 替换为 down 的 OSD ID,例如:

    [root@mon ~]# systemctl restart ceph-osd@0
    1. 如果您无法启动 ceph-osd,请按照 ceph-osd 守护进程中的步骤启动
    2. 如果您能够启动 ceph-osd 守护进程但已标记为 down,请按照 ceph-osd 守护进程中的步骤运行,但仍标记为"down"。

ceph-osd 守护进程无法启动

  1. 如果您的节点包含多个 OSD(通常超过 12 倍),请验证默认最多线程数(PID 数)是否足够。有关 详细信息,请参阅增加 PID 数
  2. 验证 OSD 数据和日志分区是否已正确挂载。您可以使用 ceph-volume lvm list 命令列出 与 Ceph 存储群集关联的所有设备和卷,然后手动检查它们是否已正确挂载。详情请查看 mount(8) 手册页。
  3. 如果您收到错误 的密钥环:缺少密钥环,无法使用 cephx 进行身份验证 错误消息,OSD 缺少密钥环。
  4. 如果您收到错误 ROR:无法对 /var/lib/ceph/osd/ceph-1 错误消息打开 OSD 超级块,ceph -osd 守护进程无法读取底层文件系统。有关如何排除故障并修复此错误的说明,请参阅以下步骤。

    注意

    如果在 OSD 主机引导期间返回此错误消息,请打开支持票据,因为这可能表示 在红帽 Bugzilla 1439210 中跟踪了一个已知问题。

  5. 检查对应的日志文件,以确定故障的原因。默认情况下,Ceph 将日志文件存储在裸机部署的 /var/log/ceph/ 目录中。

    注意

    对于基于容器的部署,Ceph 会生成日志到 journald。您可以通过在 Ceph 配置文件中 [global] 下将 log_to_file 参数设置为 true,以启用记录到 /var/log/ceph 中的文件。如需了解更多详细信息 ,请参阅了解 ceph 日志

    1. EIO 错误消息类似如下,表示底层磁盘失败:

      为修复此问题,请替换底层 OSD 磁盘。详情请参阅 替换 OSD 驱动器

    2. 如果日志包含任何其他 FAILED assert 错误,如以下错误,请打开支持票据。有关 详细信息,请参阅联系红帽支持团队

      FAILED assert(0 == "hit suicide timeout")
  6. 检查 dmesg 输出是否有底层文件系统或磁盘的错误:

    $ dmesg
    1. 如果 dmesg 输出包含任何 SCSI 错误错误消息,请参阅红帽客户门户网站中的 SCSI Error Codes Solution Finder 解决方案,以确定解决问题的最佳方法。
    2. 或者,如果您无法修复底层文件系统,请替换 OSD 驱动器。详情请参阅 替换 OSD 驱动器
  7. 如果 OSD 因分段错误而出现故障,如以下 OSD,请收集必要的信息并打开支持票据。有关 详细信息,请参阅联系红帽支持团队

    Caught signal (Segmentation fault)

ceph-osd 正在运行,但仍标记为 down

  1. 检查对应的日志文件,以确定故障的原因。默认情况下,Ceph 将日志文件存储在裸机部署的 /var/log/ceph/ 目录中。

    注意

    对于基于容器的部署,Ceph 会生成日志到 journald。您可以通过在 Ceph 配置文件中 [global] 下将 log_to_file 参数设置为 true,以启用记录到 /var/log/ceph 中的文件。如需了解更多详细信息 ,请参阅了解 ceph 日志

    1. 如果日志中包含类似于下文的错误消息,请参阅 Flapping OSD

      wrongly marked me down
      heartbeat_check: no reply from osd.2 since back
    2. 如果您看到任何其他错误,请打开支持票据。有关 详细信息,请参阅联系红帽支持团队

5.2.8. Flapping OSD

ceph -w | grep osds 命令显示 OSD 重复为 down,然后在短时间内 再次运行

# ceph -w | grep osds
2021-04-05 06:27:20.810535 mon.0 [INF] osdmap e609: 9 osds: 8 up, 9 in
2021-04-05 06:27:24.120611 mon.0 [INF] osdmap e611: 9 osds: 7 up, 9 in
2021-04-05 06:27:25.975622 mon.0 [INF] HEALTH_WARN; 118 pgs stale; 2/9 in osds are down
2021-04-05 06:27:27.489790 mon.0 [INF] osdmap e614: 9 osds: 6 up, 9 in
2021-04-05 06:27:36.540000 mon.0 [INF] osdmap e616: 9 osds: 7 up, 9 in
2021-04-05 06:27:39.681913 mon.0 [INF] osdmap e618: 9 osds: 8 up, 9 in
2021-04-05 06:27:43.269401 mon.0 [INF] osdmap e620: 9 osds: 9 up, 9 in
2021-04-05 06:27:54.884426 mon.0 [INF] osdmap e622: 9 osds: 8 up, 9 in
2021-04-05 06:27:57.398706 mon.0 [INF] osdmap e624: 9 osds: 7 up, 9 in
2021-04-05 06:27:59.669841 mon.0 [INF] osdmap e625: 9 osds: 6 up, 9 in
2021-04-05 06:28:07.043677 mon.0 [INF] osdmap e628: 9 osds: 7 up, 9 in
2021-04-05 06:28:10.512331 mon.0 [INF] osdmap e630: 9 osds: 8 up, 9 in
2021-04-05 06:28:12.670923 mon.0 [INF] osdmap e631: 9 osds: 9 up, 9 in

此外,Ceph 日志包含类似于以下的错误消息:

2021-07-25 03:44:06.510583 osd.50 127.0.0.1:6801/149046 18992 : cluster [WRN] map e600547 wrongly marked me down
2021-07-25 19:00:08.906864 7fa2a0033700 -1 osd.254 609110 heartbeat_check: no reply from osd.2 since back 2021-07-25 19:00:07.444113 front 2021-07-25 18:59:48.311935 (cutoff 2021-07-25 18:59:48.906862)

此 Means 是什么

引发 OSD 的主要原因是:

  • 某些存储集群操作(如清理或恢复)通常会花费大量时间,例如,如果您对具有大型索引或大型 PG 的对象执行这些操作。通常,在完成这些操作后,flapping OSD 问题会得到解决。
  • 与底层物理硬件相关的问题.在本例中,ceph 运行状况详细信息 命令也会返回 速度较慢的请求 错误消息。
  • 网络相关问题.

Ceph OSD 无法管理存储集群的专用网络出现故障的情况,或者显著延迟位于面向公共客户端的网络上。

Ceph OSD 使用专用网络 将 heartbeat 数据包互相发送,以注明它们是 up 和 in 。如果私有存储集群网络无法正常工作,OSD 无法发送和接收心跳数据包。因此,它们互相报告为 停机到 Ceph 监控器,同时将自身标记为 up

Ceph 配置文件中的以下参数会影响此行为:

参数描述默认值

osd_heartbeat_grace_time

OSD 等待 heartbeat 数据包返回多长时间,然后将 OSD 报告为 down 到 Ceph 监控器。

20 秒

mon_osd_min_down_reporters

在 Ceph 监控将该 OSD 标记为 down 之前,多少 OSD 必须报告另一个 OSD 为 down

2

此表显示,在默认配置中,Ceph 监控器将 OSD 标记为 down,只要只有一个 OSD 制作了三个不同的报告,其中的第一个 OSD 处于 down 状态。在某些情况下,如果单个主机遇到网络问题,整个群集可能会遇到 OSD 出现问题。这是因为主机上的 OSD 将报告集群中的其他 OSD 为 down

注意

Flanping OSD 方案不包括 OSD 进程启动时,然后立即终止的情况。

要排除这个问题,请执行以下操作

  1. 再次检查 ceph 运行状况详细信息 命令的输出。如果其中包含 较慢的请求 错误消息,请参阅 如何排除此问题。

    # ceph health detail
    HEALTH_WARN 30 requests are blocked > 32 sec; 3 osds have slow requests
    30 ops are blocked > 268435 sec
    1 ops are blocked > 268435 sec on osd.11
    1 ops are blocked > 268435 sec on osd.18
    28 ops are blocked > 268435 sec on osd.39
    3 osds have slow requests
  2. 确定哪些 OSD 标记为 down 以及它们所在的节点上:

    # ceph osd tree | grep down
  3. 在包含 flapping OSD 的节点上,对任何网络问题进行故障排除并修复。详情请参阅对 网络问题进行故障排除
  4. 或者,您可以通过设置 noup 和 no down 标记来临时强制监控器停止将 OSD 标记为 downup

    # ceph osd set noup
    # ceph osd set nodown
    重要

    使用 noupnodown 标志不会修复问题的根本原因,而是仅防止 OSD 崩溃。要打开 支持问题单,请参阅联系红帽支持团队部分以了解 详细信息。

重要

Ceph OSD 节点上、网络交换机级别上的 MTU 错误配置或两者可能会引起 Fpping OSD。要解决这个问题,请在所有存储集群节点上将 MTU 设置为统一大小,包括在核心上和通过计划停机访问网络交换机。不要调优 osd heartbeat min 大小,因为更改此设置可能会隐藏网络中的问题,也不会解决实际的网络不一致。

其它资源

5.2.9. 请求或请求速度慢

ceph-osd 守护进程较慢响应请求,ceph 运行状况详细信息 命令返回类似如下的错误消息:

HEALTH_WARN 30 requests are blocked > 32 sec; 3 osds have slow requests
30 ops are blocked > 268435 sec
1 ops are blocked > 268435 sec on osd.11
1 ops are blocked > 268435 sec on osd.18
28 ops are blocked > 268435 sec on osd.39
3 osds have slow requests

此外,Ceph 日志包含类似于以下的错误消息:

2015-08-24 13:18:10.024659 osd.1 127.0.0.1:6812/3032 9 : cluster [WRN] 6 slow requests, 6 included below; oldest blocked for > 61.758455 secs
2016-07-25 03:44:06.510583 osd.50 [WRN] slow request 30.005692 seconds old, received at {date-time}: osd_op(client.4240.0:8 benchmark_data_ceph-1_39426_object7 [write 0~4194304] 0.69848840) v4 currently waiting for subops from [610]

此 Means 是什么

请求速度较慢的 OSD 是每个无法在 osd_op_complaint_time 参数定义的时间内队列中每秒 I/O 操作(IOPS)服务的 OSD。默认情况下,此参数设置为 30 秒。

造成 OSD 缓慢请求的主要原因是:

  • 与底层硬件相关的问题,如磁盘驱动器、主机、机架或网络交换机
  • 网络相关问题.这些问题通常与闪烁的 OSD 连接。详情请参阅 Flapping OSD
  • 系统负载

下表显示了慢速请求的类型。使用 dump_historic_ops 管理 socket 命令来确定慢速请求的类型。有关管理套接字的详细信息,请参见《红帽 Ceph 存储 4 管理指南 》中的" 使用 Ceph 管理套接字 "一节。

请求类型慢描述

等待 rw 锁定

OSD 正在等待在 PG 上获取操作的锁定。

等待子操作

OSD 正在等待副本 OSD 将操作应用到日志。

未到达标记点

OSD 未达到任何主要操作里程碑。

等待降级对象

OSD 尚未复制指定次数的对象。

要排除这个问题,请执行以下操作

  1. 确定请求缓慢或块请求的 OSD 是否共享共同的硬件部分,如磁盘驱动器、主机、机架或网络交换机。
  2. 如果 OSD 共享磁盘:

    1. 使用 smartmontools 实用程序检查磁盘或日志的健康状况,以确定磁盘上的任何错误。

      注意

      smartmontools 程序包含在 smartmontools 软件包中。

    2. 使用 iostat 实用程序获取 OSD 磁盘上的 I/O 等待报告(%iowai),以确定磁盘是否负载过重。

      注意

      The iostat 实用程序包含在 sysstat 软件包中。

  3. 如果 OSD 与另一个服务共享节点:

    1. 检查 RAM 和 CPU 使用率
    2. 使用 netstat 实用程序查看网络接口控制器(NIC)上的网络统计信息,并对任何网络问题进行故障排除。如需更多信息,请参阅对 网络问题进行故障排除
  4. 如果 OSD 共享机架,请检查机架的网络交换机。例如,如果您使用巨型帧,请验证路径中的 NIC 是否已设置了巨型帧。
  5. 如果您无法确定请求速度较慢的 OSD 共享的硬件部分,或者无法对硬件和网络问题进行故障排除和修复,请打开支持票据。有关 详细信息,请参阅联系红帽支持团队

其它资源

5.3. 停止并启动重新平衡

当 OSD 出现故障或您停止时,CRUSH 算法会自动启动重新平衡过程,以在剩余的 OSD 之间重新分发数据。

因此,重新平衡可能需要时间和资源,因此,应考虑在故障排除期间停止重新平衡或维护 OSD。

注意

停止的 OSD 中的放置组在故障排除和维护期间变得 降级

先决条件

  • Ceph 监控节点的根级别访问权限.

流程

  1. 要做到这一点,在停止 OSD 前设置 noout 标志:

    [root@mon ~]# ceph osd set noout
  2. 完成故障排除或维护后,取消设置 noout 标志来 开始重新平衡:

    [root@mon ~]# ceph osd unset noout

其它资源

5.4. 挂载 OSD 数据分区

如果 OSD 数据分区没有正确挂载,ceph -osd 守护进程就无法启动。如果您发现分区没有按预期挂载,请按照本节中的步骤进行挂载。

本节只适用于裸机部署。

先决条件

  • 可以访问 ceph-osd 守护进程.
  • Ceph 监控节点的根级别访问权限.

流程

  1. 挂载分区:

    [root@ceph-mon]# mount -o noatime PARTITION /var/lib/ceph/osd/CLUSTER_NAME-OSD_NUMBER

    PARTITION 替换为专用于 OSD 数据的 OSD 驱动器上分区的路径。指定集群名称和 OSD 号。

    示例

    [root@ceph-mon]# mount -o noatime /dev/sdd1 /var/lib/ceph/osd/ceph-0

  2. 尝试启动失败的 ceph-osd 守护进程:

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

    OSD_NUMBER 替换为 OSD 的 ID。

    示例

    [root@ceph-mon]# systemctl start ceph-osd@0

其它资源

  • 如需了解更多详细信息,请参见《 红帽 Ceph 存储故障排除指南》 中的 故障 OSD

5.5. 替换 OSD 驱动器

Ceph 专为容错设计,这意味着它可以在 降级 状态下运行,而不丢失数据。因此,即使数据存储驱动器失败,Ceph 也能运行。在故障驱动器的上下文中,降级 状态意味着其他 OSD 上存储的数据的额外副本将自动回填到集群中的其他 OSD。不过,如果发生这种情况,请替换失败的 OSD 驱动器,并手动重新创建 OSD。

当驱动器出现故障时,Ceph 会将该 OSD 报告为 down

HEALTH_WARN 1/3 in osds are down
osd.0 is down since epoch 23, last address 192.168.106.220:6800/11080
注意

Ceph 也可以因为网络或权限问题将 OSD 标记为 down。详情请参阅 关闭 OSD

现代服务器通常使用热插拔驱动器进行部署,以便您可以将失败的驱动器替换为新的驱动器,而无需关闭节点。整个流程包括这些步骤:

  1. 从 Ceph 集群移除 OSD。详情请参阅 从 Ceph 集群删除 OSD 过程。
  2. 替换驱动器。详情请查看 替换物理驱动器 ]部分。
  3. 将 OSD 添加到集群。详情请参阅 在 Ceph 集群中添加 OSD 流程

先决条件

  • Ceph 监控节点的根级别访问权限.
  • 确定哪个 OSD 处于 down 状态

    [root@mon ~]# ceph osd tree | grep -i down
    ID WEIGHT  TYPE NAME      UP/DOWN REWEIGHT PRIMARY-AFFINITY
     0 0.00999         osd.0     down  1.00000          1.00000
  • 确保 OSD 进程已经停止。从 OSD 节点运行以下命令:

    [root@mon ~]# systemctl status ceph-osd@_OSD_NUMBER_
  • OSD_NUMBER 替换为标记为 down 的 OSD 的 ID,例如:

    [root@mon ~]# systemctl status ceph-osd@osd.0
    ...
       Active: inactive (dead)

    如果 ceph-osd 守护进程正在运行。如需有关 对标记为 down 的 OSD 进行故障排除但对应的 ceph-osd 守护进程正在运行的更多信息,请参阅 Down OSD。

步骤:从 Ceph 集群中删除 OSD

  1. 将 OSD 标记为 out

    [root@mon ~]# ceph osd out osd.OSD_NUMBER

    OSD_NUMBER 替换为标记为 down 的 OSD 的 ID,例如:

    [root@mon ~]# ceph osd out osd.0
    marked out osd.0.
    注意

    如果 OSD 为 down,Ceph 会在 600 秒后自动将其标记为 out,当它未从 OSD 接收任何心跳数据包时。发生这种情况时,具有故障 OSD 数据副本的其他 OSD 开始回填,以确保集群中存在所需的副本数。当集群回填时,集群将处于 降级 状态。

  2. 确保故障 OSD 正在回填。输出将包含类似如下的信息:

    [root@mon ~]# ceph -w | grep backfill
    2017-06-02 04:48:03.403872 mon.0 [INF] pgmap v10293282: 431 pgs: 1 active+undersized+degraded+remapped+backfilling, 28 active+undersized+degraded, 49 active+undersized+degraded+remapped+wait_backfill, 59 stale+active+clean, 294 active+clean; 72347 MB data, 101302 MB used, 1624 GB / 1722 GB avail; 227 kB/s rd, 1358 B/s wr, 12 op/s; 10626/35917 objects degraded (29.585%); 6757/35917 objects misplaced (18.813%); 63500 kB/s, 15 objects/s recovering
    2017-06-02 04:48:04.414397 mon.0 [INF] pgmap v10293283: 431 pgs: 2 active+undersized+degraded+remapped+backfilling, 75 active+undersized+degraded+remapped+wait_backfill, 59 stale+active+clean, 295 active+clean; 72347 MB data, 101398 MB used, 1623 GB / 1722 GB avail; 969 kB/s rd, 6778 B/s wr, 32 op/s; 10626/35917 objects degraded (29.585%); 10580/35917 objects misplaced (29.457%); 125 MB/s, 31 objects/s recovering
    2017-06-02 04:48:00.380063 osd.1 [INF] 0.6f starting backfill to osd.0 from (0'0,0'0] MAX to 2521'166639
    2017-06-02 04:48:00.380139 osd.1 [INF] 0.48 starting backfill to osd.0 from (0'0,0'0] MAX to 2513'43079
    2017-06-02 04:48:00.380260 osd.1 [INF] 0.d starting backfill to osd.0 from (0'0,0'0] MAX to 2513'136847
    2017-06-02 04:48:00.380849 osd.1 [INF] 0.71 starting backfill to osd.0 from (0'0,0'0] MAX to 2331'28496
    2017-06-02 04:48:00.381027 osd.1 [INF] 0.51 starting backfill to osd.0 from (0'0,0'0] MAX to 2513'87544
  3. 从 CRUSH map 移除 OSD:

    [root@mon ~]# ceph osd crush remove osd.OSD_NUMBER

    OSD_NUMBER 替换为标记为 down 的 OSD 的 ID,例如:

    [root@mon ~]# ceph osd crush remove osd.0
    removed item id 0 name 'osd.0' from crush map
  4. 移除与 OSD 相关的身份验证密钥:

    [root@mon ~]# ceph auth del osd.OSD_NUMBER

    OSD_NUMBER 替换为标记为 down 的 OSD 的 ID,例如:

    [root@mon ~]# ceph auth del osd.0
    updated
  5. 从 Ceph 存储集群中移除 OSD:

    [root@mon ~]# ceph osd rm osd.OSD_NUMBER

    OSD_NUMBER 替换为标记为 down 的 OSD 的 ID,例如:

    [root@mon ~]# ceph osd rm osd.0
    removed osd.0

    如果您已成功删除了 OSD,以下命令的输出中不存在它:

    [root@mon ~]# ceph osd tree
  6. 对于裸机部署,卸载失败的驱动器:

    [root@mon ~]# umount /var/lib/ceph/osd/CLUSTER_NAME-OSD_NUMBER

    指定集群的名称和 OSD 的 ID,例如:

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

    如果您成功卸载了驱动器,以下命令输出中不存在该驱动器:

    [root@mon ~]# df -h

步骤: 替换物理驱动器

有关替换物理驱动器的详情,请查看硬件节点的文档。

  1. 如果驱动器热插拔,请将失败的驱动器替换为新驱动器。
  2. 如果驱动器不可热插拔并且节点包含多个 OSD,您可能需要关闭整个节点并替换物理驱动器。考虑阻止集群回填。详情请参阅 红帽 Ceph 存储故障排除指南 中的 停止和启动重新平衡 章节。
  3. 当驱动器显示在 /dev/ 目录下时,记下驱动器路径。
  4. 如果要手动添加 OSD,找到 OSD 驱动器并格式化磁盘。

步骤:将 OSD 添加到 Ceph 集群

  1. 再次添加 OSD。

    1. 如果您使用 Ansible 部署集群,请从 Ceph 管理服务器再次运行 ceph-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. 如果您手动添加 OSD,请参阅红帽 Ceph 存储 4 操作指南中的使用命令行界面添加 Ceph OSD 部分。
  2. 确保 CRUSH 层次结构准确:

    [root@mon ~]# ceph osd tree
  3. 如果您对 CRUSH 层次结构中的 OSD 的位置不满意,请将 OSD 移到所需的位置:

    [root@mon ~]# ceph osd crush move BUCKET_TO_MOVE BUCKET_TYPE=PARENT_BUCKET

    例如,将位于 sdd:row1 的存储桶移动到 root 存储桶:

    [root@mon ~]# ceph osd crush move ssd:row1 root=ssd:root

其它资源

5.6. 增加 PID 数量

如果您的节点包含 12 个 Ceph OSD,默认的最大线程数(PID 数)可能不足,特别是在恢复期间。因此,一些 ceph-osd 守护进程可能会终止并且无法再次启动。如果发生这种情况,增加允许的最大线程数。

流程

临时增加这个数字:

[root@mon ~]# sysctl -w kernel.pid.max=4194303

要永久增加这个数字,请更新 /etc/sysctl.conf 文件,如下所示:

kernel.pid.max = 4194303

5.7. 从完整存储集群中删除数据

Ceph 自动防止 OSD 上的任何 I/O 操作达到 mon_osd_full_ratio 参数指定的容量,并且返回 完整的 osds 错误消息。

这个步骤演示了如何删除不必要的数据来修复这个错误。

注意

mon_osd_full_ratio 参数设置创建集群时 full_ratio 参数的值。之后您无法更改 mon_osd_full_ratio 的值。要临时增加 full_ratio 值,请改为增加 set-full-ratio

先决条件

  • Ceph 监控节点的根级别访问权限.

流程

  1. 确定 full_ratio 的当前值,默认设为 0.95

    [root@mon ~]# ceph osd dump | grep -i full
    full_ratio 0.95
  2. set-full-ratio 的值临时增加到 0.97

    [root@mon ~]# ceph osd set-full-ratio 0.97
    重要

    红帽强烈建议不要将 set-full-ratio 设置为大于 0.97。将此参数设置为更高的值会使恢复过程变得更加困难。因此,您可能根本无法恢复完整的 OSD。

  3. 验证您是否成功将该参数设置为 0.97

    [root@mon ~]# ceph osd dump | grep -i full
    full_ratio 0.97
  4. 监控集群状态:

    [root@mon ~]# ceph -w

    旦集群将状态从 full 更改为 nearfull,请 删除任何不必要的数据。

  5. full_ratio 的 值设置为 0.95

    [root@mon ~]# ceph osd set-full-ratio 0.95
  6. 验证您是否成功将该参数设置为 0.9 5:

    [root@mon ~]# ceph osd dump | grep -i full
    full_ratio 0.95

其它资源

  • 红帽 Ceph 存储故障排除指南中 的完整 OSD 部分.
  • 红帽 Ceph 存储故障排除指南 》中的 nearfull OSD 部分.

5.8. 升级存储集群后重新部署 OSD

本节介绍了在从 Red Hat Ceph Storage 3 升级到 Red Hat Ceph Storage 4 后,如何在专用设备上使用 block.db 的 OSD,使用 block.db 来重新部署 OSD,而无需升级操作系统。

除非另有指定,否则此流程适用于裸机和容器部署。

升级后,重新部署 OSD 的 playbook 可能会失败,并显示出错信息:

GPT headers found, they must be removed on: /dev/vdb

您可以通过在 block.db 设备中创建分区并运行 Ansible playbook 来重新部署 OSD。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • Ansible 管理节点的 root 级别访问权限。
  • Ansible 用户帐户已创建。

流程

  1. block.db 设备上创建分区。这个 sgdisk 命令自动使用下一个可用分区号:

    语法

    sgdisk --new=0:0:_JOURNAL_SIZE_ -- NEW_DEVICE_PATH

    示例

    [root@admin ~]# sgdisk --new=0:0:+2G -- /dev/vdb

  2. 创建 host_vars 目录:

    [root@admin ~]# mkdir /usr/share/ceph-ansible/host_vars
  3. 进入 host_vars 目录:

    [root@admin ~]# cd /usr/share/ceph-ansible/host_vars
  4. 在存储集群的所有主机上创建 hosts 文件:

    语法

    touch NEW_OSD_HOST_NAME

    示例

    [root@admin host_vars]# touch osd5

  5. 在 hosts 文件中定义数据设备:

    语法

    lvm_volumes:
    - data: DATA_DEVICE_PATH
      journal: NEW_DEVICE_PARTITION_PATH
    - data: RUNNING_OSD_DATA_DEVICE_PATH
        journal: PARTITION_PATH
    - data: RUNNING_OSD_DATA_DEVICE_PATH
        journal: PARTITION_PATH

    示例

    lvm_volumes:
    - data: /dev/vdd
      journal: /dev/vdb2
    - data: /dev/sdb
      journal: /dev/sdc1
    - data: /dev/sdb
      journal: /dev/sdc2

  6. 切换到 Ansible 用户,验证 Ansible 能否访问所有 Ceph 节点:

    [admin@admin ~]$ ansible all -m ping
  7. 将目录改为 Ansible 配置目录:

    [admin@admin ~]$ cd /usr/share/ceph-ansible
  8. 使用 --limit 选项运行以下 Ansible playbook:

    • 裸机部署:

      [admin@admin ceph-ansible]$ ansible-playbook site.yml --limit osds -i hosts
    • 容器部署:

      [admin@admin ceph-ansible]$ ansible-playbook site-container.yml --limit osds -i hosts

其它资源

第 6 章 Ceph MDS 故障排除

作为存储管理员,您可以使用 Ceph 元数据服务器(MDS)对最常见的问题进行故障排除。您可能会遇到的一些常见错误:

  • 需要新的 MDS 部署的 MDS 节点失败。
  • 需要重新部署 MDS 节点的问题。

6.1. 重新部署 Ceph MDS

在部署 Ceph 文件系统时,需要 Ceph 元数据服务器(MDS)守护进程。如果集群中的 MDS 节点失败,您可以通过删除 MDS 服务器并添加新的或现有服务器来重新部署 Ceph 元数据服务器。您可以使用命令行界面或 Ansible playbook 来添加或删除 MDS 服务器。

6.1.1. 先决条件

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

6.1.2. 使用 Ansible 删除 Ceph MDS

要使用 Ansible 移除 Ceph 元数据服务器(MDS),请使用 shrink-mds playbook。

注意

如果 MDS 被删除后,如果没有替换 MDS,文件系统将无法供客户端使用。如果不需要,请考虑在删除 MDS 前添加额外的 MDS 来离线。

先决条件

  • 至少一个 MDS 节点。
  • 由 Ansible 部署运行的 Red Hat Ceph Storage 集群。
  • 对 Ansible 管理节点的 rootsudo 访问权限。

流程

  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]]

其它资源

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

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

注意

如果没有在删除当前 MDS 后进行替换 MDS,则文件系统将无法供客户端使用。如果不需要,请考虑在删除现有 MDS 前添加 MDS。

先决条件

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

流程

  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]]

其它资源

6.1.4. 使用 Ansible 添加 Ceph MDS

使用 Ansible playbook 添加 Ceph 元数据服务器(MDS)。

先决条件

  • 由 Ansible 部署运行的 Red Hat Ceph Storage 集群。
  • 对 Ansible 管理节点的 rootsudo 访问权限。
  • 可以调配为 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] 部分添加同一节点来将 MDS 守护进程与一个节点上的 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 是否处于活跃状态:

    语法

    ceph mds stat

    示例

    [ansible@admin ceph-ansible]$ ceph mds stat
    cephfs:1 {0=node01=up:active} 1 up:standby

其它资源

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

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

先决条件

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

流程

  1. 通过登录到节点并创建 MDS 挂载点,添加新 MDS 节点:

    语法

    sudo mkdir /var/lib/ceph/mds/ceph-MDS_ID

    使用您要添加 MDS 守护进程的 MDS 节点 ID 替换 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 是否处于活跃状态:

    语法

    ceph mds stat

    示例

    [ansible@admin ceph-ansible]$ ceph mds stat
    cephfs:1 {0=node01=up:active} 1 up:standby

其它资源

第 7 章 多站点 Ceph 对象网关故障排除

本章包含有关如何修复与多站点 Ceph 对象网关配置和运营条件相关的最常见错误的信息。

7.1. 先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 正在运行的 Ceph 对象网关.

7.2. Ceph 对象网关的代码定义错误

Ceph 对象网关日志包含错误和警告消息,以协助对环境中条件进行故障排除。下面列出了一些常见的解决方案,并给出了建议的解决方案。

常见错误消息

data_sync: ERROR:同步操作返回错误
这是提示较低级别 bucket 同步进程返回错误的高级别数据同步过程。此消息冗余;存储桶同步错误出现在日志中。
数据同步:ERROR: 无法同步对象: BUCKET_NAME: _OBJECT_NAME_
进程无法通过 HTTP 从远程网关获取所需的对象,或者进程无法将该对象写入 RADOS,还会重试。
数据同步:ERROR:同步失败,退出(sync_status=2)
低级别消息反映上述条件之一,特别是数据已被删除,然后才能进行同步,从而显示 -2 ENOENT 状态。
数据同步:ERROR:同步失败,退出(sync_status=-5)
反映了上述条件之一的低级别消息,特别是我们未能将该对象写入 RADOS,因此显示 -5 EIO
ERROR:获取远程数据日志信息失败:ret=11
这是来自 libcurl 的 EAGAIN 通用错误代码,反映来自另一个网关的错误条件。默认情况下,它将重试。
meta sync: ERROR: 无法读取带有(2)No such file or directory 的 mdlog info
mdlog 的分片从未创建,因此无法同步。

同步错误消息

同步对象失败
进程无法通过 HTTP 从远程网关获取此对象,或者未能将该对象写入 RADOS,还会重试。
同步存储桶实例失败:(11)资源暂时不可用
主要和次要区域之间的连接问题。
同步存储桶实例失败:(125)操作取消
对同一 RADOS 对象的写入之间存在一个跟踪条件。

其它资源

7.3. 同步多站点 Ceph 对象网关

多站点同步从其它区域读取更改日志。要从元数据和数据 loags 中获取同步进度的高级视图,您可以使用以下命令:

radosgw-admin sync status

此命令列出源区域后面的日志分片(若有)。

注意

有时,您可能会在运行 radosgw-admin sync status 命令时观察恢复分片。对于数据同步,每个副本日志都有 128 个分片,它们各自独立处理。如果这些复制日志事件触发的任何操作导致来自网络、存储或其他位置出现任何错误,则会跟踪这些错误,以便稍后重试操作。虽然给定的分片具有需要重试的错误,但 radosgw-admin sync status 命令会报告该分片作为 恢复。这个恢复会自动发生,因此操作员不需要干预来解决它们。

如果以上运行的同步状态的结果返回日志分片,请运行以下命令来替换 X 的 shard-id。

语法

radosgw-admin data sync status --shard-id=X --source-zone=ZONE_NAME

示例

[root@rgw ~]# radosgw-admin data sync status --shard-id=27 --source-zone=_us-eest
{
  "shard_id": 27,
  "marker": {
         "status": "incremental-sync",
         "marker": "1_1534494893.816775_131867195.1",
         "next_step_marker": "",
         "total_entries": 1,
         "pos": 0,
         "timestamp": "0.000000"
   },
   "pending_buckets": [],
   "recovering_buckets": [
         "pro-registry:4ed07bb2-a80b-4c69-aa15-fdc17ae6f5f2.314303.1:26"
   ]
}

输出列出了同步旁边的存储桶,以及会因为前面的错误而重试哪些存储桶(若有)。

通过以下命令检查各个 bucket 的状态,将 bucket ID 替换为 X

radosgw-admin bucket sync status --bucket=X.
replace…​
X,具有存储桶的 ID 号。

结果显示哪些存储桶索引日志分片位于其源区后面。

同步中的一个常见错误是 EBUSY,这意味着同步已在进行中,通常在另一个网关上。读取写入到同步错误日志的错误,可以使用以下命令进行读取:

radosgw-admin sync error list

同步过程将重试,直到成功为止。错误仍可能发生,可能需要干预。

7.3.1. 多站点 Ceph 对象网关数据同步的性能计数器

以下性能计数器可用于 Ceph 对象网关的多站点配置来测量数据同步:

  • poll_latency 测量远程复制日志的请求延迟。
  • fetch_bytes 测量数据同步获取的对象数和字节数。

使用 ceph daemon 命令查看性能计数器的当前指标数据:

语法

ceph daemon /var/run/ceph/ceph-client.rgw.RGW_ID.asok perf dump data-sync-from-ZONE_NAME

示例

[root@rgw ~]#  ceph daemon /var/run/ceph/ceph-client.rgw.host02-rgw0.103.94309060818504.asok perf dump data-sync-from-us-west

{
    "data-sync-from-us-west": {
        "fetch bytes": {
            "avgcount": 54,
            "sum": 54526039885
        },
        "fetch not modified": 7,
        "fetch errors": 0,
        "poll latency": {
            "avgcount": 41,
            "sum": 2.533653367,
            "avgtime": 0.061796423
        },
        "poll errors": 0
    }
}

注意

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

其它资源

  • 有关 性能计数器 的更多信息,请参见《 红帽 Ceph 存储管理指南》 中的 Ceph 性能计数器一章。

第 8 章 对 Ceph iSCSI 网关(有限的可用性)进行故障排除

作为存储管理员,您可以对使用 Ceph iSCSI 网关时可能出现的大多数常见错误进行故障排除。以下是您可能遇到的一些常见错误:

  • iSCSI 登录问题.
  • VMware ESXi 报告各种连接失败。
  • 超时错误.
注意

该技术是有限可用性。如需更多信息,请参阅 已弃用的功能 章节。

8.1. 先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 正在运行的 Ceph iSCSI 网关。
  • 验证网络连接。

8.2. 为丢失的连接收集信息会导致 VMware ESXi 上的存储失败

收集系统和磁盘信息有助于确定哪些 iSCSI 目标丢失连接,并可能导致存储失败。如果需要,还可以向红帽全球支持服务提供收集这些信息,以帮助您对任何 Ceph iSCSI 网关问题进行故障排除。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 正在运行的 Ceph iSCSI 网关,即 iSCSI 目标。
  • 正在运行的 VMware ESXi 环境,即 iSCSI 启动器。
  • 对 VMware ESXi 节点的根级别访问权限.

流程

  1. 在 VWware ESXi 节点上打开内核日志:

    [root@esx:~]# more /var/log/vmkernel.log
  2. 从 VMware ESXi 内核日志中的以下错误消息收集信息:

    示例

    2020-03-30T11:07:07.570Z cpu32:66506)iscsi_vmk:
    iscsivmk_ConnRxNotifyFailure: Sess [ISID: 00023d000005 TARGET:
    iqn.2017-12.com.redhat.iscsi-gw:ceph-igw TPGT: 3 TSIH: 0]

    在此消息中,记录 ISID 号、TARGET 名称和 Target Portal Group Tag(TPGT)号。在本例中,我们有以下内容:

    ISID: 00023d000005
    TARGET: iqn.2017-12.com.redhat.iscsi-gw:ceph-igw
    TPGT: 3

    示例

    2020-03-30T11:07:07.570Z cpu32:66506)iscsi_vmk:
    iscsivmk_ConnRxNotifyFailure: vmhba64:CH:4 T:0 CN:0: Connection rx
    notifying failure: Failed to Receive. State=Bound

    在此信息中记录适配器频道(CH)号。在本例中,我们有以下内容:

    vmhba64:CH:4 T:0
  3. 查找 Ceph iSCSI 网关节点的远程地址:

    [root@esx:~]# esxcli iscsi session connection list

    示例

    ...
    vmhba64,iqn.2017-12.com.redhat.iscsi-gw:ceph-igw,00023d000003,0
       Adapter: vmhba64
       Target: iqn.2017-12.com.redhat.iscsi-gw:ceph-igw 1
       ISID: 00023d000003 2
       CID: 0
       DataDigest: NONE
       HeaderDigest: NONE
       IFMarker: false
       IFMarkerInterval: 0
       MaxRecvDataSegmentLength: 131072
       MaxTransmitDataSegmentLength: 262144
       OFMarker: false
       OFMarkerInterval: 0
       ConnectionAddress: 10.2.132.2
       RemoteAddress: 10.2.132.2 3
       LocalAddress: 10.2.128.77
       SessionCreateTime: 03/28/18 21:45:19
       ConnectionCreateTime: 03/28/18 21:45:19
       ConnectionStartTime: 03/28/18 21:45:19
       State: xpt_wait
    ...

    从命令输出中,匹配 ISID 值和前面收集的 TARGET 名称值,然后记下 RemoteAddress 值。在这个示例中,我们有以下内容:

    Target: iqn.2017-12.com.redhat.iscsi-gw:ceph-igw
    ISID: 00023d000003
    RemoteAddress: 10.2.132.2

    现在,您可以从 Ceph iSCSI 网关节点收集更多信息,以进一步排除此问题。

    1. RemoteAddress 值提及的 Ceph iSCSI 网关节点上,运行 sosreport 来收集系统信息:

      [root@igw ~]# sosreport
  4. 查找进入死状态的磁盘:

    [root@esx:~]# esxcli storage nmp device list

    示例

    ...
    iqn.1998-01.com.vmware:d04-nmgjd-pa-zyc-sv039-rh2288h-xnh-732d78fd-00023d000004,iqn.2017-12.com.redhat.iscsi-gw:ceph-igw,t,3-naa.60014054a5d46697f85498e9a257567c
       Runtime Name: vmhba64:C4:T0:L4 1
       Device: naa.60014054a5d46697f85498e9a257567c 2
       Device Display Name: LIO-ORG iSCSI Disk
    (naa.60014054a5d46697f85498e9a257567c)
       Group State: dead 3
       Array Priority: 0
       Storage Array Type Path Config:
    {TPG_id=3,TPG_state=ANO,RTP_id=3,RTP_health=DOWN} 4
       Path Selection Policy Path Config: {non-current path; rank: 0}
    ...

    从命令输出中,与 CH 号和前面收集的 TPGT 编号匹配,然后记下 Device 值。在本例中,我们有以下内容:

    vmhba64:C4:T0
    Device: naa.60014054a5d46697f85498e9a257567c
    TPG_id=3

    使用设备名称时,您可以收集处于 状态的每个 iSCSI 磁盘的一些附加信息。

    1. 收集 iSCSI 磁盘的更多信息:

      语法

      esxcli storage nmp path list -d ISCSI_DISK_DEVICE > /tmp/esxcli_storage_nmp_path_list.txt
      esxcli storage core device list -d ISCSI_DISK_DEVICE > /tmp/esxcli_storage_core_device_list.txt

      示例

      [root@esx:~]# esxcli storage nmp path list -d naa.60014054a5d46697f85498e9a257567c > /tmp/esxcli_storage_nmp_path_list.txt
      [root@esx:~]# esxcli storage core device list -d naa.60014054a5d46697f85498e9a257567c > /tmp/esxcli_storage_core_device_list.txt

  5. 收集 VMware ESXi 环境的其他信息:

    [root@esx:~]# esxcli storage vmfs extent list > /tmp/esxcli_storage_vmfs_extent_list.txt
    [root@esx:~]# esxcli storage filesystem list > /tmp/esxcli_storage_filesystem_list.txt
    [root@esx:~]# esxcli iscsi session list > /tmp/esxcli_iscsi_session_list.txt
    [root@esx:~]# esxcli iscsi session connection list > /tmp/esxcli_iscsi_session_connection_list.txt
  6. 检查潜在的 iSCSI 登录问题:

其它资源

8.3. 检查 iSCSI 登录失败,因为未发送数据

在 iSCSI 网关节点上,您可能会在系统日志中看到通用的登录协商失败消息,默认为 /var/log/messages

示例

Apr  2 23:17:05 osd1 kernel: rx_data returned 0, expecting 48.
Apr  2 23:17:05 osd1 kernel: iSCSI Login negotiation failed.

虽然系统处于此状态,但请按照此流程中的建议开始收集系统信息。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 正在运行的 Ceph iSCSI 网关,即 iSCSI 目标。
  • 正在运行的 VMware ESXi 环境,即 iSCSI 启动器。
  • 对 Ceph iSCSI 网关节点的 root 级别访问权限。
  • 对 VMware ESXi 节点的根级别访问权限.

流程

  1. 启用附加日志记录:

    [root@igw ~]# echo "module iscsi_target_mod +p" > /sys/kernel/debug/dynamic_debug/control
    [root@igw ~]# echo "module target_core_mod +p" > /sys/kernel/debug/dynamic_debug/control
  2. 等待几分钟,以便额外的调试信息填充系统日志。
  3. 禁用附加日志:

    [root@igw ~]# echo "module iscsi_target_mod -p" > /sys/kernel/debug/dynamic_debug/control
    [root@igw ~]# echo "module target_core_mod -p" > /sys/kernel/debug/dynamic_debug/control
  4. 运行 sosreport 来收集系统信息:

    [root@igw ~]# sosreport
  5. 同时捕获 Ceph iSCSI 网关和 VMware ESXi 节点的网络流量:

    语法

    tcpdump -s0 -i NETWORK_INTERFACE -w OUTPUT_FILE_PATH

    示例

    [root@igw ~]# tcpdump -s 0 -i eth0 -w /tmp/igw-eth0-tcpdump.pcap

    注意

    查找端口 3260 上的流量。

    1. 网络数据包捕获文件可能较大,因此在将任何文件上传到 Red Hat 全球支持服务前,压缩来自 iSCSI 目标和启动器的 tcpdump 输出:

      语法

      gzip OUTPUT_FILE_PATH

      示例

      [root@igw ~]# gzip /tmp/igw-eth0-tcpdump.pcap

  6. 收集 VMware ESXi 环境的其他信息:

    [root@esx:~]# esxcli iscsi session list > /tmp/esxcli_iscsi_session_list.txt
    [root@esx:~]# esxcli iscsi session connection list > /tmp/esxcli_iscsi_session_connection_list.txt
    1. 列出并收集每个 iSCSI 磁盘的更多信息:

      语法

      esxcli storage nmp path list -d ISCSI_DISK_DEVICE > /tmp/esxcli_storage_nmp_path_list.txt

      示例

      [root@esx:~]# esxcli storage nmp device list
      [root@esx:~]# esxcli storage nmp path list -d naa.60014054a5d46697f85498e9a257567c > /tmp/esxcli_storage_nmp_path_list.txt
      [root@esx:~]# esxcli storage core device list -d naa.60014054a5d46697f85498e9a257567c > /tmp/esxcli_storage_core_device_list.txt

其它资源

8.4. 检查 iSCSI 登录失败,因为超时或无法找到门户组

在 iSCSI 网关节点上,您可能会看到超时,或者无法在系统日志中找到目标门户组消息,默认为 /var/log/messages

示例

Mar 28 00:29:01 osd2 kernel: iSCSI Login timeout on Network Portal 10.2.132.2:3260

示例

Mar 23 20:25:39 osd1 kernel: Unable to locate Target Portal Group on iqn.2017-12.com.redhat.iscsi-gw:ceph-igw

虽然系统处于此状态,但请按照此流程中的建议开始收集系统信息。

先决条件

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

流程

  1. 启用等待任务转储,并将其写入文件中:

    [root@igw ~]# dmesg -c ; echo w > /proc/sysrq-trigger ; dmesg -c > /tmp/waiting-tasks.txt
  2. 查看等待以下消息的任务列表:

    • iscsit_tpg_disable_portal_group
    • core_tmr_abort_task
    • transport_generic_free_cmd

    如果这些消息显示在等待的任务列表中,则表示 tcmu-runner 服务出现了某种错误。或许 tcmu-runner 服务没有正确重启,或者 tcmu-runner 服务已崩溃。

  3. 验证 tcmu-runner 服务是否正在运行:

    [root@igw ~]# systemctl status tcmu-runner
    1. 如果 tcmu-runner 服务没有运行,则重启 tcmu -runner 服务前停止 rbd-target- gw 服务:

      [root@igw ~]# systemctl stop rbd-target-api
      [root@igw ~]# systemctl stop rbd-target-gw
      [root@igw ~]# systemctl stop tcmu-runner
      [root@igw ~]# systemctl start tcmu-runner
      [root@igw ~]# systemctl start rbd-target-gw
      [root@igw ~]# systemctl start rbd-target-api
      重要

      首先停止 Ceph iSCSI 网关可防止 IO 在 tcmu-runner 服务停机时卡住。

    2. 如果 tcmu-runner 服务正在运行,这可能是一个新程序错误。创建一个新的红帽支持问题单。

其它资源

8.5. timeout 命令错误

当 SCSI 命令在系统日志中失败时,Ceph iSCSI 网关可能会报告命令超时错误。

示例

Mar 23 20:03:14 igw tcmu-runner: 2018-03-23 20:03:14.052 2513 [ERROR] tcmu_rbd_handle_timedout_cmd:669 rbd/rbd.gw1lun011: Timing out cmd.

示例

Mar 23 20:03:14 igw tcmu-runner: tcmu_notify_conn_lost:176 rbd/rbd.gw1lun011: Handler connection lost (lock state 1)

此 Means 是什么

其他阻塞的任务可能要等待处理,从而导致 SCSI 命令超时,因为未及时收到响应。这些错误消息的另一个原因可能与不健康的红帽 Ceph 存储集群相关。

要排除这个问题,请执行以下操作

  1. 检查是否有可能在等待的任务中可能要处理一些事情。
  2. 检查红帽 Ceph 存储集群的运行状况。
  3. 从路径中的每个设备从 Ceph iSCSI 网关节点到 iSCSI 启动器节点收集系统信息。

其它资源

8.6. Abort 任务错误

Ceph iSCSI 网关可能会在系统日志中报告中止的任务错误。

示例

Apr  1 14:23:58 igw kernel: ABORT_TASK: Found referenced iSCSI task_tag: 1085531

此 Means 是什么

些其他网络中断(如交换机失败或端口错误)可能会导致这种类型的错误消息。另一种可能是不健康的红帽 Ceph 存储集群。

要排除这个问题,请执行以下操作

  1. 检查环境中是否存在网络中断。
  2. 检查红帽 Ceph 存储集群的运行状况。
  3. 从路径中的每个设备从 Ceph iSCSI 网关节点到 iSCSI 启动器节点收集系统信息。

其它资源

8.7. 其它资源

第 9 章 Ceph 放置组故障排除

本节介绍修复与 Ceph 放置组(PG)相关的最常见错误。

9.1. 先决条件

  • 验证您的网络连接。
  • 确保 monitor 能够形成仲裁。
  • 确保所有健康的 OSD 都已启动和进入 并且回填和恢复过程已完成。

9.2. 大多数常见的 Ceph 放置组错误

下表列出了 ceph 运行状况详细信息 命令返回的最常见错误消息。下表提供了解释错误并指向解决问题的具体步骤的对应部分的链接。

另外,您可以列出处于非最佳状态的放置组。详情请查看 第 9.3 节 “列出 PG 停留在 staleinactiveunclean 状态”

9.2.1. 先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 正在运行的 Ceph 对象网关.

9.2.2. 放置组错误消息

常见放置组错误消息和可能的修复表。

错误消息请查看

HEALTH_ERR

pgs down

放置组 停机

pgs inconsistent

不一致的 PG

清理错误

不一致的 PG

HEALTH_WARN

pgs stale

过时 PG

未找到

未找到的对象

9.2.3. 过时 PG

ceph health 命令将一些放置组(PG)列为 过时的

HEALTH_WARN 24 pgs stale; 3/300 in osds are down

此 Means 是什么

当 PG 的 Primary OSD 未收到 PG 执行集的 Primary OSD 或其他 OSD 报告Primary OSD 已 停机 时,monitor 会将其标记为 stale

通常,PG 在启动存储集群后,并在 peering 进程完成前进入 过时的 状态。不过,如果 PG 保留 过时的 时间超过预期,这可能表示这些 PG 的 Primary OSD 已 停机 或未向 monitor 报告 PG 统计信息。当存储 过时 PG 的 Primary OSD 备份 后,Ceph 会开始恢复 PG。

mon_osd_report_timeout 设置确定 OSD 将 PG 统计数据报告到 monitor 的频率。默认情况下,此参数设为 0.5,这表示 OSD 每半秒报告一次统计信息。

要排除这个问题,请执行以下操作

  1. 确定哪些 PG 是 过时的,以及它们存储在哪些 OSD 上。错误消息将包含类似以下示例的信息:

    示例

    # ceph health detail
    HEALTH_WARN 24 pgs stale; 3/300 in osds are down
    ...
    pg 2.5 is stuck stale+active+remapped, last acting [2,0]
    ...
    osd.10 is down since epoch 23, last address 192.168.106.220:6800/11080
    osd.11 is down since epoch 13, last address 192.168.106.220:6803/11539
    osd.12 is down since epoch 24, last address 192.168.106.220:6806/11861

  2. 对标记为 down 的 OSD 的任何问题进行故障排除。详情请参阅 关闭 OSD

其它资源

9.2.4. 不一致的 PG

有些放置组被标记为 活跃 + clean + 不一致,ceph 运行状况详细信息 返回类似如下的错误消息:

HEALTH_ERR 1 pgs inconsistent; 2 scrub errors
pg 0.6 is active+clean+inconsistent, acting [0,1,2]
2 scrub errors

此 Means 是什么

当 Ceph 检测到 PG 中一个或多个对象副本中的不一致时,它会将该 PG 标记为 不一致。最常见的不一致是:

  • 对象的大小不正确。
  • 恢复完成后,一个副本中的对象会丢失。

在大多数情况下,清理过程中的错误会导致 PG 中不一致。

要排除这个问题,请执行以下操作

  1. 确定哪个 PG 处于 不一致 状态:

    # ceph health detail
    HEALTH_ERR 1 pgs inconsistent; 2 scrub errors
    pg 0.6 is active+clean+inconsistent, acting [0,1,2]
    2 scrub errors
  2. 确定 PG 不一致 的原因。

    1. 在 PG 中启动深度清理过程:

      [root@mon ~]# ceph pg deep-scrub ID

      使用 不一致的 PG 的 ID 替换 ID,例如:

      [root@mon ~]# ceph pg deep-scrub 0.6
      instructing pg 0.6 on osd.0 to deep-scrub
    2. 搜索 ceph -w 的输出,以查找与该放置组相关的任何消息:

      ceph -w | grep ID

      使用 不一致的 PG 的 ID 替换 ID,例如:

      [root@mon ~]# ceph -w | grep 0.6
      2015-02-26 01:35:36.778215 osd.106 [ERR] 0.6 deep-scrub stat mismatch, got 636/635 objects, 0/0 clones, 0/0 dirty, 0/0 omap, 0/0 hit_set_archive, 0/0 whiteouts, 1855455/1854371 bytes.
      2015-02-26 01:35:36.788334 osd.106 [ERR] 0.6 deep-scrub 1 errors
  3. 如果输出包含与以下类似的错误消息,您可以修复 不一致的 PG。详情请参阅 修复不一致的 PG

    PG.ID shard OSD: soid OBJECT missing attr , missing attr _ATTRIBUTE_TYPE
    PG.ID shard OSD: soid OBJECT digest 0 != known digest DIGEST, size 0 != known size SIZE
    PG.ID shard OSD: soid OBJECT size 0 != known size SIZE
    PG.ID deep-scrub stat mismatch, got MISMATCH
    PG.ID shard OSD: soid OBJECT candidate had a read error, digest 0 != known digest DIGEST
  4. 如果输出包含与以下类似的错误消息,则无法安全地修复 不一致的 PG,因为您可以丢失数据。在这种情况下创建一个支持问题单。有关详细信息,请参阅 联系红帽支持

    PG.ID shard OSD: soid OBJECT digest DIGEST != known digest DIGEST
    PG.ID shard OSD: soid OBJECT omap_digest DIGEST != known omap_digest DIGEST

其它资源

9.2.5. unclean PG

ceph health 命令返回类似如下的错误消息:

HEALTH_WARN 197 pgs stuck unclean

此 Means 是什么

如果 PG 未在 Ceph 配置文件中的 mon_pg_stuck_threshold 参数中指定的秒数达到 active+clean 状态,则 Ceph 会将其标记为 uncleanmon_pg_stuck_threshold 的默认值为 300 秒。

如果 PG 不清除,它将包含没有复制 osd_pool_default_size 参数中指定的次数的对象。osd_pool_default_size 的默认值为 3,这意味着 Ceph 创建三个副本。

通常, 清理 PG 表示某些 OSD 可能已 停机

要排除这个问题,请执行以下操作

  1. 确定哪些 OSD 已 停机

    # ceph osd tree
  2. 对 OSD 进行故障排除和修复任何问题。详情请参阅 关闭 OSD

9.2.6. 不活跃的放置组

ceph health 命令返回类似如下的错误消息:

HEALTH_WARN 197 pgs stuck inactive

此 Means 是什么

如果 PG 在 Ceph 配置文件中的 mon_pg_stuck_threshold 参数中指定的秒数中未激活,Ceph 会将它标记为不活动。mon_pg_stuck_threshold 的默认值为 300 秒。

通常,不活跃的 PG 表示一些 OSD 可能已 停机

要排除这个问题,请执行以下操作

  1. 确定哪些 OSD 已 停机

    # ceph osd tree
  2. 对 OSD 进行故障排除和修复任何问题。

9.2.7. 放置组停机

ceph 运行状况详细信息 命令报告某些 PG 已 停机

HEALTH_ERR 7 pgs degraded; 12 pgs down; 12 pgs peering; 1 pgs recovering; 6 pgs stuck unclean; 114/3300 degraded (3.455%); 1/3 in osds are down
...
pg 0.5 is down+peering
pg 1.4 is down+peering
...
osd.1 is down since epoch 69, last address 192.168.106.220:6801/8651

此 Means 是什么

在某些情况下,peering 进程会被阻止,这会阻止放置组变得活跃且可用。通常,OSD 故障会导致对等故障。

要排除这个问题,请执行以下操作

确定什么块对等进程:

[root@mon ~]# ceph pg ID query

使用下 线 PG 的 ID 替换 ID,例如:

[root@mon ~]# ceph pg 0.5 query

{ "state": "down+peering",
  ...
  "recovery_state": [
       { "name": "Started\/Primary\/Peering\/GetInfo",
         "enter_time": "2012-03-06 14:40:16.169679",
         "requested_info_from": []},
       { "name": "Started\/Primary\/Peering",
         "enter_time": "2012-03-06 14:40:16.169659",
         "probing_osds": [
               0,
               1],
         "blocked": "peering is blocked due to down osds",
         "down_osds_we_would_probe": [
               1],
         "peering_blocked_by": [
               { "osd": 1,
                 "current_lost_at": 0,
                 "comment": "starting or marking this osd lost may let us proceed"}]},
       { "name": "Started",
         "enter_time": "2012-03-06 14:40:16.169513"}
   ]
}

restore_state 部分包含对等进程被阻止的信息。

  • 如果输出中包含 peering,因为 down osds 错误消息而被阻断,请参见 Down OSD
  • 如果您看到任何其他错误消息,请打开支持票据。有关详细信息,请参阅 联系红帽支持服务

其它资源

9.2.8. 未找到的对象

ceph health 命令返回类似如下的错误消息,其中包含 unfound 关键字:

HEALTH_WARN 1 pgs degraded; 78/3778 unfound (2.065%)

此 Means 是什么

当对象知道这些对象或较新的副本 ,Ceph 会将其标记为不正确,但它无法找到它们。因此,Ceph 无法恢复这样的对象,并继续恢复过程。

Situation 示例

PG 将数据存储在 osd.1osd.2 上。

  1. OSD.1 停机.
  2. OSD.2 处理一些写入操作。
  3. OSD.1 启动
  4. osd.1 和 osd .2 启动之间的对等进程启动,并且 osd.1 上缺少的对象排队以进行恢复。
  5. 在 Ceph 复制新对象之前,osd.2 中断

因此,osd.1 知道这些对象存在,但没有 OSD 具有对象的副本。

在这种情景中,Ceph 正在等待故障节点再次访问,而 未找到的对象 则阻止恢复过程。

要排除这个问题,请执行以下操作

  1. 确定哪个 PG 包含 未找到 的对象:

    [root@mon ~]# ceph health detail
    HEALTH_WARN 1 pgs recovering; 1 pgs stuck unclean; recovery 5/937611 objects degraded (0.001%); 1/312537 unfound (0.000%)
    pg 3.8a5 is stuck unclean for 803946.712780, current state active+recovering, last acting [320,248,0]
    pg 3.8a5 is active+recovering, acting [320,248,0], 1 unfound
    recovery 5/937611 objects degraded (0.001%); **1/312537 unfound (0.000%)**
  2. 列出有关 PG 的更多信息:

    [root@mon ~]# ceph pg ID query

    使用包含未找到 对象的 PG 的 ID 替换 ID,例如:

    [root@mon ~]# ceph pg 3.8a5 query
    { "state": "active+recovering",
      "epoch": 10741,
      "up": [
            320,
            248,
            0],
      "acting": [
            320,
            248,
            0],
    <snip>
      "recovery_state": [
            { "name": "Started\/Primary\/Active",
              "enter_time": "2015-01-28 19:30:12.058136",
              "might_have_unfound": [
                    { "osd": "0",
                      "status": "already probed"},
                    { "osd": "248",
                      "status": "already probed"},
                    { "osd": "301",
                      "status": "already probed"},
                    { "osd": "362",
                      "status": "already probed"},
                    { "osd": "395",
                      "status": "already probed"},
                    { "osd": "429",
                      "status": "osd is down"}],
              "recovery_progress": { "backfill_targets": [],
                  "waiting_on_backfill": [],
                  "last_backfill_started": "0\/\/0\/\/-1",
                  "backfill_info": { "begin": "0\/\/0\/\/-1",
                      "end": "0\/\/0\/\/-1",
                      "objects": []},
                  "peer_backfill_info": [],
                  "backfills_in_flight": [],
                  "recovering": [],
                  "pg_backend": { "pull_from_peer": [],
                      "pushing": []}},
              "scrub": { "scrubber.epoch_start": "0",
                  "scrubber.active": 0,
                  "scrubber.block_writes": 0,
                  "scrubber.finalizing": 0,
                  "scrubber.waiting_on": 0,
                  "scrubber.waiting_on_whom": []}},
            { "name": "Started",
              "enter_time": "2015-01-28 19:30:11.044020"}],

    may _have_unfound 部分包括 Ceph 尝试定位 未找到对象的 OSD:

    • 已探测到 的状态表示 Ceph 无法找到 该 OSD 中的未找到对象
    • osd is down 状态表示 Ceph 无法联系该 OSD。
  3. 对标记为 down 的 OSD 进行故障排除。详情请参阅 关闭 OSD
  4. 如果您无法修复导致 OSD 停机 的问题,请打开支持票据。有关 详细信息,请参阅联系红帽支持团队

9.3. 列出 PG 停留在 staleinactiveunclean 状态

失败后,PG 会进入 降级peering 等状态。这个状态表示通过故障恢复过程的正常进度。

但是,如果 PG 处于这些状态之一的时间比预期长,它可以代表更大的问题。监控器报告 PG 处于不最佳状态时。

Ceph 配置文件中的 mon_pg_stuck_threshold 选项决定了 PG 在多少秒之后被视为 不活动、未 清理过时

下表列出了这些状态及简短的说明:

状态它的含义大多数常见原因请查看

Inactive

PG 尚未能够服务读/写请求。

  • 对等问题

不活跃的放置组

unclean

PG 包含的对象不会复制所需的次数。些情况阻止 PG 恢复。

  • 未找到 的对象
  • OSD 已 停机
  • 配置不正确

unclean PG

stale

ceph-osd 守护进程尚未更新 PG 的状态。

  • OSD 已 停机

过时 PG

先决条件

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

流程

  1. 列出卡住 PG:

    [root@mon ~]# ceph pg dump_stuck inactive
    [root@mon ~]# ceph pg dump_stuck unclean
    [root@mon ~]# ceph pg dump_stuck stale

其它资源

  • 请参阅《 红帽 Ceph 存储管理指南 》中的 放置组状态 部分。

9.4. 列出放置组不一致

使用 rados 实用程序列出对象不同副本中的不一致情况。使用 --format=json-pretty 选项列出更详细的输出。

本节涵盖以下列表:

  • 池中 PG 不一致
  • 放置组中的对象不一致
  • PG 中的快照设置不一致

先决条件

  • 正在运行的红帽 Ceph 存储集群处于健康状态。
  • 节点的根级别访问权限。

流程

rados list-inconsistent-pg POOL --format=json-pretty

例如,列出名为 data 的池中所有不一致的 PG:

# rados list-inconsistent-pg data --format=json-pretty
[0.6]
rados list-inconsistent-obj PLACEMENT_GROUP_ID

例如,列出 ID 为 0.6 的 PG 中的不一致对象:

# rados list-inconsistent-obj 0.6
{
    "epoch": 14,
    "inconsistents": [
        {
            "object": {
                "name": "image1",
                "nspace": "",
                "locator": "",
                "snap": "head",
                "version": 1
            },
            "errors": [
                "data_digest_mismatch",
                "size_mismatch"
            ],
            "union_shard_errors": [
                "data_digest_mismatch_oi",
                "size_mismatch_oi"
            ],
            "selected_object_info": "0:602f83fe:::foo:head(16'1 client.4110.0:1 dirty|data_digest|omap_digest s 968 uv 1 dd e978e67f od ffffffff alloc_hint [0 0 0])",
            "shards": [
                {
                    "osd": 0,
                    "errors": [],
                    "size": 968,
                    "omap_digest": "0xffffffff",
                    "data_digest": "0xe978e67f"
                },
                {
                    "osd": 1,
                    "errors": [],
                    "size": 968,
                    "omap_digest": "0xffffffff",
                    "data_digest": "0xe978e67f"
                },
                {
                    "osd": 2,
                    "errors": [
                        "data_digest_mismatch_oi",
                        "size_mismatch_oi"
                    ],
                    "size": 0,
                    "omap_digest": "0xffffffff",
                    "data_digest": "0xffffffff"
                }
            ]
        }
    ]
}

以下字段对于决定造成不一致的原因非常重要:

  • name :副本不一致的对象名称。
  • NS PACE:是池逻辑分割的命名空间。默认情况下是空的。
  • locator :用作放置对象名称替代替换的键。
  • snap :对象的快照 ID。对象的唯一可写版本称为 head。如果对象是克隆,则此字段包含其顺序 ID。
  • Version :副本不一致的对象的版本 ID。每个对象写入操作都会递增它。
  • 错误 :显示分片之间不一致的错误列表,但不决定哪个分片或分片不正确。请参阅 分片 数组以进一步调查错误。

    • data_digest_mismatch :从一个 OSD 读取的副本摘要与其他 OSD 不同。
    • size_mismatch :克隆的大小或 对象与预期不匹配。
    • read_error :此错误表示磁盘错误很有可能导致不一致。
  • union_shard_error :所有特定于分片的错误的并集。这些错误连接到有故障的分片。with oi 结尾的错误表示您必须将故障对象中的信息与选定对象的信息进行比较。请参阅 分片 数组以进一步调查错误。

    在上例中,存储在 osd.2 上的对象副本的摘要与 osd. 0 和 osd. 1 上存储的副本不同。具体来说,副本摘要不是从 osd.2 读取的分片中计算的 0xffffffff,而是 0xe978e67f。此外,从 osd.2 读取的副本大小为 0,而 osd. 0 和 osd. 1 报告的大小为 968。

rados list-inconsistent-snapset PLACEMENT_GROUP_ID

例如,列出 ID 为 0.23 的 PG 中不一致的快照集(snapset):

# rados list-inconsistent-snapset 0.23 --format=json-pretty
{
    "epoch": 64,
    "inconsistents": [
        {
            "name": "obj5",
            "nspace": "",
            "locator": "",
            "snap": "0x00000001",
            "headless": true
        },
        {
            "name": "obj5",
            "nspace": "",
            "locator": "",
            "snap": "0x00000002",
            "headless": true
        },
        {
            "name": "obj5",
            "nspace": "",
            "locator": "",
            "snap": "head",
            "ss_attr_missing": true,
            "extra_clones": true,
            "extra clones": [
                2,
                1
            ]
        }
    ]

该命令返回以下错误:

  • ss_attr_missing :缺少一个或多个属性。属性是关于作为键值对列表编码到快照集的快照的信息。
  • ss_attr_corrupted :一个或多个属性无法解码。
  • clone_missing :缺少克隆。
  • snapset_mismatch :快照集本身不一致。
  • head_mismatch :快照集表示 head 存在或不存在,但清理结果报告其他。
  • 标头:缺少快照集 的头部
  • size_mismatch :克隆的大小或 对象与预期不匹配。

其它资源

9.5. 修复不一致的放置组

由于深度清理过程中出现错误,一些 PG 可以包含不一致的情况。Ceph 将这样的放置组报告为 不一致

HEALTH_ERR 1 pgs inconsistent; 2 scrub errors
pg 0.6 is active+clean+inconsistent, acting [0,1,2]
2 scrub errors
警告

您只能修复某些不一致的问题。

如果 Ceph 日志包括以下错误,则不要修复 PG:

_PG_._ID_ shard _OSD_: soid _OBJECT_ digest _DIGEST_ != known digest _DIGEST_
_PG_._ID_ shard _OSD_: soid _OBJECT_ omap_digest _DIGEST_ != known omap_digest _DIGEST_

相反,打开支持问题单。有关 详细信息,请参阅联系红帽支持团队

先决条件

  • Ceph 监控节点的根级别访问权限.

流程

  1. 修复 不一致的 PG:
[root@mon ~]# ceph pg repair ID
  1. 使用 不一致的 PG 的 ID 替换 ID。

其它资源

9.6. 增加放置组

放置组(PG)计数不足,会影响 Ceph 集群和数据分布的性能。它是 nearfull osds 错误消息的主要原因之一。

建议比率为每个 OSD 100 到 300 个 PG。当您向集群添加更多 OSD 时,这个比率可能会降低。

The pg_numpgp_num 参数决定了 PG 数。这些参数为每个池配置,因此您必须单独调整每个池的 PG 数较低。

重要

增加 PG 数量是您可以在 Ceph 集群上执行的一个最密集型进程。如果不以缓慢、有方法的方式完成,这个过程可能会对性能有严重影响。旦您提高 pgp_num,您将无法停止或颠倒此进程,您必须完成该过程。考虑在业务关键处理时间分配之外增加 PG 数量,并提醒所有客户端可能会对性能造成影响。如果集群处于 HEALTH_ERR 状态,则不要更改 PG 计数。

先决条件

  • 正在运行的红帽 Ceph 存储集群处于健康状态。
  • 节点的根级别访问权限。

流程

  1. 减少数据重新发布和恢复对单个 OSD 和 OSD 主机的影响:

    1. 降低 osd max backfillsosd_recovery_max_activeosd_recovery_op_priority 参数的值:

      [root@mon ~]# ceph tell osd.* injectargs '--osd_max_backfills 1 --osd_recovery_max_active 1 --osd_recovery_op_priority 1'
    2. 禁用低级和深度清理:

      [root@mon ~]# ceph osd set noscrub
      [root@mon ~]# ceph osd set nodeep-scrub
  2. 使用 每个池 Calculator 的 Ceph PG(PG) 来计算 pg_num 和 pgp_num 参数的最佳值。
  3. 以小增量增加 pg_num 值,直到您达到所需的值。

    1. 确定启动递增值。使用一个非常低的值(2 的电源),并在您确定对集群的影响时增加这个值。最佳的值取决于池大小、OSD 数和客户端 I/O 负载。
    2. 递增 pg_num 值:

      ceph osd pool set POOL pg_num VALUE

      指定池名称和新值,例如:

      # ceph osd pool set data pg_num 4
    3. 监控集群的状态:

      # ceph -s

      PGs 状态将从 creating 更改为 active+clean。等待所有 PG 都处于 active+clean 状态。

  4. 以小增量增加 pgp_num 值,直到您达到所需的值:

    1. 确定启动递增值。使用一个非常低的值(2 的电源),并在您确定对集群的影响时增加这个值。最佳的值取决于池大小、OSD 数和客户端 I/O 负载。
    2. 递增 pgp_num 值:

      ceph osd pool set POOL pgp_num VALUE

      指定池名称和新值,例如:

      # ceph osd pool set data pgp_num 4
    3. 监控集群的状态:

      # ceph -s

      PGs 状态将通过 peering、wait_backfill回填恢复 等来改变。等待所有 PG 都处于 active+clean 状态。

  5. 对 PG 数量不足的所有池重复上述步骤。
  6. osd max backfillsosd_recovery_max_activeosd_recovery_op_priority 设置为默认值:

    # ceph tell osd.* injectargs '--osd_max_backfills 1 --osd_recovery_max_active 3 --osd_recovery_op_priority 3'
  7. 启用低级和深度清理:

    # ceph osd unset noscrub
    # ceph osd unset nodeep-scrub

其它资源

9.7. 其它资源

第 10 章 Ceph 对象故障排除

作为存储管理员,您可以使用 ceph-objectstore-tool 实用程序执行高级别或低级对象操作。ceph-objectstore-tool 实用程序可帮助您对特定 OSD 或 PG 中对象相关的问题进行故障排除。

您还可以在救援/维护模式下启动 OSD 容器,以修复 OSD,而无需在 OSD 节点上安装 Ceph 软件包。

重要

操作对象可能会导致无法恢复的数据丢失。在使用 ceph-objectstore-tool 实用程序前,请联络红帽支持。

10.1. 先决条件

  • 验证没有与网络相关的问题。

10.2. 容器化环境中的 Ceph 对象故障排除

OSD 容器可以在救援/维护模式下启动,以修复 Red Hat Ceph Storage 4 中的 OSD,而无需在 OSD 节点上安装 Ceph 软件包。

您可以使用 ceph-bluestore-tool 使用 fsck 命令运行一致性检查,或者运行一致性检查并修复所有有 repair 命令的错误。

重要

此流程只适用于容器化部署。对于裸机部署跳过此部分

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • Ceph OSD 节点的根级别访问权限.
  • 停止 ceph-osd 守护进程.

流程

  1. 在集群中设置 noout 标志。

    示例

    [root@mon ~]# ceph osd set noout

  2. 登录托管 OSD 容器的节点。
  3. /etc/systemd/system/ceph-osd@.service 单元文件备份到 /root 目录。

    示例

    [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

  4. /run/ceph-osd@OSD_ID.service-cid 文件移到 /root

    示例

    [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

  5. 编辑 /etc/systemd/system/ceph-osd@.service 单元文件,并在 podman 命令中添加 -it --entrypoint /bin/bash 选项。

    示例

    # Please do not change this file directly since it is managed by Ansible and will be overwritten
    [Unit]
    Description=Ceph OSD
    After=network.target
    
    [Service]
    EnvironmentFile=-/etc/environment
    ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
    ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
    ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
      -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
      --rm \
      --net=host \
      --privileged=true \
      --pid=host \
      --ipc=host \
      --cpus=2 \
      -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 \
      -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
      -e CLUSTER=ceph \
      -v /run/lvm/:/run/lvm/ \
      -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
      -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
      -e OSD_ID=%i \
      -e DEBUG=stayalive \
      --name=ceph-osd-%i \
       \
      registry.redhat.io/rhceph/rhceph-4-rhel8:latest
    ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
    KillMode=none
    Restart=always
    RestartSec=10s
    TimeoutStartSec=120
    TimeoutStopSec=15
    Type=forking
    PIDFile=/%t/%n-pid
    
    [Install]
    WantedBy=multi-user.target

  6. 重新加载 systemd 管理器配置。

    示例

    [root@osd ~]# systemctl daemon-reload

  7. 重新启动与 OSD_ID 关联的 OSD 服务。

    语法

    systemctl restart ceph-osd@OSD_ID.service

    OSD_ID 替换为 OSD 的 ID。

    示例

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

  8. 登录与 OSD_ID 关联的容器。

    语法

    podman exec -it ceph-osd-OSD_ID /bin/bash

    示例

    [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

  9. 获取 osd fsid 并激活 OSD 以挂载 OSD 的逻辑卷(LV)。

    语法

    ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
    ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

    示例

    [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
                  osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
    [root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
    Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
    Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
    Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
    Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
    Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
    Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
    Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
    Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
     stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
    Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
     stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
    Running command: /usr/bin/systemctl start ceph-osd@0
     stderr: Running in chroot, ignoring request: start
    --> ceph-volume lvm activate successful for osd ID: 0

  10. 运行 fsckrepair 命令。

    语法

    ceph-bluestore-tool fsck --path /var/lib/ceph/osd/ceph-OSD_ID
    ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-OSD_ID

    示例

    [root@osd ~]# ceph-bluestore-tool fsck --path /var/lib/ceph/osd/ceph-0
    fsck success

    [root@osd ~]# ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-0
    repair success
  11. 退出容器后,从 /root 目录中复制 /etc/systemd/system/ceph-osd@.service 单元文件。

    示例

    [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
    [root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

  12. 重新加载 systemd 管理器配置。

    示例

    [root@osd ~]# systemctl daemon-reload

  13. /run/ceph-osd@OSD_ID.service-cid 文件移到 /tmp

    示例

    [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

  14. 重新启动与 OSD_ID 关联的 OSD 服务。

    语法

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

    示例

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

其它资源

10.3. 高级对象操作故障排除

作为存储管理员,您可以使用 ceph-objectstore-tool 实用程序来执行高级别对象操作。ceph-objectstore-tool 实用程序支持以下高级对象操作:

  • 列出对象
  • 列出丢失的对象
  • 修复丢失的对象
重要

操作对象可能会导致无法恢复的数据丢失。在使用 ceph-objectstore-tool 实用程序前,请联络红帽支持。

10.3.1. 先决条件

  • 对 Ceph OSD 节点的根级别访问权限.

10.3.2. 列出对象

OSD 可以包含零个到多个 PG 的 PG,对放置组(PG)中的多个对象包含零。ceph-objectstore-tool 实用程序允许您列出 OSD 中存储的对象。

先决条件

  • Ceph OSD 节点的根级别访问权限.
  • 停止 ceph-osd 守护进程.

流程

  1. 验证适当的 OSD 是否停机:

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

    示例

    [root@osd ~]# systemctl status ceph-osd@1

  2. 对于容器化部署,要访问 bluestore 工具,请按照以下步骤执行:

    1. 在集群中设置 noout 标志。

      示例

      [root@mon ~]# ceph osd set noout

    2. 登录托管 OSD 容器的节点。
    3. /etc/systemd/system/ceph-osd@.service 单元文件备份到 /root 目录。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 文件移到 /root

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. 编辑 /etc/systemd/system/ceph-osd@.service 单元文件,并在 podman 命令中添加 -it --entrypoint /bin/bash 选项。

      示例

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
      [Unit]
      Description=Ceph OSD
      After=network.target
      
      [Service]
      EnvironmentFile=-/etc/environment
      ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
      ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
      ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
        -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
        --rm \
        --net=host \
        --privileged=true \
        --pid=host \
        --ipc=host \
        --cpus=2 \
        -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 \
        -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
        -e CLUSTER=ceph \
        -v /run/lvm/:/run/lvm/ \
        -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
        -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
        -e OSD_ID=%i \
        -e DEBUG=stayalive \
        --name=ceph-osd-%i \
         \
        registry.redhat.io/rhceph/rhceph-4-rhel8:latest
      ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
      KillMode=none
      Restart=always
      RestartSec=10s
      TimeoutStartSec=120
      TimeoutStopSec=15
      Type=forking
      PIDFile=/%t/%n-pid
      
      [Install]
      WantedBy=multi-user.target

    6. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    7. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 替换为 OSD 的 ID。

      示例

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

    8. 登录与 OSD_ID 关联的容器。

      语法

      podman exec -it ceph-osd-OSD_ID /bin/bash

      示例

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. 获取 osd fsid 并激活 OSD 以挂载 OSD 的逻辑卷(LV)。

      语法

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
      ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      示例

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
                    osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
      [root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
      Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
      Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
       stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
      Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
       stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
      Running command: /usr/bin/systemctl start ceph-osd@0
       stderr: Running in chroot, ignoring request: start
      --> ceph-volume lvm activate successful for osd ID: 0

  3. 识别 OSD 内的所有对象,而不考虑 PG:

    [root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --op list

    示例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op list

  4. 识别 PG 中的所有对象:

    [root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --pgid PG_ID --op list

    示例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c --op list

  5. 识别对象所属的 PG:

    [root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --op list OBJECT_ID

    示例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op list default.region

  6. 对于容器化部署,要恢复更改,请按照以下步骤执行:

    1. 退出容器后,从 /root 目录中复制 /etc/systemd/system/ceph-osd@.service 单元文件。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
      [root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 文件移到 /tmp

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

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

      示例

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

其它资源

10.3.3. 列出丢失的对象

OSD 可以将对象标记为 lostunfound。您可以使用 ceph-objectstore-tool 列出 OSD 中存储的 lost 和 unfound 对象。

先决条件

  • Ceph OSD 节点的根级别访问权限.
  • 停止 ceph-osd 守护进程.

流程

  1. 验证适当的 OSD 是否停机:

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

    示例

    [root@osd ~]# systemctl status ceph-osd@1

  2. 对于容器化部署,要访问 bluestore 工具,请按照以下步骤执行:

    1. 在集群中设置 noout 标志。

      示例

      [root@mon ~]# ceph osd set noout

    2. 登录托管 OSD 容器的节点。
    3. /etc/systemd/system/ceph-osd@.service 单元文件备份到 /root 目录。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 文件移到 /root

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. 编辑 /etc/systemd/system/ceph-osd@.service 单元文件,并在 podman 命令中添加 -it --entrypoint /bin/bash 选项。

      示例

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
      [Unit]
      Description=Ceph OSD
      After=network.target
      
      [Service]
      EnvironmentFile=-/etc/environment
      ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
      ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
      ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
        -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
        --rm \
        --net=host \
        --privileged=true \
        --pid=host \
        --ipc=host \
        --cpus=2 \
        -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 \
        -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
        -e CLUSTER=ceph \
        -v /run/lvm/:/run/lvm/ \
        -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
        -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
        -e OSD_ID=%i \
        -e DEBUG=stayalive \
        --name=ceph-osd-%i \
         \
        registry.redhat.io/rhceph/rhceph-4-rhel8:latest
      ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
      KillMode=none
      Restart=always
      RestartSec=10s
      TimeoutStartSec=120
      TimeoutStopSec=15
      Type=forking
      PIDFile=/%t/%n-pid
      
      [Install]
      WantedBy=multi-user.target

    6. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    7. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 替换为 OSD 的 ID。

      示例

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

    8. 登录与 OSD_ID 关联的容器。

      语法

      podman exec -it ceph-osd-OSD_ID /bin/bash

      示例

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. 获取 osd fsid 并激活 OSD 以挂载 OSD 的逻辑卷(LV)。

      语法

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
      ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      示例

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
                    osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
      [root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
      Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
      Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
       stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
      Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
       stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
      Running command: /usr/bin/systemctl start ceph-osd@0
       stderr: Running in chroot, ignoring request: start
      --> ceph-volume lvm activate successful for osd ID: 0

  3. 使用 ceph-objectstore-tool 实用程序列出 lost 和 unfound 对象。选择适当的情况:

    1. 列出所有丢失的对象:

      [root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --op list-lost

      示例

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op list-lost

    2. 列出放置组中的所有丢失对象:

      [root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --pgid PG_ID --op list-lost

      示例

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c --op list-lost

    3. 按其标识符列出丢失的对象:

      [root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --op list-lost OBJECT_ID

      示例

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op list-lost default.region

  4. 对于容器化部署,要恢复更改,请按照以下步骤执行:

    1. 退出容器后,从 /root 目录中复制 /etc/systemd/system/ceph-osd@.service 单元文件。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
      [root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 文件移到 /tmp

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

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

      示例

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

其它资源

10.3.4. 修复丢失的对象

您可以使用 ceph-objectstore-tool 实用程序列出和修复 Ceph OSD 中存储的、未找到 的对象。这个过程只适用于旧对象。

先决条件

  • Ceph OSD 节点的根级别访问权限.
  • 停止 ceph-osd 守护进程.

流程

  1. 验证适当的 OSD 是否停机:

    语法

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

    示例

    [root@osd ~]# systemctl status ceph-osd@1

  2. 对于容器化部署,要访问 bluestore 工具,请按照以下步骤执行:

    1. 在集群中设置 noout 标志。

      示例

      [root@mon ~]# ceph osd set noout

    2. 登录托管 OSD 容器的节点。
    3. /etc/systemd/system/ceph-osd@.service 单元文件备份到 /root 目录。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 文件移到 /root

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. 编辑 /etc/systemd/system/ceph-osd@.service 单元文件,并在 podman 命令中添加 -it --entrypoint /bin/bash 选项。

      示例

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
      [Unit]
      Description=Ceph OSD
      After=network.target
      
      [Service]
      EnvironmentFile=-/etc/environment
      ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
      ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
      ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
        -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
        --rm \
        --net=host \
        --privileged=true \
        --pid=host \
        --ipc=host \
        --cpus=2 \
        -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 \
        -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
        -e CLUSTER=ceph \
        -v /run/lvm/:/run/lvm/ \
        -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
        -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
        -e OSD_ID=%i \
        -e DEBUG=stayalive \
        --name=ceph-osd-%i \
         \
        registry.redhat.io/rhceph/rhceph-4-rhel8:latest
      ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
      KillMode=none
      Restart=always
      RestartSec=10s
      TimeoutStartSec=120
      TimeoutStopSec=15
      Type=forking
      PIDFile=/%t/%n-pid
      
      [Install]
      WantedBy=multi-user.target

    6. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    7. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 替换为 OSD 的 ID。

      示例

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

    8. 登录与 OSD_ID 关联的容器。

      语法

      podman exec -it ceph-osd-OSD_ID /bin/bash

      示例

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. 获取 osd fsid 并激活 OSD 以挂载 OSD 的逻辑卷(LV)。

      语法

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
      ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      示例

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
                    osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
      [root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
      Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
      Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
       stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
      Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
       stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
      Running command: /usr/bin/systemctl start ceph-osd@0
       stderr: Running in chroot, ignoring request: start
      --> ceph-volume lvm activate successful for osd ID: 0

  3. 列出所有丢失的旧对象:

    语法

    ceph-objectstore-tool --data-path PATH_TO_OSD --op fix-lost --dry-run

    示例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op fix-lost --dry-run

  4. ceph-objectstore-tool 用户身份,使用 ceph-objectstore-tool 程序修复 丢失和 未找到 的对象。选择适当的情况:

    • 修复所有丢失的对象:

      语法

      su - ceph -c 'ceph-objectstore-tool --data-path PATH_TO_OSD --op fix-lost'

      示例

      [root@osd ~]# su - ceph -c 'ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op fix-lost'

    • 修复 PG 中丢失的所有对象:

      su - ceph -c 'ceph-objectstore-tool --data-path _PATH_TO_OSD_ --pgid _PG_ID_ --op fix-lost'

      示例

      [root@osd ~]# su - ceph -c 'ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c --op fix-lost'

    • 使用标识符修复丢失的对象:

      语法

      su - ceph -c 'ceph-objectstore-tool --data-path PATH_TO_OSD --op fix-lost OBJECT_ID'

      示例

      [root@osd ~]# su - ceph -c 'ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op fix-lost default.region'

  5. 对于容器化部署,要恢复更改,请按照以下步骤执行:

    1. 退出容器后,从 /root 目录中复制 /etc/systemd/system/ceph-osd@.service 单元文件。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
      [root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 文件移到 /tmp

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

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

      示例

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

其它资源

10.4. 低级对象操作故障排除

作为存储管理员,您可以使用 ceph-objectstore-tool 实用程序来执行低级对象操作。ceph-objectstore-tool 实用程序支持以下低级别对象操作:

  • 操作对象的内容
  • 删除对象
  • 列出对象映射(OMAP)
  • 操作 OMAP 标头
  • 操作 OMAP 密钥
  • 列出对象的属性
  • 操作对象的属性键
重要

操作对象可能会导致无法恢复的数据丢失。在使用 ceph-objectstore-tool 实用程序前,请联络红帽支持。

10.4.1. 先决条件

  • 对 Ceph OSD 节点的根级别访问权限.

10.4.2. 操作对象的内容

使用 ceph-objectstore-tool 实用程序时,您可以在对象上获取或设置字节。

重要

在对象上设置字节可能会导致无法恢复的数据丢失。要防止数据丢失,请为对象制作备份副本。

先决条件

  • Ceph OSD 节点的根级别访问权限.
  • 停止 ceph-osd 守护进程.

流程

  1. 验证适当的 OSD 是否停机:

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

    示例

    [root@osd ~]# systemctl status ceph-osd@1

  2. 对于容器化部署,要访问 bluestore 工具,请按照以下步骤执行:

    1. 在集群中设置 noout 标志。

      示例

      [root@mon ~]# ceph osd set noout

    2. 登录托管 OSD 容器的节点。
    3. /etc/systemd/system/ceph-osd@.service 单元文件备份到 /root 目录。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 文件移到 /root

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. 编辑 /etc/systemd/system/ceph-osd@.service 单元文件,并在 podman 命令中添加 -it --entrypoint /bin/bash 选项。

      示例

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
      [Unit]
      Description=Ceph OSD
      After=network.target
      
      [Service]
      EnvironmentFile=-/etc/environment
      ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
      ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
      ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
        -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
        --rm \
        --net=host \
        --privileged=true \
        --pid=host \
        --ipc=host \
        --cpus=2 \
        -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 \
        -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
        -e CLUSTER=ceph \
        -v /run/lvm/:/run/lvm/ \
        -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
        -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
        -e OSD_ID=%i \
        -e DEBUG=stayalive \
        --name=ceph-osd-%i \
         \
        registry.redhat.io/rhceph/rhceph-4-rhel8:latest
      ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
      KillMode=none
      Restart=always
      RestartSec=10s
      TimeoutStartSec=120
      TimeoutStopSec=15
      Type=forking
      PIDFile=/%t/%n-pid
      
      [Install]
      WantedBy=multi-user.target

    6. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    7. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 替换为 OSD 的 ID。

      示例

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

    8. 登录与 OSD_ID 关联的容器。

      语法

      podman exec -it ceph-osd-OSD_ID /bin/bash

      示例

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. 获取 osd fsid 并激活 OSD 以挂载 OSD 的逻辑卷(LV)。

      语法

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
      ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      示例

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
                    osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
      [root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
      Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
      Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
       stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
      Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
       stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
      Running command: /usr/bin/systemctl start ceph-osd@0
       stderr: Running in chroot, ignoring request: start
      --> ceph-volume lvm activate successful for osd ID: 0

  3. 通过列出 OSD 或 PG(PG)的对象来查找对象。
  4. 在对象中设置字节前,请进行备份和对象的工作副本:

    [root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --pgid PG_ID \
    OBJECT \
    get-bytes > OBJECT_FILE_NAME
    
    [root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --pgid PG_ID \
    OBJECT \
    get-bytes > OBJECT_FILE_NAME

    示例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \
    '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
    get-bytes > zone_info.default.backup
    
    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \
    '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
    get-bytes > zone_info.default.working-copy

  5. 编辑工作复制对象文件,并相应地修改对象内容。
  6. 设置对象的字节:

    [root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --pgid PG_ID \
    OBJECT \
    set-bytes < OBJECT_FILE_NAME

    示例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \
    '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
    set-bytes < zone_info.default.working-copy

  7. 对于容器化部署,要恢复更改,请按照以下步骤执行:

    1. 退出容器后,从 /root 目录中复制 /etc/systemd/system/ceph-osd@.service 单元文件。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
      [root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 文件移到 /tmp

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

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

      示例

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

其它资源

10.4.3. 删除对象

使用 ceph-objectstore-tool 实用程序删除对象。通过移除对象,其内容和引用将从放置组(PG)中删除。

重要

对象被删除后,您就无法重新创建对象。

先决条件

  • Ceph OSD 节点的根级别访问权限.
  • 停止 ceph-osd 守护进程.

流程

  1. 验证适当的 OSD 是否停机:

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

    示例

    [root@osd ~]# systemctl status ceph-osd@1

  2. 对于容器化部署,要访问 bluestore 工具,请按照以下步骤执行:

    1. 在集群中设置 noout 标志。

      示例

      [root@mon ~]# ceph osd set noout

    2. 登录托管 OSD 容器的节点。
    3. /etc/systemd/system/ceph-osd@.service 单元文件备份到 /root 目录。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 文件移到 /root

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. 编辑 /etc/systemd/system/ceph-osd@.service 单元文件,并在 podman 命令中添加 -it --entrypoint /bin/bash 选项。

      示例

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
      [Unit]
      Description=Ceph OSD
      After=network.target
      
      [Service]
      EnvironmentFile=-/etc/environment
      ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
      ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
      ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
        -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
        --rm \
        --net=host \
        --privileged=true \
        --pid=host \
        --ipc=host \
        --cpus=2 \
        -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 \
        -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
        -e CLUSTER=ceph \
        -v /run/lvm/:/run/lvm/ \
        -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
        -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
        -e OSD_ID=%i \
        -e DEBUG=stayalive \
        --name=ceph-osd-%i \
         \
        registry.redhat.io/rhceph/rhceph-4-rhel8:latest
      ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
      KillMode=none
      Restart=always
      RestartSec=10s
      TimeoutStartSec=120
      TimeoutStopSec=15
      Type=forking
      PIDFile=/%t/%n-pid
      
      [Install]
      WantedBy=multi-user.target

    6. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    7. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 替换为 OSD 的 ID。

      示例

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

    8. 登录与 OSD_ID 关联的容器。

      语法

      podman exec -it ceph-osd-OSD_ID /bin/bash

      示例

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. 获取 osd fsid 并激活 OSD 以挂载 OSD 的逻辑卷(LV)。

      语法

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
      ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      示例

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
                    osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
      [root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
      Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
      Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
       stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
      Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
       stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
      Running command: /usr/bin/systemctl start ceph-osd@0
       stderr: Running in chroot, ignoring request: start
      --> ceph-volume lvm activate successful for osd ID: 0

  3. 删除对象:

    语法

    ceph-objectstore-tool --data-path PATH_TO_OSD --pgid PG_ID \
    OBJECT \
    remove

    示例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \
    '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
    remove

  4. 对于容器化部署,要恢复更改,请按照以下步骤执行:

    1. 退出容器后,从 /root 目录中复制 /etc/systemd/system/ceph-osd@.service 单元文件。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
      [root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 文件移到 /tmp

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

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

      示例

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

其它资源

10.4.4. 列出对象映射

使用 ceph-objectstore-tool 实用程序列出对象映射(OMAP)的内容。输出为您提供了键列表。

先决条件

  • Ceph OSD 节点的根级别访问权限.
  • 停止 ceph-osd 守护进程.

流程

  1. 验证适当的 OSD 是否停机:

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

    示例

    [root@osd ~]# systemctl status ceph-osd@1

  2. 对于容器化部署,要访问 bluestore 工具,请按照以下步骤执行:

    1. 在集群中设置 noout 标志。

      示例

      [root@mon ~]# ceph osd set noout

    2. 登录托管 OSD 容器的节点。
    3. /etc/systemd/system/ceph-osd@.service 单元文件备份到 /root 目录。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 文件移到 /root

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. 编辑 /etc/systemd/system/ceph-osd@.service 单元文件,并在 podman 命令中添加 -it --entrypoint /bin/bash 选项。

      示例

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
      [Unit]
      Description=Ceph OSD
      After=network.target
      
      [Service]
      EnvironmentFile=-/etc/environment
      ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
      ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
      ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
        -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
        --rm \
        --net=host \
        --privileged=true \
        --pid=host \
        --ipc=host \
        --cpus=2 \
        -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 \
        -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
        -e CLUSTER=ceph \
        -v /run/lvm/:/run/lvm/ \
        -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
        -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
        -e OSD_ID=%i \
        -e DEBUG=stayalive \
        --name=ceph-osd-%i \
         \
        registry.redhat.io/rhceph/rhceph-4-rhel8:latest
      ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
      KillMode=none
      Restart=always
      RestartSec=10s
      TimeoutStartSec=120
      TimeoutStopSec=15
      Type=forking
      PIDFile=/%t/%n-pid
      
      [Install]
      WantedBy=multi-user.target

    6. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    7. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 替换为 OSD 的 ID。

      示例

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

    8. 登录与 OSD_ID 关联的容器。

      语法

      podman exec -it ceph-osd-OSD_ID /bin/bash

      示例

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. 获取 osd fsid 并激活 OSD 以挂载 OSD 的逻辑卷(LV)。

      语法

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
      ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      示例

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
                    osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
      [root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
      Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
      Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
       stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
      Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
       stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
      Running command: /usr/bin/systemctl start ceph-osd@0
       stderr: Running in chroot, ignoring request: start
      --> ceph-volume lvm activate successful for osd ID: 0

  3. 列出对象映射:

    [root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --pgid PG_ID \
    OBJECT \
    list-omap

    示例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \
    '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
    list-omap

  4. 对于容器化部署,要恢复更改,请按照以下步骤执行:

    1. 退出容器后,从 /root 目录中复制 /etc/systemd/system/ceph-osd@.service 单元文件。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
      [root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 文件移到 /tmp

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

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

      示例

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

其它资源

10.4.5. 操作对象映射标头

ceph-objectstore-tool 实用程序将输出对象映射(OMAP)标头,以及与对象的键关联的值。

先决条件

  • Ceph OSD 节点的根级别访问权限.
  • 停止 ceph-osd 守护进程.

流程

  1. 对于容器化部署,要访问 bluestore 工具,请按照以下步骤执行:

    1. 在集群中设置 noout 标志。

      示例

      [root@mon ~]# ceph osd set noout

    2. 登录托管 OSD 容器的节点。
    3. /etc/systemd/system/ceph-osd@.service 单元文件备份到 /root 目录。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 文件移到 /root

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. 编辑 /etc/systemd/system/ceph-osd@.service 单元文件,并在 podman 命令中添加 -it --entrypoint /bin/bash 选项。

      示例

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
      [Unit]
      Description=Ceph OSD
      After=network.target
      
      [Service]
      EnvironmentFile=-/etc/environment
      ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
      ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
      ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
        -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
        --rm \
        --net=host \
        --privileged=true \
        --pid=host \
        --ipc=host \
        --cpus=2 \
        -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 \
        -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
        -e CLUSTER=ceph \
        -v /run/lvm/:/run/lvm/ \
        -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
        -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
        -e OSD_ID=%i \
        -e DEBUG=stayalive \
        --name=ceph-osd-%i \
         \
        registry.redhat.io/rhceph/rhceph-4-rhel8:latest
      ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
      KillMode=none
      Restart=always
      RestartSec=10s
      TimeoutStartSec=120
      TimeoutStopSec=15
      Type=forking
      PIDFile=/%t/%n-pid
      
      [Install]
      WantedBy=multi-user.target

    6. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    7. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 替换为 OSD 的 ID。

      示例

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

    8. 登录与 OSD_ID 关联的容器。

      语法

      podman exec -it ceph-osd-OSD_ID /bin/bash

      示例

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. 获取 osd fsid 并激活 OSD 以挂载 OSD 的逻辑卷(LV)。

      语法

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
      ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      示例

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
                    osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
      [root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
      Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
      Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
       stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
      Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
       stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
      Running command: /usr/bin/systemctl start ceph-osd@0
       stderr: Running in chroot, ignoring request: start
      --> ceph-volume lvm activate successful for osd ID: 0

  2. 验证适当的 OSD 是否停机:

    语法

    systemctl status ceph-osd@OSD_NUMBER

    示例

    [root@osd ~]# systemctl status ceph-osd@1

  3. 获取对象映射标头:

    语法

    ceph-objectstore-tool --data-path PATH_TO_OSD \
    --pgid PG_ID OBJECT \
    get-omaphdr > OBJECT_MAP_FILE_NAME

    示例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
    --pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
    get-omaphdr > zone_info.default.omaphdr.txt

  4. 设置对象映射标头:

    语法

    ceph-objectstore-tool --data-path PATH_TO_OSD \
    --pgid PG_ID OBJECT \
    get-omaphdr < OBJECT_MAP_FILE_NAME

    示例

    [root@osd ~]# su - ceph -c 'ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
    --pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
    set-omaphdr < zone_info.default.omaphdr.txt

  5. 对于容器化部署,要恢复更改,请按照以下步骤执行:

    1. 退出容器后,从 /root 目录中复制 /etc/systemd/system/ceph-osd@.service 单元文件。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
      [root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 文件移到 /tmp

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

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

      示例

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

其它资源

10.4.6. 操作对象映射密钥

使用 ceph-objectstore-tool 实用程序更改对象映射(OMAP)密钥。您需要提供数据路径、放置组标识符(PG ID)、对象和 OMAP 中的密钥。

先决条件

  • Ceph OSD 节点的根级别访问权限.
  • 停止 ceph-osd 守护进程.

流程

  1. 对于容器化部署,要访问 bluestore 工具,请按照以下步骤执行:

    1. 在集群中设置 noout 标志。

      示例

      [root@mon ~]# ceph osd set noout

    2. 登录托管 OSD 容器的节点。
    3. /etc/systemd/system/ceph-osd@.service 单元文件备份到 /root 目录。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 文件移到 /root

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. 编辑 /etc/systemd/system/ceph-osd@.service 单元文件,并在 podman 命令中添加 -it --entrypoint /bin/bash 选项。

      示例

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
      [Unit]
      Description=Ceph OSD
      After=network.target
      
      [Service]
      EnvironmentFile=-/etc/environment
      ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
      ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
      ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
        -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
        --rm \
        --net=host \
        --privileged=true \
        --pid=host \
        --ipc=host \
        --cpus=2 \
        -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 \
        -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
        -e CLUSTER=ceph \
        -v /run/lvm/:/run/lvm/ \
        -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
        -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
        -e OSD_ID=%i \
        -e DEBUG=stayalive \
        --name=ceph-osd-%i \
         \
        registry.redhat.io/rhceph/rhceph-4-rhel8:latest
      ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
      KillMode=none
      Restart=always
      RestartSec=10s
      TimeoutStartSec=120
      TimeoutStopSec=15
      Type=forking
      PIDFile=/%t/%n-pid
      
      [Install]
      WantedBy=multi-user.target

    6. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    7. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 替换为 OSD 的 ID。

      示例

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

    8. 登录与 OSD_ID 关联的容器。

      语法

      podman exec -it ceph-osd-OSD_ID /bin/bash

      示例

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. 获取 osd fsid 并激活 OSD 以挂载 OSD 的逻辑卷(LV)。

      语法

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
      ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      示例

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
                    osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
      [root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
      Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
      Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
       stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
      Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
       stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
      Running command: /usr/bin/systemctl start ceph-osd@0
       stderr: Running in chroot, ignoring request: start
      --> ceph-volume lvm activate successful for osd ID: 0

  2. 获取对象映射键:

    语法

    ceph-objectstore-tool --data-path PATH_TO_OSD \
    --pgid PG_ID OBJECT \
    get-omap KEY > OBJECT_MAP_FILE_NAME

    示例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
    --pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
    get-omap "" > zone_info.default.omap.txt

  3. 设置对象映射键:

    语法

    ceph-objectstore-tool --data-path PATH_TO_OSD \
    --pgid PG_ID OBJECT \
    set-omap KEY < OBJECT_MAP_FILE_NAME

    示例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
    --pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
    set-omap "" < zone_info.default.omap.txt

    • 删除对象映射键:

      语法

      ceph-objectstore-tool --data-path PATH_TO_OSD \
      --pgid PG_ID OBJECT \
      rm-omap KEY

      示例

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
      --pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
      rm-omap ""

  4. 对于容器化部署,要恢复更改,请按照以下步骤执行:

    1. 退出容器后,从 /root 目录中复制 /etc/systemd/system/ceph-osd@.service 单元文件。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
      [root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 文件移到 /tmp

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

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

      示例

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

其它资源

10.4.7. 列出对象的属性

使用 ceph-objectstore-tool 实用程序列出对象的属性。输出为您提供对象的键和值。

先决条件

  • Ceph OSD 节点的根级别访问权限.
  • 停止 ceph-osd 守护进程.

流程

  1. 验证适当的 OSD 是否停机:

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

    示例

    [root@osd ~]# systemctl status ceph-osd@1

  2. 对于容器化部署,要访问 bluestore 工具,请按照以下步骤执行:

    1. 在集群中设置 noout 标志。

      示例

      [root@mon ~]# ceph osd set noout

    2. 登录托管 OSD 容器的节点。
    3. /etc/systemd/system/ceph-osd@.service 单元文件备份到 /root 目录。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 文件移到 /root

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. 编辑 /etc/systemd/system/ceph-osd@.service 单元文件,并在 podman 命令中添加 -it --entrypoint /bin/bash 选项。

      示例

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
      [Unit]
      Description=Ceph OSD
      After=network.target
      
      [Service]
      EnvironmentFile=-/etc/environment
      ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
      ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
      ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
        -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
        --rm \
        --net=host \
        --privileged=true \
        --pid=host \
        --ipc=host \
        --cpus=2 \
        -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 \
        -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
        -e CLUSTER=ceph \
        -v /run/lvm/:/run/lvm/ \
        -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
        -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
        -e OSD_ID=%i \
        -e DEBUG=stayalive \
        --name=ceph-osd-%i \
         \
        registry.redhat.io/rhceph/rhceph-4-rhel8:latest
      ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
      KillMode=none
      Restart=always
      RestartSec=10s
      TimeoutStartSec=120
      TimeoutStopSec=15
      Type=forking
      PIDFile=/%t/%n-pid
      
      [Install]
      WantedBy=multi-user.target

    6. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    7. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 替换为 OSD 的 ID。

      示例

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

    8. 登录与 OSD_ID 关联的容器。

      语法

      podman exec -it ceph-osd-OSD_ID /bin/bash

      示例

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. 获取 osd fsid 并激活 OSD 以挂载 OSD 的逻辑卷(LV)。

      语法

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
      ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      示例

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
                    osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
      [root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
      Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
      Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
       stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
      Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
       stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
      Running command: /usr/bin/systemctl start ceph-osd@0
       stderr: Running in chroot, ignoring request: start
      --> ceph-volume lvm activate successful for osd ID: 0

  3. 列出对象的属性:

    ceph-objectstore-tool --data-path PATH_TO_OSD \
    --pgid PG_ID OBJECT \
    list-attrs

    示例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
    --pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
    list-attrs

  4. 对于容器化部署,要恢复更改,请按照以下步骤执行:

    1. 退出容器后,从 /root 目录中复制 /etc/systemd/system/ceph-osd@.service 单元文件。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
      [root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 文件移到 /tmp

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

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

      示例

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

其它资源

10.4.8. 操作对象属性键

使用 ceph-objectstore-tool 实用程序更改对象的属性。若要操作对象的属性,您需要数据和日志路径、放置组标识符(PG ID)、对象以及对象属性中的密钥。

先决条件

  • Ceph OSD 节点的根级别访问权限.
  • 停止 ceph-osd 守护进程.

流程

  1. 验证适当的 OSD 是否停机:

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

    示例

    [root@osd ~]# systemctl status ceph-osd@1

  2. 对于容器化部署,要访问 bluestore 工具,请按照以下步骤执行:

    1. 在集群中设置 noout 标志。

      示例

      [root@mon ~]# ceph osd set noout

    2. 登录托管 OSD 容器的节点。
    3. /etc/systemd/system/ceph-osd@.service 单元文件备份到 /root 目录。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 文件移到 /root

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. 编辑 /etc/systemd/system/ceph-osd@.service 单元文件,并在 podman 命令中添加 -it --entrypoint /bin/bash 选项。

      示例

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
      [Unit]
      Description=Ceph OSD
      After=network.target
      
      [Service]
      EnvironmentFile=-/etc/environment
      ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
      ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
      ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
        -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
        --rm \
        --net=host \
        --privileged=true \
        --pid=host \
        --ipc=host \
        --cpus=2 \
        -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 \
        -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
        -e CLUSTER=ceph \
        -v /run/lvm/:/run/lvm/ \
        -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
        -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
        -e OSD_ID=%i \
        -e DEBUG=stayalive \
        --name=ceph-osd-%i \
         \
        registry.redhat.io/rhceph/rhceph-4-rhel8:latest
      ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
      KillMode=none
      Restart=always
      RestartSec=10s
      TimeoutStartSec=120
      TimeoutStopSec=15
      Type=forking
      PIDFile=/%t/%n-pid
      
      [Install]
      WantedBy=multi-user.target

    6. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    7. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 替换为 OSD 的 ID。

      示例

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

    8. 登录与 OSD_ID 关联的容器。

      语法

      podman exec -it ceph-osd-OSD_ID /bin/bash

      示例

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. 获取 osd fsid 并激活 OSD 以挂载 OSD 的逻辑卷(LV)。

      语法

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
      ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      示例

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
                    osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
      [root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
      Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
      Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
      Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
      Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
      Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
       stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
      Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
       stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
      Running command: /usr/bin/systemctl start ceph-osd@0
       stderr: Running in chroot, ignoring request: start
      --> ceph-volume lvm activate successful for osd ID: 0

  3. 获取对象的属性:

    语法

    ceph-objectstore-tool --data-path PATH_TO_OSD \
    --pgid PG_ID OBJECT \
    get-attrs KEY > OBJECT_ATTRS_FILE_NAME

    示例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
    --pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
    get-attrs "oid" > zone_info.default.attr.txt

  4. 设置对象的属性:

    语法

    ceph-objectstore-tool --data-path PATH_TO_OSD \
    --pgid PG_ID OBJECT \
    set-attrs KEY < OBJECT_ATTRS_FILE_NAME

    示例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
    --pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
    set-attrs "oid" < zone_info.default.attr.txt

  5. 删除对象的属性:

    语法

    ceph-objectstore-tool --data-path PATH_TO_OSD \
    --pgid PG_ID OBJECT  \
    rm-attrs KEY

    示例

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
    --pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
    rm-attrs "oid"

  6. 对于容器化部署,要恢复更改,请按照以下步骤执行:

    1. 退出容器后,从 /root 目录中复制 /etc/systemd/system/ceph-osd@.service 单元文件。

      示例

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
      [root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. 重新加载 systemd 管理器配置。

      示例

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 文件移到 /tmp

      示例

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. 重新启动与 OSD_ID 关联的 OSD 服务。

      语法

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

      示例

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

其它资源

10.5. 其它资源

第 11 章 联系红帽支持服务

如果本指南中的信息没有帮助您解决问题,本章将向您阐述如何联系 Red Hat 支持服务。

11.1. 先决条件

  • 红帽支持帐户.

11.2. 为红帽支持工程师提供信息

如果您无法修复与 Red Hat Ceph Storage 相关的问题,请联络红帽支持服务并提供足够数量的信息,以帮助支持工程师更快地解决遇到的问题。

先决条件

  • 节点的根级别访问权限。
  • 红帽支持帐户.

流程

  1. 红帽客户门户网站中创建一个支持问题单
  2. 理想情况下,请将 sosreport 附加到 ticket。详情请参阅 sosreport,以及如何在 Red Hat Enterprise Linux 4.6 及更新的版本中创建 sosreport。
  3. 如果 Ceph 守护进程失败并显示分段错误,请考虑生成人类可读的核心转储文件。详情请参阅生成可读的核心转储文件

11.3. 生成可读的核心转储文件

当 Ceph 守护进程意外终止分段错误时,请收集关于其故障的信息,并将其提供给红帽支持工程师。

此类信息可加快初步调查的速度。此外,支持工程师还可以将核心转储文件中的信息与红帽 Ceph 存储集群已知问题进行比较。

11.3.1. 先决条件

  1. 安装 ceph-debuginfo 软件包(如果尚未安装)。

    1. 启用包含 ceph-debuginfo 软件包的存储库:

      Red Hat Enterprise Linux 7:

      subscription-manager repos --enable=rhel-7-server-rhceph-4-DAEMON-debug-rpms

      根据 Ceph 节点的类型,将 DAEMON 替换为 osdmon

      Red Hat Enterprise Linux 8:

      subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-debug-rpms

    2. 安装 ceph-debuginfo 软件包:

      [root@mon ~]# yum install ceph-debuginfo
  2. 确定安装了 gdb 软件包,如果未安装,请安装它:

    [root@mon ~]# yum install gdb

根据部署类型继续执行此步骤:

11.3.2. 在裸机部署中生成可读的核心转储文件

如果您在裸机上使用 Red Hat Ceph Storage,请按照以下步骤生成核心转储文件。

流程

  1. 为 Ceph 生成核心转储文件。

    1. 通过在 /etc/systemd/system.conf 文件中添加以下参数,为 内核转储文件设置正确的 u limit:

      DefaultLimitCORE=infinity
    2. 注释掉 Ceph 守护进程服务文件中的 PrivateTmp=true 参数,默认位于 /lib/systemd/system/CLUSTER_NAME-DAEMON@.service

      [root@mon ~]# PrivateTmp=true
    3. suid_dumpable 标志设置为 2,以允许 Ceph 守护进程生成转储核心文件:

      [root@mon ~]# sysctl fs.suid_dumpable=2
    4. 调整内核转储文件位置:

      [root@mon ~]# sysctl kernel.core_pattern=/tmp/core
    5. 通过在 [Coredump] 部分中添加以下行修改 /etc/systemd/coredump.conf 文件:

      ProcessSizeMax=8G
      ExternalSizeMax=8G
      JournalSizeMax=8G
    6. 重新载入 systemd 服务以使更改生效:

      [root@mon ~]# systemctl daemon-reload
    7. 重启 Ceph 守护进程使更改生效:

      [root@mon ~]# systemctl restart ceph-DAEMON@ID

      指定守护进程类型(osdmon)及其 ID(OSD 的数字,或 monitor 的短主机名),例如:

      [root@mon ~]# systemctl restart ceph-osd@1
  2. 重现失败,例如尝试再次启动 守护进程。
  3. 使用 GNU Debugger(GDB)从应用程序核心转储文件中生成可读回追踪:

    gdb /usr/bin/ceph-DAEMON /tmp/core.PID

    指定失败进程的守护进程类型和 PID,例如:

    $ gdb /usr/bin/ceph-osd /tmp/core.123456

    在 GDB 命令提示中,输入设置 pag 并设置日志的命令来禁用分页并启用文件日志

    (gdb) set pag off
    (gdb) set log on

    通过输入 bt full,将 backtrace 命令应用到进程的所有线程:

    (gdb) thr a a bt full

    在生成回溯追踪后,输入 设置的 log off 来关闭 日志记录:

    (gdb) set log off
  4. 将日志文件 gdb.txt 传输到您访问红帽客户门户的系统,并将其附加到支持票据。

11.3.3. 在容器化部署中生成可读的核心转储文件

如果您在容器中使用 Red Hat Ceph Storage,请按照以下步骤生成核心转储文件。该流程涉及捕获内核转储文件的两个场景:

  • 当 Ceph 进程因为 SIGILL、SIGTRAP、SIGABRT 或 SIGSEGV 错误而意外终止时。

  • 例如,用于调试 Ceph 进程等问题的手动消耗 CPU 周期较高,或者没有响应。

先决条件

  • 对运行 Ceph 容器的容器节点的根级别访问权限。
  • 安装适当的调试软件包。
  • 安装 GNU Project Debugger(gdb)软件包。

流程

  1. 如果 Ceph 进程因为 SIGILL、SIGTRAP、SIGABRT 或 SIGSEGV 错误意外终止:

    1. 在运行失败 Ceph 进程的容器的节点上,将内核模式设置为 systemd-coredump 服务,例如:

      [root@mon]# echo "| /usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" > /proc/sys/kernel/core_pattern
    2. 监视由于 Ceph 进程导致的下一个容器失败,并在 /var/lib/systemd/coredump/ 目录中搜索内核转储文件,例如:

      [root@mon]# ls -ltr /var/lib/systemd/coredump
      total 8232
      -rw-r-----. 1 root root 8427548 Jan 22 19:24 core.ceph-osd.167.5ede29340b6c4fe4845147f847514c12.15622.1584573794000000.xz
  2. 为 Ceph 监控器和 Ceph Manager 手动捕获核心转储文件

    1. 从容器中获取 Ceph 守护进程的 ceph-mon 软件包详情:

      Red Hat Enterprise Linux 7:

      [root@mon]# docker exec -it NAME /bin/bash
      [root@mon]# rpm -qa | grep ceph

      Red Hat Enterprise Linux 8:

      [root@mon]# podman exec -it NAME /bin/bash
      [root@mon]# rpm -qa | grep ceph

      NAME 替换为 Ceph 容器的名称。

    2. 创建备份副本并打开 以编辑 ceph-mon@.service 文件:

      [root@mon]# cp /etc/systemd/system/ceph-mon@.service /etc/systemd/system/ceph-mon@.service.orig
    3. ceph-mon@.service 文件中,将这三个选项添加到 [Service] 部分,每个选项位于单独的行上:

      --pid=host \
      --ipc=host \
      --cap-add=SYS_PTRACE \

      示例

      [Unit]
      Description=Ceph Monitor
      After=docker.service
      
      [Service]
      EnvironmentFile=-/etc/environment
      ExecStartPre=-/usr/bin/docker rm ceph-mon-%i
      ExecStartPre=/bin/sh -c '"$(command -v mkdir)" -p /etc/ceph /var/lib/ceph/mon'
      ExecStart=/usr/bin/docker run --rm --name ceph-mon-%i \
        --memory=924m \
      --cpu-quota=100000 \
      -v /var/lib/ceph:/var/lib/ceph:z \
        -v /etc/ceph:/etc/ceph:z \
        -v /var/run/ceph:/var/run/ceph:z \
      -v /etc/localtime:/etc/localtime:ro \
      --net=host \
      --privileged=true \
      --ipc=host \ 1
      --pid=host \ 2
      --cap-add=SYS_PTRACE \ 3
      -e IP_VERSION=4 \
              -e MON_IP=10.74.131.17 \
            -e CLUSTER=ceph \
        -e FSID=9448efca-b1a1-45a3-bf7b-b55cba696a6e \
        -e CEPH_PUBLIC_NETWORK=10.74.131.0/24 \
        -e CEPH_DAEMON=MON \
         \
        registry.access.redhat.com/rhceph/rhceph-3-rhel7:latest
      ExecStop=-/usr/bin/docker stop ceph-mon-%i
      ExecStopPost=-/bin/rm -f /var/run/ceph/ceph-mon.pd-cephcontainer-mon01.asok
      Restart=always
      RestartSec=10s
      TimeoutStartSec=120
      TimeoutStopSec=15
      
      [Install]
      WantedBy=multi-user.target

    4. 重启 Ceph 监控守护进程:

      语法

      systemctl restart ceph-mon@MONITOR_ID

      MONITOR_ID 替换为 Ceph monitor 的 ID 号。

      示例

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

    5. 在 Ceph 监控容器中安装 gdb 软件包:

      Red Hat Enterprise Linux 7:

      [root@mon]# docker exec -it ceph-mon-MONITOR_ID /bin/bash
      sh $ yum install gdb

      Red Hat Enterprise Linux 8:

      [root@mon]# podman exec -it ceph-mon-MONITOR_ID /bin/bash
      sh $ yum install gdb

      MONITOR_ID 替换为 Ceph monitor 的 ID 号。

    6. 查找进程 ID:

      语法

      ps -aef | grep PROCESS | grep -v run

      PROCESS 替换为失败进程的名称,如 ceph-mon

      示例

      [root@mon]# ps -aef | grep ceph-mon | grep -v run
      ceph       15390   15266  0 18:54 ?        00:00:29 /usr/bin/ceph-mon --cluster ceph --setroot ceph --setgroup ceph -d -i 5
      ceph       18110   17985  1 19:40 ?        00:00:08 /usr/bin/ceph-mon --cluster ceph --setroot ceph --setgroup ceph -d -i 2

    7. 生成内核转储文件:

      语法

      gcore ID

      ID 替换为您在上一步中获取的失败进程的 ID,例如 18110

      示例

      [root@mon]# gcore 18110
      warning: target file /proc/18110/cmdline contained unexpected null characters
      Saved corefile core.18110

    8. 验证核心转储文件是否已正确生成。

      示例

      [root@mon]# ls -ltr
      total 709772
      -rw-r--r--. 1 root root 726799544 Mar 18 19:46 core.18110

    9. 在 Ceph 监控容器外部复制内核转储文件:

      Red Hat Enterprise Linux 7:

      [root@mon]# docker cp ceph-mon-MONITOR_ID:/tmp/mon.core.MONITOR_PID /tmp

      Red Hat Enterprise Linux 8:

      [root@mon]# podman cp ceph-mon-MONITOR_ID:/tmp/mon.core.MONITOR_PID /tmp

      MONITOR_ID 替换为 Ceph monitor 的 ID 号,并将 MONITOR_PID 替换为进程 ID 号。

    10. 恢复 ceph-mon@.service 文件的备份副本:

      [root@mon]# cp /etc/systemd/system/ceph-mon@.service.orig /etc/systemd/system/ceph-mon@.service
    11. 重启 Ceph 监控守护进程:

      语法

      systemctl restart ceph-mon@MONITOR_ID

      MONITOR_ID 替换为 Ceph monitor 的 ID 号。

      示例

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

    12. 上传内核转储文件以获取红帽支持分析,请参阅第 4 步。
  3. Ceph OSD 手动捕获核心转储文件:

    1. 从容器中获取 Ceph 守护进程的 ceph-osd 软件包详情:

      Red Hat Enterprise Linux 7:

      [root@osd]# docker exec -it NAME /bin/bash
      [root@osd]# rpm -qa | grep ceph

      Red Hat Enterprise Linux 8:

      [root@osd]# podman exec -it NAME /bin/bash
      [root@osd]# rpm -qa | grep ceph

      NAME 替换为 Ceph 容器的名称。

    2. 在运行 Ceph 容器的节点中,为同一版本的 ceph-osd 软件包安装 Ceph 软件包:

      Red Hat Enterprise Linux 7:

      [root@osd]# yum install ceph-osd

      Red Hat Enterprise Linux 8:

      [root@osd]# dnf install ceph-osd

      如果需要,请先启用适当的存储库。详情请参阅《安装指南 》中的启用红帽 Ceph 存储存储库 一节。

    3. 查找失败的进程的 ID:

      ps -aef | grep PROCESS | grep -v run

      PROCESS 替换为失败进程的名称,如 ceph-osd

      [root@osd]# ps -aef | grep ceph-osd | grep -v run
      ceph       15390   15266  0 18:54 ?        00:00:29 /usr/bin/ceph-osd --cluster ceph --setroot ceph --setgroup ceph -d -i 5
      ceph       18110   17985  1 19:40 ?        00:00:08 /usr/bin/ceph-osd --cluster ceph --setroot ceph --setgroup ceph -d -i 2
    4. 生成内核转储文件:

      gcore ID

      ID 替换为您在上一步中获取的失败进程的 ID,例如 18110

      [root@osd]# gcore 18110
      warning: target file /proc/18110/cmdline contained unexpected null characters
      Saved corefile core.18110
    5. 验证核心转储文件是否已正确生成。

      [root@osd]# ls -ltr
      total 709772
      -rw-r--r--. 1 root root 726799544 Mar 18 19:46 core.18110
    6. 上传内核转储文件供红帽支持分析,请参见下一步。
  4. 将核心转储文件上传至红帽支持问题单中。详情请参阅向红帽支持工程师提供信息

11.3.4. 其它资源

附录 A. Ceph 子系统默认日志记录级别值

各种 Ceph 子系统的默认日志记录级别值表。

子系统日志级别内存级别

asok

1

5

auth

1

5

buffer

0

0

客户端

0

5

context

0

5

crush

1

5

default

0

5

filer

0

5

bluestore

1

5

finisher

1

5

heartbeatmap

1

5

javaclient

1

5

journaler

0

5

journal

1

5

lockdep

0

5

mds balancer

1

5

mds locker

1

5

mds log expire

1

5

mds log

1

5

mds migrator

1

5

mds

1

5

monc

0

5

周一

1

5

ms

0

5

objclass

0

5

objectcacher

0

5

objecter

0

0

optracker

0

5

osd

0

5

paxos

0

5

perfcounter

1

5

rados

0

5

rbd

0

5

rgw

1

5

throttle

1

5

timer

0

5

tp

0

5

法律通告

Copyright © 2023 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.