現(xiàn)如今，以虛擬化技術(shù)來架構(gòu)企事業(yè)單位的核心IT系統(tǒng)已經(jīng)越來越普遍，對虛擬化技術(shù)的運用也從懷疑走向信任，從陌生走向熟悉。伴隨著虛擬化技術(shù)的不斷演進，虛擬化技術(shù)本身已經(jīng)不再是用戶擔心的首要問題，取而代之的是如何更好地規(guī)劃虛擬化架構(gòu)，如何讓虛擬化技術(shù)更好地服務(wù)IT服務(wù)，以及與運維場景相關(guān)聯(lián)的個性化技術(shù)細節(jié)。

本文以vSphere為例，從虛擬化基礎(chǔ)設(shè)施運維所涉及的各個方面出發(fā)，探討運維的問題及合理性。

從服務(wù)器說起

無論虛擬化如何水平或垂直構(gòu)建資源池，物理服務(wù)器始終是所有計算資源的承載單元，其整個x86架構(gòu)的制造工藝和設(shè)計水平都真真切切影響著整個虛擬化架構(gòu)的穩(wěn)定和高效。以一個常見的比喻來說，物理服務(wù)器就是裝雞蛋的籃子，雖然是個“籃子”都可以拿來放雞蛋，但“籃子”是否結(jié)實耐用、孔洞大小是否便于排列雞蛋等細節(jié)，則決定了雞蛋的命運。因此，一個多路處理器、大內(nèi)存的服務(wù)器，并不能簡單地像DIY一樣拼裝高配的零件就可以成為好的“籃子”，還需要兼顧虛擬化可以發(fā)揮優(yōu)勢的一些特征，比如機箱的物理散熱和雙電源，支持SD卡來安裝Hypervisor，磁盤的數(shù)量和型號滿足vSAN的部署條件，是選用光口還是電口的網(wǎng)卡、網(wǎng)卡的數(shù)量、網(wǎng)卡是否支持FCoE、交換機上千兆和萬兆接口剩余的數(shù)量，選擇FCSAN的存儲以及IPSAN如何接入等，缺少這些考量的服務(wù)器，則難免在未來部署或使用中面臨各種擴展性或性能的問題。

在CPU和內(nèi)存的容量配比上值得注意的是，物理內(nèi)存若配置得較大，比如128GB，甚至256GB，則CPU也應(yīng)考慮選擇同檔次里較高的一款，因為消耗CPU的虛機和大量不消耗CPU卻占用內(nèi)存的虛機都需要物理的CPU去調(diào)度和處理，我們既不希望看見CPU負載75%，內(nèi)存負載85%的場景，也不希望CPU負載僅10%，內(nèi)存負載就90%的不均衡。針對這個矛盾，可以考慮初期配置較高的CPU和適量的內(nèi)存，后期根據(jù)運行情況對內(nèi)存進行擴容，因為內(nèi)存的擴充較為便宜和方便。

ESXi是安裝在物理服務(wù)器上的底層操作系統(tǒng)，該系統(tǒng)可以說也是“籃子”的一部分，從操作系統(tǒng)的角度來說，ESXi已經(jīng)是較為極致的，可以安裝在機架服務(wù)器1G的SD卡存儲器，也可以通過USB來引導(dǎo)運行，還可以通過網(wǎng)絡(luò)自動部署服務(wù)加載到內(nèi)存，只要裝好了ESXi，后期的運維幾乎都不用再進機房面對服務(wù)器裸機（有遠程管理或KVM例外）。對于具備HBA卡虛擬化特性的服務(wù)器，則建議以boot from san的方式安裝ESXi，因為當單個計算節(jié)點故障時，可以直接關(guān)聯(lián)虛擬HBA卡及其相關(guān)硬件信息到備用的計算節(jié)點，實現(xiàn)快速而完整的故障恢復(fù)，即縮短RTO，也便于技術(shù)人員維修或更換。此外，還有HP、Cisco、Fujitsu、Hitachi等幾個廠商的服務(wù)器，ESXi都封裝了OEM定制版，定制版無疑在驅(qū)動的支持上要優(yōu)于通用版介質(zhì)，使用這些廠商設(shè)備時也應(yīng)盡可能使用OEM版介質(zhì)。

對舊服務(wù)器，只要支持VT-x或AMD-v，內(nèi)存大于等于4GB，也是可以考慮部署為ESXi底層的，因為它即使只能裝一個虛機，也可以讓這個虛機具備可遷移的能力，當故障來臨或業(yè)務(wù)重要性提升時，可以從容地遷移到其他服務(wù)器。

配置虛擬機

承接前文的比喻，虛擬機就是裝在“籃子”中的一只只“雞蛋”，雞蛋的數(shù)量在更多的場景中取決于內(nèi)存的大小，強烈建議在重要生產(chǎn)環(huán)境中，同一物理機分配給虛機內(nèi)存總和不宜超過物理內(nèi)存大小，雖然虛擬化環(huán)境具備內(nèi)存精簡算法，能夠?qū)ο嗤牟僮飨到y(tǒng)共同的內(nèi)存部分采用共享的方式來節(jié)約內(nèi)存使用，但既然是算法，就會消耗CPU調(diào)度，就會帶來一定的延遲，這些損耗在稍舊的服務(wù)器上表現(xiàn)更為明顯。反之，對于計算資源拮據(jù)的環(huán)境，或?qū)\行效率沒有較高要求的環(huán)境，還是可以利用此技術(shù)優(yōu)勢來節(jié)約經(jīng)費投入的。

在虛機的vCPU方面，應(yīng)盡量采用單插槽多內(nèi)核的方式，因為設(shè)定多個插槽的vCPU在運行中，會跨物理CPU插槽運行，這將增加CPU調(diào)度的損耗，而單個虛擬插槽的vCPU配置，則會在同一顆物理CPU內(nèi)來虛擬，使得虛機在使用CPU資源時調(diào)度效率更高，這一細節(jié)對運算量較大的虛機還是較為重要的。

虛機的磁盤主要是vmdk文件，該文件是虛機的本源，假設(shè)虛機其他文件都遭到破壞或丟失，但只要vmdk完好，就能夠恢復(fù)虛機運行。眾所周知，vmdk采用厚置備可以獲得更好的磁盤效率，采用精簡置備方式可以在劃分時超出物理LUN的大小上限，但在重要的生產(chǎn)環(huán)境中，本文則建議按需分配，首先對于虛機磁盤的使用比率，可以在周期性巡檢維護中獲知，利用操作系統(tǒng)的擴盤特性，如Windows的跨區(qū)卷、Linux的lvm等，待空間不足時新增vmdk來擴充是較為合理的。其次，對于vmdk容量總和超出物理LUN大小，一旦某個虛機因未知的事件快速填充過多預(yù)留的vmdk空間，容易使整個物理LUN在管理員無防備的情況下被寫滿，此時，該物理LUN上的所有虛機都會因物理LUN的磁盤滿而停機，后果是可想而知的。vmdk經(jīng)過配置，也可以作為虛擬的共享磁盤為兩個或多個虛機所共用，利用這一特性也可以搭建出Oracle rac之類的集群環(huán)境，并且效率并不差，所需注意的是共享的vmdk不要進行存儲位置的遷移，否則會在遷移中被當作每個虛機私有的磁盤復(fù)制為多個，進而破壞了共享的集群配置。

與vmdk相關(guān)聯(lián)的一個實用功能是快照，它可以保持vmdk在某一個時間點的狀態(tài)，后繼運行對磁盤產(chǎn)生的變化則用差分的vmdk去記錄，對存在風險的虛機調(diào)試特別方便，但也常常被錯誤地當作備份工具去使用。首先快照產(chǎn)生的差異vmdk存在于生產(chǎn)的LUN，過多的創(chuàng)建快照浪費昂貴的LUN空間。其次，快照數(shù)量過多潛在影響虛機運行效率，因為很可能存在連續(xù)讀取的I/O分布在多個快照vmdk中，而查詢多個vmdk文件內(nèi)在關(guān)聯(lián)性是需要消耗資源的；再次，較多的快照文件在vmdk遷移時，更容易出現(xiàn)失敗。

有不少管理員認為，既然是虛擬的，每個虛機分配的計算資源可以多一些，反正用不到的部分是可以被其他虛機使用的。誠然，單臺物理服務(wù)器的CPU資源是按照已開機虛機分配的vCPU數(shù)量去平均的，但還有內(nèi)存和磁盤I/O的優(yōu)先級呢？本文依然建議，每個虛機盡可能按需分配，這個需應(yīng)是平峰負載所需的計算資源。若將分配虛擬硬件的資源當作預(yù)留計算資源，則是對虛擬化管理的誤區(qū)。

比如某個虛機偶爾占滿資源，但因為程序不好而不釋放資源，比如新建虛機數(shù)量較多，則整個硬件資源池，可能是CPU也可能是內(nèi)存也會較快達到飽和，此時再從已分配的虛機里去擠資源就較難了，即使新采購硬件也可能時間周期長或經(jīng)費不足。我們可以按照不同應(yīng)用劃分資源池，由資源池預(yù)留這些應(yīng)用在負載高峰期所需的計算能力，包括CPU資源、物理內(nèi)存占用的優(yōu)先級、vmdk對I/O的優(yōu)先級，從而使資源池的虛擬硬件分配和占用更趨合理。

虛機模版是許多管理員喜愛的工具，最顯著的優(yōu)勢就是快速批量部署虛機，但使用此功能一定不能偷懶，尤其對于Windows模版要配置好封裝工具，以使SID在每次快速部署中得到更換，否則很容易埋下SID相同帶來的隱患問題。

如果說vmdk是虛機存活在vmfs中的唯一形式，那么ovf則是虛機跨越文件系統(tǒng)和虛機格式的一個開放形態(tài)，將虛機導(dǎo)出為ovf/ova格式，ovf文件完整的封裝當前虛機的所有文件和虛擬硬件配置，使虛機以文件的形式保存在常見的文件系統(tǒng)中，進而可以再導(dǎo)入其他虛擬化平臺，實現(xiàn)更靈活的可遷移能力。與ovf靜態(tài)轉(zhuǎn)換相對應(yīng)的是Converter工具，它能夠?qū)⒃诰€狀態(tài)的物理機轉(zhuǎn)換為虛機，將較早前版本的虛機轉(zhuǎn)換為新的虛機版本，將不同vCenter中虛機進行復(fù)制傳送，并在轉(zhuǎn)換過程中實現(xiàn)磁盤格式在精簡與厚置備之間的轉(zhuǎn)換，利用此靈活性，有文件反復(fù)寫入的虛機也可以在轉(zhuǎn)換中將vmdk文件按順序重新生成，換言之相當于對vmdk做了磁盤碎片整理，從而提高vmdk的讀寫效率。

圍繞vCenter去架構(gòu)

虛擬化基礎(chǔ)設(shè)施的中央控制單元vCenter是運維必不可少的利器，它自身由單點登錄組件、數(shù)據(jù)庫、清單組件以及vCenter服務(wù)等多個部分構(gòu)成，許多部署環(huán)境也將這些組件分別安裝在多個虛機里，以支撐較大規(guī)模的部署。但現(xiàn)實中，什么樣的規(guī)模可以稱之為大呢？以清單組件安裝時提供的選項可以作為一個參考，即100主機、1000虛機以內(nèi)，都可以作為小規(guī)模，以此為標準，我們身邊大部分的虛擬化環(huán)境都是小規(guī)模。

界定這一標準，我們大可不必逐項給每個組件新建Windows虛機，取而代之的是用 vCenter的 Appliance，該Appliance以SUSE12為基礎(chǔ)，整合了 vCenter Server、SSO、Inventory Service、Database、Web Client、Log Browser、ESXi Dump Collector、Syslog Collector、Auto Deploy等幾乎全套的組件，較高的整合度帶來了完整的功能。此外，相對于多個Windows來搭建，僅一個Linux系統(tǒng)也能給vCenter帶來更多的穩(wěn)定性和安全性，官方預(yù)置的環(huán)境相對不熟練的管理員，也能避免自行配置中一知半解的不恰當配置，在硬件資源緊缺的環(huán)境中，Appliance能夠帶來集中且可靠的中央控制服務(wù)。同時，Appliance可以直接升級打補丁，這比分散搭建環(huán)境進行升級要容易許多。

提到升級，不得不說Update Manager這個組件，它能夠方便地對集群中的ESXxi打補丁或跨版本升級，可以對虛機的vmtools進行批量更新，強烈建議在每個vCenter中都部署它，因為安全問題無小事，每一個ESXi都承載了太多的虛機，存在安全或健壯性短板的ESXi無疑給上層運行的虛機帶來了太多意料之外的可能性。并且，通過它對ESXi進行跨版本升級也能保留原有ESXi上關(guān)于網(wǎng)絡(luò)和其他插件的配置，極大簡化跨版本升級時瞻前顧后的各種考慮。目前的UM沒有OVA版，需要自行安裝Windows環(huán)境去搭建。作為vCenter插件，難免在vCenter做了調(diào)整后遇到UM被禁用的情況，此時可以使用UM安裝路徑下的VMwareUpdate ManagerUtility.exe工具，重新注冊到vCenter以解決問題。

伴隨著虛機數(shù)量的增加，Operations Manager（以下簡稱 vcops）和 Data Protection（以下簡稱vdp）是兩個不可或缺的常見工具。

vcops收集從服務(wù)器到虛機的性能指標，通過算法將各個層面的性能狀態(tài)轉(zhuǎn)化為可視化的圖表值。通常，需要連續(xù)采集2個月的運行狀態(tài)，才能較為準確地反映出CPU、內(nèi)存負載、網(wǎng)絡(luò)和磁盤吞吐率等情況的健康度，管理員依靠此工具，可以關(guān)注每個虛機和虛擬化整體的健康度，因為健康值是根據(jù)一長段時間的積累分析計算出來的，并不是單純地從當前和上一個時間段的負載去簡單比較，尤其對于磁盤I/O的負載，從SAN的管理端也只能看到哪個LUN的I/O較高，在vcops中能夠準確地知道是哪個虛機造成了較大的I/O。

與開源的Cacti或Nagios監(jiān)控工具相比，第三方監(jiān)控是對具體對象的監(jiān)控，每一個物理機、虛機的CPU、磁盤、網(wǎng)絡(luò)都可看到，是針對點的狀態(tài)反映，而vcops則將所有的對象關(guān)聯(lián)起來進行監(jiān)控和分析，得到的是針對面的狀態(tài)反映，這更有利于管理員掌握虛擬化基礎(chǔ)設(shè)施的綜合運行情況。

vdp是虛機的備份和恢復(fù)工具，備份的主要對象就是vmdk，與快照類似，利用差異化的vmdk文件實現(xiàn)增量備份，但卻獨立在生產(chǎn)LUN之外，能夠更好地管理vmdk，可以根據(jù)備份的策略實現(xiàn)不同粒度的備份需求，重復(fù)數(shù)據(jù)刪除也有效節(jié)省實際所需的備份空間消耗。在vdp虛機啟動過程中，可以觀察到許多avamar字樣，可以想象，vdp與avamar有著不淺的聯(lián)系，但與avamar相比，它們都是作為插件集成，vdp與vCenter結(jié)合的緊密度更高，avamar作為第三方插件，功能比vdp更為全面，收費也不低，而vdp總的備份空間限定在2TB之內(nèi)，可以免費使用。

當然，vCenter可用的組件不僅限于上述，還有用于vSphere整體安全的vCNS，用于容災(zāi)的SRM等，在近些年的快速發(fā)展中，一些組件逐漸消失，一些組件不斷得到加強而成為新的產(chǎn)品，這也正是虛擬化技術(shù)對IT持續(xù)散發(fā)的魅力所在。

將被變革的存儲

在服務(wù)器虛擬化發(fā)展的上一階段，CPU和內(nèi)存一直是池化的主要對象，存儲還只是拿來就用的設(shè)備，與普通服務(wù)器系統(tǒng)相比，最大的區(qū)別就是將磁盤格式化為vmfs這個文件系統(tǒng)，這個文件系統(tǒng)與vmdk文件是相輔相成的，比如精簡置備、虛擬機集群等特性都是基于vmfs實現(xiàn)的。值得注意的是，vmfs也是有版本的，我們很可能會將vSphere環(huán)境跨版本升級到一個新的版本號，卻遺忘了檢查和升級vmfs的版本。一方面，vmfs版本升級可以修復(fù)一定的漏洞，另一方面，低版本的vmfs運行在高版本的虛機上，很容易引發(fā)虛機內(nèi)I/O問題。

當前，存儲的池化成了本階段新的發(fā)展重點，vSAN就是利用服務(wù)器直連磁盤而創(chuàng)建的高可用存儲，它組網(wǎng)要求至少一塊萬兆網(wǎng)卡，擁有SATA/SAS HBA或直通模式下使用的RAID控制器，用于存儲容量的磁盤至少有1塊SSD和1塊 HDD（SATA/SAS），SSD與HDD裸盤容量的比例不少于1:10，每個主機可以創(chuàng)建不超過5個磁盤組，每個磁盤組的HDD不超過6塊，至少3臺滿足上述條件的主機組成集群。

符合上述要求的vSAN舉例來說，SSD的70%用于讀加速，30%用于寫加速，HDD是主要的容量供給，若單臺服務(wù)器可裝6塊3TB的HDD和2塊240GB的SSD，3臺服務(wù)器可獲取近50TB存儲空間，每臺400GB的磁盤緩存對于提升IOPS也能較好應(yīng)用在大多應(yīng)用場景，即減少了存儲的購置經(jīng)費，也在一套技術(shù)體系內(nèi)真正統(tǒng)管并池化了所有計算資源，減輕了存儲系統(tǒng)維護復(fù)雜度。

不過，vSAN更大的優(yōu)勢還在故障冗余，每個運行在vSAN集群中的虛機，可以設(shè)置為允許多個故障數(shù)，即設(shè)置虛機文件的冗余份數(shù)，在這樣一個3節(jié)點環(huán)境中，假設(shè)故障數(shù)設(shè)置為2，則可達到2臺服務(wù)同時壞掉，這一虛機仍可存活在僅有一臺服務(wù)器上，因為它在每個服務(wù)器的存儲上都具有了副本，這在以FCSAN/IPSAN為存儲的架構(gòu)里則是難以達到的。當然，高可用的特性，也是以損耗總的存儲空間為代價的，但反過來，用代價不菲的存儲雙活技術(shù)所投入的經(jīng)費和消耗的存儲空間會更多。從這個視角來看，vSAN就是顛覆傳統(tǒng)存儲的神器。

展望下一階段，新的vVOL技術(shù)將架起聯(lián)系vmdk與存儲LUN的橋梁，打破LUN不知道 有 vmdk，vmdk不 知 vmfs下是什么存儲的割裂局面，虛機成為存儲管理和存儲策略的基本對象。我們可以假想這樣的場景：給一個新建的虛機定義了高可用的策略，存儲就給該虛機創(chuàng)建多個互為克隆的vVOL，從而保證了虛擬機的可用性，甚至這多個vVOL放置在不同的存儲設(shè)備上，且互為鏡像，保證了無論是存儲設(shè)備還是服務(wù)器掛掉都無法阻止虛擬機的運行。

行進中的網(wǎng)絡(luò)虛擬化

原本一臺服務(wù)器接入幾個網(wǎng)絡(luò)就用幾塊網(wǎng)卡是件簡單明了的事情，而自虛擬化使用以來，一個物理服務(wù)器承載數(shù)十甚至上百的虛機也不是難事，于是，物理的網(wǎng)卡由單一的網(wǎng)絡(luò)接口一下子提升到承載上百端口，多個VLAN，甚至不同的個性化端口策略的需求上，儼然擔當了一個交換機的功能。再將視線擴展到多個服務(wù)器組成的虛擬化集群，服務(wù)器的網(wǎng)卡順理成章地成為了上連交換機的級聯(lián)口，其下對應(yīng)著數(shù)以百計虛擬的網(wǎng)卡，于是，分布式虛擬交換機就這么誕生了，它將聯(lián)網(wǎng)的范圍從單個ESXi的標準虛擬交換機擴展到了整個vCenter的范圍，提供集中化的管理端口以及高級特性。

經(jīng)過多年的發(fā)展，目前能用到的分布式虛擬交換仍然只有廠商提供的Virtual Distribution Switch（以 下簡稱VDS）和Cisco Nexus 1000V（以下簡稱N1K）兩個選擇。VDS原生在vSphere內(nèi)部，具有圖形界面，部署配置更為簡便易用；N1K與VDS一樣首先是具備分布式虛擬交換的功能，其次，它具備Cisco網(wǎng)絡(luò)所具備的交換管理特性，能夠像對待直連交換機的服務(wù)器一般配置端口策略和訪問控制，并且這些配置在網(wǎng)絡(luò)遷移時也會隨之移動。同時，也使網(wǎng)絡(luò)管理能夠跨越vSphere層面回歸到傳統(tǒng)的管理習慣上，命令行的管理界面也更貼近網(wǎng)絡(luò)管理員的親切感。

伴隨著技術(shù)演進，各大網(wǎng)絡(luò)設(shè)備廠商陸續(xù)推出了與虛擬化環(huán)境相融合的新設(shè)備或新協(xié)議，以期適應(yīng)以虛擬化為基礎(chǔ)的數(shù)據(jù)中心網(wǎng)絡(luò)管理。作為VDS的提升，NSX是新發(fā)布的網(wǎng)絡(luò)虛擬化平臺，它通過編程方式提供分布式路由、分布式防火墻等服務(wù)，在現(xiàn)有物理網(wǎng)絡(luò)上創(chuàng)建一個覆蓋現(xiàn)有IP網(wǎng)絡(luò)的靈活邏輯層，在滿足東西向和南北向通信的同時，租戶之間也保持相互隔離，在虛擬網(wǎng)絡(luò)內(nèi)提供全面的流量管理、監(jiān)控和故障排除的工具，如端口鏡像、NetFlow/IPFIX、配置備份和還原、網(wǎng)絡(luò)運行狀況檢查、QoS和LACP等。簡單來說，基于服務(wù)器自身，NSX就構(gòu)建了完整的數(shù)據(jù)中心網(wǎng)絡(luò)。

場景決定高可用程度

虛擬化的誕生，將每個操作系統(tǒng)所依賴的物理硬件特征全部虛化成了標準的虛擬硬件，那么，只要虛機文件還在，任何物理故障都不能阻擋服務(wù)快速恢復(fù)，因為標準的虛擬硬件可以不重裝系統(tǒng)就運行到另一個物理載體上，這也是虛擬化環(huán)境具備高可用性的重要基礎(chǔ)。虛擬化集群環(huán)境的這一資源切換技術(shù)由vMotion來實現(xiàn)。vMotion在線將CPU和內(nèi)存的狀態(tài)從一個物理機復(fù)制到另一個，保持業(yè)務(wù)連續(xù)的同時，也改變了虛機的計算載體，這是多么不可思議的能力。

但這項能力也存在制約因素——CPU的指令集。集群中的服務(wù)器并不會是一成不變的一次性采購，而不同年份購置的服務(wù)器，其VPUu也會或多或少有指令集的更新，新增的指令集也就決定了虛機不能從新服務(wù)器漂移到舊服務(wù)器。為了應(yīng)對集群內(nèi)CPU之間存在的差異，我們可以啟用EVC功能，該功能需要指定集群內(nèi)CPU系列的兼容度，也就是指定所有虛機都只在這一款CPU型號的指令集基礎(chǔ)上運行，從而滿足最大的兼容性，實現(xiàn)虛機從低配置CPU到高配置CPU的漂移。這樣一來，擁有更多指令集的CPU特性就不會在任何虛機上體現(xiàn)，其實質(zhì)是放棄了部分高性能能力。本文是覺得特別可惜的，因此，是否啟用EVC也應(yīng)由應(yīng)用場景決定，或者放棄由新CPU向舊CPU漂移的能力，或者放棄新指令集的性能特征，亦或者將新舊CPU物理機編組到不同的集群。

有了vMotion做基礎(chǔ)，HA不間斷地檢測群集中所有的ESXi主機，監(jiān)控群集中是否有足夠的可用資源，以便在檢測到ESXi故障時能自動在其他ESXi上重啟虛機，當檢測到ESXi主機負載達到閾值，DRS將vMotion和HA融合在一起，根據(jù)ESXi主機的CPU或內(nèi)存資源負載，動態(tài)地遷移虛機至較負載較輕的ESXi主機上。在此基礎(chǔ)上，DPM更進一步偵測集群負載，在整體負載較低時選擇ESXi主機并遷移其上的虛機到其他ESXi，繼而關(guān)閉空閑的ESXi主機達到節(jié)能降耗的效果，當集群負載升高，DPM利用iLO、IPMI或LAN喚醒來增加ESXi節(jié)點。

除了上述主機和虛機層面的高可用，虛機之上的應(yīng)用層也可通過FT來實現(xiàn)，F(xiàn)ault Tolerance會創(chuàng)建一個虛機完全相同的副本，主虛機和輔虛機執(zhí)行相同順序的x86指令，任一虛機發(fā)生故障則進行透明的故障切換，從而最大限度地延長該虛機應(yīng)用的正常運行時間。不過，F(xiàn)T在實際使用中并不像想象中那么完美，實現(xiàn)FT的虛機只能有一個單核vCPU，承載兩個虛機的物理機也必須一模一樣，不能有虛擬光驅(qū)等設(shè)備，限制條件較多，而且多次FT切換之后，可能出現(xiàn)輔助虛機不能自動啟動，有時重做FT提示配置跟FT不兼容等細節(jié)問題，實際使用時應(yīng)多做測試驗證以適應(yīng)場景需求。