故障定位和处理

Ceph总体健康查看

想观察Ceph集群的健康状态，用下面命令：

简单状态

ceph -s

详细健康状态

包括一些附加信息和调试输出

ceph health detail

配置、运行状态和计数器的报告

ceph report

日志

Ceph核心组件的日志在/var/log/ceph目录。默认每天转存一个日志文件并压缩，保存7天，可以修改/etc/logrotate.d/ceph配置文件改变默认配置。默认的调试级别很多时候不能满足。Ceph后台服务进程允许通过动态参数注入改变调试级别。

远程动态注入

ceph tell osd.0 injectargs debug osd 5/5

这个方法需要MON连接，如果有问题，请用下面的本地注入方法

本地动态注入

需要在OSD所在机器执行

ceph admin daemon /var/run/ceph/ceph­osd.0.asok config set debug_osd 5/5

启动时注入

修改配置文件/etc/ceph/ceph.conf

日志选项格式

debug {subsystem} = {log-level}/{memory-level}

常用的subsystem: rados、crush、osd、 filestore、 ms、mon、 auth

例如：

[global]
        debug ms = 1/5
[mon]
        debug mon = 20
        debug paxos = 1/5
        debug auth = 2
[osd]
        debug osd = 1/5
        debug filestore = 1/5
        debug journal = 1
        debug monc = 5/20
[mds]
        debug mds = 1
        debug mds balancer = 1
        debug mds log = 1
        debug mds migrator = 1

Ceph的日志子系统是非常广泛和消耗资源的，它可以在极短的时间内产生大量数据。注意把日志级别调高后产生大量日志导致硬盘空间不足问题。输出调试信息日志是一个非常耗时的，你应该注意在最佳性能测试时应确保日志关闭。建议在日常环境下保持合理的低日志级别，只有在定位问题时再调高日志级别。

MON

对集群对重要的是MON实例，所以故障定位和恢复也从这些实例开始。

显示选举状态、MON状态、 PAXOS算法状态命令

ceph quorum_status format 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进程挂掉，持续地监控集群健康状态是很重要的。硬件失败包括很难确认和不可预知的固件和物理失败是一些原因。可能一些软件Bug同样导致错误断言和OSD进程异常退出。

OSD状态表

状态 说明
up OSD启动
down OSD停止
in OSD在集群中
out OSD不在集群，默认OSD down 超过300s,Ceph会标记为out，会触发重新平衡操作

常见问题

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

暂时关闭PG重新平衡

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

ceph osd set noout

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

ceph osd unset noout

老/慢请求

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

老版本 ‘old requests`:

osd.0 192.168.106.220:6800/18813 312 : [WRN] old request osd_op(client.5099.0:790 fatty_26485_object789 [write 0~4096] 2.5e54f643) v4 received at 2012-03-06 15:42:56.054801 currently waiting for sub ops

新版本 ‘slow requests`:

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

可能的原因和修复方法包括：

  • 硬盘故障（检查dmesg的输出信息）；替换为正常的硬盘
  • 内核文件系统bug（检查dmesg的输出信息确）；升级内核
  • 集群负载过高（检查系统负载、iostat等）；机器扩容，尝试降低系统负载
  • ceph-osd服务进程的的bug；升级ceph或重启OSD

OSD闪断

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

ceph set nodown 
ceph set noup  
ceph set noout

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

ceph unset nodown  
ceph unset noup  
ceph unset noout

怎样确认磁盘失败

日志中应该有关于失败设备的广泛信息，SMART中应该也有一些标志。

  • 检查日志，执行如下命令：
dmesg | egrep sd[a­z
  • 通过smartctl提取信息和执行测试检查可疑的设备：
smartctl a /dev/sdX
  • 通过观察响应时间确认。任何磁盘持续显示不常见的值可能会失败。
iostat x /dev/sdX

替换OSD数据磁盘

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

  • 删除故障OSD旧信息
ceph osd crush remove osd.5
ceph auth del osd.5
ceph osd rm 5
  • 创建新的OSD
ceph-deploy osd create  192.168.2.3:/dev/sde

替换OSD日志磁盘

  • 场景1：日志盘使用SSD和数据盘分区使用SATA普通硬盘分区，日志盘坏掉需要替换新的SSD盘
  • 场景2：日志盘和数据盘使用SATA普通硬盘的2个分区，需要把日志分区替换为SSD盘的分区

如下以OSD 1 替换为新的日志分区/dev/disk/by-partuuid/5bb48687-6be6-4aef-82f6-5af822c3fad8为例说明操作步骤。

  • 设置OSD状态为noout，防止数据重新平衡

    ceph osd set noout

  • 停止OSD进程

 systemctl stop ceph-osd@1
  • 日志数据落盘到数据盘
ceph-osd -i 1 --flush-journal
  • 删除日志链接
rm -rf /var/lib/ceph/osd/ceph-1/journal
  • 创建日志链接
ln -s /dev/disk/by-partuuid/5bb48687-6be6-4aef-82f6-5af822c3fad8 /var/lib/ceph/osd/ceph-1/journa
chown ceph:ceph /var/lib/ceph/osd/ceph-1/journal
echo 5bb48687-6be6-4aef-82f6-5af822c3fad8 > /var/lib/ceph/osd/ceph-1/journal_uuid

  • 创建日志

    ceph-osd -i 1 --mkjournal

  • 启动OSD进程

systemctl start ceph-osd@1
  • 去除noout的标记
    ceph osd set noout

PG问题处理

ceph health detail

PG状态

正常的PG状态是 100%的active + clean， 这表示所有的PG是可访问的，所有副本都对全部PG都可用。如果Ceph也报告PG的其他的警告或者错误状态。

PG状态表：

状态 描述
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卡在一个非正常态时会警告。 我们特别地检查：

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

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

ceph pg dump_stuck stale
ceph pg dump_stuck inactive
ceph pg dump_stuck unclean

当一个新Pool被创建后经过一段合理的时间没有达到active+clean状态，这很有可能是么有配置、CRUSH map或者资源太少不足以到达配置的副本级别，这种情况在很多新手测试时容易发生。 例如：

  1. OSD的数目少于副本数，如集群只有2个OSD但是配置Pool的副本数为3
  2. 集群只有一个Host，但是ruleset 设置的副本选取策略为Host而不是OSD，导致永远无法选取设置的副本数目。你需要修改ruleset中osd crush chooseleaf type的默认值host为osd，这表示PG的OSD可以在同一Host上。。

Ceph清理和深度清理后到PG处于inconsistent态

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

手动修复损坏的PG的步骤：

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

注意，如果主副本错误，应该使用手动修复，如果通过命令修复则会把主副本的错误数据复制到其他副本。

incomplete PG

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

stale PG

简单地重启受影响的OSD。当一个OSD不能映射它持有所有的对象时这个问题发生。

修复步骤如下：

  1. 找到PG，执行命令：

    ceph pg dump_stuck stale

  2. 映射PG,找到OSD，执行命令：

    ceph pg map {pgname}

  3. 重启上面的OSD

peering 和 down PG

修复步骤如下：

  1. 找到受影响的PG，执行命令：

    ceph health detail

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

    ceph pg {pgname} query

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

 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错误给用户是适当的。

修复建议：

  1. 启动停止的OSD
  2. 如果还无法恢复，你可能只有放弃丢失的对象。执行如下命令回滚或删除对象：
ceph pg  {pgname}  mark_unfound_lost revert|delete

revert选项：回滚到对象的前一个版本

delete选项：完全删除这个对象

使用这个操作时注意，因为它可能是使预期存在这个对象的程序混乱。

列出带有丢失对象的PG的名字：

ceph pg {pgname} list_missing

YY云平台运维中遇到的一些问题

总体来看，集群的可用性和可靠性还是很高的，运行至今还未发生整个集群不可用的情况，在运维过程中遇到一些典型问题，现总结如下供读者参考。

大量OSD进程crash

  • 问题描述：部署252个OSD节点的集群后，出现大量OSD进程crash，而在7个OSD的测试节点无此问题。
  • 问题级别：严重
  • 故障原因：因OSD 默认采用流水线多线程模型，一个OSD和其他OSD间需要心跳、命令、数据传输等多个线程，在集群规模到达252时，一个进程使用的线程达780，而默认jewel版本 systemd启动配置文件中TasksMax为512，这导致大量的OSD crash。
  • 解决方案：
    1. TasksMax改为更大的值，如1024
    2. Jewel版本正式async messager达到可用级，可用在配置文件中设置ms-type = async 完成切换，告别海量线程的痛苦。

硬盘故障

  • 问题描述：OSD 进程crash，访问硬盘目录报Input/Output error错误，无法访问数据；重启机器后恢复。这个硬盘的OSD频繁出现这个问题。
  • 问题级别：一般
  • 故障原因：厂家未给出原因，可能是硬件故障
  • 解决方案：厂家更换硬盘，参考本章中的【怎样替换坏掉的OSD磁盘】处理

MON主机宕机

  • 问题描述：MON主机宕机，MON集群剩余2个节点，还能正常工作
  • 问题级别：一般
  • 故障原因：硬盘故障导致机器宕机
  • 解决方案：更换系统盘后，参考官网文档【新增一个MON节点】重新添加MON节点

OSD主机load 飙升到1000多

  • 问题描述：通过监控系统告警发现，在一段时间内出现多个ceph主机load飙升到1000多，导致多个OSD Crash和Ceph 监控ERR级别告警，导致一些IO请求变慢。
  • 问题级别：严重
  • 故障原因：因Ubuntu 默认安装的OS probe服务（OS 系统探测服务）定期探测分区，导致OSD日志分区异常，使OSD crash，进而触发apport服务（crash信息自动收集服务）导致load瞬间升高。
  • 解决方案：卸载无用的系统服务OS probe和apport

RBD cache数据不一致性

  • 问题描述：XSKY内部的产品一次一致性压力测试中，因为对接其他云平台测试不小心打开了 rbd cache，在压测时发现严重的不一致现象。社区近期在CephFS 侧发现这个问题，这个问题同时影响了 RBD Cache 和 CephFS 打开 Cache 的场景。
  • 问题级别：严重
  • 故障原因：在大块读时，ObjectCacher 模块读后端计算的 offset/length 错误导致的。在大块场景较容易复现。这个 Bug 实际上已经存在非常久远，这意味着所有 Ceph 云平台需要迅速关闭所有 VM 的 RBD Cache。
  • bug地址： http://tracker.ceph.com/issues/16547
  • 解决方案：关闭rbd cache。 虽然对性能有些影响，但保证数据一致性更重要。

升级10.2.0到 10.2.2版本

  • 问题描述：社区近期发布了10.2.2版本，修改很多OSD和librbd的bug。需要跟随社区进行版本升级
  • 问题级别：一般
  • 解决方案：参考【常用维护操作】中【升级Ceph软件版本】

results matching ""

    No results matching ""