《The Design of a Practical System for Fault-Tolerant Virtual Machines》——容错虚拟机，中文翻译
一個實用的容錯虛擬機系統
Daniel?J.?Scales,?Mike?Nelson,?and?Ganesh?Venkitachalam
VMware公司
{scales、mnelson?ganesh}?@vmware.com
原文地址：http://nil.csail.mit.edu/6.824/2018/papers/vm-ft.pdf
摘要
我們實現了一個商業企業級系統，用于提供容錯虛擬機，該系統基于通過另一臺服務器上的備份虛擬機復制主虛擬機(VM)執行的方法。 我們在VMware?vSphere?4.0中設計了一個完整的系統，該系統易于使用，運行在普通服務器上，通常實際應用程序的性能降低不到10%。 此外，對于幾個實際應用程序，保持主VM和輔助VM同步執行所需的數據帶寬小于20?Mbit/s，這允許在更長的距離上實現容錯。 一個易于使用的商業系統，在失敗后自動恢復冗余，除了復制VM執行外，還需要許多其他組件。 我們設計并實現了這些額外的組件，解決了在支持運行企業應用程序的vm時遇到的許多實際問題。 在本文中，我們描述了我們的基本設計，討論了備選的設計選擇和一些實現細節，并為微基準測試和實際應用程序提供了性能結果。
目錄
- 一個實用的容錯虛擬機系統
- 1. 介紹
- 2. 基本的FT的設計
- 2.1 確定性重放的實現
- 2.2 FT的協議
- 2.3 檢測和響應故障
- 3. FT的實際應用
- 3.1 啟動和重新啟動FT?vm
- 3.3 操作FT虛擬機
- 3.4 磁盤IOs的實現問題
- 3.5 網絡IO的實現問題
- 4. 設計方案
- 4.1 共享磁盤與非共享磁盤
- 4.2 在備份VM上執行磁盤讀操作
- 5. 績效評估
- 5.1 基本的性能結果
- 5.2 網絡基準
- 6. 相關工作
- 7. 結論與未來工作
- 8. 參考文獻
1. 介紹
實現容錯服務器的一種常見方法是主/備份方法[1]，在主服務器發生故障時，總是可以使用備份服務器進行接管。 備份服務器的狀態必須始終保持與主服務器幾乎相同，以便在主服務器發生故障時，備份服務器可以立即接管，并且以這種方式將故障隱藏在外部客戶機中，不會丟失任何數據。 在備份服務器上復制狀態的一種方法是幾乎連續地將主服務器的所有狀態(包括CPU、內存和I/O設備)的更改發送到備份。 然而，發送此狀態(內存中的特定更改)所需的帶寬可能非常大。
另一種可以使用更少帶寬的復制服務器的方法有時被稱為statemachine方法[13]。 其思想是將服務器建模為確定性狀態機，這些狀態機從相同的初始狀態啟動，并確保它們以相同的順序接收相同的輸入請求，從而保持同步。 由于大多數服務器或服務具有一些不確定的操作，因此必須使用額外的協調來確保主服務器和備份保持同步。 但是，保持主服務器和備份同步所需的額外信息量遠遠小于主服務器中正在更改的狀態量(主要是內存更新)。
實現協調以確保物理服務器[14]的確定性執行是困難的，特別是在處理器頻率增加的情況下。 相反，運行在管理程序之上的虛擬機(VM)是實現狀態機方法的優秀平臺。 VM可以被認為是定義良好的狀態機，其操作是被虛擬化的機器的操作(包括它的所有設備)。 與物理服務器一樣，vm也有一些不確定的操作(例如讀取一個時鐘時間或發送一個中斷)，因此必須將額外的信息發送到備份，以確保其保持同步。 由于系統管理程序完全控制VM的執行，包括所有輸入的交付，所以系統管理程序能夠捕獲主VM上關于不確定性操作的所有必要信息，并在備份VM上正確地重播這些操作。
因此，狀態機方法可以在普通硬件上為虛擬機實現，而不需要修改硬件，允許對最新的微處理器立即實現容錯。 此外，狀態機方法所需的低帶寬允許對主服務器和備份進行更大的物理分離。 例如，復制的虛擬機可以在跨校園分布的物理機器上運行，這比在同一建筑物中運行的vm提供了更高的可靠性。
我們在VMware?vSphere?4.0平臺上使用主/備份的方式實現了容錯vm，該平臺能夠高效運行完全虛擬化的x86虛擬機。 因為VMware?vSphere實現了一個完整的x86虛擬機，所以我們可以自動為任何x86操作系統和應用程序提供容錯能力。 允許我們記錄主服務器的執行并確保備份以相同方式執行的基本技術稱為確定性重放[15]。 VMware?vSphere容錯(FT)是基于確定性重放的，但是增加了必要的額外協議和功能來構建一個完整的容錯系統。 除了提供硬件容錯之外，我們的系統還通過在本地集群中任何可用的服務器上啟動一個新的備份虛擬機，在出現故障后自動恢復冗余。 此時，確定性回放和VMware?FT的生產版本都只支持單處理器vm。 記錄和回放多處理器VM的執行仍然在進行中，存在嚴重的性能問題，因為對共享內存的幾乎每次訪問都可能是不確定的操作。
Bressoud和Schneider[3]描述了一個原型imple- HP PA-RISC平臺容錯vm的配置。
圖1:基本FT配置。
我們的方法是類似的，但是由于性能的原因，我們做了一些基本的改變，并研究了一些設計方案。 此外，我們必須在系統中設計和實現許多額外的組件，并處理許多實際問題，以構建一個完整的系統，該系統對于運行企業應用程序的客戶來說是高效和可用的。 與討論的大多數其他實際系統類似，我們只嘗試處理故障停止故障[12]，即在故障服務器導致錯誤的外部可見操作之前可以檢測到的服務器故障。
論文的其余部分組織如下。 首先，我們描述了我們的基本設計和詳細的基本協議，這些協議確保在主VM失敗后，如果備份VM接管了主VM，不會丟失任何數據。 然后，我們詳細描述了構建一個健壯、完整和自動化的系統必須解決的許多實際問題。 我們還描述了實現容錯vm時出現的幾種設計選擇，并討論了這些選擇中的權衡。 接下來，我們將給出一些基準測試和一些實際企業應用程序實現的性能結果。 最后，對相關工作進行了描述和總結。
2. 基本的FT的設計
圖1顯示了我們的系統的基本設置。 對于我們希望為其提供容錯的給定VM(主VM)，我們在不同的物理服務器上運行備份VM，該服務器保持同步并與主虛擬機執行相同，只是有一點時間延遲。 我們說這兩個vm是同步的。 VM的虛擬磁盤位于共享存儲上(例如Fibre?Channel或iSCSI磁盤陣列)，因此主VM和備份VM可以訪問它們的輸入和輸出。 (我們將在第4.1節中討論主VM和備份VM具有獨立的非共享虛擬磁盤的設計。) 只有主VM通知它在網絡上的存在，因此所有網絡輸入都進入主VM。 類似地，所有其他輸入(如鍵盤和鼠標)都只進入主VM。
主VM接收的所有輸入都通過一個稱為日志通道的網絡連接發送到備份VM。 對于服務器工作負載，主要的輸入流量是網絡和磁盤。 為了確保備份VM以與主VM相同的方式執行非確定性操作，需要傳輸額外的信息(如下面的2.1節所述)。 結果是備份VM總是與主VM執行相同。 但是，備份VM的輸出會被系統管理程序刪除，因此只有主VM產生返回給客戶機的實際輸出。 如第2.2節所述，主VM和備份VM遵循特定的協議，包括備份VM的顯式確認，以確保在主VM失敗時不會丟失任何數據。
為了檢測主VM或備份VM是否失敗，我們的系統使用相關服務器之間的心跳和日志通道上的流量監控的組合。 此外，我們必須確保主VM或備份VM中只有一個接管執行，即使出現主服務器和備份服務器彼此失去通信的splitbrain情況。
在下面的小節中，我們將提供幾個重要領域的更多細節。 在第2.1節中，我們詳細介紹了確定性重放技術，它確保主vm和備份vm通過日志通道發送的信息保持同步。 在第2.2節中，我們描述了我們的FT協議的一個基本規則，它確保在主節點失敗時不會丟失數據。 在第2.3節中，我們描述了以正確的方式檢測和響應故障的方法。
2.1 確定性重放的實現
如前所述，復制服務器(或VM)的執行可以建模為確定性狀態機的復制。 如果兩個確定性狀態機以相同的初始狀態啟動，并以相同的順序提供完全相同的輸入，那么它們將經歷相同的狀態序列并產生相同的輸出。 虛擬機有一組廣泛的輸入，包括傳入的網絡數據包、磁盤讀取以及鍵盤和鼠標輸入。 非確定性事件(如虛擬中斷)和非確定性操作(如讀取處理器的時鐘周期計數器)也會影響VM的狀態。 提出了三個挑戰復制執行任何操作系統和虛擬機運行工作負載:(1)正確捕獲所有必要的輸入和非確定性,確保確定性執行備份虛擬機,(2)正確應用備份虛擬機的輸入和非確定性,和(3)這樣的方式不會降低性能。 此外，x86微處理器中的許多復雜操作都有不確定的副作用。 捕獲這些未定義的副作用并將其重新播放以產生相同的狀態是一個額外的挑戰。
VMware?replay[15]正是為VMware?vSphere平臺上的x86虛擬機提供了這一功能。 確定性重放記錄VM的輸入和與VM執行相關的所有可能的不確定性，記錄在日志文件的日志條目流中。 稍后，通過從文件中讀取日志條目，可以準確地重放VM執行。 對于不確定的操作，將記錄足夠的信息，以允許使用相同的狀態更改和輸出復制操作。 對于不確定的事件，如定時器或IO完成中斷，事件發生的確切指令也會被記錄下來。 在重放期間，事件在指令流中的同一點被交付。 VMware確定性回放實現了一種高效的事件記錄和事件傳遞機制，該機制采用了多種技術，包括使用與AMD[2]和Intel[8]聯合開發的硬件性能計數器。
Bressoud和Schneider[3]提到將VM的執行劃分為epoch，在其中，諸如中斷之類的非確定性事件只在epoch結束時交付。 epoch的概念似乎被用作一種批處理機制，因為它太昂貴了，不能在每個中斷發生的確切位置上分別交付它們。 但是，我們的事件交付機制非常有效，VMware的確定性重放不需要使用epoch。 每次中斷發生時都會被記錄下來，并在回放時有效地按適當的指令進行傳送。
2.2 FT的協議
對于VMware?FT，我們使用確定性重放來生成必要的日志條目來記錄主VM的執行，但是我們不將日志條目寫入磁盤，而是通過日志通道將它們發送到備份VM。 備份VM實時回放這些條目，因此與主VM執行相同。 但是，我們必須在日志通道上使用嚴格的FT協議來增加日志條目，以確保實現容錯。 我們的基本要求是:
輸出要求:如果備份VM曾經
主虛擬機發生故障后，備份虛擬機將繼續以與主虛擬機發送到外部世界的所有輸出完全一致的方式執行。
請注意，在發生故障轉移之后(即，備份VM在主VM發生故障后接管)，備份VM的啟動方式可能與主VM繼續執行的方式非常不同，因為在執行期間會發生許多不確定的事件。 但是，只要備份VM滿足輸出要求，在故障轉移到備份VM期間就不會丟失外部可見的狀態或數據，客戶機也不會注意到它們的服務中沒有中斷或不一致。
輸出需求可以通過延遲任何外部輸出(通常是一個網絡包)來確保，直到備份VM已經接收到所有信息，這些信息將允許它至少重播執行到輸出操作的那一點。 一個必要的條件是，備份VM必須接收到輸出操作之前生成的所有日志條目。 這些日志條目將允許它執行到最后一個日志條目。 但是，假設在主服務器執行輸出操作之后立即發生故障。 備份VM必須知道，它必須一直重播到輸出操作的那一點，并且在那一點上只“運行”(停止重播并接管主VM，如2.3節所述)。 如果備份在輸出操作之前的最后一個日志條目上運行，一些不確定的事件(例如，發送到VM的計時器中斷)可能會在執行輸出操作之前更改其執行路徑。
根據上面的約束，實現輸出需求的最簡單方法是創建一個特殊的日志條目
圖2:FT協議。
每個輸出操作。 然后，輸出需求可以通過這個特定的規則來執行:
輸出規則:主VM可能不會向外部世界發送輸出，直到備份VM接收并確認與產生輸出的操作相關的日志條目。
如果備份虛擬機已經收到了所有的日志條目,包括output-producing操作的日志條目,然后備份虛擬機將能夠完全復制主虛擬機的狀態輸出點,所以如果主死了,備份將正確地看到一個狀態,輸出一致。 相反，如果備份VM在沒有接收所有必需的日志條目的情況下接管，那么它的狀態可能會很快偏離，從而與主服務器的輸出不一致。 輸出規則在某些方面類似于[11]中描述的方法，在這種方法中，“外部同步”IO實際上可以被緩沖，只要它在下一次外部通信之前被實際寫入磁盤。
注意，輸出規則并沒有說任何關于停止主VM執行的內容。 我們只需要延遲輸出的發送，但是VM本身可以繼續執行。 由于操作系統執行非阻塞網絡和磁盤輸出，并使用異步中斷來指示完成，所以VM可以很容易地繼續執行，而且不一定會立即受到輸出延遲的影響。 相反，以前的工作[3,9]通常表明，在執行輸出之前，主VM必須完全停止，直到備份VM從主VM確認了所有必要的信息。
作為一個例子，我們在圖2中展示了說明FT協議要求的圖表。 該圖顯示了主vm和備份vm上的事件時間軸。 從主行到備份行的箭頭表示日志條目的轉移，從備份行到主行的箭頭表示確認。 有關異步事件、輸入和輸出操作的信息必須作為日志項發送到備份并得到確認。 如圖所示，外部世界的輸出被延遲，直到主VM從備份VM接收到與輸出操作相關的日志條目的確認。 如果遵循了輸出規則，那么備份VM將能夠以與主服務器的最后輸出一致的狀態接管。
我們不能保證在故障轉移情況下，所有輸出都只生成一次。 在主服務器打算發送輸出時，如果不使用具有兩階段提交的事務，備份就無法確定主服務器在發送最后一個輸出之前或之后立即崩潰。 幸運的是，網絡基礎設施(包括TCP的常見使用)被設計用來處理丟失的包和相同的(重復的)包。 請注意，到主服務器的傳入包也可能在主服務器故障期間丟失，因此不會傳遞到備份服務器。 然而，傳入的數據包可能由于與服務器故障無關的任何原因被丟棄，所以網絡基礎設施、操作系統和應用程序都被編寫來確保它們能夠補償丟失的數據包。
2.3 檢測和響應故障
如上所述，如果其他VM出現故障，主VM和備份VM必須快速響應。 如果備份VM失敗，主VM將啟動—也就是說，保留記錄模式(因此停止在日志通道上發送條目)，并開始正常執行。 如果主VM失敗，備份VM也應該啟動，但是過程要復雜一點。 由于執行的延遲，備份VM可能會有許多它已經接收和確認的日志條目，但是還沒有被使用，因為備份VM的執行還沒有達到適當的點。 備份VM必須繼續從日志條目中重播它的執行，直到它消耗完最后一個日志條目。 此時，備份VM將停止重播模式，并開始作為普通VM執行。 實際上，備份VM已經升級到主VM(現在缺少一個備份VM)。 由于它不再是一個備份VM，新的主VM現在將在來賓操作系統執行輸出操作時向外部世界生成輸出。 在轉換到正常模式期間，可能需要一些特定于設備的操作來允許正確地執行此輸出。 特別是，為了聯網，VMware?FT會自動通知網絡上新主VM的MAC地址，這樣物理網絡交換機就知道新主VM位于哪個服務器上。 此外，新升級的主VM可能需要重新發行一些磁盤IOs(如3.4節所述)。
有許多可能的方法可以嘗試檢測主vm和備份vm的故障。 VMware?FT在運行容錯vm的服務器之間使用UDP心跳來檢測服務器何時可能崩潰。 另外，VMware?FT監視從主VM發送到備份VM的日志流量，以及從備份VM發送到主VM的確認。 由于定期的計時器中斷，日志記錄流量應該是定期的，并且對于功能正常的來賓操作系統永遠不應該停止。 因此，日志條目或確認流中的停頓可能表示VM失敗。 如果心跳或日志流量停止的時間超過了特定的超時時間(大約幾秒)，就會聲明失敗。
然而，任何這樣的故障檢測方法都容易受到裂腦問題的影響。 如果備份服務器停止接收來自主服務器的心跳，這可能表明主服務器已經失敗，或者可能只是意味著仍然在運行的服務器之間的所有網絡連接已經丟失。 如果備份VM在主VM實際仍在運行時啟動，則可能會出現數據損壞和與VM通信的客戶端出現問題。 因此，我們必須確保在檢測到故障時主VM或備份VM中只有一個是活動的。 為了避免裂腦問題，我們使用了存儲VM虛擬磁盤的共享存儲。 當主VM或備份VM希望啟用時，它將在共享存儲上執行一個原子測試集操作。 如果操作成功，則允許VM運行。 如果操作失敗，那么另一個VM肯定已經啟動了，所以當前VM實際上會停止自己(“自殺”)。 如果VM在嘗試執行原子操作時無法訪問共享存儲，那么它將一直等待，直到可以訪問為止。 注意，如果共享存儲由于存儲網絡中的某些故障而無法訪問，那么VM可能無法進行有用的工作，因為虛擬磁盤駐留在相同的共享存儲上。 因此，使用共享存儲來解決分裂大腦的情況不會引入任何額外的不可用性。
該設計的最后一個方面是，一旦發生故障，其中一個VM已經上線，VMware?FT會在另一臺主機上啟動一個新的備份VM，從而自動恢復冗余。 雖然這個過程在以前的大多數工作中沒有涉及，但是它是使容錯vm有用的基礎，并且需要仔細的設計。 更多細節見3.1節。
3. FT的實際應用
第2節描述了FT的基本設計和協議。然而，要創建一個可用的、健壯的、自動化的系統，還必須設計和實現許多其他組件。
3.1 啟動和重新啟動FT?vm
必須設計的最大的附加組件之一是啟動與主VM處于相同狀態的備份VM的機制。 當發生故障后重新啟動備份VM時，也將使用此機制。 因此，對于處于任意狀態(即不只是啟動)的正在運行的主VM，此機制必須是可用的。 此外，我們希望該機制不會顯著地中斷主VM的執行，因為這將影響VM的任何當前客戶機。
對于VMware?FT，我們采用了VMware?vSphere現有的VMotion功能。 VMware?VMotion[10]允許將一個運行中的VM從一個服務器遷移到另一個服務器，而對其造成的干擾最小——VM暫停時間通常小于一秒。 我們創建了一個修改過的VMotion表單，它在遠程服務器上創建了一個VM的精確運行副本，但不會破壞本地服務器上的VM。 也就是說，我們修改后的FT?VMotion將VM克隆到遠程主機，而不是遷移它。 FT?VMotion還設置了一個日志通道，并導致源VM進入日志記錄模式作為主要的，而目標VM進入回放模式作為新的備份。 與普通的VMotion一樣，FT?VMotion通常會在不到一秒的時間內中斷主VM的執行。 因此，在運行的VM上啟用FT是一種簡單、無干擾的操作。
啟動備份VM的另一個方面是選擇運行它的服務器。 容錯vm運行在能夠訪問共享存儲的服務器集群中，因此所有vm通常可以運行在集群中的任何服務器上。 這種靈活性使得VMware?vSphere甚至可以恢復FT冗余
圖3:FT日志緩沖區和通道。
一個或多個服務器發生故障。 VMware?vSphere實現了一個集群服務，用于維護管理和資源信息。 當發生故障時，主VM現在需要一個新的備份VM來重新建立冗余，主VM會通知集群服務它需要一個新的備份。 集群服務根據資源使用情況和其他約束來確定運行備份VM的最佳服務器，并調用FT?VMotion來創建新的備份VM。 其結果是，VMware?FT通常可以在服務器發生故障后幾分鐘內重新建立VM冗余，而在執行容錯VM時不會出現任何明顯的中斷。
3.2 管理日志通道
在管理日志通道上的流量方面，有許多有趣的實現細節。 在我們的實現中，管理程序為主vm和備份vm的日志記錄條目維護了一個大型緩沖區。 當主VM執行時，它將日志條目生成到日志緩沖區中，類似地，備份VM從其日志緩沖區中使用日志條目。 主日志緩沖區的內容將盡快被清除到日志通道，日志條目一到達日志通道就被從日志通道讀入備份的日志緩沖區。 每次從網絡將一些日志條目讀入其日志緩沖區時，備份都會將確認發送回主服務器。 這些確認使VMware?FT能夠確定何時可以發送被輸出規則延遲的輸出。 圖3說明了這個過程。
如果備份VM在需要讀取下一個日志條目時遇到空日志緩沖區，它將停止執行，直到有新的日志條目可用。 由于備份VM沒有與外部通信，因此此暫停不會影響VM的任何客戶端。 類似地，如果主VM在需要寫入日志條目時遇到一個完整的日志緩沖區，它必須停止執行，直到日志條目被清除為止。 執行中的這個停止是一種自然的流控制機制，當主VM以過快的速度生成日志條目時，它會減慢主VM的速度。 但是，這種暫停會影響VM的客戶端，因為主VM將完全停止，直到它可以記錄其條目并繼續執行為止。 因此，我們的實現必須最小化主日志緩沖區被填滿的可能性。 主日志緩沖區可能被填滿的一個原因是，備份VM執行得太慢，因此消耗日志條目的速度也太慢。 通常，備份VM必須能夠以與主VM記錄執行大致相同的速度重播執行。 幸運的是，VMware確定性回放中記錄和回放的開銷大致相同。 然而,如果服務器主機負載很高的備份虛擬機與其他VM(因此過度使用資源),備份虛擬機可能無法獲得足夠的CPU和內存資源執行主虛擬機一樣快,盡管盡了最大努力備份虛擬機監控程序的虛擬機調度程序。
除了在日志緩沖區填滿時避免意外的暫停之外，還有一個我們不希望執行延遲變得太大的原因。 如果主VM出現故障，備份VM必須“迎頭趕上”，在它開始運行并開始與外部世界通信之前，必須重播它已經確認的所有日志條目。 完成重播的時間基本上就是故障點的執行延遲時間，所以備份開始運行的時間大致等于故障檢測時間加上當前執行延遲時間。 因此，我們不希望執行延遲時間太長(超過一秒)，因為這會增加大量的故障轉移時間。
因此，我們有一個額外的機制來降低主VM的速度，以防止備份VM落后太多。 在發送和確認日志條目的協議中，我們發送附加信息來確定主vm和備份vm之間的實時執行延遲。 通常，執行延遲小于100毫秒。 如果備份VM開始出現明顯的執行延遲(比如超過1秒)，VMware?FT就會通知調度器給它分配更少的CPU資源(最初只分配了幾個百分點)，從而降低主VM的速度。 我們使用一個緩慢的反饋循環，它將嘗試逐步確定主VM的適當CPU限制，以便讓備份VM能夠匹配其執行。 如果備份VM繼續滯后，我們將繼續逐步降低主VM的CPU限制。 相反，如果備份VM趕上來了，我們會逐漸增加主VM的CPU限制，直到備份VM恢復到有一點延遲。
請注意，主VM的這種減速非常罕見，通常只在系統處于極端壓力下時才會發生。 第5部分的所有性能數字都包括任何此類慢化的成本。
3.3 操作FT虛擬機
另一個實際問題是處理可能應用于主VM的各種控制操作。 例如，如果主VM被顯式地關閉，那么備份VM也應該停止，而不是嘗試運行。 另一個示例是，主服務器上的任何資源管理更改(如增加的CPU份額)也應該應用于備份。 對于這類操作，在日志通道上將特殊的控制項從主服務器發送到備份服務器，以便對備份進行適當的操作。
通常，VM上的大多數操作應該只在主VM上啟動。 然后，VMware?FT發送任何必要的控制條目來對備份VM進行適當的更改。 在主vm和備份vm上唯一可以獨立完成的操作是VMotion。 也就是說，主vm和備份vm可以獨立地移動到其他主機。 請注意，VMware?FT確保沒有一個VM被移動到另一個VM所在的服務器上，因為這種情況將不再提供容錯。 主VM的VMotion比普通VMotion增加了一些復雜性，因為備份VM必須從源主VM斷開連接，并在適當的時候重新連接到目標主VM。 備份VM的VMotion也有類似的問題，但是增加了額外的復雜性。
對于一個普通的VMotion，我們要求所有未完成的磁盤IOs在VMotion發生最后的切換時暫停(即完成)。 對于主VM，這種停頓很容易處理，只需等待物理IOs完成并將這些完成交付給VM即可。 但是，對于備份VM來說，沒有一種簡單的方法可以讓所有的IOs在任何需要的點上完成，因為備份VM必須重播主VM的執行，并在相同的執行點上完成IOs。 主VM可能正在運行一個工作負載，在正常執行期間總有磁盤IOs在運行。 VMware?FT有一個獨特的方法來解決這個問題。 當備份VM位于VMotion的最后一個切換點時，它通過日志通道請求主VM暫時停止所有IOs。 然后，備份VM的IOs自然會在單個執行點暫停，因為它會回放主VM執行暫停操作的過程。
3.4 磁盤IOs的實現問題
有許多與磁盤IO相關的細微實現問題。 首先，由于磁盤操作是非阻塞的，因此可以并行執行，因此訪問相同磁盤位置的同步磁盤操作可能導致不確定性。 另外，我們的磁盤IO實現直接在虛擬機的內存中使用DMA，因此訪問相同內存頁的同步磁盤操作也可能導致不確定性。 我們的解決方案通常是檢測任何這樣的IO爭用(這種情況很少見)，并強制在主服務器和備份服務器上以相同的方式順序執行這樣的爭用磁盤操作。
其次，磁盤操作還可以與VM中的應用程序(或OS)的內存訪問競爭，因為磁盤操作直接通過DMA訪問VM的內存。 例如，如果VM中的應用程序/操作系統正在讀取一個內存塊，同時對該塊進行磁盤讀取，那么可能會出現不確定的結果。 這種情況也不太可能發生，但我們必須發現它，并在它發生時加以處理。 一種解決方案是在磁盤操作的目標頁面上臨時設置頁面保護。 如果VM訪問的頁面也是未完成的磁盤操作的目標，并且可以暫停VM，直到磁盤操作完成，那么頁面保護將導致陷阱。 因為更改頁面上的MMU保護是一項昂貴的操作，所以我們選擇使用bounce?buffer。 bounce?buffer是一個臨時緩沖區，它的大小與磁盤操作訪問的內存大小相同。 將磁盤讀取操作修改為將指定的數據讀取到bounce緩沖區，并且僅在發送IO完成時將數據復制到來賓內存。 類似地，對于磁盤寫操作，首先將發送的數據復制到bounce緩沖區，然后將磁盤寫修改為從bounce緩沖區寫入數據。 使用bounce?buffer可以減慢磁盤操作，但是我們沒有看到它會導致任何明顯的性能損失。
第三，當發生故障時，主磁盤上與磁盤IOs相關的一些問題尚未解決(即未完成)，然后由備份接管。 新升級的主VM無法確定磁盤IOs是否已被分發到磁盤或是否已成功完成。 此外，由于磁盤IOs不是在備份VM上從外部發出的，所以在新提升的主VM繼續運行時，它們將沒有顯式的IO完成，這最終將導致VM中的來賓操作系統啟動中止或重置過程。 我們可以發送一個錯誤完成，表明每個IO失敗，因為即使IO成功完成，返回一個錯誤也是可以接受的。 但是，來賓操作系統可能無法很好地響應來自其本地磁盤的錯誤。 相反，我們會在備份VM上線過程中重新發布掛起的IOs。 因為我們已經消除了所有的競爭，所有的IOs都直接指定訪問哪些內存和磁盤塊，所以即使這些操作已經成功完成(即它們是冪等的)，也可以重新發出這些磁盤操作。
3.5 網絡IO的實現問題
VMware?vSphere為VM網絡提供了許多性能優化。 其中一些優化是基于虛擬機監控程序異步更新虛擬機網絡設備的狀態。 例如，在執行VM時，系統管理程序可以直接更新接收緩沖區。 不幸的是，這些對VM狀態的異步更新增加了不確定性。 除非我們能夠保證所有更新都發生在主服務器和備份服務器上的指令流的同一點上，否則備份的執行可能會偏離主服務器的執行。
FT的網絡仿真代碼的最大變化是禁用了異步網絡優化。 使用傳入包異步更新VM環形緩沖區的代碼已被修改，以迫使來賓操作系統將其捕獲到管理程序中，以便記錄更新并將其應用于VM。 類似地，在FT中，通常將數據包異步地從傳輸隊列中取出的代碼將被禁用，取而代之的是通過一個陷阱將數據包傳輸到hypervisor(下面提到的情況除外)。
消除網絡設備的異步更新，以及2.2節中所述的發送數據包的延遲，為網絡帶來了一些性能挑戰。 在運行FT時，我們采用了兩種方法來提高VM網絡性能。首先，我們實現了集群優化來減少VM陷阱和中斷。 當VM以足夠的比特率傳輸數據時，hypervisor可以對每組數據包執行一個傳輸陷阱，在最好的情況下，可以執行零陷阱，因為它可以將數據包作為接收新數據包的一部分進行傳輸。 同樣地，hypervisor可以通過只發布一組數據包的中斷來減少傳入數據包對VM的中斷數量。
我們的第二個網絡性能優化涉及到減少傳輸數據包的延遲。 如前所述，系統管理程序必須延遲所有傳輸的數據包，直到它從備份中獲得相應日志條目的確認。 減少傳輸延遲的關鍵是減少向備份發送日志消息并獲得確認所需的時間。 我們在這方面的主要優化包括確保發送和接收日志條目和確認都可以在沒有任何線程上下文切換的情況下完成。 VMware?vSphere?hypervisor允許向TCP堆棧注冊函數，每當接收到TCP數據時，就會從延遲執行上下文(類似于Linux中的微線程)調用這些函數。 這al?-
圖4:FT非共享磁盤配置。
在沒有任何線程上下文切換的情況下，讓我們快速處理備份上的任何傳入日志消息和主服務器收到的任何確認。 此外，當主VM對要傳輸的包進行排隊時，我們通過調度延遲執行上下文來強制相關輸出日志條目的立即日志刷新(如2.2節中所述)。
4. 設計方案
在VMware?FT的實現中，我們探索了許多有趣的設計方案。 在本節中，我們將探討其中的一些替代方法。
4.1 共享磁盤與非共享磁盤
在我們的默認設計中，主vm和備份vm共享相同的虛擬磁盤。 因此，如果發生故障轉移，共享磁盤的內容自然是正確的和可用的。 本質上，共享磁盤被認為是主vm和備份vm的外部，因此對共享磁盤的任何寫操作都被認為是與外部世界的通信。 因此，只有主VM對磁盤執行實際的寫操作，而對共享磁盤的寫操作必須根據輸出規則延遲。
另一種設計是讓主vm和備份vm擁有獨立的(非共享的)虛擬磁盤。 在這種設計中，備份VM確實執行對其虛擬磁盤的所有磁盤寫操作，并且在這樣做時，它自然會使其虛擬磁盤的內容與主VM虛擬磁盤的內容保持同步。 圖4演示了這種配置。 在非共享磁盤的情況下，虛擬磁盤本質上被認為是每個VM內部狀態的一部分。 因此，根據輸出規則，不需要延遲主磁盤的寫操作。 在主vm和備份vm無法訪問共享存儲的情況下，非共享設計非常有用。 這種情況可能是因為共享存儲不可用或太昂貴，或者是因為運行主vm和備份vm的服務器相距太遠(“長距離FT”)。 非共享設計的一個缺點是，在首次啟用容錯時，必須以某種方式顯式地同步虛擬磁盤的兩個副本。 此外，在發生故障后，磁盤可能會失去同步，因此必須在備份VM在發生故障后重新啟動時顯式地重新同步磁盤。 也就是說，FT?VMotion不僅要同步主vm和備份vm的運行狀態，還要同步它們的磁盤狀態。
在非共享磁盤配置中，可能沒有用于處理分裂大腦情況的共享存儲。 在這種情況下，系統可以使用一些其他的外部決定因素，例如一個第三方服務器，兩個服務器都可以與之通信。 如果服務器是包含兩個以上節點的集群的一部分，則系統可以選擇使用基于集群成員關系的多數算法。 在這種情況下，只有在服務器上運行VM時，才允許它運行，而服務器是包含大多數原始節點的通信子集群的一部分。
4.2 在備份VM上執行磁盤讀操作
在我們的默認設計中，備份VM從不讀取它的虛擬磁盤(不管是共享的還是非共享的)。 由于磁盤讀取被視為輸入，所以通過日志通道將磁盤讀取的結果發送到備份VM是很自然的。 另一種設計是讓備份VM執行磁盤讀取，從而消除磁盤讀取數據的日志記錄。 對于進行大量磁盤讀取的工作負載，這種方法可以極大地減少日志通道上的流量。 然而，這種方法有許多微妙之處。 它可能會降低備份VM的執行速度，因為備份VM必須執行所有的磁盤讀取，如果它們在主服務器上完成的時候物理上還沒有完成，則必須等待。
此外，還必須做一些額外的工作來處理失敗的磁盤讀操作。 如果主服務器讀取的磁盤成功，但是備份服務器讀取的相應磁盤失敗，則必須重試備份服務器讀取的磁盤，直到成功，因為備份服務器必須在內存中獲得與主服務器相同的數據。 相反，如果主磁盤讀取失敗，則目標內存的內容必須通過日志通道發送到備份，因為內存的內容將是不確定的，并且備份VM讀取成功的磁盤不一定要復制。
最后，如果在共享磁盤配置中使用這種磁盤讀取方法，還有一個微妙之處。 如果主VM對特定的磁盤位置執行讀操作，然后很快又對相同的磁盤位置執行寫操作，那么必須延遲磁盤寫操作，直到備份VM執行了第一次磁盤讀操作。 可以正確地檢測和處理這種依賴關系，但是會給實現增加額外的復雜性。 在第5.1節中，我們給出了一些性能結果，表明在備份上執行磁盤讀操作會略微降低實際應用程序的吞吐量(1-4%)，但也會顯著降低日志帶寬。 因此，在日志通道的帶寬非常有限的情況下，在備份VM上執行磁盤讀取可能很有用。
5. 績效評估
在本節中，我們將對VMware?FT在一些應用程序工作負載和網絡基準測試方面的性能進行基本評估。 對于這些結果，我們在相同的服務器上運行主vm和備份vm，每個服務器使用8個Intel?Xeon?2.8?Ghz?cpu和8?gb?RAM。 服務器通過一個10?Gbit/s的交叉網絡連接，盡管在所有情況下使用的網絡帶寬都遠遠小于1?Gbit/s。 兩個服務器都訪問它們共享的虛擬機
| SPECJbb2005 | 0.98 | 1.5兆比特/秒 |
| 內核編譯 | 0.95 | 3.0兆比特/秒 |
| 甲骨文Swingbench | 0.99 | 12兆比特/秒 |
| ms sql DVD商店 | 0.94 | 18兆比特/秒 |
表1:基本性能結果
來自EMC公司的磁盤通過標準的4gbit?/s光纖通道網絡連接。 用于驅動某些工作負載的客戶機通過一個1gbit?/s網絡連接到服務器。
我們在性能結果中評估的應用程序如下。 SPECJbb2005是一種工業標準的Java應用程序基準測試，它占用大量的CPU和內存，只做很少的IO工作。 內核編譯是運行Linux內核編譯的工作負載。 這個工作負載執行一些磁盤讀寫操作，并且由于許多編譯過程的創建和銷毀，所以對CPU和mmu的占用非常大。 Oracle?Swingbench是一個工作負載，其中Oracle?11g數據庫由Swingbench?OLTP(在線事務處理)工作負載驅動。 這個工作負載執行大量的磁盤和網絡IO，并且有80個同時的數據庫會話。 MS-SQL?DVD存儲是一種工作負載，其中Microsoft?SQL?Server?2005數據庫由DVD存儲基準驅動，該基準有16個并發客戶機。
5.1 基本的性能結果
表1給出了基本的性能結果。 對于列出的每個應用程序，第二列給出在運行服務器工作負載的VM上啟用FT時應用程序的性能與在同一VM上不啟用FT時的性能之比。 計算性能比率時，小于1的值表示FT工作負載較慢。 顯然，在這些典型的工作負載上啟用FT的開銷不到10%。 SPECJbb2005完全是受計算限制的，沒有空閑時間，但是執行得很好，因為除了定時器中斷之外，它有最小的不確定性事件。 其他工作負載執行磁盤IO并有一些空閑時間，因此FT開銷的一部分可能被FT?vm的空閑時間更少這一事實所掩蓋。 然而，一般的結論是VMware?FT能夠以相當低的性能開銷支持容錯vm。
在表的第三列中，我們給出了運行這些應用程序時在日志通道上發送的數據的平均帶寬。 對于這些應用程序，日志帶寬是相當合理的，并且很容易滿足1gbit?/s網絡。 事實上，低帶寬要求表明多個FT工作負載可以共享相同的1?Gbit/s網絡，而不會對性能產生任何負面影響。
對于運行Linux和Windows等常見客戶操作系統的vm，我們發現當客戶操作系統空閑時，典型的日志帶寬是0.5-1.5?Mbits/秒。 “空閑”帶寬主要是記錄定時器中斷的傳輸的結果。 對于具有活動工作負載的VM，日志記錄帶寬由必須發送到備份的網絡和磁盤輸入(接收到的網絡數據包和從磁盤讀取的磁盤塊)控制。 因此，日志記錄帶寬可以很大
基地
FT
日志記錄
帶寬
帶寬
帶寬
接收(1 gb)
940
604
730
傳輸(1 gb)
940
855
42
收到(10 gb)
940
860
990
傳輸(10 gb)
940
935
60
| 接收(1 gb) | 940 | 604 | 730 |
| 傳輸(1 gb) | 940 | 855 | 42 |
| 收到(10 gb) | 940 | 860 | 990 |
| 傳輸(10 gb) | 940 | 935 | 60 |
表2:1Gb和10Gb日志通道的網絡發送和接收客戶端的性能(均以Mbit/s為單位)
對于具有非常高的網絡接收或磁盤讀取帶寬的應用程序，它比表1中測量的值要高。 對于這類應用程序，日志通道的帶寬可能成為瓶頸，特別是在日志通道有其他用途的情況下。
對于許多實際應用程序，日志通道所需的相對較低的帶寬使得基于重播的容錯對于使用非共享磁盤的遠程配置非常有吸引力。 對于主備相距1-100公里的長距離配置，光纖可以很容易地支持100-?1000mbit?/s的帶寬，延遲小于10毫秒。 對于表1中的應用程序，100-?1000mbit?/s的帶寬應該足以實現良好的性能。 但是，請注意，主備份和備份之間額外的往返延遲可能會導致網絡和磁盤輸出延遲至多20毫秒。 遠程配置只適用于客戶端能夠容忍每個請求額外延遲的應用程序。
對于兩個磁盤最密集的應用程序，我們測量了在備份VM上執行磁盤讀(如4.2節所述)與通過日志通道發送磁盤讀數據對性能的影響。 對于Oracle?Swingbench，在備份VM上執行磁盤讀取時，吞吐量大約降低4%; 對于MS-SQL?DVD商店，吞吐量大約低1%。 同時，Oracle?Swingbench的日志帶寬從12兆比特/秒降低到3兆比特/秒，MS-SQL?DVD商店的日志帶寬從18兆比特/秒降低到8兆比特/秒。 顯然，對于具有更大的磁盤讀取帶寬的應用程序，可以節省更多的帶寬。 正如在第4.2節中提到的，當在備份VM上執行磁盤讀取時，性能可能會有所下降。 但是，對于日志通道帶寬有限的情況(例如，遠程配置)，在備份VM上執行磁盤讀取可能很有用。
5.2 網絡基準
網絡基準測試對于我們的系統來說是非常具有挑戰性的，原因有很多。 首先，高速網絡可能具有非常高的中斷率，這要求以非常高的速率記錄和回放異步事件。 其次，以高速率接收信息包的基準測試將導致高速率的日志流量，因為所有這些信息包都必須通過日志通道發送到備份。 第三，發送信息包的基準測試將服從輸出規則，該規則將延遲網絡信息包的發送，直到收到來自備份的適當確認。 此延遲將增加到客戶端的測量延遲。 這種延遲還可能減少到客戶機的網絡帶寬，因為隨著往返延遲的增加，網絡協議(如TCP)可能必須降低網絡傳輸速率。
表2給出了我們使用標準netperf基準測試進行的許多測量的結果。 在所有這些測量中，客戶機VM和主VM通過一個1gbit?/s網絡連接。 當主主機和備份主機通過1?Gbit/s日志通道連接時，前兩行給出發送和接收性能。 當主服務器和備份服務器通過10gbit?/s日志通道連接時，第三和第四行給出了發送和接收性能，這不僅具有更高的帶寬，而且比1gbit?/s網絡的延遲更低。 作為一個粗略的度量，1gbit?/s連接的管理程序之間的ping時間約為150微秒，而10gbit?/s連接的ping時間約為90微秒。
當不啟用FT時，主VM可以實現接近(940?Mbit/s)?1?Gbit/s的行速率進行發送和接收。 當為接收工作負載啟用FT時，日志帶寬非常大，因為所有傳入的網絡數據包都必須在日志通道上發送。 因此，日志通道可能成為瓶頸，如1gbit?/s日志網絡的結果所示。 對于10gbit?/s的測井網絡，影響要小得多。 當為傳輸工作負載啟用FT時，傳輸數據包的數據不被記錄，但是網絡中斷必須被記錄。 日志記錄的帶寬要低得多，因此可實現的網絡傳輸帶寬要高于網絡接收帶寬。 總的來說，我們可以看到，在非常高的發射和接收速率下，FT可以顯著地限制網絡帶寬，但是高的絕對速率仍然是可以實現的。
6. 相關工作
Bressoud和Schneider[3]描述了通過完全包含在管理程序級別的軟件為虛擬機實現容錯的最初想法。 他們通過使用HP?PA-RISC處理器的服務器原型，演示了保持備份虛擬機與主虛擬機同步的可行性。 然而，由于PA-RISC架構的限制，他們不能實現完全安全的、隔離的虛擬機。 此外，他們沒有實現任何故障檢測方法，也沒有試圖解決第3節中描述的任何實際問題。 更重要的是，他們對FT協議強加了一些不必要的約束。 首先，他們引入了epoch的概念，其中異步事件被延遲到一個集合間隔的末尾。 epoch的概念是不必要的——他們可能強加了它，因為他們不能足夠有效地重放單個異步事件。 其次，它們要求主VM停止執行，直到備份已經接收并確認了所有以前的日志條目。 然而，只有輸出本身(如網絡包)必須延遲——主VM本身可以繼續執行。
Bressoud[4]描述了一個在操作系統(Unixware)中實現容錯的系統，因此為在該操作系統上運行的所有應用程序提供容錯。 系統調用接口成為必須確定地復制的操作集。 這項工作與基于管理程序的工作具有類似的限制和設計選擇。
Napper等人的[9]、Friedman和Kama[7]描述了容錯Java虛擬機的實現。 它們遵循與我們類似的設計，在日志通道上發送關于輸入和非確定性操作的信息。 與Bressoud一樣，它們似乎并不專注于檢測故障并在故障后重新建立容錯能力。 此外，它們的實現僅限于為在Java虛擬機中運行的應用程序提供容錯。 這些系統試圖處理多線程Java應用程序的問題，但是要求所有數據都正確地受到鎖的保護，或者在訪問共享內存時強制進行序列化。
Dunlap等人的[6]描述了一種確定性重放的實現，其目標是調試半虛擬化系統上的應用軟件。 我們的工作支持在虛擬機中運行的任意操作系統，并為這些vm實現容錯支持，這需要更高級別的穩定性和性能。
Cully等人在一個名為Remus的項目中描述了一種支持容錯vm的替代方法及其實現。 使用這種方法，主VM的狀態在執行期間被反復檢查，并被發送到備份服務器，備份服務器收集檢查點信息。 檢查點必須非常頻繁地執行(每秒多次)，因為外部輸出必須延遲，直到發送并確認了以下檢查點。 這種方法的優點是它同樣適用于單處理器和多處理器vm。 主要問題是這種方法對網絡帶寬的要求非常高，需要在每個檢查點將增量更改發送到內存狀態。 在[5]中給出的Remus測試結果顯示，當使用1?Gbit/s網絡連接來傳輸內存狀態變化時，內核編譯和SPECweb基準測試的速度會降低100%到225%。 在減少所需的網絡帶寬方面，有一些優化可能是有用的，但是對于1?Gbit/s連接是否可以實現合理的性能，目前還不清楚。 相比之下，我們基于確定性重放的方法可以實現小于10%的開銷，幾個實際應用程序的主主機和備份主機之間所需的帶寬小于20?Mbit/s。
7. 結論與未來工作
我們在VMware?vSphere中設計并實現了一個高效、完整的系統，為運行在集群服務器上的虛擬機提供容錯(FT)。 我們的設計基于使用VMware確定性重播，通過在另一臺主機上的備份VM復制主VM的執行。 如果運行主VM的服務器發生故障，則備份VM立即接管，不會中斷或丟失數據。
總的來說，VMware?FT下的容錯vm在普通硬件上的性能非常好，并且在某些典型應用程序上的開銷還不到10%。 VMware?FT的大部分性能成本來自于使用VMware確定性回放來保持主vm和備份vm同步的開銷。 VMware?FT的低開銷是由VMware確定性重放的效率決定的。 此外，保持主備份同步所需的日志帶寬通常非常小，通常小于20?Mbit/s。 因為在大多數情況下，日志記錄帶寬非常小，所以在主vm和備份vm之間用長距離(1-100公里)分隔的情況下實現配置似乎是可行的。 因此，VMware?FT可以用于保護整個站點不受災難影響的場景。 值得注意的是，日志流通常是可壓縮的，簡單的壓縮技術可以通過少量額外的CPU開銷顯著減少日志帶寬。
我們使用VMware?FT的結果表明，可以在確定性重放的基礎上構建容錯vm的有效實現。 這樣的系統可以透明地為運行任何操作系統和應用程序的vm提供容錯，而且開銷最小。 然而，要使容錯vm系統對客戶有用，它還必須是健壯的、易于使用的和高度自動化的。 一個可用的系統需要許多其他組件，而不僅僅是vm的復制執行。 具體來說，VMware?FT通過在本地集群中找到一個合適的服務器并在該服務器上創建一個新的備份VM，在出現故障后自動恢復冗余。 通過解決所有必要的問題，我們已經演示了一個可以在客戶的數據中心中用于實際應用程序的系統。
通過確定性重放實現容錯的一個折衷之處是，目前確定性重放只在單處理器vm上有效地實現。 但是，單處理器vm對于各種工作負載來說已經足夠了，特別是在物理處理器的功能不斷增強的情況下。 此外，許多工作負載可以通過使用多個單處理器VM來擴展，而不是通過使用一個更大的多處理器VM來擴展。 針對多處理器vm的高性能回放是一個活躍的研究領域，可以通過微處理器中的一些額外硬件支持來啟用它。 一個有趣的方向可能是擴展事務性內存模型，以促進多處理器回放。
將來，我們還希望擴展我們的系統來處理部分硬件故障。 通過部分硬件故障，我們指的是服務器的功能或冗余的部分丟失，而不會導致數據損壞或丟失。 例如，丟失所有到VM的網絡連接，或者丟失物理服務器中的冗余電源。 如果在運行主VM的服務器上發生部分硬件故障，在許多情況下(但不是所有情況)，立即將故障轉移到備份VM是有利的。 這樣的故障轉移可以立即恢復關鍵VM的完整服務，并確保VM快速地從可能不可靠的服務器上移走。
致謝
我們要感謝克里希納·拉賈，他產生了許多業績成果。 有許多人參與了VMware?FT的實現。確定性回放的核心實施者(包括對各種虛擬設備的支持)和FT的基本功能包括Lan?Huang、Eric?Lowe、Slava?Malyugin、Alex?Mirgorodskiy、Kaustubh?Patil、Boris?Weissman、Petr?Vandrovec和Min?Xu。 另外，還有很多人參與了VMware?vCenter中FT的高層管理。 Karyn?Ritter在管理大部分工作上做得很出色。 使用虛擬機收集執行跟蹤確定性重放。 在2007年建模、基準測試和模擬研討會(2007年6月)的會議記錄中。
8. 參考文獻
[1] Alsberg,?P。 彈性共享分布式資源的原則。 在《第二屆軟件工程國際會議論文集》(1976)第627-644頁。
[2] AMD公司。 AMD64架構程序員手冊。 森尼維爾市。
[3] Bressoud,?T。 基于虛擬機監控程序的容錯。 在1995年12月第15次會議記錄中。
[4] TFT:應用透明容錯的軟件系統。 在
第二十八屆年會
容錯計算國際研討會(1998年6月)，頁128-137。
[5] 呆子,B。 Lefebvre,?G。 邁耶,D。 Feeley,?M。 和記黃埔,N。 A.萊姆斯:高
通過異步虛擬機提供可用性
復制。 在第五屆USENIX網絡系統設計與實現研討會論文集(2008年4月)，第161-174頁。
[6] 鄧拉普,g·W。 ，金，s。 、Cinar年代。 Basrai,?M。 和陳，P.?M.?ReVirt:允許入侵
通過虛擬機日志和回放進行分析。 2002年操作系統設計與實現研討會論文集(2002年12月)。
[7] 弗里德曼,R。 透明的容錯Java虛擬機。 在《可靠分布式系統學報》(2003年10月號)第319-328頁。
[8] 英特爾公司。 64?年?IntelA?R?IA-32?Architectures?Software?Developer’s?Manuals. 圣克拉拉的CA。
[9] 打盹的人,J。 Alvisi,?L。 和Vin?h。A
容錯的Java虛擬機。 在可靠系統與網絡國際會議論文集(2002年6月)，第425-434頁。
[10] 納爾遜,M。 Lim?B.-H。 和Hutchins,?G.用于虛擬機的快速透明遷移。 在2005年USENIX年度技術會議(2005年4月)的會議記錄中。
[11] 夜鶯,e?.?B。 Veeraraghavan,?K。 ，陳，P.?M.。 重新思考同步。 2006年操作系統設計與實現研討會論文集(2006年11月)。
[12] Schlicting,?R。 ，施耐德，f。b。故障停止
處理器:一種設計容錯計算系統的方法。 ACM計算調查1,3(1983年8月)，222-238。
[13] 使用狀態機方法實現容錯服務:教程。 ACM計算調查22,4(1990年12月)，299-319。
[14] 層云技術。 受益于層云
連續加工工藝:全自動
Microsoft?Windows服務器的正常運行時間為99.999%
環境。 在http://www.stratus.com/?/媒體/層/文件/資源/白皮書/?continuousprocessing-for-windows.pdf,?2009年6月。
[15] 徐,M。 Malyugin,?V。 謝爾登,J。 Venkitachalam,?G。 B.回溯:
總結
以上是生活随笔為你收集整理的《The Design of a Practical System for Fault-Tolerant Virtual Machines》——容错虚拟机，中文翻译的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 关于 LINK : warning LN
- 下一篇： 不长的时间，不短的记忆，岁月使然，色彩依