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

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

节点的故障检测是分布式体系无法躲避的问题，集群须要感知节点的存活，并作出恰当的调剂。平日我们采取心跳的方法来进行故障检测，并认为能正常与外界保持心跳的节点便可以或许正常供给办事。一个好的故障检测策略应当可以或许做到：

及时：节点产生异常如宕机或收集中断时，集群可以在可接收的时光范围内感知；
恰当的压力：包含对节点的压力，和对收集的压力；
容忍收集颤抖
扩散机制：节点存活状况改变导致的元信息变更须要经由过程某种机制扩散到全部集群；

不合的分布式体系因为其本身的构造不合，以及对一致性、可用性、可扩大性的需求不合，会针对以上几点作出不合的决定或弃取。下面我们就来看看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_grace(20)：多久没有收到答复可以认为对方已经down

OSD向Monitor报告请示伙伴OSD掉效

1. OSD发送缺点申报

OSD周期性的检查failure_queue中的伙伴OSD掉败信息；
向Monitor发送掉效申报，并将掉败信息参加failure_pending队列，然后将其大年夜failure_queue移除；
收到来自failure_queue或者failure_pending中的OSD的心跳时，将其大年夜两个队列中移除，并告诉Monitor撤消之前的掉效申报；
当产生与Monitor收集重连时，会将failure_pending中的缺点申报加回到failure_queue中，并再次发送给Monitor。

2. Monitor统计下线OSD

Monitor收集来自OSD的伙伴掉效申报；

当缺点申报指向的OSD掉效跨越必定阈值，且有足够多的OSD申报其掉效时，将该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的缺点申报

OSD到Monitor心跳

OSD当有pg状况改变等事宜产生，或达到必定的时光距离后，会向Monitor发送MSG_PGSTATS消息，这里称之为OSD到Monitor的心跳。
Monitor收到消息，答复MSG_PGSTATSACK，并记录心跳时光到last_osd_report。
Monitor周期性的检查所有OSD的last_osd_report，发明掉效的节点，并标记为Down。

参数：

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的实现方法来懂得其设计思路。

及时：伙伴OSD可以在秒级发明节点掉效并报告请示Monitor，并在几分钟内由Monitor将掉效OSD下线。当然，因为Ceph对一致性的请求，这个过程中客户端写入会弗成避免的被壅塞；
恰当的压力：因为有伙伴OSD报告请示机制，Monitor与OSD之间的心跳统计更像是一种保险办法，是以OSD向Monitor发送心跳的距离可以长达600秒，Monitor的检测阈值也可以长达900秒。Ceph实际上是将故障检测过程中中间节点的压力分散到所有的OSD上，以此进步中间节点Monitor的靠得住性，进而进步全部集群的可扩大性；
容忍收集颤抖：Monitor收到OSD对其伙伴OSD的报告请示后，并没有立时将目标OSD下线，而是周期性的等待几个前提：1，目标OSD的掉效时光大年夜于经由过程固定量osd_heartbeat_grace和汗青收集前提动态肯定的阈值；2，来自不合主机的报告请示达到mon_osd_min_down_reporters。3，知足前两个前提前掉效报告请示没有被源OSD撤消。
扩散：作为中间节点的Monitor并没有在更新OSDMap后测验测验广播通知所有的OSD和Client，而是惰性的等待OSD和Client来获取。以词攀来削减Monitor压力并简化交互逻辑。

【编辑推荐】

分布式体系的核心——日记
OpenStack应用Ceph存储，Ceph到底做了什么?

1/2 1 2 下一页尾页

　　推荐阅读

　　AR游戏觉醒，或将成为手游未来独角兽

近日上映的科幻片子《银翼杀手2049》也是大年夜获口碑，在IMDB网站上已经拥有高达8.5的评分。比赛无论是背景情况、音乐会、照样AI女友，也都应用了已经在市场上应用广泛的AR技巧，人们对将>>>详细阅读

本文标题：从Ceph看分布式系统故障检测

地址：http://www.17bianji.com/lsqh/39926.html

1/2 1