VMware FT 容錯(cuò)技術(shù)詳解：原理、挑戰(zhàn)與實(shí)踐

作者：piperliu 2025-06-03 00:00:04

VMware FT 就是這樣一種為虛擬機(jī) (VM) 提供高級(jí)別可用性的解決方案，它通過(guò)在不同物理服務(wù)器上維護(hù)一個(gè)與主虛擬機(jī) (Primary VM) 同步的備份虛擬機(jī) (Backup VM) 來(lái)實(shí)現(xiàn)。

VMware FT 容錯(cuò)技術(shù)詳解：原理、挑戰(zhàn)與實(shí)踐

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

容錯(cuò)的基本概念與方法

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

實(shí)現(xiàn)容錯(cuò)的核心在于復(fù)制。通常有兩種主要的復(fù)制策略：

狀態(tài)傳輸 (State Transfer) ：定期或持續(xù)地將主副本的完整狀態(tài)（包括 CPU、內(nèi)存、I/O 設(shè)備狀態(tài)）傳輸?shù)絺浞莞北尽＿@種方法的缺點(diǎn)是所需帶寬可能非常大，尤其是內(nèi)存變化頻繁時(shí)。
復(fù)制狀態(tài)機(jī) (Replicated State Machine, RSM) ：將服務(wù)器視為確定性狀態(tài)機(jī)。如果兩個(gè)狀態(tài)機(jī)從相同的初始狀態(tài)開(kāi)始，并以相同的順序接收相同的輸入，那么它們將經(jīng)歷相同的狀態(tài)序列并產(chǎn)生相同的輸出。 VMware FT 正是采用了這種方法，通過(guò)在底層復(fù)制虛擬機(jī)內(nèi)存和寄存器的執(zhí)行來(lái)實(shí)現(xiàn)。這種方法的帶寬需求通常遠(yuǎn)低于狀態(tài)傳輸。

VMware FT 的核心：基于 Hypervisor 的復(fù)制狀態(tài)機(jī)

Q: 為什么在虛擬機(jī)上實(shí)現(xiàn)確定性執(zhí)行比在物理服務(wù)器上更容易？

A: 因?yàn)?Hypervisor 模擬并控制了硬件的許多方面，例如中斷傳遞的精確時(shí)機(jī)。這使得 Hypervisor 能夠確保主虛擬機(jī)和備份虛擬機(jī)在面對(duì)相同的輸入時(shí)，其內(nèi)部狀態(tài)以完全相同的方式演進(jìn)。

Q: 什么是 Hypervisor？

A: Hypervisor，也稱(chēng)為虛擬機(jī)監(jiān)視器 (Virtual Machine Monitor, VMM)，是虛擬機(jī)系統(tǒng)的一部分。它模擬一臺(tái)完整的計(jì)算機(jī)，客戶(hù)操作系統(tǒng) (Guest OS) 及其應(yīng)用程序運(yùn)行在這個(gè)模擬的計(jì)算機(jī)（即虛擬機(jī)）內(nèi)。在 VMware FT 架構(gòu)中，Primary VM 和 Backup VM 都是運(yùn)行在各自 Hypervisor 內(nèi)的客戶(hù)機(jī)。

VMware FT 的基石是 確定性重放 (Deterministic Replay) 技術(shù)。 Primary VM 的所有輸入（如網(wǎng)絡(luò)數(shù)據(jù)包、磁盤(pán)讀取、鍵盤(pán)鼠標(biāo)操作以及所有可能導(dǎo)致非確定性行為的事件（如中斷的時(shí)間、讀取 CPU 時(shí)鐘周期計(jì)數(shù)器）都會(huì)被 Hypervisor 捕獲。這些輸入和非確定性事件被記錄成日志條目，通過(guò)一個(gè)專(zhuān)用的 日志通道 (Logging Channel) 實(shí)時(shí)發(fā)送給 Backup VM。 Backup VM 的 Hypervisor 則嚴(yán)格按照這些日志條目來(lái)“重放”P(pán)rimary VM 的執(zhí)行過(guò)程，從而保持兩者狀態(tài)的精確同步，盡管 Backup VM 的執(zhí)行會(huì)略有延遲。

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

A: Hypervisor 控制了所有隨機(jī)性的來(lái)源。

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

關(guān)鍵挑戰(zhàn)與解決方案

1. 輸出規(guī)則 (Output Rule) 與數(shù)據(jù)一致性

Q: VMware FT 如何保證在 Primary VM 故障后，Backup VM 接管時(shí)不會(huì)丟失數(shù)據(jù)或產(chǎn)生外部可見(jiàn)的不一致?tīng)顟B(tài)？

A: 這是通過(guò)嚴(yán)格遵守 輸出規(guī)則 (Output Rule) 來(lái)實(shí)現(xiàn)的。

輸出規(guī)則 ：Primary VM 在向外部世界發(fā)送任何輸出（例如網(wǎng)絡(luò)數(shù)據(jù)包、磁盤(pán)寫(xiě)入到共享磁盤(pán)）之前，必須等待 Backup VM 接收并確認(rèn)了與該輸出操作相關(guān)的日志條目。

這條規(guī)則至關(guān)重要。如果 Backup VM 已經(jīng)確認(rèn)收到了包含某個(gè)輸出操作的日志，那么即使 Primary VM 在該輸出實(shí)際發(fā)送后立即崩潰，Backup VM 也能準(zhǔn)確地重放到該輸出點(diǎn)之前的狀態(tài)，并最終產(chǎn)生與 Primary VM 相同的輸出（或達(dá)到一個(gè)與該輸出一致的狀態(tài)）。如果沒(méi)有這個(gè)規(guī)則，Backup VM 可能在沒(méi)有收到所有必要日志的情況下就上線(xiàn)，導(dǎo)致其狀態(tài)與 Primary VM 已經(jīng)發(fā)出的輸出不一致。

值得注意的是，輸出規(guī)則僅僅延遲了輸出的實(shí)際發(fā)送，Primary VM 本身可以繼續(xù)執(zhí)行后續(xù)指令，而不會(huì)被完全暫停。這與一些早期系統(tǒng)要求 Primary VM 在輸出前必須完全停止直到 Backup VM 確認(rèn)的做法不同。

Q: 如果 Primary VM 在發(fā)送輸出后立即失敗，輸出會(huì)重復(fù)嗎？這會(huì)導(dǎo)致問(wèn)題嗎？

A: Backup VM 在接管后很可能會(huì)重復(fù)該輸出。對(duì)于大多數(shù)情況，這不是問(wèn)題：

網(wǎng)絡(luò)輸出 ：如果輸出是網(wǎng)絡(luò)數(shù)據(jù)包，接收端的 TCP 協(xié)議棧通常能自動(dòng)處理和丟棄重復(fù)的數(shù)據(jù)包。
磁盤(pán) I/O ：磁盤(pán)寫(xiě)入操作通常是冪等的 (idempotent)，即多次執(zhí)行相同的寫(xiě)操作（寫(xiě)入相同數(shù)據(jù)到相同位置且中間無(wú)其他 I/O）與執(zhí)行一次的效果相同。

2. DMA 競(jìng)爭(zhēng) (Race) 與 Bounce Buffers

Q: 什么是 DMA (Direct Memory Access) 競(jìng)爭(zhēng)？VMware FT 如何避免由此導(dǎo)致的非確定性？

A: 當(dāng)硬件設(shè)備（如網(wǎng)卡或磁盤(pán)控制器）通過(guò) DMA 直接向虛擬機(jī)內(nèi)存寫(xiě)入數(shù)據(jù)時(shí)，如果客戶(hù)機(jī)操作系統(tǒng)或應(yīng)用程序恰好在幾乎同一時(shí)刻讀取該內(nèi)存區(qū)域，就可能發(fā)生競(jìng)爭(zhēng)。由于主備虛擬機(jī)執(zhí)行時(shí)序的微小差異，一個(gè)可能讀到新數(shù)據(jù)，另一個(gè)可能讀到舊數(shù)據(jù)，從而導(dǎo)致?tīng)顟B(tài)發(fā)散。

VMware FT 通過(guò)使用 bounce buffers 來(lái)避免這個(gè)問(wèn)題：

當(dāng)網(wǎng)絡(luò)數(shù)據(jù)包或磁盤(pán)數(shù)據(jù)塊到達(dá) Primary VM 時(shí)，數(shù)據(jù)首先被 DMA 到 Hypervisor 控制的一個(gè)私有“bounce buffer”中，這個(gè) buffer 是 Primary VM 無(wú)法直接訪(fǎng)問(wèn)的。
DMA 完成后，F(xiàn)T Hypervisor 中斷 Primary VM 的執(zhí)行，并記錄下中斷發(fā)生的精確指令點(diǎn)。
然后，F(xiàn)T Hypervisor 將 bounce buffer 中的數(shù)據(jù)復(fù)制到 Primary VM 的實(shí)際目標(biāo)內(nèi)存中。
之后，Primary VM 才被允許恢復(fù)執(zhí)行。
同時(shí)，這份數(shù)據(jù)會(huì)通過(guò)日志通道發(fā)送給 Backup VM。 Backup VM 的 FT Hypervisor 會(huì)在相同的指令點(diǎn)中斷 Backup VM，將數(shù)據(jù)從其自己的 bounce buffer（或直接接收到的數(shù)據(jù)）復(fù)制到 Backup VM 的內(nèi)存中，然后恢復(fù)其執(zhí)行。

通過(guò)這種方式，確保了主備虛擬機(jī)在完全相同的執(zhí)行時(shí)刻“看到”輸入數(shù)據(jù)，從而消除了 DMA 競(jìng)爭(zhēng)。盡管 bounce buffer 會(huì)增加一點(diǎn)開(kāi)銷(xiāo)，但通常不會(huì)造成明顯的性能損失。

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

VMware FT 系統(tǒng)使用多種機(jī)制來(lái)檢測(cè) Primary VM 或 Backup VM 的故障：

在運(yùn)行 FT 虛擬機(jī)的服務(wù)器之間進(jìn)行 UDP 心跳檢測(cè) (heartbeating)。
監(jiān)控日志通道上的流量。由于客戶(hù)機(jī)操作系統(tǒng)通常有規(guī)律的定時(shí)器中斷，日志流量應(yīng)該是持續(xù)的。如果日志條目或確認(rèn)信息流中斷超過(guò)預(yù)設(shè)的超時(shí)時(shí)間（通常幾秒鐘），則可能表明發(fā)生了故障。

當(dāng)檢測(cè)到故障時(shí)：

如果 Backup VM 失敗，Primary VM 會(huì)“上線(xiàn) (go live)”，即停止記錄日志并轉(zhuǎn)為普通模式運(yùn)行。
如果 Primary VM 失敗，Backup VM 的上線(xiàn)過(guò)程稍微復(fù)雜：它必須首先消耗掉其日志緩沖區(qū)中所有已接收但尚未處理的日志條目，以使其狀態(tài)達(dá)到 Primary VM 失敗前的最新點(diǎn)。完成后，Backup VM 停止重放模式，轉(zhuǎn)為新的 Primary VM，并開(kāi)始向外部世界產(chǎn)生輸出。此時(shí)，F(xiàn)T 系統(tǒng)會(huì)自動(dòng)更新網(wǎng)絡(luò)，例如通告新 Primary VM 的 MAC 地址，以便網(wǎng)絡(luò)交換機(jī)能將流量導(dǎo)向正確的服務(wù)器。

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

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

A: 當(dāng) Primary VM 和 Backup VM 之間的網(wǎng)絡(luò)連接中斷（網(wǎng)絡(luò)分區(qū)），但它們各自的物理服務(wù)器仍在運(yùn)行時(shí)，可能會(huì)發(fā)生腦裂。雙方都可能錯(cuò)誤地認(rèn)為對(duì)方已經(jīng)崩潰，并嘗試獨(dú)立“上線(xiàn)”成為唯一的活動(dòng)虛擬機(jī)。如果兩者都成功上線(xiàn)，將導(dǎo)致數(shù)據(jù)損壞和客戶(hù)端混淆。

VMware FT 使用 共享存儲(chǔ) (Shared Storage) 上的一個(gè)原子性 test-and-set 操作作為決勝機(jī)制 (tie-breaker) 來(lái)解決腦裂問(wèn)題。

共享存儲(chǔ)上維護(hù)一個(gè)初始為 false 的標(biāo)志。
當(dāng) Primary VM 或 Backup VM 認(rèn)為對(duì)方失效并決定自己上線(xiàn)時(shí)，它會(huì)首先向共享存儲(chǔ)發(fā)送一個(gè) test-and-set 請(qǐng)求。
存儲(chǔ)服務(wù)會(huì)原子地執(zhí)行類(lèi)似以下邏輯的操作：

test-and-set() {
    acquire_lock()
    if flag == true:
    release_lock()
    return false // 已經(jīng)被設(shè)置過(guò)了，你不能上線(xiàn)
    else:
    flag = true
    release_lock()
    return true  // 設(shè)置成功，你可以上線(xiàn)
}

只有當(dāng) test-and-set 操作返回 true 時(shí)，該虛擬機(jī)才被允許上線(xiàn)。如果返回 false，意味著另一方已經(jīng)成功上線(xiàn)（或正在上線(xiàn)），當(dāng)前虛擬機(jī)則會(huì)停止自己（“自殺”）以避免沖突。如果虛擬機(jī)無(wú)法訪(fǎng)問(wèn)共享存儲(chǔ)，它會(huì)等待直到可以訪(fǎng)問(wèn)為止。

這種機(jī)制確保了即使在網(wǎng)絡(luò)分區(qū)的情況下，也只有一個(gè)虛擬機(jī)能夠成功上線(xiàn)。

5. 啟動(dòng)與重啟 FT 虛擬機(jī)

為了能夠啟動(dòng)一個(gè)新的 Backup VM 與一個(gè)正在運(yùn)行的 Primary VM 同步，或者在故障后重新建立冗余，VMware FT 使用了一種修改版的 VMotion 技術(shù)，稱(chēng)為 FT VMotion。

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

6. 日志通道管理

主備 Hypervisor 都會(huì)為日志條目維護(hù)大型緩沖區(qū)。 Primary VM 產(chǎn)生日志到其緩沖區(qū)，Backup VM 從其緩沖區(qū)消耗日志。
Primary 的日志緩沖區(qū)內(nèi)容會(huì)盡快發(fā)送到日志通道，Backup 會(huì)盡快從通道讀取到自己的緩沖區(qū)。 Backup 在讀取日志后會(huì)向 Primary 發(fā)送確認(rèn) (acknowledgments)。這些確認(rèn)用于 Output Rule 的判斷。
如果 Backup 的日志緩沖區(qū)為空，它會(huì)暫停執(zhí)行等待新日志。
如果 Primary 的日志緩沖區(qū)已滿(mǎn)（通常因?yàn)?Backup 處理過(guò)慢或網(wǎng)絡(luò)擁塞），Primary VM 必須暫停執(zhí)行，這是一種自然的流控機(jī)制。為避免這種情況影響 Primary VM 性能，系統(tǒng)會(huì)監(jiān)控主備之間的執(zhí)行延遲。如果 Backup VM 落后太多（例如超過(guò)1秒），F(xiàn)T 系統(tǒng)會(huì)逐漸降低 Primary VM 的 CPU 分配，使其放慢速度，以便 Backup VM 能跟上。

7. 磁盤(pán) I/O 的特殊處理

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

Q: 當(dāng) Primary VM 發(fā)生故障時(shí)，那些已經(jīng)發(fā)起但可能尚未在物理磁盤(pán)上完成的 I/O 請(qǐng)求如何處理？

A: 當(dāng) Backup VM 上線(xiàn)成為新的 Primary VM 時(shí)，在其“go-live”過(guò)程中，它會(huì)重新發(fā)出這些掛起的 (pending) I/O 請(qǐng)求。具體來(lái)說(shuō)，日志中那些有 I/O 啟動(dòng)記錄但沒(méi)有對(duì)應(yīng)完成中斷記錄的 I/O 操作，都需要在 Backup VM 上線(xiàn)時(shí)重新啟動(dòng)。由于 VMware FT 已經(jīng)通過(guò) bounce buffer 等機(jī)制消除了 I/O 競(jìng)爭(zhēng)，并且 I/O 操作明確指定了內(nèi)存和磁盤(pán)塊，因此這些重新發(fā)出的磁盤(pán)操作即使之前已經(jīng)成功完成過(guò)，再次執(zhí)行也是安全的（冪等性）。

8. 網(wǎng)絡(luò) I/O 的挑戰(zhàn)與優(yōu)化

為了確保確定性，VMware FT 對(duì)網(wǎng)絡(luò) I/O 的處理做了一些調(diào)整：

禁用了某些基于 Hypervisor 異步更新虛擬機(jī)網(wǎng)絡(luò)設(shè)備狀態(tài)的性能優(yōu)化。例如，接收緩沖區(qū)不能再由 Hypervisor 在 VM 執(zhí)行時(shí)直接異步更新，而是需要陷入 (trap) 到 Hypervisor，記錄更新操作，然后再應(yīng)用到 VM。類(lèi)似的，異步發(fā)送數(shù)據(jù)包的優(yōu)化也被禁用，發(fā)送操作也需要通過(guò) trap 完成。
這些改變以及 Output Rule 帶來(lái)的發(fā)送延遲對(duì)網(wǎng)絡(luò)性能構(gòu)成挑戰(zhàn)。
優(yōu)化措施

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

b.減少發(fā)送延遲 ：關(guān)鍵在于減少日志消息發(fā)送到 Backup VM 并獲得確認(rèn)所需的時(shí)間。通過(guò)確保日志條目和確認(rèn)信息的發(fā)送與接收都可以在沒(méi)有線(xiàn)程上下文切換的情況下完成（例如使用類(lèi)似 Linux tasklet 的延遲執(zhí)行上下文處理 TCP 數(shù)據(jù)接收），以及在 Primary VM 發(fā)送數(shù)據(jù)包時(shí)強(qiáng)制立即刷新相關(guān)日志條目，可以顯著降低延遲。

性能與局限性

VMware FT 在典型企業(yè)應(yīng)用上的性能開(kāi)銷(xiāo)通常小于10%。日志通道所需的帶寬對(duì)于多數(shù)應(yīng)用也相當(dāng)合理，一般低于 20 Mbit/s，遠(yuǎn)低于 1 Gbit/s 網(wǎng)絡(luò)的承載能力?？臻e的客戶(hù)機(jī)操作系統(tǒng)（如 Linux 和 Windows）產(chǎn)生的日志帶寬大約在 0.5-1.5 Mbits/sec，主要來(lái)自記錄定時(shí)器中斷的傳遞。

對(duì)于網(wǎng)絡(luò)密集型應(yīng)用，特別是高接收速率的場(chǎng)景，日志通道帶寬可能成為瓶頸，因?yàn)樗薪邮盏降木W(wǎng)絡(luò)包都需要通過(guò)日志通道發(fā)送給 Backup VM。

目前，VMware FT 的生產(chǎn)版本主要支持單處理器 (uni-processor) 虛擬機(jī)。這是因?yàn)槎嗵幚砥?(multi-processor) VM 的確定性重放仍然是一個(gè)具有挑戰(zhàn)性的研究領(lǐng)域，主要難點(diǎn)在于幾乎所有對(duì)共享內(nèi)存的訪(fǎng)問(wèn)都可能構(gòu)成非確定性操作。不過(guò)，單處理器虛擬機(jī)對(duì)于許多工作負(fù)載已經(jīng)足夠，并且可以通過(guò)橫向擴(kuò)展（使用多個(gè)單處理器VM）來(lái)滿(mǎn)足需求。

總結(jié)

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

責(zé)任編輯：姜華來(lái)源： Piper蛋窩