分布式系统容错

上传人:j****9 文档编号:54565064 上传时间:2018-09-15 格式:PPT 页数:116 大小:278.50KB
返回 下载 相关 举报
分布式系统容错_第1页
第1页 / 共116页
分布式系统容错_第2页
第2页 / 共116页
分布式系统容错_第3页
第3页 / 共116页
分布式系统容错_第4页
第4页 / 共116页
分布式系统容错_第5页
第5页 / 共116页
点击查看更多>>
资源描述

《分布式系统容错》由会员分享,可在线阅读,更多相关《分布式系统容错(116页珍藏版)》请在金锄头文库上搜索。

1、第十一章 DDB的可靠性,概念,系统(System) 是由一组组件构成的一种机制,这些构成组件通过响应来自某个环境的具有可识别行为模式的刺激而相互作用。,component1,component2,component3,环境,系统,刺激,响应,系统规范说明(Specification) 系统提供的对所有可能的刺激将产生的响应行为必须遵循的说明,概念-续,故障 任何偏离规范说明的行为 软故障与硬故障 软故障 间歇性(intermittent)和瞬变性(transient)故障 硬故障 指永久性故障, 错误设计等,Fault,Error,Failure,原因,结果,导致系统失败的事件链,概念-续,

2、软故障 软故障 占90%以上并且该比例稳定 67年 美空军指出计算机中电子故障80%是间歇性的 67年 IBM 指出 90%故障是间歇性的 80年 研究指出软故障明显高于硬故障 87年 Gray指出 大部分软件故障是瞬时性故障 其它不同计算机系统中出现的统计数据:,IBM/XA 的OS 可靠性报告 57%是硬件, 12% 软件, 14%操作, 7% 环境(斯坦福 线性加速器SLAC) Tandem计算机 18%硬件 25% 软件 25%维护 17%操作, 14%环境 AT&T 5ESS数字交换机 32.3%硬件, 44.3%软件, 17.5%操作 软件故障难以讨论, Tandem指出: 通信或

3、DB的原因是产生软件故障的主要原因. 软件故障的主要原因 代码中的Bug, 曾有报告指出, 1000条指令中, 0.25-10个BUG,永久性 故障,错误的 设计,不稳定 或者 临界的 组件,不稳定的 外部环境,操作者 的过失,系统失败,永久性 错误,间歇性 错误,瞬变的 错误,系统失败的原因,概念-续,可靠性DDBMS指即使当底层系统不可靠时,该DDBMS仍然能继续处理用户需求。也就是说,即使是分布式计算环境的组成出故障,该DDBMS 仍然能执行用户需求,而不破坏数据库的一致性。 提交协议与恢复协议可靠性与事务的原子性和持久性相关,涉及的协议是提交与恢复,可靠性与可用性,可靠性 对系统行为遵

4、从某种权威性规格要求的一种度量。指在一给定时间间隔内不产生任何失败的概率。可靠性通常用于描述那些不能修复的系统。 可用性 对系统行为遵从某种权威性规格要求的一种度量。只在给定的时间点系统可以运行的概率。通常用于描述哪些可以修复的系统。,可靠性与可用性-续,DB行为所要求的规格说明 与应用有关的 事务满足一般的系统规格要求, 其中包括一致性约束(事务与应用之间的语义关系) 与应用无关的 事务维持其ACID性质(事务本身应具有的性质),可靠性与可用性-续,正确性 DB正确运行, 符合某种规格化要求 可用性 当需要访问DB时, 它是可用的 二者有时存在矛盾,可靠性与可用性-续,例: Site1 Si

5、te2x1 x2Lock x1 Lock x22PC,Ready,故障出现,Site1也Ready 故Commit,Site 2 等待,此时Site 2有两种可能: a 以正确性为标准 则等待, 并Lock 2, 直到故障恢复, 但牺牲了可用性 b 引入不一致, 尽量提高可用性, Release x2, 其它事务可以执行,Site 1 正常结束,分布式系统容错,容错 设计一种使系统识别出可能会发生的错误方法。在系统中建立一种机制,使错误在造成系统故障之前就会被检测出来,并能被清除或得到补偿。,基本容错方法和技术,错误预防 保证所实现的系统不包含任何错误 错误回避 保证系统不会带入错误的技术(详

6、细的设计方法学和质量控制)错误清除 清查那些在使用了错误回避技术路线后还残留在系统中的错误,并清除它们(大量的测试和证实过程) 故障检测,基本容错方法和技术-续,潜伏的(Latent)故障 故障发生一段时间后才被检测出来 错误潜伏期 从故障发生到被检测出来的时间 平均检测时间(MTTD) 平均错误潜伏时间 平均修复时间(MTTR) 修复一个失败的系统所需要的期望时间 平均故障间隔时间(MTBF) 在可以自我修复的系统中相继的失败之间的期望时间, 由经验或从可靠性函数计算,MTBF,MTTD,MTTR,在这段时间内, 可能发生多起错误,故障 发生,造成 错误,检测到 错误,修复,故障 发生,造成

7、 错误,时间,相继发生的事件,基本容错方法和技术-续,冗余 所有容错系统设计中都采用的基本原则是在系统的组件中提供冗余 模块化 系统的每个组件都设计为具有定义很好的输入/输出接口的模块 系统实现 故障-停止模块(fail-stop module) 进程对(Process pairs),time 正常 停止 恢复 正常,易失存储丢失,稳定存储 ok,故障-停止模块不断地对自身进行检测,当检测到一个故障时,就自动停止。优点是缩短了故障检测的潜伏期。,基本容错方法和技术-续,基本容错方法和技术-续,进程对(Process pairs) 通过软件模块的双工来实现容错。两个进程,一个是主进程,一个是备份

8、,它们同时提供同样的服务,主进程与备份进程都是基于故障-停止模块实现。 锁定-步进方式 自动检查点设置方式 状态检查点设置方式 Delta检查点设置方式 持久进程对,基本容错方法和技术-续,面向对话的通信(Session-Oriented Communication) 授权OS中的消息服务器(而不是应用程序)去检测和控制那些丢失的或重复的消息,分布式DBMS的故障,事务故障 站点故障 介质故障 通信故障,局部可靠性协议,局部恢复管理器 (LRM) 每个Site一个 维护局部事务的原子性和持久性 体系结构 数据库存储在稳定存储器中 存储和访问稳定数据库的单位是页 缓冲区中的数据库称作易失数据库

9、LRM仅仅在易失数据库上执行事务操作 对数据库的访问都要经由数据库缓冲区管理器 Flush(冲洗) 实现将数据库缓冲区页对稳定DB的强迫写,数据库 缓冲区 (易变数据库),局部恢复 管理器,数据库缓冲区 管理器,主存,取出, 冲洗,读/写,稳定 DB,读/写,LRM与缓冲区管理器的接口,局部可靠性协议-续,恢复信息 Log Undo Redo 原位更新 影子(shadowing)更新,局部可靠性协议-续,目的 保证在DB上执行的事务的原子性和持久性。协议描述了原语的执行过程 命令执行过程 Begin-Trans 登录 Read LRM先在Trans的缓冲区中读,若不在,则向缓冲区管理器发Fet

10、ch命令,读出数据后,LRM将它交给调度程序 Write 若在Buffer中得到,则在那更新,否则对Buffer Manager发Fetch命令,数据的前像和修改后的后像写入Log Abort 通过Log做Undo Commit 将事务结束记录入Log项,分布式可靠性协议,目的:维持在多个数据库上执行的事务的原子性和持久性 原语 Begin_Trans read, write, Abort, commit, recover 命令执行与局部协议类似 Read/write 使用ROWA规则,分布式可靠性协议-续,可靠性协议组成 包括提交、终结、恢复协议 终结协议 分布式系统特有的协议。若一个Sit

11、e故障,希望其它Site也停止该事务。 非阻断协议 允许Trans在非失效Site终结,而不必等待失效Site的恢复,改进Trans的响应时间。 独立的恢复协议 如何在发生失效时终结Trans, 而不必求助于其它Site,可以减少恢复时需要交换的信息。,分布式可靠性协议-续,终结协议与恢复协议的比较 假若一个Site失效 终结协议确定了为失效Site如何处理该失效事件 恢复协议确定失效Site重启动后,进程(协调者,参与者)恢复它的状态的过程 网络分割时 终结协议采取必要的措施来终结在不同网络区间执行的活动事务 当网络重新连接后,恢复协议保证使各个冗余DB相互一致,2PC协议,简单的能保证分布

12、式事务原子提交的协议,协调者,参与者,2PC-提交,协 调 者,参 与 者,2PC-夭折,集中式2PC,协调者 参与者,I,W,C,A,I,R,C,A,commit-申请申请-prepare*,no abort*,prepared* commit,commit ACK,申请-prepare prepared,申请-prepare no,abort ACK,F,ACK*,ACK*,标记: 输入消息输出消息 * = 每一个,当参与者进入“R”状态: 它必定已获得所有资源 它只能根据协调者指令提交或夭折 当所有参与者是在“R”时, 协调者才能进入“C” 状态, 即, 它一定最终能提交,2PC-续,2

13、PC讨论 参与者可以单方面撤销Trans,直至它作出肯定性的提议(单方面中止的时间是在其作出肯定提议之前) 一旦参与者确定了提交或撤销协议,它就不能更改它的提议。 参与者处于Ready状态,可以根据协调者发来的消息种类,直接转为Abort/Commit 全局提交必须是所有参与者共同作出的全局终结决定 通信故障出现时,协调者和参与者可能会出现互等状态,2PC-续,假撤销2PC和假提交2PC协议 改善2PC的性能 假撤销协议中,协调者不必等待参与者的ACK消息,减少了协调者与参与者之间传递消息的数量 假提交协议中,可以不将Prepare写入Log,减少了Log写入的次数,2PC的恢复协议,参与者在

14、Ready状态的恢复(1a) 此时P重启时通过识别Log中有Ready记录,没有Commit/Abort记录判定其在Ready状态,重启时询问协调者或其它Site。 协调者已发出Prepare命令 此时恢复程序可识别出Log中有Prepare记录,但没有“G-commit”/“G-abort”记录,重发命令 协调者已发出Global命令 恢复时识别出Log中“G-commit”/“G-abort”记录,重发命令,2PC中远程Site恢复问题,当P回答了Ready之后,还没有收到有关命令之前故障,需要远程Site之间交换信息,获取信息的方法有: 向协调者询问 若此时C也故障,则得不到回答,P被阻

15、断 重定向询问 向其它P询问,此时只要有一个P收到命令,则该P也可以获得命令(要求有关结束事务的信息也必须在P站点保留) 脱机方式 给每个Site分配一组脱机站点S(i), 当i故障时,所有有关i的信息都送到S(i)保留,Trans阻断与终结协议,Trans阻断 某个Site上本来可以终结(提交或撤销)的子事务,由于DDBS故障,必须等待到故障恢复(其占有的资源不释放) 阻断协议 发生某类故障时,使分布式Trans处于阻断状态 终结协议 允许事务在有故障情况下仍能正确结束,Trans阻断与终结协议-续,2PC协议是终结协议的条件 至少有一个Site已收到结果命令(该Site可以告知其它参与者) 没有一个参与者收到命令,并且只有协调者Site故障(可以新造协调者),2PC 阻断,例:Coord P2RP1 P3R RP4 R,2PC的终结协议,使用超时技术 协调者超时 在等待状态超时,可以决定“全局撤销” 在撤销/提交状态超时,重发“G-abort”/“G-commit” 参与者超时 在初始状态超时,单方面Abort 在Ready状态超时,被阻断,等待 设计终结协议,

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 生活休闲 > 社会民生

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号