CN105704187A - 一种集群脑裂的处理方法及装置 - Google Patents
一种集群脑裂的处理方法及装置 Download PDFInfo
- Publication number
- CN105704187A CN105704187A CN201410707420.3A CN201410707420A CN105704187A CN 105704187 A CN105704187 A CN 105704187A CN 201410707420 A CN201410707420 A CN 201410707420A CN 105704187 A CN105704187 A CN 105704187A
- Authority
- CN
- China
- Prior art keywords
- cluster
- sub
- subset group
- traffic handing
- handing capacity
- 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
Links
Abstract
本发明实施例公开了一种集群脑裂的处理方法及装置。本发明实施例方法包括：当集群内发生网络故障分裂为多个子集群，所述集群内各节点进行仲裁盘抢占时，判断所述多个子集群是否具备业务处理能力，确定所述子集群中具备业务处理能力的子集群；当所述具备业务处理能力的子集群为多个时，确定具备业务处理能力的目标子集群；将所述具备业务处理能力的子集群中，除目标子集群外的子集群已抢占的仲裁盘释放，让所述目标子集群发起抢占所有仲裁盘。本发明实施例避免了直接选出的子集群可能无实际业务处理能力而导致业务中断，增强了故障场景处理的准确性。
Description
技术领域
本发明涉及计算机技术领域，特别涉及一种集群脑裂的处理方法及装置。
背景技术
高可用集群技术被广泛的应用于存储技术领域。为了保证高可用集群的正常工作，需要集群内的每个节点在提供对外服务时有正常的活性，从而保证对外提供稳定的服务。
在集群提供服务的过程中，由于环境的变化，节点可能会发生这样或者那样的故障，如网络阻塞等，而造成节点从集群中断开，出现脑裂现象，导致集群分裂为多个子集群。此时处于子集群中的节点可以相互通信，而与另一个子集群中的节点无法通信。当两个子集群中的节点都仍有权限访问共享资源时，如果不采用相应的防止措施则会导致集群发生脑裂，即分裂后的子集群各自都认为自己对特定的共享资源拥有访问权限，认为其他节点已宕机，自己是“唯一健在者”，子集群可能先后对该共享资源进行相应的读写操作，从而造成数据的不一致。为了使得集群系统能正常运行，往往需要提供相应的仲裁机制来解决集群系统发生脑裂时所引发的这类问题。
现有技术中，采用选举算法来选出一个多数派子集群接管原集群的所有业务，具体为：集群中各个节点需要心跳机制来通报彼此的“健康状况”，每收到一个节点的“通报”代表一票(心跳数)。对于有n个节点的集群，正常运行时，每个节点都会有n票，发生脑裂后，每个节点只能接受所在小集群的节点通报，只能有m(m<n)票。如果m<n/2，则该节点所在集群为少数派集群，该集群中所有节点全部自动停止业务，多数派子集群接管原集群的所有业务。
但现有技术由于无法有效识别脑裂和存储节点宕机，使用选举算法处理集群脑裂，存在固有缺陷，即应该接管业务的多数派集群可能无实际业务接管能力(宕机)，这样少数派集群自动停止业务后，所有节点都停止处理业务。
发明内容
本发明实施例提供了一种集群脑裂的处理方法及装置，避免了直接选出的子集群可能无实际业务处理能力而导致业务中断，增强了故障场景处理的准确性。
本发明实施例第一方面提供了一种集群脑裂的处理方法，包括：
当集群内发生网络故障分裂为多个子集群，所述集群内各节点进行仲裁盘抢占时，判断所述多个子集群是否具备业务处理能力，确定出所述子集群中具备业务处理能力的子集群；
当所述具备业务处理能力的子集群为多个时，确定具备业务处理能力的目标子集群；
将所述具备业务处理能力的子集群中，除目标子集群外的子集群已抢占的仲裁盘释放，让所述目标子集群发起抢占所有仲裁盘。
结合本发明实施例的第一方面，在本发明实施例的第一方面的第一种实现方式中，所述判断所述多个子集群是否具备业务处理能力，确定出所述子集群中具备业务处理能力的子集群包括：
判断所述多个子集群中是否有节点抢占到仲裁盘，确定有节点抢占到仲裁盘的子集群为具备业务处理能力的子集群。
结合本发明实施例的第一方面，在本发明实施例的第一方面的第二种实现方式中，所述当所述具备业务处理能力的子集群为多个时，确定具备业务处理能力的目标子集群包括：
当所述具备业务处理能力的子集群为多个时，获取具备业务处理能力的每个子集群中的每个节点接收的心跳票数，确定接收的心跳票数最多的节点所在的子集群为最大子集群；
判断所述最大子集群是否有多个，若否，则确定所述最大子集群为目标子集群，若是，则根据预置的选择条件，确定目标子集群。
结合本发明实施例的第一方面的第二种实现方式，在本发明实施例的第一方面的第三种实现方式中，所述根据预置的选择条件，确定目标子集群包括：
判断所述多个最大子集群中是否只有一个最大子集群中包括预置的设备，若是，则确定该最大子集群为目标子集群。
结合本发明实施例的第一方面到第一方面的第三种实现方式，在本发明实施例的第一方面的第四种实现方式中，所述方法还包括：
当所述具备业务处理能力的子集群为一个时，该具备业务处理能力的子集群发起抢占所有仲裁盘。
本发明实施例的第二方面提供了一种集群脑裂的处理装置，包括：
确定单元，用于当集群内发生网络故障分裂为多个子集群，所述集群内各节点进行仲裁盘抢占时，判断所述多个子集群是否具备业务处理能力，确定出所述子集群中具备业务处理能力的子集群；
业务处理单元，用于当所述确定单元确定的具备业务处理能力的子集群为多个时，确定具备业务处理能力的目标子集群，将所述具备业务处理能力的子集群中，除目标子集群外的子集群已抢占的仲裁盘释放，让所述目标子集群发起抢占所有仲裁盘。
结合本发明实施例的第二方面，在本发明实施例的第二方面的第一种实现方式中，所述判断单元具体用于判断所述多个子集群中是否有节点抢占到仲裁盘，确定有节点抢占到仲裁盘的子集群为具备业务处理能力的子集群。
结合本发明实施例的第二方面，在本发明实施例的第二方面的第二种实现方式中，所述业务处理单元包括：
确定模块，用于当所述具备业务处理能力的子集群为多个时，获取具备业务处理能力的每个子集群中的每个节点接收的心跳票数，确定接收的心跳票数最多的节点所在的子集群为最大子集群；
判断模块，用于判断所述确定模块确定的最大子集群是否有多个，若否，则确定所述最大子集群为目标子集群，若是，则根据预置的选择条件，确定目标子集群。
结合本发明实施例的第二方面的第二种实现方式，在本发明实施例的第二方面的第三种实现方式中，所述判断模块具体用于判断所述多个最大子集群中是否只有一个最大子集群中包括预置的设备，若是，则确定该最大子集群为目标子集群。
结合本发明实施例的第二方面到第二方面的第三种实现方式，在本发明实施例的第二方面的第四种实现方式中，所述业务处理单元还用于当所述具备业务处理能力的子集群为一个时，使该具备业务处理能力的子集群发起抢占所有仲裁盘。
从以上技术方案可以看出，本发明实施例具有以下优点：
本发明实施例中先通过集群内节点仲裁盘抢占确定集群内具备业务处理能力的子集群，在具备业务处理的子集群中选举出目标子集群发起抢占所有仲裁盘，接管原集群的所有业务，避免了直接选出的子集群可能无实际业务处理能力而导致业务中断，增强了故障场景处理的准确性。
附图说明
图1是本发明实施例中集群脑裂的处理方法的一个实施例示意图；
图2是本发明实施例中集群脑裂的处理方法的另一个实施例示意图；
图3是本发明实施例中集群脑裂的处理方法的另一个实施例示意图；
图4是本发明实施例中集群脑裂的处理装置的一个实施例示意图；
图5是本发明实施例中集群脑裂的处理装置的另一个实施例示意图；
图6是本发明实施例中集群脑裂的处理装置的另一个实施例示意图。
具体实施方式
本发明实施例提供了一种集群脑裂的处理方法及装置，避免了直接选出的子集群可能无实际业务处理能力而导致业务中断，增强了故障场景处理的准确性。
为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。
本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
请参阅图1，本发明实施例中集群脑裂的处理方法的一个实施例包括：
101、当集群内发生网络故障分裂为多个子集群，所述集群内各节点进行仲裁盘抢占时，判断所述多个子集群是否具备业务处理能力，确定出所述子集群中具备业务处理能力的子集群；
高可用集群技术被广泛的应用于存储技术领域。为了保证高可用集群的正常工作，需要集群内的每个节点(存储节点)在提供对外服务时有正常的活性，从而保证对外提供稳定的服务。
仲裁盘的作用是协调集群节点间的故障转移，通过仲裁盘可以确定在给定的时间使用哪个存储节点进行业务处理，在互为备份的节点组成的业务引擎中，当其他节点停止服务后，抢占到仲裁盘的节点接管该业务引擎对应处理的业务。
在集群提供服务的过程中，由于环境的变化，节点可能会发生这样或者那样的故障，如网络阻塞等，而造成节点从集群中断开，出现脑裂现象，导致集群分裂为多个子集群。
当集群内发生网络故障分裂为多个子集群，集群内的节点首先会进行仲裁盘抢占，即集群内节点尝试各自抢占一块仲裁盘，此时，判断所述多个子集群是否具备业务处理能力，确定所述子集群中具备业务处理能力的子集群。
102、当所述具备业务处理能力的子集群为多个时，确定具备业务处理能力的目标子集群；
确定所述子集群中具备业务处理能力的子集群后，当具备业务处理能力的子集群为多个时，需要从这多个具备业务处理能力的子集群中确定一个具备业务处理能力的目标子集群，让目标子集群接管原集群的所有业务。
103、将所述具备业务处理能力的子集群中，除目标子集群外的子集群已抢占的仲裁盘释放，让所述目标子集群发起抢占所有仲裁盘。
本实施例中，在确定具备业务处理能力的目标子集群后，将具备业务处理能力的子集群中，除目标子集群外的子集群已抢占的仲裁盘释放，即将具备业务处理能力的子集群中，除目标子集群外的子集群中各节点抢占的仲裁盘释放，让所述目标子集群发起抢占所有仲裁盘，此时，目标子集群即接管原集群的所有业务。
本发明实施例中先通过集群内节点仲裁盘抢占确定集群内具备业务处理能力的子集群，在具备业务处理的子集群中选举出目标子集群发起抢占所有仲裁盘，接管原集群的所有业务，避免了直接选出的子集群可能无实际业务处理能力而导致业务中断，增强了故障场景处理的准确性。
图1所示的实施例中，当所述具备业务处理能力的子集群为多个时，确定具备业务处理能力的目标子集群有多种实现方式，下面以一具体实施例作出详细描述，请参阅图2，本发明实施例中集群脑裂的处理方法的一个实施例包括：
201、当集群内发生网络故障分裂为多个子集群，所述集群内各节点进行仲裁盘抢占时，判断所述多个子集群是否具备业务处理能力，确定出所述子集群中具备业务处理能力的子集群；
高可用集群技术被广泛的应用于存储技术领域。为了保证高可用集群的正常工作，需要集群内的每个节点(存储节点)在提供对外服务时有正常的活性，从而保证对外提供稳定的服务。
仲裁盘的作用是协调集群节点间的故障转移，通过仲裁盘可以确定在给定的时间使用哪个存储节点进行业务处理，在互为备份的节点组成的业务引擎中，当其他节点停止服务后，抢占到仲裁盘的节点接管该业务引擎对应处理的业务。
在集群提供服务的过程中，由于环境的变化，节点可能会发生这样或者那样的故障，如网络阻塞等，而造成节点从集群中断开，出现脑裂现象，导致集群分裂为多个子集群。
当集群内发生网络故障分裂为多个子集群，集群内的节点首先会进行仲裁盘抢占，即集群内节点尝试各自抢占一块仲裁盘，此时，判断所述多个子集群是否具备业务处理能力，确定出所述子集群中具备业务处理能力的子集群。
本实施例中，判断所述多个子集群是否具备业务处理能力，确定所述子集群中具备业务处理能力的子集群可以是：判断所述多个子集群中是否有节点抢占到仲裁盘，确定有节点抢占到仲裁盘的子集群为具备业务处理能力的子集群，子集群中没有节点抢占到仲裁盘，则可知该子集群中各节点已宕机，不具备业务处理能力。
202、当所述具备业务处理能力的子集群为多个时，获取具备业务处理能力的每个子集群中的每个节点接收的心跳票数，确定接收的节点心跳票数最多的节点所在的子集群为最大子集群；
集群中的各个节点，都会通过心跳机制来通报彼此的“健康状况”，即集群中的每个节点都会定期向其他节点通知自己的心跳信息，每收到一个节点的“通报”，代表一票，对于有n个节点的集群，正常运行时，每个节点接收的心跳票数都会有n票，发生脑裂后，假设分裂为n1、n2个节点的两个子集群，则每个节点只能接受所在子集群的节点通报，只能有n1或n2票。
本实施例中，在确定所述子集群中具备业务处理能力的子集群后，当具备业务处理能力的子集群为多个时，需要获取具备业务处理能力的每个子集群中的每个节点在定期内接收的心跳票数，从这多个具备业务处理能力的子集群中确定接收的心跳票数最多的节点所在的子集群为最大子集群，例如，假设n个节点的子集群分裂为n1、n2个节点的两个子集群(n1＞n2)，则一个子集群中的每个节点在定期内接收到的心跳票数为n1票，另一个子集群中的每个节点在定期内接收到的心跳票数为n2票，由于n1＞n2，此时节点在定期内接收到的心跳票数为n1票的子集群为最大子集群，在实际应用中，可能会出现集群分裂的子集群中有两个或以上具备节点数相同的子集群，且它们的节点也是最多的，这些子集群中的节点在定期内接收到的心跳票数就会相同且最多，此时，最大子集群即有多个。
203、判断所述最大子集群是否有多个；
若否，则确定所述最大子集群为目标子集群，若是，则执行步骤204；
本实施例中，在最大子集群只有一个时，则直接确定为目标子集群。
204、根据预置的选择条件，确定目标子集群；
在最大子集群有多个时，则根据预置的选择条件，确定目标子集群，具体可以是：
判断所述多个最大子集群中是否只有一个最大子集群中包括预置的设备，如某个最大子集群中有一个节点是预置的重要的业务设备，如服务中心，而另外的最大子集群中则没有重要的业务设备，若是，则确定该包括预置的重要的业务设备的最大子集群为目标子集群，还可以采取其他手段确定目标子集群，如下面所述随机确定目标子集群或根据最大子集群中重要程度参数等。
在实际应用中，还可能出现多个最大子集群中均有预置的重要业务设备时，还可以根据预先设置的设备的重要等级，判断这多个最大子集群的重要程度参数(可以对集群中设备重要等级求和)，选择重要程度参数最大或最小的最大子集群为目标子集群(重要等级可以设置为等级参数越大越重要，也可以等级参数越小越重要，当设置为等级参数越大越重要时，此时选择重要程度参数最大的最大子集群，当设置为等级参数越小越重要时，此时选择重要程度参数最小的最大子集群，此处不作限定)。例如，假设最大子集群M中包括M1、M2、M3三个节点设备、N中包括N1、N2、N3三个节点设备，根据预先设置的设备的重要等级，假设参数越大越重要，例如M1、M2、M3、N1、N2、N3的重要等级参数分别为4、3、2，4、4、3，则最大子集群M重要程度参数M’＝4+3+2＝9，最大子集群N重要程度参数N’＝4+4+3＝11，B’＞M’，此时则确定最大子集群N’为目标子集群。
可以理解的是，在最大子集群包括多个时，在某些实施例中，也可以随机确定最大子集群中的一个目标子集群，此处不作限定。
205、将具备业务处理能力的子集群中，除目标子集群外的子集群已抢占的仲裁盘释放，让所述目标子集群发起抢占所有仲裁盘。
本实施例中，在确定具备业务处理能力的目标子集群后，将具备业务处理能力的子集群中，除目标子集群外的子集群已抢占的仲裁盘释放，让所述目标子集群发起抢占所有仲裁盘，此时，目标子集群即接管原集群的所有业务。
本实施例中，当步骤201中判断所述多个子集群是否具备业务处理能力，确定所述子集群中具备业务处理能力的子集群时，当所述具备业务处理能力的子集群为一个时，该具备业务处理能力的子集群发起抢占所有仲裁盘，而不用执行步骤202至204了。
本发明实施例中先通过集群内节点仲裁盘抢占确定集群内具备业务处理能力的子集群，在具备业务处理的子集群中选举出目标子集群发起抢占所有仲裁盘，接管原集群的所有业务，避免了直接选出的子集群可能无实际业务处理能力而导致业务中断，增强了故障场景处理的准确性；
其次，详细描述当所述具备业务处理能力的子集群为多个时，根据节点接收到的心跳票数确定具备业务处理能力的目标子集群，增强故障场景处理的准确性。
为了便于更好的理解技术，下面实施例以一具体应用场景对上述实施例中描述的集群脑裂的处理方法进行详细描述，请参阅图3，本发明实施例中集群脑裂的处理方法的一个实施例包括：
301、当集群A内发生网络故障分裂为子集群A1、A2，所述集群A内各节点进行仲裁盘抢占时，判断所述子集群A1、A2是否具备业务处理能力，确定出所述子集群A1、A2中具备业务处理能力的子集群；
当集群A内发生网络故障分裂为子集群A1、A2，集群A内的节点首先会进行仲裁盘抢占，即集群A内节点尝试各自抢占一块仲裁盘，此时，判断所述子集群A1、A2是否具备业务处理能力，确定所述子集群A1、A2中具备业务处理能力的子集群，若子集群A1、A2中没有节点抢占到仲裁盘，则可知该子集群中各节点已宕机，不具备业务处理能力。
判断所述子集群A1、A2是否具备业务处理能力，确定所述子集群A1、A2中具备业务处理能力的子集群可以是：判断所述子集群A1、A2中是否有节点抢占到仲裁盘，确定有节点抢占到仲裁盘的子集群为具备业务处理能力的子集群。
302、当子集群A1、A2均具备业务处理能力时，获取子集群A1、A2中的每个节点接收的心跳票数，确定接收的节点心跳票数最多的节点所在的子集群为最大子集群；
本实施例中，假设子集群A1、A2中均有节点抢占到仲裁盘，则确定子集群A1、A2均具备业务处理能力。
集群中的各个节点，都会通过心跳机制来通报彼此的“健康状况”，即集群中的每个节点都会定期向其他节点通知自己的心跳信息，每收到一个节点的“通报”，代表一票，对于有n个节点的集群，正常运行时，每个节点接收的心跳票数都会有n票，发生脑裂后，假设分裂为n1、n2个节点的两个子集群，则每个节点只能接受所在子集群的节点通报，只能有n1或n2票。
本实施例中，假设子集群A1、A2中均包括三个节点，则子集群A1、A2中的每个子节点在定期内接收到的心跳票数均为3票，此时最大子集群即为子集群A1和A2。
303、判断所述最大子集群是否有多个；
若否，则确定所述最大子集群为目标子集群，若是，则执行步骤204；
由于本实施例中最大子集群即为子集群A1和A2，因此需要确定最大子集群中的目标子集群。
304、在所述最大子集群A1、A2中是否只有一个最大子集群中包括预置的设备时，确定该包括预置的设备的最大子集群为目标子集群。
判断所述最大子集群A1、A2中是否只有一个最大子集群中包括预置的设备；若是，则确定该包括预置的设备的最大子集群为目标子集群，若否，则可以采取其他手段确定目标子集群，如下面所述随机确定目标子集群或根据最大子集群中重要程度参数等。
判断所述最大子集群A1、A2中是否只有一个最大子集群中包括预置的设备，如某个最大子集群中有一个节点是预置的重要的业务设备，如服务中心，而另外的最大子集群中则没有重要的业务设备，若是，则确定该包括预置的重要的业务设备的最大子集群为目标子集群。
本实施例中假设子集群A1中包括服务中心节点，而子集群A2中没有，由于服务中心是预置的重要的业务设备，则确定子集群A1为目标子集群。
在实际应用中，还可能出现多个最大子集群中均有预置的重要业务设备时，还可以根据预先设置的设备的重要等级，判断这多个最大子集群的重要程度参数(可以对集群中设备重要等级求和)，选择重要程度参数最大或最小的最大子集群为目标子集群(重要等级可以设置为等级参数越大越重要，也可以等级参数越小越重要，当设置为等级参数越大越重要时，此时选择重要程度参数最大的最大子集群，当设置为等级参数越小越重要时，此时选择重要程度参数最小的最大子集群，此处不作限定)。例如，假设最大子集群M中包括M1、M2、M3三个节点设备、N中包括N1、N2、N3三个节点设备，根据预先设置的设备的重要等级，假设参数越大越重要，例如M1、M2、M3、N1、N2、N3的重要等级参数分别为4、3、2，4、4、3，则最大子集群M重要程度参数M’＝4+3+2＝9，最大子集群N重要程度参数N’＝4+4+3＝11，N’＞M’，此时则确定最大子集群N为目标子集群。
可以理解的是，在最大子集群包括多个时，在某些实施例中，也可以随机确定最大子集群中的一个目标子集群，此处不作限定。
305、将子集群A2已抢占的仲裁盘释放，让所述目标子集群A1发起抢占所有仲裁盘。
本实施例中，目标子集群为A1，具备业务处理能力的子集群中，除目标子集群A1外的子集群为A2，将子集群A2已抢占的仲裁盘释放，让所述目标子集群A1发起抢占所有仲裁盘，此时，目标子集群A1即接管原集群A的所有业务。
本实施例中，当步骤301中判断所述多个子集群是否具备业务处理能力，确定所述子集群中具备业务处理能力的子集群时，当所述具备业务处理能力的子集群为一个时，该具备业务处理能力的子集群发起抢占所有仲裁盘，而不用执行步骤302至304了，即假设判断A1、A2中只有一个子集群为具备业务处理能力的子集群时，则该具备业务处理能力的子集群直接发起抢占所有仲裁盘，而不用执行后续的步骤了。
下面介绍本发明实施例中的集群脑裂的处理装置实施例，请参阅图4，本发明实施例中的集群脑裂的处理装置一个实施例包括：
确定单元401，用于当集群内发生网络故障分裂为多个子集群，所述集群内各节点进行仲裁盘抢占时，判断所述多个子集群是否具备业务处理能力，确定出所述子集群中具备业务处理能力的子集群；
业务处理单元402，用于当所述确定单元确定的具备业务处理能力的子集群为多个时，确定具备业务处理能力的目标子集群，将所述具备业务处理能力的子集群中，除目标子集群外的子集群已抢占的仲裁盘释放，让所述目标子集群发起抢占所有仲裁盘。
本发明实施例中先通过确定单元401集群内节点仲裁盘抢占确定集群内具备业务处理能力的子集群，业务处理单元402在具备业务处理的子集群中选举出目标子集群发起抢占所有仲裁盘，接管原集群的所有业务，避免了直接选出的子集群可能无实际业务处理能力而导致业务中断，增强了故障场景处理的准确性；
下面介绍本发明实施例中的集群脑裂的处理装置实施例，请参阅图5，本发明实施例中的集群脑裂的处理装置一个实施例包括：
确定单元501，用于当集群内发生网络故障分裂为多个子集群，所述集群内各节点进行仲裁盘抢占时，判断所述多个子集群是否具备业务处理能力，确定出所述子集群中具备业务处理能力的子集群；
业务处理单元502，用于当所述确定单元确定的具备业务处理能力的子集群为多个时，确定具备业务处理能力的目标子集群，将所述具备业务处理能力的子集群中，除目标子集群外的子集群已抢占的仲裁盘释放，让所述目标子集群发起抢占所有仲裁盘。
在本发明一些实施例中，所述判断单元具体用于判断所述多个子集群中是否有节点抢占到仲裁盘，确定有节点抢占到仲裁盘的子集群为具备业务处理能力的子集群。
本实施例中，所述业务处理单元502还可以包括：
确定模块5021，用于当所述具备业务处理能力的子集群为多个时，获取具备业务处理能力的每个子集群中的每个节点接收的心跳票数，确定接收的心跳票数最多的节点所在的子集群为最大子集群；
判断模块5022，用于判断所述确定模块确定的最大子集群是否有多个，若否，则确定所述最大子集群为目标子集群，若是，则根据预置的选择条件，确定目标子集群。
在本发明一些实施例中，所述判断模块5022具体用于判断所述多个最大子集群中是否只有一个最大子集群中包括预置的设备，若是，则确定该最大子集群为目标子集群。
在本发明一些实施例中，所述业务处理单元502还用于当所述具备业务处理能力的子集群为一个时，使该具备业务处理能力的子集群发起抢占所有仲裁盘。
上面从单元化功能实体的角度对本发明实施例中的集群脑裂的处理装置进行了描述，下面从硬件处理的角度对本发明实施例中的集群脑裂的处理装置进行描述，请参阅图6，本发明实施例中的集群脑裂的处理装置600包括：
输入装置601、输出装置602、处理器603和存储器604(其中处理器603的数量可以一个或多个，图6中以一个处理器603为例)。在本发明的一些实施例中，输入装置601、输出装置602、处理器603和存储器604可通过总线或其它方式连接，其中，图6中以通过总线连接为例。
其中，通过调用存储器604存储的操作指令，处理器603用于执行如下步骤：
本发明实施例涉及的终端可以具有比图6所示出的更多或更少的部件，可以组合两个或更多个部件，或者可以具有不同的部件配置或设置，各个部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件或硬件和软件的组合实现。
所述处理器601用于执行如下操作：
当集群内发生网络故障分裂为多个子集群，所述集群内各节点进行仲裁盘抢占时，判断所述多个子集群是否具备业务处理能力，确定出所述子集群中具备业务处理能力的子集群；
当所述具备业务处理能力的子集群为多个时，确定具备业务处理能力的目标子集群；
将所述具备业务处理能力的子集群中，除目标子集群外的子集群已抢占的仲裁盘释放，让所述目标子集群发起抢占所有仲裁盘。
在本发明一些实施例中，所述处理器601还可以用于执行如下操作：
判断所述多个子集群中是否有节点抢占到仲裁盘，确定有节点抢占到仲裁盘的子集群为具备业务处理能力的子集群。
在本发明一些实施例中，所述处理器601还可以用于执行如下操作：
当所述具备业务处理能力的子集群为多个时，获取具备业务处理能力的每个子集群中的每个节点接收的心跳票数，确定接收的心跳票数最多的节点所在的子集群为最大子集群；
判断所述最大子集群是否有多个，若否，则确定所述最大子集群为目标子集群，若是，则根据预置的选择条件，确定目标子集群。
在本发明一些实施例中，所述处理器601还可以用于执行如下操作：
判断所述多个最大子集群中是否只有一个最大子集群中包括预置的设备，若是，则确定该最大子集群为目标子集群。
在本发明一些实施例中，所述处理器601还可以用于执行如下操作：
当所述具备业务处理能力的子集群为一个时，该具备业务处理能力的子集群发起抢占所有仲裁盘。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims (10)
1.一种集群脑裂的处理方法，其特征在于，包括：
当集群内发生网络故障分裂为多个子集群，所述集群内各节点进行仲裁盘抢占时，判断所述多个子集群是否具备业务处理能力，确定出所述子集群中具备业务处理能力的子集群；
当所述具备业务处理能力的子集群为多个时，确定具备业务处理能力的目标子集群；
将所述具备业务处理能力的子集群中，除目标子集群外的子集群已抢占的仲裁盘释放，让所述目标子集群发起抢占所有仲裁盘。
2.根据权利要求1所述的方法，其特征在于，所述判断所述多个子集群是否具备业务处理能力，确定出所述子集群中具备业务处理能力的子集群包括：
判断所述多个子集群中是否有节点抢占到仲裁盘，确定有节点抢占到仲裁盘的子集群为具备业务处理能力的子集群。
3.根据权利要求1所述的方法，所述当所述具备业务处理能力的子集群为多个时，确定具备业务处理能力的目标子集群包括：
当所述具备业务处理能力的子集群为多个时，获取具备业务处理能力的每个子集群中的每个节点接收的心跳票数，确定接收的心跳票数最多的节点所在的子集群为最大子集群；
判断所述最大子集群是否有多个，若否，则确定所述最大子集群为目标子集群，若是，则根据预置的选择条件，确定目标子集群。
4.根据权利要求3所述的方法，其特征在于，所述根据预置的选择条件，确定目标子集群包括：
判断所述多个最大子集群中是否只有一个最大子集群中包括预置的设备，若是，则确定该最大子集群为目标子集群。
5.根据权利要求1至4中任一所述的方法，其特征在于，所述方法还包括：
当所述具备业务处理能力的子集群为一个时，该具备业务处理能力的子集群发起抢占所有仲裁盘。
6.一种集群脑裂的处理装置，其特征在于，包括：
确定单元，用于当集群内发生网络故障分裂为多个子集群，所述集群内各节点进行仲裁盘抢占时，判断所述多个子集群是否具备业务处理能力，确定出所述子集群中具备业务处理能力的子集群；
业务处理单元，用于当所述确定单元确定的具备业务处理能力的子集群为多个时，确定具备业务处理能力的目标子集群，将所述具备业务处理能力的子集群中，除目标子集群外的子集群已抢占的仲裁盘释放，让所述目标子集群发起抢占所有仲裁盘。
7.根据权利要求6所述的装置，其特征在于，所述判断单元具体用于判断所述多个子集群中是否有节点抢占到仲裁盘，确定有节点抢占到仲裁盘的子集群为具备业务处理能力的子集群。
8.根据权利要求6所述的装置，其特征在于，所述业务处理单元包括：
确定模块，用于当所述具备业务处理能力的子集群为多个时，获取具备业务处理能力的每个子集群中的每个节点接收的心跳票数，确定接收的心跳票数最多的节点所在的子集群为最大子集群；
判断模块，用于判断所述确定模块确定的最大子集群是否有多个，若否，则确定所述最大子集群为目标子集群，若是，则根据预置的选择条件，确定目标子集群。
9.根据权利要求8所述的装置，其特征在于，所述判断模块具体用于判断所述多个最大子集群中是否只有一个最大子集群中包括预置的设备，若是，则确定该最大子集群为目标子集群。
10.根据权利要求6至9中任一所述的装置，其特征在于，所述业务处理单元还用于当所述具备业务处理能力的子集群为一个时，使该具备业务处理能力的子集群发起抢占所有仲裁盘。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410707420.3A CN105704187B (zh) | 2014-11-27 | 2014-11-27 | 一种集群脑裂的处理方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410707420.3A CN105704187B (zh) | 2014-11-27 | 2014-11-27 | 一种集群脑裂的处理方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN105704187A true CN105704187A (zh) | 2016-06-22 |
| CN105704187B CN105704187B (zh) | 2019-03-05 |
Family
ID=56230774
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201410707420.3A Active CN105704187B (zh) | 2014-11-27 | 2014-11-27 | 一种集群脑裂的处理方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN105704187B (zh) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106484327A (zh) * | 2016-09-20 | 2017-03-08 | 华为技术有限公司 | 一种数据处理方法及相关存储设备 |
| CN108134712A (zh) * | 2017-12-19 | 2018-06-08 | 海能达通信股份有限公司 | 一种分布式集群脑裂的处理方法、装置及设备 |
| CN108366086A (zh) * | 2017-12-25 | 2018-08-03 | 聚好看科技股份有限公司 | 一种控制业务处理的方法及装置 |
| WO2019119263A1 (zh) * | 2017-12-19 | 2019-06-27 | 海能达通信股份有限公司 | 一种分布式集群脑裂的处理方法、装置及设备 |
| CN112003916A (zh) * | 2020-08-14 | 2020-11-27 | 苏州浪潮智能科技有限公司 | 一种基于异构存储的集群仲裁的方法、系统、设备及介质 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102308559A (zh) * | 2011-07-26 | 2012-01-04 | 华为技术有限公司 | 一种用于集群计算机系统的投票仲裁方法及装置 |
| US8108715B1 (en) * | 2010-07-02 | 2012-01-31 | Symantec Corporation | Systems and methods for resolving split-brain scenarios in computer clusters |
| CN102394914A (zh) * | 2011-09-22 | 2012-03-28 | 浪潮(北京)电子信息产业有限公司 | 集群脑裂处理方法和装置 |
| US20120179771A1 (en) * | 2011-01-11 | 2012-07-12 | Ibm Corporation | Supporting autonomous live partition mobility during a cluster split-brained condition |
| CN102594596A (zh) * | 2012-02-15 | 2012-07-18 | 华为技术有限公司 | 识别集群网络中可用分区的方法、装置及集群网络系统 |
| US20140040671A1 (en) * | 2012-07-31 | 2014-02-06 | International Business Machines Corporation | Securing crash dump files |
-
2014
- 2014-11-27 CN CN201410707420.3A patent/CN105704187B/zh active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8108715B1 (en) * | 2010-07-02 | 2012-01-31 | Symantec Corporation | Systems and methods for resolving split-brain scenarios in computer clusters |
| US20120179771A1 (en) * | 2011-01-11 | 2012-07-12 | Ibm Corporation | Supporting autonomous live partition mobility during a cluster split-brained condition |
| CN102308559A (zh) * | 2011-07-26 | 2012-01-04 | 华为技术有限公司 | 一种用于集群计算机系统的投票仲裁方法及装置 |
| CN102394914A (zh) * | 2011-09-22 | 2012-03-28 | 浪潮(北京)电子信息产业有限公司 | 集群脑裂处理方法和装置 |
| CN102594596A (zh) * | 2012-02-15 | 2012-07-18 | 华为技术有限公司 | 识别集群网络中可用分区的方法、装置及集群网络系统 |
| US20140040671A1 (en) * | 2012-07-31 | 2014-02-06 | International Business Machines Corporation | Securing crash dump files |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106484327A (zh) * | 2016-09-20 | 2017-03-08 | 华为技术有限公司 | 一种数据处理方法及相关存储设备 |
| CN106484327B (zh) * | 2016-09-20 | 2019-07-23 | 华为技术有限公司 | 一种数据处理方法及相关存储设备 |
| US10712947B2 (en) | 2016-09-20 | 2020-07-14 | Huawei Technologies Co., Ltd. | Data processing method and related storage device |
| CN108134712A (zh) * | 2017-12-19 | 2018-06-08 | 海能达通信股份有限公司 | 一种分布式集群脑裂的处理方法、装置及设备 |
| WO2019119263A1 (zh) * | 2017-12-19 | 2019-06-27 | 海能达通信股份有限公司 | 一种分布式集群脑裂的处理方法、装置及设备 |
| CN108134712B (zh) * | 2017-12-19 | 2020-12-18 | 海能达通信股份有限公司 | 一种分布式集群脑裂的处理方法、装置及设备 |
| CN108366086A (zh) * | 2017-12-25 | 2018-08-03 | 聚好看科技股份有限公司 | 一种控制业务处理的方法及装置 |
| CN112003916A (zh) * | 2020-08-14 | 2020-11-27 | 苏州浪潮智能科技有限公司 | 一种基于异构存储的集群仲裁的方法、系统、设备及介质 |
| WO2022033119A1 (zh) * | 2020-08-14 | 2022-02-17 | 苏州浪潮智能科技有限公司 | 一种基于异构存储的集群仲裁的方法、系统、设备及介质 |
| CN112003916B (zh) * | 2020-08-14 | 2022-05-13 | 苏州浪潮智能科技有限公司 | 一种基于异构存储的集群仲裁的方法、系统、设备及介质 |
| US11762601B2 (en) | 2020-08-14 | 2023-09-19 | Inspur Suzhou Intelligent Technology Co., Ltd. | Method for arbitrating heterogeneous storage-based cluster, and system, computer device and non-transitory computer-readable medium thereof |
Also Published As
| Publication number | Publication date |
|---|---|
| CN105704187B (zh) | 2019-03-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3433759B1 (en) | Method and apparatus for expanding high-availability server cluster | |
| US10601643B2 (en) | Troubleshooting method and apparatus using key performance indicator information | |
| US20170103003A1 (en) | Physical network security device and control method therefor | |
| CN105704187A (zh) | 一种集群脑裂的处理方法及装置 | |
| US10846186B2 (en) | Central processing unit CPU hot-remove method and apparatus, and central processing unit CPU hot-add method and apparatus | |
| CN108551765A (zh) | 输入/输出隔离优化 | |
| US20170270015A1 (en) | Cluster Arbitration Method and Multi-Cluster Cooperation System | |
| US9710341B2 (en) | Fault tolerant link width maximization in a data bus | |
| US10341138B2 (en) | Spanning tree protocol enabled N-node link aggregation system | |
| CN109245926B (zh) | 智能网卡、智能网卡系统及控制方法 | |
| CN109873714B (zh) | 云计算节点配置更新方法及终端设备 | |
| US11102284B2 (en) | Service processing methods and systems based on a consortium blockchain network | |
| CN103647820A (zh) | 用于分布式集群系统的仲裁方法及仲裁装置 | |
| US9917740B2 (en) | Reducing internodal communications in a clustered system | |
| EP3200416A1 (en) | Sas system, traversal method and device thereof | |
| CN104298565A (zh) | 一种初始化端口的方法及装置 | |
| US10637748B2 (en) | Method and apparatus for establishing interface between VNFMS, and system | |
| US9535792B2 (en) | System and method for policy based management of a communication device configuration persistence | |
| WO2015101278A1 (zh) | 一种小区激活方法和装置 | |
| WO2016206433A1 (zh) | 服务器负载均衡的方法及装置 | |
| Balhara et al. | Leader election algorithms in distributed systems | |
| US10491421B2 (en) | Ring protection network module | |
| US9929934B2 (en) | Partner discovery in control clusters using shared VLAN | |
| CN108833306B (zh) | 一种vsm系统报文传输装置及方法 | |
| EP3188531A1 (en) | Cluster system self-organizing method, device, and cluster system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |