Hey,man,are you ok? -- 关于心跳、故障监测、lease机制

   

  电话之于短信、微信的一个很大的不同点在于,前者更加及时,有更快速直接的反馈;而后面两个虽然称之为instant message,但经常时发出去了就得等对方回复,等多久是不确定的。打电话能明确知道对方在不在,我所表达的信息是否已经传达;而短信或者微信,只知道消息发出去了,但对方是否收到,或者是否查看就不清楚了。

  在通过网络通信的环境下,也是很难知道一个消息对方是否已经处理,因为要知道对方是否处理,依赖于对方的回复(ack),但即使对方没有回复,也不能说明对方就没有处理,也许仅仅是对方回复的那条消息丢失了

  很多时候,一个进程需要判断另外一个进程是否还在工作,如何判断呢?判断是否准确呢,能否保证一致性呢?本文尝试回答这些问题。

  本文中,节点通常就是指一个进程,一个提供服务的进程。后文中,只要不加以强调,进程和节点是同一个意思。

  本文地址:http://www.cnblogs.com/xybaby/p/8710421.html

进程的状态

  一个进程是否crash(在本文中,只要进程是非预期的终止,就成为crash),在单机环境下是很好判断的,只要查看还有没有这个进程就行了。这里有两个问题:

  第一:分布式环境下能否准确判断进程crash?

  第二:是否需要明确一个进程是否crash?

  对于第一个问题,答案是几乎不能的,后面详细分析。

  而第二个问题,有的时候是无需明确一个进程是否已经crash,而需要明确的是该进程是否持续对外提供服务,即使没有crash,如果不按程序的预期工作了(比如进程死循环、死锁、断网),那么也可以说这个服务挂了,“有的人活着,他已经死了”。分布式环境中,我们关心的是,节点(进程)是否对外提供服务,真死(crash)假死(活着但不工作)都是死(从系统的角度看)。

 

  我们称一个对外提供服务的进程处于active状态,否则处于none-active状态。

Failure detection

  如何判断一个进程是否处于active状态,最简单明了的方式就是:每隔一段时间就和这个进程通通信,如果目标进程在一定的时间阈值内回复,那么我们就说这个进程是active的,否则就是none-active的。这种定时通信的策略我们统称为心跳。

  心跳有两种方式:第一种是单向的heartbeat;第二种是ping pong(ping ack)

  在后文中,被检测的进程称之为target,而负责检测的进程称之为detector

  第一种方式,target进程需要告知detector进程自己的存活性,只需要定时给detector发消息就行了,“hi, duddy, I am Ok!”。detector无需给target回复任何消息,detector的任务是,每隔一定时间去检查一下target是否有来汇报,没有的话,detector就认为target处于none-active状态了

  

 

  而第二种方式,ping pong或者ping ack,更为常见:

  detector给target发消息:hi,man,are you ok?

  target回复detector:Yes, I am ok!

  然后detector、target定时重复上面两步

  

 

  detector负责发起检测:如果target连续N次不回复消息,那么detector就可以认为target处于none-active状态了。

  这两种方式,区别在于谁来主动发消息,而相同点在于:谁关心active状态,谁来检测。就是说,不管是简单的heartbeat,还是ping ack,都是detector来检测target的状态。在实际中,ping ack的方式会应用得多一些,因为在ack消息中也可以携带一些信息,比如后文会提到的lease。

gunicorn failure detection

  gunicorn是一个遵循python wsgi的http server,使用了prefork master-worker模型(在gunicorn中,master被称为Arbiter),能够与各种wsgi web框架协作。在本文,关注的是Arbiter进程对Worker进程状态的检测。

  既然Worker进程是Arbiter fork出来的,即Arbiter是Worker进程的父进程,那么当Worker进程退出的时候,Master是可以通过监听signal.SIGCHLD信号来知道子进程的结束。但这还不够,gunicorn还有另外一招,我在《gunicorn syncworker 源码解析》中也有所提及:

  (1)gunicorn为每一个Worker进程创建一个临时文件

  (2)worker进程在每次轮训的时候修改该临时文件的属性

  (3)Arbiter进程检查临时文件最新一次修改时间是否超过阈值,如果超过,那么就给Worker发信号,kill掉该Worker

  不难看出,这是上面提到的第一种检测方式(单向的heartbeat),worker进程(target)通过修改文件属性的方式表明自己处于active状态,Arbiter(detector)进程检测文件属性来判断worker进程最近是否是active状态。

  这个检测的目的就是防止worker进程处于假死状态,没有crash,但是不工作。

tcp keepalive

  在计算机网络中,心跳也使用非常广泛。比如为了检测目标IP是否可达的ping命令、TCP的keepalive。

A keepalive (KA) is a message sent by one device to another to check that the link between the two is operating, or to prevent the link from being broken.  

   在TCP协议中,是自带keepalive来保活的,有三个很重要的选项(option)

tcp_keepidle :对一个连接进行有效性探测之前运行的最大非活跃时间间隔
tcp_keepintvl :两个探测的时间间隔
tcp_keepcnt :关闭一个非活跃连接之前进行探测的最大次数

  三个选项是这么配合的:如果一条连接上tcp_keepidle 这么长时间没有发消息之后,则开始心跳检测,心跳检测的时间间隔是tcp_keepintvl ,如果连续探测tcp_keepcnt 这么多次,还没有收到对应的回应,那么主动关闭连接。

  这三个参数的默认值都比较大,就是说需要较长时间才能检测网络不可达,因此一般情况下,程序会将三个参数调小。

  可以看到,这是典型的ping ack探测方式。

应用层心跳

  如果我们使用TCP最为传输层协议,那么是否就可以依赖TCP的keepalive来检查连接的状态,或者说对端进程的active状态呢?

  答案是不能的,因为,TCP只能保证说链接是通的,但并不能表明对端是可用的,比如说对端进程处于死锁状态,但链接仍然是通的,tcp keepalive会持续收到回应,因此传输层的心跳无法发现进程的不可用状态。所以我们需要应用层的心跳,如果收到应用层的心跳回复,那么对端肯定不会是none-active的。

Failure detector与consensus

  前面提到,通过心跳,是无法准确判断target是否是crash,但有的情况下我们又需要明确知道对方是crash了?还是说只是网络不通?毕竟这是两个不同的状态。

  而且target的crash还分为crash-stop,crash-recovery两种情况。crash-stop是说一个进程如果crash了,那么不会重新启动,也就不会接受任何后续请求;而crash-recovery是说,进程crash之后会重启(是否在同一个物理机上重启没有任何关系)。

completeness vs accuracy

  如果目标是检测出target的crash状态,那么检测算法有两个重要的衡量标准:

Completeness: every process failure is eventually detected (no misses)

Accuracy: every detected failure corresponds to a crashed process (no mistakes)

  前者(completeness)是说,如果一个进程挂掉,那么一定能被检测到;后者(accuracy)是说,如果detector认为target进程挂掉了,那么就一定挂掉了,不会出现误判。

  对于crash-stop模型,只能保证completenss,不能保证accurary。completeness不难理解,而accuracy不能保证是因为网络通信中, 由于延时、丢包、网络分割的存在,导致心跳消息(无论是单向的heartbeat还是ping ack)无法到达,也就没法判断target是否已经crash,也许还活得好好的,只是与detector之间的网络出了问题。

  那如果是crash-recovery模型呢,通过简单的心跳,不仅不能保证accuracy,甚至不能保证completeness,因为target进程可能快速重启,当然增加一些进程相关的信息还是能判断crash-recovery的情况,比如target进程维护一个版本号,心跳需要对比版本号。

  总之,网络环境下,很难保证故障检测的准确性(accuracy)。

lease

  接下来,考虑一个很常见的场景,在系统中有两类进程:一个master和多个slave,master给slave分配任务,master需要通过心跳知道每个slave的状态,如果某个slave处于none-active状态,那么需要将该slave负责的任务转移到其他处于active状态的slave上。master也充当了detector的角色,每个slave都是被检测的target。

  在这个场景中,有两点需要注意,第一,使用了心跳作为探测方式,而心跳探测只能保证completeness(完整性),而不能保证accuracy(准确性)。第二,slave负责的任务是否是可重复的?即同一份任务是否可以同时在多个slave上进行。failure detection的不准确性对slave任务的重新分配有至关重要的影响。

  如果任务是可重复的,比如幂等的运算,那么当master通过心跳判断slave处于none-active状态的时候,只需要将任务重新分配给其他slave就行,不用管该slave是否还存活着。MapReduce就是这样的例子,master在worker(MapReduce中的slave进程)进程失活(甚至只是运算进度太慢)的时候,将该worker负责的任务(task)调度到其他worker上。因此可能出现多个worker负责同一份任务的情况,但这并不会产生什么错误,因为任务的计算结果需要回报给master,master保证对于一份任务只会采纳一份计算结果,而且同一份任务,不管是哪个worker执行,结果都是一致的。

  但如果任务只能由一个节点来执行呢,由于心跳检测的不准确性,那么将任务从本来还在工作的节点重新调度到其他节点时,就会出现严重的问题。比如在primary-secondary副本控制协议中,primary的角色只能由一个节点来扮演,如果同时有两个primary,那么就出现了脑裂(brain-split),从这名字就能听出来问题的严重性。因此,即使在心跳检测出现误判的情况下,也要保证任务的唯一性,或者说,需要detector与target之间达成共识:target不要对外提供服务了。这个时候Lease机制就是很不错的选择,因为Lease机制具有很好的容错性,不会受到网络故障、延迟的影响。

  关于lease机制,我在《带着问题学习分布式系统之数据分片》中有简单介绍,这里再简单提一下Lease在GFS中的使用。

  GFS采用了primary-seconday副本控制协议,primary决定了数据修改的顺序。而primary的选举、维护是由master节点负责的,master与primary的心跳中,会携带lease信息。这个lease信息是master对primary的承诺:在lease_term这个时间范围内,我不会选举出新的primary。那么对于primary,在这个时间内,执行primary的职责,一旦过了这个时间,就自动失去了primary的权利。如果primary节点本身是ok的,并且与master之间网络正常,那么在每次心跳的时候,会延长这个lease_term,primary节点持续对外服务。一旦超过lease_term约定的时间,master就会选出新的primary节点,而旧的primary节点如果没有crash,在恢复与master的心跳之后,会意识到已经有了新的primary,然后将自己降级为secondary。

关于detector

  从上面GFS的例子,可以看到master是一个单点,也就是说由一个节点来负责所以其它节点的failure detection,这就是集中式的故障检测。如下图所示:

   由于detector是单点,因此压力会比较大。更为严重的问题,在使用了lease机制的系统中,一旦detector故障,所以节点都无法获取lease,也就无法提供服务,整个系统完全不可用。

  因此,detector的高性能、高可用非常重要,以一个集群的形式提供failure detection功能。

references

buffalo cse486 failure_detectors.pdf

gunicorn.org

Failure_detector

Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency 

   

 

posted @ 2018-04-08 09:32 xybaby 阅读(...) 评论(...) 编辑 收藏