CN102364448B - 一种计算机故障管理***的容错方法 - Google Patents
一种计算机故障管理***的容错方法 Download PDFInfo
- Publication number
- CN102364448B CN102364448B CN201110277680.8A CN201110277680A CN102364448B CN 102364448 B CN102364448 B CN 102364448B CN 201110277680 A CN201110277680 A CN 201110277680A CN 102364448 B CN102364448 B CN 102364448B
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims description 56
- 238000012545 processing Methods 0.000 claims abstract description 102
- 230000005540 biological transmission Effects 0.000 claims abstract description 47
- 230000008569 process Effects 0.000 claims description 39
- 238000001514 detection method Methods 0.000 claims description 35
- 230000007246 mechanism Effects 0.000 claims description 32
- 239000000306 component Substances 0.000 claims description 28
- 238000002955 isolation Methods 0.000 claims description 22
- 230000006870 function Effects 0.000 claims description 13
- 238000003745 diagnosis Methods 0.000 claims description 9
- 239000003795 chemical substances by application Substances 0.000 claims description 8
- 238000004891 communication Methods 0.000 claims description 8
- 238000011084 recovery Methods 0.000 claims description 7
- 230000009471 action Effects 0.000 claims description 6
- 239000008358 core component Substances 0.000 claims description 6
- 230000002452 interceptive effect Effects 0.000 claims description 6
- 238000012544 monitoring process Methods 0.000 claims description 5
- 238000013459 approach Methods 0.000 claims description 3
- 230000000903 blocking effect Effects 0.000 claims description 3
- 238000005538 encapsulation Methods 0.000 claims description 3
- 230000007257 malfunction Effects 0.000 claims description 3
- 230000026676 system process Effects 0.000 claims description 2
- 238000007726 management method Methods 0.000 description 163
- 238000013461 design Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000002159 abnormal effect Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000011069 regeneration method Methods 0.000 description 1
- 230000000246 remedial effect Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000004148 unit process Methods 0.000 description 1
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)和内核故障管理冗余单元8),内核故障管理核心单元含内核事件传输通道6)、内核故障处理模块7),其中:
内核故障管理核心单元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所述的方法,其特征在于,通过用户空间的故障管理核心单元1)、故障管理冗余单元2)、代理接收模块3)和代理发送模块4),包括错误检测模块(1)、事件分发模块(2)、诊断引擎模块(3)、故障处理模块(4)和检查点处理单元(5)收集***各组件的错误信息,生成标准错误事件发送给事件分发模块(2);事件分发模块将错误检测模块生成的标准错误事件交给诊断引擎模块处理;诊断引擎模块将标准错误事件进行归并,并根据错误事件的诊断规则诊断组件故障,预测组件可能产生的故障,生成标准故障事件交给事件分发模块;事件分发模块进一步将标准故障事件发送给故障处理模块,由其完成后续故障处理动作;
内核空间的内核故障管理核心单元5)收集***各组件的错误信息,将原始内核错误事件交给内核事件传输通道6);
内核事件传输通道6)判断原始内核错误事件类型,如果是紧急事件,则直接交给内核故障处理模块7)处理;如果是一般事件,则将原始内核错误事件发送给代理接收模块3);代理接收模块3)根据原始内核错误事件创建标准内核错误事件交给事件分发模块(2),进而完成用户空间一系列处理动作,最终将生成的标准内核故障事件由代理发送模块4)发送给内核事件传输通道)6;内核事件传输通道6)将标准内核故障事件交给内核故障处理模块7)处理;
容错工作流程如下:
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 CN102364448A (zh) | 2012-02-29 |
CN102364448B true 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) |
Families Citing this family (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102662831B (zh) * | 2012-03-20 | 2015-02-11 | 中国人民解放军国防科学技术大学 | 一种容错***诊断策略优化方法 |
CN103067740B (zh) * | 2012-12-31 | 2015-08-12 | 浙江元亨通信技术股份有限公司 | 视频监控设备故障智能检测方法及其检测*** |
CN103064770B (zh) * | 2013-01-08 | 2014-09-17 | 哈尔滨工程大学 | 双进程冗余瞬时故障容错方法 |
US20140195672A1 (en) * | 2013-01-09 | 2014-07-10 | Microsoft Corporation | Automated failure handling through isolation |
CN103197981B (zh) * | 2013-01-21 | 2016-02-03 | 浪潮(北京)电子信息产业有限公司 | 存储空间预警方法和*** |
CN103455393A (zh) * | 2013-09-25 | 2013-12-18 | 浪潮电子信息产业股份有限公司 | 一种基于进程冗余的容错***设计方法 |
CN103559124B (zh) * | 2013-10-24 | 2017-04-12 | 华为技术有限公司 | 故障快速检测方法及装置 |
CN103593251A (zh) * | 2013-11-07 | 2014-02-19 | 浪潮电子信息产业股份有限公司 | 一种基于进程冗余的容错***及其设计方法 |
CN103617094A (zh) * | 2013-12-18 | 2014-03-05 | 哈尔滨工业大学 | 多核处理器的瞬时故障容错*** |
US9640972B2 (en) * | 2014-03-26 | 2017-05-02 | Infineon Technologies Ag | Controlled switch-off of a power switch |
CN103995759B (zh) * | 2014-05-21 | 2015-04-29 | 中国人民解放军国防科学技术大学 | 基于核内外协同的高可用计算机***故障处理方法及装置 |
CN105988885B (zh) * | 2015-03-26 | 2019-01-29 | 朱怡安 | 基于补偿回滚的操作***故障自恢复方法 |
CN105069052B (zh) * | 2015-07-24 | 2018-10-09 | 北京控制工程研究所 | 一种星载操作***集成的故障快速自主处理方法 |
CN105045917B (zh) * | 2015-08-20 | 2019-06-18 | 北京百度网讯科技有限公司 | 一种基于实例的分布式数据恢复方法和装置 |
CN105528276B (zh) * | 2015-12-09 | 2018-08-21 | 中国航空工业集团公司西安航空计算技术研究所 | 基于分区操作***健康监控的模块支持层故障处理方法 |
CN106339297B (zh) * | 2016-09-14 | 2020-10-02 | 郑州云海信息技术有限公司 | 一种存储***故障实时告警的方法及*** |
CN106844082A (zh) * | 2017-01-18 | 2017-06-13 | 联想(北京)有限公司 | 处理器预测故障分析方法及装置 |
CN106980555B (zh) * | 2017-03-24 | 2020-04-07 | 山东浪潮商用***有限公司 | 一种超时线程处理方法及装置 |
CN108205479A (zh) * | 2017-10-25 | 2018-06-26 | 珠海市魅族科技有限公司 | 一种故障信息处理的方法、装置及存储介质 |
CN111443624B (zh) * | 2019-01-17 | 2021-03-23 | 北京地平线机器人技术研发有限公司 | 车载设备及其检测方法 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
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集团股份有限公司 | 一种嵌入式容错***及其容错方法 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006178616A (ja) * | 2004-12-21 | 2006-07-06 | Nec Corp | フォールトトレラントシステム、これで用いる制御装置、動作方法、及び動作プログラム |
KR101331935B1 (ko) * | 2009-12-09 | 2013-11-21 | 한국전자통신연구원 | 추적점 기반의 고장 진단/복구 시스템 및 그 방법 |
-
2011
- 2011-09-19 CN CN201110277680.8A patent/CN102364448B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
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集团股份有限公司 | 一种嵌入式容错***及其容错方法 |
CN101833497A (zh) * | 2010-03-30 | 2010-09-15 | 山东高效能服务器和存储研究院 | 一种基于专家***方法的计算机故障管理*** |
Also Published As
Publication number | Publication date |
---|---|
CN102364448A (zh) | 2012-02-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102364448B (zh) | 一种计算机故障管理***的容错方法 | |
KR101888029B1 (ko) | 가상 머신 클러스터 모니터링 방법 및 모니터링 시스템 | |
CN101833497B (zh) | 一种基于专家***方法的计算机故障管理*** | |
US20080115012A1 (en) | Method and infrastructure for detecting and/or servicing a failing/failed operating system instance | |
EP2518627B1 (en) | Partial fault processing method in computer system | |
US9104644B2 (en) | Operating method of software fault-tolerant handling system | |
CN100394394C (zh) | 容错双工计算机***及其控制方法 | |
CN103370693A (zh) | 重启进程 | |
CN103370694A (zh) | 重启数据处理*** | |
CN103678051B (zh) | 一种集群数据处理***中的在线故障容错方法 | |
CN107506261B (zh) | 适应cpu、gpu异构集群的级联容错处理方法 | |
CN102404139B (zh) | 一种提高容错服务器应用层级容错性能的方法 | |
Lyu et al. | Software fault tolerance in a clustered architecture: Techniques and reliability modeling | |
CN106844082A (zh) | 处理器预测故障分析方法及装置 | |
JP2012003651A (ja) | 仮想化環境監視装置とその監視方法およびプログラム | |
CN109117317A (zh) | 一种集群故障恢复方法和相关装置 | |
CN112631981A (zh) | 一种模拟训练可靠容错仿真引擎 | |
Becker et al. | A practical approach to failure mode, effects and criticality analysis (FMECA) for computing systems | |
CN103995759A (zh) | 基于核内外协同的高可用计算机***故障处理方法及装置 | |
Mouallem et al. | A fault-tolerance architecture for kepler-based distributed scientific workflows | |
CN106528276A (zh) | 一种基于任务调度的故障处理方法 | |
CN114968129A (zh) | 磁盘阵列冗余方法、***、计算机设备和存储介质 | |
CN109144815A (zh) | 一种实时检测的计算机故障处理*** | |
JP2015106226A (ja) | 二重化システム | |
CN103150236A (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 |