1. 检查集群的整体状态：

   # ceph health detail

   如果命令返回 HEALTH_WARN 或 HEALTH_ERR，详情请参阅 第 1.2 节 “了解 ceph health 命令的输出”。

2. 检查 Ceph 日志中是否列出 第 1.3 节 “了解 Ceph 日志” 中列出的任何错误消息。日志默认位于 /var/log/ceph/ 目录中。
3. 如果日志没有包含足够数量的信息，提高调试级别并尝试重现失败的操作。详情请查看 第 2 章 配置日志记录。
4. 使用 ceph-medic 实用程序诊断存储集群。如需了解更多详细信息 ，请参阅《红帽 Ceph 存储 3 管理指南》的使用 ceph-medic 诊断 Ceph 存储集群 部分。

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

   systemctl status ceph-mon@<host-name>
   systemctl start ceph-mon@<host-name>

   使用运行守护进程的主机的短名称替换 <host-name>。不确定时使用 hostname -s 命令。

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

1. 检查对应的 monitor 日志，默认位于 /var/log/ceph/ceph-mon.<host-name>.log。

2. 如果日志包含类似于下列错误消息的错误消息，monitor 可能具有损坏的存储：

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

   要解决这个问题，请替换 monitor。请参阅 第 4.4 节 “替换失败的 monitor”。

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

   Caught signal (Bus error)

   重要

   不要手动从 monitor 目录中删除任何数据。反之，使用 ceph-monstore-tool 紧凑它。详情请查看 第 4.5 节 “压缩 monitor 存储”。

4. 如果您看到任何其他错误消息，请打开支持票据。详情请查看 第 9 章 联系红帽支持服务。

1. 在没有仲裁的 monitor 主机中，使用 mon_status 命令检查其状态：

   ceph daemon <id> mon_status

   使用 monitor ID 替换 <id>，例如：

   # ceph daemon mon.a mon_status

2. 如果状态为 探测，请验证 mon_status 输出中其他 monitor 的位置。

   1. 如果地址不正确，monitor 带有不正确的 monitor 映射(monmap)。要解决这个问题，请参阅 第 4.2 节 “注入 monitor map”。
   2. 如果地址正确，请验证 monitor 时钟是否已同步。详情请查看 第 4.1.2 节 “时钟偏移”。另外，对任何网络问题进行故障排除，请参阅 第 3 章 网络问题故障排除。
3. 如果状态为选中状态 ， 请验证 monitor 时钟是否同步。请参阅 第 4.1.2 节 “时钟偏移”。
4. 如果状态从 选择 同步变为 同步，请打开支持票据。详情请查看 第 9 章 联系红帽支持服务。
5. 如果 monitor 是 领导 机或工作 机， 请验证 monitor 时钟是否已同步。请参阅 第 4.1.2 节 “时钟偏移”。如果同步时钟无法解决问题，请打开支持问题单。详情请查看 第 9 章 联系红帽支持服务。

1. 验证您的网络是否正常工作。详情请查看 第 3 章 网络问题故障排除。特别是，如果您使用 NTP，则对 NTP 客户端的任何问题进行故障排除。如需更多信息，请参阅 第 3.2 节 “基本 NTP 故障排除”。
2. 如果您使用远程 NTP 服务器，请考虑在网络上部署您自己的 NTP 服务器。详情请查看 Red Hat Enterprise Linux 7 的《系统管理员指南》 中的使用 ntpd 配置 NTP 一章。
3. 如果您不使用 NTP 客户端，请设置一个。详情请参阅 Red Hat Enterprise Linux 或 Ubuntu 的红帽 Ceph 存储 3 安装指南中的为 红帽 Ceph 存储配置网络时间协议 一节。
4. 如果您使用虚拟机托管 monitor，请将其移至裸机主机。不支持使用虚拟机托管 monitor。详情请查看红帽客户门户网站中的 Red Hat Ceph Storage: 支持的配置 文章。

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. 紧凑 monitor 存储.详情请查看 第 4.5 节 “压缩 monitor 存储”。

1. 验证 PG 计数是否足够，并在需要时增加。详情请查看 第 7.5 节 “增加 PG 数量”。
2. 验证您是否使用最优于集群版本的 CRUSH 可调项，如果不是，请进行调整。详情请查看红帽 Ceph 存储 3 存储 3 存储策略 指南中的 CRUSH 可调项小节 ，以及如何测试对红帽客户门户上红帽 Ceph 存储中 OSD 的 PG 分布的影响 CRUSH map 可调项。
3. 根据利用率更改 OSD 的权重。请参阅红帽 Ceph 存储 3 的存储策略指南中的设置 OSD Weight by Utilization 部分。

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

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

      # ceph osd df

   2. 查看 OSD 在特定节点上使用的空间：从包含 nearful OSD 的节点运行以下命令：

      $ df

   3. 如果需要，添加新 OSD 节点。请参阅《红帽 Ceph 存储 3 管理指南 》中的 添加和删除 OSD 节点 章节。

1. 确定哪个 OSD 为 down:

   # 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 守护进程：

   systemctl restart ceph-osd@<OSD-number>

   使用 down 的 OSD 的 ID 替换 <OSD-number>，例如：

   # systemctl restart ceph-osd@0

   1. 如果您无法启动 ceph-osd，请按照 ceph-osd 守护进程中的步骤启动。
   2. 如果您能够启动 ceph-osd 守护进程，但标记为 down，请按照 ceph-osd 守护进程正在运行但仍标记为 down 的步骤操作。

1. 如果您有一个包含多个 OSD 的节点（通常比 12 多个 OSD），请验证默认最多线程数（PID 数）是否足够。详情请查看 第 5.5 节 “增加 PID 数量”。

2. 验证 OSD 数据和日志分区是否已正确挂载：

   # ceph-disk list
   ...
   /dev/vdb :
    /dev/vdb1 ceph data, prepared
    /dev/vdb2 ceph journal
   /dev/vdc :
    /dev/vdc1 ceph data, active, cluster ceph, osd.1, journal /dev/vdc2
    /dev/vdc2 ceph journal, for /dev/vdc1
   /dev/sdd1 :
    /dev/sdd1 ceph data, unprepared
    /dev/sdd2 ceph journal

   如果 ceph-disk 将分区标记为 active，则会挂载分区。如果分区是 prepared，挂载它。详情请查看 第 5.3 节 “挂载 OSD 数据分区”。如果分区是 unprepared，则必须在挂载前首先准备它。请参阅《红帽 Ceph 存储 3 管理指南 》中的准备 OSD 数据和日志驱动器一节。

3. 如果您收到 ERROR: missing keyring, cannot use cephx for authentication 错误消息，则 OSD 缺少密钥环。请参阅《红帽 Ceph 存储 3 管理指南》 中的 密钥环管理部分。

4. 如果您收到 ERROR: unable to open OSD superblock on /var/lib/ceph/osd/ceph-1 错误消息，ceph-osd 守护进程将无法读取底层文件系统。有关如何排除故障并修复此错误的说明，请参阅以下步骤。

   注意

   如果在 OSD 主机引导期间返回此错误消息，请打开支持票据，因为这可能表示 在红帽 Bugzilla 1439210 中跟踪了一个已知问题。详情请查看 第 9 章 联系红帽支持服务。

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

   1. 类似于以下内容的 EIO 错误消息表示底层磁盘失败：

      FAILED assert(!m_filestore_fail_eio || r != -5)

      为修复此问题，请替换底层 OSD 磁盘。详情请查看 第 5.4 节 “替换 OSD 驱动器”。

   2. 如果日志包含任何其他 FAILED assert 错误，如以下错误，请打开支持票据。详情请查看 第 9 章 联系红帽支持服务。

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

6. 检查 dmesg 输出是否有底层文件系统或磁盘的错误：

   $ dmesg

   1. error -5 错误消息类似如下，表示底层 XFS 文件系统崩溃。有关如何解决这个问题的详情，请查看红帽客户门户网站中的 "xfs_log_force: error -5 返回"? 解决方案的含义。

      xfs_log_force: error -5 returned

   2. 如果 dmesg 输出包含任何 SCSI error 错误消息，请参阅红帽客户门户网站中的 SCSI Error Codes Solution Finder 解决方案，以确定解决问题的最佳方法。
   3. 或者，如果您无法修复底层文件系统，请替换 OSD 驱动器。详情请查看 第 5.4 节 “替换 OSD 驱动器”。

7. 如果 OSD 因分段错误而出现故障，如以下 OSD，请收集必要的信息并打开支持票据。详情请查看 第 9 章 联系红帽支持服务。

   Caught signal (Segmentation fault)

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

   1. 如果日志包含类似以下的错误消息，请参阅 第 5.1.4 节 “Flapping OSD”。

      wrongly marked me down
      heartbeat_check: no reply from osd.2 since back

   2. 如果您看到任何其他错误，请打开支持票据。详情请查看 第 9 章 联系红帽支持服务。

1. 再次检查 ceph health detail 命令的输出。如果包含 slow requests 错误消息，请参阅 第 5.1.5 节 “请求速度较慢，请求被阻塞” 了解如何排除此问题的详情。

   # 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 的节点上，对任何网络问题进行故障排除并修复。详情请查看 第 3 章 网络问题故障排除。

4. 或者，您可以通过设置 noup 和 nodown 标志来临时强制监控器停止将 OSD 标记为 down 和 up ：

   # ceph osd set noup
   # ceph osd set nodown

   重要

   使用 noup 和 nodown 标志不会修复造成问题的根本原因，而是只防止 OSD 崩溃。如果无法自行修复并对错误进行故障排除，请打开支持票据。详情请查看 第 9 章 联系红帽支持服务。

5. 此外，可以通过在 Ceph 配置文件中设置 osd heartbeat min size = 100，然后重新启动 OSD，来修复 flapping OSD。这会导致因为 MTU 错误配置解决了网络问题。

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

2. 如果 OSD 共享磁盘：

   1. 使用 smartmontools 工具检查磁盘或日志的健康状况，以确定磁盘中的任何错误。

      注意

      smartmontools 工具包括在 smartmontools 软件包中。

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

      注意

      iostat 工具包括在 sysstat 软件包中。

3. 如果 OSD 共享主机：

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

1. 确定哪些 PG 是 stale，以及它们存储在哪些 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 的所有问题进行故障排除。详情请查看 第 5.1.3 节 “个或更多 OSD 发生故障”。

1. 确定处于 inconsistent 状态的 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. 确定放置组为 inconsistent 的原因。

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

      ceph pg deep-scrub <id>

      使用 inconsistent 放置组的 ID 替换 <id>，例如：

      # ceph pg deep-scrub 0.6
      instructing pg 0.6 on osd.0 to deep-scrub

   2. 搜索 ceph -w 的输出与该放置组相关的信息：

      ceph -w | grep <id>

      使用 inconsistent 放置组的 ID 替换 <id>，例如：

      # 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. 如果输出包含类似以下的错误消息，您可以修复 inconsistent 放置组。详情请查看 第 7.4 节 “修复事件 PG”。

   <pg.id> shard <osd>: soid <object> missing attr _, missing attr <attr 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. 如果输出包含类似以下的错误消息，则无法安全地修复 inconsistent 放置组，因为您可以丢失数据。在这种情况下创建一个支持问题单。详情请查看 第 9 章 联系红帽支持服务。

   <pg.id> shard <osd>: soid <object> digest <digest> != known digest <digest>
   <pg.id> shard <osd>: soid <object> omap_digest <digest> != known omap_digest <digest>

1. 确定哪些 OSD 为 down:

   # ceph osd tree

2. 对 OSD 进行故障排除和修复任何问题。详情请查看 第 5.1.3 节 “个或更多 OSD 发生故障”。

1. 确定哪些 OSD 为 down:

   # ceph osd tree

2. 对 OSD 进行故障排除和修复任何问题。详情请查看 第 5.1.3 节 “个或更多 OSD 发生故障”。

1. osd.1 进入 down。
2. osd.2 处理一些写入操作。
3. osd.1 发送至 up。
4. osd.1 和 osd.2 之间的对等进程启动，osd.1 中缺少的对象排队以进行恢复。
5. 在 Ceph 复制新对象之前，osd.2 转到 down。

1. 确定哪个 PG 包含 unfound 对象：

   # 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 的更多信息：

   # ceph pg <id> query

   使用包含 unfound 对象的 PG 的 ID 替换 <id>，例如：

   # 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"}],

   might_have_unfound 部分包含 Ceph 尝试查找 unfound 对象的 OSD：

   • already probed 状态表示 Ceph 无法找到该 OSD 中的 unfound 对象。
   • osd is down 状态表示 Ceph 无法联系该 OSD。
3. 对标记为 down 的 OSD 进行故障排除。详情请查看 第 5.1.3 节 “个或更多 OSD 发生故障”。
4. 如果您无法修复导致 OSD 成为 down 的问题，请打开支持票据。详情请查看 第 9 章 联系红帽支持服务。

流程

1. 验证适当的 OSD 是否停机：

   语法

   systemctl status ceph-osd@$OSD_NUMBER

   示例

   [root@osd ~]# systemctl status ceph-osd@1

2. 识别 OSD 内的所有对象，而不考虑 PG:

   语法

   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

3. 识别 PG 中的所有对象：

   语法

   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

4. 识别对象所属的 PG：

   语法

   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

流程

1. 验证适当的 OSD 是否停机：

   语法

   systemctl status ceph-osd@$OSD_NUMBER

   示例

   [root@osd ~]# systemctl status ceph-osd@1

2. 列出所有丢失的旧对象：

   语法

   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

3. 使用 ceph-objectstore-tool 工具修复 丢失和未找到 的对象。选择适当的情况：

   1. 修复所有丢失的对象：

      语法

      ceph-objectstore-tool --data-path $PATH_TO_OSD --op fix-lost

      示例

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op fix-lost

   2. 修复 PG 中丢失的所有对象：

      语法

      ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID --op fix-lost

      示例

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c --op fix-lost

   3. 使用标识符修复丢失的对象：

      语法

      ceph-objectstore-tool --data-path $PATH_TO_OSD --op fix-lost $OBJECT_ID

      示例

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op fix-lost default.region

流程

1. 验证适当的 OSD 是否停机：

   语法

   systemctl status ceph-osd@$OSD_NUMBER

   示例

   [root@osd ~]# systemctl status ceph-osd@1

2. 通过列出 OSD 或 PG(PG)的对象来查找对象。

3. 在对象中设置字节前，请进行备份和对象的工作副本：

   语法

   ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID \
   $OBJECT \
   get-bytes > $OBJECT_FILE_NAME
   
   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

4. 编辑工作复制对象文件，并相应地修改对象内容。

5. 设置对象的字节：

   语法

   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

流程

1. 删除对象：

   语法

   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

流程

1. 验证适当的 OSD 是否停机：

   语法

   systemctl status ceph-osd@$OSD_NUMBER

   示例

   [root@osd ~]# systemctl status ceph-osd@1

2. 列出对象映射：

   语法

   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

流程

1. 验证适当的 OSD 是否停机：

   语法

   systemctl status ceph-osd@$OSD_NUMBER

   示例

   [root@osd ~]# systemctl status ceph-osd@1

   • 获取对象映射标头：

     语法

     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

   • 设置对象映射标头：

     语法

     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":""}'  \
     set-omaphdr < zone_info.default.omaphdr.txt

流程

1. 验证适当的 OSD 是否停机：

   语法

   systemctl status ceph-osd@$OSD_NUMBER

   示例

   [root@osd ~]# systemctl status ceph-osd@1

2. 列出对象的属性：

   语法

   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

流程

1. 验证适当的 OSD 是否停机：

   语法

   systemctl status ceph-osd@$OSD_NUMBER

   示例

   [root@osd ~]# systemctl status ceph-osd@1

   • 获取对象的属性：

     语法

     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

   • 设置对象的属性：

     语法

     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

   • 删除对象的属性：

     语法

     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"

1. 安装 ceph-debuginfo 软件包（如果尚未安装）。

   1. 启用包含 ceph-debuginfo 软件包的软件仓库：

      subscription-manager repos --enable=rhel-7-server-rhceph-3-DAEMON-debug-rpms

      根据节点类型，将 DAEMON 替换为 osd 或 mon。

   2. 安装 ceph-debuginfo 软件包：

      [root@mon ~]# yum install ceph-debuginfo

2. 确定安装了 gdb 软件包，如果没有安装，请安装它：

   [root@mon ~]# yum install gdb

流程

1. 为 Ceph 生成核心转储文件。

   1. 通过在 /etc/systemd/system.conf 文件中添加以下参数，为核心转储文件设置正确的 ulimits ：

      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. 重新载入 systemd 服务以使更改生效：

      [root@mon ~]# systemctl daemon-reload

   6. 重启 Ceph 守护进程使更改生效：

      [root@mon ~]# systemctl restart ceph-DAEMON@ID

      指定守护进程类型（osd 或 mon）及其 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 命令提示中，输入 set pag off 和 set log on 命令禁用分页并启用对文件的日志记录：

   (gdb) set pag off
   (gdb) set log on

   输入 thr a a bt full，将 backtrace 命令应用到进程的所有线程：

   (gdb) thr a a bt full

   在生成回溯追踪后，输入 set log off ：

   (gdb) set log off

4. 将日志文件 gdb.txt 传输到您访问红帽客户门户网站的系统，并将其附加到支持问题单中。

流程

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 软件包详情：

      [root@mon]# docker 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 软件包：

      [root@mon]# docker 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 监控容器外部复制内核转储文件：

      [root@mon]# docker 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 软件包详情：

      [root@osd]# docker exec -it NAME /bin/bash
      [root@osd]# rpm -qa | grep ceph

      将 NAME 替换为 Ceph 容器的名称。

   2. 在运行 Ceph 容器的节点中，为同一版本的 ceph-osd 软件包安装 Ceph 软件包：

      [root@osd]# yum 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. 将核心转储文件上传至红帽支持问题单中。详情请参阅向红帽支持工程师提供信息。