CN102012850B - 基于硬件监视和微包协议的关键数据恢复方法 - Google Patents
基于硬件监视和微包协议的关键数据恢复方法 Download PDFInfo
- Publication number
- CN102012850B CN102012850B CN201010579850A CN201010579850A CN102012850B CN 102012850 B CN102012850 B CN 102012850B CN 201010579850 A CN201010579850 A CN 201010579850A CN 201010579850 A CN201010579850 A CN 201010579850A CN 102012850 B CN102012850 B CN 102012850B
- Authority
- CN
- China
- Prior art keywords
- data
- bag
- monitoring
- hardware
- piece
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
一种基于硬件监视和微包协议的三模冗余容错计算机***中的关键数据恢复方法,其特征在于:把需要恢复的关键数据分成大小相等的硬件数据块,再把硬件数据块划分成大小相同的监测包;同时在硬件上针对每个硬件数据块设置监视器,该监视器能监测的监测包数与每个硬件数据块划分的监测包数相等,一旦发现某监测包有更新或修改,则形成对该硬件数据块的数据区域重新传送的依据,重新传送数据时以包为单位进行以减少重新传送的数据量。
Description
技术领域
本发明涉及三模冗余容错计算机***中的关键数据恢复方法,尤其涉及基于硬件监视和微包协议的三模冗余容错计算机***中的关键数据恢复方法。
背景技术
三模冗余(TMR)容错计算机通常用于要求可靠性比较高的环境中,如果其中一台机器发生严重故障后,***降级为双级运行模式,在双机运行过程中恢复故障机器,并且在恢复过程中不中断***的正常运行,使***能够重新从双机运行模式恢复到三模运行状态,从而提高三模冗余容错计算机的可靠性与连续性。。对于可修复TMR容错***来说,恢复是实现容错***容错目的和提高***可靠性和可用性的重要环节,因此故障恢复对于研究三模冗余容错计算机来说是一项至关重要的技术,解决得好坏直接影响到三模冗余***的功能及运行操作的正确性。
而目前的故障恢复方法都是针对专门的具体应用。文献1(Nakamikawa T,Morita Y,Yamaguchi S.High Performance Fault Tolerant Computer and its Fault Recovery[J].1997 Pacific Rim International Symposium on Fault-Tolerant Systems,1997:2-6)给出了基于存储器双机窃取拷贝的恢复方案,可以不中断***运行,快速实现大量内存数据的传送,但需要复杂的硬件支持,更适合在双机***中进行实现。文献2(Yu Shu-Yi,McCluskey E J.On-line Testing and Recovery in TMR Systems for Real-Time Applictions[J].Test Conference Proceedings.International,2001,240-249)是一种部分恢复方案,在数据/输出表决时一旦检查到故障状态,立即对故障机器故障区域进行恢复,可实现对瞬态故障的状态恢复,但不适用于模块级恢复。文献3(李海山,欧中红,杨升春等.基于 COTS的容错服务器及其故障恢复技术[J].计算机工程,2007,33(8):253-255)提出的阶梯型恢复方法以进程为单位逐步恢复***到三模冗余状态。恢复过程中,***采用双机与三模混合运行,管理复杂,比较适合在三模冗余容错服务器中应用。
文献4(张伟功,朱晓燕,关永,等.基于微包协议的三模冗余容错计算机无缝重构方法[J].计算机科学,2009,(36)6:286-289)中提出的基于微包协议的恢复方法通过逻辑模块的优化设计,消除了单点故障模式,可以极大地提高***应用的可靠性与可信性。但是对于内存数据和当前状态的管理则是通过软件实现,主要有三方面的不足:首先,采用单向链表方式按更新频度对关键数据按队列进行管理,如果内存数据和机器运行状态有更新则需要用户通过调用软件程序通知TMR容错计算机的恢复程序,多数情况下用户会集中通知,否则需要在每一个程序分支中通知恢复程序,执行效率低;其次,对关键数据的监测是以单向链表上的链表块为单位,如果关键数据有更新,则对应的链表块数据的修改标志会重新置位,而用户的修改不可能局限在一个块内,也不可能整块数据都需要重新传送恢复,因此以软件方式实现的关键数据管理导致应用方便性和可监测性不足,监视粒度大;再次,原来的恢复方法只能利用周期任务的空闲时间,当空闲时间能够传送的数据量小于每个周期中用产更改量时有问题,不能进行无缝恢复。
发明内容
本发明旨在解决现有技术中存在的技术问题,尤其是上述文献4中存在的不足,使得在不中止***正常工作的情况下对***进行恢复,以保证三模冗余容错***正常运算与控制过程的连续性与一致性。
本发明为解决上述技术问题所采取的技术方案为:一种基于硬件监视和微包协议的三模冗余容错计算机***中的关键数据恢复方法,其特征在于:把需要恢复的关键数据分成大小相等的硬件数据块,再把硬件数据块划分成大小相同的监测包;同时在硬件上针对每个硬件数据块设置监视器,该监视器能监测的监测包数与每个硬件数据块划分的监测包数相等,一旦发现某监测包有更新或修改,则将代表该硬件数据块的数据区域需要被重新传送的标志位置位,重新传送数据时以监测包为单位进行以减少重新传送的数据量;监视器为每个硬件数据块配置四个寄存器:表示硬件块在整个监控内存区中的位置的块起始地址寄存器、用来决定监测那些包的块内监测包使能标志寄存器、用来记录数据修改的监测结果的块内监测包变化标志寄存器和在监测包被恢复时用来清除相应的包的修改标志的块内监测包修改标志清除寄存器,其中软件设计模块只负责把关键数据分成适当的协议微包通过同步串口传送给故障机器,所述软件设计模块建立一种基于单向有序链表结构和矩阵式监测的关键数据区管理方法,按照微包协议的数据容量、恢复通道数据传送速率、***任务周期与空闲时间大小、恢复缓冲区尺寸这些参数,将需要恢复的关键数据区在软件上划分为若干个连续或不连续的数据片,纵横排列组成关键数据矩阵,借鉴高速缓存命中比较方法,对每个硬件数据块的修改情况和恢复情况进行实时监测,按照关键数据区的链表顺序,对所有关键数据进行轮回查询与恢复,从而保证数据恢复的一致性。
本发明提出的上述技术方案克服了传统容错计算机在故障恢复方面的缺陷。
本发明的其他特征和效果将在下面结合附图的具体实施方式中详细说明。
附图说明
图1为本发明的基于硬件监视和微包协议的三模冗余容错计算机***中的关键数据恢复方法中的三模冗余容错计算机的***组成图;
图2为本发明的基于硬件监视和微包协议的三模冗余容错计算机***中的关键数据恢复方法中的关键数据区数据变化监测地址映射示意图。
图3为本发明的基于硬件监视和微包协议的三模冗余容错计算机***中的关键数据恢复方法中的链表结构图。
图4为本发明的基于硬件监视和微包协议的三模冗余容错计算机***中的关键数据恢复方法中的故障机器自恢复流程图。
图5为本发明的基于硬件监视和微包协议的三模冗余容错计算机***中的关键数据恢复方法中的正常机器恢复故障机器流程图。
具体实施方式
下面将结合附图描述本发明的基于硬件监视和微包协议的三模冗余容错计算机***中的关键数据恢复方法。
三模冗余容错计算机的***组成如图1所示。***由三个完全相同的高性能嵌入式计算机主板和一个输出表决模块组成,通过内置的紧耦合同步机制构成一个完全没有单点失效模式的面向嵌入式控制的三模冗 余计算机。其中CPU模块是计算机主板的核心组成部分,使用基于SPARC V8体系结构的32位微处理器BM3803MG,三个计算机主板上都集成了专门的同步模块和串行数据交换模块,各计算机主板之间相互完全独立,可以在同步模块的控制下对外部输入数据进行同步采集,独立完成控制运算,同步输出控制信号,最后通过表决模块输出到控制对象。其中三机同步模块与串行数据交换通道在同一块FPGA上实现。
***恢复的核心问题是将正常机器的内存数据与机器状态复制到故障机器上,使其能够恢复到与正常机器相同的状态。为了有效地利用***任务的空闲时间提高执行效率,并能够提供较强的***扩展能力,对无缝恢复关键数据方法进行改进,本发明采取的主要方法是:利用硬件上的设置监视关键数据区域的写操作,即:把需要恢复的关键数据分成大小相等的硬件数据块,在硬件数据块相等的基础上再把数据块划分成大小相同的监测包;同时在硬件上针对每个硬件块设置一种监视器,该监视器能监测的包数与每个硬件块划分的包数相等,这样可基于包尺寸进行监视,一旦发现某监测包数据有更新或修改,则形成对该块数据区域重新传送的依据,重新传送数据时以监测包为单位进行以减少重新传送的数据量。因为在机器运行过程中,对数据的更新可能只是某个硬件块中的一包或几包数据,有可能不会涉及到整个数据块,如果基于包尺寸进行监视的话,检测到有监测包被更新,那么只传送该包数据即可,不用重新传送整个数据块。
故障机器恢复的过程中是不能中断其它两个机器正常运行的,只能利用CPU的空闲时间恢复关键数据,如果恢复的数据量大,整个机器的恢复时间可能会延长。
总体来说是将恢复改由硬件完成,在监测数据变化和更新的过程,不需要软件参与管理关键数据的变化从而降低软件参与的要求,提高软件执行的效率,软件设计模块只负责把恢复数据分成适当的协议微包通过同步串口传送给故障机器。结合不同状态恢复的需要,制定一套具有扩展能力的恢复命令包协议,然后在此基础上研究一种无缝恢复的方法。
采用上述的无缝数据恢复方法后,将故障恢复过程分解为众多不连续的子过程穿插在***的空闲时间中执行,关键数据区也按照协议包的 数据容量分为若干个微包进行传送和恢复。当***空闲时间不足以将关键数据区的所有微包在一个空闲时间片中完全恢复时,就会发生关键数据区的微包恢复传送过程与***应用程序交替执行的情况。由于***应用程序执行过程中会对关键数据区中的部分数据进行修改,如不做特别处理,就会出现一部分已传送和恢复的数据会被应用程序修改,导致故障机器最终恢复的关键数据区的内部比较陈旧,与正常机器上的数据不一致,从而使恢复过程失败。如何对关键数据区进行有效管理,保证正常机器与故障机器数据的一致性成为上述无缝恢复方法必须研究的一个重要问题。
本发明根据计算机程序执行与访问的局部性理论,建立一种基于单向有序链表结构和矩阵式监测的关键数据区管理方法,按照微包协议的数据容量、恢复通道数据传送速率、***任务周期与空闲时间大小、恢复缓冲区尺寸这些参数,将需要恢复的关键数据区在软件上划分为若干个连续或不连续的数据片,纵横排列组成关键数据矩阵,借鉴CACHE(高速缓存)命中比较方法,对每个数据片的修改情况和恢复情况进行实时监测,根据恢复子过程的可重复性原理,按照关键数据区的链接顺序,对所有关键数据进行轮回查询与恢复,实现一种可收敛的增量式恢复,从而保证数据恢复的一致性。
为保证机器状态恢复的一致性,规定将***时间基准和I/O(输入/输出端口) 状态恢复工作安排在恢复过程的末尾,与关键数据区恢复的结束检查过程及***重同步过程一起组成一个不可中断的原子过程。
下面将具体描述本发明的方法的实现过程。
首先介绍***关键数据的硬件监视策略。
为了能够实时监测应用软件对关键数据区的访问情况,可以从硬件上设置一套关键数据区数据修改监测电路。如图2所示,将关键数据区划分为若干个(例如16个)连续或不连续的硬件数据块,每个块又分为若干个(例如为16个)连续的监测包。监测包大小为数据变化监测区域的粒度,即数据修改监测的最小分辨单位,其大小可以是一个微包的数据容量,也可以是多个微包容量的大小,监测包的大小例如为1KB,这样每个监测块的数据容量例如就是1KB*16=16KB,16个块一共可以监 测总大小为256KB的不连续内存区域。监测块的起始地址由应用软件在初始化时设置,为了管理方便,可以规定监测块的起始地址必须与块大小的边界对齐,即在16KB边界上对齐。这样的话,硬件就不需要保存和比较地址的低位部分,可以在实现过程中简化逻辑,节省资源,提高电路速度。
监测电路为每个硬件块各配置4个32位边界对齐的寄存器,如果硬件实现了多个数据块,则各块寄存器顺序排列。例如,当实现的数据块为16个时,本模块将包括64个寄存器,占用地址00~FC,第一个块的寄存器的地址是0、4、8、c,第二个块是10、14、18、1c,依次类推,第16块的寄存器地址是F0、F4、F8、FC。每个块的四个寄存器定义如下:
(1)块起始地址寄存器,指一个硬件块在整个监控内存区中的位置,块地址从位0开始。可以读写,复位后内容不确定。
(2)块内监测包使能标志寄存器,用来决定监测哪些包,每位对应一个监测包。可读写,复位后为全0。
(3)块内监测包变化标志寄存器,用来记录数据修改的监测结果,各位为1时,表示相应包对应的数据区域被改写过,只读,复位后为全0
(4)块内监测包修改标志清除寄存器,在监测包被恢复时,通过它来清除相应的包的修改标志,只写。
由于CPU数据宽度限制了硬件块监测包数量的地址位数。为了方便CPU对监视模块中监测包修改标志的访问,设计中限制每个硬件数据块中的监测包数量不能大于CPU的数据宽度。CPU通过一次读操作即可能取得一个数据块中所有监测包的修改标志,这样做的目的可以降低设计难度。另外CPU的数据宽度还会限制数据块起始地址的长度,即要求数据块的起始地址位数也不能大于CPU数据宽度。
在硬件设计上把所有的关键数据区看作是一个以块号为行、包号为列的监测矩阵。假设RAM区大小为18MB,每个块起始地址寄存器不仅包括12位起始地址,还包括一个地址匹配比较器(16个块的起始地址寄存器合在一起可以看作是一个输出为块编号的联相存储器)。当CPU对RAM存储器进行写操作时,存储器地址同时送给监测电路,监测电路将CPU的地址对应地划分为块地址、包地址和数据地址三个域。块地址域 送到每个块地址的地址匹配比较器,包地址则被送给一个译码器。如果某一监测块的块起始地址与CPU的块地址域相匹配,块地址比较器输出一个匹配块编号,然后以此匹配块编号作为地址,将包地址译码结果写入对应的块的包修改标志寄存器的相应位中;如果对应的包没有被使能(即不需要监测)或没有匹配块,则不启动包修改标志的写操作。图2给出了关键数据区数据更改监测过程的地址变换示意图。
下面说明***关键数据区管理及恢复方法。
首先介绍关键数据区链表结构。
关键数据区是指***恢复时需要在故障机器上恢复的那些内存区域,一般由全局变量、静态数据及任务堆栈等重要数据构成,可以是一个连续的内存区域,也可以是由多个内存数据块组成。我们在选择关键数据区时应尽量减少数据量,降低对三机数据交换速率的要求,有效减少***恢复时间。
在硬件设计中,把关键数据区域的数据划分成大小相等的硬件数据块。在软件设计模块中,将所有需要恢复的关键数据区组成一个有序的单向链表,链表上的每块数据量最大不超过每个硬件块数据的大小。在恢复关键数据时,以微包大小为单位传送,微包的大小可以根据需要改变,但必须小于等于监测包。用户可以通过固化函数库中的关键数据区管理函数向此单向链表中添加或删除关键数据,设置关键数据区时不需要受前述的硬件监测电路块、包结构及链表排序的限制,只需要提供起始地址与长度即可。管理函数会将用户设置区域自动对齐到硬件监测包的边界上,然后将其按地址从低到高的顺序***到单向链表结构中。在搜索各硬件数据块的块起始地址时,如果有匹配的地址,则将块中相应包的使能标志设为有效,否则按从低到高的顺序重新排列各硬件数据块的起始地址,并将当前设置的数据区的起始地址作为一个新块***到硬件数据块中。
单向链表中为每个链表数据块设置一个包括数据块地址范围、监测块号、监测包屏蔽字、包恢复标志(RF)、包长度剩余和包数等内容的数据块表项,如图3所示。
接着介绍关键数据区的管理。
关键数据区管理主要包括链表数据块的添加和删除。链表数据块的添加过程如下:首先判断要***的数据块大小是否超出硬件数据块的范围,如果超出则拆分为两块,依次类推,直到划分完毕为止,最多不超过硬件上规定的硬件数据块数;其次是将要***的数据块起始地址依次与链表上的数据块起始地址相比较,按照地址序列将数据块***链表中。如果当前链表数据块地址范围包含要***的数据块,则合并数据块。如果要***的数据块的地址范围介于链表中两个数据块之间则同时进行合并。如果没有重合的地址范围则与当前链表数据块的起始地址相比较,依次***到链表中即可。如果没有找到小于当前链表数据块的起始地址则直接***到链表末尾。
确定数据块在链表中的位置以后,要置相应的包屏蔽字。包屏蔽字是链表结构中的一个数据项,相当于一个32位的寄存器,有几个监测包数据就把包屏蔽寄存器相应位置1。由于在软件设计模块对每个链表数据块进行了合并排序,每个链表数据块的第一个监测包和最后一个监测包的大小有可能不等于硬件上规定的监测包的大小,因此在设置包屏蔽字时首先判断是不是第一个监测包和最后一个监测包,如果是则先置第一个监测包和最后一个监测包的包屏蔽字,再置其它的监测包屏蔽字,置包屏蔽字的过程中记录该链表数据块的监测包数,同时使包恢复标志(RF)等于包屏蔽字。
删除操作可以把链表上的数据块全部删除,也可以删除链表上的某个数据块。删除某个数据块的过程和添加数据块过程基本上是一样的,首先也是找到要删除的数据块在链表中的地址范围,如果介于两个数据块之间则要进行两次删除,删除完之后需要扫描链表上的数据块是否有需要合并的,如果有则进行合并。基本过程和添加数据块过程是一样的,这里不再赘述。
现在介绍***恢复方法。
硬件监视和单向链表式数据结构的软硬件设计使得容错计算机的故障恢复效率得到了极大提高,利用***任务的空闲周期将用户设置的关键数据恢复到故障机器中,把***恢复状态分为故障机器的自恢复和正 常机器恢复故障机器两个状态。
故障机器自恢复的流程如图4所示,故障机器进入故障恢复状态后,不停地检测是否收到其他两个正常机器的恢复微包,当收到一个微包后,首先检查是否恢复完成命令微包,如果是则设置三机同步模式,退出故障恢复状态,发送本机的同步请求,进入同步等待状态;其次若不是命令结束微包,故障机器要对左右机传送的微包进行正确性校验,若两个微包都正确则取故障值较小机器的微包,否则取正确机器的微包;若左右机的微包都不正确,向两个正常机器回送微包错误应答字。最后根据恢复类型字的判别恢复故障机器的故障表、内存数据或不归零计数器等。
正常机器恢复故障机器是指在***空闲态时发送正常机器的数据给故障机器,流程如图5所示。首先判断任务定时器的剩余时间是否足够传送一次微包数据,如果时间允许则先恢复故障表数据,再恢复内存数据。内存数据是按单向链表结构,逐块按监测包传送的。在数据恢复过程中,判断RF、块内数据变化标志寄存器和包屏蔽相与的结果,如果判断结果不为0则恢复该包数据,如果该包数据恢复完,则RF置为0,下次判断该包数据是否需要恢复时,再取三者相与的结果,如果为0就不需要再次恢复了。
其次,当链表中最后一个数据块被恢复完成后,恢复函数从链表开始处对每个数据块进行修改标志检查,若某一监测包的数据修改标志有效,重新启动对它的恢复过程。恢复完成后,继续检查其它监测包的修改标志,直到链表结尾,然后再重新检查。如果在一次检查过程中,链表中所有数据块对应的监测包的修改标志均无效,则说明关键数据区的恢复过程已完成,恢复函数启动恢复结束过程,因为同步过程会首先判断恢复完成标志,如果处于恢复完成状态,则重新升级为三机同步模式。然后再根据目前的同步模式调用对应的同步函数,使被恢复的机器进入重同步过程,***恢复为三机运行模式。
Claims (6)
1.一种基于硬件监视和微包协议的三模冗余容错计算机***中的关键数据恢复方法,其特征在于:把需要恢复的关键数据分成大小相等的硬件数据块,再把硬件数据块划分成大小相同的监测包;同时在硬件上针对每个硬件数据块设置监视器,该监视器能监测的监测包数与每个硬件数据块划分的监测包数相等,一旦发现某监测包有更新或修改,则将代表该硬件数据块的数据区域需要被重新传送的标志位置位,重新传送数据时以监测包为单位进行以减少重新传送的数据量;监视器为每个硬件数据块配置四个寄存器:表示硬件块在整个监控内存区中的位置的块起始地址寄存器、用来决定监测那些包的块内监测包使能标志寄存器、用来记录数据修改的监测结果的块内监测包变化标志寄存器和在监测包被恢复时用来清除相应的包的修改标志的块内监测包修改标志清除寄存器;其中软件设计模块只负责把关键数据分成适当的协议微包通过同步串口传送给故障机器,所述软件设计模块建立一种基于单向有序链表结构和矩阵式监测的关键数据区管理方法,按照微包协议的数据容量、恢复通道数据传送速率、***任务周期与空闲时间大小、恢复缓冲区尺寸这些参数,将需要恢复的关键数据区在软件上划分为若干个连续或不连续的数据片,纵横排列组成关键数据矩阵,借鉴高速缓存命中比较方法,对每个硬件数据块的修改情况和恢复情况进行实时监测,按照关键数据区的链表顺序,对所有关键数据进行轮回查询与恢复,从而保证数据恢复的一致性。
2.根据权利要求1所述的方法,其特征在于:为保证机器状态恢复的一致性,将***时间基准和输入/输出端口状态恢复工作安排在恢复过程的末尾,与关键数据区恢复的结束检查过程及***重同步过程一起组成一个不可中断的原子过程。
3.根据权利要求1所述的方法,其特征在于:所述单向有序链表由所有需要恢复的关键数据区组成,链表上的每块数据量最大不超过每个硬件块数据的大小;用户能够通过管理函数向此单向链表中添加或删除关键数据;设置关键数据区时只需要提供起始地址与长度,管理函数能将用户设置区域自动对齐到硬件监测的监测包的边界上,然后将其按地址从低到高的顺序***到单向链表结构中;在搜索各硬件数据块的块起始地址时,如果有匹配的地址,则将块中相应包的使能标志设为有效,否则按从低到高的顺序重新排列各硬件数据块的起始地址,并将当前设置的数据区的起始地址作为一个新块***到硬件数据块中。
4.根据权利要求3所述的方法,其特征在于:所述管理函数向单向链表中添加关键数据的过程如下:首先判断要***的数据块大小是否超出硬件数据块的范围,如果超出则拆分为两块,依次类推,直到划分完毕为止,数据块数量最多不超过硬件上规定的数据块数;其次是将要***的数据块起始地址依次与链表上的数据块起始地址相比较,按照地址序列将数据块***链表中;如果当前数据块地址范围包含要***的数据块,则合并数据块;如果要***的数据块的地址范围介于链表中两个数据块之间则同时进行合并;如果没有重合的地址范围则与当前数据块的起始地址相比较,依次***到链表中即可;如果没有找到小于当前数据块的起始地址则直接***到链表末尾。
5.根据权利要求4所述的方法,其特征在于:在确定数据块在链表中的位置以后,要置相应的包屏蔽字,包屏蔽字是链表结构中的一个数据项,有几包数据就把包屏蔽寄存器相应位置1;在设置包屏蔽字时首先判断是不是第一包数据和最后一包数据,如果是则先置第一包数据和最后一包数据的包屏蔽字,再置其它的包屏蔽字,置包屏蔽字的过程中记录该块数据的包数,同时使包恢复标志RF的值等于包屏蔽字。
6.根据权利要求5所述的方法,其特征在于:在数据恢复过程中,判断包恢复标志RF、块内数据变化标志寄存器和包屏蔽字相与的结果,如果判断结果不为0则恢复该包数据,如果该包数据恢复完,则包恢复标志RF置为0,下次判断该包数据是否需要恢复时,再取三者相与的结果,如果为0就不需要再次恢复了;当链表中最后一个数据块被恢复完成后,恢复函数从链表开始处对每个数据块进行修改标志检查,若某一监测包的数据修改标志有效,重新启动对它的恢复过程;恢复完成后,继续检查其它监测包的包恢复标志,直到链表结尾,然后再重新检查;如果在一次检查过程中,链表中所有数据块对应的监测包的修改标志均无效,则说明关键数据区的恢复过程已完成,恢复函数启动恢复结束过程,如果处于恢复完成状态,则重新升级为三机同步模式;然后再根据目前的同步模式调用对应的同步函数,使被恢复的机器进入重同步过程,***恢复为三机运行模式。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201010579850A CN102012850B (zh) | 2010-12-09 | 2010-12-09 | 基于硬件监视和微包协议的关键数据恢复方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201010579850A CN102012850B (zh) | 2010-12-09 | 2010-12-09 | 基于硬件监视和微包协议的关键数据恢复方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102012850A CN102012850A (zh) | 2011-04-13 |
CN102012850B true CN102012850B (zh) | 2012-09-12 |
Family
ID=43843026
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201010579850A Expired - Fee Related CN102012850B (zh) | 2010-12-09 | 2010-12-09 | 基于硬件监视和微包协议的关键数据恢复方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102012850B (zh) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102270162B (zh) * | 2011-07-29 | 2013-01-16 | 中国航天科技集团公司第五研究院第五一三研究所 | 一种应用于sparcv8结构计算机的容错引导方法 |
US8938430B2 (en) * | 2012-02-22 | 2015-01-20 | International Business Machines Corporation | Intelligent data archiving |
CN102761614A (zh) * | 2012-06-29 | 2012-10-31 | 浪潮(北京)电子信息产业有限公司 | 一种实现网络数据传输断点续传的方法及*** |
CN103399807B (zh) * | 2013-06-28 | 2015-03-25 | 中国航天科技集团公司第五研究院第五一三研究所 | 一种用于三模冗余计算机的动态现场自主恢复方法 |
CN107577614B (zh) * | 2013-06-29 | 2020-10-16 | 华为技术有限公司 | 数据写入方法及内存*** |
CN107590283B (zh) * | 2017-09-29 | 2019-12-24 | 浙江大华技术股份有限公司 | 一种文件回收方法、装置、服务器及计算机可读存储介质 |
US11176101B2 (en) * | 2018-02-05 | 2021-11-16 | Bank Of America Corporation | System and method for decentralized regulation and hierarchical control of blockchain architecture |
CN109274452B (zh) * | 2018-08-28 | 2020-02-18 | 宁波艾柏瑞信息技术有限公司 | 一种高速运算分析装置 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6732300B1 (en) * | 2000-02-18 | 2004-05-04 | Lev Freydel | Hybrid triple redundant computer system |
CN101441586B (zh) * | 2009-01-13 | 2010-06-02 | 首都师范大学 | 基于微包协议的三模冗余容错计算机无缝重构方法 |
-
2010
- 2010-12-09 CN CN201010579850A patent/CN102012850B/zh not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
CN102012850A (zh) | 2011-04-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102012850B (zh) | 基于硬件监视和微包协议的关键数据恢复方法 | |
Katta et al. | Ravana: Controller fault-tolerance in software-defined networking | |
CN101593136B (zh) | 使得计算机具有高可用性的方法和计算机*** | |
Cao et al. | The TickerTAIP parallel RAID architecture | |
US5968185A (en) | Transparent fault tolerant computer system | |
US8788879B2 (en) | Non-volatile memory for checkpoint storage | |
Sciascia et al. | Scalable deferred update replication | |
Alagappan et al. | Correlated crash vulnerabilities | |
CN105830040A (zh) | 用于访问存储器的存储器装置 | |
US20050240806A1 (en) | Diagnostic memory dump method in a redundant processor | |
CN101369241A (zh) | 一种机群容错***、装置及方法 | |
Hunt et al. | DDOS: taming nondeterminism in distributed systems | |
Sebepou et al. | Cec: Continuous eventual checkpointing for data stream processing operators | |
CN101937376A (zh) | 一种数据管理方法及数据存储装置 | |
CN108038201B (zh) | 一种数据整合***及其分布式数据整合*** | |
CN102521066A (zh) | 星载计算机空间环境事件容错方法 | |
De Florio | A Fault-Tolerance Linguistic Structure for Distributed Applications | |
CN101441586B (zh) | 基于微包协议的三模冗余容错计算机无缝重构方法 | |
CN106155943A (zh) | 一种双控存储设备的掉电保护的方法及装置 | |
US8639968B2 (en) | Computing system reliability | |
Alagappan et al. | {Fault-Tolerance}, Fast and Slow: Exploiting Failure Asynchrony in Distributed Systems | |
US8375188B1 (en) | Techniques for epoch pipelining | |
Bondavalli et al. | State restoration in a COTS-based N-modular architecture | |
Cores et al. | Failure avoidance in MPI applications using an application-level approach | |
Cornwell et al. | Efficient system-level remote checkpointing technique for blcr |
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 | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20120912 Termination date: 20191209 |
|
CF01 | Termination of patent right due to non-payment of annual fee |