CN106130778A - 一种处理集群故障的方法及一种管理节点 - Google Patents
一种处理集群故障的方法及一种管理节点 Download PDFInfo
- Publication number
- CN106130778A CN106130778A CN201610565589.9A CN201610565589A CN106130778A CN 106130778 A CN106130778 A CN 106130778A CN 201610565589 A CN201610565589 A CN 201610565589A CN 106130778 A CN106130778 A CN 106130778A
- Authority
- CN
- China
- Prior art keywords
- node
- services
- sub
- calculating
- current
- 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.)
- Pending
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/0654—Management of faults, events, alarms or notifications using network fault recovery
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Environmental & Geological Engineering (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明提供了一种处理集群故障的方法及一种管理节点,该方法,包括:预先在集群的管理节点上部署用于作业调度的主服务,在所述集群的每个计算节点上部署与所述主服务相匹配的子服务;所述管理节点利用所述主服务检测当前计算节点的子服务是否发生故障,如果是,则所述管理节点重启当前计算节点的子服务;所述管理节点利用所述主服务检测当前计算节点的故障是否已修复,如果否,则所述管理节点重启当前计算节点。本发明提供了一种处理集群故障的方法及一种管理节点,能够更加简单的处理集群故障。
Description
技术领域
本发明涉及计算机技术领域,特别涉及一种处理集群故障的方法及一种管理节点。
背景技术
集群一般由管理节点和计算节点组成,计算节点承载计算任务的主体,包括大量的cpu核数,内存及IO带宽等。在集群长期稳定计算过程中,计算节点时刻运行各种各样的任务来完成计算工作。
现有的集群中,当计算节点发生故障时,需要通过专用的设备与计算节点进行故障检测,当检测出故障时,通过人工对计算节点的故障进行处理。
通过上述描述可见,现有技术中对计算节点的故障的处理比较复杂。
发明内容
本发明实施例提供了一种处理集群故障的方法及一种管理节点,能够更加简单的处理集群故障。
一方面,本发明实施例提供了一种处理集群故障的方法,包括:
S1:预先在集群的管理节点上部署用于作业调度的主服务,在所述集群的每个计算节点上部署与所述主服务相匹配的子服务;
S2:所述管理节点利用所述主服务检测当前计算节点的子服务是否发生故障,如果是,则执行步骤S3;
S3:所述管理节点重启当前计算节点的子服务;
S4:所述管理节点利用所述主服务检测当前计算节点的故障是否已修复,如果否,则执行步骤S5;
S5:所述管理节点重启当前计算节点。
进一步地,所述S3,包括:
所述管理节点登录当前计算节点,重启当前计算节点的子服务。
进一步地,所述S3,包括:所述管理节点通过系统层向当前计算节点发送重启子服务的第一重启命令,利用所述第一重启命令重启当前计算节点的子服务。
进一步地,还包括:
预先在所述管理节点和每个计算节点上部署IPMI(Intelligent PlatformManagement 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、磁碟或者光盘等各种可以存储程序代码的介质中。
最后需要说明的是:以上所述仅为本发明的较佳实施例,仅用于说明本发明的技术方案,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所做的任何修改、等同替换、改进等,均包含在本发明的保护范围内。
Claims (10)
1.一种处理集群故障的方法,其特征在于,包括:
S1:预先在集群的管理节点上部署用于作业调度的主服务,在所述集群的每个计算节点上部署与所述主服务相匹配的子服务;
S2:所述管理节点利用所述主服务检测当前计算节点的子服务是否发生故障,如果是,则执行步骤S3;
S3:所述管理节点重启当前计算节点的子服务;
S4:所述管理节点利用所述主服务检测当前计算节点的故障是否已修复,如果否,则执行步骤S5;
S5:所述管理节点重启当前计算节点。
2.根据权利要求1所述的方法,其特征在于,
所述S3,包括:
所述管理节点登录当前计算节点,重启当前计算节点的子服务。
3.根据权利要求1所述的方法,其特征在于,
所述S3,包括:所述管理节点通过系统层向当前计算节点发送重启子服务的第一重启命令,利用所述第一重启命令重启当前计算节点的子服务。
4.根据权利要求1所述的方法,其特征在于,
还包括:
预先在所述管理节点和每个计算节点上部署智能平台管理接口IPMI,建立所述管理节点的IPMI与每个计算节点的IPMI的连接;
所述S5包括:
所述管理节点通过IPMI向当前计算节点的IPMI发送第二重启命令,利用所述第二重启命令重启当前计算节点。
5.根据权利要求1-4中任一所述的方法,其特征在于,
所述S2中的所述管理节点利用所述主服务检测当前计算节点的子服务是否发生故障,包括:
所述管理节点利用所述主服务确定当前计算节点的子服务的状态,在当前计算节点的子服务的状态为down状态或offline状态时,确定当前计算节点的子服务发生故障。
6.一种管理节点,其特征在于,包括:
第一主服务模块、子服务重启模块、第二主服务模块、节点重启模块;
所述第一主服务模块,用于利用部署在所述管理节点上的用于作业调度的主服务检测当前计算节点的与所述主服务相匹配的子服务是否发生故障,如果是,则触发所述子服务重启模块;
所述子服务重启模块,用于重启当前计算节点的子服务,触发所述第二主服务模块;
所述第二主服务模块,用于利用所述主服务检测当前计算节点的故障是否已修复,如果否,则触发所述节点重启模块;
所述节点重启模块,用于重启当前计算节点。
7.根据权利要求6所述的管理节点,其特征在于,
所述子服务重启模块,用于登录当前计算节点,重启当前计算节点的子服务。
8.根据权利要求6所述的管理节点,其特征在于,
所述子服务重启模块,用于通过系统层向当前计算节点发送重启子服务的第一重启命令,利用所述第一重启命令重启当前计算节点的子服务。
9.根据权利要求6所述的管理节点,其特征在于,
所述节点重启模块,用于通过部署在管理节点上的智能平台管理接口IPMI向当前计算节点的IPMI发送第二重启命令,利用所述第二重启命令重启当前计算节点,其中,所述管理节点的IPMI与当前计算节点的IPMI的连接。
10.根据权利要求6-9中任一所述的管理节点,其特征在于,
所述第一主服务模块,用于利用所述主服务确定当前计算节点的子服务的状态,在当前计算节点的子服务的状态为down状态或offline状态时,确定当前计算节点的子服务发生故障。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610565589.9A CN106130778A (zh) | 2016-07-18 | 2016-07-18 | 一种处理集群故障的方法及一种管理节点 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610565589.9A CN106130778A (zh) | 2016-07-18 | 2016-07-18 | 一种处理集群故障的方法及一种管理节点 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN106130778A true CN106130778A (zh) | 2016-11-16 |
Family
ID=57283398
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610565589.9A Pending CN106130778A (zh) | 2016-07-18 | 2016-07-18 | 一种处理集群故障的方法及一种管理节点 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN106130778A (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108289034A (zh) * | 2017-06-21 | 2018-07-17 | 新华三大数据技术有限公司 | 一种故障发现方法和装置 |
CN108769170A (zh) * | 2018-05-18 | 2018-11-06 | 郑州云海信息技术有限公司 | 一种集群网络故障自检系统及方法 |
CN109144789A (zh) * | 2018-09-10 | 2019-01-04 | 网宿科技股份有限公司 | 一种重启osd的方法、装置及系统 |
CN110764940A (zh) * | 2018-07-26 | 2020-02-07 | 北京国双科技有限公司 | 分布式系统服务异常的处理方法及装置 |
CN110798375A (zh) * | 2019-09-29 | 2020-02-14 | 烽火通信科技股份有限公司 | 一种增强容器集群高可用性的监控方法、系统及终端设备 |
CN113345566A (zh) * | 2021-07-07 | 2021-09-03 | 上海蓬海涞讯数据技术有限公司 | 一种医院运营管理数据采集集成装置及系统 |
CN114567518A (zh) * | 2022-02-15 | 2022-05-31 | 深圳绿米联创科技有限公司 | 设备状态的提示方法、装置、电子设备及存储介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100017655A1 (en) * | 2008-07-16 | 2010-01-21 | International Business Machines Corporation | Error Recovery During Execution Of An Application On A Parallel Computer |
CN102510343A (zh) * | 2011-11-16 | 2012-06-20 | 广东新支点技术服务有限公司 | 基于远程检测和电源管理的高可用集群系统假死解决方法 |
CN103152419A (zh) * | 2013-03-08 | 2013-06-12 | 中标软件有限公司 | 一种云计算平台的高可用集群管理方法 |
CN104461823A (zh) * | 2014-12-03 | 2015-03-25 | 浪潮集团有限公司 | 一种自动恢复集群中意外宕机节点的方法 |
-
2016
- 2016-07-18 CN CN201610565589.9A patent/CN106130778A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100017655A1 (en) * | 2008-07-16 | 2010-01-21 | International Business Machines Corporation | Error Recovery During Execution Of An Application On A Parallel Computer |
CN102510343A (zh) * | 2011-11-16 | 2012-06-20 | 广东新支点技术服务有限公司 | 基于远程检测和电源管理的高可用集群系统假死解决方法 |
CN103152419A (zh) * | 2013-03-08 | 2013-06-12 | 中标软件有限公司 | 一种云计算平台的高可用集群管理方法 |
CN104461823A (zh) * | 2014-12-03 | 2015-03-25 | 浪潮集团有限公司 | 一种自动恢复集群中意外宕机节点的方法 |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108289034A (zh) * | 2017-06-21 | 2018-07-17 | 新华三大数据技术有限公司 | 一种故障发现方法和装置 |
CN108769170A (zh) * | 2018-05-18 | 2018-11-06 | 郑州云海信息技术有限公司 | 一种集群网络故障自检系统及方法 |
CN110764940A (zh) * | 2018-07-26 | 2020-02-07 | 北京国双科技有限公司 | 分布式系统服务异常的处理方法及装置 |
CN109144789A (zh) * | 2018-09-10 | 2019-01-04 | 网宿科技股份有限公司 | 一种重启osd的方法、装置及系统 |
CN109144789B (zh) * | 2018-09-10 | 2020-12-29 | 网宿科技股份有限公司 | 一种重启osd的方法、装置及系统 |
CN110798375A (zh) * | 2019-09-29 | 2020-02-14 | 烽火通信科技股份有限公司 | 一种增强容器集群高可用性的监控方法、系统及终端设备 |
CN110798375B (zh) * | 2019-09-29 | 2021-10-01 | 烽火通信科技股份有限公司 | 一种增强容器集群高可用性的监控方法、系统及终端设备 |
CN113345566A (zh) * | 2021-07-07 | 2021-09-03 | 上海蓬海涞讯数据技术有限公司 | 一种医院运营管理数据采集集成装置及系统 |
CN114567518A (zh) * | 2022-02-15 | 2022-05-31 | 深圳绿米联创科技有限公司 | 设备状态的提示方法、装置、电子设备及存储介质 |
CN114567518B (zh) * | 2022-02-15 | 2024-03-12 | 深圳绿米联创科技有限公司 | 设备状态的提示方法、装置、电子设备及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN106130778A (zh) | 一种处理集群故障的方法及一种管理节点 | |
TWI746512B (zh) | 實體機器故障分類處理方法、裝置和虛擬機器恢復方法、系統 | |
CN103607297B (zh) | 一种计算机集群系统的故障处理方法 | |
CN103873279B (zh) | 一种服务器管理方法,及装置 | |
CN110430071A (zh) | 业务节点故障自愈方法、装置、计算机设备及存储介质 | |
CN106789306A (zh) | 通信设备软件故障检测收集恢复方法和系统 | |
CN105337765A (zh) | 一种分布式hadoop集群故障自动诊断修复系统 | |
CN102684944B (zh) | 入侵检测方法和装置 | |
WO2016188100A1 (zh) | 信息系统故障场景信息收集方法及系统 | |
CN110716842B (zh) | 集群故障检测方法和装置 | |
CN105243004A (zh) | 一种故障资源检测方法及装置 | |
CN106603696B (zh) | 一种基于超融合基础框架的高可用系统 | |
CN101771563B (zh) | 网络服务程序的监控方法 | |
CN104980524A (zh) | 一种weblogic连接池失效监测方法 | |
CN105656698A (zh) | 一种网络应用系统智能监控结构与方法 | |
CN104038373A (zh) | 信息预警与自修复系统及方法 | |
CN103595572B (zh) | 一种云计算集群中节点自修复的方法 | |
CN105553783A (zh) | 一种配置双机资源切换的自动化测试方法 | |
CN112787855A (zh) | 一种面向广域分布式服务的主备管理系统及管理方法 | |
CN112256498A (zh) | 一种故障处理的方法和装置 | |
WO2018035765A1 (zh) | 网络异常的检测方法及装置 | |
CN107291589A (zh) | 在机器人操作系统中提升系统可靠性的方法 | |
CN109450703A (zh) | 故障的处理方法及装置、存储介质 | |
KR101663504B1 (ko) | 스마트 워터 그리드 기반 통합 운영 서비스 제공 방법 및 시스템 | |
CN108366077A (zh) | 裂变式防攻击网络接入系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20161116 |