CN101377750B - 一种用于机群容错的系统和方法 - Google Patents
一种用于机群容错的系统和方法 Download PDFInfo
- Publication number
- CN101377750B CN101377750B CN2008102115663A CN200810211566A CN101377750B CN 101377750 B CN101377750 B CN 101377750B CN 2008102115663 A CN2008102115663 A CN 2008102115663A CN 200810211566 A CN200810211566 A CN 200810211566A CN 101377750 B CN101377750 B CN 101377750B
- Authority
- CN
- China
- Prior art keywords
- checkpoint
- node
- request
- fault
- server
- 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.)
- Active
Links
Images
Landscapes
- Retry When Errors Occur (AREA)
Abstract
本发明公开了一种用于机群容错的系统和方法。该系统包括：检查点服务器，其网络连接到所述多个结点，用于收集并行应用的所有进程的信息，向结点发送监控请求，并响应来自结点的检查点操作请求，并将检查点文件保存于检查点文件服务器上；在检查点切取操作完成后，执行检查点恢复操作；检查点文件服务器，其网络连接到所述多个结点，用于存储检查点文件，并在进程恢复过程中提供检查点文件访问支持；故障监测模块，位于所述结点上，用于根据所述监控请求来监测本地结点的操作系统的运行状态和所述监控请求指定进程的指定运行状态，以及所述监控请求指定的硬件部件的指定状态，并在监测到故障时向所述检查点服务器发送检查点操作请求。
Description
技术领域
本发明涉及机群容错，特别涉及一种基于进程检查点切取和恢复的用于机群容错的方法和系统。
背景技术
机群是当前高性能计算机的主流结构，它的结点和互连网络通常都采用现成的商品化部件而非定制。这种硬件平台的开放性和可扩展性使机群相对于传统的大型机(Mainframe)、大规模并行处理系统(Massively ParallelProcessors，MPPs)和对称多处理系统(Symmetric MultiProcessors，SMPs)而言具有优良的性能价格比。随着机群系统规模的不断扩展和复杂性的逐渐提高，其可靠性呈现下降趋势。机群系统的容错问题已经引起了学术界和工业界的广泛关注。探索具有较低的开销和良好的可扩展性的机群容错机制，使得百万亿次、千万亿次规模的机群系统能够具有理想的可用性是当前机群系统设计所面临的迫切任务。
基于进程检查点切取和恢复技术的卷回恢复策略是在机群等并行计算机系统中并行应用容错的主要途径。
进程检查点切取和恢复技术是指在一个时刻保存一个目标进程的运行状态，并在随后的一个时刻以此状态为起点重建该进程，使其继续运行。在该过程中，被保存的进程状态叫做该进程的检查点，保存检查点的操作常称为切取(Checkpointing)。而利用检查点重建进程，使其能够继续运行的操作称为恢复(Recovery或Restart)。对于在应用的运行过程中周期性执行的检查点操作，相邻两次操作之间的时间跨度称为检查点间隔。进程检查点的内容不但包括基本的进程属性，用户地址空间中的数据段、堆栈段、堆等存储区域的当前内容，而且还包括用于进程间通信和输入/输出(I/O)的各种操作系统资源的当前状态，例如已创建的套接字(Sockets)、共享内存、消息队列和已打开的各种类型的文件等等。
根据在机群系统中实现的不同层次，目前已有的进程检查点技术可以分为系统级检查点技术和用户级检查点技术。系统级检查点技术是通过修改操作系统代码或者加载核心扩展模块的方式，在操作系统的核心层实现进程状态的保存和恢复。用户级检查点技术是在目标进程的用户态上下文中对其状态进行保存和恢复。这两种现有技术都需要在目标进程所在的结点内运行，其不足之处在于当目标结点出现故障的时候检查点操作无法运行。这一特点使得现有的并行应用检查点技术需要在并行计算机出现任何软硬件错误之前，对所有的相关进程执行检查点操作。因此，现有的协同式并行应用检查点技术有如下缺点：一，需要定期对一个并行应用中的所有进程进行检查点操作，导致时间开销很大；二，检查点映像文件所占存储资源庞大，为了满足检查点的存储需求，会使机群系统部件数量增多，从而导致系统成本增加，但系统整体可靠性却下降。
发明内容
本发明的一个目的是为并行应用提供局部化的快速故障恢复，提供一种用于机群容错的系统。
本发明的另一个目的是提供一种用于机群容错的方法，克服现有的并行应用检查点方法通过对一个并行应用中的所有进程执行周期性的检查点操作实现容错所导致的不足。
本发明的发明内容主要是源于对机群故障的如下规律性：
第一，并行应用异常中止过程中的多米诺骨牌效应。对于一个并行程序而言，除了诸如水灾、断电等特殊的全系统故障之外，往往是其中一个进程首先异常中止，然后这一故障通过进程间通信机制逐渐扩散到更多的进程，最终导致整个并行应用的中止。
基于该规律认识，本发明能够在结点出现故障的情况下及时地对一个并行应用中受故障影响的进程单独进行检查点和恢复，从而避免整个并行应用因为极少数受结点故障影响的进程而异常中止。
第二，并行应用中一个进程的异常中止往往源于该进程所在结点的操作系统、后台服务进程错误和机群系统资源紧张等客观故障因素。由于现有的处理器(CPU)和操作系统对用户进程的各种保护机制，上述客观故障因素往往不会对无关应用程序的进程状态造成破坏，即结点故障发生时，其操作系统中的绝大部分用户进程的状态依然正确而完整。基于该规律认识，本发明可以对已出现故障的结点中的进程执行检查点操作，获取该进程的正确状态。
第三，上述客观故障的发生是一个过程。无论是硬件故障，还是软件故障，从故障被激活到造成无法忽略或者不可挽回的机群系统错误和失效，这两个时间点之间往往存在一个过程。基于该规律认识，本发明可以根据故障的类型，针对不同硬件部件的特点或者软件故障传播的可能路径确定当前故障对于指定进程的状态的影响，甚至阻止特定故障导致计算机系统的崩溃。
因此，机群中并行应用的容错问题就归结为可否实现对机群软硬件故障的探测，可否从已探测到故障的计算机(即结点)中获取所需的进程状态，如何使得单个进程的检查点切取和恢复过程不会影响其所在的并行应用中的其它进程。
为了本发明的目的，本发明提供如下技术方案：
一种用于机群容错的系统，所述机群包括网络连接的多个结点，该系统包括：
检查点服务器，其网络连接到所述多个结点，用于收集并行应用的所有进程的信息，根据进程信息，向结点发送监控请求，并响应来自结点的检查点操作请求，执行远程检查点切取操作，并将检查点文件保存于检查点文件服务器上；在检查点切取操作完成后，执行检查点恢复操作；
检查点文件服务器，其网络连接到所述多个结点，用于存储检查点文件，并在进程恢复过程中提供检查点文件访问支持；
故障监测模块，位于所述结点上，用于根据所述监控请求来监测本地结点的操作系统的运行状态和所述监控请求指定进程的指定运行状态，以及所述监控请求指定的硬件部件的指定状态，并在监测到故障时向所述检查点服务器发送检查点操作请求和向被监测的并行应用的其他进程广播通知该进程正在进行检查点操作。
进一步地，所述检查点服务器包括：
并行应用进程管理器，用于在机群结点中加载并行应用，并收集并行应用的所有进程的信息；
并行应用注册管理器，用于注册并行应用的所有进程的信息，并根据进程信息，向结点发送监控请求；
检查点切取模块，用于响应来自结点的检查点操作请求，执行远程检查点切取操作，将检查点文件保存于检查点文件服务器中，并在检查点切取操作完成后，将检查点文件的位置和对应进程在其并行应用中的逻辑序号信息发送给所述并行应用进程管理器；
所述并行应用进程管理器还用于在收到所述检查点文件的位置和对应进程的逻辑序号信息后，执行进程恢复操作。
进一步地，在检查点服务器进行远程检查点切取过程中，通过远程直接内存访问方式获取出现故障的进程的所有状态。
进一步地，所述结点还包括：
用于通信及状态监控的协处理器；
其中，所述协处理器包括通信系统检查点模块，该通信系统检查点模块用于实现通信设备的检查点切取并将通信设备的检查点文件保存到所述检查点文件服务器上，以及根据所述通信设备的检查点文件实现通信设备的断点恢复；
其中，所述故障监测模块运行在该协处理器上。
进一步地，所述协处理器上还包括：
远程检查点服务模块，用于响应来自所述检查点服务器的读取本地进程状态、本地通信设备的状态的请求，和响应来自本地结点的故障监测模块的请求向检查点服务器发出启动检查点操作的请求并向检查点服务器发送启动检查点操作的请求。
进一步地，所述结点还包括：
主机方处理器，该主机方处理器包括内核状态监控模块和进程恢复模块；
其中，当该所述内核状态监控模块监测到操作系统内核状态出现故障时，向所述故障监测模块发送结点故障恢复请求；所述故障监测模块在接收到所述结点故障恢复请求后，向所述检查点服务器发送检查点操作请求；
所述进程恢复模块用于接收并行应用进程管理器发来的待恢复进程的检查点文件的位置和逻辑序号信息，读取检查点文件，完成进程恢复过程。
一种用于机群容错的方法，其特征是，包括如下步骤：
步骤S1，在检查点服务器上注册并行应用并向故障监测模块发送结点监控请求；
步骤S2：故障监测模块在收到监控请求后开始监测故障；
步骤S3，当故障监测模块监测到故障时，向检查点服务器发送检查点操作请求，然后通过广播将故障进程正在执行检查点操作这一事件通知被监测应用中的其它进程；
步骤S4：检查点服务器接收到检查点操作请求后执行检查点切取；
步骤S5：检查点切取完成后，检查点服务器执行进程恢复。
进一步地，在步骤S2中，所述的监测故障的方法包括：
根据时钟中断计数超出预定范围，判断操作系统故障；
根据操作系统内部接口调用失败，判断操作系统故障；
根据表征硬件状态的参数超出预先设定的范围，判断硬件故障；
根据应用进程或后台服务进程遇到失败的的系统调用或不该收到的信号，判断进程故障。
进一步地，在步骤S3中，还包括：主机方处理器的内核状态监控模块监测内核状态是否出现故障，并在监测到内核状态出现故障时，向故障监测模块发送故障恢复请求，当故障监测模块收到内核状态监控模块发来的故障恢复请求时，向检查点服务器发送检查点操作请求。
进一步地，在步骤S3中，还包括当故障监测模块监测到故障时，首先冻结本地所有被监测的进程打开的通信端口。
进一步地，在步骤S4中，所述检查点切取包括如下步骤：
步骤S41，加载故障进程所在结点的操作系统符号表；
步骤S42，加载故障进程所在结点的操作系统核心类型表；
步骤S43，根据故障进程号查找故障进程的进程控制块，并复制到检查点服务器的本地缓冲区中；
步骤S44，创建检查点映像文件，并保存检查点文件内容。
进一步地，步骤S5具体包括如下步骤：
步骤S51，确定进程恢复所用的结点；
步骤S52，并行应用进程管理器向进程恢复所用的结点发送恢复进程命令；
步骤S53，进程恢复所用的结点接收恢复进程命令，执行进程恢复。
进一步地，步骤S53还包括：在进程的恢复过程中，在该进程的通信端口恢复的末尾，用于通信及状态监控的协处理器向并行应用的其它进程广播通知继续通信。
进一步地，步骤S53还包括：判断并行应用的所有故障进程是否全部恢复，如果是，则被监测的并行应用继续运行，如果否，则等待所有故障进程全部恢复。
本发明产生的有益效果是：
与现有的机群容错系统相比，本发明提供的基于故障时检查点切取和恢复(Crash-Time ChecKpoint and Restart，CTCKR)的用于机群容错的系统不再试图对机群系统中全部或者大部分结点同时出现故障的情况进行处理，也不再试图对机群系统中所有可能发生的故障都提供支持。本发明仅在探测到故障发生在一个机群结点中之后，且仅针对故障结点中的进程，执行检查点切取和恢复操作。本发明避免了现有的并行检查点系统需要定期、全局地执行检查点操作所带来的性能和存储开销，本发明的性能和存储开销与机群系统规模基本不相关，具有良好的可扩展性。
本发明是针对机群结点中的硬件故障、系统软件故障和性能故障，当故障发生时进行检查点切取操作并恢复进程，其目标场景是同一时刻发生故障的结点数量远小于整个机群系统的规模。
本发明的主要内容之一是基于远程直接内存访问(Remote Direct MemoryAccess，RDMA)通信技术的远程检查点切取和恢复。远程直接内存访问的通信过程具有无需目标结点的CPU和操作系统参与的特点，并且具有机群高速通信系统的优异性能。因此，远程检查点切取机制在目标结点的操作系统拒绝服务(Denial Of Servi ce)等故障条件下能高效地切取(Checkpo int)应用进程的检查点。
本发明实现了机群通信系统对检查点切取和恢复的支持，使得针对单个进程的检查点切取和恢复过程不会影响同一个并行应用中的其它进程的执行。
本发明在机群结点中实现故障检测，再探测到故障后触发远程检查点切取和恢复操作，从而避免定期地执行检查点操作所带来的性能和存储开销。
本发明仅在探测到故障发生在一个机群结点中之后，且仅针对故障结点中的进程，执行检查点切取和恢复操作，这就使每次需要保存检查点的数据量从O(N)(N为并行应用的规模)降低为O(e)(e为同一时刻出现故障的机群结点的数量，一般为1)。鉴于进程检查点切取和恢复操作的过程中，绝大部分的时间用于检查点文件的读写，每次故障时检查点切取和恢复过程的时间开销t可以表示为：
t≈S(P)/Bw+S(P)/Br
上式表示，本发明的故障时检查点切取和恢复过程的总时间开销约等于目标进程P的检查点文件的长度S(P)除以文件写带宽Bw和S(P)除以文件读带宽Br。对于单个检查点文件的读写性能极易优化，因此本发明的时间开销和存储开销都小于现有技术。
本发明不但可以用于并行应用的故障恢复，也可以用于机群系统正常运行状态下的系统管理，如进程迁移等操作。
附图说明
图1是本发明的用于机群容错的系统结构图；
图2是本发明具体实施方式中的检查点服务器的结构图；
图3是本发明的用于机群容错的系统在一个结点中的布置；
图4是本发明的用于机群容错的方法流程图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明的用于机群容错的系统和方法进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
如图1所示，本发明的一种用于机群容错的系统，所述机群包括网络连接的多个结点1，该系统还包括：
检查点服务器2，其网络连接到所述多个结点1上，用于收集并行应用的所有进程的信息，根据进程信息，向结点发送监控请求，并响应来自结点1的检查点操作请求，执行检查点切取操作，并将检查点文件保存于检查点文件服务器3中；在检查点切取操作完成后，该检查点服务器2执行检查点恢复操作，使进程恢复运行；
检查点文件服务器3，其网络连接到所述多个结点1上，用于存储检查点文件，并在进程恢复过程中提供检查点文件访问支持；
故障监测模块11，位于所述结点1上，用于根据所述监控请求来监测本地结点1的操作系统的运行状态和所述监控请求指定进程的指定运行状态，以及所述监控请求指定的硬件部件的指定状态，并在监测到故障时向所述检查点服务器2发送检查点操作请求和向被监测的并行应用的其他进程广播通知该进程正在进行检查点操作。
较佳地，如图2所示，所述检查点服务器2包括：
并行应用进程管理器21，用于在机群结点中加载并行应用，并收集并行应用的所有进程的信息。
并行应用注册管理器22，用于注册并行应用的所有进程的信息，并根据进程信息，向结点发送监控请求。
检查点切取模块23，用于响应来自结点的检查点操作请求，执行远程检查点切取操作，将检查点文件保存于检查点文件服务器3中，并在检查点切取操作完成后，将检查点文件的位置和对应进程在其并行应用中的逻辑序号信息发送给所述并行应用进程管理器21。
所述并行应用进程管理器21还用于在收到所述检查点文件的位置和对应进程的逻辑序号信息后，执行进程恢复过程。
在远程检查点切取过程中，目标进程(即出现故障的进程)的所有状态都是通过远程直接内存访问方式而获取。
远程直接内存访问是本领域技术人员已知的技术，它是一种通过共享内存、通信协处理器、DMA控制器或者其它硬件电路实现的对远程计算机中的存储器件进行读、写的计算机通信方式。该技术一般需要事先获知被访问的存储单元的物理地址。
作为一种实施方式，当上述并行应用是MPI(Message Passing Interface，并行应用编程事实上的接口标准)应用时，所述并行应用进程管理器21可以实现于MPI进程管理器(如MPIRUN)的功能扩展之中。
较佳地，图3示出了本发明的用于机群容错的系统在机群结点上的布置，所述结点1包括用于通信及状态监控的协处理器10；所述协处理器10上包括通信系统检查点模块12，用于实现通信设备的检查点切取并将通信设备的检查点文件保存到所述检查点文件服务器3上，和根据所述通信设备的检查点实现通信设备的断点恢复。所述故障监测模块11也在该协处理器10上。
该通信系统检查点模块12实现于机群通信系统的扩展之中，可以保存结点1的通信系统的接收和发送缓冲区的内容、接收和发送序号、接收和发送完成事件等通信状态。在图3中，通信及状态监控协处理器(Co-processor)10是用于执行机群通信操作的功能部件，也是通信系统检查点模块的执行者。通信及状态监控协处理器10可以位于通信网卡上或者嵌入结点计算机的主板中。
较佳地，所述协处理器上还包括远程检查点服务模块13，用于响应来自检查点服务器2的读取本地进程状态、本地通信设备的状态的请求，或者响应来自本地结点的故障监测模块11的请求向检查点服务器2发出启动检查点操作的请求并向检查点服务器发送启动检查点操作的请求。
较佳地，所述结点还包括主机方处理器100，该主机方处理器100包括内核状态监控模块101和进程恢复模块102。
当该内核状态监控模块101监测到操作系统内核状态出现故障时，向所述故障监测模块11发送结点故障恢复请求；所述故障监测模块11在接收到所述结点故障恢复请求后，向所述检查点服务器2发送检查点操作请求。这样做的目的是在主机方处理器的操作系统的内核状态出现故障时，立刻请求执行检查点操作。这样，对于故障的监测就由内核状态监控模块和故障监测模块完成。
进程恢复模块102用于接收并行应用进程管理器发来的待恢复进程的检查点文件的位置和逻辑序号信息，读取检查点文件，完成进程恢复过程。
结点中的主存储器(又称内存)一般以页面(4096字节)的方式组织，操作系统内核可以访问任何一个页面。当一个内存页面被分配给一个用户进程之后，就映射到了用户进程的地址空间中。
如图4所示，作为一种具体实施方式，此处以运行一个MPI并行应用程序为例介绍本发明的用于机群容错的方法，该方法包括如下步骤：
步骤S1，在检查点服务器上注册并行应用并向故障监测模块发送结点监控请求。
当MPI进程管理器加载一个MPI应用时，MPI进程管理器收集到所有子进程的基本信息之后，向检查点服务器发送应用注册请求。远程检查点服务器在接收该请求之后，根据其中包含的进程信息，向所有相关结点的故障监测模块发送结点监控请求。
该应用注册请求中包含被监测应用的注册号及其所有进程的基本信息、可用的远程检查点服务器地址(列表)和结点监控策略码。结点监控策略码用于配置故障监测模块对本地的系统状态做何种监测，包括监测时间间隔、监测内容等。
步骤S2：故障监测模块在收到监控请求后监测故障。
在被监测应用的运行过程中，结点的故障监测模块定期地主动监测本结点的操作系统的运行故障，和所述监控请求指定进程的指定运行状态的故障，以及所述监控请求指定的硬件部件的指定状态的故障。
作为一种具体实施方式，此处所述的监测故障的方法包括：
(1)根据时钟中断计数判断操作系统故障；当在一预定时间内，时钟中断计数没有增加，则判定为操作系统故障。
对于常见的Unix、Linux等通用操作系统而言，进程调度、系统资源监控、系统时间的维护等操作系统功能都依赖于时钟中断。时钟中断的频率一般设为每秒钟100到1000次。每个操作系统都会用一个特定的变量作为已处理的时钟中断的计数。如果时钟中断计数变量在指定的一段时间，如0.05秒，之内没有增加就可以判定为操作系统严重故障。
(2)根据操作系统内部接口调用失败，判断操作系统故障；
在Unix、Windows等操作系统的核心代码中存在很多对于操作系统的正常工作至关重要的函数接口，例如分配内存资源的各种调用接口。这些接口的调用失败进而会导致操作系统的一个核心模块或者整个系统的错误或失效。在现有的操作系统中，对于这些函数接口的调用失败的处理都较为简单，例如向更上一级返回错误代码，或者不做任何判断继续执行。而本发明中，上述调用失败的处理过程中可以触发本发明所提出的检查点操作。本发明的内核状态监控模块用于记录各种接口调用失败的信息，通知故障监测模块，以触发一次故障处理。
(3)根据表征硬件状态的参数超出预先设定的范围，判断硬件故障；
CPU温度、机箱温度、电源电压、CPU风扇转速、硬盘转速等参数可以方便地通过内建于各种硬件部件中的传感器获取。传感器的读数表征硬件的状态，当传感器读数在预先设定的范围内时，认为硬件运转正常。当传感器的读数超出预先设定的范围内时，故障监测模块判断为硬件故障。
如前面所述的，客观故障的发生是一个过程。无论是硬件故障，还是软件故障，从故障被激活到造成无法忽略或者不可挽回的机群系统错误和失效，这两个时间点之间往往存在一个过程，例如CPU温度超出了预先设定的温度，但是不会马上导致系统崩溃。因此，本发明可以根据故障的类型，针对不同硬件部件的特点或者软件故障传播的可能路径确定当前故障对于指定进程的状态的影响，甚至阻止特定故障导致计算机系统的崩溃。
(4)根据应用进程或后台服务进程遇到失败的的系统调用或不该收到的信号(Signal)，故障监测模块判断为故障进程。
当应用进程或者某个后台服务进程碰到了失败的系统调用、不该收到的信号(Signal)等故障时，故障监测模块可以触发一次故障处理。
在监测故障的过程中，每个用户进程在进入操作系统核心的时候需要将其所用的所有寄存器的状态保存在指定的内存区域中。这就使操作系统在核心中遇到故障之后，在检查点恢复时，检查点服务器可以获得各个用户进程在运行的最后一刻的完整的寄存器状态。
步骤S3，当故障监测模块监测到故障时，向检查点服务器发送检查点操作请求。
当故障监测模块监测到操作系统故障或受监控的进程故障时，向检查点服务器发送检查点操作请求，请求检查点服务器对指定的本地进程实施远程检查点切取。
较佳地，该步骤S3中，还包括当故障监测模块监测到故障时，首先冻结本地所有被监测的进程打开的通信端口。因为当结点故障进程出现之后，主机方CPU会停止进程的运行，与此同时，也应中止这些进程的通信操作。
较佳地，该步骤S3还包括：在向检查点服务器发送检查点操作请求后，通过广播向被监测应用中的其它进程通知该进程正在执行检查点操作。
更佳地，步骤S3还包括：主机方处理器的内核状态监控模块监测内核状态是否出现故障，并在监测到内核状态出现故障时，向故障监测模块发送故障恢复请求，当故障监测模块收到内核状态监控模块发来的故障恢复请求时，向检查点服务器发送检查点操作请求。也可以如同当故障监测模块监测到故障时，首先冻结本地所有被监测的进程打开的通信端口，并在向检查点服务器发送检查点操作请求后，通过广播向被监测应用中的其它进程通知该进程正在执行检查点操作。
步骤S4：检查点服务器接收到检查点操作请求后执行检查点切取。
当一个检查点服务器收到检查点操作请求之后，开始检查点切取过程，并将检查点文件保存到检查点文件服务器。在检查点切取成功结束之后，检查点服务器将所得到的检查点映像文件的位置和对应进程的逻辑序号(Rank)等信息发送给MPI进程管理器，由MPI进程管理器管理后续的进程恢复过程。
较佳地，在步骤S4中，所述检查点切取包括如下步骤：
步骤S41，加载故障进程所在结点的操作系统符号表。
操作系统符号表的内容为操作系统中各数据结构和函数接口的名称与其虚拟地址的对照表。
步骤S42，加载故障进程所在结点的操作系统核心类型表。
操作系统核心类型表是在操作系统核心编译过程中生成的，描述每种核心数据结构的长度，及其各个成员变量的偏移的文件。
在此之后，对于故障进程所在的操作系统中的任何核心数据的访问，原则上都需要先查询上述的操作系统符号表，得到该数据所属的数据结构的虚拟地址，再通过查询操作系统核心类型表，得到该数据的确切的虚拟地址，最后再转换为远程直接存储访问技术所需的物理地址。对于故障进程的用户空间的任何数据的访问，需要先查询该进程的页表，将所需数据的虚拟地址转换为远程直接内存访问技术所需的物理地址，即该数据所在的页面的物理地址及其在该页面中的偏移。在步骤S42后的各步骤中，对于故障进程的任何数据的访问，都隐含上述地址转换和远程直接内存访问过程。
较佳地，本发明可以利用数据的局部性原理通过远程直接内存访问预取后续步骤将会用到的数据，并将其缓存于检查点服务器的本地内存中，以提高后续步骤的执行速度。
步骤S43，根据故障进程号查找故障进程的进程控制块，并复制到检查点服务器的本地缓冲区中。
步骤S44，创建检查点映像文件，并保存检查点文件内容。
步骤S44中保存检查点文件内容具体包括如下步骤：
步骤S4401，保存故障进程的进程号(PID)、用户号(UID)、实际用户号(EUID)、组号(GID)、实际组号(EGID)和进程名称等基本属性。
步骤S4402，保存故障进程所在结点的CPU的状态信息，包括通用寄存器、调试寄存器和浮点协处理器的状态。
步骤S4403，保存故障进程所在结点的操作系统中的信号(Signal)处理信息。
步骤S4404，根据内存描述符(Memory Descriptor，例如在linux系统中为mm_struct结构)保存故障进程的虚拟地址空间。该虚拟地址空间包括：故障进程的代码段、数据段、堆空间、堆栈段和环境变量区的起止地址，和各个虚拟内存区域结构(Virtual Memory Areas，例如在linux系统中为vm_area_struct结构)所对应的虚拟内存区域的内容。
数据段、堆空间和堆栈段内的物理页面全部会被远程读取，所含数据并非全零的页面都将被保存到检查点映像中。
步骤S4405，保存故障进程的根目录(root)、替换根目录(altroot)和当前工作目录(pwd)的完整路径。
步骤S4406，保存故障进程的文件描述符表。
步骤S4407，逐一保存故障进程已打开文件的基本信息。所述已打开文件的基本信息包括：
(1)对于普通文件，要记录文件名、访问模式、长度、偏移等信息。
本发明的容错方法对普通文件的支持仅限于只读文件和通过内存映射方式打开的读/写文件。
(2)对于字符型设备，按照不同的主、从设备号，分别对对应设备进行检查点切取。进程所用的通信设备一般属于字符型设备，因而通信系统的检查点切取就在这一步骤中执行。
步骤S4408，为检查点映像文件加入末尾标记。
步骤S5：检查点切取完成后，检查点服务器执行进程恢复。
检查点服务器中的MPI进程管理器管理进程恢复过程。
较佳地，步骤S5具体包括如下步骤：
步骤S51，确定进程恢复所用的结点。该步骤S51有两种实现方式，包括：MPI进程管理器选择机群系统中预先配备的空闲结点作为进程恢复所用的结点；或者，预先为每个机群结点提供远程电源管理支持，MPI进程管理器可以通过向故障进程所在的结点发送重启动消息来重启动该结点，作为进程恢复所用的结点。
步骤S52，MPI进程管理器向进程恢复所用的结点发送恢复进程命令。
在该恢复进程命令中，包括检查点文件的位置，检查点文件的位置以其在检查点文件服务器中的路径的形式给出。
步骤S53，进程恢复所用的结点接收恢复进程命令，执行进程恢复。
在该步骤中，在进程恢复所用的结点上，进程恢复模块创建一个子进程(本发明中称为宿主进程)，并在其中创建与被恢复进程相同数量的线程，然后在以下步骤中，根据检查点文件的内容，以宿主进程中的各个线程为基础，重建被恢复进程。
较佳地，步骤S53中的进程恢复过程大体上是上述的检查点切取过程的逆过程，具体包括如下步骤：
步骤S5301，根据检查点文件的头部信息判断其是否合法性，如果是，则继续，如果否，则退出。
步骤S5302，创建宿主进程，并在其中创建与被恢复进程相同数量的线程。
步骤S5303，重新设置被恢复进程的PID，UID，EUID，GID，EGID和进程名称等用于进程管理的基本属性。
步骤S5304，恢复所述被恢复进程的核心栈中的CPU状态部分，包括通用寄存器、调试寄存器和浮点协处理器。
在该核心栈中设置的内容将在CPU即将返回用户态的时候赋予CPU中的各个寄存器。也就是说，在这一步不是要立刻改变CPU中各个对应的寄存器的内容。
在该步骤S5304中，根据被恢复进程是在系统调用的时候被切取，还是在CPU因中断、异常进入核心态之后被切取而采取不同的恢复路径。这两种情况的识别和处理，涉及CPU中存储下一条待执行指令的地址的寄存器和在系统调用指令中保存系统调用号的寄存器。在X86系列处理器中，它们分别对应于EIP和EAX，或者其64位扩展版本RIP和RAX。
作为一种具体实施方式，该步骤S5304根据上述两种不同情况执行如下两个恢复过程之一：
(a)如果检查点中的进程状态标记表明被恢复进程是在系统调用失败之后被切取(在X86系列处理器中，可以根据当CPU进入核心态时EAX或RAX为正数而判定)，则设置EIP和EAX，或RIP和RAX，使进程恢复运行之后重新执行该未完成的系统调用指令。
(b)如果被恢复进程的检查点是通过中断、异常进入核心态之后被切取，则设置EIP或者RIP，使被恢复进程返回用户态之后继续向前执行。
步骤S5305，恢复所述被恢复进程中信号处理的相关信息。
步骤S5306中，解除宿主进程的所有虚拟存储区域的映射。
步骤S5307，加载被恢复进程的所有虚拟存储区域的映射。
对于数据段、堆空间和堆栈段内的数据，将以页面为单位从检查点文件中读取，并拷贝到为对应的虚拟地址所分配的物理页面中。
步骤S5308，设置被恢复进程的虚拟地址空间描述信息，如内存描述符(mm_struct结构)中的代码段、数据段、堆空间、堆栈段和环境变量区的起止地址等。
步骤S5309，恢复所述被恢复进程的根目录(root)、替换根目录(altroot)和当前工作目录(pwd)的路径。
步骤S5310，关闭宿主进程的执行时关闭文件描述符位图(例如在linux系统中的close_on_exec)中的各个文件。
步骤S5311，逐一恢复所述被恢复进程已打开文件的基本信息。
(1)对于普通文件，恢复对应文件的访问模式、长度、偏移等属性。
(2)对于字符型设备，按照不同的主、从设备号，调用对应设备的恢复函数。
被恢复进程所用的通信设备一般属于字符型设备，通信系统检查点的恢复过程就在这一步骤S5311中执行。通信系统检查点的恢复过程是根据进程检查点中保存的通信系统的接收和发送缓冲区的内容、接收和发送序号、接收和发送完成事件等通信状态，恢复本进程相关的通信系统状态。
步骤S5312，设置被恢复进程的状态为可运行，使其可以被正常地调度执行。
较佳地，该步骤S53还包括：在进程的恢复过程中，在该进程的通信端口恢复的末尾，用于通信及状态监控的协处理器向并行应用的其它进程广播通知继续通信。
更佳地，步骤S53还包括：判断并行应用的所有故障进程是否全部恢复，如果是，则被监测的并行应用继续运行，如果否，则等待所有故障进程全部恢复。
与现有的机群容错系统相比，本发明提供的基于故障时检查点切取和恢复(Crash-Time ChecKpoint and Restart，CTCKR)的用于机群容错的系统不再试图对机群系统中全部或者大部分结点同时出现故障的情况进行处理，也不再试图对机群系统中所有可能发生的故障都提供支持。本发明仅在探测到故障发生在一个机群结点中之后，且仅针对故障结点中的进程，执行检查点切取和恢复操作。本发明避免了现有的并行检查点系统需要定期、全局地执行检查点操作所带来的性能和存储开销，本发明的性能和存储开销与机群系统规模基本不相关，具有良好的可扩展性。
本发明是针对机群结点中的硬件故障、系统软件故障和性能故障，当故障发生时进行检查点切取操作并恢复进程，其目标场景是同一时刻发生故障的结点数量远小于整个机群系统的规模。
本发明的主要内容之一是基于远程直接内存访问(Remote Direct MemoryAccess，RDMA)通信技术的远程检查点切取和恢复。远程直接内存访问的通信过程具有无需目标结点的CPU和操作系统参与的特点，并且具有机群高速通信系统的优异性能。因此，远程检查点切取机制在目标结点的操作系统拒绝服务(Denial Of Service)等故障条件下能高效地切取(Checkpoint)应用进程的检查点。
本发明实现了机群通信系统对检查点切取和恢复的支持，使得针对单个进程的检查点切取和恢复过程不会影响同一个并行应用中的其它进程的执行。
本发明在机群结点中实现故障检测，再探测到故障后触发远程检查点切取和恢复操作，从而避免定期地执行检查点操作所带来的性能和存储开销。
本发明仅在探测到故障发生在一个机群结点中之后，且仅针对故障结点中的进程，执行检查点切取和恢复操作，这就使每次需要保存检查点的数据量从O(N)(N为并行应用的规模)降低为O(e)(e为同一时刻出现故障的机群结点的数量，一般为1)。鉴于进程检查点切取和恢复操作的过程中，绝大部分的时间用于检查点文件的读写，每次故障时检查点切取和恢复过程的时间开销t可以表示为：
t≈S(P)/Bw+S(P)/Br
上式表示，本发明的故障时检查点切取和恢复过程的总时间开销约等于目标进程P的检查点文件的长度S(P)除以文件写带宽Bw和S(P)除以文件读带宽Br。对于单个检查点文件的读写性能极易优化，因此本发明的时间开销和存储开销都小于现有技术。
本发明不但可以用于并行应用的故障恢复，也可以用于机群系统正常运行状态下的系统管理，如进程迁移等操作。
以上所述内容，仅为本发明具体的实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围内。
Claims (14)
1.一种用于机群容错的系统，所述机群包括网络连接的多个结点，其特征是，该系统包括：
检查点服务器，其网络连接到所述多个结点，用于收集并行应用的所有进程的信息，根据进程信息，向结点发送监控请求，并响应来自结点的检查点操作请求，执行远程检查点切取操作，并将检查点文件保存于检查点文件服务器上；在检查点切取操作完成后，执行检查点恢复操作；
检查点文件服务器，其网络连接到所述多个结点，用于存储检查点文件，并在进程恢复过程中提供检查点文件访问支持；
故障监测模块，位于所述结点上，用于根据所述监控请求来监测本地结点的操作系统的运行状态和所述监控请求指定进程的指定运行状态，以及所述监控请求指定的硬件部件的指定状态，并在监测到故障时向所述检查点服务器发送检查点操作请求和向被监测的并行应用的其他进程广播通知该进程正在进行检查点操作。
2.根据权利要求1所述的一种用于机群容错的系统，其特征是，所述检查点服务器包括：
并行应用进程管理器，用于在机群结点中加载并行应用，并收集并行应用的所有进程的信息；
并行应用注册管理器，用于注册并行应用的所有进程的信息，并根据进程信息，向结点发送监控请求；
检查点切取模块，用于响应来自结点的检查点操作请求，执行远程检查点切取操作，将检查点文件保存于检查点文件服务器中，并在检查点切取操作完成后，将检查点文件的位置和对应进程在其并行应用中的逻辑序号信息发送给所述并行应用进程管理器；
所述并行应用进程管理器还用于在收到所述检查点文件的位置和对应进程的逻辑序号信息后，执行进程恢复操作。
3.根据权利要求1或2所述的一种用于机群容错的系统，其特征是，在检查点服务器进行远程检查点切取过程中，通过远程直接内存访问方式获取出现故障的进程的所有状态。
4.根据权利要求1或2所述的一种用于机群容错的系统，其特征是，所述结点包括：
用于通信及状态监控的协处理器；
其中所述协处理器包括通信系统检查点模块，该通信系统检查点模块用于实现通信设备的检查点切取并将通信设备的检查点文件保存到所述检查点文件服务器上，以及根据所述通信设备的检查点文件实现通信设备的断点恢复；
其中，所述故障监测模块运行在该协处理器上。
5.根据权利要求4所述的一种用于机群容错的系统，其特征是，所述协处理器上还包括：
远程检查点服务模块，用于响应来自所述检查点服务器的读取本地进程状态、本地通信设备的状态的请求，和响应来自本地结点的故障监测模块的请求向检查点服务器发出启动检查点操作的请求并向检查点服务器发送启动检查点操作的请求。
6.根据权利要求1或2所述的一种用于机群容错的系统，其特征是，所述结点还包括：
主机方处理器，该主机方处理器包括内核状态监控模块和进程恢复模块；
其中，当该所述内核状态监控模块监测到操作系统内核状态出现故障时，向所述故障监测模块发送结点故障恢复请求；所述故障监测模块在接收到所述结点故障恢复请求后，向所述检查点服务器发送检查点操作请求；
所述进程恢复模块用于接收并行应用进程管理器发来的待恢复进程的检查点文件的位置和逻辑序号信息，读取检查点文件，完成进程恢复过程。
7.一种用于机群容错的方法，其特征是，包括如下步骤：
步骤S1，在检查点服务器上注册并行应用并向故障监测模块发送结点监控请求；
步骤S2：故障监测模块在收到监控请求后开始监测故障；
步骤S3，当故障监测模块监测到故障时，向检查点服务器发送检查点操作请求，然后通过广播将故障进程正在执行检查点操作这一事件通知被监测应用中的其它进程；
步骤S4：检查点服务器接收到检查点操作请求后执行检查点切取；
步骤S5：检查点切取完成后，检查点服务器执行进程恢复。
8.根据权利要求7所述的用于机群容错的方法，其特征是，在步骤S2中，所述的监测故障的方法包括：
根据时钟中断计数超出预定范围，判断操作系统故障；
根据操作系统内部接口调用失败，判断操作系统故障；
根据表征硬件状态的参数超出预先设定的范围，判断硬件故障；
根据应用进程或后台服务进程遇到失败的系统调用或不该收到的信号，判断进程故障。
9.根据权利要求7所述的用于机群容错的方法，其特征是，在步骤S3中，还包括：主机方处理器的内核状态监控模块监测内核状态是否出现故障，并在监测到内核状态出现故障时，向故障监测模块发送故障恢复请求，当故障监测模块收到内核状态监控模块发来的故障恢复请求时，向检查点服务器发送检查点操作请求。
10.根据权利要求7所述的用于机群容错的方法，其特征是，在步骤S3中，还包括当故障监测模块监测到故障时，首先冻结本地所有被监测的进程打开的通信端口。
11.根据权利要求7所述的用于机群容错的方法，其特征是，在步骤S4中，所述检查点切取包括如下步骤：
步骤S41，加载故障进程所在结点的操作系统符号表；
步骤S42，加载故障进程所在结点的操作系统核心类型表；
步骤S43，根据故障进程号查找故障进程的进程控制块，并复制到检查点服务器的本地缓冲区中；
步骤S44，创建检查点映像文件，并保存检查点文件内容。
12.根据权利要求7或11所述的用于机群容错的方法，其特征是，步骤S5具体包括如下步骤：
步骤S51，确定进程恢复所用的结点；
步骤S52，并行应用进程管理器向进程恢复所用的结点发送恢复进程命令；
步骤S53，进程恢复所用的结点接收恢复进程命令，执行进程恢复。
13.根据权利要求12所述的用于机群容错的方法，其特征是，步骤S53还包括：在进程的恢复过程中，在该进程的通信端口恢复的末尾，用于通信及状态监控的协处理器向并行应用的其它进程广播通知继续通信。
14.根据权利要求12所述的用于机群容错的方法，其特征是，步骤S53还包括：判断并行应用的所有故障进程是否全部恢复，如果是，则被监测的并行应用继续运行，如果否，则等待所有故障进程全部恢复。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2008102115663A CN101377750B (zh) | 2007-09-21 | 2008-09-19 | 一种用于机群容错的系统和方法 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200710122196 | 2007-09-21 | ||
| CN200710122196.1 | 2007-09-21 | ||
| CN2008102115663A CN101377750B (zh) | 2007-09-21 | 2008-09-19 | 一种用于机群容错的系统和方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101377750A CN101377750A (zh) | 2009-03-04 |
| CN101377750B true CN101377750B (zh) | 2010-10-06 |
Family
ID=40413071
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNA200810215663XA Pending CN101369241A (zh) | 2007-09-21 | 2008-09-12 | 一种机群容错系统、装置及方法 |
| CN2008102115663A Active CN101377750B (zh) | 2007-09-21 | 2008-09-19 | 一种用于机群容错的系统和方法 |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNA200810215663XA Pending CN101369241A (zh) | 2007-09-21 | 2008-09-12 | 一种机群容错系统、装置及方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (2) | CN101369241A (zh) |
Families Citing this family (50)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2760875C (en) * | 2009-05-04 | 2018-02-27 | Nortel Networks Limited | Using a variable timer for sending an error indication |
| CN101794242B (zh) * | 2010-01-29 | 2012-07-18 | 西安交通大学 | 服务于操作系统核心层的容错计算机系统数据比较方法 |
| CN101833497B (zh) * | 2010-03-30 | 2015-01-21 | 浪潮电子信息产业股份有限公司 | 一种基于专家系统方法的计算机故障管理系统 |
| CN102413004B (zh) * | 2010-09-26 | 2014-07-02 | 北京旋极信息技术股份有限公司 | 故障注入的方法和装置 |
| CN102033787B (zh) * | 2010-11-04 | 2013-03-13 | 曙光信息产业股份有限公司 | 一种对集群存储介质进行容错性管理的方法 |
| CN102221995A (zh) * | 2011-05-19 | 2011-10-19 | 中国石油集团川庆钻探工程有限公司 | 地震数据处理作业的断点恢复方法 |
| CN102323900B (zh) * | 2011-08-31 | 2014-03-26 | 国家计算机网络与信息安全管理中心 | 一种众核环境下基于动态感知的系统容错机制 |
| CN102364448B (zh) * | 2011-09-19 | 2014-01-15 | 浪潮电子信息产业股份有限公司 | 一种计算机故障管理系统的容错方法 |
| CN102404139B (zh) * | 2011-10-21 | 2014-01-15 | 浪潮电子信息产业股份有限公司 | 一种提高容错服务器应用层级容错性能的方法 |
| WO2012167552A1 (zh) * | 2011-11-15 | 2012-12-13 | 华为技术有限公司 | 监控方法及设备、网络设备 |
| US8954794B2 (en) * | 2012-06-05 | 2015-02-10 | Infineon Technologies Ag | Method and system for detection of latent faults in microcontrollers |
| CN103036957B (zh) * | 2012-12-05 | 2015-04-29 | 华为技术有限公司 | 一种数据通信方法和装置 |
| US9619314B2 (en) * | 2013-04-05 | 2017-04-11 | Hitachi, Ltd. | Management system and management program |
| CN103294769B (zh) * | 2013-04-28 | 2016-02-03 | 中国工商银行股份有限公司 | 一种大型服务器写文件的系统及方法 |
| US9626261B2 (en) * | 2013-11-27 | 2017-04-18 | Futurewei Technologies, Inc. | Failure recovery resolution in transplanting high performance data intensive algorithms from cluster to cloud |
| CN104699549B (zh) * | 2013-12-04 | 2019-07-26 | 联想(北京)有限公司 | 一种信息获取方法、信息发送方法及电子设备 |
| CN103617094A (zh) * | 2013-12-18 | 2014-03-05 | 哈尔滨工业大学 | 多核处理器的瞬时故障容错系统 |
| US9800519B2 (en) * | 2014-08-21 | 2017-10-24 | Microsoft Technology Licensing, Llc | Equitable sharing of system resources in workflow execution |
| CN105515812A (zh) * | 2014-10-15 | 2016-04-20 | 中兴通讯股份有限公司 | 资源的故障处理方法及装置 |
| CN104536770A (zh) * | 2015-01-28 | 2015-04-22 | 浪潮电子信息产业股份有限公司 | 一种支持并行作业断点恢复的作业提交和恢复方法 |
| CN104743137B (zh) * | 2015-03-05 | 2017-01-04 | 北京控制工程研究所 | 一种基于事件队列的航天器故障诊断方法 |
| US9652336B2 (en) | 2015-03-13 | 2017-05-16 | International Business Machines Corporation | Resilient programming frameworks for handling failures in parallel programs |
| JP2017188072A (ja) * | 2016-04-05 | 2017-10-12 | ルネサスエレクトロニクス株式会社 | 半導体装置及びアクセス管理方法 |
| CN107329810B (zh) * | 2016-04-28 | 2023-09-08 | 恩智浦美国有限公司 | 用于多核处理器的信号机 |
| CN107665154B (zh) * | 2016-07-27 | 2020-12-04 | 浙江清华长三角研究院 | 基于rdma与消息传递的可靠数据分析方法 |
| US10162559B2 (en) * | 2016-09-09 | 2018-12-25 | Veritas Technologies Llc | Systems and methods for performing live migrations of software containers |
| JP6900690B2 (ja) * | 2017-02-07 | 2021-07-07 | オムロン株式会社 | 制御装置 |
| CN109213627B (zh) * | 2017-07-03 | 2021-10-22 | 宏碁股份有限公司 | 容错操作方法与使用此方法的电子装置 |
| CN107995202A (zh) * | 2017-12-08 | 2018-05-04 | 杭州电子科技大学 | 一种采用Hash表组合实现拟态防御模型表决器的方法 |
| CN108279994B (zh) * | 2018-01-22 | 2021-04-16 | 北京仿真中心 | 一种连接Citrix已发布应用异常的自动化解决方法 |
| CN108595122B (zh) * | 2018-04-25 | 2020-12-22 | 江苏人加信息科技有限公司 | 一种基于局域网的计算机安全管理系统 |
| CN108961029B (zh) * | 2018-07-26 | 2022-05-06 | 创新先进技术有限公司 | 一种分布式对账处理方法、系统及终端设备 |
| CN110830283B (zh) * | 2018-08-10 | 2021-10-15 | 华为技术有限公司 | 故障检测方法、装置、设备和系统 |
| CN109324876A (zh) * | 2018-10-12 | 2019-02-12 | 西安交通大学 | 一种高可用的Docker与虚拟机初始放置方法 |
| RU2739866C2 (ru) * | 2018-12-28 | 2020-12-29 | Акционерное общество "Лаборатория Касперского" | Способ обнаружения совместимых средств для систем с аномалиями |
| US10997029B2 (en) | 2019-03-07 | 2021-05-04 | International Business Machines Corporation | Core repair with failure analysis and recovery probe |
| CN109831342A (zh) * | 2019-03-19 | 2019-05-31 | 江苏汇智达信息科技有限公司 | 一种基于分布式系统的故障恢复方法 |
| US11048549B2 (en) | 2019-04-04 | 2021-06-29 | Google Llc | Transferral of process state and/or components in computing environments |
| CN110162074B (zh) * | 2019-06-05 | 2020-03-31 | 南京航空航天大学 | 一种基于层级结构的直升机群的姿态健康管理方法 |
| CN111181760B (zh) * | 2019-09-02 | 2021-10-08 | 腾讯科技（深圳）有限公司 | 网络故障探测方法、装置、计算机可读介质及电子设备 |
| CN110727536A (zh) * | 2019-10-09 | 2020-01-24 | 上海元城汽车技术有限公司 | 控制器自检方法、装置、计算机设备和可读存储介质 |
| CN111736996B (zh) * | 2020-06-17 | 2022-08-16 | 上海交通大学 | 一种面向分布式非易失内存系统的进程持久化方法及装置 |
| CN112559253B (zh) * | 2020-12-24 | 2021-12-03 | 科东(广州)软件科技有限公司 | 一种计算机系统数据备份与还原的方法及装置 |
| FI130137B (en) | 2021-04-22 | 2023-03-09 | Univ Of Oulu | A METHOD FOR INCREASING ENERGY EFFICIENCY USING ERROR-TOLERANT ALGORITHMS FOR UNDERVOLTAGE DIGITAL SYSTEMS |
| CN113420815B (zh) * | 2021-06-24 | 2024-04-30 | 江苏师范大学 | 半监督rsdae的非线性pls间歇过程监测方法 |
| CN113515430A (zh) * | 2021-09-14 | 2021-10-19 | 国汽智控(北京)科技有限公司 | 进程的状态监控方法、装置和设备 |
| CN114564361B (zh) * | 2022-03-03 | 2024-05-07 | 合众新能源汽车股份有限公司 | 用于智能驾驶平台的应用管理方法及系统 |
| CN117665726A (zh) * | 2022-08-26 | 2024-03-08 | 上海禾赛科技有限公司 | 异常监控系统及方法、装置、处理方法、雷达及监控方法 |
| CN117076212B (zh) * | 2023-10-17 | 2024-02-23 | 北京卡普拉科技有限公司 | Mpi通信数据内容的一致性检查方法、装置、介质及设备 |
| CN117093353B (zh) * | 2023-10-17 | 2024-02-02 | 北京开源芯片研究院 | 一种中断控制方法、装置、电子设备及可读存储介质 |
-
2008
- 2008-09-12 CN CNA200810215663XA patent/CN101369241A/zh active Pending
- 2008-09-19 CN CN2008102115663A patent/CN101377750B/zh active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN101369241A (zh) | 2009-02-18 |
| CN101377750A (zh) | 2009-03-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101377750B (zh) | 一种用于机群容错的系统和方法 | |
| US8352940B2 (en) | Virtual cluster proxy to virtual I/O server manager interface | |
| US5815651A (en) | Method and apparatus for CPU failure recovery in symmetric multi-processing systems | |
| US7805636B2 (en) | Bootable post crash analysis environment | |
| US6895416B2 (en) | Checkpointing filesystem | |
| US7853825B2 (en) | Methods and apparatus for recovering from fatal errors in a system | |
| Wang et al. | Hybrid checkpointing for MPI jobs in HPC environments | |
| US20150007172A1 (en) | Cloud-enabled, distributed and high-availability system with virtual machine checkpointing | |
| US9588844B2 (en) | Checkpointing systems and methods using data forwarding | |
| CN101876926B (zh) | 一种非对称结构的软件三机热备容错方法 | |
| US20070168699A1 (en) | Method and system for extracting log and trace buffers in the event of system crashes | |
| CN101271409A (zh) | 用于迁移逻辑分区的装置和方法以及产品 | |
| US20030131039A1 (en) | System, method, and computer program product for preserving trace data after partition crash in logically partitioned systems | |
| JPS62298839A (ja) | 障害時に計算機システムを再始動する方法 | |
| CN101937344B (zh) | 一种计算机快速启动的装置及方法 | |
| US20120304184A1 (en) | Multi-core processor system, computer product, and control method | |
| JP2007133544A (ja) | 障害情報解析方法及びその実施装置 | |
| US20240152286A1 (en) | Fast restart of large memory systems | |
| US7904564B2 (en) | Method and apparatus for migrating access to block storage | |
| Rosenblum et al. | Implementing efficient fault containment for multiprocessors: confining faults in a shared-memory multiprocessor environment | |
| US20090300290A1 (en) | Memory Metadata Used to Handle Memory Errors Without Process Termination | |
| US7302690B2 (en) | Method and apparatus for transparently sharing an exception vector between firmware and an operating system | |
| JP2006079485A (ja) | 電子計算機における障害解析用情報収集方式 | |
| US7934067B2 (en) | Data update history storage apparatus and data update history storage method | |
| CN117389781B (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 | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant |