CN109257195A - 集群中节点的故障处理方法及设备 - Google Patents

集群中节点的故障处理方法及设备 Download PDF

Info

Publication number
CN109257195A
CN109257195A CN201710564995.8A CN201710564995A CN109257195A CN 109257195 A CN109257195 A CN 109257195A CN 201710564995 A CN201710564995 A CN 201710564995A CN 109257195 A CN109257195 A CN 109257195A
Authority
CN
China
Prior art keywords
node
cluster
fault detection
sub
unreachable
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
CN201710564995.8A
Other languages
English (en)
Other versions
CN109257195B (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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies 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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN201710564995.8A priority Critical patent/CN109257195B/zh
Priority to CA3066853A priority patent/CA3066853A1/en
Priority to PCT/CN2018/082663 priority patent/WO2019011018A1/zh
Priority to EP18832228.3A priority patent/EP3627767B1/en
Publication of CN109257195A publication Critical patent/CN109257195A/zh
Priority to US16/732,749 priority patent/US11115263B2/en
Application granted granted Critical
Publication of CN109257195B publication Critical patent/CN109257195B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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/0686—Additional information in the notification, e.g. enhancement of specific meta-data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/142—Reconfiguring to eliminate the error
    • G06F11/1425—Reconfiguring to eliminate the error by reconfiguration of node membership
    • 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/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • H04L41/065—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis involving logical or physical relationship, e.g. grouping and hierarchies
    • 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/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
    • 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/0677—Localisation of faults
    • 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/12—Discovery or management of network topologies
    • 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/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • 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
    • 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/0823—Errors, e.g. transmission errors
    • 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/0823—Errors, e.g. transmission errors
    • H04L43/0829—Packet loss
    • 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/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • 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/20—Arrangements for monitoring or testing data switching networks the monitoring system or the monitored elements being virtualised, abstracted or software-defined entities, e.g. SDN or NFV
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G06F11/0754—Error or fault detection not based on redundancy by exceeding limits

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Hardware Redundancy (AREA)

Abstract

本申请实施例涉及一种集群中节点的故障处理方法及设备。该方法包括获取集群的故障检测拓扑信息，该故障检测拓扑信息包含所述集群中所有节点之间的故障检测关系；获取故障指示消息，该故障指示消息用于指示检测节点到被检测节点不可达；根据故障检测拓扑信息，以及故障指示消息，确定集群中的子集群，其中，属于不同子集群中的节点互不可达；根据集群的子集群，确定工作集群。通过本申请实施例可以实现以较小的代价，最大程度的保留集群中的可用节点，提高了集群中可用节点的数量，确保了高可用性，降低了集群重启，业务不可用的概率，降低了故障恢复、业务迁移的开销。

Description

集群中节点的故障处理方法及设备
技术领域
本申请涉及计算机技术领域，尤其涉及一种集群中节点的故障处理方法及设备。
背景技术
随着分布式计算和云计算技术在信息领域的发展，传统通信技术(communicationtechnology，CT)领域逐渐向信息通信技术(Information Communications Technology，ICT)转型和发展。ICT是信息技术与通信技术相融合而形成的一个新的概念和新的技术领域。CT向ICT的转型和发展过程中，不可避免地会遇到很多复杂且困难的问题需要解决，如CT领域中复杂网络的运营使得网络成本居高不下，在CT向ICT转型过程中，解决复杂网络问题是一个非常重要和具有挑战的问题。
为了推动CT向ICT的转型，SDN(Software Defined Network，软件定义网络)逐渐发展起来。SDN是Emulex网络一种新型网络创新架构，是网络虚拟化的一种实现方式。而SDN实现分布式或产品云化不可避免的需要解决分布式集群管理等问题。
SDN业务对集群节点的通信能力要求较高，而Akka集群的去中心化架构保证了节点之间的通信能力。因此一些公司采用了Akka集群来构建SDN控制器的集群能力。
Akka集群中节点分为leader节点和非leader节点。其中leader节点的功能是负责节点加入集群或踢出集群，其他功能与普通节点一致。
Akka的故障检测机制是，如果一条链路发生故障或某个节点随机丢包发生故障时，由于Akka无法感知具体是链路故障还是节点丢包故障，只是通过心跳检测到节点之间无法连通，为了保证可靠性，将链路两端的节点都踢出，从而导致高概率将正确的节点踢出。Akka的故障检测与处理机制，导致在网络差的情况下，链路或节点故障(挂掉或严重丢包)场景下，Akka集群的故障处理策略高概率会产生误踢，使得剩下的集群的节点数未过半，而业务很多时候需要集群节点过半才能正常运行，最终导致集群高概率不可用，增加了业务迁移、故障恢复开销，并且对用户使用SDN带来了严重的影响。
集群架构中，关于上述问题，业界技术往往从gossip算法本身或从故障检测角度考虑进行修改，业界一般采用的方法是当节点i与节点j之间心跳不通时，节点i委托其他节点去ping节点j，若委托节点中任意一个节点可与节点j之间ping通，则认为节点j为reachable。该方法增大了故障检测的时间开销和gossip算法同步的数据量。
发明内容
本申请实施例提供了一种集群中节点的故障处理方法及设备，可以实现在集群中链路出现故障时，准确定位到故障节点和故障链路，以较小的代价消除集群中的故障，降低了集群重启，业务不可用的概率。
第一方面，本申请实施例提供了一种集群中节点的故障处理方法。该方法包括：获取集群的故障检测拓扑信息，该集群中的一个节点被集群中的至少一个其他节点执行故障检测，故障检测通常通过检测节点向被检测节点发送检测报文(通常为心跳报文)实现，该故障检测拓扑信息包含所述集群中检测节点与被检测节点之间的故障检测关系；从检测节点获取故障指示消息，该故障指示消息用于指示检测节点到被检测节点不可达；根据故障检测拓扑信息，以及故障指示消息，确定集群中的子集群，其中，属于不同子集群中的节点互不可达；根据集群的子集群，确定工作集群，其中，本申请实施例中的集群可以为去中心化集群。获取集群的故障检测拓扑信息具体可以包括：接收所述集群中其他节点发送的故障检测拓扑信息；或者，基于预设规则进行推算故障检测拓扑信息。通过本申请实施例可以实现在集群中链路出现故障时，结合集群的故障检测拓扑信息以及故障指示消息，确定集群排除故障链路后形成的子集群，根据子集群确定工作集群，能够选择最优的子集群作为工作集群，例如，可以选择包含节点数最多的子集群，相对于直接删除故障链路两端的两个节点，或者通过额外的检测来确定要删除的节点。
容易理解的是，集群中任意一个节点既可以作为检测节点的角色，也可以作为被检测节点的角色，也可以在不同故障检测关系中同时承担检测节点和被检测节点的角色。
本申请实施例通过故障检测拓扑信息以及故障指示消息来确定子集群，可以以较小的代价，确定集群发生故障后所产生的可用子集群，最大程度的保留集群中的可用节点，提高了集群中可用节点的数量，确保了高可用性，降低了集群重启，业务不可用的概率，降低了故障恢复、业务迁移的开销。
在一种可选的实现方式中，在确定工作集群时，可以采用如下列举方式：
根据节点数量确定工作集群。例如，确定节点数量最多的子集群为工作集群；
根据种子节点确定工作集群。例如，确定种子节点最多的子集群为工作集群；
根据运行主业务的节点确定工作集群。例如，确定运行主业务的节点最多的子集群为工作集群；
根据健康状态或者可用资源状态确定工作集群。例如，确定健康状态满足预设条件的节点数量最多的子集群为工作集群；或者，确定可用资源状态满足预设条件的节点数量最多的子集群为工作集群。
此外，以上列举的方式可以多个考虑因素同时采用，例如，确定包含种子节点，且节点数量最多子集群为工作集群；或者，确定健康状态满足预设条件，且运行主业务的节点数量最多的集群未工作集群等
在一种可选地实现方式中，根据故障检测拓扑信息，以及所述故障指示消息，确定集群中的子集群时，根据故障检测拓扑信息所形成的故障检测关系拓扑图，标记出故障指示消息所对应的故障边，从而确定集群中的故障链路和/或故障节点，根据所确定的故障链路和故障节点确定节点互不可达的子集群。本申请实施例根据故障检测关系拓扑图，基于图论，可以根据更全面信息，更合理的确定出故障链路和故障节点，以便更合理的确定出工作集群。
在一种可选地实现方式中，根据故障检测拓扑信息，以及故障指示消息，确定集群中的子集群时，根据集群中节点的网络连接关系所形成的网络拓扑图，标记出根据故障指示消息以及故障检测拓扑信息所确定的故障节点和故障链路，从而确定集群中的故障链路和故障节点，根据所确定的故障链路和故障节点确定节点互不可达的子集群。本申请实施例根据网络拓扑图，基于图论，可以根据更全面信息，更合理的确定出故障链路和故障节点，以便更合理的确定出工作集群。
在一种可选地实现中，若一节点被多个节点所检测，且根据故障指示消息所有检测该节点的检测节点到该节点均不可达，则该节点为故障节点；若一节点被多个节点所检测，且根据故障指示消息检测该节点的检测节点有部分到该节点不可达，而部分检测节点到该节点仍然可达，则不可达的检测节点到该节点之间的链路为故障链路。
在一个可选地实现中，前述根据所述集群的子集群，确定工作集群时，可以选择子集群中代价最小且保证能够正常工作的子集群作为工作集群，其中，子集群继承集群的属性越多，代价越小，该属性可以包括节点的数量、种子节点的数量以及运行的主业务等等。具体地可以根据所述集群的子集群，确定工作集群包括下述任意一种或多种方式：确定节点数量最多的子集群为工作集群；确定包含种子节点，且节点数量最多的子集群为工作集群；确定包含种子节点最多的子集群为工作集群；确定运行主业务的节点最多的子集群为工作集群；以及，基于健康状态或者可用资源状态确定工作集群。通过本申请实施例，可以实现选择工作集群的选择，以满足工作集群能够正常运行，最健康或者影响现有业务的代价最小等等条件。
在另一个可选地实现中，前述根据故障检测拓扑信息，以及故障指示消息，确定集群中的子集群包括：根据故障检测拓扑信息，确定基于节点之间的故障检测关系的拓扑图，从拓扑图中删除故障指示消息所对应的边，确定删除后的拓扑图的连通子图，根据连通子图确定子集群，另外，可以根据拓扑图的连通分量或者强连通分量对应的子集群确定为工作集群。通过本申请实施例可以实现结合能够体现集群汇总节点的故障检测关系的拓扑图来实现子集群的确定，通过拓扑图中的连接关系，可以更方便准确的确定出子集群。
在再一个可选地实现中，在确定工作集群后，该工作集群中可能还包括故障链路，也就是故障指示信息中的检测节点和被检测节点都包含在该工作集群中，此时，可以通过删除工作集群中的一个或多个节点来消除故障链路。其中，可以根据预设规则确定要删除的节点。具体地，该方法还包括：确定工作集群中的不可达节点中故障指示消息指向最多的不可达节点为要删除的节点；向集群中其他节点发送第一指示消息，该第一指示消息用于指示所述要删除的节点。通过本申请实施例，可以进一步地实现工作集群中故障链路的消除，通过确定故障指示消息指向最多的不可达节点为要删除的节点，相对于现有技术中直接删除链路两端的两个节点，或者通过额外的检测来确定要删除的节点，本申请实施例可以以较小的代价，最大程度的保留集群中的可用节点，提高了集群中可用节点的数量，确保了高可用性，降低了集群重启，业务不可用的概率，降低了故障恢复、业务迁移的开销。
本实施例的执行主体可以是集群中的任意一个节点，在一些实施例中，将该节点称之为控制节点。在一个可选地实现中，删除的节点可以为控制节点本身。通过本申请实施例，若控制节点自己在故障链路上，需要确定自己是否为要删除的节点，以保证每个节点看到的信息一致，提高故障节点和故障链路定位的准确性。
在另一个可选地实现中，前述确定所述工作集群中的不可达节点中故障指示消息指向最多的不可达节点为要删除的节点包括：确定所述工作集群中的不可达节点中故障指示消息指向最多的不可达节点，且健康状态最差的一个为要删除的节点，该健康状态基于节点对心跳报文的响应的时间所确定。通过本申请实施例，可以根据故障指示消息指向次数以及健康状态，以较小的代价删除不可达节点，降低业务不可用的概率。
第二方面，一种集群中节点的故障处理方法。该方法包括：获取集群的故障检测拓扑信息，集群中的一个节点被所述集群中的至少一个其他节点执行故障检测，所述故障检测拓扑信息包含所述集群中检测节点与被检测节点之间的故障检测关系；获取故障指示消息，该故障指示消息用于指示检测节点到被检测节点不可达；根据所述故障检测拓扑信息确定故障指示消息指向最多的不可达节点为要删除的节点。通过本申请实施例，控制节点仅需要接收集群中其他节点所发送的故障检测消息即可确定要删除的节点，相对于现有技术，控制节点无需对其他节点进行直接检测，从而减少了控制节点的负担。当集群中选择任意节点作为控制节点时，减小了对该节点的原有业务的影响。
在另一个可选地实现中，前述确定所述工作集群中的不可达节点中故障指示消息指向最多的不可达节点为要删除的节点包括：确定所述工作集群中的不可达节点中故障指示消息指向最多的不可达节点，且健康状态最差的一个为要删除的节点，该健康状态基于节点对心跳报文的响应的时间所确定。通过本申请实施例，可以根据故障指示消息指向次数以及健康状态，以较小的代价删除不可达节点，降低业务不可用的概率。
在一种可能的实现方式中，在确定的要删除的节点之后，根据故障检测拓扑信息，确定集群中删除的节点和未被删除的节点形成的子集群，其中，属于不同子集群中的节点互不可达，；根据集群的子集群，确定工作集群。通过本申请实施例可以实现在集群中链路出现故障时，根据拓扑图准确定位到故障节点和故障链路，以较小的代价删除集群中的不可达节点，降低了集群重启，业务不可用的概率，降低了故障恢复、业务迁移的开销。
在一些可能的实现方式中，在确定子集群时，可以根据第一方面所提供的方法确定子集群。
第三方面，本申请实施例提供了一种故障处理设备。该故障处理设备具有实现上述方法实际中节点的行为的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的单元。
在一个可选地实现中，该故障处理设备包括：收发器、处理器以及存储器，收发器用于与其他节点进行通信，存储器用于用户存储数据和程序。当故障处理设备运行时，处理器执行存储器存储的计算机执行指令，以使故障处理设备执行如第一方面以及第一方面的各种可选方式中或者第二方面以及第二方面的各种可选方式中的故障处理方法。
第四方面，本申请实施例提供了一种计算机可读存储介质，用于储存为上述故障处理设备所用的计算机可读指令，其包含用于执行上述第一方面以及可选地实现中或者第二方面以及第二方面的各种可选方式中所设计的程序。
第五方面，本申请实施例提供了一种计算机程序产品，用于储存为上述故障处理设备所用的计算机可读指令，其包含用于执行上述第一方面以及可选地实现中或者第二方面以及第二方面的各种可选方式中所设计的程序。
附图说明
图1为一种网络架构示意图；
图2为本申请实施例提供的一种集群中节点的故障处理方法信令交互示意图；
图3为本申请实施例提供的另一种集群中节点的故障处理方法流程示意图；
图4为本申请实施例提供的一个示例；
图5为本申请实施例提供的另一个示例；
图6为本申请实施例提供的又一个示例；
图7为本申请实施例提供的再一个示例；
图8为本申请实施例提供的再一个示例；
图9为本申请实施例提供的一种故障处理装置结构示意图；
图10为本申请实施例提供的一种故障处理设备结构示意图。
具体实施方式
本申请实施例提供的集群中节点的故障处理方法及设备，可以应用于去中心化集群应对节点故障的处理，具体地，集群中的节点对故障节点的删除，以及进一步地选择工作集群等等。
本申请实施例提供的集群中节点的故障处理方法适用于如图1所示的场景中。如图1所示，集群包括多个节点，其中，负责节点加入集群或踢出集群的节点为控制节点10，其他节点为普通节点20，例如，图1中的普通节点20包括普通节点201、普通节点202、普通节点203以及普通节点204等等。控制节点10为集群中包括的多个节点中符合预设规则的节点，例如，一般选择集群中的多个节点中IP+Port最小的可达(reachable)节点作为控制节点，如果控制节点出现故障或者其他情况的影响需要重新确定控制节点，则依据此规则在剩余的多个可达节点中选择控制节点。
以Akka集群为例，Akka集群中任何一个成员节点都有可能成为集群的Leader(即，控制节点)，这是基于Gossip收敛(Convergence)过程得到的确定性结果。Leader只是一种角色，在各轮Gossip收敛过程中Leader是不断变化的。Leader的职责是使成员节点(即，普通节点)进入或离开集群。
一个成员节点开始于joining状态，一旦所有节点都看到了该新加入Akka集群的节点，则Leader会设置这个节点的状态为up。
如果一个节点安全离开Akka集群，可预期地它的状态会变为leaving状态，当Leader看到该节点为leaving状态，会将其状态修改为exiting，然后当所有节点看到该节点状态为exiting，则Leader将该节点删除，状态修改为removed状态。
如果一个节点处于不可达(unreachable)状态，基于Gossip协议Leader是无法执行任何操作收敛(Convergence)到该节点的，所以unreachable状态的节点的状态是必须被改变的，它必须变成reachable状态或者down状态(即，从集群中删除)。如果down状态的节点想再次加入到Akka集群，它需要重新启动，并且重新加入集群(经由joining状态)。
为了集群能够正常运行，集群中的节点通过故障检测来识别故障，以便进行故障处理。其中，节点与节点之间的故障检测关系可包括单向检测和双向检测。两个节点之间只有其中一个检测的为单向检测，两个节点之间互相检测为双向检测。例如，结合图1所示，若控制节点10检测普通节点202，而普通节点202检测控制节点10，则控制节点10与202之间为单向检测。若控制节点10与普通节点201之间可以相互检测，则控制节点10与普通节点201之间为双向检测。
应该知道的是，图1所示的集群仅为示例，本申请实施例中的集群可以包括更多或更少的节点，集群中的节点也可以包括其他的连接方式。
本申请提供了集群中节点的故障处理方法、装置及设备。通过结合集群的故障检测拓扑信息以及故障指示消息，确定集群排除故障链路后形成的子集群，根据子集群确定工作集群，能够选择最优的子集群作为工作集群，例如，可以选择包含节点数最多的子集群，相对于直接删除故障链路两端的两个节点，或者通过额外的检测来确定要删除的节点，本申请实施例可以以较小的代价，最大程度的保留集群中的可用节点，提高了集群中可用节点的数量，确保了高可用性，降低了集群重启，业务不可用的概率，降低了故障恢复、业务迁移的开销。
下面结合附图，通过具体的实施例及其应用场景对本申请实施例提供的一种集群中节点的故障处理方法、装置及设备进行详细地说明。
图2为本申请实施例提供的一种集群中节点的故障处理方法信令交互示意图。如图2所示该方法具体包括：
S210，控制节点获取集群的故障检测拓扑信息，该拓扑信息包含该集群中检测节点与被检测节点之间的故障检测关系。其中，集群中的一个节点被集群中的至少一个其他节点进行故障检测。
集群的故障检测拓扑信息可以根据节点检测机制确定。具体的，每个节点向控制节点发送故障检测拓扑消息，每个故障检测拓扑消息用于指示一个节点所故障检测的一个或多个或节点。控制节点接收集群中其他节点发送的多个故障检测拓扑消息，结合自身所故障检测的所有节点，可以得到集群中所有节点之间的故障检测关系。
另外，集群中的故障检测拓扑信息还可以根据预设规则推算。例如，对集群中的节点进行编号，并确定预设规则为每个节点检测本节点编号后两位的两个节点。则控制节点在确定了集群中的节点编号以及预设规则后，既可以推算出节点之间的故障检测关系，从而获取故障检测拓扑信息。
S220，控制节点从检测节点获取故障指示消息，该故障指示消息用于指示检测节点到被检测不可达。
节点在确定与其所检测的节点之间的链路不可达时，可以向与其连接的节点(包括控制节点)发送故障指示消息，该消息中，检测节点为其本身，被检测节点为其所检测的节点。
集群中的每个节点上可以根据故障指示消息维护一个全局集群节点列表，该列表可以体现集群中各个节点的状态，其中，节点的状态包括节点是否被检测为不可达，以及被哪个节点标检测为不可达。
其中，不可达还可以认为是一个节点状态的一个额外标志，该标志用于标识集群中的节点不能与该节点正常通讯。
S230，控制节点根据故障检测拓扑信息，以及故障指示消息，确定集群中的子集群，其中，属于不同子集群中的节点互不可达。
由于故障检测消息仅能确定被检测节点不可达，而无法确定是由于检测节点到被检测节点之间的链路故障导致不可达，还是由于被检测节点故障导致的不可达。因此，在获取了基于全部节点之间的故障检测关系所构成的故障检测拓扑信息的基础上，根据故障指示消息，可以结合获得包含了当前的故障指示消息的故障检测拓扑图。基于图论的相关理论，可以确定在发生故障后集群分裂成的子集群。
在一种该实现方式中，可以在基于故障检测关系的拓扑信息形成故障检测关系拓扑图，该故障检测关系拓扑图中的每一条有向边表示检测节点与被检测节点之间的检测关系。当获取了故障指示消息后，将该故障指示消息所对应的检测节点与被检测节点之间的边标记为故障边，从而得到了包含当前故障边的故障检测关系拓扑图。基于该拓扑图，可以判断集群中的故障链路以及故障节点。例如，若指向同一节点的单向边中，既存在故障边，也存在正常的边，则所述故障边对应的被检测的链路为故障链路；若指向同一节点的单向边均为故障边，则该节点为故障节点。根据所确定的故障节点和故障边，即可判断集群是否分裂为了互不可达的子集群。
可以理解的，在一些情况下，集群中虽然出现了故障链路或者故障节点，但是集群中的所有节点仍然相互可达，即集群并未分裂为子集群。在这种情况下，所确定的子集群即为原集群本身。
S240，根据集群的子集群，确定工作集群。
在确定工作集群时，可依据三条原则：业务可用性、集群可扩展性和业务可靠性。
控制节点在排除出故障的链路后，确定集群中的所有节点构成一个子集群时，该子集群即为工作集群。
控制节点在排除出故障的链路后，确定集群中所有节点构成多个子集群时，可以根据下述一种或多种方式确定工作集群：
确定节点数量最多的子集群为工作集群；
确定包含种子节点，且节点数量最多的子集群为工作集群；
确定包含种子节点最多的子集群为工作集群；
确定运行主业务的节点最多的子集群为工作集群，主业务可以是指所有业务中的重点业务，也可以是指主备业务中的主业务；
以及，基于健康状态或者可用资源状态确定工作集群；等等。
需要说明的是，集群可分为种子节点和非种子节点，种子节点通过在配置文件中静态配置，是普通节点加入集群的联系点。非种子节点(普通节点)，通过种子节点动态加入集群。
举例来说，控制节点可以根据如下条件来确定工作集群。
保留节点数量多，且至少含有一个种子节点的子集群作为工作集群。若节点数最多且包含至少一个种子节点的子集群有唯一的一个，则确定子集群中节点数最多且包含至少一个种子节点的子集群为工作集群。若节点数量最多的子集群包括至少两个，该至少两个子集群节点数相同，且都包含种子节点，则保留至少两个子集群中种子节点多的子集群作为工作集群。换句话说，若节点数最多且包含至少一个种子节点的子集群有多个，则确定节点数最多且包含的种子节点的数量最多的子集群为工作集群。若节点数量最多且包含种子节点最多的子集群包括至少两个，该至少两个子集群节点数及包含的种子节点数相同，则确定种子节点中ip+port最小节点所在子集群为工作集群。
可以保证只有一个子集群存活，也就是仅保证工作集群中的节点工作，其他节点可以关机、下线或离开集群等等，以便集群能够正常的工作。
接下来，控制节点在确定工作集群后，工作集群中可能还存在故障链路，一般故障链路不会造成集群脑裂，也就是不会使集群分为多个子集群。控制节点还可以通过决策来消除工作集群中的故障链路，具体还可以包括如下步骤：
S250，确定工作集群中的不可达节点中故障指示消息指向最多的不可达节点为要删除的节点。
其中，故障指示消息指向最多的不可达节点即为，工作集群中的节点在故障消息中作为被检测节点的节点。
故障指示消息指向为不可达节点的次数至少可以有如下多种统计方式。
可以直接对接收到的故障指示消息进行统计，确定出节点作为被检测节点的次数。
还可以是，集群中的每个节点上可以维护一个全局集群节点列表，该列表可以体现集群中各个节点的状态，其中，节点的状态包括节点是否可达，还可以进一步统计不可达节点不可达的次数，不可达节点的不可达的次数越多，即可认为故障指示消息指向最多。
例如，集群中各个节点可以接收至少一个故障指示消息；若结合集群中所有节点的故障检测关系确定检测节点与被检测节点之间为单向故障检测，则将该指示消息对应的被检测节点标记为不可达一次，例如，可建立不可达节点集合，将不可达节点添加在不可达节点集合中，并记录不可达次数；若检测节点与被检测节点之间为双向故障检测，则将该故障指示消息对应的检测节点和被检测节点添加在不可达节点集合中，并分别记录不可达次数。若故障指示消息中的检测节点或被检测节点为其本身，则将其本身添加在不可达节点集合中，并记录不可达次数，以便集群中所有节点统计的不可达节点以及其对应的不可达次数一致。
下面对不可达节点的确定进行更详细的介绍。
方式一，若集群中只包含单向链路，在集群正常启动后，集群中的各个节点获取故障检测拓扑信息。集群中的节点接收故障指示消息，该故障指示消息用于指示unreachable事件，即，用于指示检测节点到被检测节点不可达，则将全局集群节点列表中对应的被检测节点标记为不可达，并且每被一个节点检测到一次不可达，则不可达次数加1。
方式二，若集群中只包含双向链路，在集群正常启动后，集群中的各个节点获取故障检测拓扑信息。集群中节点接收故障指示消息，则在全局集群节点列表中将故障指示消息对应的检测节点和被检测节点标记为不可达，并且每接收到一次故障指示消息，则检测节点和被检测节点的不可达次数都分别1。例如，在丢包场景下，通过心跳检测链路时好时坏，坏的时候被检测到unreachable，不可达次数加1，好的时候又被检测到reachable，再坏的时候又被检测到unreachable，不可达次数再加1，会不停重复上述过程，直至问题解决。其中，节点根据指示消息确定被检测节点和检测检点包括其自身时，该节点在自身维护的全局集群节点列表中将其自身标记为不可达。
例如，结合图3所示，若节点303出现严重丢包。以节点303为例：
第一次：节点301被节点303发现为unreachable，由于节点301与节点303之间为双向链路，则节点303中unreachable次数统计情况如下表1所示：
表1
节点 unreachable次数
节点301 1
节点302 0
节点303 1
第二次：节点302被节点303标记为unreachable，由于节点302与节点303之间为双向链路，则节点303中unreachable次数统计情况如下表2所示：
表2
节点 unreachable次数
节点301 1
节点302 1
节点303 2
方式三，若集群中既包含双向链路又包含单向链路，在集群正常启动后，集群中的各个节点获取故障检测拓扑信息。集群中的节点接收故障指示消息。集群中的每个节点结合故障检测拓扑信息判断，若检测节点与被检测节点之间的链路为双向链路，将全局集群节点列表中对应的检测节点和被检测节点标记为不可达，以及检测节点和被检测节点的不可达次数加1；若检测节点与被检测节点为单向链路，则将全局集群节点列表中对应的被检测节点标记为不可达，对被检测节点的不可达次数加1。其中，节点根据指示消息确定被检测节点和检测检点包括其自身时，且检测节点和被检测节点之间为双向链路时，该节点在自身维护的全局集群节点列表中将其自身标记为不可达，自身的不可达次数加1。
例如，节点i收到节点j被节点k发现为unreachable时(i≠k)，将节点j的unreachable次数加1；节点i收到节点j被节点i发现为unreachable时，根据故障检测拓扑信息，确定节点i与节点j之间是否为双向链路，若为双向链路，则节点i在故障链路上，将节点i和节点j的unreachable次数分别加1；若为单向链路，将节点j的unreachable次数加1。
每个节点上维护的全局集群节点列表的形式可以如表3所示：
表3
节点 unreachable次数
节点1 …
节点2 …
节点3 …
… …
另外，在确定要删除的节点时，还可以根据健康状态来确定，删除最不健康的一个。健康状态可以根据节点对心跳报文的响应时间所确定。例如，节点的健康状态可以是节点的Phi值，其中，Phi值计算原理是根据历史最近采样n次(如1000次)学习得到一个正态分布函数，然后根据当前心跳响应时间评估当前心跳的健康状态，phi值越大，心跳越不健康。当phi值超过设定的阈值时，则认为节点为unreachable。
节点的健康状态还可以通过全局集群节点列表中节点的不可达次数来确定，其中，节点的不可达次数越多，节点越不健康。
S260，向集群中其他节点发送指示消息，该指示消息用于指示要删除的节点。
控制节点在确定要删除的节点后，需要通知集群中的其他节点，以使得其他节点将该要删除的节点删除，或者将该要删除的节点标记为删除状态(例如，down状态)，确保集群能够正常的工作。
另外，由于只有控制节点才有权限对集群中的节点进行删除的操作，所以集群中的节点可以判断自己是否为控制节点，在自己是控制节点时，再执行步骤S250-S260。
另外在本身请实施例中，若通过执行S210-S230后，还会接收到包括unreachable事件的指示消息，也就是，可能还存在不可达节点，则继续执行S250-S260，如此迭代，直至不会再收到包括unreachable事件的指示消息。
图3为本申请实施例提供的另一种集群中节点的故障处理方法流程示意图。节点可根据故障检测信息生成拓扑图，可以结合拓扑图进行故障处理。如图3所示该方法具体包括：
S310，获取集群的故障检测拓扑信息。其中，故障检测拓扑信息包含集群中检测节点与被检测节点之间的故障检测关系。其中，集群中的一个节点被集群中的至少一个其他节点进行故障检测。
故障检测拓扑信息的获取可以参见前述结合图2所示的实施例中的S210。此处不再赘述。
S320，从检测节点获取故障指示消息，该故障指示消息用于指示检测节点到被检测不可达。
故障指示消息的获取可以参见前述结合图2所示的实施例中的S220。此处不再赘述。
S330，根据故障检测拓扑信息，确定节点之间的故障检测关系拓扑图，从故障检测关系拓扑图中删除故障指示消息所对应的边，确定删除后的故障检测关系拓扑图的连通子图，根据连通子图确定子集群。
根据集群中节点的故障检测拓扑信息包括的集群中各个节点之间的故障检测关系。根据各个节点之间的故障检测关系可以确定集群的故障检测关系拓扑图。
在具体实施过程中，故障检测关系拓扑图中的各个节点之间可以通过有向边连接，也即故障检测关系拓扑图中体现故障检测的方向。或者，故障检测关系拓扑图中的各个节点之间也可以通过无向边连接，也即故障检测关系拓扑图中不体现故障检测的方向。
例如，若集群中节点与节点之间只包含双向故障检测关系或者仅包含单向故障检测关系，则在确定故障检测关系拓扑图时，即可以为有向图，也可以是无向图。若集群中节点之间即包含双向故障检测关系又包含单向故障检测关系，则在确定故障检测关系拓扑图时，可以为有向图。故障检测关系拓扑图中的节点通过有向边连接的为有向图，拓扑图中的节点通过无向边连接的为无向图。
另外，还可以在获取到集群的故障检测拓扑信息后，即确定故障检测关系拓扑图。例如，以Akka集群中的心跳检测机制为例，节点可根据接收到的基于心跳检测机制的故障检测拓扑信息，来确定Akka集群中节点的故障检测关系拓扑图。例如，若接收的故障检测拓扑信息中包括节点a为检测节点、节点b为被检测节点，以及节点b为检测节点、节点a为被检测节点的故障检测拓扑信息时，则确定节点a与节点b连接，且节点a与节点b之间为双向检测关系；若接收的故障检测拓扑信息中只包括节点a为检测节点、节点b为被检测节点的信息时，则确定节点a与节点b连接，且节点a与节点b之间为单向检测关系，若根据故障检测拓扑信息形成的故障检测关系拓扑图为有向图，节点a和节点b之间的连接关系对于节点b来说为入度；若接收的集群的故障检测拓扑信息中只包括节点b为检测节点、节点a为被检测节点的指示消息时，则确定节点a与节点b连接，且节点a与节点b之间为单向故障检测关系。
接下来，故障指示消息指示了检测节点到被检测节点不可达，在基于节点之间故障检测关系拓扑图中删除该检测节点到被检测节点之间的边，确定删除后的故障检测关系拓扑图的连通子图，每个连通子图相互独立，连通子图与连通子图之间不存在相互连接的节点。每个连通子图对应一个子集群。
在本发明实施例具体实施过程中，通常集群中的检测节点与被检测节点之间的检测关系比较丰富，使得检测关系能在一定程度上体现网络拓扑关系，换句话说，集群中故障检测关系能够检测集群中所有的节点，根据故障检测关系拓扑图即可实现集群的链路状态的判断。
在另一种实现方式中，S330还可以替换为根据故障检测拓扑信息，以及故障指示消息，确定集群中的故障节点和故障链路，从集群的网络拓扑图中删除故障节点和故障链路，确定删除后的网络拓扑图的连通子图，根据删除后的网络拓扑图的连通子图确定所述子集群，其中，网络拓扑图包含了集群的所有节点之间的网络连接信息。
在该种实现方式中，由于故障检测关系拓扑图一般不完全等同于网络拓扑图，也就是说，集群中的故障检测关系并没有遍及集群中的所有链路，所以在根据网络拓扑图在确定子集群时，首先需要确定是节点出现故障，还是链路出现故障。例如，若指向同一节点的单向边中，既存在故障边，也存在正常的边，则所述故障边对应的被检测的链路为故障链路；若指向同一节点的单向边均为故障边，则该节点为故障节点。对于节点出现故障，在网络拓扑图中，即可认为与该节点的所有连接均断开，对于链路出现故障，在网络拓扑图中，即可认为仅有该故障连链路对应的边断开。根据所确定的故障节点和故障边，结合网络拓扑图即可判断集群是否分裂为了互不可达的子集群，以及具体分裂成了哪些子集群。
S340，根据集群的子集群，确定工作集群。
确定工作集群的原则以及方式可参见前述实施例中S240中的相关描述。
另外，在本发明实施例中，在确定工作集群时，可以确定删除后的故障检测关系拓扑图或网络拓扑图的连通子图中的连通分量或强连通分量，确定该连通分量或强连通分量对应的子集群为工作集群。
其中，若故障检测关系拓扑图或网络拓扑图为有向图，则删除故障指示消息对应的边后，形成的连通子图中最大的一个称为强连通分量。若故障检测关系拓扑图或网络拓扑图为无向图，则删除故障指示消息对应的边后，形成的连通子图中最大的一个称为连通分量。
若删除故障指示消息对应的边后的故障检测关系拓扑图或网络拓扑图具有多个连通分量或强连通分量，则可以进一步结合种子节点、运行主业务的节点，健康状态以及可用资源状态等等确定工作集群。具体可参见前述实施例中S240中的相关描述。
接下来，控制节点在确定工作集群后，工作集群中可能还存在故障链路，一般该故障链路不会造成集群脑裂，也就是不会使集群分为多个子集群。控制节点还可以通过决策来消除工作集群中的故障链路，具体还可以参见前述实施例中步骤S250-S260中的描述。
另外，控制节点还可以结合故障检测关系拓扑图或网络拓扑图确定要删除的节点。
具体地，集群中节点的故障检测关系拓扑图包括集群中各个节点之间的故障检测关系对应的边，在网络拓扑图中包括各个节点之间的网络连接关系对应的边。结合图论，根据故障检测关系拓扑图或网络拓扑图，可以确定节点的度值。控制节点可以从集群中删除度值最高的不可达节点，进一步的，控制节点可以从集群中删除不可达节点集合中故障边构成的入度值最高的不可达节点。其中，不可达节点涉及的故障链路越多，该节点为故障节点的概率越大。其中，不可达节点的故障链路构成的入度值是指，在故障检测关系拓扑图或网络拓扑图中不可达节点作为故障链路指向的节点的次数。
另外，故障边入度值最高的不可达节点可以包括多个故障边入度值相同的不可达节点，此时，可以进一步根据不可达节点的健康状态，确定最不健康的一个不可达节点为要删除的节点。
其中，控制节点在删除一个节点后，还可以将删除该节点后形成的孤点以及其他需踢出的节点确定为要删除的节点，其中，孤点是指在故障检测关系拓扑图或网络拓扑图中入度和出度都为0的节点。
具体地，控制节点确定删除要删除的节点后的集群中的故障检测关系拓扑图或网络拓扑图，根据删除要删除的节点后集群中的故障检测关系拓扑图或网络拓扑图确定所有边出度和入度都为0的节点为继续要删除的节点。
通过本申请实施例可以实现，一条链路出现故障，只踢出这条链路中的一个节点(phi值大或unreachable次数最多的节点)，剩下的节点若与其他节点链路未出现故障，则可以正常运行。n条链路(平行，无交集)出现故障，每条链路踢出一个节点(phi值大或unreachable次数最多的节点，共n个节点)，剩下的节点若与其他节点链路未出现故障，则可以正常运行，n为正整数；n条链路(存在交集)出现故障，踢出交点(交点涉及故障链路数多优先踢；链路数相同的交点，选择phi值大或unreachable次数最多的节点)，剩下的节点若与其他节点链路未出现故障，则可以正常运行。
在另一个实施例中，还可以先删除要删除的节点，在控制节点删除要删除的节点后，可以确定工作集群，该工作集群为子集群中节点数最多且包含至少一个种子节点的子集群，该子集群为不包含要删除的节点或者仅包含要删除的节点的集群中节点的集群。
集群中节点的拓扑信息包括集群中各个节点之间的故障检测关系，根据该故障检测关系，确定故障指示消息指向最多的不可达节点为要删除的节点。例如，可以根据基于节点之间的故障检测关系的拓扑图，可以确定不可达节点的度值。控制节点可以从集群中删除不可达节点集合中故障边构成的入度值最高的不可达节点，进一步的，控制节点可以通知集群中的各个节点从集群中删除要删除的节点。
另外，不可达节点集合中故障边构成的入度值最高的节点可以包括多个故障边构成的入度值相同的不可达节点，此时，可以进一步根据不可达节点的健康状态，确定最不健康的一个不可达节点为要删除的要删除的节点。
集群中多个故障边构成的入度值最高，最不健康的节点包括多个，则确定ip+port最大的节点为要删除的节点。以此，保护控制节点，因为一般控制节点为ip+port最小的节点。
其中，控制节点删除要删除的节点后，被删除的节点会形成至少一个子集群，未被删除的节点也会形成至少一个子集群。集群中的各个节点可根据拓扑图以及被删除的节点确定自己所在的子集群，并确定自己所在的集群是否为工作集群，如果自己所在的集群是工作集群，则该工作集群中的各个节点处于工作状态；如果确定自己所在的集群不是工作集群，则该集群中的各个节点可以处于关机状态。
在确定工作集群时，可依据三条原则：业务可用性、集群可扩展性和业务可靠性。
具体地：保留节点数量多，且至少含有一个种子节点的子集群作为工作集群。
若节点数最多且包含至少一个种子节点的子集群有唯一的一个，则确定子集群中节点数最多且包含至少一个种子节点的一个子集群为工作集群。
若节点数量最多的子集群包括至少两个，该至少两个子集群节点数相同，且都包含种子节点，则保留至少两个子集群中种子节点多的集群作为工作集群。换句话说，若节点数最多且包含至少一个种子节点的子集群有多个，则确定节点数最多且包含的种子节点的数量最多的一个子集群为工作集群。
若节点数量最多且包含种子节点最多的子集群包括至少两个，该至少两个子集群节点数及包含的种子节点数相同，则保留种子节点中ip+port最小节点所在集群。
保证只有一个子集群存活，以便集群能够正常的工作。
在具体实现时，集群中各个节点在接收到leader节点发送的用于指示要删除的节点的指示消息时，结合集群中节点的故障检测关系拓扑图或网络拓扑图，判断自己所在的子集群，以及该子集群是否为工作集群。
当根据故障检测关系拓扑图或网络拓扑图确定自己所在的子集群为节点数最多且包含种子节点的子集群时，确定自己所在的子集群为工作集群；当根据故障检测关系拓扑图或网络拓扑图确定自己所在的子集群不是节点数最多的子集群时，确定自己所在的子集群为非工作集群。
当根据故障检测关系拓扑图或网络拓扑图确定自己所在的子集群，是节点数量最多的子集群的至少两个中的一个时，该至少两个节点数量最多的子集群节点数相同，且都包含种子节点。则进一步判断自己所在的集群是否为至少两个节点数量最多的子集群中包含的种子节点最多集群：若是，则确定自己所在的子集群为工作集群；若不是，确定自己所在的子集群为非工作集群。
当根据故障检测关系拓扑图或网络拓扑图确定自己所在的子集群，是节点数量最多且包含种子节点最多的至少两个子集群中的一个，该至少两个子集群节点数及包含的种子节点数相同，则进一步判断种子节点中ip+port最小节点是否在自己所在的子集群中：若是，则确定自己所在的子集群为工作集群；若不是，确定自己所在的子集群为非工作集群。
在一个示例中，如图4所示，以3节点集群为例，节点411为控制节点。每个节点被集群中其他两个节点检测(监控)，检测节点之间每隔一秒发送一次心跳报文。若节点412与节点413之间的链路出现故障，在故障检测时，节点412告知节点411“节点413为unreachable”，节点413告知节点411“节点412为unreachable”。
依据Akka现有故障处理机制，节点412和节点413均会被节点411踢出集群，使得最终节点411、节点412和节点413形成三个独立网络分区。
对于委托方法的故障处理机制，在出现上述情况后，节点412发现节点413为unreachable，则委托节点411去ping节点413，节点411能连通节点413，于是节点413被标记为reachable；节点413发现节点412为unreachable，则委托节点411去ping节点412，发现节点412为reachable，则节点412被标记为reachable。由此，不会踢出任何节点；节点412和节点413的链路故障一直持续，业务数据会一直存在丢包现象。
基于本申请实施例，在如图4所示的情况出现时，首先确定集群中如图4所示的故障检测信息(例如，故障检测关系拓扑图)，然后确定排除故障链路后，形成一个子集群，确定该子集群为工作集群，由于该子集群中依然存在故障链路，故继续确定要删除节点，其中，故障指示消息指向最多节点为节点412和节点413，进一步确定节点412和节点413中的一个为要删除的节点。删除节点412或节点413，后工作集群为“节点411，节点413”，或者，“节点411，节点412”。
在另一个示例中，如图5所示，若节点503出现严重丢包。
故障检测：节点501认为节点503为unreachable，并告知节点502；节点503认为节点501为unreachable，并告知节点502；节点502认为节点503为unreachable，并告知节点501；节点503认为节点502为unreachable，并告知节点501。
依据Akka现有故障处理机制，每个节点均升为leader，踢出其他节点，集群分为三个独立集群，每个集群包含一个节点。leader节点在故障链路上，会出现多leader情况，多leader决策不一致，也会导致集群高概率不可用。
基于本申请实施例，在如图5所示的情况出现时，首先确定集群中如图5所示的故障检测信息(例如，基于故障检测关系的拓扑图)，然后确定排除故障链路后，形成两个子集群，一个包括节点501和节点502，另一个包括节点503。确定该两个子集群中包括节点501和节点502的子集群为工作集群，该工作集群中不包含故障链路，集群正常运行。
在又一个示例中，如图6所示，以5节点集群为例，若节点604出现故障，严重丢包。
在故障检测过程中，设节点603和节点605监控到节点604为unreachable，会检测到如下情况：
节点603认为节点604为unreachable，告知节点601、节点602和节点605；
节点605认为节点604为unreachable，告知节点601、节点602和节点603；
节点604认为节点603为unreachable，告知节点601、节点602和节点605；
节点404认为节点605为unreachable，告知节点601、节点602和节点603。
依据Akka现有故障处理机制，节点601和节点602认为节点603、节点604、节点605为unreachable，Leader节点(节点601)踢出节点603、节点604和节点605，剩余节点601和节点602，形成四个网络分区：“节点601，节点602”，“节点603”，“节点604”以及“节点605”任一网络分区节点数未过半。
基于本申请实施例，在如图6所示的情况出现时，首先确定集群中如图6所示的故障检测信息(例如，故障检测关系拓扑图)，然后确定排除故障链路后，形成两个子集群，一个包括节点601、节点602、节点603和节点605，另一个包括节点604。确定该两个子集群中包括节点601、节点602、节点603和节点605的子集群为工作集群，该工作集群中不包含故障链路，集群正常运行。
在再一个示例中，如图7所示，若节点704与节点703，以及节点704与节点705之间的链路出现故障。在故障检测过程中，会出现如下情况：
节点703认为节点704为unreachable，告知节点701、节点702和节点705；
节点705认为节点704为unreachable，告知节点701、节点702和节点703；
节点704认为节点703为unreachable，告知节点701和节点702，节点701和节点702将节点703为unreachable的信息传播给节点705；
节点704认为节点705为unreachable，告知节点701和节点702，节点701和节点702将节点705为unreachable的信息传播给节点703。
依据Akka故障处理机制，则节点701和节点702认为节点703、节点704、节点705为unreachable。Leader节点(节点501)踢出节点703、节点704和节点705，剩余节点701和节点702，形成四个网络分区：“节点701，节点702”，“节点703”，“节点704”以及“节点705”。任一网络分区节点数都未过半。
基于本申请实施例，在如图7所示的情况出现时，首先确定集群中如图7所示的故障检测信息(例如，故障检测关系拓扑图)，然后确定排除故障链路后，形成一个子集群，确定该子集群为工作集群，由于该子集群中依然存在故障链路，故继续确定要删除节点，其中，故障指示消息指向最多节点为节点704，进一步确定节点704为要删除的节点。删除节点704，后工作集群包括节点701、节点702、节点703和节点705，集群正常运行。
通过上述分析可知，Akka现有策略的不足。高概率误踢正常节点，导致在要求集群节点过半的业务情况下，集群高概率不可用。
基于委托方法存在不足。节点i委托其他节点去ping节点j时，必须要保证节点i与委托的b个节点是相通的，以及这b个节点与节点j在正常情况下是相通的，但实际场景不一定满足；发现故障时间长，且gossip同步数据量较大；不能解决现有的网络故障问题。
如图8所示，若节点802与节点803，以及节点804和节点805之间的链路出现故障。且，Phi(节点802)＝0.8，phi(节点803)＝0.85，phi(节点804)＝0.9，phi(节点805)＝0.82
基于本申请实施例，在如图8所示的情况出现时，首先确定集群中如图8所示的故障检测信息(例如，故障检测关系拓扑图)，然后确定排除故障链路后，形成一个子集群，确定该子集群为工作集群，由于该子集群中依然存在故障链路，故继续确定要删除节点，其中，故障指示消息指向最多节点为节点802、节点803、节点804以及节点805，由于度值都相同，所以删除最不健康的节点，即节点804，删除节点804后，集群中还存在故障，节点801确定故障指示消息指向最多节点为节点802和节点803。由于度值都相同，所以删除最不健康的节点，即节点803。删除节点704，后工作集群包括节点801、节点802和节点805，集群节点过半，集群正常运行。
图9为本申请实施例提供的一种故障处理装置结构示意图。该装置900适用于集群中。其中，本申请实施例与前述结合图2和图3所示的方法实施例对应，可相互参照理解。该装置900具体包括：
第一获取单元901用于获取集群的故障检测拓扑信息，该集群中的一个节点被集群中的至少一个其他节点进行故障检测，该故障检测拓扑信息包含集群中检测节点与被检测节点之间的故障检测关系；
第二获取单元902用于从检测节点获取故障指示消息，该故障指示消息用于指示检测节点到被检测节点不可达；
处理单元903用于根据故障检测拓扑信息，以及故障指示消息，确定集群中的子集群，其中，属于不同子集群中的节点互不可达；
处理单元903还用于根据集群的子集群，确定工作集群。
具体地，处理单元903还用于执行下述任意一种或多种方式：
确定节点数量最多的子集群为工作集群；
确定包含种子节点，且节点数量最多的子集群为工作集群；
确定包含种子节点最多的子集群为工作集群；
确定运行主业务的节点最多的子集群为工作集群；
以及，基于健康状态或者可用资源状态确定工作集群。
可选地，处理单元903还用于，根据所述故障检测拓扑信息，确定节点之间的故障检测关系拓扑图，从所述故障检测关系拓扑图中删除所述故障指示消息所对应的边，确定删除后的故障检测关系拓扑图的连通子图，根据所述连通子图确定所述子集群。
在另一种实现方式中，处理单元903还用于，根据所述故障检测拓扑信息，以及所述故障指示消息，确定所述集群中的故障节点和故障链路，从所述集群的网络拓扑图中删除所述故障节点和故障链路，确定删除后的网络拓扑图的连通子图，根据所述删除后的网络拓扑图的连通子图确定所述子集群，其中，所述网络拓扑图包含了所述集群的所有节点之间的网络连接信息。
进一步地，处理单元903还用于，确定所述工作集群中的不可达节点中故障指示消息指向最多的不可达节点为要删除的节点；
该设备还可以包括发送单元904，用于向集群中其他节点发送第一指示消息，所述第一指示消息用于指示所述要删除的节点。
另外，所述要删除的节点可以为其本身。
可选地，处理单元904还用于确定所述工作集群中的不可达节点中故障指示消息指向最多的不可达节点，且健康状态最差的一个为要删除的节点，所述健康状态基于节点对心跳报文的响应的时间所确定。
可选地，第一获取单元901还用于接收所述集群中其他节点发送的故障检测拓扑信息；或者，基于预设规则进行推算所述故障检测拓扑信息。
图10为本申请实施例提供的一种故障处理设备结构示意图。该设备1000适用于本发明实施例的集群中，其中，该集群中的节点可以部分或全部运行在同一个故障处理设备中，例如，该集群中的节点可以为虚拟机，每个故障处理设备中可以运行一个或多个虚拟机。也可以是每个故障处理设备对应一个集群中的节点。如图10所示，该设备1000可以包括收发器1001、处理器1002、存储器1003。该处理器1002、收发器1001和存储器1003可以通过总线1004连接并完成相互间的通信。收发器1001用于与其他节点进行交互，可包括接收单元和发送单元；存储器1003用来存储程序以及数据。处理器1002通过执行存储器1003中存储的程序，执行本申请方法实施例中故障处理设备的功能。
另外，在图9所描述的装置900中，第二获取单元以及发送模块的功能可由本发明实施例中的收发器来实现，确定模块的功能由本发明实施例中的处理器来实现。其中，第一获取单元用于接收所述集群中其他节点发送的故障检测拓扑信息时，该第一获取单元的功能由本发明实施例中的收发器来实现。或者，第一获取单元用于基于预设规则进行推算所述故障检测拓扑信息时，该第一获取单元的功能由本发明实施例中的收发器来实现。
需要说明的是，本申请中描述的处理器1002可以是一个处理器，也可以是多个处理元件的统称。例如，该处理器1002可以是中央处理器(Central Processing Unit，CPU)，也可以是特定集成电路(Application Specific Integrated Circuit，ASIC)，或者是被配置成实施本发明实施例的一个或多个集成电路。
存储器1003可以是一个存储装置，也可以是多个存储元件的统称，且用于存储可执行程序代码或接入网管理设备运行所需要参数、数据等。且存储器1003可以包括随机存储器(random access memory，RAM)，也可以包括非易失性存储器(non-volatile memory)，例如磁盘存储器，闪存(Flash)等。其中，处理器可存储器可集成为处理电路。
本发明实施例提供的一种集群，该集群包括至少一个前述任意一个实施例中所描述的故障处理设备。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (16)

1.一种集群中节点的故障处理方法，其特征在于，所述方法包括：
获取所述集群的故障检测拓扑信息，所述集群中的一个节点被所述集群中的至少一个其他节点执行故障检测，所述故障检测拓扑信息包含所述集群中检测节点与被检测节点之间的故障检测关系；
从所述检测节点接收故障指示消息，所述故障指示消息用于指示所述检测节点到被检测节点不可达；
根据所述故障检测拓扑信息，以及所述故障指示消息，确定所述集群中的子集群，其中，属于不同子集群中的节点互不可达；
根据所述集群的子集群，确定工作集群。
2.根据权利要求1所述的方法，其特征在于，所述根据所述集群的子集群，确定工作集群包括下述任意一种方式：
确定节点数量最多的子集群为工作集群；
确定包含种子节点，且节点数量最多的子集群为工作集群，其中，所述种子节点为预配置的节点，非种子节点通过所述种子节点加入集群；
确定包含种子节点最多的子集群为工作集群；
确定运行主业务的节点最多的子集群为工作集群；
以及，基于所述子集群中的节点的健康状态或者可用资源状态确定工作集群，其中节点的健康状态基于所述节点对检测报文的响应时间确定。
3.根据权利要求1或2所述的方法，其特征在于，所述根据所述故障检测拓扑信息，以及所述故障指示消息，确定所述集群中的子集群包括：
根据所述故障检测拓扑信息，确定节点之间的故障检测关系拓扑图，从所述故障检测关系拓扑图中删除所述故障指示消息所对应的边，确定删除后的故障检测关系拓扑图的连通子图，根据所述删除后的故障检测关系拓扑图的连通子图确定所述子集群。
4.根据权利要求1或2所述的方法，其特征在于，所述根据所述故障检测拓扑信息，以及所述故障指示消息，确定所述集群中的子集群包括：
根据所述故障检测拓扑信息，以及所述故障指示消息，确定所述集群中的故障节点和故障链路，从所述集群的网络拓扑图中删除所述故障节点和/或故障链路，确定删除后的网络拓扑图的连通子图，根据所述删除后的网络拓扑图的连通子图确定所述子集群，其中，所述网络拓扑图包含了所述集群的所有节点之间的网络连接信息。
5.根据权利要求1-4任意一项所述的方法，其特征在于，所述方法还包括，
确定所述工作集群中的不可达节点中被最多故障指示消息指向的不可达节点为要删除的节点，所述不可达节点为故障指示消息所指向的被检测节点；
向所述工作集群中其他节点发送第一指示消息，所述第一指示消息用于指示所述要删除的节点。
6.根据权利要求5所述的方法，其特征在于，所述确定所述工作集群中的不可达节点中故障指示消息指向最多的不可达节点为要删除的节点包括：
确定所述工作集群中的不可达节点中被最多故障指示消息指向的不可达节点，且健康状态最差的一个为要删除的节点。
7.根据权利要求1-6任意一项所述的方法，其特征在于，所述获取所述集群的故障检测拓扑信息具体包括：
接收所述集群中其他节点发送的故障检测关系，根据接收到的故障检测关系确定所述故障检测拓扑信息；
或者，基于预设规则推算所述故障检测拓扑信息。
8.一种故障处理设备，所述设备适用于集群中，其特征在于，包括：
第一获取单元，用于获取所述集群的故障检测拓扑信息，所述集群中的一个节点被所述集群中的至少一个其他节点执行故障检测，所述故障检测拓扑信息包含所述集群中检测节点与被检测节点之间的故障检测关系；
第二获取单元，用于从所述检测节点获取故障指示消息，所述故障指示消息用于指示所述检测节点到被检测节点不可达；
处理单元，用于根据所述故障检测拓扑信息，以及所述故障指示消息，确定所述集群中的子集群，其中，属于不同子集群中的节点互不可达；
所述处理单元还用于根据所述集群的子集群，确定工作集群。
9.根据权利要求8所述的设备，其特征在于，所述处理单元还用于执行下述任意一种方式：
确定节点数量最多的子集群为工作集群；
确定包含种子节点，且节点数量最多的子集群为工作集群，其中，所述种子节点为预配置，非种子节点通过所述种子节点加入集群；
确定包含种子节点最多的子集群为工作集群；
确定运行主业务的节点最多的子集群为工作集群；
以及，基于所述子集群中的节点的健康状态或者可用资源状态确定工作集群，其中节点的健康状态基于所述节点对检测报文的响应时间确定。
10.根据权利要求8或9所述的设备，其特征在于，所述处理单元还用于，根据所述故障检测拓扑信息，确定节点之间的故障检测关系拓扑图，从所述故障检测关系拓扑图中删除所述故障指示消息所对应的边，确定删除后的故障检测关系拓扑图的连通子图，根据所述删除后的故障检测关系拓扑图的连通子图确定所述子集群。
11.根据权利要求8或9所述的设备，其特征在于，所述处理单元还用于，根据所述故障检测拓扑信息，以及所述故障指示消息，确定所述集群中的故障节点和故障链路，从所述集群的网络拓扑图中删除所述故障节点和/或故障链路，确定删除后的网络拓扑图的连通子图，根据所述删除后的网络拓扑图的连通子图确定所述子集群，其中，所述网络拓扑图包含了所述集群的所有节点之间的网络连接信息。
12.根据权利要求8-11任意一项所述的设备，其特征在于，
所述处理单元还用于，确定所述工作集群中的不可达节点中被最多故障指示消息指向的不可达节点为要删除的节点，所述不可达节点为故障指示消息所指向的被检测节点；
还包括发送单元，用于向所述工作集群中其他节点发送第一指示消息，所述第一指示消息用于指示所述要删除的节点。
13.根据权利要求12所述的设备，其特征在于，所述处理单元还用于，确定所述工作集群中的不可达节点中被最多故障指示消息指向的不可达节点，且健康状态最差的一个为要删除的节点。
14.根据权利要求8-13任意一项所述的设备，其特征在于，所述第一获取单元还用于接收所述集群中其他节点发送的故障检测关系，根据接收到的故障检测关系确定所述故障检测拓扑信息；
或者，基于预设规则推算所述故障检测拓扑信息。
15.一种计算机可读存储介质，包括计算机可读指令，当计算机读取并执行所述计算机可读指令时，使得计算机执行如权利要求1-7任意一项所述的方法。
16.一种计算机程序产品，包括计算机可读指令，当计算机读取并执行所述计算机可读指令，使得计算机执行如权利要求1-7任意一项所述的方法。
CN201710564995.8A 2017-07-12 2017-07-12 集群中节点的故障处理方法及设备 Active CN109257195B (zh)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN201710564995.8A CN109257195B (zh) 2017-07-12 2017-07-12 集群中节点的故障处理方法及设备
CA3066853A CA3066853A1 (en) 2017-07-12 2018-04-11 Intra-cluster node troubleshooting method and device
PCT/CN2018/082663 WO2019011018A1 (zh) 2017-07-12 2018-04-11 集群中节点的故障处理方法及设备
EP18832228.3A EP3627767B1 (en) 2017-07-12 2018-04-11 Fault processing method and device for nodes in cluster
US16/732,749 US11115263B2 (en) 2017-07-12 2020-01-02 Intra-cluster node troubleshooting method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710564995.8A CN109257195B (zh) 2017-07-12 2017-07-12 集群中节点的故障处理方法及设备

Publications (2)

Publication Number Publication Date
CN109257195A true CN109257195A (zh) 2019-01-22
CN109257195B CN109257195B (zh) 2021-01-15

Family

ID=65001087

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710564995.8A Active CN109257195B (zh) 2017-07-12 2017-07-12 集群中节点的故障处理方法及设备

Country Status (5)

Country Link
US (1) US11115263B2 (zh)
EP (1) EP3627767B1 (zh)
CN (1) CN109257195B (zh)
CA (1) CA3066853A1 (zh)
WO (1) WO2019011018A1 (zh)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110247818A (zh) * 2019-05-21 2019-09-17 中国平安财产保险股份有限公司 一种数据监控方法、装置、存储介质和服务器
CN111737079A (zh) * 2020-05-20 2020-10-02 山东鲸鲨信息技术有限公司 一种集群网络的监控方法和装置
CN111786887A (zh) * 2020-06-30 2020-10-16 中国工商银行股份有限公司 由控制设备执行的数据转发方法、装置、计算设备和介质
CN112468596A (zh) * 2020-12-02 2021-03-09 苏州浪潮智能科技有限公司 一种集群仲裁方法、装置、电子设备及可读存储介质
CN113660339A (zh) * 2021-08-18 2021-11-16 北京百度网讯科技有限公司 用于去中心化集群的方法和装置
CN113794593A (zh) * 2021-09-14 2021-12-14 新华三信息安全技术有限公司 一种集群故障处理方法及装置
CN113805788A (zh) * 2020-06-12 2021-12-17 华为技术有限公司 一种分布式存储系统及其异常处理方法和相关装置
CN114285722A (zh) * 2021-12-10 2022-04-05 苏州浪潮智能科技有限公司 一种分布式存储集群节点通信告警方法、装置、设备及介质
WO2022095349A1 (zh) * 2020-11-05 2022-05-12 苏州浪潮智能科技有限公司 一种集群拓扑更新方法、系统、设备及计算机存储介质

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11410174B2 (en) * 2018-08-07 2022-08-09 International Business Machines Corporation Custom blockchain for IoT devices
CN112860496A (zh) 2019-11-27 2021-05-28 华为技术有限公司 故障修复操作推荐方法、装置及存储介质
CN111698132B (zh) * 2020-06-12 2022-03-01 北京字节跳动网络技术有限公司 用于控制集群中心跳事件的方法、装置、设备和介质
CN112367191B (zh) * 2020-10-22 2023-04-07 深圳供电局有限公司 一种5g网络切片下服务故障定位方法
CN112445809A (zh) * 2020-11-25 2021-03-05 浪潮云信息技术股份公司 一种分布式数据库节点存活状态检测模块及方法
US11995562B2 (en) * 2020-12-03 2024-05-28 International Business Machines Corporation Integrating documentation knowledge with log mining for system diagnosis
CN112910981B (zh) * 2021-01-27 2022-07-26 联想(北京)有限公司 一种控制方法及装置
US11516033B1 (en) * 2021-05-31 2022-11-29 Nutanix, Inc. System and method for metering consumption
US20230030168A1 (en) * 2021-07-27 2023-02-02 Dell Products L.P. Protection of i/o paths against network partitioning and component failures in nvme-of environments
US20230032812A1 (en) * 2021-08-02 2023-02-02 International Business Machines Corporation Auto-split and auto-merge clusters
CN116545766B (zh) * 2023-06-27 2023-12-15 积至网络(北京)有限公司 基于链式安全的验证方法、系统及设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102594596A (zh) * 2012-02-15 2012-07-18 华为技术有限公司 识别集群网络中可用分区的方法、装置及集群网络系统
US20140189443A1 (en) * 2012-12-31 2014-07-03 Advanced Micro Devices, Inc. Hop-by-hop error detection in a server system
CN104378232A (zh) * 2014-11-10 2015-02-25 东软集团股份有限公司 主备集群组网模式下的脑裂发现、恢复方法及装置
CN105450717A (zh) * 2014-09-29 2016-03-30 中兴通讯股份有限公司 集群脑裂处理方法和装置
CN106254103A (zh) * 2016-07-28 2016-12-21 北京中电普华信息技术有限公司 一种rtmp集群系统可动态配置方法及装置

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6438705B1 (en) * 1999-01-29 2002-08-20 International Business Machines Corporation Method and apparatus for building and managing multi-clustered computer systems
US7327683B2 (en) * 2000-03-16 2008-02-05 Sri International Method and apparatus for disseminating topology information and for discovering new neighboring nodes
US8195976B2 (en) * 2005-06-29 2012-06-05 International Business Machines Corporation Fault-tolerance and fault-containment models for zoning clustered application silos into continuous availability and high availability zones in clustered systems during recovery and maintenance
US8634289B2 (en) * 2009-12-31 2014-01-21 Alcatel Lucent Efficient protection scheme for MPLS multicast
US8762417B2 (en) * 2010-05-04 2014-06-24 International Business Machines Corporation Event impact analysis
US9098392B1 (en) * 2011-04-29 2015-08-04 Symantec Corporation Systems and methods for changing fencing modes in clusters
US9292371B1 (en) * 2013-12-11 2016-03-22 Symantec Corporation Systems and methods for preventing failures of nodes in clusters
US9450852B1 (en) * 2014-01-03 2016-09-20 Juniper Networks, Inc. Systems and methods for preventing split-brain scenarios in high-availability clusters
CN104796273B (zh) * 2014-01-20 2018-11-16 中国移动通信集团山西有限公司 一种网络故障根源诊断的方法和装置
CN106209400B (zh) * 2015-04-30 2018-12-07 华为技术有限公司 一种定位故障的方法和设备
US10320703B2 (en) * 2015-09-30 2019-06-11 Veritas Technologies Llc Preventing data corruption due to pre-existing split brain
CN106656682B (zh) 2017-02-27 2019-10-25 网宿科技股份有限公司 集群心跳检测方法、系统及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102594596A (zh) * 2012-02-15 2012-07-18 华为技术有限公司 识别集群网络中可用分区的方法、装置及集群网络系统
US20140189443A1 (en) * 2012-12-31 2014-07-03 Advanced Micro Devices, Inc. Hop-by-hop error detection in a server system
CN105450717A (zh) * 2014-09-29 2016-03-30 中兴通讯股份有限公司 集群脑裂处理方法和装置
CN104378232A (zh) * 2014-11-10 2015-02-25 东软集团股份有限公司 主备集群组网模式下的脑裂发现、恢复方法及装置
CN106254103A (zh) * 2016-07-28 2016-12-21 北京中电普华信息技术有限公司 一种rtmp集群系统可动态配置方法及装置

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110247818A (zh) * 2019-05-21 2019-09-17 中国平安财产保险股份有限公司 一种数据监控方法、装置、存储介质和服务器
CN111737079A (zh) * 2020-05-20 2020-10-02 山东鲸鲨信息技术有限公司 一种集群网络的监控方法和装置
CN111737079B (zh) * 2020-05-20 2024-04-09 山东鲸鲨信息技术有限公司 一种集群网络的监控方法和装置
CN113805788B (zh) * 2020-06-12 2024-04-09 华为技术有限公司 一种分布式存储系统及其异常处理方法和相关装置
CN113805788A (zh) * 2020-06-12 2021-12-17 华为技术有限公司 一种分布式存储系统及其异常处理方法和相关装置
CN111786887A (zh) * 2020-06-30 2020-10-16 中国工商银行股份有限公司 由控制设备执行的数据转发方法、装置、计算设备和介质
WO2022095349A1 (zh) * 2020-11-05 2022-05-12 苏州浪潮智能科技有限公司 一种集群拓扑更新方法、系统、设备及计算机存储介质
US11902095B2 (en) 2020-12-02 2024-02-13 Inspur Suzhou Intelligent Technology Co., Ltd. Cluster quorum method and apparatus, electronic device, and readable storage medium
CN112468596A (zh) * 2020-12-02 2021-03-09 苏州浪潮智能科技有限公司 一种集群仲裁方法、装置、电子设备及可读存储介质
CN112468596B (zh) * 2020-12-02 2022-07-05 苏州浪潮智能科技有限公司 一种集群仲裁方法、装置、电子设备及可读存储介质
CN113660339A (zh) * 2021-08-18 2021-11-16 北京百度网讯科技有限公司 用于去中心化集群的方法和装置
CN113660339B (zh) * 2021-08-18 2023-08-04 北京百度网讯科技有限公司 用于去中心化集群的方法和装置
CN113794593B (zh) * 2021-09-14 2023-05-26 新华三信息安全技术有限公司 一种集群故障处理方法及装置
CN113794593A (zh) * 2021-09-14 2021-12-14 新华三信息安全技术有限公司 一种集群故障处理方法及装置
CN114285722B (zh) * 2021-12-10 2023-08-25 苏州浪潮智能科技有限公司 一种分布式存储集群节点通信告警方法、装置、设备及介质
CN114285722A (zh) * 2021-12-10 2022-04-05 苏州浪潮智能科技有限公司 一种分布式存储集群节点通信告警方法、装置、设备及介质

Also Published As

Publication number Publication date
CA3066853A1 (en) 2019-01-17
EP3627767B1 (en) 2022-02-23
WO2019011018A1 (zh) 2019-01-17
US20200145283A1 (en) 2020-05-07
EP3627767A4 (en) 2020-05-13
US11115263B2 (en) 2021-09-07
EP3627767A1 (en) 2020-03-25
CN109257195B (zh) 2021-01-15

Similar Documents

Publication Publication Date Title
CN109257195A (zh) 集群中节点的故障处理方法及设备
CN105187249B (zh) 一种故障恢复方法及装置
CN111817911B (zh) 一种探测网络质量的方法、装置、计算设备及存储介质
US9672085B2 (en) Adaptive fault diagnosis
CN102158360B (zh) 一种基于时间因子因果关系定位的网络故障自诊断方法
CN107171819A (zh) 一种网络故障诊断方法及装置
CN113973042B (zh) 用于网络问题的根本原因分析的方法和系统
CN113259168B (zh) 一种故障根因分析方法及装置
CN102594596B (zh) 识别集群网络中可用分区的方法、装置及集群网络系统
CN106789306A (zh) 通信设备软件故障检测收集恢复方法和系统
EP3232620B1 (en) Data center based fault analysis method and device
CN110071843B (zh) 一种基于流路径分析的故障定位方法及装置
CN109964450B (zh) 一种确定共享风险链路组的方法及装置
CN107656847A (zh) 基于分布式集群的节点管理方法、系统、装置及存储介质
Oi et al. Method for estimating locations of service problem causes in service function chaining
CN112068935A (zh) kubernetes程序部署监控方法、装置以及设备
CN115150253B (zh) 一种故障根因确定方法、装置及电子设备
CN113285837B (zh) 一种基于拓扑感知的载波网络服务故障诊断方法及装置
AU2014200806B1 (en) Adaptive fault diagnosis
US20140047102A1 (en) Network monitoring
JP5458644B2 (ja) 大規模ネットワーク監視方法
Li et al. Terminator: An Efficient and Light-weight Fault Localization Framework
CN113992495B (zh) 告警信息的处理方法、装置、计算机设备和存储介质
Tang et al. Towards collaborative user-level overlay fault diagnosis
Kannan et al. Nail-it-down: nailing and fixing configuration faults in cloud environments

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