http://ieeexplore.ieee.org/do…
虚拟机拷贝是通过从主(物理)机向备机反复热迁移虚拟机(virtual machine live migration),在事故发生时将虚拟机在备机拉起的技术。在正常运行时,备机的虚拟机处于休眠状态。这个休眠说的更具体点,从机器角度看,不执行指令;从网络角度看,不回ARP。
传统的虚拟机拷贝(virtual machine replication)是这么做的:
主备机都连在同两个局域网段,一根线用来传业务网络包,一根线用来传拷贝网络包;
对于路由器来说,在正常运行期间,永远看到的是主机(因为ARP有回包);
对虚拟机进行高速拷贝,并热迁移至备机。这个频率一般在一秒钟几次到十几次;
在遇到硬件故障时,拉起备机;
让备机主动发送网络包来更新局域网其他节点,尤其是路由器,和交换机的信息,使其网络可见。
难点来了,即使在很高频次的拷贝,还是会有状态不一致的情况(state inconsistency)。具体是这么产生的:
C:client S:Server 数字:包顺序 SB:Server Backup
C–1->S SB
C<-1–S…SB
C–2->S SB
C<-2–S(挂了,2更新了的状态还没同步给备机)
拉起SB
C–3->SB(SB:2都还没传,你传3给我干嘛)
在论文里面,这个2的回包被称作最后一口气包(lasp gasp packet)。这个状态不一致指的是C和SB的之间的。C认为我要传3,SB认为你应该是2。
那传统虚拟机拷贝是怎么来应对这个最后一口气包的呢,他在主机回包那里加了一层缓存墙,
C–1->S SB
C |1<-S…SB(同步成功了后)
C<-1 S SB
C–2->S
C |2<-S(挂了,2更新了的状态还没同步给备机)
拉起SB
C–2->SB(SB:没毛病)
其实他就是把拷贝和回包做成了同步阻塞操作,S挂掉以后,还没来得及拷贝的虚拟机状态随着最后一口气包一起干掉。有经验的同学很快能看出来,这个对性能会有极恶劣的影响的。并且,为了保证回包缓存不爆炸,传统虚拟机拷贝技术一定要保证非常快的拷贝频率,对系统的压力更是雪上加霜。
逆虚拟机拷贝(reverse virtual machine replication)就是主要解决以上两个问题的。具体机制在下文讲述。