从Ceph看分布式系统故障检测

节点的故障检测是分布式系统无法回避的问题,集群需要感知节点的存活,并作出适当的调整。通常我们采用心跳的方式来进行故障检测,并认为能正常与外界保持心跳的节点便能够正常提供服务。一个好的故障检测策略应该能够做到:

不同的分布式系统由于其本身的结构不同,以及对一致性、可用性、可扩展性的需求不同,会针对以上几点作出不同的抉择或取舍。下面我们就来看看Ceph是怎么做的。

Ceph故障检测机制

Ceph作为有中心的分布式结构,元信息的维护和更新自然的都由其中心节点Ceph Monitor来负责。节点的存活状态发生改变时,也需要Monitor来发现并更新元信息并通知给所有的OSD节点。最自然的,我们可以想到让中心节点Monitor保持与所有OSD节点之间频繁的心跳,但如此一来,当有成百上千的OSD节点时Monitor变会有比较大的压力。之前在Ceph Monitor and Paxos中介绍过Ceph的设计思路是通过更智能的OSD和Client来减少对中心节点Monitor的压力。同样的,在节点的故障检测方面也需要OSD和Monitor的配合完成。下面的介绍基于当前最新的11.0.0版本。

OSD之间心跳

属于同一个pg的OSD我们称之为伙伴OSD,他们会相互发送PING\PONG信息,并且记录发送和接收的时间。OSD在cron中发现有伙伴OSD相应超时后,会将其加入failure_queue队列,等待后续汇报。

参数:

osd_heartbeat_interval(6): 向伙伴OSD发送ping的时间间隔。实际会在这个基础上加一个随机时间来避免峰值。

osd_heartbeat_grace(20):多久没有收到回复可以认为对方已经down

OSD向Monitor汇报伙伴OSD失效

1. OSD发送错误报告
2. Monitor统计下线OSD

参数:

osd_heartbeat_grace(20): 可以确认OSD失效的时间阈值;

mon_osd_reporter_subtree_level(“host”):在哪一个级别上统计错误报告数,默认为host,即计数来自不同主机的osd报告

mon_osd_min_down_reporters(2): 最少需要多少来自不同的mon_osd_reporter_subtree_level的osd的错误报告

mon_osd_adjust_heartbeat_grace(true):在计算确认OSD失效的时间阈值时,是否要考虑该OSD历史上的延迟,因此失效的时间阈值通常会大于osd_heartbeat_grace指定的值

OSD到Monitor心跳

参数:

mon_osd_report_timeout(900):多久没有收到osd的汇报,Monitor会将其标记为Down;

osd_mon_report_interval_max(600):OSD最久多长时间向Monitor汇报一次;

osd_mon_report_interval_min(5):OSD向Monitor汇报的最小时间间隔

总结

可以看出,Ceph中可以通过伙伴OSD汇报失效节点和Monitor统计来自OSD的心跳两种方式发现OSD节点失效。回到在文章开头提到的一个合格的故障检测机制需要做到的几点,结合Ceph的实现方式来理解其设计思路。

参考

CONFIGURING MONITOR/OSD INTERACTION

SOURCE CODE

Table of Contents