[论文札记]NSDI'05_Christopher Clark_Live Migration of Virtual Machines

[论文笔记]NSDI'05_Christopher Clark_Live Migration of Virtual Machines

Live Migration of Virtual Machines是剑桥大学学者Christopher Clark在2005年时的一篇著作。为之后的Xen中的XenMotion热迁移模块打下了坚实的基础。拜读此作作为进入云计算热迁移方向的敲门砖，读书笔记如下：

热迁移(live migration)的优势

1) 整个操作系统和其上运行的应用作为单个转移单元，避免的了进程级(process-level)迁移方法所需面对的难点。一方面，guest OS和VMM间的窄接口(narrow interface)规避了残余依赖(residual dependencies)；另一方面，在热迁移完成之后，原主机“退役”，这就在原主机需要维护的情况下十分有用。

2) 应用级(application-level)迁移是无法做到不宕机的，而整个VM级迁移将可以做到这一点。

3) 可以分化用户(users)和作业者(operator)的关注点。用户可以把在VM中运行的软件和服务全权委托给操作系统，且不需要为作业者提供OS级的访问权限；作业者不需关注VM中发生的任何细节问题，而只需对整个操作系统进行迁移操作。

热迁移所针对的情况

总的来说，热迁移对于集群管理员来说是一个强有力的工具。它把软硬件的注意事项分离，使得集群的硬件系统转变成单个连贯的管理域。在很多情况下，虚拟化搭配热迁移可以使得集群的管理效能更高。例如，1) 集群中的某台物理机需要维护的时候。需要把该主机从集群中移出，亦即管理员把其上运行的OS实例转移到其他集群节点上，释放原主机并对其进行维护； 2) 为了达到集群负载均衡，OS实例也需要在主机间迁移，以重新分配资源。

Xen热迁移技术所关注的问题

       Xen中的高性能迁移目前只支持本地热迁移，亦即企业数据中心内部的VM迁移。其中，需要解决的技术问题包括：

1) 最小化宕机时间(minimize the downtime)；

2) 优化迁移双方主机同步状态下的总迁移时间(consider the total migration time)；

3) 确保迁移所产生的资源竞争不会影响当前正在进行的服务和应用。

Xen热迁移技术也不支持本地块设备(local block device)，亦即虚拟机必须存储在网络文件系统中。

预拷贝式(Pre-Copy)热迁移

请参看 http://virtual.51cto.com/art/200907/139175.htm

可写工作集(Writable WorkingSets)

       在热迁移过程中，对原主机运行服务性能影响最大的是内存转移。预拷贝(Pre-Copy)热迁移的内存转移速度虽然不如纯粹的Stop-and-Copy方式那么快，但是它的宕机时间仅仅只有人类很难感知的几十至一百多毫秒。但是预拷贝式热迁移的缺点是，若拷贝过程中有些页面被改写了，那么这些页面在下一轮迭代时还需重传。但大部分的负载中只有少部分的内存页是被频繁更新的，这些页面在目的主机上是不需要被持续维护的。

       对于预拷贝式热迁移，最理想的情况是当前VM的内存一直没有被改写，这样的情况基本等于Stop-and-Copy方式。最糟糕的情况是，VM内存产生脏页的速度大于拷贝(带宽传输)的速度。一般情况下，负载中大部分的页面很少或从未被修改，这些页面适于预拷贝；剩下的少部分页面被频繁改写，这些页面适于Stop-and-Copy。这些被频繁改写的页面被称作可写工作集(WritableWorking Sets)。

       如图2，作者在512MB内存VM上对SPEC CINT2000测试集进行了完整的运行，得到了其在不同时刻的WWS曲线。其中涉及到了一系列顺序子项目，gzip vpr pcc…… X轴表示时间，Y轴表示4KB大小的脏页数量，时间间隔为8秒。由图可以观察得到，对于不同的负载，WWS的表现也不不同。比如”eon”几乎没有WWS，非常适合于热迁移；而”gap”在执行过程中持续地生成脏页(WWS)，使得迁移异常困难。

       基于以上的数据，我们可以根据大致的在每一个时间节点上WWS的表现，估算得到在最终Stop-and-Copy阶段需要传输的数据，继而得到估算的宕机时间downtime。

       图3-6分别展示了作者团队由四个不同的负载得到的实验结果。每一幅图包括了3个子图，子图之间不同的地方只有传输带宽，分别为128Mb/s,256Mb/s,512Mb/s。每一幅子图中，灰色柱状图表示每一个时间节点下的脏页数量（由记录得到），从上至下的4条曲线分别为经历过1-4次Pre-Copy迭代之后的服务宕机时间downtime。观察图可得：

1) 一般情况下，预拷贝式迁移比纯粹的Stop-and-Copy方式具有更好的性能(downtime更小)。

2) 迭代次数增加，downtime减少，但是在高带宽的背景下，这种减少的趋势会相应减小。所以迭代的次数是值得权衡的。

这使得我们得出这样的结论：对于越靠后的迭代（当然执行时间也相对越短），分配的带宽应当越大，这样才能使得最后的Stop-and-Copy阶段传输的最频繁的WWS所需时间相对最短。针对如果进行带宽调整，作者团队设计了一个速率自适应算法(Rate-Adaptive Algorithm)。

速率自适应算法(Rate-AdaptiveAlgorithm)

具体的算法流程应该的如下：

该算法的特点：

1) 在传输大部分不频繁写的内存页面时，传输速率较低；

2) 在传输WWS尤其是写密集的内存页面时，传输速率较高。

所带来的优势就是显而易见的：

1) 有效缩短宕机时间downtime；

2) 平均带宽以及CPU资源占用较低。

针对脏页的策略

       作者对多次实验得到的结果进行定性分析，推测页面变“脏”具有以下两点特性：

1) 时间聚集性。上一轮迭代中的脏页这一轮很可能也会变脏；

2) 物理聚集性。某一个页面变脏，则与之物理相邻的页面也极可能变脏，这意味着，若我们在一个物理簇中没有检测到变脏的页面，那么很有可能在这个簇里面所有应该变脏的页面被忽略了。

针对第一种特性，相应的策略为，当前轮迭代只传输上一轮变脏而这一轮没有变脏的页面，这在一定程度上减小了传输带宽；针对第二种特性，作者团队采用了对VM的物理内存空间进行伪随机序列扫描的策略。

准虚拟化优化策略

       对于迁移来说，所谓的准虚拟化是指，OS本身可以察觉自己将要被迁移，亦即它对迁移是有感知的。一下几种方法可以使迁移的效率得到提高：

1) “击晕”流氓进程。众所周知，流氓进程频繁读写内存，会瞬间造成WWS过大。作者团队的策略是创建一个监视进程，监视所有进程。当某一个进程的写故障超过40次(作者团队的经验数值)，就立即把其置入等待队列之中。

2) 对于一个典型的OS来说，任意时刻都存在着一定数量的空闲页，包括真正的空闲页以及冷缓存页。若在第一次Pre-Copy迭代中不传输这些页面，那么就会大大缩短传输时间。但是，若之后的工作需要读取这些页面，那么反而会付出比正常预拷贝机制更大的代价。

小结

之后，作者在第6章中进行了一系列实验，以佐证预拷贝热迁移的可行性和效率。并指出了日后的研究重点为：

1) 集群管理。也就是现在的XenCenter。

2) 广域网热迁移。

3) 对本地块设备进行迁移。现在的XenCenter中有一种以Template的形式新建虚拟机的策略应是以此而来。