集群运行过程中,总会遇到各种问题,这里汇总一下遇到的问题及解决方法
Ceph 整体状态查看
|
|
Ceph 日志查看
Ceph核心组件的日志在/var/log/ceph目录。默认每天转存一个日志文件并压缩,保存7天,可以修改/etc/logrotate.d/ceph配置文件改变默认配置。
更改日志级别
注意:修改日志级别会,每小时会长1G的数据。输出调试信息日志是一个非常耗时的,应该注意在最佳性能测试时应确保日志关闭。建议在日常环境下保持合理的低日志级别,只有在定位问题时再调高日志级别。
远程动态注入
|
|
本地动态注入
|
|
OSD 启动时注入
系统日志设置
mon
mon相关状态
|
|
client 无法链接mon的可能原因
- 连通性和防火墙规则。在MON主机上修改允许TCP 端口6789的访问。
- 磁盘空间。每个MON主机上必须有超过5%的空闲磁盘空间使MON和levelDB数据库正常工作。
- 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 |
常见问题
- 硬盘失败。可以通过系统日志或SMART活动确认。有些有缺陷的硬盘因为密集的有时限的错误修复活动变的很慢。
- 网络连接问题。可以使用ping、iperf等普通网络工具进行调试。
- OSD文件存储的磁盘空间不足。 磁盘到85%将会触发HEALTH_WARN告警。磁盘到95%会触发HEALTH_ERR告警,OSD为了避免填满磁盘会停止。
- 超过系统资源限制。系统内存应该足够主机上所有的OSD进程,打开文件句柄数和最大线程数也应该是足够的。
OSD进程处理心跳的限制导致进程自杀。默认的处理和通信超时不足以执行IO饥饿型的操作,尤其是失败后的恢复。这经常会导致OSD闪断的现象出现。
暂时关闭pg重新平衡
在维护操作或解决问题时,不希望在停止一些OSD后,超时的OSD被标记为out后,CRUSH算法自动进行重新平衡操作。需要执行集群关闭out检测命令:
这样在停止的OSD中的PG会变为降级态。当维护操作完成后,需要先启动停止的OSD,再恢复默认设置:
老/慢 请求
如果一个OSD服务进程很慢地响应请求。它会产生一个请求耗时过久超过30秒的警告提示信息。
- 可能的原因和修复方法包括:
- 硬盘故障(检查dmesg的输出信息);替换为正常的硬盘
- 内核文件系统bug(检查dmesg的输出信息确);升级内核
- 集群负载过高(检查系统负载、iostat等);机器扩容,尝试降低系统负载
- ceph-osd服务进程的的bug;升级ceph或重启OSD
OSD 闪断
OSD重启或恢复中后,OSD在peering状态一直闪断。因为IO密集型的任务导致影响心跳检测异常,你可以暂时为集群通过打开nodown noup选项。执行命令:
当集群健康稳定后,执行如下命令恢复默认值:
确认磁盘损坏
检查日志,执行如下命令:
###替换osd数据磁盘
当集群规模比较大,磁盘出硬件故障是一个常态。为了维持集群规模稳定,必须及时的修复因硬盘故障停止的OSD。 因为Ceph采用了多个副本的策略,一般情况下,不需要恢复坏掉硬盘的数据。用一个新硬盘初始化一个OSD即可。操作步骤如下:
替换ssd日志磁盘
由于我们使用过程中,一块ssd分4个区,给4个osd使用,所以如果ssd日志磁盘坏掉,需要给对应的osd都要操作
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卡在一个非正常态时会警告。 我们特别地检查:
- inactive : PG太长时间不在active态,例如PG长时间不能处理读写请求,通常是peering的问题。
- unclean : PG太长时间不在clean态,例如PG不能完成从上一个失败的恢复,通常是unfound objects导致。
- stale : PG状态未被OSD更新,表示所有存储PG的OSD可能挂掉,一般启动相应的OSD进程即可。
在MON节点执行如下命令,可以明确列出卡住的PG:
Ceph清理和深度清理后到PG处于inconsistent态
清理操作被用来检查对象的可用性和健康状态。当集群没有IO密集型(例如恢复)的操作时PG被清理,已经执行清理操作再执行IO密集操作,然而清理操作继续。如果清理任务发现任何对象有损坏或者不匹配的数据(校验和检测),它将标记这个对象为不能使用并且需要手动介入和恢复。OSD执行写操作时计算校验和,Ceph并不能武断地决定副本中的哪个校验和是正确的。例如有3个副本的校验和,有1个不同,很容易猜出应该修复的错误副本(从其他副本恢复),但是当有3个不同的校验和或者一些比特错误,我们不能武断的说哪个是好的。这不是一个端到端的数据修正检查。
#### 手动修复损坏的pg
- 找到有不一致对象的PG, 执行如下命令 ceph pg dump | grep inconsistent 或者 ceph health detail
- 当主副本是正确数据时,执行修复命令。或者通过在OSD的硬盘上手动复制正确的文件覆盖掉错误的文件。 ceph pg repair {pgnum}
注意:如果主副本错误,应该使用手动修复,如果通过命令修复则会把主副本的错误数据复制到其他副本。
incomplete PG
这个告警是因为实际副本数少于min_size。可能是由于PG对应的OSD挂掉导致。尝试启动挂掉的OSD。
stale PG
简单地重启受影响的OSD。当一个OSD不能映射它持有所有的对象时这个问题发生,执行如下操作:
找到PG
1ceph pg dump_stuck stale映射pg,找到osd:
1ceph pg map {pgname}重启上面的osd
12ssh {osd-node}systemctl restart ceph-osd@{osd-number}
peering 和 down PG
找到受影响的pg
1ceph health detail下面命令响应结果中的 [“recovery_state”][“blocked”]部分显示peering被停止 的原因,大多数的情况都是一些OSD挂掉。
1ceph pg {pgname} query尝试重启上面挂掉的OSD,如果无法启动,应该为执行如下命令标记为lost,让恢复操作开始。
1ceph osd lost {osd-number}
unfound objects
在特殊的失败组合下Ceph会警告unfound objects。这意味着存储集群知道有些对象存在,但是却无法找到它的副本。下面的例子说明这是怎么发生的,有1个PG他映射的的OSD是 1和2:
- OSD 1挂掉
- OSD 2单独处理一些请求
- OSD 1运行
- OSD 1和2重新peering,1上丢失的对象在队列中等待恢复
- 在新对象之前被复制之前,OSD2挂掉
现在OSD 1知道一些对象存在,但是没有这个副本活的OSD。 这种情况下,到这些对象的IO将被阻塞,集群希望失败的OSD快速地回来。这时假设返回一个IO错误给用户是适当的。
修复建议: - 启动停止的osd
- 如果还无法恢复,你可能只有放弃丢失的对象。执行如下命令回滚或删除对象:123456ceph pg {pgname} mark_unfound_lost revert|deleterevert选项:回滚到对象的前一个版本delete选项:完全删除这个对象使用这个操作时注意,因为它可能是使预期存在这个对象的程序混乱。列出带有丢失对象的PG的名字:ceph pg {pgname} list_missing