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

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

【技术实现步骤摘要】
分布式集群节点宕机重启恢复方法


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

技术介绍

[0002]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进行回放，这个过程通常会很快。完成之后再修改路由，业务方的读写才会恢复正常。
[0003]分布式可以将数据、IO访问分散到多个节点，让整个存储系统随着节点的增多容量和性能线性增加。传统集群模式下共享存储无法灵活扩展。分布式系统数据节点出现的故障分为临时性和永久性两种情况。总控节点会对下线的节点进行探测，如果一定时间，节点重新可用，则为临时性故障。否则为永久性故障。分布式系统中每个数据都有多个副本，重新上线的节点需要从其他副本中增量同步这段时间丢失的数据。然后重新提供服务。永久性故障：需要选择一个新的节点，拷贝副本的数据，成为新的副本节点。另外，总控节点也有可能出现故障，目前非P2P的分布式系统基本都是通过强一致性的备机达到HA的效果。多个备机的时候，则可能需要通过选举协议Paxos来选择新的总控节点。所以只需总控节点选择一个新的副本成为主副本进行继续提供写服务。对于分布式系统而言，故障探测是容错处理的先决条件。心跳包(HeartBeat)在单机系统中是进行故障检测的最常用的手段。总控节点每隔一段时间向work节点发送一个心跳包，如果一切正常，work节点就会回复总本文档来自技高网...

【技术保护点】

【技术特征摘要】
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)...

【专利技术属性】
技术研发人员：潘路，刘珂，姚红，牛新征，罗涛，
申请(专利权)人：成都西南信息控制研究院有限公司，
类型：发明
国别省市：