理解逆虛擬機拷貝(Reverse Virtual Machine Replication) - 上

http://ieeexplore.ieee.org/do...

虛擬機拷貝是經過從主(物理)機向備機反覆熱遷移虛擬機(virtual machine live migration)，在事故發生時將虛擬機在備機拉起的技術。在正常運行時，備機的虛擬機處於休眠狀態。這個休眠說的更具體點，從機器角度看，不執行指令；從網絡角度看，不回ARP。

傳統的虛擬機拷貝(virtual machine replication)是這麼作的：

1. 主備機都連在同兩個局域網段，一根線用來傳業務網絡包，一根線用來傳拷貝網絡包；

2. 對於路由器來講，在正常運行期間，永遠看到的是主機（由於ARP有回包）；

3. 對虛擬機進行高速拷貝，並熱遷移至備機。這個頻率通常在一秒鐘幾回到十幾回；

4. 在遇到硬件故障時，拉起備機；

5. 讓備機主動發送網絡包來更新局域網其餘節點，尤爲是路由器，和交換機的信息，使其網絡可見。

難點來了，即便在很高頻次的拷貝，仍是會有狀態不一致的狀況（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)就是主要解決以上兩個問題的。具體機制在下文講述。