容错机制（通用10篇）
容错机制 篇1
多核处理器和多核集群已经成为市场的主流,但串行编程无法从多核架构中直接获益,并行编程成为必然的选择。传统的openMP和MPI是被广泛使用的并行编程接口,分别对应共享存储和分布式系统,但这两者的抽象度依然不高,没有从根本上将用户从并行实现的细节中解放出来。同时,熟练掌握并应用复杂的编译制导命令与消息传递接口所耗精力与时间也使得并行编程效率不能满足应用增长的需求。
MapReduce是Google开发的一种简洁抽象的分布式计算模型,其目标是使那些没有多少并行编程经验的程序员能够尽可能快地开发并行应用。在MapReduce框架中,每一次计算请求,被称为作业。在分布式计算Map/Reduce框架中,为了完成这个作业,它进行两步走的战略,首先是将其拆分成若干个Map任务,分配到不同的机器上去执行,每一个Map任务拿输入文件的一部分作为自己的输入,经过一些计算,生成某种格式的中间文件,这种格式必须与最终所需的文件格式完全一致,但是仅仅包含一部分数据。等到所有Map任务完成后,它会进入下一个步骤,用以合并这些中间文件获得最后的输出文件。此时,系统会生成若干个Reduce任务,同样也是分配到不同的机器去执行,它的目标就是将若干个Map任务生成的中间文件汇总到最后的输出文件中去。经过如上步骤,所需的目标文件生成。整个算法的关键,就在于增加了一个中间文件生成的流程,大大提高了灵活性,使其分布式扩展性得到了保证。
1. 基本框架
与分布式文件系统类似,Map/Reduce的集群同样由三类服务器构成。其中作业服务器负责管理运行在此框架下所有作业。与HDFS的主控服务器类似,它也是作为单点存在,从而简化了负责的同步流程。具体的负责执行用户定义操作的是任务服务器,每一个作业被拆分成很多的任务,包括Map任务和Reduce任务等,任务是具体执行的基本单元,它们都需要分配到合适任务服务器上去执行,任务服务器一边执行一边向作业服务器汇报各个任务的状态,以此来帮助作业服务器了解作业执行的整体情况,分配新的任务等。
除了作业的管理者执行者,还需要有一个任务的提交者,这就是客户端。与分布式文件系统一样,客户端也不是一个单独的进程,而是一组API,用户需要自定义好自己需要的内容,经由客户端相关的代码,将作业及其相关内容和配置,提交到作业服务器去,并时刻监控执行的状况。
与HDFS的通信机制相同,Map/Reduce也是用了协议接口来进行服务器间的交流。实现者作为RPC服务器,调用者经由RPC的代理进行调用,如此,完成大部分的通信,具体服务器的架构,和其中运行的各个协议状况,参见上图。
从图中可以看到,与HDFS相比,相关的协议减少,客户端与任务服务器,任务服务器之间,都不再有直接通信关系。这并不意味着客户端就不需要了解具体任务的执行状况,也不意味着任务服务器之间不需要了解别家任务执行的情形,而是由于整个集群各机器的联系比HDFS复杂得多,直接通信难以维系,所以都统一由作业服务器整理转发。
2. MapReduce编程模型调度机制
(1) master选择空闲的worker,然后分配给他们每个一个map任务或者一个reduce任务。
(2) map阶段:map worker从输入数据中解析key/value对,传给用户定义的Map函数产生中间key/value对,然后将中间key/value对写入本地磁盘并将其散布在由分割函数指定的R个区域中,最后将这些缓存对在局部磁盘的具体位置传回给master。
(3) reduce阶段:reduce worker先从master得到中间key/value对在map worker局部磁盘上的位置信息,并使用远程过程调用从map worker的局部磁盘中读取数据。读取完所有数据之后,reduceworker按照中间key进行排序,reduce worker遍历排好序的中间数据,将把key和与它对应的中间value传给用户提供的Reduce函数,最后将Reduce函数的输出写到与这个reduce对应的最终输出文件中。
(4)当所有的map和reduce任务被完成之后,master唤醒用户程序,MapReduce调用返回到用户代码。
3. MapReduce采用的容错机制
MapReduce模型具有很强的容错性,当worker节点出现错误时,只需要将该worker节点屏蔽在系统外等待修复,并将该worker上执行的程序迁移到其他worker上重新执行,同时将该迁移信息通过Master发送给需要该节点处理结果的节点。MapReduce使用检查点的方式来处理Master出错失败的问题,当Master出现错误时,可以根据最近的一个检查点重新选择一个节点作为Master并由此检查点位置继续运行。
Master周期性的ping各个worker,检测worker的状态。当一段时间之后没有响应,master将认为worker已经出现故障。在该worker上正在处理的map或reduce任务将被设置为空闲状态,以便重新调度。完成的map任务需要重新执行,那是因为它们的输出是存储在出现故障机器上的本地磁盘,而导致不可访问。完成的reduce任务输出结果是存储在全局文件系统而不存在这个问题。
4. 结束语
MapReduce作为一种较为流行的云计算编程模型,在云计算系统中应用广阔。但是基于它的开发工具Hadoop并不完善。特别是其调度算法过于简单,判断需要进行推测执行的任务的算法造成过多任务需要推测执行,降低了整个系统的性能。改进Map2Reduce的开发工具,包括任务调度器、底层数据存储系统、输入数据切分、监控“云”系统等方面是将来一段时间的主要发展方向。另外,将MapReduce的思想运用在云计算以外的其他方面也是一个流行的研究方向。
容错机制 篇2
来源:四川日报 【字体：大中小】
分享到：
新闻由头
据四川日报报道，近日，我省广元、眉山、德阳等地相继出台了“支持改革创新容错纠错办法”，这是容错机制在我省的首批实施，目的是给愿干事、敢干事、能干成事的干部以“试错权”。消息刊登后引发各界关注。
容错机制是改革创新的护身符
评论员周明华
自古以来，不少人深谙中庸之道，坚信木秀于林，风必摧之，不管干啥事都不能太冒，不当出头鸟。一些地方还流行着一种“洗碗效应”，辛苦的洗碗工，一直埋头洗碗，小心翼翼，有朝一日，不小心摔碎一个碗，一旁的管理者便会恼羞成怒，横眉瞪眼：你咋这么不小心？干什么吃的？扣你绩效不说，若有情绪，还可能丢掉工作，卷被盖走人。
这有阻于改革向纵深推进，特别是在大众创业万众创新的背景下，如此事事谨慎终将会被时代淘汰掉。一些干部心中总有个“怕”字，怕犯错、怕出头、怕被批评。思想保守、不思进取，宁愿碌碌无为，也不愿甩开膀子大干一场；“你上坡我上坡，圈圈一样多，你干啥我干啥，圈圈一样大”；两只眼睛睁得圆又大，双手插进裤兜，抖腿观望，反正“你洗碗、我察看”，甘当“维持会长”。
总书记强调，“我们做人一世，为官一任，要有肝胆，要有担当精神，应该对„为官不为‟感到羞耻。”很久以前，曾国藩也说过，“以苟活为羞，以避事为耻。”对于领导干部来说，怕出事而躲开事，属为官之耻。“不敢为、不作为”实质是担当不足，怕被追责；虽不犯错，实际上却是一种庸政懒政的隐性表现，造成行政资源的白白浪费。而探索建立容错机制，通过制度化设计，明确敢作为与乱作为的具体情形和政策界限，从而使勇于创新探索者卸下包袱、轻装上阵，面对改革攻坚艰巨任务，能迈得开步子、甩得开膀子，同时也利于在全社会营造鼓励创新、宽容失败的浓厚氛围。
宋代名臣范仲淹有一句名言“公罪不可无，私罪不可有”。意思是出于公心，为天地立新，为百姓立命，所犯错误，只要不是大错、没造成大的损失是应当被谅解的。一个人一生做事，不可能件件都不出差错。况且就改革创新而言，本没有轻易可寻、天然生成的路子，要踩出新路就可能走错、也需要试踏。我们允许试错，实则是为更多干部敢于作为、先行先试创造良好的政策环境和舆论空间。
改革创新的布局和推进，颇似下一盘错综复杂、厮杀激烈的围棋，形势的驾驭、棋形的死活、力量的消长，往往取决于我们能否做出两个“眼”。其中一个关键“眼位”，便是“创新”。当前，改革挺进深水区，困难和矛盾叠加。敢闯新路者本身就需要一种勇气和担当，如果一足踩空，呛个半死，再被拖上来打板子、羞面子、丢位子，谁还会愿意去开拓创新？事实证明，给干部最大的支持是“容错”。对那些长期冲在改革发展一线的干部来说，容错机制为他们安心工作、踏实干事吃了一粒“定心丸”、加了一道“护身符”；对于大胆改革、勇于担当的干部来说，则增添了一份敢做善为的底气和信心。
警惕容错机制为不法行为买单
评论员邓也
为了给改革创新者撑腰壮胆，近年来，全国多地相继探索建立容错免责机制，给干部一定的“试错权”。可以肯定的是，“试错权”能一定程度破解为官不为现象，但如何防止其被滥用，成为少数干部违法违纪的“挡箭牌”，也是值得深思的课题。这也是容错机制中必须考虑的“不能容”的命题。毕竟，只有宽严相济、惩护并举的制度，才能甄别和保护真正有为的改革者，让干事创业迸发出新动力。
凡事总得有个度，容错免责也要有前提。需要警惕的是，有人借改革之机踩党纪红线、闯法律禁区，自诩为“闯将”，结果冒进犯错反而成了其改革魄力与能力的“标签”；也有人装模作样，以改革之名行拖延之实，心存杂念、以权谋私，延误改革发展先机。这些借容错机制充当护身符的现象不容小觑，小则延误发展、重则为害一方，必须严厉追责。说到底，容错免责的落脚点必须是干事创业，价值取向必须是为国为民，决策过程必须是合乎规范，决不允许以改革为名牟取私利、恣意妄为。正所谓识错辨错，应容为公之失，不赦为私之罪。
容错免责必须要有基本底线。“容”的是真正意义上改革创新中发生的探索性失误，“免”的是勇创改革深水区的“失误”之责。这些改革创新的出发点必须符合广大群众的利益诉求，符合科学民主的决策程序，有明确的现实针对性。也就是说，对一名干部而言，能不能容错、该不该容错，关键要看目的、方向，看其出发点是否为了改革发展，其行为是否触犯了“三条线”——道德底线、法律红线、党纪高压线。因此，在实施容错机制的过程中，必须明确界定“公错”和“私罪”的界限，把犯错和违法乱纪区别开来。
容错免责之后要紧跟纠错改错。建立容错免责机制的目的，是为了解决问题，更好地推动改革发展，不能搞“一容了之”，知错不改。纠错不是为了追究责任，而是当错误初见端倪时，及时纠正改正，避免放任错误扩大，造成不可挽回的损失。这也是对干部最好的关心爱护。因此，建立容错免责机制的同时，要建立完善配套的纠错改错机制，正确处理好纠错改错与责任追究的关系，既体现对干部责任担当的保护，又通过经验教训的总结，督促干部找准问题、剖析原因、找出解决办法。特别是要减少决策失误，充分发扬民主集中制，坚持一切从实际出发，坚持问计于基层、问计于群众，搞好科学论证，避免再犯类似错误。
容错机制须向基层一线倾斜
□张雨
“上面千条线，下面一根针”，“四个全面”战略布局，“十三五”规划战役部署，四川省委关于全面创新改革驱动转型发展的决定，都要靠基层干部去贯彻落实。如今，全面建成小康社会进入最后五年倒计时，各项改革事业进入攻坚期，任务重、难度大，风险也随之加大。
于此背景下，基层干部要干事就免不了出错。更何况，一些探索的对错，要由实践、时间去检验。不允许犯错，或一有小错，就被揪住不放，那么只会阻止探索创新。建立容错机制，就是要给干部、尤其是基层干部以“试错权”，旗帜鲜明地鼓励和保护改革创新的干部，使他们成为勇于拼搏的实干者。
容许犯错一直在说，为何仍有极少数基层干部怕干事、怕出事？其中的重要原因之一，是容错一直停留在口头上，没有形成有效的保障机制。哪些错容许，容许到什么程度，上下都不明确；一些错以前容许，后来又不容许了；甲地容许，乙地又不容许……难免让人无所适从。
只有将容错形成机制，明确容许的界限、尺度、标准，以及一系列申报、受理、核实、审定、报备等程序，才能在新常态下，为基层干部敢想敢干进行制度性兜底，使其勇于上阵、大胆开拓、少些顾虑。
网友跟评
粉笔小龙：不作为根本上是领导干部责任担当意识不够，但是实际中针对干部行为的舆论环境也不够宽松。稍有差池，大有“口诛笔伐”之势，想起来都怕怕哟。要真正鼓励创新有为，就要有制度保障的创新空间。
重庆立法者回应“容错机制”质疑 篇3
这次，是缘于重庆为促进内陆开放而创建容错机制的立法尝试。
重庆市人大常委会审议通过的《重庆市促进开放条例》1月1日正式施行。这是全国首部旨在促进开放的地方性法规，因而格外受到关注。而引发争议的是，开放条例中的容错机制明确规定：开放工作发生失误，未达到预期效果，或者造成一定损失，但符合以下三个条件的，可以减轻或者免除有关人员的责任：一、工作措施的制定和实施程序符合有关规定；二、个人和所在单位没有牟取私利；三、未与其他单位或者个人恶意串通，损害公共利益。
对此，赞许者说，此举能保障“创新者无罪”，从而推动改革创新，而质疑者认为容错机制会助长拍脑袋决策和资源浪费。
“有了这个地方‘王法’，重庆的各级政府还有什么不敢想的?还有什么不敢做的?真为重庆的老百姓捏着一大把汗哦!”一位网友说。
究竟重庆的这一做法出于何种想法?立法者又如何看待这些质疑?《瞭望东方周刊》记者近日独家专访了重庆市人大财经委员会副主任委员罗先成。
使“领头羊”不成为“替罪羊”
《瞭望东方周刊》：重庆为什么要以立法形式建立容错机制?
罗先成：为给重庆扩大开放、建设内陆开放型经济提供良好的法治环境，重庆市人大常委会2008年3月启动了促进开放的地方立法工作。 容错机制的设立，重庆借鉴了深圳、西安立法探索的成果。深圳在2006年出台的《深圳经济特区改革创新促进条例》明确规定了三种改革创新工作未达到预期效果的免责条款。
实际上，在促进开放立法、建立容错机制的背后，是重庆深入改革发展中遇到的“难言之隐”。
重庆和成都成为全国统筹城乡发展综合配套改革实验区后，重庆在开展城乡统筹改革的探索中面临的严峻问题在于，很多改革一旦施行会与现行国家法律法规有碰撞，一些基层干部认为改革难度大，产生了畏难情绪，不敢去闯去试，而一些开始探索改革的基层干部又在中央有关部门严格执行法律法规的执法检查中受到批评，从而改革的积极性受到影响。
《瞭望东方周刊》：也就是说，容错机制的设置是为了消除改革者的顾虑，使他们敢于创新?
罗先成：是的。重庆制定开放条例时正值我国改革开放30周年之际，回顾30年历程，是一个制度碰撞的过程，新制度对旧制度进行变革。30年来，改革开放中敢干敢闯的人中有不少承担了责任，为改革开放付出了成本，过去很多人只看到为改革付出的物质成本，而往往忽视了一些人为改革付出的个人命运成本。
而如今进一步改革开放面对的国际国内形势更加复杂、社会转型期的矛盾更加突出，改革开放的风险性、困难性、复杂性加剧。要开放就必然涉及改革创新，但“大胆地吃螃蟹”就有可能犯错。重庆开放立法特别设置容错机制就是为免除创新者的后顾之忧，保护开放工作的积极性，鼓励大胆探索。
建立容错机制就是为了保证开放创新的“领头羊”不成为“替罪羊”，激励官员“大胆地闯，大胆地试”，通过容错机制去保障“创新者无罪”。宽容失败正是鼓励大胆改革创新，因而保留这项制度是十分必要的。
重庆制定开放条例就是向全社会传递出一种积极的信号，向世人、重庆各级干部昭示重庆改革开放的坚定决心。深圳改革创新促进条例出台至今，免责条例还没有实施一次，可见容错机制的意义不在条文本身，而是坚定改革开放的决心。
防止“决策时拍脑袋，执行时拍胸脯，失误时拍屁股”
《瞭望东方周刊》：据世界银行的估计，“七五”到“九五”期间，我国投资决策失误率在30％左右，资金浪费及经济损失大约在4000亿～5000亿元。一些质疑者担心，容错机制会加剧拍脑袋决策和资源浪费，对此，你怎么看?
罗先成：在立法过程中，重庆充分考虑了这一情况，对在开放工作中出现的决策失误责任适用“容错”时，充分吸纳了民意，相关条款对“容错”范围作了明确限制，为预防腐败设立了“防火墙”。而政府具体决策投资行为发生失误不属于“容错”范围。
此外，为了规范政府的决策行为，强化决策责任，减少决策失误，保证决策质量，重庆市政府早在2005年便制定了《重庆市政府重大决策程序规定》，从源头上防止“决策时拍脑袋、执行时拍胸脯、失误时拍屁股”的“三拍”现象。这是我国第一个规范政府重大决策程序的政府令，主要约束行政首长的决策行为，决策失误的依照该规定将问责行政首长。
《瞭望东方周刊》：在中央4万亿刺激经济方案的背景下，各地政府“跑步前进”争抢项目，如住房和城乡建设部五天内便收到500多宗各地提交兴建污水处理厂的立项申请，历来罕见。但有专家指出，目前内地已建好的1400座污水处理厂中，有一半在“晒太阳”。此时，重庆建立容错机制会不会让有些干部借开放之名行“瞎折腾”之实?
罗先成：与此相比，在我看来，目前一些地方政府部门和官员无所作为，“干的不如看的”，“一慢二看三通过”，死气沉沉、活力不够的情况，才是阻碍深化改革开放的更主要影响因素。因此，你说的情况要尽力避免，但创新更需要鼓励。
《瞭望东方周刊》：容错机制应是行政问责制的补充机制，在全国尚未建立完善的行政问责制背景下，重庆建容错机制是否太过超前?
罗先成：重庆2004年在全国率先建立行政首长问责制，先后启动50次，98名官员受到问责，在解决官员“情政”和“怠政”上取得很好效果。而2008年以襄汾溃坝事故和三鹿问题奶粉事件为标志，我国“问责风暴”显现出鲜明的特色，问责范围之广、问责级别之高为近年来所罕见。我国行政问责的制度建设也走上新高度。重庆的容错机制是与行政问责制、重大决策程序规范等一系列制度配合实施的。
当然，社会上对容错机制的争议，我们也会全面客观地面对，真理越争越明，社会上的争议也让我们今后更加审慎地执行容错机制。
罚款要“打开天窗说亮话”
《瞭望东方周刊》：《重庆市促进开放条例》共49条，涵盖了许多方面，但是单单容错机制这一条引起如此广泛的争议，以至于大家都忽略了其他方面的内容，你如何总结条例的其他突破之处?它还在哪些方面鼓励了开放?
罗先成：我觉得比较大的突破是《条例》从加强开放制度建设出发，对改善政务环境作了非常具体的规定。
《条例》把监督政府服务态度上升到地方性法规层面，对政府部门服务方面作出很多细节上的规定。比如到政府某部门办证，第一次去被告知缺某个材料，第二次去又被告知还差其他材料。在以前，企业或市民遇到这种情况顶多就是投诉，而工作人员最多就是因态度不好而受批评了事。这部条例正式通过实施后，再出现上述情况，政府部门工作人员就是违法了，将被追究法律责任。
在行政执法方面，《条例》对法律、法规和规章规定的行政处罚自由裁量权进行了细化，并公布实施，压缩行政处罚自由裁量空间，从源头上防止滥用行政处罚自由裁量权。
容错机制 篇4
机载雷达作为航空电子设备的关键组成部分, 需要满足高可靠性的要求。将系统错误产生的影响降至最低、实现容错的运行机制至关重要。构建容错系统最基本的思想是设置冗余。目前诸多的容错技术通过硬件冗余、软件冗余、信息冗余中的一种或几种来实现错误的检测恢复[1⁃2]。其中一些容错方法具有通用性。如检查点回卷恢复容错方法能够处理绝大多数软硬件暂时性失效导致的错误, 硬件多机冗余方法能解决硬件永久失效的问题[3]。
机载雷达的用途和应用环境决定了其应满足实时性高和体积小的要求, 因此机载雷达系统多构建在分布嵌入式环境下。分布嵌入式环境复杂的软硬件结构使得机载雷达产生的错误具有多样性, 各类错误出现的位置、对系统功能的影响以及影响的严重性各不相同。尽管一些容错方法适用于较多类型的错误处理。然而对出现在不同位置、不同种类的错误采用同一种容错方法是不适当的。因为通用的容错方法的开销相对较大, 对于某些类型的错误不是最优的容错选择, 会增加不必要的容错开销。本文针对机载雷达系统的特点提出一种多层划分的容错体系结构, 致力于减小为原系统实现容错机制所产生的开销, 对于提高雷达可靠性的同时保证雷达的工作性能具有重要意义。在多层划分的容错体系结构下, 需要实现一种能够准确诊断错误、隔离错误、进行重新配置并恢复系统预定状态的方法。为此设计了一种分布式冗余管理协议来实现错误的诊断和隔离, 在确定故障节点的情况下管理冗余接替并进行拓扑重构。考虑到硬件冗余的容错方法具有较高的成本及机载空间占用, 结合低卷回代价的检查点回卷恢复软件容错手段能够平衡系统容错在时间与空间方面的开销。
1 多层划分容错结构
机载雷达系统由天线、发射机、接收机、处理机及它们之间的接口、传输与控制总线构成。各分机功能正常运行以及分机之间协同有序的工作保证了雷达系统的正常运行。容错系统的构建可视为在原系统的基础上实现错误检测机制和一系列错误处理机制的过程。雷达系统可能发生错误的类型、位置、粒度以及对系统功能影响的严重程度多种多样, 针对同一种错误通常有多种错误处理机制能够实现针对该类型错误的容错, 然而采取不同错误处理机制的代价也是不同的。尽管一些容错技术具有通用性, 适用于较多类型的错误处理。然而通用的容错方法的开销相对较大, 对于某些类型的错误不是最优的容错选择, 会增加不必要的容错开销。本文根据容错机制实现的位置将机载雷达容错系统分为三个层次:芯片电路层、节点层和系统层。每个层次都会针对相应的软硬件环境和粒度实现相应层次的故障诊断、故障隔离、重新配置以及状态的复位或恢复。
在设计容错系统时, 首先将系统的容错需求分解到各层次;然后每个层次根据分解的容错需求汇总需处理的故障类型, 并为之设置相应的故障处理方式;最后以每层故障处理结果是否能够满足整个系统的容错需求为评价标准, 设置各层的故障处理结果信息。由于多层划分容错设计追求容错代价的最小化, 系统在实现容错目标的前提下更倾向于在较低的层次解决故障, 因此容错的过程是自底向上的。故障处理结果信息以
多层划分的容错体系结构如图1所示, 其清晰而易维护, 针对容错需求设计的故障处理方式贯穿雷达系统的每一层次。且呈现了多层划分容错系统在每一层可能处理的部分错误类型以及错误处理的结果。低层上报的未解决故障将同相邻高层检测到的故障一同被本层的预定义故障处理流程处理。这种自底向上构建容错系统的方式试图在每一层尽可能的处理相应级别的错误, 避免底层的微小错误导致高代价的故障处理方式的介入。同时这种方式能够整合层级错误类型, 实现层与层之间透明的错误传输和处理, 降低了容错处理的复杂度。
芯片电路层容错机制提供贴近硬件底层的容错措施。如缓存的奇偶校验保护、内存错误检查和纠正 (Error Correcting Codes) 以及晶体管的三重模件冗余 (Triple Modular Redundant) 技术等[4⁃5]。致力于保证构成独立功能的软件节点的容错运行。芯片电路层容错机制对于提高整个系统的可靠性非常重要, 因为越接近底层的错误越难以在高层采取有效措施对错误进行纠正, 高层针对底层错误的解决方式通常是复位或制定相应的冗余接替, 这种方式的代价是很高的。以雷达处理机中实现脉冲压缩功能的某一节点的某关键电子元件故障为例, 通常的容错方法是脉压节点的硬件冗余, 但是如果针对节点内的关键电子元件采用多个冗余元件实现低粒度容错, 即能以更小的空间代价替代节点冗余实现此类错误的容错。如果同时使用这两种方法, 则大大提高了雷达处理机的可靠性。
节点层容错机制实现在构成独立功能的软件节点上, 致力于保证软件相应功能单元的容错运行。节点层的容错机制能够处理多数芯片电路层抛出的无法解决的错误情况, 结合硬件冗余采用诸如看门狗定时器以及检查点备份等软件冗余方法能够复位或恢复节点运行状态, 或提供允许程度内的降级服务。同样以雷达处理机脉冲压缩单元为例, 脉压单元使用n个节点并行工作实现原始数据的分段脉压, 并使用一个脉压冗余节点。如果有两个脉压节点发生故障无法运行, 则节点层容错机制采取相应容错措施保证脉压单元的n-1个有效节点对外提供低速率的脉压处理降级服务。
系统层以整个系统对外提供的功能或服务为对象, 根据节点层的状态选择最优的容错方法并对外反馈错误信息及处理方式。对于非复位类型的容错方法, 系统层容错机制负责各节点间容错运行的一致性状态, 保证整个系统故障与恢复前后的状态一致。系统层容错机制使用分布式冗余管理协议来实现节点的错误诊断和错误隔离, 根据优化的容错策略重新配置以实现系统状态的复位或恢复。系统层负责冗余管理的协调和一致, 使得故障节点本身以及其他相关节点能够在故障处理后协调运行, 对外提供正确的功能和服务。
各层次的容错机制并非孤立的, 而是相互协同实现整个雷达系统的容错功能。低层次容错机制尽可能的解决出现的错误, 如果某些类型的错误无法完全解决, 则将错误抛给高层进行解决。举例来说, 假设雷达系统实现目标检测功能的某个芯片上出现了访存越界错误, 对于此类错误芯片电路层无法进行有效的恢复, 只能将错误类型通知相应的节点层容错机制, 于是节点层的访存异常处理流程将被执行, 终止相应的进程并使用冗余接替, 如果不存在冗余则试图提供降级服务保证节点提供的目标检测功能仍然有效, 最后将节点状态和错误处理方式通知系统层。系统层会根据出错节点的状态通知与之功能相关的节点如目标跟踪节点, 并控制目标跟踪节点更改算法以适应目标检测节点的变化情况。
2 分布式冗余管理协议
故障检测是实现容错系统非常重要的一环。在多层划分容错机制中, 节点间接口故障是一类特殊的故障。因为这类故障的发生会导致层次之间故障类型及故障处理结果信息传递的失败。接口的故障多与组件的电气特性有关, 往往导致大粒度的冗余接替。为此设计了分布式冗余管理协议, 不仅可以用于节点的故障判定, 并且能够在确定故障节点的情况下管理冗余接替并进行拓扑重构。分布式冗余管理协议在故障检测及隔离方面具有时间复杂度低、实现简单的特点。
协议规定在包含n个节点的系统中, 每个节点向其他k (2≤k≤n-1) 个节点发送周期性的心跳消息, 并假设这些消息能够实现无错传输被其他节点正确的接收到。协议通过消息携带的关于节点自身的运行状态信息来判断相应节点是否发生错误或失效, 并使得相关的无错节点获得系统内出错节点的信息保持一致。任意一个节点发送的心跳消息都需要被系统内其他k个节点所确认并维护, 则系统内的每个节点都负责维护k个不同节点的运行状态信息。同时每个节点自身的运行状态信息也分布在k个不同节点上。其中一定时间内无法收到来自某个节点的信息的情况被认为是节点失效。协议可以保证系统在至多有k-1个节点失效的情况下仍能准确检测到系统内任一节点的运行状态信息, k值可以根据系统设计情况和可靠性需求灵活指定。
2.1 初始化及心跳检测
(1) 对于最多包含n个节点的系统, 系统内的每个节点都维护一个大小为n的环形哈希表, 哈希表的每个位置都与各节点一一对应。定义哈希函数Hash () , 来自节点Ni (1≤i≤n) 的运行状态信息将被写入当前节点哈希表中Hash (Ni) 的位置。定义变量state表示节点的运行状态:state值为1表示节点运行状态正常;state值为0表示节点故障或失效。
(2) 系统初始化时各节点哈希表的所有位置将被置零, 每个节点将设置current指针指向其维护的哈希表中自身的位置;设置start指针指向其维护的哈希表中第k前驱的位置;并设置end指针指向其维护的哈希表中第k后继的位置。其中start= (current-k) %n, end= (current+k) %n。从当前节点出发, 逆时针方向逐个访问处于有效状态的节点直到start指针指向位置可以获得当前节点的k个前驱节点的运行状态信息。
(3) 系统内节点Ni (1≤i≤n) 每经过心跳周期τ向其k个处于有效状态的后继节点S1, S2, ⋯, Sk发送心跳消息。Ni的第i后继节点Si在接收到Ni的消息后, 将其哈希表中Hash (Ni) 的位置写入Ni的运行状态信息。节点状态正常置1, 节点故障置0。
(4) 为节点Ni的k个前驱节点P1, P2, ⋯, Pk设置接收超时时间τ1。如果当前时间t>τ+τ1, Ni仍未接收到其第i前驱节点Pi的消息, 表明节点Pi已经失效。则将Ni哈希表中Hash (Pi) 的位置写入0。
(5) 经过时间τ2 (τ2>τ1) 后, 以k为步长选择系统内任意én kù个节点, 查看这些节点哈希表中的k个前驱节点的运行状态信息, 即可获得整个系统内所有节点的运行状况。
2.2 节点失效的拓扑重构
如果协议通过心跳检测发现某一节点失效, 则需重新建立现存有效节点之间的关系。单点失效的情况将会涉及其k个前驱节点和k个后继节点的拓扑重构。如果节点Ni失效, 则将其k个前驱节点P1, P2, ⋯, Pk的哈希表中的end指针分别移动到下一位置, 即令end= (end+1) %n;并将其k个后继节点S1, S2, ⋯, Sk的哈希表中的start指针分别移动到上一位置, 即令start= (start-1) %n。
图2和图3分别反映了失效节点后继和前驱的拓扑重构操作。
3 检查点回卷恢复容错方法
考虑到机载雷达系统的应用环境和自身特点, 过多采用硬件冗余的容错策略并不合适。因为较多的硬件冗余不仅会占用宝贵的机载空间, 也会提高机载雷达的成本。另外, 在机载雷达的某个子系统故障时采用硬件冗余的容错方式只能恢复到初始状态, 这样会丢失故障前的结果和状态。而雷达系统常常需要跟踪测量多个目标, 从初始状态重新建立目标轨迹跟踪需要相当长的时间, 因此需要寻找一种具有较小回卷代价的容错方法。检查点回卷恢复容错方法为容错系统提供了一种低卷回代价的软件容错手段。
检查点回卷恢复容错方法是一种通过软件冗余实现的容错方法。各节点在雷达运行过程中以同步或异步的方式实时保存单元检查点。如果雷达运行时发生故障, 可以通过各系统备份的满足全局一致性状态的一组检查点将整个雷达软件系统恢复到之前的状态, 并保证恢复前后状态的一致性和数据的完整性。单元检查点的保存在节点层实现, 每个单元的检查点是其所在节点的嵌入式芯片中的关键结构的数据映像文件, 文件内容由各类寄存器、堆栈、只读ROM中的数据按一定格式构成。单元检查点的实现是与硬件体系结构紧密耦合的, 可以通过函数库的方式提供给高级程序调用。目前相关领域技术已比较成熟。
3.1 检查点的一致性状态
检查点的一致性状态是指:如果某一运行实体采取检查点时的状态反映接收到来自另一发送实体的消息, 那么对应的发送实体在某一检查点时的状态也反映此消息已发出, 那么两个状态处于一致性状态, 所属不同实体的两个检查点叫做一致性检查点[6]。如果全局检查点中的任意两个局部检查点都符合一致性约束, 那么全局检查点也是一致的。然而在节点故障时有两类消息会使系统处于不一致的状态, 它们分别是在途消息和孤儿消息。
令Ca, x表示进程Pa的第x个检查点, Sa, x表示检查点Ca, x时的系统状态。
∃进程Pa, Pb, 检查点对 (Ca, x, Cb, y) , 进程Pa发送给进程Pb的消息m, 使得消息已发送状态send (m) ∈Sa, x同时消息已接收状态recv (m) ∈Sb, y, 则称m为在途消息。
∃进程Pa, Pb, 检查点对 (Ca, x, Cb, y) , 进程Pa发送给进程Pb的消息m, 使得recv (m) ∈Sb, y, 同时send (m) ∉Sa, x, 则称m为孤儿消息。
3.2 基于悲观消息日志的异步检查点回卷恢复策略
通过异步方式实现全局检查点备份的方法赋予系统内各节点很高的灵活性, 这种方式允许各节点独立的保存本地检查点, 能够满足机载雷达系统的实时性要求。然而在选择满足一致性状态的全局检查点的过程中容易产生多米诺效应[7]。多米诺效应是指在回卷的过程中为了避免出现孤儿消息或在途消息导致的检查点不一致状态而产生的过度回卷的现象, 极端的情况可能使系统回卷到初始状态, 从而降低恢复的效率。
为了避免异步方式实现全局检查点可能出现的多米诺效应, 可以采取记录消息日志的辅助手段, 对于在程序运行中所遇到的任何一个不确定的消息发送动作, 系统都假设在此动作发生后系统会出现故障。于是在每个不确定的消息发送动作产生结果之前, 将能够复现此消息传输过程的关键信息能够保存到稳定的存储介质中, 然后继续程序的运行。这种策略是工程领域常用的悲观策略, 可以称之为悲观消息日志方法。借助这种手段在系统出现故障, 寻找可恢复的全局一致性状态时能够消除孤儿消息、在途消息以及多米诺效应带来的不利影响。
采用悲观消息日志方法具有以下优点:首先无需为异步实现的全局检查点设计复杂的协议保证其一致性状态, 实现简单;再者在回卷恢复时仅需从最近的全局检查点开始, 并且仅对出错的进程执行回卷操作, 恢复的代价小。
4 仿真实验
实验借助Qui KLab实时嵌入式系统测试工具进行系统的仿真、故障注入及结果分析。实验通过主机开发测试模型对被测系统的交联对象的内特性与外部环境进行仿真, 构建测试环境模型与接口驱动模型。并借助FIU自动测试故障注入箱实现实时环境下的电气故障模拟。表1描述了采用多层划分容错机制实现的系统与采用一般容错方法实现的系统在典型故障输入时的表现。
5 结论
本文针对雷达系统的结构特点提出一种多层划分的容错体系结构, 通过自底向上的方式构建容错系统并试图在每一层尽可能的处理相应级别的错误, 避免底层的微小错误导致高代价的故障处理方式的介入, 由此可以提高容错处理的效率。为容错系统设计的分布式冗余管理协议能够实现节点的错误诊断和错误隔离, 为容错系统节点级的故障检测和重新配置提供了简单有效的方法。最后利用基于悲观日志的异步检查点回卷恢复策略实现程序状态的回卷恢复, 为机载雷达系统提供了一种低卷回代价的软件容错手段。算法具有良好的时间性能和扩展性, 能够满足机载雷达系统应用环境的需求。
摘要：针对机载雷达系统的高可靠性要求, 提出了一种多层划分的容错体系结构。采用自底向上分层的方式构建容错系统并试图在每一层尽可能的处理相应级别的错误, 避免由微小错误导致高代价故障处理方式的介入。在此基础上设计分布式冗余管理协议实现节点的错误诊断、错误隔离以及重新配置, 并采用一种基于悲观消息日志的异步检查点回卷恢复策略用于程序状态的复位或恢复。最后通过系统仿真故障注入的方式验证采用多层划分容错机制设计的系统具有更高的容错效率。
关键词：机载雷达系统,容错体系,多层划分,检查点回卷恢复
参考文献
[1]AIDEMARK J.Node level fault tolerance for embedded real time systems[D].Goteborg, Sweden:Department of Computer Engineering, Chalmers University of Technology, 2004.
[2]VIJAYKUMAR T N, POMERANZ I, CHENG K.Transient fault recovery using simultaneous multithreading[C]//Proc.of the-29th International Symposium on Computer Architecture.Washington, DC, USA:IEEE Computer Society, 2002:8798.
[3]AFONSO F, SILVA C, TAVARES A, et al.Application level fault tolerance in real time embedded systems[C]//Proc.of In ternational Symposium on Industrial Embedded Systems.[S.1.]:IEEE Press, 2008:126-133.
[4]AIDEMARK J, FOLKESSON P, KARLSSON J.A framework for node level fault tolerance in distributed real time systems[C]//Proceedings of the-2005 International Conference on De pendable Systems and Networks.Yokohama, Japan:IEEE Computer Society, 2005:656-665.
[5]刘耀, 胡越明, 金利峰.高可靠计算机系统的容错技术[J].计算机工程, 2004, 30 (z1) :590-592.
[6]GOIRI I, JULIA F, GUITART J, et al.Checkpoint based fault tolerant Infrastructure for virtualized service providers[C]//2010 IEEE Network Operations and Management Symposium.Osaka:IEEE, 2010:455-462.
[7]SARIDAKIS T.Design patterns for checkpoint based rollback recovery[C]//Proceedings of the-10th Conference on Pattern Languages of Programs.IL, USA:Robert Allerton Park and Conference Center, 2003:1-27.
[8]GAISLER J.A portable and fault tolerant microprocessor based on the SPARC V8 architecture[C]//Proceedings of the-2002 In ternational Conference on Dependable Systems and Networks.Bethesda, MD, USA:IEEE Computer Society, 2002:409415.
[9]傅忠传, 陈红松, 崔刚.处理器容错技术研究与展望[J].计算机研究与发展, 2007, 44 (1) :154-160.
建立容错纠错机制心得体会 篇5
市商务局召开党组扩大会议，专题学习讨论市委办、市政府办《关于充分调动干部积极性激励改革创新干事创业的实施意见》，局纪检组长陈洁就建立健全容错纠错机制做了中心发言。
会上，局党组书记、局长许建平向全局职工提出了三点学习要求。一是要提振精气神。要弘扬“三气”，做有骨气、有勇气、有志气的商务人，要敢于创新、敢于超越，同强的比、向高的攀、与勇的争、跟快的赛，高标准高质量完成上级下达的各项任务。二是要聚集正能量。强化创先争优理想信念教育，从精神激励层面来调动全体干部工作的积极性，进一步激发干事创业的工作热情，全力争创一流的工作业绩。三是要打造新氛围。营造团结和谐的干事创业氛围，凝聚全体干部的智慧和力量，形成各司其职、各负其责、相互配合的良好局面;同时，把“想干事、能干事、干成事”作为衡量标准，加大通报表彰和考核力度，使干事的人政治上有奔头，待遇上有提升。
容错机制 篇6
为了提高读光盘的能力, 厂商在光驱上做了很大改动, 提高光驱中激光头的功率是常用的方法, 这是从硬件设备上提高光盘的容错性能。但是, 光头功率增大后, 长时间“超频”使用会使光头老化, 严重影响光驱的寿命。这种以牺牲光驱寿命来换取容错性的方法是不可取的。本文则是从软件角度出发, 在Linux操作系统下, 在块设备驱动程序的基础上实现了软件层次的光盘容错机制, 以驱动程序小的改动为代价实现了一定能力的光盘容错, 提高了光盘的使用寿命。
1Linux设备驱动程序
Linux内核与外部设备之间的交互操作是通过设备驱动程序实现的。设备驱动程序属于内核的一部分, 为外设定义了相关的数据结构和操作函数, 并通过特定的接口与内核和其它设备驱动程序通信。图1就是设备驱动层在内核中的位置: 系统调用是操作系统内核和应用程序之间的接口, 设备驱动程序是操作系统内核和机器硬件之间的接口。设备驱动程序为应用程序屏蔽了硬件的细节, 这样在应用程序看来, 硬件设备只是一个设备文件, 应用程序可以像操作普通文件一样对硬件设备进行操作。设备驱动程序作为内核的一部分完成以下的功能。
(1) 对设备初始化和释放;
(2) 把数据从内核传送到硬件和从硬件读取数据;
(3) 读取应用程序传送给设备文件的数据和回送应用程序请求的数据;
(4) 检测和处理设备出现的错误。
在Linux操作系统下有三类主要的设备文件类型, 分别是字符设备、块设备和网络设备。字符设备和块设备的主要区别是:在对字符设备发出读/写请求时, 实际的硬件I/O一般就紧接着发生了;块设备则不然, 它利用一块系统内存作缓冲区, 当用户进程对设备的请求能满足用户的要求, 就返回请求的数据, 如果不能, 就调用请求函数来进行实际的I/O操作。块设备主要是针对磁盘、光盘等慢速设备设计的,
以免耗费过多的CPU时间来等待。光盘作为一种大容量存储设备, 它是作为块设备被Linux中的块设备驱动程序处理。
2块设备驱动数据结构及流程
块设备驱动层作为内核的一部分, 定义了很多的数据结构, 有描述外设的, 也有描述外设请求的, 这些数据结构对于分析驱动程序流程至关重要, 以下是其中的两个重要的数据结构, 均在blkdev.h中定义:
(1) 请求队列结构体。
(2) 请求结构体:request
光盘的读取请求是通过块设备驱动程序实现的, 在Linux操作系统下, 这是通过请求队列的形式实现的。正常的读取操作过程包括三个步骤:
(1) 检查当前读取请求的有效性。这是由blk.h中定义的宏INIT_REQUEST完成;
(2) 进行实际的数据传送。用变量CURRENT (实际上是个宏) 可以获得发出请求的一些细节, CURRENT是一个指向结构体request的指针。request是以request_ queue (请求队列) 为链接头、通过其中的双向循环链表queue链接起来进行管理, 见图2中第一列的三个结构体。每一个request (请求) 又可以处理多个连续的读操作, 通过图2中的结构体buffer_head进行管理, 而实际的数据保存在data中。
(3) 清除当前的请求。这个操作由函数ide_end_request完成, 函数的代码在ide.h中。实际的执行操作向这个函数传递一个参数, 成功时为1, 失败时为0。当ide_end_request以参数0调用时, 一个“I/O error”消息会被发给系统日志 (通过printk) , 即发生读请求错误。
3设备驱动层次的容错机制
总之, 设备驱动层次的容错机制包括初始化、读操作判断以及错误处理这三个阶段, 详细的容错流程则可以参考图3。在Linux操作系统下, 光盘容错处理机制的具体处理过程如下:
(1) 操作系统在收到读光盘命令后、在进行读操作之前, 先进行初始化工作:
sectors = N (N是一个常量) , sectors 是每次读操作失败之后跳过的扇区块数, 在连续读错的情况下, 以2的倍数递增;
sector_end = 0, sector_end 是跳块之后下一次要读的块号, 即有如下关系:
sector_end=current_sector + sectors, current_sector是当前块号, 初始化为0;
Error_times=0, 连续读错误的次数, 有上限M (常数) , 初始化为0;
(2) 通过图3, 可以看到正确的读操作流程图, 如果发生读取操作错误, 则进入到错误处理的流程中去, 具体的操作如下:
sector_end=current_sector + sectors, 得到跳过sectors块之后下一次要读取的块号;
Error_times ++, 连读错误次数加1, 并且要判断是否大于最大允许的连读错误次数, 如果大于等于允许的最大连续读取错误次数, 则认为光盘数据损坏严重, 退出当前读命令;
sectors=2×sectors, 在连续读取错误时跳过的扇区块数加倍;
真正跳块的操作是从下一次开始的sectors块读取操作, 但不一定是sectors次循环, 因为在Linux块设备驱动程序中, 每个读取操作是以data为单位的, 而每个data中会存放若干个块的数据, 此外, 多次连续的读取操作可以合并到一个读请求中, 可以参考图2。取消该次读操作所做的工作是由前面曾经提到过的ide_end_request函数实现的。ide_end_request 函数是对于读取操作的扫尾工作, 在正确的读取操作结束之后会返回1, 而在错误的读取操作之后会返回0。如果没有错误处理机制, 原始的驱动程序是一次处理一个data的数据, 而且要等到该次读错误操作返回。在底层操作中是通过一个时间溢出值为0来标识的, 在连续若干块发生错误的情况下, 每次都要等到溢出值为0, 导致读盘极其缓慢, 对于检测中使用的高清碟片而言则是出现播放画面停顿或马赛克等现象。
在上述错误处理机制中, 要改变的是ide_end_request对于跳过的块的处理操作:就是把这些要跳过的块当成已正确读取结束而返回1。也就是在判断处于跳块操作过程后, 不进行任何真正的读取操作, 直接调用ide_end_request来对该次的读取请求进行清理工作。在每一次读取操作过程中, 所做的清理工作是对于该次请求所使用的缓冲空间的释放。在ide_end_request中, 我们要在合适的时机把该次request 中所有用来存放数据的data和管理data的buffer_head处理掉, 采用的方法和正确读取数据之后对于这些结构体和缓冲区的处理方法一样:首先暂存request中bh所指向的buffer_head结构体;接着对request中指向的buffer_head和data进行释放操作, 这是由blkdev.h中的blk_finished_sectors函数实现的;处理完之后通过暂存的前一个buffer_head使得下一个buffer_head前移, 按照上面的方法继续调用blk_finished_sectors进行处理, 直到所有的data和buffer_head都处理完毕。下面的一些示例代码展示了这个过程:
代码中req是request结构体类型的变量, bh是buffer_head结构体类型的变量, nsect是一个data里的块数, hard_sector、hard_nr_sectors是request的内部成员, 分别存放的是当前要处理的块号和本次读请求的所有块数, 会随着清理工作的进行而更新;
(3) 跳过相应的块数之后, 下一次则按照正常的读操作进行, 如果读操作正确, 则进入到正确读操作流程, 否则跳块操作持续下去直到光盘最后或者连读错误次数达到上限值M。
4结束语
本文通过软件机制在Linux驱动程序层次实现了一定的光盘容错机制, 提高了对损坏光盘的容错性能。本方案经过大量的测试并初步用于高清媒体播放器中, 结果表明, 对于85%以上有坏块的光盘, 在遇到损坏的部分时, 经过修改的驱动程序可以对其继续读取, 而未经修改的则长时间卡在损坏的地方不能继续读取。
但是, 本方案也有一定的局限性, 测试结果表明:对于损坏比较严重的光盘, 软件层次的检验需要花费不少的时间;另外, 扇区块跳读的速度也不是最快的, 有待于进一步的优化措施。
摘要：容错机制对于读光盘是很重要的。本文分析了Linux操作系统下块设备驱动程序的工作流程, 并实现了一种在驱动层通过扇区块跳读来实现光盘容错的方法, 显著提高Linux操作系统下光盘的重复利用率。
关键词：Linux,驱动程序,扇区块,光盘,容错
参考文献
[1] (美) 鲁比尼等著, 魏永明等译.Linux设备驱动程序 (第二版) .北京:中国电力出版社, 2002.346～397
[2]Daniel P.Bovet, Marco Cesati著.Understanding the Linux Kernel (2nd Edition) .O’Reilly, 2002.1～50
[3]孙树清, 陈萍.可录型光盘与菁染料光存储媒体的研究进展.化学通报, 1999, (第6期) :
[4]宋宝华著.Linux设备驱动开发详解.北京:人民邮电出版社, 2008.2～71
容错机制 篇7
1 容错计算机系统结构
自主研发三模冗余(Triple Module Redundancy-TMR)体系结构的容错服务器，它由3个同构的处理模块C1、C2、C3通过专用高速总线(PHN)相连组成，3个处理模块同步的执行相同的操作，系统将各处理模块的结果通过“三中取二”的表决方式输出来屏蔽TMR的单点故障，从而提高系统的可靠性。
PEi是主处理器模块包括CPU、MEMORY、CHIPSET板;NICi是高速网络接口电路;FMMi是容错管理模块，主要由它实现容错计算机的容错功能，包括多信道数据通信、Ci间同步、数据表决、故障检测、隔离和恢复、系统降级等。
2 故障恢复方案
2.1 容错原理
用户向服务器提交的每个关键任务Task都采用主动任务复制(Active Replication)方式[4]复制到3个处理模块中去。这样同一任务Taski的三个复制进程Pi_1,Pi_2,Pi_3在同步机制[3]的管理下在3个处理模块中同步地运行，处理结果经过比较、表决来达到检错、容错的目的。所以服务器的容错功能体现在对关键任务进程集T={Task1,Task2，…，Taskn}中任务的容错计算。
2.2 故障模型
系统出现故障时，先假设为瞬时故障，在对其恢复的同时对该处理模块进行一次故障计数，当在一定时间范围内计数值超过门槛值N时，就判定该处理模块发生永久故障，并被隔离出TMR系统，系统降级为双模(Double Module Redundancy-DMR)系统，如图1所示。
2.3 进程拷贝原理与关键技术
通过系统建模和对容错原理的研究得出永久故障恢复的目标是在目标处理模块上重建原DMR系统的关键任务进程集TDMR={T1,T2，…，Tk}[7]为了实现永久故障的恢复。提出应用进程拷贝实现TDMR重建的思想。进程拷贝就是保证进程Pi正常运行的前提下，在目标处理模块上建立其复本Pj。
因为实现服务器永久故障的恢复需要对TDMR进行拷贝，所以为了保证多进程之间的相关性进一步开发出以进程家族为单位的多进程拷贝(Multi-Process Copy)机制，它同样包括进程家族检查点机制。
3 永久故障恢复的实现
3.1 软件结构
进程复制由进程检查点机制和进程重建机制经系统守护进程Scanf_process统一调度实现的。进程检查点机制中由函数checkpoint()负责将进程的状态信息记录到一种自定义的二进制文件(checkpoint_format)中生成检查点。被记录的进程状态信息包括：进程的地址空间、文件、共享内存、寄存器、信号量、套接字、管道等资源的使用状况。
3.2 进程的重建过程
3.2.1 家族检查点的分割
因为进程拷贝是以家族为单位进行的，所以在目标处理模块上要以进程为单位先将家族检查点文件分割成若干检查点文件。编写了分割函数chop()，它根据家族检查点文件中的头结构来识别各进程的具体内容。
3.2.2 总体过程
(1)从DMR系统中提取关键任务形成关键任务进程集合TDMR={T1,T2，…，Tk}，准备开始拷贝TDMR。
(2)调用函数checkpoint()对Processfamily_i中各进程状态进行保存，生成对应的家族检查点文件ckptfamily_i并将其传输到目标处理模块上。
(3)目标处理模块上应用chop()函数将接收的ckptfamily_i以进程为单位分割为若干独立的检查点ckpt，最后依次调用restart()函数加载各检查点文件重建进程家族Processfamily_i。
(4)重复步骤2到4直到TDMR中的进程全部拷贝到目标处理模块上为止
总体流程如图2所示。
4 结语
具有透明性的同步和故障恢复机制是构造容错系统的两大难点。大多数容错服务器永久故障的恢复机制采用复杂的硬件设备和软件，这增加了系统开发的难度、周期和成本。鉴于这些问题，采用软件方法在Linux操作系统级实现对永久故障的恢复，并对用户完全透明，通过试验测试验证了其有效性。
参考文献
[1]P.Gawkowski,J.Sosnowski Assessing Software Implemented Fault Detection and Fault Tolerance Mechanisms Institute of Computer Science,Warsaw University of Technology,Warsaw,Poland.
[2]D.W.Bradley and A.M.Tyrrell.The.Architecture for a Hard-ware Immune System.Prcceedings of the third NASA/DoD workshop on evolvable hardware.2001IEEE.
容错机制 篇8
当今的网络应用对于互操作性的需求日益增加。各种在线业务已从简单的信息交互领域扩展到服务交互领域。尤其在电子商务和电子政务领域, 协同服务环境的构建成为了新的发展趋势。Web服务技术能够以一种标准化的方式实现异构系统之间松耦合的互操作, 为协同服务环境的构建提供了有力的支持。然而, 目前的Web服务技术仍有许多关键的问题有待解决, 其中很重要的一个方面就是Web服务的可靠性和容错性。
容错是保障系统可靠性和可用性的关键技术, 使得系统在发生部分失效时仍能尽可能地继续工作。我们在智能政务系统的服务集成项目中, 发现Web服务的可靠性和容错性对系统的有效运作产生了很大的影响。为此, 我们在政务服务集成系统中引入了基于补偿服务链的Web服务容错机制。
1 Web服务容错性分析
1.1 传统的Web服务容错技术
导致Web服务调用出错的原因主要有两个方面:网络故障导致消息传送失败和Web服务节点失效导致服务请求失败。对于这两个问题, 传统的解决方法主要包括两点: (1) 在服务请求者与服务提供者之间引入消息确认/重传机制。每一次消息发送都必须得到消息接收者的确认, 对于传送失败的消息重新发送。 (2) 建立Web服务的备份, 当服务请求失败时, 请求者将向备份服务重新发送请求消息[3]。
传统的容错技术的实现需要Web服务客户端 (请求者) 的参与、消息重传、备份Web服务寻找等操作都由Web服务客户端完成, 这将增加客户端系统的开销, 并且会增加客户端系统的复杂性。另外, 采用简单的消息重传和服务备份的容错机制只适用于请求目标为单一Web服务的场合。对于服务集成系统来说, 任一服务节点错误将导致整个Web服务组合执行失败, 这将造成计算资源的浪费。
1.2 Web服务容错机制的设计目标
出于对传统Web服务容错技术改进的考虑, 我们提出了Web服务容错机制的四个设计目标: (1) 实现客户端透明性:尽可能地减小Web服务错误对客户端系统的影响, 并且容错机制的实现不应由客户端参与; (2) 提供对Web服务组合的支持:对于服务集成系统来说, 容错机制不仅要支持对单个Web服务的容错, 还需要支持Web服务组合的容错; (3) 建立服务补偿机制:当Web服务调用出错时, 将触发相应的服务补偿动作, 而不是立即返回出错信息; (4) 实现对Web服务会话状态的监控和维护:容错机制能够对Web服务组合的执行过程进行监控和维护, 将单个Web服务失败造成的影响控制在一定的范围之内, 而不会导致整个Web服务组合执行的失败。
2 基于补偿服务链的Web服务模型
2.1 相关概念
定义1 补偿服务CWS (Compensating Web Service) :目标Web服务出错, 触发相应的补偿动作时调用的Web服务。包括以下三类: (1) 目标Web服务的备份; (2) 与目标Web服务功能相同或相近的替代服务; (3) 特定的出错处理服务。
定义2 补偿服务链CWSL (Compensating Web Service Linked List) :指定的Web服务及其补偿服务集按照一定的次序构成的链表结构。
CWSL={E1, E2, E3, …, En} (n≥2)
其中E1为指定的Web服务;Ei (1
CWSL的构建通过链接器实现, 其结构如图1所示。
链接器独立于原始的Web服务, 它通过invoke接口以标准的SOAP方式调用相应的Web服务。当调用成功时, 则停止CWSL中的请求传递过程, 向请求者返回响应消息;当调用失败时, 链接器通过next接口将服务请求传递到服务链的一下结点。只有在目标Web服务及其所有补偿服务都失效时, 才会启动服务中止程序, 返回请求失败消息。
定义3 基于补偿服务链的Web服务组合WSC (Web Services Composition) :由补偿服务链CWSL构成的有序集合。
WSC={LE1, LE2, LE3|LE4, [LE5, LE6], …, LEn} (n≥1)
WSC中的每一元LEi都为一个CWSL, 其中LE3 | LE4 表明LE3与LE4 并行执行, [LE5, LE6 ]表明LE5与LE6两者选一执行。
2.2 基于补偿服务链的Web服务模型
基于补偿服务链的Web服务模型如图2所示。该模型为一个二维结构, 横向为Web服务组合中各个Web服务的有序排列;纵向为各个Web服务对应的补偿服务链。
在该模型下, 对于Web服务的请求将转变为基于补偿服务链的Web服务组合的一次执行。执行的过程可分为三种情况: (1) 服务组合中的所有Web服务都调用成功, WSC执行产生的最终响应消息由各个CWSL的头元素WS的响应消息构成。这种情况下无须启动容错机制。 (2) 服务组合中的某些Web服务调用失败, 但都可通过相应的CWSL上的某个补偿服务来完成请求处理, 即Web服务调用出错可通过CWSL得以恢复或进行一定的补偿操作。这种情况下, WSC的实际执行结果与预期的执行结果存在着一定的差别, 将记录在最终的响应消息中, 交由容错框架做进一步的处理。 (3) 服务组合中的某些Web服务调用失败, 并且将触发某个CWSL末端的服务中止程序。这种情况下, 无法由CWSL完成容错, 但是WSC的执行状态将记录在最终的响应消息中, 交由容错框架进行容错处理。
3 Web服务容错框架
实现容错机制的一个关键问题是实现对Web服务会话状态的监控和维护, 因此, 我们在补偿服务链的基础上建立了Web服务会话管理机制。服务补偿机制与会话管理机制结合起来构成了整个容错框架, 如图3所示。
3.1 Web服务会话
从请求者发出服务请求, 到服务提供者完成请求处理, 返回最终的响应消息的整个过程定义为一次Web服务会话。传统的Web服务模型中, 服务请求者与服务提供者之间的通信和交互是基于标准的SOAP方式, 但是SOAP以无状态的HTTP协议为载体, 在服务请求调用过程中无法获知Web服务的会话状态信息。
我们对标准的SOAP消息进行了扩展, 在消息头部增加了描述Web服务会话状态的元素
其中子元素Requester描述发起Web服务会话的请求者的相关信息;ProviderSet指明Web服务会话中所涉及到的服务提供者的集合;SessionStatusSet记录ProviderSet中描述的所有服务提供者的调用状态, 即2.2节所述的服务组合的执行状态。
3.2 Web服务会话的管理
容错框架中对Web服务会话状态的监控和维护是通过会话创建器、会话注册器、会话管理器以及会话持久化四个部分来实现。其关键步骤如图3所示。
(1) 请求者发送服务请求消息, 申请一次Web服务会话。
(2) 会话创建器根据请求消息, 调用服务集成模块, 生成相应的Web服务组合 (WSC) 。
(3) 会话创建器根据服务集成模块返回的结果信息创建一次Web服务会话, 并通过会话注册器进行注册。会话注册器初始化
(4) 会话管理器从会话注册器中提取Web服务组合信息中的服务补偿规则, 创建补偿服务链。
(5) 会话管理器向基于补偿服务链的Web服务组合发送请求消息, 启动Web服务组合的执行。请求消息的头部包含用于记录本次Web服务会话状态的
(6) 会话管理器从Web服务组合的响应消息头部中提取
(7) 会话管理器完成对响应消息的处理或相关的容错动作后, 向请求者返回最终的响应消息, 结束本次Web服务会话。
3.3 应用实例
我们在政务服务集成系统中实现了上述Web服务容错机制。其中的一个应用实例是用于数据备份服务中, 如图4所示。
数据备份服务的功能是将各个部门业务系统产生的数据备份到数据中心。为确保备份服务的可靠性, 我们建立了实时备份服务、延迟备份服务以及通知备份服务构成补偿服务链。默认情况下采用实时备份方式;当实时备份出错时, 备份请求将依次由延迟备份服务或通知备份服务接管。该容错机制有效地提升了数据备份服务的可靠性。
4 结束语
本文提出了一种基于补偿服务链的Web服务容错机制。通过建立服务补偿机制和Web服务会话管理机制达到容错的目的。该容错机制能够有效地增强Web服务请求调用的可靠性。接下来的工作是对补偿服务链模型作进一步的优化, 在补偿服务链的构建中考虑服务质量、优先级等因素。
摘要：针对网络故障以及Web服务节点暂时性失效, 导致Web服务请求出错的问题, 提出了一种Web服务容错机制。通过建立服务补偿机制和Web服务会话管理机制达到容错的目的。首先对Web服务的容错性问题进行了分析;接着详细论述了服务补偿机制和容错框架的设计与实现方案;最后通过在政务服务集成系统中的应用实例说明了该容错机制能够有效地增强Web服务请求调用的可靠性。
关键词：Web服务,容错,可靠性,补偿服务
参考文献
[1]岳昆, 王晓玲, 周傲英.Web服务核心支撑技术研究综述[J].软件学报, 2004, 15 (3) :428-442.
[2]石静, 丁长明, 赵泽宇.Web服务合成研究综述[J].计算机科学, 2004, 31 (6) :54-58.
[3]Fang C, Liang D, Lin F.Fault tolerant web services[J].Journal of Sys-tems Architecture, 2007 (53) :21-38.
[4]Sun Y, Ma X, Xie K.A compensation mechanism in GIS web servicecomposition[C].Geoscience and Remote Sensing Symposium, 2005.
容错机制 篇9
在控制系统复杂性越来越增强的情况下,各个控制领域也不断地引进分布式控制系统,例如飞行控制系统,武器防御系统, 工业控制系统等等,但在控制器数量变多的同时,系统出现问题的几率也在变大。各个任务在控制系统中都被紧促的时间制约着,也称为“时限”,一旦控制器有问题让一些任务不能在规定的时间内做完,这样造成损失的可能性会很大。为避免此类问题, 分布式控制系统中还需增强容错能力,以提高在一些控制器出现问题的情况下完成任务的效率,进而保证控制系统的可靠性能。
容错调度算法是用软件工具处理在分布式控制系统中有容错故障的,而不是用其他硬件的一种有用的办法。迄今为止, 在分布式系统中采用的容错技术是:分布式投票技术,反转恢复技术和基/副版本技术,但是这些都没有考虑有关任务的一些实时性问题。现今的实时容错技术一般是以基/副版本为蓝本而实施起来的,按照等待处理的实时任务的性能,进而发展出了RM算法、RMFF算法、PB-Overloading算法、SS算法、RB算法、HFTS算法等。其中,RM算法、RMFF算法属于处理周期任务,PB-Overloading算法属于非处理周期任务,SS算法、 RB算法、HFTS算法属于处理混合任务。
调度算法在处理混合任务的调度过程中,对非周期任务实行预留时间,预留时间指的是原本属于任务周期的部分,现在被分到非周期任务中去,然而人们为使周期任务可以调度,所以在选择固定时间内处理机上的周期任务时,把运行完后所留下的时间当做预留的时间。因为在周期任务被完成最坏的情形下,才能产生预留时间,所以非周期任务不能得到回应在一个周期频频来临的时候。
对于以上的一些问题,该篇文章按照处理机数目的多少把周期任务集分成周期任务子集,周期任务子集在处理机上的调度不同,因为周期任务在各个处理机上所运行的不一样,所以运算的预留时间也不尽一样。因为周期任务频频来到而当时无法应对的时候,能够把一些任务调度到没有那么多周期任务的处理机上去实行。如果这样,不仅使周期任务的调度得到有力的保证,而且也能应对周期任务所提出的需求,进而增强控制系统容错调度的力度。
1实时系统的动态容错调度模型
现在很多以实时系统为基础的容错调度模式和算法也相应地产生了。一般的容错技术有:分布式投票技术、反转恢复技术和主/副版本技术。由于这些不能完成实时系统的需求,因此有人又提供了一种不完善的,算法也不准确的容错技术。更有甚者,根据主/副版技术使实时调度中的容错能力得到提高,以此为准,探讨了混合型的容错调度,然而这样的算法没有顾虑到容错技术出现问题的情况,也没有思考错综复杂的网络环境。 本文主要通过引进面向方面的办法,结合Cyber Physical网络环境对实时系统的容错调度算法做一些探索和分析。针对系统出现问题仍能有充足的时间来面向方面与扩展UML框架,在使实时系统的容错调度能满意的前提下,不仅考虑可调度性,还考虑到可靠性能,在多变的Cyber Physical网络环境下,进一步分析时间和容错的方面。然而,由于刚刚归纳了Cyber一physical Systems的定义,所以其他的理论分析和基本工作还有待完善,缺乏更加准确统一的国际化概念和内涵,因此这个课题没有更进一步的探索,而是按照Cyber Physical网络环境的特点,运用面向方面,分析出能在错综复杂的Cyber Physical网络环境下以实时系统为基础的容错调度和算法。这样,对于发展cyber一Physicalsystems和容错技术都有着很大的作用。
2容错技术
容错技术的一般定义是系统能够在其出现故障并让结果不发生变化时自行进行处理。它的一般内涵是为不受故障的影响, 而运用外界资源的冗余方法来实现的,进而自行完善系统或者是安全的停机,让系统进入到可以控制的情况下。它的设计理念一般有模块耦合性,模块独立性,冗余,维修等。设计故障、操作故障、环境故障、硬件故障是容错技术所要关注的四种故障类型。
方法一:把那些有容错要求的实时任务拷贝到不一样的处理机节点上,一旦执行任务时发生错误,那个拷贝的样本就会在其他好的处理机上正常的被实行,此类方法只能在时间能满足的情况下才能完成任务,才能提高任务的实时性,就是运用时间冗余来得到可靠性能。此种方法通常只适合没有时间限制的系统,而且在目前的系统没有出现问题时,容错算法为容错保留的实行任务的时间都无用了,这样让中央处理器的利用效率大大降低了。
方法二:在不一样的处理机上同时运行一个任务的多个拷贝的样本,截取正确的运行结果。迄今为止,有两种一般的方法 : 主备份p B ( primary Baekup ) 和三模冗 余TMR (Triple Modular Redundancy),TMR方法的运行步骤是在不一样的处理机上同时运行三个样本,然后对这三个结果进行筛选, 然而此类办法的花费代价较高,而且调度算法在实时性能需求比较大的系统中的关系处理得不好,也不能完善调度算法,进一步保证系统的实时性能。
3系统模型描述
考虑一个由多台处理机构成的分布式控制系统,该系统需要处理多个周期任务和非周期任务,其形式化描述如下:
(1)一组周期任务
其中,N代表周期任务数;Ci代表任务ti在一个周期内的最大执行时间;Ti代表任务ti的最小执行间隔—即周期。设任务的截止时限等于其周期。
(2)一组非周期任务
其中,K代表某一时刻存在于系统中的非周期任务数;ai是非周期任务随机到达系统的时间;ci为任务ji最大执行时间; D为任务ji相对截止时限。
4结果验证
我们在T= 0.2,U= 0.9周期任务数为100个时随机选择一个处理器进行仿真.假设被选择处理器不出现故障,系统中每间隔 Δt= 1000ms系统就有一个处理器出现故障且故障持续时间为符合[100,200 ](ms)上均匀分布的随机数。假设被选择的处理器为:8号处理器;该处理器的执行速度d8= 1.207776。我们可以得到:每一个有容错任务的基版本和副版本的最大响应时间都小于任务时限的1/ 2,即小于这些版本的时限;同时无容错任务的时限也小于它们的时限.这就说明无论系统中是否有处理器出现故障,所有任务都能满足它们的时限,不存在时限丢失问题.这说明本算法是有效的。
5结束语
容错机制 篇10
在工业自动化、机器人系统、武器系统、航空和航天等领域中,为了提高系统的可靠性,双机容错技术得到了普遍的应用和发展。双机容错是由两套完全同构的计算机系统组成[1],作为双机容错系统的控制核心—容错控制器是实现双机故障诊断和仲裁切换的关键机构。本文提出并实现一种基于FPGA的容错控制器,它的功能根据所设计双机容错系统的应用特点,不但实现了双机容错系统中故障的检测和诊断,且能根据诊断结果作出故障处理的仲裁结果,使双机能够及时得到实时判断结果,完成双机容错系统的切换重构工作。该方案有效地结合了FPGA器件的优势及特点,将其引入高可靠性嵌入式系统应用领域,降低了成本,提高了系统的可靠性。
1 双机容错系统结构
本文所设计的FPGA容错控制器应用于如图1所示的双模冗余热备份容错计算机系统。该双机容错系统其应用功能是通过CAN总线接受上位机发送的数据,通过双机容错系统的计算机解算处理后再经过RS422总线下传给接受方设备。
工作原理:该系统由计算机A和计算机B组成主备机,由交叉数据通道实现双机间的通讯,由FP-GA实现的容错控制器完成双机容错系统的部分故障检测、诊断和仲裁切换的任务。另外,A机和B机各有独自的外围控制逻辑和外设,这样即不会引起系统资源的竞争,增加了整体系统的稳定性。双机上电后,首先进行A、B机硬件自检,自检通过后,默认A机作为主系统,接受数据并将此数据和此次接受任务的标志发送至交叉数据通道固定单元,等待双机同步,B机作为备份机同样接受数据并将此数据和此次接受任务的标志发送至交叉数据通道固定单元[2],等待双机同步,然后两机从交叉数据通道中取出任务标志和对方接受的数据进行同步和比较,然后分别执行相同数据的解析任务。将任务标志和计算结果又送至交叉数据通道,两机又通过任务标志和结果数据的比较完成数据发送数据任务的同步和输出数据的比较检测。在接受和主备发送数据的比较中,若比较一致,程序由A机输出,比对不一致程序转到各自自检程序,根据自检结果和主备机标志切换正常计算机作为系统输出,系统转为单机运行。
另外,容错控制器还要实时监测软硬件心跳状态是否正常,若某台主机出现故障,根据故障机是否为当班机,进行相应的容错处理,包括是否请求无故障机切换为当班机、是否复位故障机等处理过程。
2 容错控制器设计
为实现所描述双机容错系统的整体监控和备份功能,本文提出的基于FPGA的容错控制器结构如图2所示。容错控制器根据所接收到的状态信号,判断单机在系统中的地位,并给出相应的输出信号,容错控制器包括:软件心跳检测模块WTD、硬件心跳检测模块ALE_WTD和仲裁判决模块Arbiter。
2.1 两主机负责处理的信号[1]
因为两主机与容错控制器的连接工作机制完全相同,这里只介绍主机A处理的信号:(1)发送周期性的脉冲信号wdi1给WDT,表示主机A处于正常工作状态;(2)通过ALE自动发送既定的脉宽到ALE_WTD,表示主机ALE信号正常;(3)通过主机A的IO口发送主机目前的主备机标志、比较结果标志、自检结果标志到容错控制器仲裁判决模块,等待仲裁判决处理。(4)接收来自仲裁判决模块Arbiter的脉冲信号RESET,以使主机A复位重启恢复故障;(5)接收来自仲裁判决模块Arbiter的中断请求信号Switch1_INT,表示当主机B发生故障且主机B之前是当班机时,请求主机A机接管工作;(6)接收来自仲裁判决模块的脉冲信号state1,表示系统中对等机主机B的工作状态,为主机A是否进入单机运行态做准备。
2.2 软件心跳检测模块(WTD)
程序跑飞、程序死循环等是常出现的软件故障,本设计中在容错控制器采用看门狗技术来检测此故障。看门狗WTD接受来自主机A的IO口发送的周期性脉冲信号wdi1,该脉冲信号对WTD计数器清零。当下一个clk(WTD内部时钟)周期到来时,WDT计数器重新开始计数。如果WDT计数超过某个值(即主机A在规定的时间周期内没有发送wd1脉冲),则认为主机A发生故障,WDT将发送wdo1信号至仲裁判决模块等待仲裁判决处理。
2.3 硬件心跳检测模块(ALE_WTD)
由于51单片机的ALE引脚,无论单片机是否访问外存,ALE都能在一定时间内提供至少一个上升沿或下降沿[3]。如果ALE信号不正常,那么可以确定CPU一定是出现了永久故障。本文设计两个看门狗(ALE_WTD)监测主机的ALE信号,当两主机的ALE不正常引起硬件不能喂狗时,溢出信号(ALE_wdo1=‘1’或ALE_wdo2=‘1’)送至仲裁判决模块等待仲裁处理。这种通过硬件喂狗方式来检测CPU故障的方法既可以节省单片机有限的IO口资源又不用设计专门的喂狗程序。
2.4 仲裁判决模块(Arbiter)
仲裁判决模块根据容错信号包括双机发出的自检信号(self_chk1和self_chk2)、数据一致比较结果信号(diff_chk1和diff_chk2)和软硬件心跳检测模块检测到的结果信号(wdo1和wdo2、ALE_wdo1和ALE_wdo2)这四组检测结果信号和双机发出的主备机状态标志(flag1和flag2),完成对双机状态的判断,最后给出切换请求、复位和对等机状态信号等系统重构信号。图3是主机A被容错控制器仲裁判断后的流程图。
由图3可以看出,四种输入信号self_chk1、diff_chk1、wdi1、ALE1中的任何一个被检测到不正常时,被判断为该机不正常,然后根据该机目前是否为主机(flag1=‘1’),若为主机,则申请切换B机为当班机(置switch2_INT=‘1’)并通知对B机对等机不正常(置state2=‘1’),同时复位A机。主机B的仲裁判决过程同主机A。通过在FPGA中利用硬件描述语言的进程并行模块语句和并行语句特点,实现此模块是很有效的方法。
3 系统实现
根据以上介绍,本文提出的容错控制器是在FPGA芯片上实现的,利用QuartusⅡ8.0,设计如图4所示的VHDL语言编译综合后的RTL级视图。WTD1和WTD2模块分别集成了对主机A和主机B的软硬心跳检测的看门狗模块,Abiter模块即为前面提到仲裁判决模块。这里为了满足系统中CPU及总线控制器等电路的复位信号要求至少200 ms的保持时间,增加了一个reset模块用它来专门处理保持200 ms的复位信号。在程序设计中考虑到输入异步产生的毛刺现象,设计中增加了clk信号作为全局时钟同步信号,充分解决了毛刺问题。[4]
图4中WTD1和WTD2功能相同,feed和ALE信号是被检测的两主机的喂狗信号和ALE信号,经过WTD1的看门狗监测后输出故障监测结果信号至Arbitry模块,Arbitry模块根据两主机的主备机标志信号flag1和flag2、自检信号self_chk1和self_chk2、比较信号diff_chk1和diff_chk2、由看门狗监测到的ALE错误信号CPU1_ERROR和CPU2_ER-ROR、和喂狗失败信号wdo1和wdo2判断仲裁后向两主机输出对等机状态信号state1和state2、切换请求中断信号switch1_INT、switch2_INT和复位信号reset1和reset2。reset1和reset2又经过Reset模块处理输出既定时间的复位信号至两主机系统的各个电路。
4 结果与讨论
本设计选用Altera公司的CycloneⅡ系列型号为EP2C8Q208C8的FPGA芯片,在Windows XP操作系统环境下使用该公司的开发软件Quartus II8.0作为EDA设计工具设计实现。时序仿真波形如图5所示。
由图5中看出,两主机输入的四组检测信号通过容错控制器的故障检测、诊断以及仲裁判断输出复位、切换请求等系统重构信号。例如图5中时间棒(Time Bar)所示:
当时间棒处于+221.88 ns时,容错控制器的WTD看门狗检测到输入信号wdi1由于出现高电平脉冲时间超过既定时间。在时间棒所指处出现“狗咬”,容错控制器根据此时的flag1为高电平,flag2为低电平,确定进行双机切换,置switch2_INT高电平,置switch1_INT为低电平,表示要求主机2接管当班机任务;state1置高电平,state2置为低电平,表示通知主机B对等机(A机)不正常;并置reset1为高电平十个脉冲信号,表示对主机A复位保持一定时间。
其他三个时间棒所指点容错处理结果,由图5容易看出结果也满足设计要求。通过以上时序分析,本文设计的容错控制器满足双机容错系统的容错控制功能的要求,引入了clk全局时钟后信号未出现毛刺,满足系统性能需求。
5 总结
该容错控制器应用于某设备双机容错系统上进行验证,满足系统需求。由于该双机容错系统对数据处理的实时要求比较高,采用本文设计的容错控制器具有的实时监测,实时仲裁等特点,保证了双机容错系统切换时的准连续性;另外,通过FPGA硬件实现仲裁检测任务减轻了双机容错系统软件任务的负担,保证了容错系统不会由于采用复杂的软件实现仲裁判决带来的不可靠性影响。
摘要：根据双机容错系统故障检测和诊断、仲裁技术的常用方案及特点,结合某在研双机容错系统,提出了一种基于FPGA容错控制器的设计方案。仲裁模块作为容错控制器的核心模块,可根据双机工作的监测信号负责完成主备机切换功能。为了实现软硬件心跳故障监控功能,在FPGA内嵌了WTD模块。同时,全局时钟引用于各个模块后,良好消除了输出信号的毛刺问题。实验结果表明,该设计方案满足系统要求,可靠性较好。
关键词：双模容错计算机,FPGA,故障检测与诊断,仲裁
参考文献
[1]李迅,李洪峻,刘庆敖.双模容错计算机的设计与实现.计算机工程,2008;9(17):240—241
[2]朱朝晖,张崇峰,陈卫东.空间双机容错计算机系统研究.上海航天,2004;(6):18—23
[3]王幸之,忘雷.单片机抗干扰应用系统抗干扰技术.北京:北京航空航天大学出版社,2000