ceph组件的状态

发表于 | 分类于 | 浏览 次

Ceph 整体状态查看

1
2
3
ceph -s  #ceph状态是否正常，及配置运行状态
ceph -w  #实时查看数据写入情况
ceph health detail #如果集群有问题，会详细列出具体的pg或者osd

mon

mon相关状态

1
ceph quorum_status -f json-pretty

client 无法链接mon的可能原因

  1. 连通性和防火墙规则。在MON主机上修改允许TCP 端口6789的访问。
  2. 磁盘空间。每个MON主机上必须有超过5%的空闲磁盘空间使MON和levelDB数据库正常工作。
  3. MON没有工作或者离开选举，检查如上命令输出结果中的quorum_status和mon_status或者ceph -s 的输出来确定失败的MON进程，尝试重启或者部署一个新的来替代它。

MON 状态表

状态 说明
probing 正在探测态。这意味着MON正在寻找其他的MON。当MON启动时， MON尝试找在monmap定义的其他剩余的MON。在多MON的集群中，直到MON找到足够多的MON构建法定选举人数之前，它一直在这个状态。这意味着如果3个MON中的2个挂掉，剩余的1个MON将一直在probing状态，直到启动其他的MON中的1个为止。
electing 正在选举态。这意味着MON正在选举中。这应该很快完成，但有时也会卡在正这，这通常是因为MON主机节点间的时钟偏移导致的.
synchronizing 正在同步态。这意味着MON为了加入到法定人数中和集群中其他的MON正在同步.
leader或peon 领导态或员工态。这不应该出现。然而有机会出现，一般和时钟偏移有很大关系

时钟偏移警告

MON可能被MON节点之间的重要的时钟偏移激烈的影响。这经常会转变为没有明显原因的诡异的行为。为了避免这种问题，应该在MON节点上运行一个时间同步的工具。默认最大容忍的时钟偏移为0.05s，虽然可以修改，但不建议修改，这是官方开发和QA认可的值。私自未经测试修改虽然无数据丢失风险，可能会对MON集群和总体集群健康导致意外的作用。 如果遇到这个告警，同步时钟，在MON上运行NTP的客户端会有帮助。如果经常遇到这个问题，可能是因为使用了远端的NTP服务器，请考虑在内网部署NTP服务器。

OSD

OSD 状态表

状态 说明
up osd启动
down osd停止
in osd在集群中
out osd不在集群中，默认OSD down 超过300s,Ceph会标记为out，会触发重新平衡操作
up & in 说明该OSD正常运行，且已经承载至少一个PG的数据。这是一个OSD的标准工作状态
up & out 说明该OSD正常运行，但并未承载任何PG，其中也没有数据。一个新的OSD刚刚被加入Ceph集群后，便会处于这一状态。而一个出现故障的OSD被修复后，重新加入Ceph集群时，也是处于这一状态
down & in 说明该OSD发生异常，但仍然承载着至少一个PG，其中仍然存储着数据。这种状态下的OSD刚刚被发现存在异常，可能仍能恢复正常，也可能会彻底无法工作
down & out 说明该OSD已经彻底发生故障，且已经不再承载任何PG

常见问题

  1. 硬盘失败。可以通过系统日志或SMART活动确认。有些有缺陷的硬盘因为密集的有时限的错误修复活动变的很慢。
  2. 网络连接问题。可以使用ping、iperf等普通网络工具进行调试。
  3. OSD文件存储的磁盘空间不足。 磁盘到85%将会触发HEALTH_WARN告警。磁盘到95%会触发HEALTH_ERR告警，OSD为了避免填满磁盘会停止。
  4. 超过系统资源限制。系统内存应该足够主机上所有的OSD进程，打开文件句柄数和最大线程数也应该是足够的。
    OSD进程处理心跳的限制导致进程自杀。默认的处理和通信超时不足以执行IO饥饿型的操作，尤其是失败后的恢复。这经常会导致OSD闪断的现象出现。

暂时关闭pg重新平衡

在维护操作或解决问题时，不希望在停止一些OSD后，超时的OSD被标记为out后，CRUSH算法自动进行重新平衡操作。需要执行集群关闭out检测命令：

1
ceph osd set noout

这样在停止的OSD中的PG会变为降级态。当维护操作完成后，需要先启动停止的OSD，再恢复默认设置：

1
ceph osd unset noout

老/慢 请求

如果一个OSD服务进程很慢地响应请求。它会产生一个请求耗时过久超过30秒的警告提示信息。

1
2
{date} {osd.num} [WRN] 1 slow requests, 1 included below; oldest blocked for > 30.005692 secs
{date} {osd.num}  [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]
  1. 可能的原因和修复方法包括：
  2. 硬盘故障（检查dmesg的输出信息）；替换为正常的硬盘
  3. 内核文件系统bug（检查dmesg的输出信息确）；升级内核
  4. 集群负载过高（检查系统负载、iostat等）；机器扩容，尝试降低系统负载
  5. ceph-osd服务进程的的bug；升级ceph或重启OSD

OSD 闪断

OSD重启或恢复中后，OSD在peering状态一直闪断。因为IO密集型的任务导致影响心跳检测异常，你可以暂时为集群通过打开nodown noup选项。执行命令：

1
2
3
ceph osd set nodown 
ceph osd set noup  
ceph osd set noout

当集群健康稳定后，执行如下命令恢复默认值：

1
2
3
ceph osd unset nodown  
ceph osd unset noup  
ceph osd unset noout

确认磁盘损坏

检查日志，执行如下命令：

1
2
3
4
5
6
7
8
9
dmesg | egrep sd[a­]
eg:
dmesg |egrep sda

通过smartctl提取信息和执行测试检查可疑的设备:
smartctl a /dev/sda

通过观察响应时间确认。任何磁盘持续显示不常见的值可能会失败：
iostat x /dev/sda

###替换osd数据磁盘
当集群规模比较大，磁盘出硬件故障是一个常态。为了维持集群规模稳定，必须及时的修复因硬盘故障停止的OSD。 因为Ceph采用了多个副本的策略，一般情况下，不需要恢复坏掉硬盘的数据。用一个新硬盘初始化一个OSD即可。操作步骤如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
两种情况：
a. 如果磁盘坏掉osd会标记为down，默认300秒osd会被标记为out，数据会开始迁移。所以我们替换osd数据磁盘，确保数据迁移完成，集群状态是ok。
b. 如果磁盘将要损坏，但还没有坏，仍然是up&in的，则需要先把该osd 设置为out: ceph osd out osd.0,这样集群会把osd.0的数据 rebalancing and copying到其他机器上去。直到整个集群编程active+clean，再进行后续操作

1. 关闭 osd.0的进程
systemctl stop ceph-osd@0

2. 删除旧osd信息(osd.0为例)：
ceph osd crush remove osd.0
ceph auth del osd.0
ceph osd rm 0

3. 创建新osd
a. ceph osd create #会自动生成uuid和osd-number
b. ssh {new_osd_host}
c. sudo mkdir /var/lib/ceph/osd/ceph-{osd-number}  #上一步生成的osd-number
d. 分区 通过parted把osd的磁盘分区为一个分区
e. sudo mkfs -t xfs /dev/{drive} # 上一步分区
f. sudo mount /dev/{sdx} /var/lib/ceph/osd/ceph-{osd-number}
g. ceph-osd -i {osd-number} --mkfs --mkkey   # 初始化osd数据目录
目录必须为空
h. ceph auth add osd.{osd-number} osd 'allow *' mon 'allow rwx' -i /var/lib/ceph/osd/ceph-{osd-number}/keyring #注册认证key
i. ceph osd crush add osd.{osd-number}# 添加osd到crush map，则该osd可以接受数据了，这个时候osd的状态为 down & in。ceph osd crush add osd.0 1.0 host=bj-yh-ceph-node2
j. systemctl start ceph-osd@{osd-number} # 启动osd进程，数据会rebalancing and migrating 到新的osd上

替换ssd日志磁盘

由于我们使用过程中，一块ssd分4个区，给4个osd使用，所以如果ssd日志磁盘坏掉，需要给对应的osd都要操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
1. 设置OSD状态为noout，防止数据重新平衡
ceph osd set noout

2. 停止osd进程
ssh {ssd所在节点}
systemctl stop ceph-osd@x  #ssd所对应的osds

3. 日志数据落盘到数据盘
ceph-osd -i {osd-number} --flush-journal #该ssd日志分区所对应的所有osd-number

4. 删除日志链接
rm -rf /var/lib/ceph/osd/{osd-number}/journal # #该ssd日志分区所对应的所有osd-number

5. 创建日志链接
ln -s /dev/disk/by-partuuid/{uuid} /var/lib/ceph/osd/ceph-{osd-number}/journal # 注意别把使用中的分区给绑定错了
chown ceph:ceph /var/lib/ceph/osd/ceph-{osd-number}/journal
echo {uuid} > /var/lib/ceph/osd/ceph-{osd-number}/journal_uuid  #前面/dev/disk/by-partuuid/{uuid} uuid

6. 创建日志
ceph-osd -i {osd-number} --mkjournal

7. 启动osd进程
systemctl start ceph-osd@{osd-number}

如果所有osd进程都起来了

8. 去除noout的标记
ceph osd set noout

PG

ceph health detail #正常会返回 ok

PG 状态表

正常是active+clean

状态 描述
active 活跃状态。ceph将处理到达这个PG的读写请求
unactive 非活跃状态。该PG不能处理读写请求
clean 干净状态。Ceph复制PG内所有对象到设定正确的数目
unclean 非干净状态。PG不能从上一个失败中恢复
down 离线状态。有必需数据的副本挂掉，比如对象所在的3个副本的OSD挂掉，所以PG离线
degraded 降级状态。ceph有些对象的副本数目没有达到系统设置，一般是因为有OSD挂掉
inconsistent 不一致态。Ceph 清理和深度清理后检测到PG中的对象在副本存在不一致，例如对象的文件大小不一致或recovery结束后一个对象的副本丢失
peering 正在同步状态。PG正在执行同步处理
recovering 正在恢复状态。Ceph正在执行迁移或同步对象和他们的副本
incomplete 未完成状态。实际的副本数少于min_size。Ceph检测到PG正在丢失关于已经写操作的信息，或者没有任何健康的副本。如果遇到这种状态，尝试启动失败的OSD，这些OSD中可能包含需要的信息或者临时调整副本min_size的值到允许恢复。
stale 未刷新状态。PG状态没有被任何OSD更新，这说明所有存储这个PG的OSD可能down
backfilling 正在后台填充状态。 当一个新的OSD加入集群后，Ceph通过移动一些其他OSD上的PG到新的OSD来达到新的平衡；这个过程完成后，这个OSD可以处理客户端的IO请求。
remapped 重新映射状态。PG活动集任何的一个改变，数据发生从老活动集到新活动集的迁移。在迁移期间还是用老的活动集中的主OSD处理客户端请求，一旦迁移完成新活动集中的主OSD开始处理。

PG 长时间卡在一些状态

遇到失败后PG进入如 “degraded” 或 “peering”的状态是正常的。通常这些状态指示失败恢复处理过程中的正常继续。然而，一个PG长时间保持在其中一些状态可能是一个更大问题的提示。因此，MON当PG卡在一个非正常态时会警告。 我们特别地检查：

  1. inactive : PG太长时间不在active态，例如PG长时间不能处理读写请求，通常是peering的问题。
  2. unclean : PG太长时间不在clean态，例如PG不能完成从上一个失败的恢复，通常是unfound objects导致。
  3. stale : PG状态未被OSD更新，表示所有存储PG的OSD可能挂掉，一般启动相应的OSD进程即可。

在MON节点执行如下命令，可以明确列出卡住的PG：

1
2
3
ceph pg dump_stuck stale
ceph pg dump_stuck inactive
ceph pg dump_stuck unclean
1
2
3
4
5
6
7
8
9
Ceph清理和深度清理后到PG处于inconsistent态：

清理操作被用来检查对象的可用性和健康状态。当集群没有IO密集型（例如恢复）的操作时PG被清理，已经执行清理操作再执行IO密集操作，然而清理操作继续。如果清理任务发现任何对象有损坏或者不匹配的数据（校验和检测），它将标记这个对象为不能使用并且需要手动介入和恢复。OSD执行写操作时计算校验和，Ceph并不能武断地决定副本中的哪个校验和是正确的。例如有3个副本的校验和，有1个不同，很容易猜出应该修复的错误副本（从其他副本恢复），但是当有3个不同的校验和或者一些比特错误，我们不能武断的说哪个是好的。这不是一个端到端的数据修正检查。

手动修复损坏的pg

1. 找到有不一致对象的PG， 执行如下命令 ceph pg dump | grep inconsistent 或者 ceph health detail
2. 当主副本是正确数据时，执行修复命令。或者通过在OSD的硬盘上手动复制正确的文件覆盖掉错误的文件。 ceph pg repair {pgnum}
   注意：如果主副本错误，应该使用手动修复，如果通过命令修复则会把主副本的错误数据复制到其他副本。

incomplete PG

这个告警是因为实际副本数少于min_size。可能是由于PG对应的OSD挂掉导致。尝试启动挂掉的OSD。

stale PG

简单地重启受影响的OSD。当一个OSD不能映射它持有所有的对象时这个问题发生,执行如下操作：

  1. 找到PG

    1
    ceph pg dump_stuck stale

  2. 映射pg，找到osd：

    1
    ceph pg map {pgname}

  3. 重启上面的osd

    1
    2
    ssh {osd-node}
    systemctl restart ceph-osd@{osd-number}

peering 和 down PG

  1. 找到受影响的pg

    1
    ceph health detail

  2. 下面命令响应结果中的 [“recovery_state”][“blocked”]部分显示peering被停止 的原因,大多数的情况都是一些OSD挂掉。

    1
    ceph pg {pgname} query

  3. 尝试重启上面挂掉的OSD，如果无法启动，应该为执行如下命令标记为lost，让恢复操作开始。

    1
    ceph osd lost {osd-number}

unfound objects

在特殊的失败组合下Ceph会警告unfound objects。这意味着存储集群知道有些对象存在，但是却无法找到它的副本。下面的例子说明这是怎么发生的，有1个PG他映射的的OSD是 1和2：

  1. OSD 1挂掉

  2. OSD 2单独处理一些请求

  3. OSD 1运行

  4. OSD 1和2重新peering，1上丢失的对象在队列中等待恢复

  5. 在新对象之前被复制之前，OSD2挂掉
    现在OSD 1知道一些对象存在，但是没有这个副本活的OSD。 这种情况下，到这些对象的IO将被阻塞，集群希望失败的OSD快速地回来。这时假设返回一个IO错误给用户是适当的。
    修复建议：

  6. 启动停止的osd

  7. 如果还无法恢复，你可能只有放弃丢失的对象。执行如下命令回滚或删除对象：

    1
    2
    3
    4
    5
    6
    ceph pg  {pgname}  mark_unfound_lost revert|delete
    revert选项：回滚到对象的前一个版本
    delete选项：完全删除这个对象
    使用这个操作时注意，因为它可能是使预期存在这个对象的程序混乱。
    列出带有丢失对象的PG的名字：
    ceph pg {pgname} list_missing
Donate