VMware FT 容錯技術詳解：原理、挑戰與實踐

在現代計算環境中，業務連續性至關重要。服務器故障可能導致服務中斷、數據丟失，進而造成巨大的經濟損失和聲譽損害。容錯 (Fault Tolerance, FT) 技術旨在確保單個硬件故障不會影響應用程序的可用性。VMware FT 就是這樣一種為虛擬機 (VM) 提供高級別可用性的解決方案，它通過在不同物理服務器上維護一個與主虛擬機 (Primary VM) 同步的備份虛擬機 (Backup VM) 來實現。

容錯的基本概念與方法

首先，我們需要明確 VMware FT 主要針對的是 失效-停止 (fail-stop) 型故障。這類故障指的是組件發生故障后會完全停止工作，例如電源故障、網絡中斷或整個服務器宕機。這類故障可以通過復制 (replication) 來處理。相比之下，一些更復雜的故障，如軟件缺陷 (software bug)、設計缺陷 (design flaw) 或惡意的拜占庭 (Byzantine) 故障（即組件可能產生錯誤結果但表面上仍在運行），則不在此類 fail-stop 容錯系統的主要處理范圍內。

實現容錯的核心在于復制。通常有兩種主要的復制策略：

• 狀態傳輸 (State Transfer) ：定期或持續地將主副本的完整狀態（包括 CPU、內存、I/O 設備狀態）傳輸到備份副本。這種方法的缺點是所需帶寬可能非常大，尤其是內存變化頻繁時。
• 復制狀態機 (Replicated State Machine, RSM) ：將服務器視為確定性狀態機。如果兩個狀態機從相同的初始狀態開始，并以相同的順序接收相同的輸入，那么它們將經歷相同的狀態序列并產生相同的輸出。 VMware FT 正是采用了這種方法，通過在底層復制虛擬機內存和寄存器的執行來實現。這種方法的帶寬需求通常遠低于狀態傳輸。

VMware FT 的核心：基于 Hypervisor 的復制狀態機

Q: 為什么在虛擬機上實現確定性執行比在物理服務器上更容易？

A: 因為 Hypervisor 模擬并控制了硬件的許多方面，例如中斷傳遞的精確時機。這使得 Hypervisor 能夠確保主虛擬機和備份虛擬機在面對相同的輸入時，其內部狀態以完全相同的方式演進。

Q: 什么是 Hypervisor？

A: Hypervisor，也稱為虛擬機監視器 (Virtual Machine Monitor, VMM)，是虛擬機系統的一部分。它模擬一臺完整的計算機，客戶操作系統 (Guest OS) 及其應用程序運行在這個模擬的計算機（即虛擬機）內。在 VMware FT 架構中，Primary VM 和 Backup VM 都是運行在各自 Hypervisor 內的客戶機。

VMware FT 的基石是 確定性重放 (Deterministic Replay) 技術。 Primary VM 的所有輸入（如網絡數據包、磁盤讀取、鍵盤鼠標操作以及所有可能導致非確定性行為的事件（如中斷的時間、讀取 CPU 時鐘周期計數器）都會被 Hypervisor 捕獲。這些輸入和非確定性事件被記錄成日志條目，通過一個專用的 日志通道 (Logging Channel) 實時發送給 Backup VM。 Backup VM 的 Hypervisor 則嚴格按照這些日志條目來“重放”Primary VM 的執行過程，從而保持兩者狀態的精確同步，盡管 Backup VM 的執行會略有延遲。

Q: VMware FT 如何處理那些看似隨機的非確定性事件，以確保主備一致？

A: Hypervisor 控制了所有隨機性的來源。

• 中斷傳遞 ：Hypervisor 會記錄 Primary VM 中斷發生的精確指令位置，并在 Backup VM 執行到相同指令時傳遞該中斷。這得益于 CPU 的性能計數器 (performance counters) 等硬件輔助特性。 VMware 的實現足夠高效，無需像早期某些系統那樣將中斷延遲到某個“紀元 (epoch)”結束時才處理。
• 時間或硬件周期計數器 ：當應用程序試圖讀取當前時間或硬件周期計數器時，Hypervisor 會攔截這些指令，并確保 Primary VM 和 Backup VM 獲取到相同的值。
• 隨機數生成器 ：即使應用程序調用隨機數生成器，Hypervisor 也會確保主備獲得相同的隨機數序列。

關鍵挑戰與解決方案

1. 輸出規則 (Output Rule) 與數據一致性

Q: VMware FT 如何保證在 Primary VM 故障后，Backup VM 接管時不會丟失數據或產生外部可見的不一致狀態？

A: 這是通過嚴格遵守 輸出規則 (Output Rule) 來實現的。

輸出規則 ：Primary VM 在向外部世界發送任何輸出（例如網絡數據包、磁盤寫入到共享磁盤）之前，必須等待 Backup VM 接收并確認了與該輸出操作相關的日志條目。

這條規則至關重要。如果 Backup VM 已經確認收到了包含某個輸出操作的日志，那么即使 Primary VM 在該輸出實際發送后立即崩潰，Backup VM 也能準確地重放到該輸出點之前的狀態，并最終產生與 Primary VM 相同的輸出（或達到一個與該輸出一致的狀態）。如果沒有這個規則，Backup VM 可能在沒有收到所有必要日志的情況下就上線，導致其狀態與 Primary VM 已經發出的輸出不一致。

值得注意的是，輸出規則僅僅延遲了輸出的實際發送，Primary VM 本身可以繼續執行后續指令，而不會被完全暫停。這與一些早期系統要求 Primary VM 在輸出前必須完全停止直到 Backup VM 確認的做法不同。

Q: 如果 Primary VM 在發送輸出后立即失敗，輸出會重復嗎？這會導致問題嗎？

A: Backup VM 在接管后很可能會重復該輸出。對于大多數情況，這不是問題：

• 網絡輸出 ：如果輸出是網絡數據包，接收端的 TCP 協議棧通常能自動處理和丟棄重復的數據包。
• 磁盤 I/O ：磁盤寫入操作通常是冪等的 (idempotent)，即多次執行相同的寫操作（寫入相同數據到相同位置且中間無其他 I/O）與執行一次的效果相同。

2. DMA 競爭 (Race) 與 Bounce Buffers

Q: 什么是 DMA (Direct Memory Access) 競爭？VMware FT 如何避免由此導致的非確定性？

A: 當硬件設備（如網卡或磁盤控制器）通過 DMA 直接向虛擬機內存寫入數據時，如果客戶機操作系統或應用程序恰好在幾乎同一時刻讀取該內存區域，就可能發生競爭。由于主備虛擬機執行時序的微小差異，一個可能讀到新數據，另一個可能讀到舊數據，從而導致狀態發散。

VMware FT 通過使用 bounce buffers 來避免這個問題：

• 當網絡數據包或磁盤數據塊到達 Primary VM 時，數據首先被 DMA 到 Hypervisor 控制的一個私有“bounce buffer”中，這個 buffer 是 Primary VM 無法直接訪問的。
• DMA 完成后，FT Hypervisor 中斷 Primary VM 的執行，并記錄下中斷發生的精確指令點。
• 然后，FT Hypervisor 將 bounce buffer 中的數據復制到 Primary VM 的實際目標內存中。
• 之后，Primary VM 才被允許恢復執行。
• 同時，這份數據會通過日志通道發送給 Backup VM。 Backup VM 的 FT Hypervisor 會在相同的指令點中斷 Backup VM，將數據從其自己的 bounce buffer（或直接接收到的數據）復制到 Backup VM 的內存中，然后恢復其執行。

通過這種方式，確保了主備虛擬機在完全相同的執行時刻“看到”輸入數據，從而消除了 DMA 競爭。盡管 bounce buffer 會增加一點開銷，但通常不會造成明顯的性能損失。

3. 故障檢測與切換 (Failover)

VMware FT 系統使用多種機制來檢測 Primary VM 或 Backup VM 的故障：

• 在運行 FT 虛擬機的服務器之間進行 UDP 心跳檢測 (heartbeating)。
• 監控日志通道上的流量。由于客戶機操作系統通常有規律的定時器中斷，日志流量應該是持續的。如果日志條目或確認信息流中斷超過預設的超時時間（通常幾秒鐘），則可能表明發生了故障。

當檢測到故障時：

• 如果 Backup VM 失敗，Primary VM 會“上線 (go live)”，即停止記錄日志并轉為普通模式運行。
• 如果 Primary VM 失敗，Backup VM 的上線過程稍微復雜：它必須首先消耗掉其日志緩沖區中所有已接收但尚未處理的日志條目，以使其狀態達到 Primary VM 失敗前的最新點。完成后，Backup VM 停止重放模式，轉為新的 Primary VM，并開始向外部世界產生輸出。此時，FT 系統會自動更新網絡，例如通告新 Primary VM 的 MAC 地址，以便網絡交換機能將流量導向正確的服務器。

4. 腦裂 (Split-Brain) 問題及其解決

Q: 什么是腦裂 (split-brain) 問題？VMware FT 如何防止這種情況？

A: 當 Primary VM 和 Backup VM 之間的網絡連接中斷（網絡分區），但它們各自的物理服務器仍在運行時，可能會發生腦裂。雙方都可能錯誤地認為對方已經崩潰，并嘗試獨立“上線”成為唯一的活動虛擬機。如果兩者都成功上線，將導致數據損壞和客戶端混淆。

VMware FT 使用 共享存儲 (Shared Storage) 上的一個原子性 test-and-set 操作作為決勝機制 (tie-breaker) 來解決腦裂問題。

• 共享存儲上維護一個初始為 false 的標志。
• 當 Primary VM 或 Backup VM 認為對方失效并決定自己上線時，它會首先向共享存儲發送一個 test-and-set 請求。
• 存儲服務會原子地執行類似以下邏輯的操作：

test-and-set() {
    acquire_lock()
    if flag == true:
    release_lock()
    return false // 已經被設置過了，你不能上線
    else:
    flag = true
    release_lock()
    return true  // 設置成功，你可以上線
}

• 只有當 test-and-set 操作返回 true 時，該虛擬機才被允許上線。如果返回 false，意味著另一方已經成功上線（或正在上線），當前虛擬機則會停止自己（“自殺”）以避免沖突。如果虛擬機無法訪問共享存儲，它會等待直到可以訪問為止。

這種機制確保了即使在網絡分區的情況下，也只有一個虛擬機能夠成功上線。

5. 啟動與重啟 FT 虛擬機

為了能夠啟動一個新的 Backup VM 與一個正在運行的 Primary VM 同步，或者在故障后重新建立冗余，VMware FT 使用了一種修改版的 VMotion 技術，稱為 FT VMotion。

• FT VMotion 可以在不顯著中斷 Primary VM 執行的情況下（通常暫停時間小于1秒），在另一臺服務器上克隆出一個與 Primary VM 狀態完全相同的 Backup VM，并自動建立起它們之間的日志通道。
• 當發生故障后，比如 Primary VM 失效，原來的 Backup VM 上線成為新的 Primary VM。此時，為了恢復冗余，這個新的 Primary VM 會通知集群管理服務 (clustering service)。集群服務會根據資源使用情況在集群中選擇一臺合適的服務器，并調用 FT VMotion 來創建并啟動一個新的 Backup VM。這個過程通常能在幾分鐘內自動完成。

6. 日志通道管理

• 主備 Hypervisor 都會為日志條目維護大型緩沖區。 Primary VM 產生日志到其緩沖區，Backup VM 從其緩沖區消耗日志。
• Primary 的日志緩沖區內容會盡快發送到日志通道，Backup 會盡快從通道讀取到自己的緩沖區。 Backup 在讀取日志后會向 Primary 發送確認 (acknowledgments)。這些確認用于 Output Rule 的判斷。
• 如果 Backup 的日志緩沖區為空，它會暫停執行等待新日志。
• 如果 Primary 的日志緩沖區已滿（通常因為 Backup 處理過慢或網絡擁塞），Primary VM 必須暫停執行，這是一種自然的流控機制。為避免這種情況影響 Primary VM 性能，系統會監控主備之間的執行延遲。如果 Backup VM 落后太多（例如超過1秒），FT 系統會逐漸降低 Primary VM 的 CPU 分配，使其放慢速度，以便 Backup VM 能跟上。

7. 磁盤 I/O 的特殊處理

• 共享磁盤 (Shared Disk) ：在默認配置中，Primary VM 和 Backup VM 共享虛擬磁盤（如通過 Fibre Channel 或 iSCSI SAN 訪問）。此時，只有 Primary VM 實際執行對共享磁盤的寫操作，這些寫操作也受 Output Rule 的約束。 Backup VM 不執行寫操作，其輸出會被 Hypervisor丟棄。
• 非共享磁盤 (Non-shared Disk) ：也支持主備各自擁有獨立的（非共享的）虛擬磁盤。在這種情況下，Backup VM 也會執行所有磁盤寫操作到它自己的虛擬磁盤上，從而保持與 Primary VM 磁盤內容的同步。這種配置下，Primary VM 的磁盤寫操作不再被視為外部輸出，因此不需要遵循 Output Rule 進行延遲。這對于共享存儲不可用或主備距離較遠 (“long-distance FT”) 的場景很有用。
• Primary 故障時未完成的磁盤 I/O

Q: 當 Primary VM 發生故障時，那些已經發起但可能尚未在物理磁盤上完成的 I/O 請求如何處理？

A: 當 Backup VM 上線成為新的 Primary VM 時，在其“go-live”過程中，它會重新發出這些掛起的 (pending) I/O 請求。具體來說，日志中那些有 I/O 啟動記錄但沒有對應完成中斷記錄的 I/O 操作，都需要在 Backup VM 上線時重新啟動。由于 VMware FT 已經通過 bounce buffer 等機制消除了 I/O 競爭，并且 I/O 操作明確指定了內存和磁盤塊，因此這些重新發出的磁盤操作即使之前已經成功完成過，再次執行也是安全的（冪等性）。

8. 網絡 I/O 的挑戰與優化

為了確保確定性，VMware FT 對網絡 I/O 的處理做了一些調整：

• 禁用了某些基于 Hypervisor 異步更新虛擬機網絡設備狀態的性能優化。例如，接收緩沖區不能再由 Hypervisor 在 VM 執行時直接異步更新，而是需要陷入 (trap) 到 Hypervisor，記錄更新操作，然后再應用到 VM。類似的，異步發送數據包的優化也被禁用，發送操作也需要通過 trap 完成。
• 這些改變以及 Output Rule 帶來的發送延遲對網絡性能構成挑戰。
• 優化措施

a.聚集優化 (Clustering Optimizations) ：當 VM 以足夠高的比特率傳輸數據時，Hypervisor 可以將多個數據包的發送合并為一次 trap，甚至在某些情況下（如作為接收新包的一部分發送）可以做到零 trap。類似地，對接收到的數據包也可以合并中斷通知。

b.減少發送延遲 ：關鍵在于減少日志消息發送到 Backup VM 并獲得確認所需的時間。通過確保日志條目和確認信息的發送與接收都可以在沒有線程上下文切換的情況下完成（例如使用類似 Linux tasklet 的延遲執行上下文處理 TCP 數據接收），以及在 Primary VM 發送數據包時強制立即刷新相關日志條目，可以顯著降低延遲。

性能與局限性

VMware FT 在典型企業應用上的性能開銷通常小于10%。日志通道所需的帶寬對于多數應用也相當合理，一般低于 20 Mbit/s，遠低于 1 Gbit/s 網絡的承載能力。空閑的客戶機操作系統（如 Linux 和 Windows）產生的日志帶寬大約在 0.5-1.5 Mbits/sec，主要來自記錄定時器中斷的傳遞。

對于網絡密集型應用，特別是高接收速率的場景，日志通道帶寬可能成為瓶頸，因為所有接收到的網絡包都需要通過日志通道發送給 Backup VM。

目前，VMware FT 的生產版本主要支持單處理器 (uni-processor) 虛擬機。這是因為多處理器 (multi-processor) VM 的確定性重放仍然是一個具有挑戰性的研究領域，主要難點在于幾乎所有對共享內存的訪問都可能構成非確定性操作。不過，單處理器虛擬機對于許多工作負載已經足夠，并且可以通過橫向擴展（使用多個單處理器VM）來滿足需求。

總結

VMware FT 通過在 Hypervisor 層面實現復制狀態機和確定性重放，為虛擬機提供了一種高效、透明的故障切換解決方案。它巧妙地解決了非確定性事件處理、輸出一致性、腦裂等關鍵問題，并通過一系列實用性設計（如 FT VMotion、自動恢復冗余）使其成為一個完整且易用的企業級容錯系統。盡管當前主要針對單處理器虛擬機和 fail-stop 故障，但其設計理念和實現為關鍵業務應用提供了堅實的保障。