@dyk
2015-07-12T08:52:57.000000Z
字数 3925
阅读 410
ReadingNote
NDSI'08 Best Paper
使虚拟机能在物理硬件失效的情况下面正常对外提供服务。带来的失效时间非常小几秒的失效时间。
可以使用当前的软件以及系统在没有修改的情况下透明的使用Remus。每秒大概能向backup节点同步信息达到40次以上。
并且将操作全部分解成一系列的复制快照
Remus的设计基于以下三个目标
Generality，通用性，让单一的应用能够支持高可用性的代价很高，需要让很大范围的应用软件都能享受高可用的支持，所以Remus的设计笔记基于底层进行
Transparency，透明性，Remus支持软件不做修改就运行在Remus上面
Seamless failure recovery，无缝的错误恢复，错误恢复必须很快并且让外部不能察觉，并且恢复之后不能产生外部的信息丢失即与外部的信息不一致，例如TCP链接必须保持一致。
方法：
（1），采用虚拟化技术试验全系统的复制技术
（2），我们采用speculative execution的方式提高主虚拟机的运行效率，即不用等待同步完成便运行下面的命令
现有的技术都是采用锁步的办法是两个虚拟机（主虚拟机以及备份虚拟机保持一致），并且严格按照确定的执行步骤进行，这样的机制将带来以下两个严重问题
（1），这样的方法对于系统的结构严格依赖，需要备份系统对于指令以及外部事件十分的了解
（2），这样的方法运用在多核系统中会带来严重的额外消耗。
Speculative execution
由于重放确定的输入将会导致很严重的额外消耗，由于对于同样一个输入的重放信息很有可能将会产生不一样的输出信息，所以Remus并不打算采用确定重放的技术。
并且在外部接收到可见的输出之前主虚拟机和备份虚拟机的状态需要同步。所以采用缓存的方法。并且在同步点之后将采用Speculative execution.
非同步的复制技术
由于有了输出的缓存所以允许主虚拟机以及备份虚拟机的状态能表现得不同步，主虚拟机可以在不等待备份虚拟机确认同步的情况下，继续执行下去。
由于以上的技术才使得检查点能够在十几MS的时间内完成
对Xen添加了细粒度的检查点设置的扩展
所有的外部的网络输出将全部暂存在缓冲区中知道主副虚拟机的状态一致。
不像外部的网络输出一样，磁盘的状态是外部不可见的，所有的磁盘状态也是非同步分传送方式传送给备份节点的RAM中，
直到达到同步完成的时间点之后，磁盘的修改也将从RAM中写入磁盘文件，并且备份节点通知主节点释放外部网络包。
值得注意的是除了主节点发生故障备份的虚拟机实际上并没有真正的执行命令，备份虚拟机只是左右一个快照的容器，这样做能十分
节省备份节点上面的资源,这样可以在一台物理节点上面备份多个虚拟机
Remus不会将主节点上面的软件错误以及失效停止的条件带到备份节点上面
流水线式的检查点
Remus采用积极的流水线方式来执行流水线操作，Remus将自动的捕捉运行时候的软件状态改变。如下图所示
执行的步骤被有效的离散化
检查点是基于Xen现有的实时迁移机制实现的。在原节点的虚拟机还在运行的时候便将内存复制到新的节点上面。在迁移的过程对于内存的写命令将被记录，
并且被修改的脏页也将复制到目的地，在几个周期之后或者再也没有需要同步的修改的产生，内存的脏页将和CPU状态一起传送到目的地点。
整个迁移的时间由 内存的大小 和 worklord中的写内存命令的多少有关
Xen提供了影子页表的机制来跟踪虚拟机的内存修改状态，
对于实时迁移
Xen将所有的修改写入内存并且保存一个自从上个周期到现在的脏页的映射表。每一个周期迁移进程在读取该映射表并且重新设置该映射表。
在迁移的最后，迁移进程将进入一个 停止——复制的阶段，在那个阶段所有剩余的内存页都复制到目的节点并且目的节点开始执行
Remus实现检查点的功能就像实时迁移的最后一个过程一样，在把修改的内存和CPU状态放入缓冲区之后主虚拟机继续运行而不是和迁移一样在备份节点上面恢复
由于迁移最后一个步骤的时间主要话费在虚拟机的调度上面，这个调度的低效是由于xenstore守护进程的实现并不合理
Remus为了优化同步检查点的过程采用了以下两个方法
（1），Remus减少了进程之间的挂起以及恢复虚拟机用户域的命令
（2），Remus在挂起和恢复的进程中完全移除了xenstore
由于原有的过程是 migration -》 xend -》 xenstore -》 event chanel -》 guset -》 hypercall -》 xenstore -》 interupt -》 xend -》 migration
500MS delay
Remus为客户虚拟机创建一个专用的事件通道，使migration进程能通过该通道挂起虚拟机
并且创建了一个新的超级调用，允许进程注册时间通道，为了接受虚拟机挂起完成的结果反馈
Remus 优化了内存复制的过程
（1）快速过滤感觉的内存页
（2）将客户机的内存全部映射给复制进程
检查点的支持
给 挂起到磁盘 以及 实时迁移做了修改
（1）在客户虚拟机被挂起之后允许恢复它的操作，之前Xen不支持实时检查点，在把虚拟机的状态写入磁盘后将立刻摧毁他
（2）将一次性启动的挂起进程修改了守护进程，这样可以在检查点周期中只复制新的脏页
支持重新恢复需要做以下两个修改
（1）一个新的超级调用，该调用能将domain标记为可调度的（(Xen removes suspended domains from scheduling consideration, because previously they were always destroyed after their state had been replicated）
不同步的传输
利用缓存
客户虚拟机的修改
以往的半虚拟客户机在挂起之后将disconnentct 所有的设备 除了CPU
这些修改都提高了Remus的性能，但是跟对于全虚拟化的虚拟机来说这些修改并不是必须的
绝大部分的网络协议不像TCP一样可靠，这样对于网络传输过程中肯定会产生包的丢失或者重复，所以保持备份的同时数据包严格的按照队列出售传输
输入的信息将立刻传入主虚拟机
输出信息在得到备份节点的确认之后 主虚拟机将给缓存区发送Release命令 释放网络包
Remus在备份节点上面保存了一个完整的磁盘镜像，在启动备份保护之前。
启动保护之后所有的磁盘修改将被记录并且传送给备份节点
这样的好处它让主虚拟机的磁盘一致保持的与崩溃一致的检查点状况
Remus同时只允许一个磁盘工作
Remus的磁盘缓存是基于Xen block tao module实现的，这个模块允许特权域的进程插入前端与后端驱动中间，记录磁盘的操作请求
虚拟机迁移，Remus在现有Xen的虚拟机实时迁移的基础上面做出了扩展，是的能够支持高频率的迁移记忆检查点。[3]的方法能将镜像迁移到目标的节点上面但是外界的网络连接不能保证。[4]号工作是对于本文的解决方案最相近的一种。[4]采用的解决方案是要求在远端的几点上面使用确定性重放，但是实际上重放的条件有很多的限制（在多核的CPU上面的扩展并不容易Cyrus: Unintrusive Application-Level Record-Replay for Replay Parallelism貌似这个是解决的方法）。
虚拟机日志以及重放虚拟机日志的功能能用在许多的其他方面，例如入侵检测系统。这个重放系统会想系统的被攻击或者出现错误的过程都重放。有时候也会只为了forensics目的。
Operating system replication[1,18,23,25],这些都是为了负载平衡的问题而支持迁移的。如果只迁移进程的话，原来的地方可能会留下很多相互依赖的进程（docker 整套迁移环境）。
Library Approaches有很多并行编程框架类似CoCheck[29]也支持迁移以及发生错误的时候的全分布系统的恢复。
Introspection Optimizations，实际上Remus同步的数据很多都并不是必要的。
Hardware virtualization support，
Log-structured datacenters，作者希望系统能够有效的存储不仅仅是数据，以及transient state。
[Brendan Cully]http://dblp.uni-trier.de/pers/hd/c/Cully:Brendan
Geoffrey Lefebvre
Dutch T. Meyer
Michael J. Feeley
Norman C. Hutchinson
Andrew Warfield
这个几个人都是在可靠计算以及日志重放恢复上面发表的多个文章