@dyk
2015-07-12T13:47:05.000000Z
字数 3692
阅读 308
ReadingNote
DSN'14
这篇文章主要是对于各种云恢复策略的统计和介绍。
| 回滚策略 | 样例 |
|---|---|
| 云应用回滚 | 基于检查点的回滚 基于日志的回滚 |
| 容灾 | 异地容灾 云存储复制 |
| 虚拟机复制 | Remus |
| 容错 | Recovery Block, N-version Programming, Parallel， FTCloud |
| 云内部策略恢复 | FATE&DESTINI |
| 测试驱动脚本 | Chef mini test |
| 云操作错误解决 | 脚本/管理工具异常解决 |
| 云操作事务回滚 | 向前/向后回滚 |
| 云操作进程回滚 | 操作的undo&redo |
| 基于用户的回滚一用 | 回滚策略的生成 |
这个方法把云分布式系统当作一个互相交互的进程的集合。当错误发生时候将回滚错误发生进程以及受其影响的其他进程。而基于日志的方法将重放不确定性时间（用户输入等等）。
这一项技术是保护服务的持续性。一般都是采用多个复制放置物理性的灾害导致服务失效。
由于云的不确定性和云资源的不可见性。当失效发生时候立刻切换到备份。
解决错误的方法是让错误发生在一个系统里面，并不是移除错误。
Recovery Block，是一个结构化的冗余的程序模块，如果主模块错误，备用模块将被启用。
N-Verison，允许多个功能一样的程序独立地被生成。
Parallel，并行运行多个同样功能的程序，当第一个程序返回结果时候将会被当作最后的结果。
FTCloud，在云环境中针对不同的组件采用不同的策略（RB，NVPParallel等等。）
云内部的协议，例如HDFS的内部协议，他的可恢复的能力由具体的恢复策略而定。
采用异常处理来解决操作的运行时错误。
解决云事务的问题，例如（长时间的事务）。
SoCC'13 Poster
在对云应用做零星的操作的时候会反生服务失效的错误。例如 ，升级，重新部署配置，迁移，调度。他们中的很多是由进程的错误产生的。在现实的大规模的系统中进场有多个操作进程在并行发生，这样也将会加剧错误诊断和恢复的问题。现有的回滚恢复机制基本都是假设组件会随机的fail并且使用基于检查点的回滚恢复以及补偿行为[1],以及redundancy and rejuvenation方法[2]。这些回滚机制并不会考虑特定的操作进程，例如是由脚本运行的，还是人与云的API以及不确定的资源进行交互等等。另外的方法例如FATE/DESTINI就是针对由系统内部的协议实现的进程的，依赖于系统自身的系统来检测以及从bugs中恢复。我们针对的问题是对于外部的的零星的操作的。
作者的方法是显性的对操作进行建模和分析。作者将进程划分为有多个step组成的section。分离的标准可以由于不同的目的而发生改变，例如错误诊断，一致性检查，恢复。对于恢复来说，作者的初始化分类标准包括：
作者做出了一系列的声明代表了每个阶段执行的期望程序结果。作者使用了运行时的assertion评估以及监控系统[3]来检测每个section结束之后的错误并且在需要的时候出发回滚恢复操作。
作者在AWS的应用成立的一个典型的AMI驱动的rolling upgrade 进程上面应用了作者的方法。Netflix也有一个Asgard的工具支持这个进程。作者用他自己的分类方法将Asgard的内部回滚恢复组件与错误处理机制给分开了。作者同时也在一些section的结尾加入了能够触发日志的assertion评估。作者的程序能够更早检测到可能被Asgard遗漏的错误。作者发现Asgard并没有为re-executin设计相应的粒度以及idempotence幂等性所以在Asgard选中的代码段并不能执行基于re-execution的回滚恢复操作。我们为了从一些的错误中恢复设计了一些可以替代的外部命令。例如，对于一些意外停止的一些实例，可以重新启动它们或者kill这些实例然后依靠auto-scaling的组来重新启动他们。作者的回滚恢复的消耗明显低于Asgard。
现在，为了能够让操作者能够更加简单的设计与实现他们的原子操作的脚本，re-execution块以及为了恢复目的而设计的可替换的指令，作者开了patterns和frameworks。作者也将这些和assertion评估和监控框架进行了结合[4]。
当云用户在对云应用执行roll upgrade操作的是有，由于云的不确定性，错误可能会发生。这些错误将妨碍正常操作以及导致错误的配置信息。例如调用不可靠的云API操作，有与API的长时间未有responde，将会导致rolling upgrade操作产生不可预测的错误。解决策略是1)补偿性的undo&redo以及1)修复。
在云平台的应用在部署，升级，重新配置等等的阶段，错误将会导致操作的失败。例如，云的API的不确定性。解决问题的一个方案就是recovery。现有的方案例如异常处理机制，不能解决一些跨平台跨语言的异常问题。作者提出的方案要在不用修改原有的系统的情况下面加入recover的功能来恢复云平台的sporadic操作的错误。
Recovery for Failures in Rolling Upgrade on Clouds
[19][25] Data derivation Graph的工作在进程回滚的时候主要系统内容知识使用。DDG能够记录数据是如何产生的，如何传递的，以及如何执行的。
对于Long-Running Transactions，一般采用的操作是backward recovery以及forward recovery
本系列文章都是针对不同的云的层次的错误发生的问题提出了相应的解决办法。这些策略以往也是存在的，只不过作者的解决方案更加的优化。