一种处理集群故障的方法及一种管理节点与流程

本发明涉及计算机技术领域，特别涉及一种处理集群故障的方法及一种管理节点。

背景技术：

集群一般由管理节点和计算节点组成，计算节点承载计算任务的主体，包括大量的cpu核数，内存及IO带宽等。在集群长期稳定计算过程中，计算节点时刻运行各种各样的任务来完成计算工作。

现有的集群中，当计算节点发生故障时，需要通过专用的设备与计算节点进行故障检测，当检测出故障时，通过人工对计算节点的故障进行处理。

通过上述描述可见，现有技术中对计算节点的故障的处理比较复杂。

技术实现要素：

本发明实施例提供了一种处理集群故障的方法及一种管理节点，能够更加简单的处理集群故障。

一方面，本发明实施例提供了一种处理集群故障的方法，包括：

S1：预先在集群的管理节点上部署用于作业调度的主服务，在所述集群的每个计算节点上部署与所述主服务相匹配的子服务；

S2：所述管理节点利用所述主服务检测当前计算节点的子服务是否发生故障，如果是，则执行步骤S3；

S3：所述管理节点重启当前计算节点的子服务；

S4：所述管理节点利用所述主服务检测当前计算节点的故障是否已修复，如果否，则执行步骤S5；

S5：所述管理节点重启当前计算节点。

进一步地，所述S3，包括：

所述管理节点登录当前计算节点，重启当前计算节点的子服务。

进一步地，所述S3，包括：所述管理节点通过系统层向当前计算节点发送重启子服务的第一重启命令，利用所述第一重启命令重启当前计算节点的子服务。

进一步地，还包括：

预先在所述管理节点和每个计算节点上部署IPMI(Intelligent Platform Management Interface，智能平台管理接口)，建立所述管理节点的IPMI与每个计算节点的IPMI的连接；

所述S5包括：

所述管理节点通过IPMI向当前计算节点的IPMI发送第二重启命令，利用所述第二重启命令重启当前计算节点。

进一步地，所述S2中的所述管理节点利用所述主服务检测当前计算节点的子服务是否发生故障，包括：

所述管理节点利用所述主服务确定当前计算节点的子服务的状态，在当前计算节点的子服务的状态为down状态或offline状态时，确定当前计算节点的子服务发生故障。

另一方面，本发明实施例提供了一种管理节点，包括：

第一主服务模块、子服务重启模块、第二主服务模块、节点重启模块；

所述第一主服务模块，用于利用部署在所述管理节点上的用于作业调度的主服务检测当前计算节点的与所述主服务相匹配的子服务是否发生故障，如果是，则触发所述子服务重启模块；

所述子服务重启模块，用于重启当前计算节点的子服务，触发所述第二主服务模块；

所述第二主服务模块，用于利用所述主服务检测当前计算节点的故障是否已修复，如果否，则触发所述节点重启模块；

所述节点重启模块，用于重启当前计算节点。

进一步地，所述子服务重启模块，用于登录当前计算节点，重启当前计算节点的子服务。

进一步地，所述子服务重启模块，用于通过系统层向当前计算节点发送重启子服务的第一重启命令，利用所述第一重启命令重启当前计算节点的子服务。

进一步地，所述节点重启模块，用于通过部署在管理节点上的智能平台管理接口IPMI向当前计算节点的IPMI发送第二重启命令，利用所述第二重启命令重启当前计算节点，其中，所述管理节点的IPMI与当前计算节点的IPMI的连接。

进一步地，所述第一主服务模块，用于利用所述主服务确定当前计算节点的子服务的状态，在当前计算节点的子服务的状态为down状态或offline状态时，确定当前计算节点的子服务发生故障。

在本发明实施例中，管理节点可以通过主服务自动的检测计算节点的子服务是否发生故障，当检测到计算节点的子服务发生故障时，通过重启计算节点的子服务来进行修复，当重启子服务后，还是无法修复该故障时，通过重启计算节点进行修复，对计算节点的故障的处理可以通过管理节点自动完成，无需人工参与，更加简单的处理集群故障。

附图说明

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

图1是本发明一实施例提供的一种处理集群故障的方法的流程图；

图2是本发明一实施例提供的另一种处理集群故障的方法的流程图；

图3是本发明一实施例提供的一种管理节点的示意图。

具体实施方式

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

如图1所示，本发明实施例提供了一种处理集群故障的方法，该方法可以包括以下步骤：

S1：预先在集群的管理节点上部署用于作业调度的主服务，在所述集群的每个计算节点上部署与所述主服务相匹配的子服务；

S2：所述管理节点利用所述主服务检测当前计算节点的子服务是否发生故障，如果是，则执行步骤S3；

S3：所述管理节点重启当前计算节点的子服务；

S4：所述管理节点利用所述主服务检测当前计算节点的故障是否已修复，如果否，则执行步骤S5；

S5：所述管理节点重启当前计算节点。

在本发明实施例中，管理节点可以通过主服务自动的检测计算节点的子服务是否发生故障，当检测到计算节点的子服务发生故障时，通过重启计算节点的子服务来进行修复，当重启子服务后，还是无法修复该故障时，通过重启计算节点进行修复，对计算节点的故障的处理可以通过管理节点自动完成，无需人工参与，更加简单的处理集群故障。

在本发明一实施例中，所述S3，包括：所述管理节点登录当前计算节点，重启当前计算节点的子服务。

在本发明一实施例中，所述S3，包括：所述管理节点通过系统层向当前计算节点发送重启子服务的第一重启命令，利用所述第一重启命令重启当前计算节点的子服务。

在管理节点和计算节点上，主服务和子服务属于二者在应用层的连接，二者还有在系统层的连接，当应用层连接故障时，可以通过系统层来进行交互。在本实施例中，管理节点通过系统层向当前计算节点的系统发送第一重启命令，使得当前计算节点重启子服务。

在系统层之下还有硬件层之间的连接，下面的IPMI就属于硬件层。

在本发明一实施例中，还包括：预先在所述管理节点和每个计算节点上部署IPMI，建立所述管理节点的IPMI与每个计算节点的IPMI的连接；

所述S5包括：所述管理节点通过IPMI向当前计算节点的IPMI发送第二重启命令，利用所述第二重启命令重启当前计算节点。

在本实施例中，管理节点和计算节点通过各自的IPMI建立了IPMI网络，通过该IPMI网络可以在硬件层进行交互。当重启当前计算节点的子服务已经无法解决该故障时，可以通过IPMI网络来重启当前计算节点进行修复。

如果重启当前计算节点也无法修复该故障，管理节点可以获取当前计算节点的系统日志，方便维护人员使用该系统日志对当前计算节点进行修复，并可以发出报警信号，通知维护人员及时维护。

在本发明一实施例中，所述S2中的所述管理节点利用所述主服务检测当前计算节点的子服务是否发生故障，包括：

所述管理节点利用所述主服务确定当前计算节点的子服务的状态，在当前计算节点的子服务的状态为down状态或offline状态时，确定当前计算节点的子服务发生故障。

在本实施例中，通过当前计算节点的子服务的状态来判断当前计算节点的子服务是否发生故障。当子服务的状态为down状态或offline状态时，当前计算节点的子服务已经无法与管理节点的主服务进行交互了，管理节点无法为当前计算节点分配任务。

当子服务的状态为offline状态时，可用“pbs-c节点名”来子服务恢复正常，也就是使子服务上线。举例来说，当前计算节点的节点名为001，当前计算节点的子服务的状态为offline状态，管理节点向当前计算节点发送“pbs-c 001”命令，使得当前计算节点的子服务上线。

本发明实施例提供的方法可以通过检测脚本来实现，具体地，管理节点打开自动计划任务，可以通过crond服务来实现，在该服务中配置管理节点按照一定频次执行检测脚本。这里的一定频次可以是一周一次或一天一次，这样不会占用管理节点过多的资源。

另外，在本发明一实施例中，可以通过以下方式来确定当前计算节点是否发生故障：管理节点利用主服务向当前计算节点的子服务发送检测信号，判断是否接收到当前计算节点的子服务对检测信号的响应信号，如果是，则确定当前计算节点的子服务没有发生故障，否则，确定当前计算节点的子服务发生故障。

在发明实施例中，集群可以是windows集群，也可以是linux集群。下面以linux集群为例，在该集群中，管理节点和每个计算节点上都部署有torque，通过torque可以是作业调度，管理节点上主服务为server服务，每个计算节点上的子服务为mom服务。

如图2所示，本发明实施例提供了一种处理集群故障的方法，该方法可以包括以下步骤：

步骤201：预先在集群的管理节点上部署server服务，在集群的每个计算节点上部署与server服务相匹配的mom服务。

具体地，在管理节点安装pbs的server端，在计算节点安装pbs的mom端，server服务通过server端实现，mom服务通过mom端实现。server服务与mom服务进行交互，采集mom服务各个节点的服务状态，比如pbsnodes能查看所有节点的状态。

步骤202：预先在管理节点和每个计算节点上部署IPMI，建立管理节点的IPMI与每个计算节点的IPMI的连接。

具体地，管理节点与每个计算节点之前通过各自的IPMI构成IPMI网络，通过IPMI网络进行交互。在管理节点和每个计算节点上配置IPMI远程控制程式，可以在管理节点上通过IPMI网络来重启计算节点。

步骤203：管理节点利用server服务确定当前计算节点的mom服务的状态是否是down状态或offline状态，如果是，则执行步骤204。

具体地，如果当前计算节点的mom服务的状态是down状态或offline状态，则说明mom服务无法与server服务进行交互，管理节点无法对当前计算节点进行作业调度，确定当前计算节点的mom服务发生故障。如果当前计算节点的mom服务的状态不是down状态且不是offline状态，确定当前计算节点的mom服务没有发生故障，结束当前流程，或者等待下一个周期执行步骤203。

步骤204：管理节点登录当前计算节点，重启当前计算节点的mom服务。

具体地，虽然在应用层上管理节点无法通过server服务与当前计算节点进行交互，但是，在系统层上，管理节点可以登录到当前计算节点，对当前计算节点进行操作，也就是重启当前计算节点的mom服务。

另外，管理节点还可以通过系统层向当前计算节点发送重启mom服务的命令，使得当前计算节点根据该命令重启mom服务。

步骤205：管理节点利用server服务确定当前计算节点的mom服务的状态是否是down状态或offline状态，如果是，则执行步骤206。

在重启当前计算节点的mom服务后，再次对当前计算节点的mom服务的状态进行检查，来确定该故障是已修复，如果当前计算节点的mom服务的状态仍然是down状态或offline状态，说明该故障已修复，否则，说明该故障没有修复，需要采取后续措施进行修复。

步骤206：管理节点通过IPMI向当前计算节点的IPMI发送第二重启命令，利用第二重启命令重启当前计算节点。

具体地，管理节点在硬件层通过IPMI网络与当前计算节点进行交互，通过硬件层直接重启当前计算节点，以对故障进行修复。

通过该步骤可以在当前计算节点因故障发生宕机时，重启当前计算节点进行修复。

在步骤206之后，还可以包括：

管理节点利用server服务确定当前计算节点的mom服务的状态是否是down状态或offline状态，如果是，则获取当前计算节点的系统日志，发出报警信号。

通过该步骤可以在无法自我修复时，向维护人员提供系统日志，帮助维护人员更加方便的进行修复。

另外，在管理节点上部署了主服务，并在每个计算节点上部署了从服务之后，可以手动验证集群的作业调度功能是否正常，抓取节点信息功能是否正常，验证均正常后，可以执行本发明实施例提供的方法，这样可以避免由于作业调度功能异常导致本发明实施例的方法失败。

本发明实施例设计简便，可以用于含有作业调度系统的linux计算集群系统在出现某个或某几个计算节点因不可控制因素导致的宕机或服务不正常时，能够通过自动执行任务进行自检测自修复，将故障分类并予以简单恢复，不能恢复时记录日志便于维护人员维护。

本发明实施例中，能实现在无人值守的情况下对集群的故障进行监管和初步恢复，对于严重故障可进行记录收集系统日志以便维护人员分析。

本发明实施例简单明了，易于操作，管理节点安装的作业调度软件是整个架设的基础，自任务判断流程是架设的核心，运行时间不建议过频，集群中存在其他角色类型的节点依旧适用。最终目的是保证集群在无人时刻监管职守时，能自行监控恢复故障上线，最大限度提高资源利用率及计算效率，保障集群的稳定运行。

如图3所示，本发明实施例提供的一种管理节点，包括：

第一主服务模块301、子服务重启模块302、第二主服务模块303、节点重启模块304；

所述第一主服务模块301，用于利用部署在所述管理节点上的用于作业调度的主服务检测当前计算节点的与所述主服务相匹配的子服务是否发生故障，如果是，则触发所述子服务重启模块302；

所述子服务重启模块302，用于重启当前计算节点的子服务，触发所述第二主服务模块303；

所述第二主服务模块303，用于利用所述主服务检测当前计算节点的故障是否已修复，如果否，则触发所述节点重启模块304；

所述节点重启模块304，用于重启当前计算节点。

在本发明一实施例中，所述子服务重启模块，用于登录当前计算节点，重启当前计算节点的子服务。

在本发明一实施例中，所述子服务重启模块，用于通过系统层向当前计算节点发送重启子服务的第一重启命令，利用所述第一重启命令重启当前计算节点的子服务。

在本发明一实施例中，还包括：

所述节点重启模块，用于通过部署在管理节点上的IPMI向当前计算节点的IPMI发送第二重启命令，利用所述第二重启命令重启当前计算节点，其中，所述管理节点的IPMI与当前计算节点的IPMI的连接。

在本发明一实施例中，所述第一主服务模块，用于利用所述主服务确定当前计算节点的子服务的状态，在当前计算节点的子服务的状态为down状态或offline状态时，确定当前计算节点的子服务发生故障。

上述装置内的各单元之间的信息交互、执行过程等内容，由于与本发明方法实施例基于同一构思，具体内容可参见本发明方法实施例中的叙述，此处不再赘述。

本发明各个实施例至少具有如下有益效果：

1、在本发明实施例中，管理节点可以通过主服务自动的检测计算节点的子服务是否发生故障，当检测到计算节点的子服务发生故障时，通过重启计算节点的子服务来进行修复，当重启子服务后，还是无法修复该故障时，通过重启计算节点进行修复，对计算节点的故障的处理可以通过管理节点自动完成，无需人工参与，更加简单的处理集群故障。

2、本发明实施例简单明了，易于操作，能够保证集群在无人时刻监管职守时，能自行监控恢复计算节点的故障，最大限度提高集群的资源利用率及计算效率，保障集群的稳定运行。

需要说明的是，在本文中，诸如第一和第二之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个······”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同因素。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储在计算机可读取的存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质中。

最后需要说明的是：以上所述仅为本发明的较佳实施例，仅用于说明本发明的技术方案，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所做的任何修改、等同替换、改进等，均包含在本发明的保护范围内。