CN107329830A - 一种分布式集群系统优化的方法及装置 - Google Patents

Abstract

本发明公开了一种分布式集群系统优化的方法，包括：判断CTDB中的每一个节点是否有集群监控服务，若有，则为MON节点，若没有，则为非MON节点；将所述CTDB的主服务部署在任意非MON节点上。由此可见，本发明实施例提供的一种分布式集群系统优化的方法，通过将CTDB的主服务固定在非MON节点上，可以节省当MON节点宕机时，等待其他节点选举出CTDB主服务的时间，因此可以直接对节点进行虚拟IP漂移，避免了卡顿现象。本发明还提供了一种分布式集群系统优化的装置，同样可以实现上述技术效果。

Description

一种分布式集群系统优化的方法及装置

技术领域

本发明涉及分布式集群系统领域，更具体地说，涉及一种分布式集群系统优化的方法及装置。

背景技术

随着云计算与大数据的发展，存储的数据呈现爆炸式增长，分布式集群系统则可以对大规模数据进行良好的存储。对于分布式集群的应用，需要其具备高可用性，也就是当系统出现故障时，可以缩短故障切换的时间，使集群在非正常的状态下，也可以提供正常的存储服务，提高系统的可用性。

如果提供全局统一存储空间的节点对外提供标准服务的节点宕机了，则会导致服务终端，影响系统的使用，因此通常分布式集群系统在提供服务时，不使用实际IP地址提供服务，而是多个节点对外提供一组虚拟IP，通过虚拟IP与真实IP的映射关系提供服务。因此，在提供服务时，如果分布式集群节点宕机不能继续提供服务，虚拟IP会漂移值其他节点，继续提供服务。

但是这种方式下，会因为分布式集群系统主服务漂移时间较长，导致IP漂移出现卡顿。

因此，如何避免集群系统节点漂移卡顿现象，是本领域技术人员需要解决的问题。

发明内容

本发明的目的在于提供一种分布式集群系统优化的方法及装置，以避免集群系统节点漂移卡顿现象。

为实现上述目的，本发明实施例提供了如下技术方案：

一种分布式集群系统优化的方法，包括：

判断CTDB中的每一个节点是否有集群监控服务，若有，则为MON节点，若没有，则为非MON节点；

将所述CTDB的主服务部署在任意非MON节点上。

其中，将所述CTDB的主服务部署在任意非MON节点上之前，还包括：

判断所述MON节点的数量是否大于第一预设阈值；

若是，则继续执行所述将所述CTDB的主服务部署在任意非MON节点上的步骤；

若否，则将所述CTDB的主服务部署在任意MON节点上。

其中，还包括：

将所述CTDB的锁释放机制设置为立即释放。

其中，将所述CTDB的锁释放机制设置为立即释放之前，还包括：

判断所述MON节点的数量是否大于第二预设阈值；

若是，则继续执行所述将所述CTDB的锁释放机制设置为立即释放的步骤；

若否，则将所述CTDB的锁释放机制设置为默认状态。

其中，将所述CTDB的锁释放机制设置为立即释放之前，还包括：

检测当前CTDB中故障节点的总数是否大于第三预设阈值；

若是，则继续执行将所述CTDB的锁释放机制设置为立即释放的步骤；

若否，则将所述CTDB的锁释放机制设置为默认状态。

一种分布式集群系统优化的装置，包括：

第一判断模块，用于判断CTDB中的每一个节点是否有集群监控服务，若有，则为MON节点，若没有，则为非MON节点；

第一主服务部署模块，用于将所述CTDB的主服务部署在任意非MON节点上。

其中，还包括：

第二判断模块，用于将所述CTDB的主服务部署在任意非MON节点上之前，判断所述MON节点数是否大于第一预设阈值；

所述第一主服务部署模块，用于当所述MON节点数大于第一预设阈值时，将所述CTDB的主服务部署在任意非MON节点上；

第二主服务部署模块，用于当所述MON节点数不大于第一预设阈值时，将所述CTDB的主服务部署在任意MON节点上。

其中，还包括：

第一锁释放机制设置模块，用于将所述CTDB的锁释放机制设置为立即释放。

其中，还包括：

第三判断模块，用于将所述CTDB的锁释放机制设置为立即释放之前，判断所述MON节点的数量是否大于第二预设阈值；

所述第一锁释放机制设置模块，用于当所述MON节点数大于第二预设阈值时，将所述CTDB的锁释放机制设置为立即释放；

第二锁释放机制设置模块，用于当所述MON节点数不大于第二预设阈值时，将所述CTDB的锁释放机制设置为默认状态。

其中，还包括：

第四判断模块，用于将所述CTDB的锁释放机制设置为立即释放之前，检测当前CTDB中的故障结点数是否大于第三预设阈值；

所述第一锁释放机制设置模块，用于当前CTDB中的故障结点数大于第三预设阈值时，将所述CTDB的锁释放机制设置为立即释放；

第三锁释放机制设置模块，用于当前CTDB中的故障结点数不大于第三预设阈值时，将所述CTDB的锁释放机制设置为默认状态。

通过以上方案可知，本发明提供的一种分布式集群系统优化的方法，包括：判断CTDB中的每一个节点是否有集群监控服务，若有，则为MON节点，若没有，则为非MON节点；将所述CTDB的主服务部署在任意非MON节点上。

由此可见，本发明实施例提供的一种分布式集群系统优化的方法，通过将CTDB的主服务固定在非MON节点上，可以节省当MON节点宕机时，等待其他节点选举出CTDB主服务的时间，因此可以直接对节点进行虚拟IP漂移，避免了卡顿现象。本发明还提供了一种分布式集群系统优化的装置，同样可以实现上述技术效果。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例公开的一种分布式集群系统优化的方法；

图2为本发明实施例公开的一种CTDB架构示意图；

图3为本发明实施例公开的一种具体的分布式集群系统优化的方法；

图4为本发明实施例公开的一种具体的分布式集群系统优化的方法；

图5为本发明实施例公开的一种具体的分布式集群系统优化的方法；

图6为本发明实施例公开的一种具体的分布式集群系统优化的装置结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例公开了一种分布式集群系统优化的方法，以避免集群系统节点漂移卡顿现象。

参见图1，本发明实施例提供的一种分布式集群系统优化的方法，包括：

S101，判断CTDB中的每一个节点是否有集群监控服务，若有，则为MON节点，若没有，则为非MON节点。

具体地，参见图2，为本发明实施例应用的CTDB(数据库集群)架构示意图，其中CTDB Master为CTDB主服务的节点，CTDB nodes为普通节点，标识MON的节点为MON节点，未标识MON的节点未非MON节点，CTDB每个节点由CTDB NET(CTDB网络)连接，Cluster network为集群内部网络，四个节点对外提供四个虚拟IP，外部有客户端，通过Public Network(公共网络)与CTDB集群交互。

CTDB的服务可以控制业务漂移，也就是说，当客户端访问的集群节点出现宕机时，由CTDB的服务控制故障节点的虚拟IP漂移至其他非故障节点，从而使客户端可以访问正常的集群节点，因此客户端可以继续对集群进行正常的访问。在CTDB的节点中，设置了MON(集群监控服务)的节点为MON节点，相反，如果节点中没有MON服务，则这个节点为非MON节点。

需要说明的是，MON节点中的集群监控服务用来监控集群的整体服务，即MON节点对每个节点的每种服务进行监控，同样MON节点对CTDB的服务也进行监控，也就是需要监控虚拟IP的漂移。

S102，将所述CTDB的主服务部署在任意非MON节点上。

具体的，对CTDB服务进行部署时，将其主服务部署到非MON节点上。

需要说明的是，本发明在对CTDB服务部署时，将CTDB的主服务由部署到MON节点上，改为了部署到非MON节点上。在部署到MON节点上时，如果MON节点宕机，需要主服务先进行漂移，也就是需要等待其他节点选举出CTDB主服务，因此就会造成漂移切换的卡顿。而将CTDB主服务部署到非MON节点上时，可以不等待其他节点选举出CTDB主服务的时间，因此会避免切换卡顿。

由此可见，本发明实施例公开的一种分布式集群系统优化的方法，通过将CTDB的主服务固定在非MON节点上，可以节省当MON节点宕机时，等待其他节点选举出CTDB主服务的时间，因此可以直接对节点进行虚拟IP漂移，避免了卡顿现象。

为进一步优化卡顿，参见图3，本发明提供了一种具体的分布式集群系统优化的方法，具体地：

S201，判断CTDB中的每一个节点是否有集群监控服务，若有，则为MON节点，若没有，则为非MON节点。

S202，判断所述MON节点的数量是否大于第一预设阈值，若是，执行S203，若否，执行S204。

具体地，根据当前集群的情况设置第一预设阈值，第一预设阈值限定此集群MON节点的一个临界值，如果当前MON节点的个数大于这个临界值，那么再将CTDB主服务部署到MON节点上时，则会出现卡顿，就需要将CTDB的主服务设置到非MON上，避免卡顿。而不大于这个临界值时，则不会出现卡顿，可以不将主服务部署到非MON上，也就是可以将主服务部署到MON节点上。

例如，在一个CTDB集群中，有三个MON节点，将CTDB主服务部署至MON节点时，由于节点数很少，因此不会出现卡顿现象，就可以直接将CTDB的主服务部署到MON节点上，但如果超过三个，比如五个或五个以上的MON节点，则在切换时虚拟IP时，则会由于MON节点过多而出现卡顿，就需要将CTDB的主服务设置到非MON上。

S203，将所述CTDB的主服务部署在任意非MON节点上。

具体地，如果MON节点超过预设的阈值，那么就需要将CTDB的主服务部署在任意的非MON节点上，以避免MON节点过多会出现虚拟IP切换卡顿的情况。

S204，将所述CTDB的主服务部署在任意MON节点上。

具体地，如果MON节点数没有超过预设的阈值，那么可以将CTDB的主服务部署到MON节点上。

因此，通过本发明实施例可以对MON节点数目的判断，确定当前的集群需不需要将CTDB主服务部署至非MON节点上，因此可以在超过阈值与未超过阈值的两种情况下都确保不会出现卡顿的情况。

为进一步对集群卡顿进行优化，本发明实施例提供了一种具体的分布式集群系统优化的方法，具体地，本发明实施例基于上述两个实施例添加以下步骤：

将所述CTDB的锁释放机制设置为立即释放。

具体地，在CTDB中，如果集群节点宕机，需要虚拟IP进行漂移时，此时就需要由CTDB锁机制来控制，也就是说，当节点发生故障宕机时，默认状态是需要此节点等待一定时间再释放锁，比如等待4s，释放锁后才可以进行其他操作，然而如果多个MON节点出现宕机时，那么由于每个节点的锁均未释放，因此会出现死锁现象，导致虚拟IP的切换的过程卡死，而无法完成。因此，在本发明实施例中，将CTDB的锁释放机制修改为立即释放，也就是将CTDB的每个节点的锁机制设置为发生故障后立即释放。

需要说明的是，由于是将默认状态的释放时间进行修改，因此会在原有的操作中增加了修改这个操作，然而如果MON节点没有超过某一个阈值，或故障的节点没有超过某一个阈值时，不会出现死锁的现象，则不需要修改锁释放时间，因此可以不增加此次修改的操作，即不需要修改CTDB的锁释放机制。

由此可见，本发明实施例对CTDB锁释放机制修改为了立即释放，因此节点发生故障后没有等待的时间，当多个MON节点都发生故障时也不会出现死锁现象，也就不会导致虚拟IP切换的过程卡死。

为了减少不必要的操作，本发明实施例提供了一种具体的分布式集群系统优化的方法，具体地，参见图4，本发明实施例基于上述实施例添加以下步骤：

S301，判断所述MON节点的数量是否大于第二预设阈值，若是，执行S302，若否，执行S303。

具体地，根据当前集群的情况确定出一个第二预设阈值，如果MON节点没有超过第二预设阈值，则说明在此集群中，MON节点故障宕机时，即使释放锁机制为默认值，也不会出现死锁，因此可以不将CTDB锁释放机制修改为立即释放。

需要说明的时，第二预设阈值一般情况下与第一预设阈值相同，但是也可以不同，由当前的集群环境决定。

S302，将所述CTDB的锁释放机制设置为立即释放。

具体地，当MON节点的数量超过了第二预设阈值，则说明此时多个MON节点宕机会导致死锁，因此需要将CTDB的锁释放机制设置为立即释放，避免虚拟IP切换过程卡死。

S303，将所述CTDB的锁释放机制设置为默认状态。

具体地，当MON节点的数量没有超过第二预设阈值，则说明此时MON节点的数目较少，出现MON节点宕机时，也不会出现死锁的情况，因此可以不将CTDB锁释放机制修改为立即释放，减少不必要的操作。

为了减少不必要的操作，本发明实施例提供了一种具体的分布式集群系统优化的方法，具体地，参见图5，本发明实施例基于上述实施例添加以下步骤：

S401，检测当前CTDB中故障节点的总数是否大于第三预设阈值，若是则执行S401，若否，则执行S402。

具体地，首先设定一个针对故障节点数的第三预设阈值，如果故障的节点数没有超过这个阈值，则不会出现死锁的现象。然后检测当前CTDB中的故障节点的数量，对其进行判断，如果故障节点数超过了阈值，则说明会发生死锁，因此需要将节点的锁释放机制修改为立即释放，如果没有超过这个阈值，则说明目前在CTDB中还不会发生节点的死锁，因此可以不用将锁释放机制进行修改。

S402，将所述CTDB的锁释放机制设置为立即释放。

具体地，当前CTDB中故障节点的总数大于第三预设阈值时，则说明如果再有节点故障则会出现死锁现象，因此为了避免这种情况发生，需要将CTDB的锁释放机制修改为立即释放。

S403，将所述CTDB的锁释放机制设置为默认状态。

具体地，当前CTDB中故障节点的总数大于第三预设阈值时，则说明目前在CTDB中还不会发生节点的死锁，因此可以不用将锁释放机制进行修改。

需要说明的是，如果CTDB的锁释放机制已经设置为立即释放后，故障节点数又降低到阈值以下，则可以再将CTDB的锁释放机制恢复为默认状态。

下面对本发明实施例提供的一种分布式集群系统优化的装置进行介绍，下文描述的一种分布式集群系统优化的装置与上文描述的一种分布式集群系统优化的方法可以相互参照。

参见图6，本发明实施例提供的一种分布式集群系统优化的装置，具体包括：

第一判断模块501，用于判断CTDB中的每一个节点是否有集群监控服务，若有，则为MON节点，若没有，则为非MON节点。

具体地，CTDB(数据库集群)的服务可以控制业务漂移，也就是说，当客户端访问的集群节点出现宕机时，由CTDB的服务控制故障节点的虚拟IP漂移至其他非故障节点，从而使客户端可以访问正常的集群节点，因此客户端可以继续对集群进行正常的访问。在CTDB的节点中，设置了MON(集群监控服务)的节点为MON节点，相反，如果节点中没有MON服务，则这个节点为非MON节点。

需要说明的是，MON节点中的集群监控服务用来监控集群的整体服务，即MON节点对每个节点的每种服务进行监控，同样，MON节点对CTDB的服务也进行监控，也就是需要监控虚拟IP的漂移。

第一主服务部署模块502，用于将所述CTDB的主服务部署在任意非MON节点上。

具体的，对CTDB服务进行部署时，第一主服务部署模块502将其主服务部署到非MON节点上。

需要说明的是，本发明在对CTDB服务部署时，第一主服务部署模块502将CTDB的主服务由部署到MON节点上，改为了部署到非MON节点上。在部署到MON节点上时，如果MON节点宕机，需要主服务先进行漂移，也就是需要等待其他节点选举出CTDB主服务，因此就会造成漂移切换的卡顿。而将CTDB主服务部署到非MON节点上时，可以不等待其他节点选举出CTDB主服务的时间，因此会避免切换卡顿。

由此可见，本发明实施例公开的一种分布式集群系统优化的方法，通过第一主服务部署模块502将CTDB的主服务固定在非MON节点上，可以节省当MON节点宕机时，等待其他节点选举出CTDB主服务的时间，因此可以直接对节点进行虚拟IP漂移，避免了卡顿现象。本发明还提供了一种分布式集群系统优化的装置，同样可以实现上述技术效果。

为进一步优化卡顿，本发明提供了一种具体的分布式集群系统优化的装置，具体包括：

第一判断模块501，用于判断CTDB中的每一个节点是否有集群监控服务，若有，则为MON节点，若没有，则为非MON节点。

第二判断模块601，用于将所述CTDB的主服务部署在任意非MON节点上之前，判断所述MON节点数是否大于第一预设阈值。

具体地，根据当前集群的情况设置第一预设阈值，第一预设阈值限定此集群MON节点的一个临界值，第二判断模块601进行判断，如果当前MON节点的个数大于这个临界值，那么再将CTDB主服务部署到MON节点上时，则会出现卡顿，就需要将CTDB的主服务设置到非MON节点上，避免卡顿。而不大于这个临界值时，则不会出现卡顿，可以不将主服务部署到非MON上，也就是可以将主服务部署到MON节点上

例如，在一个CTDB集群中，有三个MON节点，将CTDB主服务部署至MON节点时，由于节点数很少，因此不会出现卡顿现象，就可以直接将CTDB的主服务部署到MON节点上，但如果超过三个，比如五个或五个以上的MON节点，则在切换时虚拟IP时，则会由于MON节点过多而出现卡顿，就需要将CTDB的主服务设置到非MON上。

所述第一主服务部署模块602，用于当所述MON节点数大于第一预设阈值时，将所述CTDB的主服务部署在任意非MON节点上。

具体地，如果MON节点超过预设的阈值，那么所述第一主服务部署模块602就需要将CTDB的主服务部署在任意的非MON节点上，以避免MON节点过多会出现虚拟IP切换卡顿的情况。

第二主服务部署模块603，用于当所述MON节点数不大于第一预设阈值时，将所述CTDB的主服务部署在任意MON节点上。

具体地，如果MON节点数没有超过预设的阈值，那么第二主服务部署模块603可以将CTDB的主服务部署到MON节点上。

因此，通过本发明实施例可以通过第二判断模块601对MON节点数目的判断，确定当前的集群需不需要将CTDB主服务部署至非MON节点上，因此可以在超过阈值与未超过阈值的两种情况下都确保不会出现卡顿的情况。

为进一步对集群卡顿进行优化，本发明实施例提供了一种具体的分布式集群系统优化的装置，具体地，本发明实施例基于上述两个实施例添加以下模块：

第一锁释放机制设置模块701，用于将所述CTDB的锁释放机制设置为立即释放。

具体地，在CTDB中，如果集群节点宕机，需要虚拟IP进行漂移时，此时就需要由CTDB锁机制来控制，也就是说，当节点发生故障宕机时，默认状态是需要此节点等待一定时间再释放锁，比如等待4s，释放锁后才可以进行其他操作，然而如果多个MON节点出现宕机时，那么由于每个节点的锁均未释放，因此会出现死锁现象，导致虚拟IP的切换的过程卡死，而无法完成。因此，在本发明实施例中，第一锁释放机制设置模块701将CTDB的锁释放机制修改为立即释放，也就是将CTDB的每个节点的锁机制设置为发生故障后立即释放。

需要说明的是，由于是将默认状态的释放时间进行修改，因此会在原有的操作中增加了修改这个操作，然而如果MON节点没有超过某一个阈值，或故障的节点没有超过某一个阈值时，不会出现死锁的现象，则不需要修改锁释放时间，因此可以不增加此次修改的操作，即不需要修改CTDB的锁释放机制。

由此可见，本发明实施例通过第一锁释放机制设置模块701对CTDB锁释放机制修改为了立即释放，因此节点发生故障后没有等待的时间，当多个MON节点都发生故障时也不会出现死锁现象，也就不会导致虚拟IP切换的过程卡死。

为了减少不必要的操作，本发明实施例提供了一种具体的分布式集群系统优化的装置，具体地，本发明实施例基于上述实施例添加以下模块：

第三判断模块801，用于将所述CTDB的锁释放机制设置为立即释放之前，判断所述MON节点的数量是否大于第二预设阈值。

具体地，根据当前集群的情况确定出一个第二预设阈值，并通过第三判断模块801进行判断，如果MON节点没有超过第二预设阈值，则说明在此集群中，MON节点故障宕机时，即使释放锁机制为默认值，也不会出现死锁，因此可以不将CTDB锁释放机制修改为立即释放。

需要说明的时，第二预设阈值一般情况下与第一预设阈值相同，但是也可以不同，由当前的集群环境决定。

所述第一锁释放机制设置模块701，用于当所述MON节点数大于第二预设阈值时，将所述CTDB的锁释放机制设置为立即释放。

具体地，当MON节点的数量超过了第二预设阈值，则说明此时多个MON节点宕机会导致死锁，因此需要通过第一锁释放机制设置模块701将CTDB的锁释放机制设置为立即释放，避免虚拟IP切换过程卡死。

第二锁释放机制设置模块802，用于当所述MON节点数不大于第二预设阈值时，将所述CTDB的锁释放机制设置为默认状态。

具体地，当MON节点的数量没有超过第二预设阈值，则说明此时MON节点的数目较少，出现MON节点宕机时，也不会出现死锁的情况，因此可以不将CTDB锁释放机制修改为立即释放，通过第二锁释放机制设置模块802将所述CTDB的锁释放机制设置为默认状态，减少不必要的操作。

为了减少不必要的操作，本发明实施例提供了一种具体的分布式集群系统优化的装置，具体地，本发明实施例基于上述实施例添加以下模块：

第四判断模块901，用于将所述CTDB的锁释放机制设置为立即释放之前，检测当前CTDB中的故障结点数是否大于第三预设阈值。

具体地，首先设定一个针对故障节点数的第三预设阈值，第四判断模块901进行判断，如果故障的节点数没有超过这个阈值，则不会出现死锁的现象。然后检测当前CTDB中的故障节点的数量，对其进行判断，如果故障节点数超过了阈值，则说明会发生死锁，因此需要将节点的锁释放机制修改为立即释放，如果没有超过这个阈值，则说明目前在CTDB中还不会发生节点的死锁，因此可以不用将锁释放机制进行修改。

所述第一锁释放机制设置模块701，用于当前CTDB中的故障结点数大于第三预设阈值时，将所述CTDB的锁释放机制设置为立即释放。

具体地，当前CTDB中故障节点的总数大于第三预设阈值时，则说明如果再有节点故障则会出现死锁现象，因此为了避免这种情况发生，需要利用所述第一锁释放机制设置模块701将CTDB的锁释放机制修改为立即释放。

第三锁释放机制设置模块902，用于当前CTDB中的故障结点数不大于第三预设阈值时，将所述CTDB的锁释放机制设置为默认状态。

具体地，当前CTDB中故障节点的总数大于第三预设阈值时，则说明目前在CTDB中还不会发生节点的死锁，因此可以不用将锁释放机制进行修改，也就是利用第三锁释放机制设置模块902将CTDB的锁释放机制设置为默认状态。

需要说明的是，如果CTDB的锁释放机制已经设置为立即释放后，故障节点数又降低到阈值以下，则可以再通过第三锁释放机制设置模块902将CTDB的锁释放机制恢复为默认状态。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种分布式集群系统优化的方法，其特征在于，包括：

判断CTDB中的每一个节点是否有集群监控服务，若有，则为MON节点，若没有，则为非MON节点；

将所述CTDB的主服务部署在任意非MON节点上。

2.根据权利要求1所述的方法，其特征在于，将所述CTDB的主服务部署在任意非MON节点上之前，还包括：

判断所述MON节点的数量是否大于第一预设阈值；

若是，则继续执行所述将所述CTDB的主服务部署在任意非MON节点上的步骤；

若否，则将所述CTDB的主服务部署在任意MON节点上。

3.根据权利要求1或2所述的方法，其特征在于，还包括：

将所述CTDB的锁释放机制设置为立即释放。

4.根据权利要求3所述的方法，其特征在于，将所述CTDB的锁释放机制设置为立即释放之前，还包括：

判断所述MON节点的数量是否大于第二预设阈值；

若是，则继续执行所述将所述CTDB的锁释放机制设置为立即释放的步骤；

若否，则将所述CTDB的锁释放机制设置为默认状态。

5.根据权利要求3所述的方法，其特征在于，将所述CTDB的锁释放机制设置为立即释放之前，还包括：

检测当前CTDB中故障节点的总数是否大于第三预设阈值；

若是，则继续执行将所述CTDB的锁释放机制设置为立即释放的步骤；

若否，则将所述CTDB的锁释放机制设置为默认状态。

6.一种分布式集群系统优化的装置，其特征在于，包括：

第一判断模块，用于判断CTDB中的每一个节点是否有集群监控服务，若有，则为MON节点，若没有，则为非MON节点；

第一主服务部署模块，用于将所述CTDB的主服务部署在任意非MON节点上。

7.根据权利要求6所述的装置，其特征在于，还包括：

第二判断模块，用于将所述CTDB的主服务部署在任意非MON节点上之前，判断所述MON节点数是否大于第一预设阈值；

所述第一主服务部署模块，用于当所述MON节点数大于第一预设阈值时，将所述CTDB的主服务部署在任意非MON节点上；

第二主服务部署模块，用于当所述MON节点数不大于第一预设阈值时，将所述CTDB的主服务部署在任意MON节点上。

8.根据权利要求6或7所述的装置，其特征在于，还包括：

第一锁释放机制设置模块，用于将所述CTDB的锁释放机制设置为立即释放。

9.根据权利要求8所述的装置，其特征在于，还包括：

第三判断模块，用于将所述CTDB的锁释放机制设置为立即释放之前，判断所述MON节点的数量是否大于第二预设阈值；

所述第一锁释放机制设置模块，用于当所述MON节点数大于第二预设阈值时，将所述CTDB的锁释放机制设置为立即释放；

第二锁释放机制设置模块，用于当所述MON节点数不大于第二预设阈值时，将所述CTDB的锁释放机制设置为默认状态。

10.根据权利要求8所述的装置，其特征在于，还包括：

第四判断模块，用于将所述CTDB的锁释放机制设置为立即释放之前，检测当前CTDB中的故障结点数是否大于第三预设阈值；

所述第一锁释放机制设置模块，用于当前CTDB中的故障结点数大于第三预设阈值时，将所述CTDB的锁释放机制设置为立即释放；

第三锁释放机制设置模块，用于当前CTDB中的故障结点数不大于第三预设阈值时，将所述CTDB的锁释放机制设置为默认状态。