Introduction
这篇是以华中科大刘海坤博士等人在2009年HPDC大会上的LiveMigrationofVirtualMachineBasedonFullSystemTraceandReplay来进行讨论的。
05年的时候,Xen和VMWare分别推出了里程碑式的关于热迁移方面的论文[1]和[2],相继提出了pre-copy式的方案,所针对的应用场景皆为同一子网下的LAN。该方案中要迁移的内容大致分3种:1)VM的物理内存。这是最棘手的,因为直接影响到了downtime;2)网络链接和虚拟设备的状态;3)SCSI存储。尽管pre-copy式的热迁移可以大幅减少downtime至毫秒级别,但是仍然有一些问题没有解决:
1)仅限于目前的LAN,因为它无法应对脏页生产速率大于用于迁移的网络带宽的情况;
2)在[1]中提出的”para-virtualizationoptimizations”策略虽然一定程度上优化了WWS过大的问题和减少了不必要的freepages,但也降低了用户的experience,这对一些交互性敏感的服务是致命的(比如低延迟的服务)。
3)没有考虑到CPU缓存数据。尽管不一定会导致targethost出错,但大量的缓存和TLBmissing也许会使VM接手的服务性能下降。
所以,作者基于Revirt[3]提出了CR-TRMotion迁移策略,其目的是为了减少需要传输的总数据,并巧妙地把原本需要传输的数据,利用targethost闲置的资源根据log文件进行replay,使热迁移应用在WAN/MAN下成为可能。
Design
(1)Strategy
CT-RT的基本策略是:首先,sourcehost以copy-on-write的方式生成一个对guestOS透明的checkpoint,并传输给targethost。然后,targethost接收checkpoint完毕,返回消息,sourcehost就以一定时间间隔不断发送logfile,直到达到某终止条件。此期间,sourcehost不停运行service,targethost则不断根据接收得到的logfile进行基于checkpoint的回放。达到终止条件,sourcehost在传输完最后的logfile之后suspend,targethost则在回放完最后的filelog之后接手service。
(2)MigrationProcess
根据论文[3-5],对于大多数负载而言,log的增长速率是小于1MB/s的,相较于LAN的1Gb/s小很多。而且,log的回放速度必然是大于log的增长速度的,因为在进程在普通执行过程当中会阻塞等待I/O事件,而回放则会skip掉HLT指令造成的空闲等待时间。所以作者们有了一下的设计实现CT-RT的过程,如图1:
Initialization。选择资源充足的targethost,正确的选择会加速迁移并增进QoS。
Reservation。A(sourcehost)发送迁移请求至B(targethost),并保证B有足够的资源。
Checkpointing。A冻结,并在此瞬间把系统状态以COW的方式复制入一个imagefile。完毕后A照常运行。
IterativeLogTransferring。第一轮迭代,传输checkpointfile至B,期间,A把non-deterministicsystemevents记录在logfile中。接下来的迭代,A传输上一轮迭代中产生的logfile至B,B则从checkpointfile中恢复并不断回放接收到的logfile。因为,log的传输远远比生产速度快,所以总会收敛的。
Waiting-and-Chasing。在经历过若干此迭代之后,上一轮产生的logfile大小小于了设定的某个阈值的时候(作者们默认设定的是1KB),A询问B是否可以进入Stop-and-Copy阶段,若B回放速度不够快,比如B上未使用的logfile文件大小超过了设定的阈值,B会告知A推迟Stop-and-Copy阶段直到B把logfile回放完毕或达到指定阈值。当然,若B的回放速度足够快,这一阶段是可以跳过不进行的。
Stop-and-Copy。Asuspend,B接收完剩下的logfile(非常小,小于设定的阈值),并回放之。此时A和B基本一致,若B宕机,A仍然可以恢复运行(post-copy则不行)。
Commitment。B告知A,它已经成功同步了运行状态。A承认了迁移事物,并把所有网络重定向给B,这个时候A才真正停止工作,可以销毁。
ServiceTakingover。B接管A的services。
(3)AlgorithmAnalysis
接下来,作者进行了理论上的算法分析。首先是在fastsynchronization的环境下,该情况下log的回放速度较高,所以可以略过Waiting-and-Chasing阶段。具体过程如图2:
然后在SynchronizationwithWaiting-and-Chasing的情况下进行分析。如图3:
由以上两种情况经过理论推算得到总结论,以下趋势对CT-RT式迁移有利:1)checkpoint文件越小;2)networkbandwidth越大;3)log增长率越小。其中前两个影响因子比第3个要大。
根据推理得到的公式可知,CT-RT方法中造成downtime的因素为finallogfile的传输时间,filelogfile的replay时间以及其他时间(启动,交接服务)。而在fastsynchronization情况下,TMT(总传输时间)主要组成成分为传输checkpoint的时间加上所有logfile的传输时间,而TDT(总传输数据)则为TMT*网络带宽;在SynchronizationwithWaiting-and-Chasing情况下,TMT则不是单纯的TDT/网络带宽,而是checkpoint和logfile1的传输时间加上logfile1-logfilen的回放时间。
Implementation
(1)SystemStructure
如图6:
系统基本是基于Revirt的,只是为了实现策略,修改了loggingmodule并且把日志数据流指向了NIC。VMMkernelmodule和kernelhooks把log记录在hostkernel内存的循环缓冲区中,user-leveldaemon把缓冲区中的数据传输给targethost。
Revirt和现行的pre-copy机制,并不能很好的契合CT-RT,所以进行了如下两项主要修改和优化。
(2)COWCheckpointing
针对Revirt不能进行runtimecheckpointing的缺陷,作者引入了COW机制。过程如下:1)checkpoint请求被受理,VM立即suspend并记录下VCPU的状态,所有VM内存页设置为read-only;2)VM恢复并运行,与此同时,所有内存页面复制入网络传输buffer,并通过网络传输给targethost。在该过程中,所有变脏的页面首先复制到COWbuffer中,然后才被replication提取到网络传输buffer。3)当所有页面被复制,才一齐进行传输。
(3)LocalDeviceMigration
和pre-copy以及post-copy不同,CT-RT若不加限制,可能会对NAS中的同块数据进行先后读写,比如sourcehost先行读写之后,targethost回放再次进行读写。作者们针对此问题采取了对应的方法。对所有在sourceVM上对磁盘的读操作进行拦截并把其相关字节记录在logfile中,在targethost回放期间,所有targetVM对磁盘的读操作也被禁止,并重定向到logfile。在回放期间,所有对磁盘的写操作也被禁止,因为操作并没有改变文件的状态。
Conclusion
CT-RT和pre-copy实现的机制比较类似,区别在于传输的内容不是内存页面而是logfile,所以对带宽的要求并不那么苛刻,总迁移时间和downtime明显缩短,对runningservice影响较小,并且对写密集应用有更好的适用性。需要注意的是对NAS的访问机制要稍加修改,并需要优化Revirt系统的checkpointing,以适应本方法的特殊要求。
但是,在多核环境下,记录和回放内存race的代价是昂贵的。作者们想到的应对策略(未实现)是用VCPU的热插技术,在migration时设置成单VCPU,完成时再设置回来。这种牺牲性能的方法,需要经过实验和pre-copy进行比较,得到在多核环境下的迁移最佳方案。
Reference
[1]LiveMigrationofVirtualMachines
[2]Fasttransparentmigrationforvirtualmachines
[3]ReVirt:Enablingintrusionanalysisthroughvirtual-machineloggingandreplay
[4]ExecRecorder:VM-BasedFull-SystemRelayforAttackAnalysisandSystemRecovery
[5]Retrace:Collectingexecutiontracewithvirtualmachinedeterministicreplay