CN112887367A - 实现分布式集群高可用的方法、系统及计算机可读介质 - Google Patents

实现分布式集群高可用的方法、系统及计算机可读介质 Download PDF

Info

Publication number
CN112887367A
CN112887367A CN202110029223.0A CN202110029223A CN112887367A CN 112887367 A CN112887367 A CN 112887367A CN 202110029223 A CN202110029223 A CN 202110029223A CN 112887367 A CN112887367 A CN 112887367A
Authority
CN
China
Prior art keywords
node
vip
main
current state
zookeeper
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202110029223.0A
Other languages
English (en)
Other versions
CN112887367B (zh
Inventor
张军
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huayun Data Holding Group Co Ltd
Original Assignee
Huayun Data Holding Group Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huayun Data Holding Group Co Ltd filed Critical Huayun Data Holding Group Co Ltd
Priority to CN202110029223.0A priority Critical patent/CN112887367B/zh
Publication of CN112887367A publication Critical patent/CN112887367A/zh
Application granted granted Critical
Publication of CN112887367B publication Critical patent/CN112887367B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1034—Reaction to server failures by a load balancer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1029—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers using data related to the state of servers by a load balancer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Hardware Redundancy (AREA)

Abstract

本发明提供了实现分布式集群高可用的方法、系统及计算机可读介质，该方法包括：在分布式集群的每个节点中部署VIP进程，在每个节点的主进程中部署Zookeeper客户端，并在主进程与Zookeeper服务端之间建立长连接；VIP进程对当前状态的主节点中的主进程进行监测以确定当前状态的主节点的健康状态，并在当前状态的主节点发生故障时，由作为当前状态的主节点中的VIP进程删除当前状态的主节点中的VIP，则由剩余的节点以抢占方式确定唯一VIP，以将抢占到唯一VIP的节点作为主节点，并由VIP对外提供服务。通过本发明，有效地避免了分布式集群中的各个节点间出现双VIP及其所导致的脑裂现象，避免了节点间出现网络断开时各节点对资源的争夺，提高了用户体验。

Description

实现分布式集群高可用的方法、系统及计算机可读介质
技术领域
本发明涉及计算机技术领域，尤其涉及一种实现分布式集群高可用的方法、系统及计算机可读介质。
背景技术
脑裂(split-brain)是指在一个高可用(High Availability，HA)系统中，当联系着的两个节点断开联系时，本来为一个整体的系统，分裂为两个独立节点，这时两个节点开始争抢共享资源，从而导致系统混乱、数据损坏的现象。随着互联网及云计算的快速发展及基于用户所产生的业务量不断增加，对业务的可靠性和性能要求越来越高。在实际的生产环境中，绝大多数集群都是高可用的，一旦发生脑裂，集群或者高可用集群中的多个节点的角色均变成了主节点，此时用户均可与多个原本不是主节点的节点(即从节点)执行写操作等节点上可执行的各项操作，从而导致各个节点之间的数据存在不一致的情况。
在高可用集群中通常包含一个主节点(Master)和多个从节点(Backup)，主节点与多个从节点之间通常基于Keepalived及Haproxy的组合，以确保集群的高可用性能。Keepalived是以VRRP协议(虚拟路由冗余协议)为基础实现的。主节点与各从节点之间通过心跳机制维持状态。当从节点无法接收到主节点发送的VRRP控制报文时，则认为主节点已经宕机。在此场景中则根据VRRP协议的优先级从多个从节点中选举出一个从节点并作为新的主节点。新的主节点启动资源管理模块以接管原来的主节点上运行的资源、服务或者进程。
在现有技术中，为了实现分布式集群的高可用，通常采用检测脚本检测主进程的状态，并向Keepalived汇报。Keepalived通过检测脚本的监听状态确定是否需要切换VIP(虚拟IP地址)至其他节点，以由选定的一个节点作为主节点对外提供服务。参图1所示，当节点出现心跳超时导致网络断开时，例如节点2与节点3发生网络断开，则节点1与节点2会立即组成一个集群，节点3与节点4也会立即组成一个集群，且节点3与节点4无法感知到节点1及节点2的存在。此时Keepalived会在重新在节点3与节点4之间重新建立VIP，例如在节点4上建立VIP。此时，VIP分别出现在节点1与节点4上，当用户对分布式集群执行读写数据时，则会出现节点1与节点4对共享资源的争夺，从而出现所谓的“脑裂”。
由此可见，采用Keepalived实现分布式集群的高可用虽然在业务层面不需要加入复杂的逻辑且配置相对简单，但在主从节点间出现网络断开时，极易出现两个作为VIP的节点，从而引起脑裂现象。同时，在上述现有技术中需要使用监测脚本去检测主进程的健康状态，从而导致可控性较差。最后，在类似上述技术的现有技术中，当主节点宕机时，如果该主节点不连接数据库，则主节点宕机会直接导致数据丢失，而如果为主节点配置数据库存储数据又会导致占用系统资源，并对数据库的稳定性提出了更为苛刻的技术要求。
有鉴于此，有必要对现有技术中的实现分布式集群高可用的方法予以改进，以解决上述问题。
发明内容
本发明的目的在于揭示一种实现分布式集群高可用的方法、系统及计算机可读介质，用以避免分布式集群中的各个节点间出现双VIP及脑裂现象，同时在节点间出现网络断开时各节点对资源的争夺，避免现有技术中采用Keepalived实现分布式集群的高可用所存在的上述缺陷。
为实现上述第一个发明目的，本发明提供了实现分布式集群高可用的方法，包括：
在分布式集群的每个节点中部署VIP进程，在每个节点的主进程中部署Zookeeper客户端，并在主进程与Zookeeper服务端之间建立长连接；
VIP进程对当前状态的主节点中的主进程进行监测以确定当前状态的主节点的健康状态，并在当前状态的主节点发生故障时，由作为当前状态的主节点中的VIP进程删除当前状态的主节点中的VIP，则由剩余的节点以抢占方式确定唯一VIP，以将抢占到唯一VIP的节点作为主节点，并由所述VIP对外提供服务。
作为本发明的进一步改进，所述方法还包括：
由Zookeeper客户端在Zookeeper服务端中建立包含节点名称的持久节点及临时节点，若当前状态的主节点发生故障时，由VIP进程通过判断临时节点是否存在以确定主进程的健康状态。
作为本发明的进一步改进，所述由剩余的节点以抢占方式确定唯一VIP的操作由剩余节点中所部署的VIP进程执行；
所述Zookeeper服务端保存各个节点基于用户发起的操作请求所对应生成的版本号，以在由剩余的节点以抢占方式确定唯一VIP的操作前还包括：
对Zookeeper服务端所保存的版本号进行一致性校验。
作为本发明的进一步改进，所述用户发起的操作请求由读操作、写操作、删除操作、迁移操作或者备份操作中的一种或者几种的任意组合。
作为本发明的进一步改进，将抢占到唯一VIP的节点作为主节点之后，还包括：卸载发生故障的主节点中的VIP。
作为本发明的进一步改进，每个节点中部署的VIP进程与主进程共同被Zookeeper服务端所纳管，所述Zookeeper服务端被配置为Zookeeper进程。
作为本发明的进一步改进，在当前状态的主节点中的VIP进程删除当前状态的主节点中的VIP后，还包括：
对所述被执行删除VIP的主节点的健康状态进行轮询检测，并判断被执行删除VIP的主节点中的主进程与Zookeeper是否恢复连接；
若恢复连接，由Zookeeper进程协调VIP进程在被删除VIP的节点中重新建立VIP或者删除重复的VIP；
若无法恢复连接，由Zookeeper进程从剩余节点中确定唯一VIP。
基于相同发明思想，并为实现第二个发明目的，本申请还揭示了一种实现分布式集群高可用的系统，其特征在于，包括：
两个以上运行主进程的节点，部署于每个节点中的VIP进程，所述主进程中部署Zookeeper客户端，以及Zookeeper服务端；
所述主进程与Zookeeper服务端之间建立长连接，
VIP进程对当前状态的主节点中的主进程进行监测以确定当前状态的主节点的健康状态，并在当前状态的主节点发生故障时，由作为当前状态的主节点中的VIP进程删除当前状态的主节点中的VIP，则由剩余的节点以抢占方式确定唯一VIP，以将抢占到唯一VIP的节点作为主节点，并由所述VIP对外提供服务。
作为本发明的进一步改进，所述Zookeeper服务端被配置为Zookeeper进程，并部署于各节点中，且各节点中不配置数据库。
最后，基于相同发明思想，为实现第三个发明目的，本申请还揭示了一种计算机可读介质，
所述计算机可读介质中存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行如第一个发明创造所述的实现分布式集群高可用的方法中的步骤。
与现有技术相比，本发明的有益效果是：
在本申请中，通过在主进程中部署Zookeeper客户端，并利用Zookeeper的分布式协调服务的特点，不需要使用额外的脚本监测主进程的健康情况，相对脚本检测所形成的监测过程繁琐、维护成本较高等缺点而言，利用Zookeeper进程或者Zookeeper服务端记录当前状态的主节点中健康状态及宕机后的恢复状态确定是否由其他从节点以竞争方式确定唯一的VIP以重新定义出新的主节点，还是由原来的主节点作为主节点，因此相对于传统的基于Keepalived及Haproxy的组合以确保集群的高可用性能的现有技术，本申请所揭示的技术方案可基于Zookeeper以全局性的命名空间保存分布式集群中各个节点的信息，因此不需要部署数据库存储节点的信息数据；
同时，在本申请中，当在先的作为主节点的节点因为宕机或者网络断开后将VIP漂移至其他的从节点后，如果发生宕机或者网络断开的主节点恢复后，通过循环地检测原先发生宕机或者网络断开的主节点是否恢复，以确定是否将VIP重新切换至原来的主节点，从而有效地防止了恢复后的主节点出现空载的不良情况，避免了主节点资源的浪费，尤其是在超融合存储系统中能够极大地提高分布式集群中的各个节点的资源利用率，及主从节点的动态切换，从而有效地避免了分布式集群中的各个节点间出现双VIP及其所导致的脑裂现象，避免了节点间出现网络断开时各节点对资源的争夺，提高了用户体验。
附图说明
图1为配置有四个节点的分布式集群发生节点间网络断开时形成双VIP节点并导致该分布式集群发生脑裂的拓扑图；
图2为使用本发明所揭示的实现分布式集群高可用的方法在配置有四个节点的分布式集群发生节点间网络断开时，由当前状态的主节点(即节点1)发生节点间网络断开后，删除节点1中的VIP并由节点4抢占唯一的VIP，以将节点4作为下一个状态的主节点并为用户发起的操作予以响应的拓扑图；
图3为本发明一种实现分布式集群高可用的方法的整体流程图；
图4为本发明一种实现分布式集群高可用的系统的拓扑图；
图5为在包含四个节点的分布式集群中作为当前状态的主节点(即节点1)发生节点间网络断开时所，由节点1中的VIP进程删除节点1中的VIP的详细流程图；
图6为根据图5中在下一次检测时若被删除VIP的节点(即节点1)中的主进程与Zookeeper恢复连接时在节点1中执行的详细流程图；
图7为根据图5中在下一次检测时若被删除VIP的节点(即节点1)中的主进程与Zookeeper无法恢复连接，并由分布式集群中的剩余节点以抢占方式确定唯一VIP，以将抢占到唯一VIP的节点作为主节点，并由所述VIP对外提供服务的详细流程图；
图8为本发明一种计算机可读介质的拓扑图。
具体实施方式
下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。
在详细阐述本实施例之前，对本申请各个实施例所涉及的技术术语予以必要解释与定义。
术语“集群”：通过局域网、广域网或者其他通信方式予以连接，通过一组松散集成的计算机软件或硬件连接起来高度紧密地协作完成计算工作所形成的计算机系统。同时，在本申请中“集群”与术语“计算机集群”或者术语“数据中心”具等同技术含义。
术语“主从切换”：角色为主节点与角色为从节点之间的角色切换，无论是主节点还是从节点，均属于“节点”；并且在本申请中，术语“主服务器”与术语“主节点”之间具等同技术含义，术语“从服务器”与术语“从节点”之间具等同技术含义；术语“实质性宕机”与术语“非实质性宕机”互为相反技术概念，其中，“非实质性宕机”是指因业务繁忙或者检测超时等原因所导致的主节点与一个或者多个从节点之间无法收发VRRP控制报文，并由此引发主节点被认定为“Fail”的状态。
以下通过多个实施例对本发明的具体实现过程予以阐述。
实施例一：
参图2至图7所示，本实施例揭示了一种实现分布式集群高可用的方法(以下简称“方法”)的一种具体实施方式。
参图3所示，在本实施例中，该方法包括以下步骤S1至步骤S2。为便于描述本发明的具体方案，申请人示出了包含四个节点(即节点1～节点4，参图2所示)所构成的一种分布式集群。分布式集群在本实施例中可被理解为一种包含多个节点的系统(例如超融合系统)、装置(如分布式存储装置)或者平台(例如分布式云平台)等。节点优选为物理节点，当然也可将节点理解为虚拟节点、虚拟设备、由容器构建的宿主机或者服务器。
步骤S1、在分布式集群的每个节点中部署VIP进程20，在每个节点的主进程10中部署Zookeeper客户端11，并在主进程10与Zookeeper服务端30之间建立长连接。Zookeeper服务端30被配置为Zookeeper进程31，并部署于各节点中，且各节点中不配置数据库(Database)。每个节点中部署的VIP进程20与主进程10共同被Zookeeper服务端30所纳管，Zookeeper服务端30被配置为Zookeeper进程31。该方法还包括：由Zookeeper客户端11在Zookeeper服务端30中建立包含节点名称的持久节点及临时节点，若当前状态的主节点发生故障时，由VIP进程20通过判断临时节点是否存在以确定主进程的健康状态。包含节点名称的持久节点及临时节点均被保存至Zookeeper服务端30。在本实施例中，在主进程10中部署Zookeeper客户端11，并通过Zookeeper客户端11被逻辑上独立于主进程10的Zookeeper服务端30所纳管，增加了对主进程10的监测力度，降低了程序或者应用的耦合性，以及对程序或者应用的可控性与可靠性，并且不需要额外配置监测脚本(例如JS脚本)去监控主进程10的健康状态或者工作状态。
Zookeeper进程31是一种开源的分布式应用程序协调服务组件，可用于分布式应用场景中的数据管理、集群管理、状态同步、全局管理统一命名空间、分布式应用配置项等服务。Zookeeper服务端30用于存储数据、表格、配置项等，且可以采用类似文件系统(FileSystem)的目录树架构。持久节点以命名空间保存分布式集群中各个节点的信息。在本实施例中，在每个节点中的主进程10中部署Zookeeper客户端11，并在Zookeeper客户端11中建立临时节点。在本实施例中，以节点的名称等节点信息命名的持久节点与临时节点、VIP所属的节点(即哪个节点实际上占有该唯一的VIP)等信息均保存在逻辑上独立于主进程10与VIP进程20的Zookeeper服务端30中，从而使得整个分布式集群可通过全局性的命名空间保存该分布式集群的上述信息，从而省略配置数据库，由此不仅从架构上简化了该分布式集群的设计与部署的难度，也能够提高分布式集群的可靠性与程序的鲁棒性。
当主进程10与Zookeeper服务端30断开连接，则证明节点1的健康状态出现异常，不管这种异常是因为宕机导致还是因为断电导致，甚至是因为部署在节点1中的存储设备(例如固态硬盘或者HDD)写满而而无法持续地向及节点中写入数据所导致的，都会导致节点1中的主进程10发生与Zookeeper服务端30断开连接的事件。当节点1中的主进程10发生与Zookeeper服务端30断开后，由节点1中的VIP进程20基于节点1中的Zookeeper客户端11所建立的临时节点是否存在以确定节点1中的主进程10是否健康；如果临时节点消失，则证明该主进程10出现异常(或者认定运行该主进程10的节点宕机或者断开连接)；如果临时节点存在，则证明该主进程10正常。在本实施例中，每个节点中部署的VIP进程20主要用于VIP漂移的高可用，并VIP漂移后将上一个状态作为主节点中的VIP进行删除，避免分布式集群中出现两个VIP。
主进程10是需要被监控的进程，并通过该主进程10向用户的发起的各种操作请求予以响应。每个节点中VIP进程20基于Zookeeper服务端30与Zookeeper客户端11之间相同通信，以通过Zookeeper客户端11通过Zookeeper服务端30来获取到Zookeeper服务。在本实施例中，由于直接在每个节点的主进程10部署Zookeeper客户端11，使得Zookeeper服务端30能够协同集中地监视各个节点的主进程20及所属节点的健康状态，从而通过Zookeeper服务端30通知VIP进程20是否要删除主节点中的VIP(虚拟IP地址)，以保障整个分布式集群的高可用性与系统的健壮性与原子性。一个逻辑上独立的分布式集群对外原则上仅可见一个VIP。
步骤S2、VIP进程20对当前状态的主节点(例如节点1)中的主进程10进行监测以确定当前状态的主节点的健康状态，并在当前状态的主节点发生故障时，由作为当前状态的主节点中的VIP进程20删除当前状态的主节点中的VIP，则由剩余的节点以抢占方式确定唯一VIP，以将抢占到唯一VIP的节点作为主节点，并由所述VIP对外提供服务。优选的，在本实施例中，将抢占到唯一VIP的节点作为主节点之后，还包括：卸载发生故障的主节点中的VIP。
参图2所示，由剩余的节点以抢占方式确定唯一VIP的操作由剩余节点中所部署的VIP进程20执行。例如，节点2宕机、断电或者与节点2～节点4断开网络连接后，需要将节点1中的VIP漂移至被由节点2～节点4(即“剩余的节点”)以抢占方式确定唯一VIP，例如节点4抢占到该VIP，则节点1将VIP漂移至节点4中。此时，节点1不响应用户发起的各种操作请求，因此用户与节点1之间禁止数据的读取，并在用户与节点4(假设被节点4抢占到VIP的实例中)之间发生数据读取操作。在此场景中，即使节点2与节点3之间发生网络断开或者节点1与节点2之间发生网络断开，则节点3、4或者节点2～节点4之间依然会以竞争方式抢占唯一的VIP，并防止在同一个分布式集群中出现两个VIP及两个主节点，避免出现脑裂。
在本实施例中，该Zookeeper服务端30保存各个节点基于用户发起的操作请求所对应生成的版本号，以在由剩余的节点以抢占方式确定唯一VIP的操作前还包括：对Zookeeper服务端30所保存的版本号进行一致性校验。具体的，用户发起的操作请求由读操作、写操作、删除操作、迁移操作或者备份操作中的一种或者几种的任意组合。
在zookeeper的VIP节点中存储两个key-value的值，这两个key分别是previous-owner、current-owner，两个value分别是VIP之前所在节点的名称(例如节点1)和当前VIP所在节点的名称(例如节点4)，刚开始部署的时候这两个key对应的value值是一样的，都是当前这个节点的名称。
当VIP所在节点(例如节点1)出现故障，VIP进程20检测到节点1中的主进程10故障会将本节点的VIP清除掉，其他没有故障的节点的VIP进程也会监测到VIP所在节点出现故障(即感知到节点1已经出现故障)，此时节点2～节点4会竞争去争取获取这个VIP。在本实施例胡中，在竞争过程中为了保证原子性可通过记录版本号的方式让每次去Zookeeper服务端30中获取数据/更新数据，以防止多个节点(即节点2～节点4)同时去更改Zookeeper服务端30中VIP所在节点的信息。当某个节点(例如节点4)成功竞争到这个VIP的拥有权，则立即在节点4中建立VIP，并同时将Zookeeper服务端30中记录的current-owner值更改为这个节点的名称，这时候这个节点称为后一个状态的主节点，此时节点4中的previous-owner和current-owner的值不相同。
当原来的VIP所在节点(即节点1)出现故障恢复后，后一个状态的主节点监测到原先VIP节点恢复后，会先将建立在备节点的VIP清除掉，然后原先VIP的主节点会获取这个VIP，并在这个主节点重新建立VIP，让原先的业务继续在这个节点服务，同时更改current-owner的值为主节点名称。
在本实施例中，在主节点故障VIP切换后，能够记录之前这个VIP的拥有者(即Zookeeper服务端30中记录上一个状态的主节点是节点1)，有助于下一次检测后如果发现原来的主节点(即节点1)故障恢复后，重新将这个VIP切换到原先的主节点。主节点故障恢复后，将VIP重新返回给原先的主节点。申请人指出通过上述技术手段能够有效地防止上一个状态作为主节点(即节点1)发生故障后重新恢复出现空载情况，浪费资源，从而使得超融合存储场景下让每个节点都充分利用资源。通过记录版本号的方式让每次去更改Zookeeper都保持原子性，防止在更改Zookeeper的过程中数据被其他节点更改掉。在本实施例中，术语“资源”可独立包含由用户(User)发起的访问请求或者向用户进行响应所配置的一种或者几种服务能力，包括但不限于数据、物理资源、虚拟资源、APP、下载地址、音频文件、视频文件、存储资源、操作系统等。
在本实施例中，在当前状态的主节点中的VIP进程删除当前状态的主节点中的VIP后，还包括：对所述被执行删除VIP的主节点的健康状态进行轮询检测，并判断被执行删除VIP的主节点中的主进程10与Zookeeper是否恢复连接(参图5所示)；若恢复连接，由Zookeeper进程31协调VIP进程20在被删除VIP的节点(即前述的节点1)中重新建立VIP或者删除重复的VIP(参图6所示，此时被删除重复的VIP也是节点1中的VIP)；若无法恢复连接，由Zookeeper进程31从剩余节点中确定唯一VIP(参图7所示)，并具体为从节点2～节点4中以抢占方式确定唯一的VIP，并将抢占到该VIP的节点作为下一个状态的主节点。
作为向用户予以响应的主节点是一个周期性动态变化的过程。例如，若节点1未发生宕机、断电或者与整个集群或者其他节点发生网路断开，则节点1被认定为当前状态的主节点，此时节点2～节点4被认定为从节点。若节点1发生宕机、断电或者与整个集群或者其他节点发生网路断开，且VIP漂移至节点4，则节点4被认定为下一个状态的主节点，节点2～节点3被认定为从节点。如果节点1恢复后，优先将唯一的VIP重新在节点1中予以重新建立，并在下一次检测过程中对节点1的健康状态进行检测，因此在本实施例中，作为主节点的角色是一个动态变化的过程，并不会被用户所感知。
结合图5至图6所示，本实施例更具体的示出了流程100～流程300，以对不同状态中的主节点的角色切换及VIP的漂移以及回归予以进一步说明。
参图5所示。
流程100。
开始。
步骤101：当前状态的主节点中的主进程与Zookeeper断开连接。
步骤102：判断VIP是否属于当前状态的主节点，若是，则跳转步骤103，若否，则跳转步骤104，以作下一次检测。
步骤103：VIP进程删除当前状态的主节点中的VIP。
步骤104：下一次检测。在本实施例中，所谓轮询与步骤104可作等同理解。
在下一次检测后可能出现两种情况，即情况105：当前状态的主节点(即之前发生故障的节点1)中的主进程与Zookeeper恢复连接，或者情况106：当前状态的主节点(即之前发生故障的节点1)中的主进程与Zookeeper无法恢复连接，而且此种无法恢复连接是一个相对较长的时间，例如几天或者几周。对于情况105对应执行流程200，对于情况106对应执行流程300。
参图6所示，当前状态的主节点(即之前发生故障的节点1)中的主进程与Zookeeper恢复连接后，执行步骤201：判断VIP是否属于当前状态的节点，此处的“当前状态的节点”是节点1。若是，跳转执行步骤202，若否，跳转执行步骤204。
步骤202：VIP在当前状态的节点(即节点1)中未建立，进一步执行步骤203。
步骤203：在当前状态的节点中建立VIP，从而将图2中漂移至及节点4中的VIP重新返回给原先的主节点，即节点1。
步骤204：VIP在当前状态的主节点(即节点1)中已建立。
步骤205：VIP进程删除当前状态的主节点的VIP。
步骤206：下一次检测，以设定的时间间隔循环检测，以为整个分布式集群确定唯一的VIP，并通过返回步骤207执行流程100。
参图7所示，当前状态的主节点(即之前发生故障的节点1)中的主进程与Zookeeper无法恢复连接后，执行步骤301：判断当前状态的主节点中的主进程与Zookeeper是否断开连接，若是，则跳转步骤302，若否，则跳转步骤306。
步骤302：判断VIP是否属于当前状态的主节点，若是，则跳转步骤306，若否，则跳转步骤303：以剩余的节点(即节点2～节点3)以抢占方式确定唯一的VIP，以将抢占到的唯一的VIP的节点(例如节点4)作为主节点。此处的“主节点”是节点1在设定的一定时间长度内(例如几天或者几周)无法排除故障时而将“主节点”的角色由节点4顶替而言的。
步骤304：判断竞争是否成功，若否，则跳转步骤306，若是，则跳转步骤305：由抢占到唯一VIP的节点(例如节点4)作为主节点，即下一个状态中的主节点。
步骤306：下一次检测，以设定的时间间隔循环检测，以为整个分布式集群确定唯一的VIP，并通过返回步骤307执行流程100。
由此完成整个分布式集群中各个节点确定唯一的VIP过程。
实施例二：
参图2与图4所示，本实施例揭示了一种实现分布式集群高可用的系统，包括：两个以上运行主进程的节点，部署于每个节点中的VIP进程，所述主进程中部署Zookeeper客户端，以及Zookeeper服务端。主进程与Zookeeper服务端之间建立长连接，VIP进程对当前状态的主节点中的主进程进行监测以确定当前状态的主节点的健康状态，并在当前状态的主节点发生故障时，由作为当前状态的主节点中的VIP进程删除当前状态的主节点中的VIP，则由剩余的节点以抢占方式确定唯一VIP，以将抢占到唯一VIP的节点作为主节点，并由所述VIP对外提供服务。Zookeeper服务端30被配置为Zookeeper进程31，并部署于各节点中(即同时部署于节点1～节点4中)，且各节点中不配置数据库。
本实施例所揭示的实现分布式集群高可用的系统与实施例一中具有相同部分的技术方案，请参实施例一所述，在此不再赘述。
实施例三：
参图8所示，本实施例还揭示了一种计算机可读介质900。计算机可读介质900中存储有计算机程序指令901，所述计算机程序指令901被一处理器902读取并运行时，执行如实施例一所述的实现分布式集群高可用的方法中的步骤。本实施例所揭示的实现分布式集群高可用的系统与实施例一中具有相同部分的技术方案，请参实施例一所述，在此不再赘述。
本发明实施例中所描述的各种说明性的逻辑块，或单元都可以通过通用处理器，数字信号处理器，专用集成电路(ASIC)，现场可编程门阵列或其它可编程逻辑装置，离散门或晶体管逻辑，离散硬件部件，或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器，可选地，该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现，例如数字信号处理器和微处理器，多个微处理器，一个或多个微处理器联合一个数字信号处理器核，或任何其它类似的配置来实现。
上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。
对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。
此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (10)

1.实现分布式集群高可用的方法，其特征在于，包括：
在分布式集群的每个节点中部署VIP进程，在每个节点的主进程中部署Zookeeper客户端，并在主进程与Zookeeper服务端之间建立长连接；
VIP进程对当前状态的主节点中的主进程进行监测以确定当前状态的主节点的健康状态，并在当前状态的主节点发生故障时，由作为当前状态的主节点中的VIP进程删除当前状态的主节点中的VIP，则由剩余的节点以抢占方式确定唯一VIP，以将抢占到唯一VIP的节点作为主节点，并由所述VIP对外提供服务。
2.根据权利要求1所述的方法，其特征在于，所述方法还包括：
由Zookeeper客户端在Zookeeper服务端中建立包含节点名称的持久节点及临时节点，若当前状态的主节点发生故障时，由VIP进程通过判断临时节点是否存在以确定主进程的健康状态。
3.根据权利要求1所述的方法，其特征在于，所述由剩余的节点以抢占方式确定唯一VIP的操作由剩余节点中所部署的VIP进程执行；
所述Zookeeper服务端保存各个节点基于用户发起的操作请求所对应生成的版本号，以在由剩余的节点以抢占方式确定唯一VIP的操作前还包括：
对Zookeeper服务端所保存的版本号进行一致性校验。
4.根据权利要求3所述的方法，其特征在于，所述用户发起的操作请求由读操作、写操作、删除操作、迁移操作或者备份操作中的一种或者几种的任意组合。
5.根据权利要求3所述的方法，其特征在于，将抢占到唯一VIP的节点作为主节点之后，还包括：卸载发生故障的主节点中的VIP。
6.根据权利要求1至5中任一项所述的方法，其特征在于，每个节点中部署的VIP进程与主进程共同被Zookeeper服务端所纳管，所述Zookeeper服务端被配置为Zookeeper进程。
7.根据权利要求6所述的方法，其特征在于，在当前状态的主节点中的VIP进程删除当前状态的主节点中的VIP后，还包括：
对所述被执行删除VIP的主节点的健康状态进行轮询检测，并判断被执行删除VIP的主节点中的主进程与Zookeeper是否恢复连接；
若恢复连接，由Zookeeper进程协调VIP进程在被删除VIP的节点中重新建立VIP或者删除重复的VIP；
若无法恢复连接，由Zookeeper进程从剩余节点中确定唯一VIP。
8.一种实现分布式集群高可用的系统，其特征在于，包括：
两个以上运行主进程的节点，部署于每个节点中的VIP进程，所述主进程中部署Zookeeper客户端，以及Zookeeper服务端；
所述主进程与Zookeeper服务端之间建立长连接，
VIP进程对当前状态的主节点中的主进程进行监测以确定当前状态的主节点的健康状态，并在当前状态的主节点发生故障时，由作为当前状态的主节点中的VIP进程删除当前状态的主节点中的VIP，则由剩余的节点以抢占方式确定唯一VIP，以将抢占到唯一VIP的节点作为主节点，并由所述VIP对外提供服务。
9.根据权利要求8所述的系统，其特征在于，所述Zookeeper服务端被配置为Zookeeper进程，并部署于各节点中，且各节点中不配置数据库。
10.一种计算机可读介质，其特征在于，
所述计算机可读介质中存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行如权利要求1至7中任一项所述的实现分布式集群高可用的方法中的步骤。
CN202110029223.0A 2021-01-11 2021-01-11 实现分布式集群高可用的方法、系统及计算机可读介质 Active CN112887367B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110029223.0A CN112887367B (zh) 2021-01-11 2021-01-11 实现分布式集群高可用的方法、系统及计算机可读介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110029223.0A CN112887367B (zh) 2021-01-11 2021-01-11 实现分布式集群高可用的方法、系统及计算机可读介质

Publications (2)

Publication Number Publication Date
CN112887367A true CN112887367A (zh) 2021-06-01
CN112887367B CN112887367B (zh) 2022-11-01

Family

ID=76047749

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110029223.0A Active CN112887367B (zh) 2021-01-11 2021-01-11 实现分布式集群高可用的方法、系统及计算机可读介质

Country Status (1)

Country Link
CN (1) CN112887367B (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113660350A (zh) * 2021-10-18 2021-11-16 恒生电子股份有限公司 分布式锁协调方法、装置、设备及存储介质
CN114090211A (zh) * 2021-11-23 2022-02-25 中国银行股份有限公司 协调单任务主从程序的方法、装置和相关多服务器系统
CN114826905A (zh) * 2022-03-31 2022-07-29 西安超越申泰信息科技有限公司 一种下层节点切换管理服务的方法、系统、设备及介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106375342A (zh) * 2016-10-21 2017-02-01 用友网络科技股份有限公司 一种基于zookeeper技术的系统集群方法及系统
CN109639794A (zh) * 2018-12-10 2019-04-16 杭州数梦工场科技有限公司 一种有状态集群恢复方法、装置、设备及可读存储介质
CN110858168A (zh) * 2018-08-24 2020-03-03 浙江宇视科技有限公司 集群节点故障处理方法、装置及集群节点
CN112104727A (zh) * 2020-09-10 2020-12-18 华云数据控股集团有限公司 一种精简高可用Zookeeper集群部署方法及系统
CN112115003A (zh) * 2020-09-27 2020-12-22 浪潮电子信息产业股份有限公司 一种服务进程的掉线恢复方法、装置、设备及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106375342A (zh) * 2016-10-21 2017-02-01 用友网络科技股份有限公司 一种基于zookeeper技术的系统集群方法及系统
CN110858168A (zh) * 2018-08-24 2020-03-03 浙江宇视科技有限公司 集群节点故障处理方法、装置及集群节点
CN109639794A (zh) * 2018-12-10 2019-04-16 杭州数梦工场科技有限公司 一种有状态集群恢复方法、装置、设备及可读存储介质
CN112104727A (zh) * 2020-09-10 2020-12-18 华云数据控股集团有限公司 一种精简高可用Zookeeper集群部署方法及系统
CN112115003A (zh) * 2020-09-27 2020-12-22 浪潮电子信息产业股份有限公司 一种服务进程的掉线恢复方法、装置、设备及存储介质

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113660350A (zh) * 2021-10-18 2021-11-16 恒生电子股份有限公司 分布式锁协调方法、装置、设备及存储介质
CN114090211A (zh) * 2021-11-23 2022-02-25 中国银行股份有限公司 协调单任务主从程序的方法、装置和相关多服务器系统
CN114826905A (zh) * 2022-03-31 2022-07-29 西安超越申泰信息科技有限公司 一种下层节点切换管理服务的方法、系统、设备及介质

Also Published As

Publication number Publication date
CN112887367B (zh) 2022-11-01

Similar Documents

Publication Publication Date Title
CN112887367B (zh) 实现分布式集群高可用的方法、系统及计算机可读介质
WO2019085875A1 (zh) 存储集群的配置修改方法、存储集群及计算机系统
US9785691B2 (en) Method and apparatus for sequencing transactions globally in a distributed database cluster
WO2017177941A1 (zh) 主备数据库切换方法和装置
US8949828B2 (en) Single point, scalable data synchronization for management of a virtual input/output server cluster
US8856091B2 (en) Method and apparatus for sequencing transactions globally in distributed database cluster
CN102394914A (zh) 集群脑裂处理方法和装置
CN102355369B (zh) 虚拟化集群系统及其处理方法和设备
WO2016070375A1 (zh) 一种分布式存储复制系统和方法
CN107544783B (zh) 一种数据更新方法、装置及系统
CN103763155A (zh) 分布式云存储系统多服务心跳监测方法
CN103840961A (zh) 双机热备份系统
US20080288812A1 (en) Cluster system and an error recovery method thereof
WO2016180005A1 (zh) 处理虚拟机集群的方法和计算机系统
WO2012097588A1 (zh) 数据存储方法、设备和系统
CN111935244B (zh) 一种业务请求处理系统及超融合一体机
JP5855724B1 (ja) 仮想機器管理装置、仮想機器管理方法及び仮想機器管理プログラム
CN108512753B (zh) 一种集群文件系统中消息传输的方法及装置
JP2019191843A (ja) 接続制御プログラム、接続制御方法、及び接続制御装置
CN114116912A (zh) 一种基于Keepalived实现数据库高可用的方法
CN107357800A (zh) 一种数据库高可用零丢失解决方法
US20240036996A1 (en) Methods and systems to improve input/output (i/o) resumption time by batching multiple non-conflicting operations during a non-disruptive automatic unplanned failover from a primary copy of data at a primary storage system to a mirror copy of the data at a cross-site secondary storage system
CN115145782A (zh) 一种服务器切换方法，MooseFS系统及存储介质
CN109474694A (zh) 一种基于san存储阵列的nas集群的管控方法及装置
CN104052799A (zh) 一种利用资源环实现高可用存储的方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant