CN102364448A - 一种计算机故障管理系统的容错方法 - Google Patents
一种计算机故障管理系统的容错方法 Download PDFInfo
- Publication number
- CN102364448A CN102364448A CN2011102776808A CN201110277680A CN102364448A CN 102364448 A CN102364448 A CN 102364448A CN 2011102776808 A CN2011102776808 A CN 2011102776808A CN 201110277680 A CN201110277680 A CN 201110277680A CN 102364448 A CN102364448 A CN 102364448A
- Authority
- CN
- China
- Prior art keywords
- kernel
- fault
- module
- fault management
- event
- 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
Images
Landscapes
- Hardware Redundancy (AREA)
- Retry When Errors Occur (AREA)
Abstract
本发明提供一种计算机故障管理系统的容错框架，分为用户空间和内核空间两部分，包括故障管理核心单元1）、检查点处理模块2）、故障管理冗余单元3）、代理接收模块4）、代理发送模块5）、内核故障管理核心单元6）、内核事件传输通道7）、内核故障处理模块8）和内核故障管理冗余单元9）组成。
Description
技术领域
本发明涉及一种计算机应用技术领域, 具体地说是一种计算机故障管理系统的容错方法。
背景技术
随着计算机技术的飞速发展，计算机系统已经广泛应用于国防、教育、科研、工业、金融及社会生活的各个领域之中。在不断追求高计算能力的同时，对于计算机系统可靠性也提出了更高的要求。尤其对于支撑关键应用的计算机系统，一旦其出现故障，造成的后果是难以想象的。因此，在现代计算机系统中设计部署故障管理系统，尤其是高可靠的故障管理系统，以此来保证计算机系统的可靠性是十分必要的。
故障管理系统能够实时检测计算机系统当中的软/硬件错误，根据产生的错误参考诊断规则对错误进行诊断，一旦满足诊断规则的触发条件则立即触发故障，再由专门的故障处理模块执行故障处理（包括故障隔离、故障恢复和故障修复），并根据故障处理的执行结果进行进一步处理。故障管理系统的整个执行过程是由事件驱动，不需要人工参与，具有可预测、自我修复的特点，能够有效避免计算机系统发生故障，从而满足计算机系统可靠性要求。
然而，在追求故障管理系统保证计算机系统可靠性的同时，如何保证故障管理系统的可靠性成为十分关键和重要的前提。因此需要从计算机系统的总体结构性设计出发，综合考虑计算机系统整体可靠性和故障管理系统自身可靠性，提出一种完整优化的故障管理系统容错框架是十分必要的。
由于操作系统内核十分脆弱，容易引起Panic，我们需要尽量避免这种情况提前处理的同时，也需要考虑一旦紧急情况发生时候的急救措施。因此，提出一种故障管理系统具有一定独立性的设计，使其在紧急时刻仍能够运行良好，并能够采取一些紧急处理。
发明内容
本发明的目的是提供一种计算机故障管理系统的容错框架，以保证故障管理系统的可靠性，进而保证计算机系统的整体可靠性。
本发明是按以下方式实现的，以故障管理系统为中心，提供一套完整的容错框架，使其既能保证故障管理系统服务自身的可靠性，也能保证在操作系统内核Panic的情况下故障管理系统仍能够进行紧急处理，从而提高系统的整体可用性，该框架分为用户空间和内核空间两部分，其中：
用户空间包括：故障管理核心单元1），故障管理冗余单元2），代理接收模块3）和代理发送模块4）；其中：
故障管理核心单元1）：是整个框架在用户空间部分的核心，负责错误收集、故障诊断以及故障处理，包括故障隔离、故障恢复和故障修复；采用检查点机制，定期保存当前错误处理状态信息；故障管理核心单元由错误检测模块（1）、事件分发模块（2）、诊断引擎模块（3）、故障处理模块（4）和检查点处理单元（5）组成，其中：
错误检测模块（1），针对系统不同组件部署多个错误检测模块，具体组件涉及文件系统、应用程序和服务以及提供用户空间检测手段的硬件组件，错误检测模块主动将自己生成的错误事件加入事件分发模块事件缓冲区；
事件分发模块（2），负责向故障管理核心单元各模块主动分发事件，事件包括错误事件和故障事件，事件分发模块遍历事件缓冲区中每一个事件，如果是错误事件，则将事件发给诊断引擎模块的归并单元，如果是故障事件，则查询故障处理模块哈希表，将故障事件发给指定故障处理模块；
诊断引擎模块（3），包含一套诊断规则，针对每一类故障事件创建一个归并单元，由归并单元产生故障事件，并加入事件分发模块的事件缓冲区；
故障处理模块（4），针对系统不同组件部署多个故障处理模块，组件涉及CPU、内存和I/O以及应用程序，故障处理方式包括故障隔离、故障恢复和故障修复，根据故障处理结果选择更优的故障处理方式；
检查点处理单元（5），由检查点信息收集模块①、检查点创建模块②和检查点回滚模块③组成；检查点处理单元负责收集故障管理核心单元各组件信息，创建检查点消息以及回滚检查点；
故障管理冗余单元2）：是故障管理核心单元的冗余组件，负责接收故障管理核心单元的心跳及监控故障管理核心单元的工作状态；定期将故障管理核心单元的检查点信息保存至检查点文件中，故障管理冗余单元和故障管理核心单元相互监听对方心跳，当心跳超时，故障管理冗余单元则立即重启对方单元的执行进程，故障管理冗余单元工作流程如下：
a）交互模块接收检查点处理单元发送的检查点消息，保存至检查点消息缓冲区，当消息数目达到预设阀值时，由信息保存模块将消息缓冲区中所有消息保存至检查点文件；
b）交互模块接受检查点处理单元的消息请求，从检查点消息缓冲区或检查点文件中获取指定检查点消息并发送给检查点处理单元；
代理接收模块3）：代理接收模块位于用户空间，是故障管理系统用户空间和内核空间的通信代理，负责接收来自内核空间的错误事件；生成内核标准错误事件并加入事件分发模块事件缓冲区，采用Netlink机制与内核事件传输通道通信，模块由故障管理核心单元执行进程初始化，独立运行；
代理发送模块4）：代理发送模块位于用户空间，是故障管理系统用户空间和内核空间的通信代理，负责将内核标准错误事件的诊断结果发送给内核事件传输通道，再由内核事件传输通道将内核错误事件的诊断结果发送给内核空间故障处理模块，代理发送模块采用Netlink机制与内核事件传输通道通信，由故障管理核心单元执行进程初始化，独立运行；
内核空间包括：内核故障管理核心单元5），含内核事件传输通道6），内核故障处理模块7），内核故障管理冗余单元8），其中：
内核故障管理核心单元5）：是整个框架在内核空间部分的核心，内核故障管理核心单元由内核事件传输通道和内核故障处理模块组成，负责对内核错误事件的收集、分发和故障处理，采用一个内核线程、一组接口和应用规范的方式，内核错误检测源，包括内核模块、驱动程序和内核部件，通过这组接口和应用规范，使用故障管理系统提供的故障管理功能，其中，通过在中断下半部和内核代码中添加回调函数的方法，获得内核错误检测源的原始错误信息，回调函数调用的一组接口实际是对内核事件传输通道的封装，应用规范指内核错误事件，包括一般事件和紧急事件的故障处理规则；
内核故障管理核心单元工作流程如下：
a）内核事件传输通道获得原始错误信息；
b）内核事件传输通道判断原始错误事件类型，如果是一般事件，则将原始事件发送给代理接收模块，如果是紧急事件，则直接交给内核故障处理模块；
c）内核故障处理模块处理紧急事件以及来自用户空间的标准故障事件；
为了保证内核故障管理核心单元执行线程可靠运行，采用在系统启动时，隔离处于两个不
同NUMA域中的两个逻辑CPU单独运行内核故障管理核心单元执行线程的方法，CPU选择策略如下：
a）根据ACPI提供的SRAT表，在第一个节点任意选择一个CPU；
b）根据距离表，再找出与此相距最远的一个CPU；
选择距离最远CPU的目的是为了减少由于两个CPU同时出错而造成故障管理系统无法正常运行的可能性；
内核事件传输通道6）：是故障管理系统用户空间和内核空间的信息传递接口，采用Netlink机制实现；内核事件传输通道封装成一组接口，在内核模块、驱动程序和内核部件的中断下半部和内核代码中以回调函数形式被调用，与用户空间代理接收模块和代理发送模块传递事件信息；
内核故障处理模块7）：分为内核紧急事件处理和一般事件处理，经内核故障管理核心单元判断，如果是内核紧急事件，则直接由内核故障处理模块处理，包括采用Kexec机制快速重启一个新内核；如果是一般事件，则经由故障管理系统用户空间诊断后，再由内核故障处理模块处理，包括调用内核空间功能函数；其中：
（1）针对某些MCA机制对致命错误恢复不成功，PCIE AER机制对致命错误恢复不成功，内核发生致命错误情况，在这种情况下内核执行Panic处理，截断Panic处理，由内核故障处理模块处理，执行Kexec机制快速重启一个新内核；
（2）针对MCA、PCIE AER、SCSI EH机制成功恢复可恢复错误，以及内核发生非紧急错误情况，经过用户空间故障管理核心单元诊断后，最终交给内核故障处理模块处理，处理方式包括：CPU Offline、PCIE Offline、内存页隔离；
内核故障管理冗余单元8）：是内核故障管理核心单元5）的冗余组件，负责监控内核故障管理核心单元的工作状态，内核故障管理冗余单元和内核故障管理核心单元之间采用心跳连接，负责接收内核故障管理核心单元的心跳，以监控内核故障管理核心单元的工作状态；
内核故障管理冗余单元8）执行线程运行在另一个隔离的逻辑CPU上，且与运行内核故障管理核心单元执行线程的逻辑CPU距离最远，减少由于两个CPU同时出错造成故障管理系统无法正常运行的可能性；
内核故障管理冗余单元8）执行线程监听内核故障管理核心单元执行线程的心跳，当检测到心跳超时，内核故障管理冗余单元立即担当内核故障管理核心单元的角色，取代原来的内核故障管理核心单元继续工作，同时，初始化一个新的内核故障管理冗余单元，并将其迁移到另一个隔离的CPU上运行；
用户空间各单元或模块收集各组件错误信息，生成标准错误事件发送给事件分发模块；事件分发模块将错误检测模块生成的标准错误事件交给诊断引擎模块处理；诊断引擎模块将标准错误事件进行归并，并根据错误事件的诊断规则诊断组件故障，预测组件可能产生的故障，生成标准故障事件交给事件分发模块；事件分发模块进一步将标准故障事件发送给故障处理模块，由其完成后续故障处理动作；
内核空间各单元或模块收集各内核组件错误信息，将原始内核错误事件交给内核事件传输通道；内核事件传输通道判断原始内核错误事件类型，如果是紧急事件，则直接交给内核故障处理模块处理；如果是一般事件，则将原始内核错误事件发送给用户空间代理接收模块；代理接收模块根据原始内核错误事件创建标准内核错误事件交给事件分发模块，进而完成用户空间一系列处理动作，最终将生成的标准内核故障事件由代理发送模块发送给内核事件传输通道；内核事件传输通道将标准内核故障事件交给内核故障处理模块处理；
容错工作流程如下：
a）信息收集，检查点信息收集模块分别遍历各错误检测模块、事件分发模块和各故障处理模块的事件缓冲区，获得当前各模块事件缓冲区中所有的事件信息；获得诊断引擎模块当前所有归并单元的信息；
b）检查点创建，检查点创建模块将检查点信息收集模块获得的所有信息，按照检查点消息格式创建检查点消息；
c）消息发送，检查点创建模块将当前检查点消息发送给故障管理冗余单元；
d）检查点回滚，检查点回滚模块从故障管理冗余单元获得指定检查点消息，包括用户指定或者最近一次检查点，按照检查点消息格式解析检查点消息，并初始化故障管理核心单元对应模块；
检查点消息由检查点消息头CkptHeader和一组模块段数据ModSecData组成，格式如下：
[CkptHeader, ModSecData, ModSecData, …, ModSecData]
CkptHeader描述检查点时间、消息大小、模块段数目信息，ModSecData描述各模块具体检查点信息，包括模块段头ModSecHeader和模块包含的一组事件信息CkptEvent组成，格式如下：
[ModSecHeader, CkptEvent, CkptEvent, …, CkptEvent]
ModSecHeader描述模块类型、模块段数据大小、模块包含事件数目的信息。
为了保证故障管理系统自身的可靠性，对故障管理系统核心部件-故障管理核心单元采用检查点机制，定期保存其错误处理状态信息；同时，采用故障管理冗余单元对故障管理核心单元进行心跳检测，一旦检测到故障管理核心单元执行进程非正常终止，则立刻重启故障管理系统并快速回滚到上一次检查点状态并继续工作，从而提高故障管理系统的可用性。
以故障管理系统为中心，提供一套完整的容错框架，为了保证在操作系统内核Panic的情况下故障管理系统能够做一些紧急处理，采用隔离一部分CPU资源的方法，这部分CPU资源只运行故障管理系统内核空间执行程序，独立于操作系统进程调度，并修改内核Panic机制，当内核Panic时执行内核空间故障管理系统故障处理过程；同时，采用内核故障管理冗余单元对内核故障管理核心单元进行心跳检测，一旦检测到内核故障管理核心单元执行线程非正常终止，则立刻取代内核故障管理核心单元进行工作，并重新初始化一个新的内核故障管理冗余单元；同时，为了尽量减少在内核空间的工作，采用内核非紧急错误事件由用户空间故障管理系统诊断的策略。综上特征，从而提高系统的整体可用性。
本发明所述的计算机故障管理系统的容错框架与现有的故障管理系统相比，具有以下优点：
1. 本系统框架分跨用户空间和内核空间，综合考量各种故障检测手段，具有可扩展性，既能检测应用程序引发的错误和异常，保证服务的可靠性，又能检测各主要硬件错误以及操作系统驱动程序等错误，保证系统的可靠性。
2. 本系统框架对关键部件采用检查点策略，定期保存错误在处理过程各阶段的状态信息，保证不会由于系统执行进程异常终止等情况而导致错误处理信息丢失，对关键部件采用冗余组件监控策略，用冗余组件监控关键部件的工作状态。从而保证系统自身的可靠性。
3. 本系统框架具有一定的独立性，框架内核空间部分独立运行于隔离的CPU资源上，从而故障管理系统的运行状况不受内核影响，因而一旦内核Panic时，故障管理系统仍能够继续运行，并采取紧急故障补救措施。同时，对框架内核空间部分的关键部件采用冗余互备策略，提高系统自身的可靠性。
附图说明
附图1为故障管理系统容错框架结构示意图；
附图2为故障管理系统容错框架处理流程示意图；
附图3为检查点处理单元结构示意图；
附图4为检查点处理单元处理流程示意图。
具体实施方式
下面结合附图对本发明的方法进行更详细的说明。
参照附图1，计算机故障管理系统容错框架分为用户空间和内核空间两部分，用户空间部分由故障管理核心单元，内含检查点处理模块，故障管理冗余单元以及代理接收模块和代理发送模块组成，内核空间部分由内核故障管理核心单元，包括内核事件传输通道、内核故障处理模块和内核故障管理冗余单元组成。
计算机故障管理系统容错框架各部分功能和工作职责如下：
故障管理核心单元：是整个框架在用户空间部分的核心，负责错误收集、故障诊断以及故障处理，其中故障处理方式包括故障隔离、故障恢复和故障修复，根据故障处理结果选择更优的故障处理方式；采用检查点机制，定期保存当前错误处理状态信息。
检查点处理模块：负责收集故障管理核心单元各组件信息，创建检查点消息，以及回滚检查点。
故障管理冗余单元：是故障管理核心单元的冗余组件，负责接收故障管理核心单元的心跳，以监控故障管理核心单元的工作状态；定期将故障管理核心单元的检查点信息保存至检查点文件中。
代理接收模块：是故障管理系统用户空间和内核空间的通信代理，负责接收来自内核空间的错误事件。
代理发送模块：是故障管理系统用户空间和内核空间的通信代理，负责将内核错误事件的诊断结果发送给内核空间故障处理模块。
内核故障管理核心单元：是整个框架在内核空间部分的核心，负责对内核错误事件的收集、分发和故障处理。
内核事件传输通道是故障管理系统用户空间和内核空间的信息传递接口，采用Netlink机制实现。
内核故障处理模块：分为内核紧急事件处理和一般事件处理，经内核故障管理核心单元判断，如果是内核紧急事件，则直接由内核故障处理模块处理，例如采用Kexec机制快速重启一个新内核；如果是一般事件，则经由故障管理系统用户空间诊断后，再由内核故障处理模块处理（调用内核空间功能函数）。
内核故障管理冗余单元：是内核故障管理核心单元的冗余组件，负责接收内核故障管理核心单元的心跳，以监控内核故障管理核心单元的工作状态。
参照附图2，本发明所述系统的容错框架处理的主要工作流程如下：
用户空间各错误检测模块收集各组件错误信息，生成标准错误事件发送给事件分发模块；事件分发模块将错误检测模块生成的标准错误事件交给诊断引擎模块处理；诊断引擎模块将标准错误事件进行归并，并根据错误事件的诊断规则诊断组件故障，预测组件可能产生的故障，生成标准故障事件交给事件分发模块；事件分发模块进一步将标准故障事件发送给故障处理模块由其完成后续故障处理动作。
内核空间各内核错误检测源收集各内核组件错误信息，将原始内核错误事件交给内核事件传输通道；内核事件传输通道判断原始内核错误事件类型，如果是紧急事件，则直接交给内核故障处理模块处理；如果是一般事件，则将原始内核错误事件发送给用户空间代理接收模块；代理接收模块根据原始内核错误事件创建标准内核错误事件交给事件分发模块，进而完成用户空间一系列处理动作，最终将生成的标准内核故障事件由代理发送模块发送给内核事件传输通道；内核事件传输通道将标准内核故障事件交给内核故障处理模块处理。
1. 故障管理核心单元
本发明所述系统中，故障管理核心单元是整个框架在用户空间部分的核心。参照附图2，故障管理核心单元由错误检测模块、事件分发模块、诊断引擎模块、故障处理模块和检查点处理单元组成。
1）错误检测模块，针对系统不同组件部署多个错误检测模块，具体组件涉及文件系统、应用程序和服务，以及提供用户空间检测手段的硬件组件等。错误检测模块主动将自己生成的错误事件加入事件分发模块事件缓冲区；
2）事件分发模块，负责向故障管理核心单元各模块主动分发事件，事件包括错误事件和故障事件。事件分发模块遍历事件缓冲区中每一个事件，如果是错误事件，则将事件发给诊断引擎模块的归并单元。如果是故障事件，则查询故障处理模块哈希表，将故障事件发给指定故障处理模块；
3）诊断引擎模块，包含一套诊断规则，针对每一类故障事件创建一个归并单元，由归并单元产生故障事件，并加入事件分发模块的事件缓冲区；
4）故障处理模块，针对系统不同组件部署多个故障处理模块，组件涉及CPU、内存和I/O，以及应用程序等。故障处理方式包括故障隔离、故障恢复和故障修复，根据故障处理结果选择更优的故障处理方式。
5）故障管理冗余单元和故障管理核心单元相互监听对方心跳，当心跳超时，则立即重启对方单元的执行进程。
2. 检查点处理单元
本发明所述系统中，检查点处理单元属于故障管理核心单元。参照附图3，检查点处理单元由检查点信息收集模块、检查点创建模块和检查点回滚模块组成。
参照附图4，其主要工作流程如下：
a）信息收集，检查点信息收集模块分别遍历各错误检测模块、事件分发模块和各故障处理模块的事件缓冲区，获得当前各模块事件缓冲区中所有的事件信息；获得诊断引擎模块当前所有归并单元的信息；
b）检查点创建，检查点创建模块将检查点信息收集模块获得的所有信息，按照检查点消息格式创建检查点消息；
c）消息发送，检查点创建模块将当前检查点消息发送给故障管理冗余单元；
d）检查点回滚，检查点回滚模块从故障管理冗余单元获得指定检查点消息（用户指定或者最近一次检查点），按照检查点消息格式解析检查点消息，并初始化故障管理核心单元对应模块。
在本系统的典型实现中，检查点消息由检查点消息头（CkptHeader）和一组模块段数据（ModSecData）组成，格式如下：
[CkptHeader, ModSecData, ModSecData, …, ModSecData]
CkptHeader描述检查点时间、消息大小、模块段数目等信息。ModSecData描述各模块具体检查点信息，包括模块段头（ModSecHeader）和模块包含的一组事件信息（CkptEvent）组成，格式如下：
[ModSecHeader, CkptEvent, CkptEvent, …, CkptEvent]
ModSecHeader描述模块类型、模块段数据大小、模块包含事件数目等信息。
3. 故障管理冗余单元
本发明所述系统中，故障管理冗余单元是故障管理核心单元的冗余组件，负责监控故障管理核心单元的工作状态；定期将故障管理核心单元的检查点信息保存至检查点文件中。参照附图2，故障管理冗余单元执行进程监听故障管理核心单元执行进程发送的心跳，当检测到心跳超时，故障管理冗余单元立即重启故障管理核心单元执行进程。
故障管理冗余单元主要工作流程如下：
a）交互模块接收检查点处理单元发送的检查点消息，保存至检查点消息缓冲区，当消息数目达到预设阀值时，由信息保存模块将消息缓冲区中所有消息保存至检查点文件；
b）交互模块接受检查点处理单元的消息请求，从检查点消息缓冲区或检查点文件中获取指定检查点消息并发送给检查点处理单元。
4. 代理接收模块
本发明所述系统中，代理接收模块位于用户空间是故障管理系统用户空间和内核空间的通信代理，负责接收来自内核空间的错误事件，生成内核标准错误事件并加入事件分发模块事件缓冲区。采用Netlink机制与内核事件传输通道通信，模块由故障管理核心单元执行进程初始化，独立运行。
5. 代理发送模块
本发明所述系统中，代理发送模块位于用户空间是故障管理系统用户空间和内核空间的通信代理，负责将内核标准错误事件的诊断结果-内核标准故障事件发送给内核事件传输通道。采用Netlink机制与内核事件传输通道通信，模块由故障管理核心单元执行进程初始化，独立运行。
6. 内核故障管理核心单元
本发明所述系统中，内核故障管理核心单元是整个框架在内核空间部分的核心。参照附图2，内核故障管理核心单元由内核事件传输通道和内核故障处理模块组成，负责对内核错误事件的收集、分发和故障处理。在实现上，采用一个内核线程、一组接口和应用规范的方式。内核错误检测源（包括内核模块、驱动程序和内核部件）可以通过这组接口和应用规范，使用故障管理系统提供的故障管理功能。其中，通过在中断下半部和内核代码中添加回调函数的方法，获得内核错误检测源的原始错误信息，回调函数调用的一组接口实际是对内核事件传输通道的封装，应用规范指内核错误事件（一般事件和紧急事件）的故障处理规则。
参照附图2，内核故障管理核心单元主要工作流程如下：
a）内核事件传输通道获得原始错误信息；
b）内核事件传输通道判断原始错误事件类型，如果是一般事件，则将原始事件发送给代理接收模块，如果是紧急事件，则直接交给内核故障处理模块；
c）内核故障处理模块处理紧急事件以及来自用户空间的标准故障事件。
为了保证内核故障管理核心单元执行线程可靠运行，采用在系统启动时，隔离处于两个不同NUMA域中的两个逻辑CPU单独运行内核故障管理核心单元执行线程的方法。CPU选择策略如下：
a）根据ACPI提供的SRAT表，在第一个节点任意选择一个CPU；
b）根据距离表，再找出与此相距最远的一个CPU。
选择距离最远CPU的目的是为了减少由于两个CPU同时出错而造成故障管理系统无法正常运行的可能性。
7. 内核事件传输通道
本发明所述系统中，内核事件传输通道是故障管理系统用户空间和内核空间的信息传递接口，采用Netlink机制实现。内核事件传输通道封装成一组接口，在内核模块、驱动程序和内核部件的中断下半部和内核代码中以回调函数形式被调用。与用户空间代理接收模块和代理发送模块传递事件信息。
8. 内核故障处理模块
本发明所述系统中，内核故障处理模块分为内核紧急事件处理和一般事件处理。
（1）针对某些MCA机制对致命错误恢复不成功，PCIE AER机制对致命错误恢复不成功，内核发生致命错误等情况（通常在这种情况下内核执行Panic处理），截断Panic处理，由内核故障处理模块处理，执行Kexec机制快速重启一个新内核；
（2）针对MCA、PCIE AER、SCSI EH等机制成功恢复可恢复错误，以及内核发生非紧急错误等情况，经过用户空间故障管理核心单元诊断后，最终交给内核故障处理模块处理。处理方式包括：CPU Offline、PCIE Offline、内存页隔离等。
9. 内核故障管理冗余单元
本发明所述系统中，内核故障管理冗余单元是内核故障管理核心单元的冗余组件，负责监控内核故障管理核心单元的工作状态。内核故障管理冗余单元执行线程运行在另一个隔离的逻辑CPU上，且与运行内核故障管理核心单元执行线程的逻辑CPU距离最远，减少由于两个CPU同时出错造成故障管理系统无法正常运行的可能性。
参照附图2，内核故障管理冗余单元执行线程监听内核故障管理核心单元执行线程的心跳，当检测到心跳超时，内核故障管理冗余单元立即担当内核故障管理核心单元的角色，取代原来的内核故障管理核心单元继续工作。同时，初始化一个新的内核故障管理冗余单元，并将其迁移到另一个隔离的CPU上运行。
Claims (4)
1.一种计算机故障管理系统的容错方法, 其特征在于以故障管理系统为中心，提供一套完整的容错框架，使其既能保证故障管理系统服务自身的可靠性，也能保证在操作系统内核Panic的情况下故障管理系统仍能够进行紧急处理，从而提高系统的整体可用性，该框架分为用户空间和内核空间两部分，其中：
用户空间包括：故障管理核心单元1），故障管理冗余单元2），代理接收模块3）和代理发送模块4），其中：
故障管理核心单元1）：是整个框架在用户空间部分的核心，负责错误收集、故障诊断以及故障处理，包括故障隔离、故障恢复和故障修复；采用检查点机制，定期保存当前错误处理状态信息；故障管理核心单元由错误检测模块（1）、事件分发模块（2）、诊断引擎模块（3）、故障处理模块（4）和检查点处理单元（5）组成，其中：
错误检测模块（1），针对系统不同组件部署多个错误检测模块，具体组件涉及文件系统、应用程序和服务以及提供用户空间检测手段的硬件组件，错误检测模块主动将自己生成的错误事件加入事件分发模块事件缓冲区；
事件分发模块（2），负责向故障管理核心单元各模块主动分发事件，事件包括错误事件和故障事件，事件分发模块遍历事件缓冲区中每一个事件，如果是错误事件，则将事件发给诊断引擎模块的归并单元，如果是故障事件，则查询故障处理模块哈希表，将故障事件发给指定故障处理模块；
诊断引擎模块（3），包含一套诊断规则，针对每一类故障事件创建一个归并单元，由归并单元产生故障事件，并加入事件分发模块的事件缓冲区；
故障处理模块（4），针对系统不同组件部署多个故障处理模块，组件涉及CPU、内存和I/O以及应用程序，故障处理方式包括故障隔离、故障恢复和故障修复，根据故障处理结果选择更优的故障处理方式；
检查点处理单元（5），由检查点信息收集模块①、检查点创建模块②和检查点回滚模块③组成；检查点处理单元负责收集故障管理核心单元各组件信息，创建检查点消息以及回滚检查点；
故障管理冗余单元2）：是故障管理核心单元的冗余组件，负责接收故障管理核心单元的心跳及监控故障管理核心单元的工作状态；定期将故障管理核心单元的检查点信息保存至检查点文件中，故障管理冗余单元和故障管理核心单元相互监听对方心跳，当心跳超时，故障管理冗余单元则立即重启对方单元的执行进程，故障管理冗余单元工作流程如下：
a）交互模块接收检查点处理单元发送的检查点消息，保存至检查点消息缓冲区，当消息数目达到预设阀值时，由信息保存模块将消息缓冲区中所有消息保存至检查点文件；
b）交互模块接受检查点处理单元的消息请求，从检查点消息缓冲区或检查点文件中获取指定检查点消息并发送给检查点处理单元；
代理接收模块3）：代理接收模块位于用户空间，是故障管理系统用户空间和内核空间的通信代理，负责接收来自内核空间的错误事件；生成内核标准错误事件并加入事件分发模块事件缓冲区，采用Netlink机制与内核事件传输通道通信，模块由故障管理核心单元执行进程初始化，独立运行；
代理发送模块4）：代理发送模块位于用户空间，是故障管理系统用户空间和内核空间的通信代理，负责将内核标准错误事件的诊断结果发送给内核事件传输通道，再由内核事件传输通道将内核错误事件的诊断结果发送给内核空间故障处理模块，代理发送模块采用Netlink机制与内核事件传输通道通信，由故障管理核心单元执行进程初始化，独立运行；
内核空间包括：内核故障管理核心单元5），含内核事件传输通道6），内核故障处理模块7），内核故障管理冗余单元8），其中：
内核故障管理核心单元5）：是整个框架在内核空间部分的核心，内核故障管理核心单元由内核事件传输通道和内核故障处理模块组成，负责对内核错误事件的收集、分发和故障处理，采用一个内核线程、一组接口和应用规范的方式，内核错误检测源，包括内核模块、驱动程序和内核部件，通过这组接口和应用规范，使用故障管理系统提供的故障管理功能，其中，通过在中断下半部和内核代码中添加回调函数的方法，获得内核错误检测源的原始错误信息，回调函数调用的一组接口实际是对内核事件传输通道的封装，应用规范指内核错误事件，包括一般事件和紧急事件的故障处理规则；
内核故障管理核心单元工作流程如下：
a）内核事件传输通道获得原始错误信息；
b）内核事件传输通道判断原始错误事件类型，如果是一般事件，则将原始事件发送给代理接收模块，如果是紧急事件，则直接交给内核故障处理模块；
c）内核故障处理模块处理紧急事件以及来自用户空间的标准故障事件；
为了保证内核故障管理核心单元执行线程可靠运行，采用在系统启动时，隔离处于两个不
同NUMA域中的两个逻辑CPU单独运行内核故障管理核心单元执行线程的方法，CPU选择策略如下：
a）根据ACPI提供的SRAT表，在第一个节点任意选择一个CPU；
b）根据距离表，再找出与此相距最远的一个CPU；
选择距离最远CPU的目的是为了减少由于两个CPU同时出错而造成故障管理系统无法正常运行的可能性；
内核事件传输通道6）：是故障管理系统用户空间和内核空间的信息传递接口，采用Netlink机制实现；内核事件传输通道封装成一组接口，在内核模块、驱动程序和内核部件的中断下半部和内核代码中以回调函数形式被调用，与用户空间代理接收模块和代理发送模块传递事件信息；
内核故障处理模块7）：分为内核紧急事件处理和一般事件处理，经内核故障管理核心单元判断，如果是内核紧急事件，则直接由内核故障处理模块处理，包括采用Kexec机制快速重启一个新内核；如果是一般事件，则经由故障管理系统用户空间诊断后，再由内核故障处理模块处理，包括调用内核空间功能函数；其中：
（1）针对某些MCA机制对致命错误恢复不成功，PCIE AER机制对致命错误恢复不成功，内核发生致命错误情况，在这种情况下内核执行Panic处理，截断Panic处理，由内核故障处理模块处理，执行Kexec机制快速重启一个新内核；
（2）针对MCA、PCIE AER、SCSI EH机制成功恢复可恢复错误，以及内核发生非紧急错误情况，经过用户空间故障管理核心单元诊断后，最终交给内核故障处理模块处理，处理方式包括：CPU Offline、PCIE Offline、内存页隔离；
内核故障管理冗余单元8）：是内核故障管理核心单元5）的冗余组件，负责监控内核故障管理核心单元的工作状态，内核故障管理冗余单元和内核故障管理核心单元之间采用心跳连接，负责接收内核故障管理核心单元的心跳，以监控内核故障管理核心单元的工作状态；
内核故障管理冗余单元8）执行线程运行在另一个隔离的逻辑CPU上，且与运行内核故障管理核心单元执行线程的逻辑CPU距离最远，减少由于两个CPU同时出错造成故障管理系统无法正常运行的可能性；
内核故障管理冗余单元8）执行线程监听内核故障管理核心单元执行线程的心跳，当检测到心跳超时，内核故障管理冗余单元立即担当内核故障管理核心单元的角色，取代原来的内核故障管理核心单元继续工作，同时，初始化一个新的内核故障管理冗余单元，并将其迁移到另一个隔离的CPU上运行。
2.根据权利要求1所述的方法，其特征在于，用户空间各单元或模块收集各组件错误信息，生成标准错误事件发送给事件分发模块；事件分发模块将错误检测模块生成的标准错误事件交给诊断引擎模块处理；诊断引擎模块将标准错误事件进行归并，并根据错误事件的诊断规则诊断组件故障，预测组件可能产生的故障，生成标准故障事件交给事件分发模块；事件分发模块进一步将标准故障事件发送给故障处理模块，由其完成后续故障处理动作；
内核空间各单元或模块收集各内核组件错误信息，将原始内核错误事件交给内核事件传输通道；内核事件传输通道判断原始内核错误事件类型，如果是紧急事件，则直接交给内核故障处理模块处理；如果是一般事件，则将原始内核错误事件发送给用户空间代理接收模块；代理接收模块根据原始内核错误事件创建标准内核错误事件交给事件分发模块，进而完成用户空间一系列处理动作，最终将生成的标准内核故障事件由代理发送模块发送给内核事件传输通道；内核事件传输通道将标准内核故障事件交给内核故障处理模块处理；
容错工作流程如下：
a）信息收集，检查点信息收集模块分别遍历各错误检测模块、事件分发模块和各故障处理模块的事件缓冲区，获得当前各模块事件缓冲区中所有的事件信息；获得诊断引擎模块当前所有归并单元的信息；
b）检查点创建，检查点创建模块将检查点信息收集模块获得的所有信息，按照检查点消息格式创建检查点消息；
c）消息发送，检查点创建模块将当前检查点消息发送给故障管理冗余单元；
d）检查点回滚，检查点回滚模块从故障管理冗余单元获得指定检查点消息，包括用户指定或者最近一次检查点，按照检查点消息格式解析检查点消息，并初始化故障管理核心单元对应模块；
检查点消息由检查点消息头CkptHeader和一组模块段数据ModSecData组成，格式如下：
[CkptHeader, ModSecData, ModSecData, …, ModSecData]
CkptHeader描述检查点时间、消息大小、模块段数目信息，ModSecData描述各模块具体检查点信息，包括模块段头ModSecHeader和模块包含的一组事件信息CkptEvent组成，格式如下：
[ModSecHeader, CkptEvent, CkptEvent, …, CkptEvent]
ModSecHeader描述模块类型、模块段数据大小、模块包含事件数目的信息。
3.根据权利要求1所述的方法，其特征在于，为了保证故障管理系统自身的可靠性，对故障管理系统核心部件-故障管理核心单元采用检查点机制，定期保存其错误处理状态信息；同时，采用故障管理冗余单元对故障管理核心单元进行心跳检测，一旦检测到故障管理核心单元执行进程非正常终止，则立刻重启故障管理系统并快速回滚到上一次检查点状态并继续工作，从而提高故障管理系统的可用性。
4.根据权利要求1所述的方法，其特征在于，以故障管理系统为中心，提供一套完整的容错框架，为了保证在操作系统内核Panic的情况下故障管理系统能够做一些紧急处理，采用隔离一部分CPU资源的方法，这部分CPU资源只运行故障管理系统内核空间执行程序，独立于操作系统进程调度，并修改内核Panic机制，当内核Panic时执行内核空间故障管理系统故障处理过程；同时，采用内核故障管理冗余单元对内核故障管理核心单元进行心跳检测，一旦检测到内核故障管理核心单元执行线程非正常终止，则立刻取代内核故障管理核心单元进行工作，并重新初始化一个新的内核故障管理冗余单元；同时，为了尽量减少在内核空间的工作，采用内核非紧急错误事件由用户空间故障管理系统诊断的策略，综上特征，从而提高系统的整体可用性。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201110277680.8A CN102364448B (zh) | 2011-09-19 | 2011-09-19 | 一种计算机故障管理系统的容错方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201110277680.8A CN102364448B (zh) | 2011-09-19 | 2011-09-19 | 一种计算机故障管理系统的容错方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN102364448A true CN102364448A (zh) | 2012-02-29 |
| CN102364448B CN102364448B (zh) | 2014-01-15 |
Family
ID=45691014
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201110277680.8A Active CN102364448B (zh) | 2011-09-19 | 2011-09-19 | 一种计算机故障管理系统的容错方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN102364448B (zh) |
Cited By (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102662831A (zh) * | 2012-03-20 | 2012-09-12 | 中国人民解放军国防科学技术大学 | 一种容错系统诊断策略优化方法 |
| CN103064770A (zh) * | 2013-01-08 | 2013-04-24 | 哈尔滨工程大学 | 双进程冗余瞬时故障容错方法 |
| CN103067740A (zh) * | 2012-12-31 | 2013-04-24 | 浙江元亨通信技术股份有限公司 | 视频监控设备故障智能检测方法及其检测系统 |
| CN103197981A (zh) * | 2013-01-21 | 2013-07-10 | 浪潮(北京)电子信息产业有限公司 | 存储空间预警方法和系统 |
| CN103455393A (zh) * | 2013-09-25 | 2013-12-18 | 浪潮电子信息产业股份有限公司 | 一种基于进程冗余的容错系统设计方法 |
| CN103559124A (zh) * | 2013-10-24 | 2014-02-05 | 华为技术有限公司 | 故障快速检测方法及装置 |
| CN103593251A (zh) * | 2013-11-07 | 2014-02-19 | 浪潮电子信息产业股份有限公司 | 一种基于进程冗余的容错系统及其设计方法 |
| CN103617094A (zh) * | 2013-12-18 | 2014-03-05 | 哈尔滨工业大学 | 多核处理器的瞬时故障容错系统 |
| CN103995759A (zh) * | 2014-05-21 | 2014-08-20 | 中国人民解放军国防科学技术大学 | 基于核内外协同的高可用计算机系统故障处理方法及装置 |
| CN104954002A (zh) * | 2014-03-26 | 2015-09-30 | 英飞凌科技股份有限公司 | 功率开关的受控关断 |
| CN105051692A (zh) * | 2013-01-09 | 2015-11-11 | 微软技术许可有限责任公司 | 通过隔离的自动化故障处理 |
| CN105045917A (zh) * | 2015-08-20 | 2015-11-11 | 北京百度网讯科技有限公司 | 一种基于实例的分布式数据恢复方法和装置 |
| CN105069052A (zh) * | 2015-07-24 | 2015-11-18 | 北京控制工程研究所 | 一种星载操作系统集成的故障快速自主处理方法 |
| CN105528276A (zh) * | 2015-12-09 | 2016-04-27 | 中国航空工业集团公司西安航空计算技术研究所 | 基于分区操作系统健康监控的模块支持层故障处理方法 |
| CN105988885A (zh) * | 2015-03-26 | 2016-10-05 | 朱怡安 | 基于补偿回滚的操作系统故障自恢复方法 |
| CN106339297A (zh) * | 2016-09-14 | 2017-01-18 | 郑州云海信息技术有限公司 | 一种存储系统故障实时告警的方法及系统 |
| CN106844082A (zh) * | 2017-01-18 | 2017-06-13 | 联想(北京)有限公司 | 处理器预测故障分析方法及装置 |
| CN106980555A (zh) * | 2017-03-24 | 2017-07-25 | 山东浪潮商用系统有限公司 | 一种超时线程处理方法及装置 |
| CN108205479A (zh) * | 2017-10-25 | 2018-06-26 | 珠海市魅族科技有限公司 | 一种故障信息处理的方法、装置及存储介质 |
| CN111443624A (zh) * | 2019-01-17 | 2020-07-24 | 厦门地平线征程智能科技有限公司 | 车载设备及其检测方法 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20060150004A1 (en) * | 2004-12-21 | 2006-07-06 | Nec Corporation | Fault tolerant system and controller, operation method, and operation program used in the fault tolerant system |
| CN101216792A (zh) * | 2008-01-14 | 2008-07-09 | 中兴通讯股份有限公司 | 实时操作系统的任务管理方法、装置及实时操作系统 |
| CN101377750A (zh) * | 2007-09-21 | 2009-03-04 | 中国科学院计算技术研究所 | 一种用于机群容错的系统和方法 |
| CN101833497A (zh) * | 2010-03-30 | 2010-09-15 | 山东高效能服务器和存储研究院 | 一种基于专家系统方法的计算机故障管理系统 |
| CN101923495A (zh) * | 2009-06-10 | 2010-12-22 | Tcl集团股份有限公司 | 一种嵌入式容错系统及其容错方法 |
| US20110138224A1 (en) * | 2009-12-09 | 2011-06-09 | Electronics And Telecommunications Research Institute | Method and system for tracepoint-based fault diagnosis and recovery |
-
2011
- 2011-09-19 CN CN201110277680.8A patent/CN102364448B/zh active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20060150004A1 (en) * | 2004-12-21 | 2006-07-06 | Nec Corporation | Fault tolerant system and controller, operation method, and operation program used in the fault tolerant system |
| CN101377750A (zh) * | 2007-09-21 | 2009-03-04 | 中国科学院计算技术研究所 | 一种用于机群容错的系统和方法 |
| CN101216792A (zh) * | 2008-01-14 | 2008-07-09 | 中兴通讯股份有限公司 | 实时操作系统的任务管理方法、装置及实时操作系统 |
| CN101923495A (zh) * | 2009-06-10 | 2010-12-22 | Tcl集团股份有限公司 | 一种嵌入式容错系统及其容错方法 |
| US20110138224A1 (en) * | 2009-12-09 | 2011-06-09 | Electronics And Telecommunications Research Institute | Method and system for tracepoint-based fault diagnosis and recovery |
| CN101833497A (zh) * | 2010-03-30 | 2010-09-15 | 山东高效能服务器和存储研究院 | 一种基于专家系统方法的计算机故障管理系统 |
Cited By (34)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102662831A (zh) * | 2012-03-20 | 2012-09-12 | 中国人民解放军国防科学技术大学 | 一种容错系统诊断策略优化方法 |
| CN102662831B (zh) * | 2012-03-20 | 2015-02-11 | 中国人民解放军国防科学技术大学 | 一种容错系统诊断策略优化方法 |
| CN103067740A (zh) * | 2012-12-31 | 2013-04-24 | 浙江元亨通信技术股份有限公司 | 视频监控设备故障智能检测方法及其检测系统 |
| CN103067740B (zh) * | 2012-12-31 | 2015-08-12 | 浙江元亨通信技术股份有限公司 | 视频监控设备故障智能检测方法及其检测系统 |
| CN103064770B (zh) * | 2013-01-08 | 2014-09-17 | 哈尔滨工程大学 | 双进程冗余瞬时故障容错方法 |
| CN103064770A (zh) * | 2013-01-08 | 2013-04-24 | 哈尔滨工程大学 | 双进程冗余瞬时故障容错方法 |
| CN105051692A (zh) * | 2013-01-09 | 2015-11-11 | 微软技术许可有限责任公司 | 通过隔离的自动化故障处理 |
| CN103197981A (zh) * | 2013-01-21 | 2013-07-10 | 浪潮(北京)电子信息产业有限公司 | 存储空间预警方法和系统 |
| CN103455393A (zh) * | 2013-09-25 | 2013-12-18 | 浪潮电子信息产业股份有限公司 | 一种基于进程冗余的容错系统设计方法 |
| CN103559124A (zh) * | 2013-10-24 | 2014-02-05 | 华为技术有限公司 | 故障快速检测方法及装置 |
| WO2015058711A1 (zh) * | 2013-10-24 | 2015-04-30 | 华为技术有限公司 | 故障快速检测方法及装置 |
| US10223183B2 (en) | 2013-10-24 | 2019-03-05 | Huawei Technologies Co., Ltd. | Rapid fault detection method and device |
| CN103559124B (zh) * | 2013-10-24 | 2017-04-12 | 华为技术有限公司 | 故障快速检测方法及装置 |
| CN103593251A (zh) * | 2013-11-07 | 2014-02-19 | 浪潮电子信息产业股份有限公司 | 一种基于进程冗余的容错系统及其设计方法 |
| CN103617094A (zh) * | 2013-12-18 | 2014-03-05 | 哈尔滨工业大学 | 多核处理器的瞬时故障容错系统 |
| CN104954002A (zh) * | 2014-03-26 | 2015-09-30 | 英飞凌科技股份有限公司 | 功率开关的受控关断 |
| CN104954002B (zh) * | 2014-03-26 | 2018-06-05 | 英飞凌科技股份有限公司 | 功率开关的受控关断 |
| CN103995759A (zh) * | 2014-05-21 | 2014-08-20 | 中国人民解放军国防科学技术大学 | 基于核内外协同的高可用计算机系统故障处理方法及装置 |
| CN105988885B (zh) * | 2015-03-26 | 2019-01-29 | 朱怡安 | 基于补偿回滚的操作系统故障自恢复方法 |
| CN105988885A (zh) * | 2015-03-26 | 2016-10-05 | 朱怡安 | 基于补偿回滚的操作系统故障自恢复方法 |
| CN105069052A (zh) * | 2015-07-24 | 2015-11-18 | 北京控制工程研究所 | 一种星载操作系统集成的故障快速自主处理方法 |
| CN105069052B (zh) * | 2015-07-24 | 2018-10-09 | 北京控制工程研究所 | 一种星载操作系统集成的故障快速自主处理方法 |
| CN105045917B (zh) * | 2015-08-20 | 2019-06-18 | 北京百度网讯科技有限公司 | 一种基于实例的分布式数据恢复方法和装置 |
| CN105045917A (zh) * | 2015-08-20 | 2015-11-11 | 北京百度网讯科技有限公司 | 一种基于实例的分布式数据恢复方法和装置 |
| CN105528276B (zh) * | 2015-12-09 | 2018-08-21 | 中国航空工业集团公司西安航空计算技术研究所 | 基于分区操作系统健康监控的模块支持层故障处理方法 |
| CN105528276A (zh) * | 2015-12-09 | 2016-04-27 | 中国航空工业集团公司西安航空计算技术研究所 | 基于分区操作系统健康监控的模块支持层故障处理方法 |
| CN106339297B (zh) * | 2016-09-14 | 2020-10-02 | 郑州云海信息技术有限公司 | 一种存储系统故障实时告警的方法及系统 |
| CN106339297A (zh) * | 2016-09-14 | 2017-01-18 | 郑州云海信息技术有限公司 | 一种存储系统故障实时告警的方法及系统 |
| CN106844082A (zh) * | 2017-01-18 | 2017-06-13 | 联想(北京)有限公司 | 处理器预测故障分析方法及装置 |
| CN106980555B (zh) * | 2017-03-24 | 2020-04-07 | 山东浪潮商用系统有限公司 | 一种超时线程处理方法及装置 |
| CN106980555A (zh) * | 2017-03-24 | 2017-07-25 | 山东浪潮商用系统有限公司 | 一种超时线程处理方法及装置 |
| CN108205479A (zh) * | 2017-10-25 | 2018-06-26 | 珠海市魅族科技有限公司 | 一种故障信息处理的方法、装置及存储介质 |
| CN111443624A (zh) * | 2019-01-17 | 2020-07-24 | 厦门地平线征程智能科技有限公司 | 车载设备及其检测方法 |
| CN111443624B (zh) * | 2019-01-17 | 2021-03-23 | 北京地平线机器人技术研发有限公司 | 车载设备及其检测方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN102364448B (zh) | 2014-01-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102364448B (zh) | 一种计算机故障管理系统的容错方法 | |
| US10152382B2 (en) | Method and system for monitoring virtual machine cluster | |
| CN110581852A (zh) | 一种高效型拟态防御系统及方法 | |
| CN106789306B (zh) | 通信设备软件故障检测收集恢复方法和系统 | |
| WO2016188100A1 (zh) | 信息系统故障场景信息收集方法及系统 | |
| CN103152414A (zh) | 一种基于云计算的高可用系统及其实现方法 | |
| CN105550012A (zh) | 一种自定义恢复故障虚拟机的方法 | |
| CN103678051B (zh) | 一种集群数据处理系统中的在线故障容错方法 | |
| CN1801107A (zh) | 数据恢复方法 | |
| CN101237315A (zh) | 一种用于双控高可用系统的同步检测和故障隔离方法 | |
| CN101556679A (zh) | 一种综合前端系统故障处理方法及计算机设备 | |
| US7886181B2 (en) | Failure recovery method in cluster system | |
| CN1794198A (zh) | 容错双工计算机系统及其控制方法 | |
| CN105589756A (zh) | 批处理集群系统以及方法 | |
| CN102404139A (zh) | 一种提高容错服务器应用层级容错性能的方法 | |
| JP5425720B2 (ja) | 仮想化環境監視装置とその監視方法およびプログラム | |
| CN109117317A (zh) | 一种集群故障恢复方法和相关装置 | |
| CN103902401A (zh) | 基于监控的虚拟机容错方法及装置 | |
| CN113147776A (zh) | 车辆用热备份故障处理系统、方法及采用其的车辆 | |
| CN103995759A (zh) | 基于核内外协同的高可用计算机系统故障处理方法及装置 | |
| CN114968129B (zh) | 磁盘阵列冗余方法、系统、计算机设备和存储介质 | |
| CN106528276A (zh) | 一种基于任务调度的故障处理方法 | |
| CN109144815A (zh) | 一种实时检测的计算机故障处理系统 | |
| CN115549751A (zh) | 遥感卫星地面站监控系统和方法 | |
| CN114598591A (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 |