CN114518973A - 分布式集群节点宕机重启恢复方法 - Google Patents

Abstract

本发明公开的一种分布式集群节点宕机重启恢复方法，恢复能力极强，能够极大的提高分布式集群节点宕机带来的损失。本发明通过下述技术方案实现：在其分布式系统客户端中设置配置参数类属性：配置该属性后，启动节点中的状态机，记录时间、长度信息，默认启动一个定时器任务，根据快照机制，自动完成快照操作，状态机基于快照Raft算法对快照进行优化,完成快照双重触发策略；状态机通过日志管理模块和时间管理模块进行日志提交和时间提交，不断从缓存队列中取出日志提交信息，从领导节点加载最新的镜像文件至本地快照执行器；采用双触发的触发因子，选择性发送RPC请求，实现触发快照断点续传，得到最终的重启恢复数据状态值。

Description

分布式集群节点宕机重启恢复方法

技术领域

本发明涉及分布式领域故障恢复技术，一种分布式系统分布式集群节点的宕机重启恢复方法。

背景技术

HRegionServer是HBase中最主要的组件，负责table数据的实际读写，管理Region。在分布式集群中，HRegionServer一般跟DataNode在同一个节点上，目的是实现数据的本地性，提高读写效率。无业务情况下，RegionServer占用CPU高。在HDFS中，DataNode负责存储实际数据。RegionServer主要负责响应用户的请求，向HDFS读写数据。一般在分布式集群中，RegionServer运行在DataNode服务器上，实现数据的本地性。每个RegionServer包含多个Region，它负责的功能如下：处理分批给它的Region。处理客户端读写请求。刷新缓存到HDFS中。处理Region分片。执行压缩。RegionServer是HBase中最核心的模块，其内部管理了一系列Region对象，每个Region由多个HStore组成，每个HStore对应表中一个列族的存储。HBase是按列进行存储的，将列族作为一个集中的存储单元，并且HBase将具备相同I/O特性的列存储到一个列族中，这样可以保证读写的高效性。RegionServer最终将Region数据存储在HDFS中，采用HDFS作为底层存储。HBase自身并不具备数据复制和维护数据副本的功能，而依赖HDFS为HBase提供可靠和稳定的存储。随着Apache HBase在各个领域的广泛应用，在HBase运维或应用的过程中我们可能会遇到这样的问题：同一个HBase集群使用的用户越来越多，不同用户之间的读写或者不同表的compaction、region splits操作可能对其他用户或表产生了影响。将所有业务的表都存放在一个集群的好处是可以很好的利用整个集群的资源，只需要一套运维系统。如果一个业务或者一个部门使用一个HBase集群，这样会导致HBase集群的数量越来越多，直接导致了运维成本的增加。而且集群的分离也会导致资源的浪费，有些集群资源过剩，有些集群资源不足，这种情况我们无法充分利用不同集群的资源。RegionServer作为HBase集群中实际的执行节点，不可避免地也会出现宕机。在分布式领域RegionServer宕机无法避免。另外，RegionServer宕机一定程度上会影响业务方的读写请求。一旦读取请求要读另外两份block块的数据，就只能通过网络访问其他节点，读取性能必然不高。如果仅仅依赖HBase本身的balance操作，就会使得系统整体Locality越来越低，系统整体表现越来越混乱，读性能越来越差。一旦发生宕机，心跳就会停止，超过一定时间(SessionTimeout)Zookeeper就会认为RegionServer宕机离线。集群中某些节点意外损坏导致集群中部分虚拟机无法正常使用。Redis集群是一个分布式(distributed)、容错(fault-tolerant)的Redis实现，集群可以使用的功能是普通单机。单机程序可能因为程序bug、宕机等因素导致进程死掉。当进程重启时，往往希望服务能恢复到原来的一致状态。状态的恢复依赖数据和日志。不论是传统的关系型数据库或者近几年比较火的NoSQL，操作日志都是这些系统必备的故障恢复手段。在作日志的形式中,传统的关系型数据库的操作日志分为回滚(UNDO)、重做(REDO)，UNDO/REDO日志3种。比如一个事务T对记录X执行加2操作，记录X＝1，修改过后X＝3，那么UNDO日志为<T,X,1>，REDO日志为<T,X,3>，UNDO/REDO日志为<T,X,1,3>。关系型数据库一般采用UNDO/REDO日志格式。对于NoSql，比如redis，则有自己的日志格式协议文件，叫做aof文件。操作日志的性能优化：有时候系统也许对性能要求较高，允许一定程度的数据丢失。每次操作日志都进行追加可能并不是一个最好的解决方案。这时可以考虑成组提交，操作日志可以积累到一定时间或量时再批量刷入日志文件中。比如redis提供3种AOF选项：关闭AOF文件,每次执行操作时都写AOF文件,每秒写一次AOF文件。对数据敏感性不是太高的系统可以选择每秒fsync一次到AOF文件。哪怕系统出现故障，也只会丢失1s的数据。如果仅靠操作日志对故障的系统进行恢复，当系统运行时间较长，操作日志巨大时，则通过REDO日志进行故障恢复的时间可能会让人难以忍受。因此需要定期将内存中的数据转储到磁盘上，这样就可以仅仅对转储后的REDO日志进行恢复即可，大大加快了故障恢复的时间。这就是CheckPoint。Redis中将此叫做RDB持久化。众所周知，RegionServer宕机是由zookeeper首先感知到的，而zookeeper感知到RegionServer宕机事件是需要一定时间的，这段时间默认会有3min。也就是说，在RegionServer宕机之后的3min之内系统并不知晓它实际上已经宕机了，所有的读写路由还会正常落到它上面，可想而知，这些读写必然都会失败。当然，并不是所有RegionServer宕机都需要3min中才能被Zookeeper感知。如果RegionServer在运行过程中产生自身难以解决的问题，它会自己abort自己，并且RegionServer会主动通知Zookeeper自己已经宕机的事实。这种场景下，影响用户读写的时间会极大的缩短到秒级。Zookeeper一旦感知到RegionServer宕机之后，就会第一时间通知集群的管理者Master，Master首先会将这台RegionServer上所有Region移到其他RegionServer上，再将HLog分发给其他RegionServer进行回放，这个过程通常会很快。完成之后再修改路由，业务方的读写才会恢复正常。

分布式可以将数据、IO访问分散到多个节点，让整个存储系统随着节点的增多容量和性能线性增加。传统集群模式下共享存储无法灵活扩展。分布式系统数据节点出现的故障分为临时性和永久性两种情况。总控节点会对下线的节点进行探测，如果一定时间，节点重新可用，则为临时性故障。否则为永久性故障。分布式系统中每个数据都有多个副本，重新上线的节点需要从其他副本中增量同步这段时间丢失的数据。然后重新提供服务。永久性故障：需要选择一个新的节点，拷贝副本的数据，成为新的副本节点。另外，总控节点也有可能出现故障，目前非P2P的分布式系统基本都是通过强一致性的备机达到HA的效果。多个备机的时候，则可能需要通过选举协议Paxos来选择新的总控节点。所以只需总控节点选择一个新的副本成为主副本进行继续提供写服务。对于分布式系统而言，故障探测是容错处理的先决条件。心跳包(HeartBeat)在单机系统中是进行故障检测的最常用的手段。总控节点每隔一段时间向work节点发送一个心跳包，如果一切正常，work节点就会回复总控节点的心跳包，同时心跳包中会含有work节点的机器的运行情况(如load值,cpu和IO的使用情况)。否则总控节点尝试一定次数后仍收不到回包则认为work节点出现了故障。但普通的心跳检测机制是无协议和承诺的，它的检测结果并不一定可靠。比如可能网络问题或者work节点繁忙未应答，总控节点认为work节点失效，但其实work节点仍在正常提供服务。在分布式系统中，这个是存在一定业务风险的。问题主要在于它是单方面判定节点失效。比如，总控节点认为work节点失效，所以为服务重新选取了新的主服务节点，而判定失效的节点可能正在继续正常工作，导致"双主"问题。分布式系统通常使用租约(lease)来进行故障检测。总控节点可以给work节点发放租约，work节点在有效期内才可以提供服务。群是一组相互独立的、通过高速网络互相联通的节点，构成了一个组，并以单一系统的模式加以管理。一个客户与集群相互作用时，集群就是一个独立的服务器。随着数据量的增多，snapshot文件也会变大。当集群中的Follower节点落后Leader节点太多时，Leader中的部分日志已经删除，日志保存在快照文件中，follower需要请求Leader的快照文件来及时跟上集群进度，Leader节点发送自身的snapshot文件给Follower节点时，可能在发送中途会遇到中断，中断后重传会消耗更多时间。根据Snapshot的机制，典型的Snapshot策略分为长度策略和时间策略。长度策略只考虑服务器磁盘空间所占大小，时间策略只考虑了服务器运行时间。由于两种策略在不同情况下的效果存在不一致，单独的策略在极端情况下都会存在不足。当vSAN集群出现突然断电、网络故障等特殊情况时会导致vSAN集群各节点之间的元信息不一致，因此会使vSAN集群中的部分节点不可用，而此时由于不可用的节点无法加入到自动横向扩展vSAN集群，也无法同步正确的元信息，也就意味着这个节点将永远被孤立，这个节点的数据也将永远无法正常使用。从而引发vSAN集群故障，用户部分或全部数据无法访问。当vSAN的节点不可用时一定会影响vSAN中的用户数据，并且很大概率会导致vSAN集群瘫痪，所有数据都无法正常使用。在同一个vSphere数据中心中，如果创建多个vSAN群集，则每个vSAN群集的ESXi主机都是全新安装的操作系统。如果从一个vSAN群集中移除ESXi主机，再在同一个数据中心中创建新的vSAN群集，那么只会显示一个vSAN存储，并且vSAN存储的容量大小显示不正确。虽然故障容忍功能允许管理员在集群中设置冗余，它是所有vSAN配置一个集成。vSAN配置的标准三节点架构包括两个节点和一个特殊使用用例的见证节点，但不一定知道vSAN究竟如何确定一个集群可支持多少个故障。分布式系统最难解决的便是一致性问题，并且在检测到宕机之后会将宕机RegionServer上的所有Region重新分配到集群中其他正常RegionServer上去，再根据HLog进行丢失数据恢复，恢复完成之后,快到期时work节点需要向总控节点进行续约才能继续提供服务。若比如出现网络故障，否则总控节点可以认为work节点已经不再提供服务，work节点也因为未成功续约而停止服务。这样就可以保证服务的一致性。租约的一个问题是超时判定问题，因为不同节点之间的本地时钟可以不一致，所以需要总控节点对超时时间增加一个放宽量。比如work节点的租约有效期为1分钟，总控节点需要超时65s时才可以判定work节点已经失效。SOFAJRaft是对Raft共识算法的Java实现。既然是共识算法，就不可避免的要对需要达成共识的内容，在多个服务器节点之间进行传输，一般将这些共识的内容称之为日志块(LogEntry)。在SOFAJRaft中，可以通过“节点之间并发复制日志”、“批量化复制日志”和“复制日志pipeline机制”等优化手段来保证服务器节点之间日志复制效率达到最大化。但如果遇到下面的两个场景，仅依靠上面的优化方法并不能有效地根本解决问题：在一个实际的分布式存储系统中，不可能让节点中的日志无限增加。冗长的日志导致系统重启时需要花费很长的时间进行回放，影响系统整体可用性。当对某个SOFAJRaft Group集群以新增节点方式来扩容，新节点需要从当前的Leader中获取所有的日志并重放到本身的状态机中，这对Leader和网络带宽都会带来不小的开销。因为服务器节点需要存储的日志不断增加，但是磁盘空间有限，除了对磁盘卷大小扩容外，Windows操作系统因为某一些原因出现启动后多次崩溃问题，不管通过任何方式都没办法解决冗长的日志导致系统重启时需要花费很长的时间进行回放，影响系统整体可用性。解决问题的方法可以通过引入快照机制。快照通过某种数据格式文件来保存系统当前的状态值的一个副本称为“快照”，快照同字面意思一样，可以分为“快”和“照”：“快”：高效快捷，通过快照可以很方便的将系统还原至某一时刻的状态；“照”：通过快照机制是保存系统某一时刻的状态值。snapshot的缺点就是不是增量的，即使内存中某个值没有变，下次做snapshot的时候同样会被dump到磁盘。当leader需要发给某个follower的log entry被丢弃了(因为leader做了snapshot)，leader会将snapshot发给落后太多的follower。或者当新加进一台机器时，也会发送snapshot给它。一旦节点重启需要回放大量日志，影响availability。在Raft集群中，Leader和Follower节点间做日志复制时，很可能会存在有部分Follower节点没有完全跟上Leader节点的情况，如果此时Leader节点裁剪了从“snapshot_2”文件最后的index+1位置前的日志，那剩余未完成日志复制的Follower节点就无法从Leader节点同步日志，而只能通过Leader发送过来的installSnapshotRequest来完成同步最新的状态了。vSAN集群中可以有多个FTT策略，随着数据量的增多，snapshot文件也会变大。当集群中的Follower节点落后Leader节点太多时，Leader中的部分日志已经删除，日志保存在快照文件中，follower需要请求Leader的快照文件来及时跟上集群进度，Leader节点发送自身的snapshot文件给Follower节点时，可能在发送中途会遇到中断，中断后重传会消耗更多时间。

发明内容

本发明的目的是针对现有技术存在的不足之处，提供一种恢复能力强，能够极大的提高分布式集群节点宕机带来的损失的分布式集群节点的宕机重启恢复方法，以解决集群中节点宕机重启问题。

本发明的上述目的可以通过下述技术方案予以实现：一种分布式集群节点宕机重启恢复方法，具有如下技术特征：基于ESXi虚拟机管理程序中包含的分布式软件层，搭建虚拟存储区域网络VSAN集群，定义节点状态机的快照Snapshot存储模块，时间管理模块和日志管理模块，创建快照编写器；在其分布式系统客户端中设置配置参数类属性，将快照Snapshot文件的存储路径，配置应用到集群当中，并创建在VSAN集群的所有主机之间共享的单个存储池；快照Snapshot存储模块存储日志管理模块配置变更和用户提交任务日志，把日志从领导Leader节点复制到其它节点上面，将序列化为一条日志存储下来；配置属性后，启动节点中的Raft状态机，初始化和集群中其它节点的通信，让各个节点开始互相通讯，时间管理模块记录时间、长度信息和结束索引，默认启动一个定时器任务，通知对应的节点状态机创建快照Snapshot，根据快照Snapshot机制，判断记录时间和结束索引是否达到临界点，是则更新时间和索引，自动完成快照Snapshot操作，生成快照Snapshot文件。采用双触发策略对snapshot进行触发快照文件采用分片发送的方式，实现断点续传；集群中的节点根据自身当前情况，基于快照Raft算法对快照snapshot进行优化，自主选择虚拟机存储策略或快照编写器编辑现有存储策略容错方法完成快照Snapshot双重触发策略快照snapshot镜像文件，快照镜像文件对T1～T3时刻内日志数据集合指令进行合并，合并日志数据集合并生成snapshot文件，各节点完成故障恢复后向所述管理节点发送分布式集群节点宕机重启恢复成功信号，管理节点收到集群各节点的宕机重启恢复成功信号后，向各节点发送恢复结束信号，得到最终的宕机重启恢复数据状态值。

本发明相比于现有技术具有如下有益效果：

本发明基于ESXi虚拟机管理程序中包含的分布式软件层，搭建虚拟存储区域网络VSAN集群，定义Raft状态机的快照Snapshot存储模块，时间管理模块和日志管理模块，创建快照编写器；运用快照Raft算法对快照snapshot进行优化,完成快照Snapshot双重触发策略。这种给出的双触发方式，合理结合两种策略，双触发的方式能让集群中的节点根据自身当前情况自主选择何种策略完成snapshot。可以根据情况让状态机自动选择采用哪种策略，更加合理的完成一次快照，对节点宕机重启恢复的时间消耗更少。实验结果表明，经该方法在分布式集群节点宕机重启恢复的时间消耗更少，共享数据存储恢复能力极强。这种基于策略的管理非常灵活，可以在每个虚拟机或每个虚拟磁盘的基础上应用。可以通过实施RAID擦除编码来降低较高“失败容忍”(FTT)策略的存储要求。且承受失败次数越多，专用于恢复的数据量越大。失败容忍FTT功能可确定vSAN群集中可能发生的故障数量，而不会影响数据完整性和虚拟机可用性。

本发明针对随着数据量的增多，snapshot文件也会变大。当集群中的Follower节点落后Leader节点太多时，Leader中的部分日志已经删除，日志保存在快照文件中，follower需要请求Leader的快照文件来及时跟上集群进度，Leader节点发送自身的snapshot文件给Follower节点时，可能在发送中途会遇到中断，中断后重传会消耗更多时间这一问题，基于快照Raft算法对快照snapshot进行优化，自主选择虚拟机存储策略或快照编写器编辑现有存储策略容错方法完成快照Snapshot双重触发策略快照snapshot镜像文件，采用对snapshot文件进行分片发送的方式，实现断点续传。在发送文件的中途发生中断后，采用分片发送后，时间消耗会相比之前减少，且发送时间越长时间效率提高越明显。

本发明基于快照Raft算法对快照snapshot进行优化，自主选择虚拟机存储策略或快照编写器编辑现有存储策略容错方法完成快照Snapshot双重触发策略快照snapshot镜像文件，快照镜像文件对T1～T3时刻内日志数据集合指令进行合并，合并日志数据集合并生成snapshot文件，各节点完成故障恢复后向所述管理节点发送分布式集群节点宕机重启恢复成功信号，管理节点收到集群各节点的宕机重启恢复成功信号后，向各节点发送恢复结束信号，得到最终的宕机重启恢复数据状态值，解决了集群中节点宕机重启问题。

附图说明

图1是本发明分布式集群节点宕机重启恢复的流程图；

图2是图1的双触发时序图；

图3是谁的断点续传示意图；

图4是缓存队列的示意图。

具体实施方式

参阅图1-图4。根据本发明，基于ESXi虚拟机管理程序中包含的分布式软件层，搭建虚拟存储区域网络VSAN集群，定义Raft状态机的快照Snapshot存储模块，时间管理模块和日志管理模块，创建快照编写器；在其分布式系统客户端中设置配置参数类属性，将快照Snapshot文件的存储路径，配置应用到集群当中，并创建在VSAN集群的所有主机之间共享的单个存储池；快照Snapshot存储模块存储日志管理模块配置变更和用户提交任务日志，把日志从领导Leader节点复制到其它节点上面，将序列化为一条日志存储下来；配置属性后，启动节点中的Raft状态机，初始化和集群中其它节点的通信，让各个节点开始互相通讯，时间管理模块记录时间、长度信息和结束索引，默认启动一个定时器任务，通知对应的Raft状态机创建快照Snapshot，根据快照Snapshot机制，判断记录时间和结束索引是否达到临界点，是则更新时间和索引，自动完成快照Snapshot操作，生成快照Snapshot文件。采用双触发策略对snapshot进行触发快照文件采用分片发送的方式，实现断点续传；集群中的节点根据自身当前情况，基于快照Raft算法对快照snapshot进行优化，自主选择虚拟机存储策略或快照编写器编辑现有存储策略容错方法完成快照Snapshot双重触发策略快照snapshot镜像文件，快照镜像文件对T1～T3时刻内日志数据集合指令进行合并，合并日志数据集合并生成snapshot文件，各节点完成故障恢复后向所述管理节点发送分布式集群节点宕机重启恢复成功信号，管理节点收到集群各节点的宕机重启恢复成功信号后，向各节点发送恢复结束信号，得到最终的宕机重启恢复数据状态值。

快照Snapshot存储模块存储记录Raft配置变更和用户提交任务日志，把日志从领导Leader节点复制到其他节点上面，将序列化为一条日志存储下来，并且VSAN群集中的每个主机都可以为群集提供存储。VSAN集群使用闪存硬盘(SSD)硬盘作为缓存层，使用机械硬盘(HDD)硬盤作为容量层。

节点状态机根据初始化的引发快照触发的初始化信息，判断节点当前Raft状态机所记录的信息是否达到触发条件；满足条件进行日志压缩与状态保存，否则序列化节点目前的状态信息，启动新的goroutine传入状态信息、压缩到的日志下标等恢复信息，进行shnapshot处理，当server节点的日志长度超过阈值时启动快照技术。

参阅图2、图3。针对集群中可能不止一个跟随Follower需要接收快照snapshot文件，因此快照snapshot分片采用生产者消费者模型，每一个需要快照文件的跟随Follower节点都是线程池中的消费者，而跟随Leader节点作为生产者。由于在进行快照Snapshot保存和加载时，节点自身的状态机会被阻塞，跟随Leader节点向跟随Follower节点发送发RPC日志信息在这段时间内都会停滞，为减少节点阻塞所带来的影响，本实施例，在状态机中引入缓存队列，状态机中引入缓存队列存放跟随Leader节点发送的日志信息。日志管理模块在Raft状态机中加入缓存队列存放领导Leader节点发送的日志信息，日志信息先进入到这个缓存队列中定义Raft状态机的Snapshot存储模块，把Leade节点内从起始的T1时刻至当前T3时刻这一时间范围内的所有日志都重新传至本地后提交给Raft状态机。

节点状态机根据双触发策略，向日志管理模块和时间管理模块进行日志提交和时间提交，不断从缓存队列中取出日志提交信息，逐条复制T1～T3时刻内的所有日志。当Follower节点过于落后集群整体状态时，快照Snapshot存储模块触发快照Snapshot，从Leader节点加载最新的镜像文件Snapshot_Index_File至本地快照Snapshot执行器。快照Snapshot执行器采用双触发的触发因子，从Leader节点传给新扩容的Raft节点的数据，对snapshot文件进行分片发送，通过网络远程接口，从远程计算机程序上请求服务，根据远程过程调用协议RPC发送给跟随Follower节点，跟随Follower节点再根据当前所获得的分片数，选择性发送RPC请求，实现触发快照Snapshot断点续传。客户端(Client)存根，存放服务端(Server)的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方。服务端存根，接收客户端发送过来的消息，将消息解包，并调用本地的方法。

日志管理模块在日志提交后向领导Leader节点返回信息，返回日志里的首/末个日志索引，删除所有现有日志，重置下任日志索引；然后调用底层日志存储，根据领导Leader节点发送到Follower节点的时间大于Raft状态机日志提交时间，更新break索引值和break时间。

节点状态机根据快照Snapshot的机制，将快照Snapshot策略分为长度策略和时间策略。长度策略只考虑服务器磁盘空间所占大小，时间策略只考虑服务器运行时间，长度策略其完成一次快照snapshot操作和集群当前的网络情况，时间策略完成一次快照snapshot操作。

快照Snapshot双重触发策略包括：一个日志长度为Break_index＝start_Index+interval的触发策略和另一个状态机时间表示为Break_Time＝start_Time+time_int，触发条件表示为trigger＝Break_indexor Break_Time，其中，Break_index表示按照日志索引长度完成一次快照，start_Index表示起始索引位置interval表示初始化完成一次快照的间隔索引长度；Break_Time表示的是按照固定时间完成一次快照，start_Time表示起始时间，time_int表示初始化完成一次快照的间隔时间。

两种双重触发单独快照Snapshot策略下的触发因子如下：

则双触发的触发因子：

节点中的状态机启动，记录时间、长度信息。分别表示为：

0＜δ＜1为集群中的速率因子，当δ越大其就越倾向于和长度策略一致，δ越小就越倾向于时间策略，其中，len是日志索引的长度，ε表示集群节点间的传输速率均速的情况，T是节点当前的系统时间，ti是初始设定的定时快照的时间，其中，t₀是0时刻的节点系统时间，t₁是1时刻的节点系统时间，t_cur是节点当前的系统时间，p_i是i个日志数量两种双重触

触发条件满足后，根据当前节点状况判断是否进行快照snapshot，其中，包括当前节点是否正在保存快照，节点当前是否正在运行，是则检查传入的日志压缩下表是否合法，然后，序列化日志压缩处的指数index等上下文信息，并追加append传入的状态信息，持久化快照信息，否则，截断日志项，压缩日志尺寸，将状态机判断是否完成快照的部分条件表示为：

term_l-term_s＝0

max(laIndex_i)＞max(lsIndex_i)

其中，term_l表示当前节点的任期，term_s快照中的任期，laIndex_i是状态机中最新应用的索引，lsIndex_i是快照文件中最后一个索引。

在快照Snapshot文件分片发送中，对快照snapshot文件定义如下：

并记一个快照snapshot文件发送的理想时间消耗

对文件进行分片后t将变为：

分片数通过RPC发送给跟随Follower节点，跟随Follower节点再根据当前所获得的分片数，选择性发送RPC请求，

其中，ε表示集群节点间的传输速率均速的情况，l_j表示每一个分片文件，j表示分片的索引号。从公式中可以看出随快照文件和集群当前的网络速率相关。在发送文件的中途发生中断后，采用分片发送后，时间消耗会相比之前减少且发送时间越长时间效率提高越明显。

传输速率通常是变化的，snapshot文件的发送时间记为：

其中，

表示速率和时间的关系。在快照发送过程中有中断发生时，通过对快照文件分片后，有效减少上述公式中的分母权重，减少时间消耗。

如图4所示缓存队列。领导Leader节点发送的日志信息通过共识模块先进入到缓存队列中，节点状态机中的日志提交从队列中不断取出，日志提交后向领导Leader节点返回信息。由于节点状态机中的日志提交会从队列中不断取出，只有这个缓存队列满了，节点的状态机才会发生阻塞，由于领导Leader节点发送到跟随Follower节点的时间大于状态机日志提交时间，故能很大程度上减少阻塞所带来的影响。

以上所述的仅是本发明的优选实施实例。应当指出，对于本领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以作出若干变形和改进，比如通过实际结构的调整变化，也可推广到其他系统领域的应用平台，这些变更和改变都应视为本发明的保护范围。

Claims (10)

1.一种分布式集群节点宕机重启恢复方法，具有如下技术特征：基于ESXi虚拟机管理程序中包含的分布式软件层，搭建虚拟存储区域网络VSAN集群，定义Raft状态机的快照Snapshot存储模块，时间管理模块和日志管理模块，创建快照编写器；在其分布式系统客户端中设置配置参数类属性，将快照Snapshot文件的存储路径，配置应用到集群当中，并创建在VSAN集群的所有主机之间共享的单个存储池；快照Snapshot存储模块存储日志管理模块配置变更和用户提交任务日志，把日志从领导Leader节点复制到其它节点上面，将序列化为一条日志存储下来；配置属性后，启动节点中的状态机，初始化和集群中其它节点的通信，让各个节点开始互相通讯，时间管理模块记录时间、长度信息和结束索引，默认启动一个定时器任务，通知对应的节点状态机创建快照Snapshot，根据快照Snapshot机制，判断记录时间和结束索引是否达到临界点，是则更新时间和索引，唤醒阻塞Raft状态机，自动完成快照Snapshot操作，生成快照Snapshot文件，否则进行节点启动，确认是否存在快照Snapshot文件，确认后加载快照Snapshot文件；确定调用方法的循环迭代Break，根据领导Leader节点发送到Follower节点的时间大于状态机日志提交时间，迭代检查属性的值，更新break索引值和break时间，如果该值大于当前迭代的索引值，则立即返回，采用双触发策略对snapshot进行触发快照文件采用分片发送的方式，实现断点续传；集群中的节点根据自身当前情况，基于快照Raft算法对快照snapshot进行优化，自主选择虚拟机存储策略或快照编写器编辑现有存储策略容错方法完成快照Snapshot双重触发策略快照snapshot镜像文件，快照镜像文件对T1～T3时刻内日志数据集合指令进行合并，合并日志数据集合并生成snapshot文件，各节点完成故障恢复后向所述管理节点发送分布式集群节点宕机重启恢复成功信号，管理节点收到集群各节点的宕机重启恢复成功信号后，向各节点发送恢复结束信号，得到最终的宕机重启恢复数据状态值。

2.如权利要求1所述的分布式集群节点宕机重启恢复方法其特征在于：快照Snapshot存储模块存储记录Raft配置变更和用户提交任务日志，把日志从领导Leader节点复制到其他节点上面，将序列化为一条日志存储下来，并且VSAN群集中的每个主机为群集提供存储；节点状态机根据初始化的引发快照触发的初始化信息，判断节点当前Raft状态机所记录的信息是否达到触发条件；满足条件进行日志压缩与状态保存，否则序列化节点目前的状态信息，启动新的goroutine传入状态信息、压缩到的日志下标等恢复信息，进行shnapshot处理，当server节点的日志长度超过阈值时启动快照技术。

3.如权利要求1所述的分布式集群节点宕机重启恢复方法其特征在于：在状态机中引入缓存队列，存放跟随Leader节点发送的日志信息，日志管理模块在Raft状态机中加入缓存队列存放领导Leader节点发送的日志信息，日志信息先进入到这个缓存队列中定义Raft状态机的Snapshot存储模块，把Leade节点内从起始的T1时刻至当前T3时刻这一时间范围内的所有日志都重新传至本地后提交给Raft状态机，节点状态机根据双触发策略，向日志管理模块和时间管理模块进行日志提交和时间提交，不断从缓存队列中取出日志提交信息，逐条复制T1～T3时刻内的所有日志；当Follower节点过于落后集群整体状态时，快照Snapshot存储模块触发快照Snapshot，从Leader节点加载最新的镜像文件Snapshot_Index_File至本地快照Snapshot执行器。

4.如权利要求1所述的分布式集群节点宕机重启恢复方法其特征在于：快照Snapshot执行器采用双触发的触发因子，从Leader节点传给新扩容的Raft节点的数据，对snapshot文件进行分片发送，通过网络远程接口，从远程计算机程序上请求服务，根据远程过程调用协议RPC发送给跟随Follower节点，跟随Follower节点再根据当前所获得的分片数，选择性发送RPC请求，实现触发快照Snapshot断点续传；客户端(Client)存根，存放服务端(Server)的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方；服务端存根，接收客户端发送过来的消息，将消息解包。

5.如权利要求1所述的分布式集群节点宕机重启恢复方法其特征在于：日志管理模块在日志提交后向领导Leader节点返回信息，返回日志里的首/末个日志索引，删除所有现有日志，重置下任日志索引；然后调用底层日志存储，根据领导Leader节点发送到Follower节点的时间大于Raft状态机日志提交时间，更新break索引值和break时间。

6.如权利要求1所述的分布式集群节点宕机重启恢复方法其特征在于：节点状态机根据快照Snapshot的机制，将快照Snapshot策略分为长度策略和时间策略，长度策略只考虑服务器磁盘空间所占大小，时间策略只考虑服务器运行时间，长度策略其完成一次快照snapshot操作和集群当前的网络情况，时间策略完成一次快照snapshot操作。

7.如权利要求1所述的分布式集群节点宕机重启恢复方法其特征在于：快照Snapshot双重触发策略包括：一个日志长度为Break_index＝start_Index+interval的触发策略和另一个状态机时间表示为Break_Time＝start_Time+time_int，触发条件表示为trigger＝Break_indexor Break_Time，其中，Break_index表示按照日志索引长度完成一次快照，start_Index表示起始索引位置interval表示初始化完成一次快照的间隔索引长度；Break_Time表示的是按照固定时间完成一次快照，start_Time表示起始时间，time_int表示初始化完成一次快照的间隔时间。

8.如权利要求1所述的分布式集群节点宕机重启恢复方法其特征在于：两种双重触发单独快照Snapshot策略下的触发因子如下：

则双触发的触发因子：

节点中的状态机启动，记录时间、长度信息。分别表示为：

0＜δ＜1为集群中的速率因子，当δ越大其就越倾向于和长度策略一致，δ越小就越倾向于时间策略，其中，len是日志索引的长度，ε表示集群节点间的传输速率均速的情况，T是节点当前的系统时间，ti是初始设定的定时快照的时间，其中，t₀是0时刻的节点系统时间，t₁是1时刻的节点系统时间，t_cur是节点当前的系统时间，p_i是i个日志数量。

9.如权利要求1所述的分布式集群节点宕机重启恢复方法其特征在于：触发条件满足后，根据当前节点状况判断是否进行快照snapshot，其中，包括当前节点是否正在保存快照，节点当前是否正在运行，是则检查传入的日志压缩下表是否合法，然后，序列化日志压缩处的指数index上下文信息，并追加append传入的状态信息，持久化快照信息，否则，截断日志项，压缩日志尺寸，将状态机判断是否完成快照的部分条件表示为：

term_l-term_s＝0

max(laIndex_i)＞max(lsIndex_i)

其中，term_l表示当前节点的任期，term_s快照中的任期laIndex_i是状态机中最新应用的索引，lsIndex_i是快照文件中最后一个索引。

10.如权利要求1所述的分布式集群节点宕机重启恢复方法其特征在于在快照Snapshot文件分片发送中，对快照snapshot文件定义如下：

并记一个快照snapshot文件发送的理想时间消耗t：

对文件进行分片后t将变为：

分片数通过RPC发送给跟随Follower节点，跟随Follower节点再根据当前所获得的分片数，选择性发送RPC请求，

其中，ε表示集群节点间的传输速率均速的情况，l_j表示每一个分片文件，j表示分片的索引号。

Images