ceph原理解析（OSD故障排除万字经验总结）

1.1. 与OSD相关的最常见错误消息，下面我们就来聊聊关于ceph原理解析?接下来我们就一起去了解一下吧!

ceph原理解析

1.1. 与OSD相关的最常见错误消息

下表列出了ceph health detail命令返回或包含在Ceph日志中的最常见错误消息。

与OSD相关的错误消息

Error message

state

full osds

HEALTH_ERR

nearfull osds

HEALTH_WARN

osds are down

HEALTH_WARN

requests are blocked

HEALTH_WARN

slow requests

HEALTH_WARN

与OSD相关的Ceph日志中的常见错误消息

Error message

Log file

heartbeat_check: no reply from osd.X

Main cluster log

wrongly marked me down

Main cluster log

osds have slow requests

Main cluster log

FAILED assert(!m_filestore_fail_eio)

OSD log

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

OSD log

1.1.1. Full OSDs

ceph health detail命令返回类似于以下内容的错误消息：

HEALTH_ERR 1 full osds

osd.3 is full at 95%

这意味着什么：

Ceph可防止客户端在整个OSD节点上执行I/O操作，以避免丢失数据。HEALTH_ERR full osds当集群达到mon_osd_full_ratio参数设置的容量时，它将返回消息。默认情况下，此参数设置为0.95即95％的集群容量。

解决方式：

确定存储使用的百分比（%RAW USED）：

# ceph df

如果%RAW USED超过70-75％，你可以：

• 删除不必要的数据，这是避免生产停止的短时间的解决方案。有关详细信息，请参见第1.6部分“从完整集群中删除数据”。
• 通过添加新的OSD节点来扩展集群。

1.1.2. Nearfull OSDs

ceph health detail命令返回类似于以下内容的错误消息：

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

这意味着什么：

nearfull osds当集群达到mon osd nearfull ratio defaults参数设置的容量时，Ceph返回消息。默认情况下，此参数设置为0.85占集群容量的85％。

Ceph以最佳方式分配基于CRUSH层次结构的数据，但不能保证完全平均分配。数据分布不均匀和nearfull osds消息的主要原因是：

• OSD在集群中的OSD节点之间不平衡。也就是说，一些OSD节点承载的数据明显多于其他OSD节点，或者CRUSH映射中某些OSD的权重不足以满足其容量。
• 根据OSD的数量，用例，每个OSD的目标PG和OSD利用率，放置组（PG）数目不正确。
• 集群使用不适当的CRUSH可调参数。
• OSD的后端存储空间几乎已满。

解决方式：

1. 验证PG数目是否足够，并在需要的时候增加它。

2. 验证您是否使用对集群版本最佳的CRUSH可调参数，如果不是则调整它们。

3 .按利用率更改OSD的权重。

4. 确定OSD使用的磁盘上剩余的空间。

1. a. 查看OSD使用的空间大小：

#ceph osd df

1. b. 查看OSD在特定节点上使用的空间大小。使用包含nearfulOSD 的节点中的以下命令：

$ df -h

1. c. 如果需要，请添加新的OSD节点。

1.1.3. 一个或多个OSD Down掉

运行ceph health命令返回类似于以下错误：

HEALTH_WARN 1/3 in osds are down

这意味着什么：

ceph-osd由于可能的服务故障或与其他OSD通信的问题， 其中一个进程不可用。结果，幸存的ceph-osd守护进程向监视器mon报告了此失败。

如果ceph-osd守护程序未运行，则基础OSD驱动器或文件系统已损坏，或者某些其他错误（例如缺少密钥环keyring）阻止守护程序启动。

在大多数情况下，网络问题会导致ceph-osd守护程序运行但仍标记为的情况down。

解决方式：

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>

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

#systemctl restart ceph-osd@0 a.如果您无法启动ceph-osd，请按照下列步骤的ceph-osd守护进程无法启动。 b.如果您能够启动ceph-osd，但是它被标记为down，请去掉标记n。

该ceph-osd守护程序无法启动

1. 如果你的节点包含多个OSD（通常多于12个），请验证默认的最大线程数（PID数）是否足够。。

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

#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，请安装它。

3. 如果您收到ERROR: missing keyring, cannot use cephx for authentication错误消 息，则OSD是缺少keyring认证。

4. 如果收到ERROR: unable to open OSD superblock on /var/lib/ceph/osd/ceph-1错

误消息，则ceph-osd守护程序无法读取基础文件系统。

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

录中。

1. a. 一个EIO类似下面的一个错误消息表示基础磁盘的故障：

FAILED断言（！m_filestore_fail_eio || r！= -5）

1. 要解决此问题，请更换基础OSD磁盘。
2. b. 如果日志包含任何其他FAILED assert错误（例如以下错误），请详细查看日志。

FAILED断言（0 ==“击中自杀超时”）

6. 检查系统dmesg日志输出以查找基础文件系统或磁盘的错误：

$ dmesg

1. a. 类似于以下error -5错误消息表示底层XFS文件系统的损坏。

xfs_log_force: error -5 returned

1. b. 如果dmesg输出包含任何SCSI error错误消息，则查看磁盘物理连接情况。
2. c. 或者，如果您无法修复基础文件系统，请更换OSD驱动器。

7.如果OSD出现分段故障（如下所示），则查看详细的启动情况。

Caught signal (Segmentation fault)

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

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

中。

1. a. 如果日志包含类似于以下内容的错误消息，请参见第1.1.4节“Flapping OSDs””。

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

1.1.4. Flapping抖动OSD

ceph -w | grep osds命令显示的OSD在短时间内反复up与down：

# ceph -w | grep osds

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

此外，Ceph日志包含类似于以下内容的错误消息：

2016-07-25 03:44:06.510583 osd.50 127.0.0.1:6801/149046 18992 : cluster [WRN] map e600547 wrongly marked me down

2016-07-25 19:00:08.906864 7fa2a0033700 -1 osd.254 609110 heartbeat_check: no reply from osd.2 since back 2016-07-25 19:00:07.444113 front 2016-07-25 18:59:48.311935 (cutoff 2016-07-25 18:59:48.906862)

这意味着什么：

找出OSD反复flapping的主要原因：

• 某些集群操作（例如清理或恢复）会花费异常的时间，例如，如果您对具有大索引或大型放置组的对象执行这些操作。通常，在这些操作完成之后，flapping osd问题会解决。
• 底层物理硬件的问题。在这种情况下，该ceph health detail命令也会返回slow requests错误消息。
• 网络问题。

当公共（前端）网络以最佳方式运行时，如果集群（后端）网络出现故障或显着延迟时，OSD则会无法很好地处理这种情况。

OSD使用集群网络相互发送心跳包以通知它们是up和in状态。如果集群网络无法正常工作，则OSD无法发送和接收心跳包。因此，他们互相报告为down状态，同时将自己标记为up。

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

Parameter

Description

Default value

osd_heartbeat_grace_time

在报告OSD down与监视器之前，OSD等待心跳包返回多长时间。

20 seconds

mon_osd_min_down_reporters

在监视器将OSD标记 为Down之前，有多少OSD必须报告另一个OSD down

1mon_osd_min_down_reports

在监视器将OSD标记 为Down之前，必须报告OSD的Down次数

3

此表显示在默认配置中，mon标记OSD，就down好像只有一个OSD制作了关于第一个OSD的三个不同报告down。在某些情况下，如果一个主机遇到网络问题，整个集群可能会遇到抖动的OSD。这是因为驻留在主机上的OSD将报告集群中的其他OSD down。

解决方式：

1. ceph health detail再次 检查命令的输出。如果它包含slow requests错误消息，请参见1.1.5 部分“Slow Requests, and Requests are Blocked”，以获取有关如何解决此问题的详细信息。

# 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. 在包含拍打OSD的节点上，排除故障并修复任何网络问题。

4.或者，您可以临时强制标记osd为noup，nodown：

# ceph osd set noup # ceph osd set nodown

注意：使用noup和nodown标志不能从根本上解决问题，只能防止OSD抖动。

1.1.5. Slow Requests, and Requests are Blocked

该ceph-osd守护进程是缓慢的，以响应请求和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

此外，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]

这意味着什么：

每个具有慢请求的OSD，其不能在由osd_op_complaint_time参数定义的时间内服务队列中的每秒I/O操作（IOPS）。默认情况下，此参数设置为30秒。

OSD请求缓慢的主要原因是：

• 底层硬件的问题，例如磁盘驱动器，主机，机架或网络交换机。
• 网络问题。这些问题通常与flapping OSD有关。
• 系统负载。

下表显示了慢速请求的类型。使用dump_historic_opsadministration socket命令确定慢速请求的类型。

Slow request type

Description

waiting for rw locks

OSD正在等待获取操作的放置组pg的锁定。

waiting for subops

OSD正在等待副本OSD将操作应用于日志。no flag points reached

OSD没有达到任何重大操作点要求。

waiting for degraded object

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

解决方式：

1. 确定具有慢速或块请求的OSD是否共享一个共同的硬件，例如磁盘驱动器，主机，机架或网络交换机。

2. 如果OSD共享磁盘：

a. 使用该smartmontools工具检查磁盘或日志的运行状况以确定磁盘上的任何错误。

注意：该smartmontools实用程序包含在smartmontools包中。

b. 使用该iostat命令获取%iowai，OSD磁盘上的I/O等待报告(%iowai) 可以确定磁盘是否处于高负载状态。

注意：该iostat工具包含在sysstat包中。

3. 如果OSD在同一主机上：

a. 检查RAM和CPU利用率

b. 使用该netstat实用程序可以查看网络接口控制器（NIC）上的网络统计信息，并解决任何网络问题。

4. 如果OSD在同一机架，请检查机架的网络交换机。例如，如果使用巨型帧，请验证路径中的NIC是否设置了巨型帧。

1.2. Stopping and Starting Rebalancing

当OSD失败或人为停止时，CRUSH算法会自动启动重新平衡过程，以在剩余的OSD中重新分配数据。

重新平衡可能需要些时间和资源，因此，请在故障排除或维护OSD期间停止数据重新平衡。为此，请在停止OSD之前设置noout标志：

# ceph osd set noout

完成故障排除或维护后，取消设置noout标志以开始重新平衡：

# ceph osd unset noout

1.3. 安装OSD数据分区

如果未正确配置OSD数据分区，则ceph-osd守护程序无法启动。如果发现未按预期配置分区，请按照以下的步骤进行安装。

过程：安装OSD数据分区

1. 挂载分区：

# mount -o noatime <partition> /var/lib/ceph/osd/<cluster-name>-<osd-number>

替换<partition>为专用于OSD数据的OSD驱动器上的分区路径。指定集群名称和OSD编号，例 如：# mount -o noatime/dev/sdd1 /var/lib/ceph/osd/ceph-0

2. 尝试启动失败的ceph-osd守护程序：

# systemctl start ceph-osd@<OSD-number>

替换为<OSD-number>OSD的ID，例如：

# systemctl start ceph-osd@0

1.4. 更换OSD驱动器

Ceph专为容错而设计，这意味着它可以在degraded不丢失数据的状态下运行。因此，即使数据存储驱动器发生故障，Ceph也可以运行。在驱动器出现故障的情况下，degraded状态意味着存储在其他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可能由网络故障或者权限等原因造成的。

现代服务器通常使用热插拔驱动器进行部署，因此您可以在不关闭节点的情况下拉出故障驱动器并将其替换为新驱动器。整个过程包括以下步骤：

1. 从Ceph集群中删除OSD。

2. 更换驱动器。

3. 将OSD添加到集群。

在开始之前

1. 确定Down掉的OSD:

# 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

2. 使用如下命令，确认OSD服务已经停止:

# systemctl status ceph-osd@<OSD-number>

替换<OSD-number>为标记为的OSD的ID down，例如：

# systemctl status ceph-osd@osd.0 ... Active: inactive (dead)

过程: 从Ceph集群中删除OSD

1. 标记OSD为out:

# ceph osd out osd.<OSD-number>

替换<OSD-number>为标记为的OSD的ID down，例如：

# ceph osd out osd.0

marked out osd.0.

注意：如果OSD是down，Ceph在没有从OSD接收任何心跳包的900秒后自动将其标记为out。发生 这种情况时，其他带有失败OSD数据副本的OSD开始回填，以确保集群中存在所需的副本数量。当集群回填时，集群将处于某种degraded状态。

2. 确保失败的OSD正在回填。输出将包括类似于以下内容的信息：

# 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：

# ceph osd crush remove osd.<OSD-number>

替换<OSD-number>为标记为的OSD的ID down，例如：

# ceph osd crush remove osd.0 removed item id 0 name 'osd.0' from crush map

4. 删除与OSD相关的身份验证密钥：

# ceph auth del osd.<OSD-number>

替换<OSD-number>为标记为的OSD的ID down，例如：

# ceph auth del osd.0 updated

5. 从Ceph存储集群中删除OSD：

# ceph osd rm osd.<OSD-number>

替换<OSD-number>为标记为的OSD的ID down，例如：

# ceph osd rm osd.0 removed osd.0

如果已成功删除OSD，则以下命令的输出中不存在对应的OSD：

# ceph osd tree

6. 卸载发生故障的驱动器：

# umount /var/lib/ceph/osd/<cluster-name>-<OSD-number>

指定集群的名称和OSD的ID，例如：

# umount /var/lib/ceph/osd/ceph-0/

如果已成功卸载驱动器，则它不会出现在以下命令的输出中：

# df -h

过程：更换物理驱动器

1.有关更换物理驱动器的详细信息。

a.如果您使用Ansible部署集群，请ceph-ansible再次从Ceph管理服务器运行该手册：

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

b.如果手动添加OSD，请确认每一步完整。

2.当驱动器出现在/dev/目录下时，请记下驱动路径。

3.如果要手动添加OSD,请找到OSD驱动器并格式化磁盘。

过程: 将OSD添加到Ceph集群

1. 再次添加OSD.

a. 如果您使用Ansible部署集群，请ceph-ansible再次从Ceph管理服务器运行该手册：

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

b. 如果手动添加OSD，请确认每一步完整。

2.确保CRUSH层次结构准确：

# ceph osd tree

3.如果您对CRUSH层次结构中OSD的位置不满意，请将OSD移动到所需位置：

ceph osd crush move <bucket-to-move> <bucket-type>=<parent-bucket>

例如，要将位于sdd:row1根桶的桶移动到根桶：

# ceph osd crush move ssd:row1 root=ssd:root

1.5. Increasing the PID count

如果你的节点包含超过12个Ceph OSD，则默认的最大线程数（PID数目）可能不足，尤其是在恢复期间。因此，一些ceph-osd守护进程可能会终止并无法再次启动。如果发生这种情况，请增加允许的最大线程数。

临时增加数量：

# sysctl -w kernel.pid.max=4194303

永久增加数量，请/etc/sysctl.conf按如下方式添加配置：

kernel.pid.max = 4194303

1.6. 从完整集群中删除数据

Ceph自动阻止对达到mon_osd_full_ratio参数指定容量的OSD的任何I/O操作，并返回full osds错误消息。

此过程说明如何删除不必要的数据以修复此错误。

注意：该mon_osd_full_ratio参数是在创建集群时设置full_ratio参数值。你不能改变mon_osd_full_ratio之后的值。要暂时增加full_ratio值，请增加pg_full_ratio。

过程：从完整集群中删除数据

1.确定当前值full_ratio，默认情况下设置为0.95：

# ceph pg dump | grep -i full full_ratio 0.95

2.临时增加的价值pg_full_ratio来0.97：

# ceph pg set_full_ratio 0.97

注意：建议不要将pg_full_ratio值设置为高于0.97。将此参数设置为更高的值会使恢复过程更 加困难。因此，您可能根本无法恢复完整的OSD。

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

# ceph pg dump | grep -i full full_ratio 0.97

4. 监控集群状态：

# ceph -w

只要集群从状态更改full为nearfull，就删除任何不必要的数据。

5. 将值设置full ratio为0.95：

# ceph pg set_full_ratio 0.95

6. 验证您是否已成功将参数设置为0.95：

# ceph pg dump | grep -i full full_ratio 0.95

翻译自：https://access.redhat.com/documentation/enus/red_hat_ceph_storage/2/html/troubleshooting_guide/troubleshooting-osds#full-osds

译者：祝祥 新钛云服运维架构师

十年运维经验，曾任刻通云运维工程师、微烛云和某互联网金融平台首席运维架构师。拥有OpenStack、CCIE、阿里云、ZStack等技术认证。有上万台云主机，PB级别分布式存储运维经验。熟悉各种虚拟化技术，软硬件，网络，容器编排等技术，拥有python开发经验。热爱各种开源技术。

,