無論是一臺虛擬機崩潰或是主機出錯，高可用性虛擬化（HA）應用工具保證可以自動重啟出錯的虛擬機。這些HA應用卻為開發(fā)人員和服務器管理員帶來了不切實際的希望。

　　服務器管理團隊開始相信他們可以將HA工具應用于各式各樣的企業(yè)套管程序，但是最近由數(shù)據(jù)中心之間虛擬機的機動性帶來的挑戰(zhàn)，正是錯誤地相信了HA的魔力所帶來的直接后果。

　　讓我們來關心一下關于HA產(chǎn)品的傳說與現(xiàn)實情況：

　　VMware的高可用性：假定你可以準確地檢測到一個虛擬機操作系統(tǒng)或應用服務出錯（例如：數(shù)據(jù)庫軟件），但你仍然需要重啟虛擬機。一些時間的流失就是系統(tǒng)可運行性上一個9的損失（系統(tǒng)的可運行性一般用百分數(shù)表示，常用的是5個9——99.999%，一個9的損失就會使可運行性降至99.99%）。

　　VMware的容錯性：這個特征是指在兩臺主機上分別同時運行相同虛擬機的兩個不同副本。對于短期問題而言這是一個***的解決方案，例如：我不想讓硬件問題中斷我的長時間的批處理任務。可現(xiàn)實問題是如果虛擬機或是它自己的軟件崩潰，這個虛擬機的兩個副本會同時崩潰。

　　高可用性集群：類似Windows Server故障轉(zhuǎn)移集群技術（Failover Clustering）的策略會在同一個或者另外一臺服務器上重啟失敗的服務（例如：SQL服務），與此同時，這種重啟會耗費若干秒鐘到若干分鐘的時間不等，有時如果數(shù)據(jù)庫必須進行大規(guī)模恢復時甚至會耗費更長的時間。這也會降低系統(tǒng)的可運行性。

　　現(xiàn)在讓我?guī)砹硗庖环N數(shù)據(jù)觀點：我們最近經(jīng)歷了一次由一個站內(nèi)STP協(xié)議錯誤導致的轉(zhuǎn)發(fā)循環(huán)。在網(wǎng)管系統(tǒng)（NMS）及時發(fā)現(xiàn)問題和一個操作員現(xiàn)場支持的情況下，恢復時間花費了將近30分鐘。不可否認，這其中一些時間花在了收集便于事后處理分析的證據(jù)上。

　　下一個事實：數(shù)據(jù)中心之間的橋接可能會導致長距離的轉(zhuǎn)發(fā)循環(huán)，或者你可能看到由轉(zhuǎn)發(fā)循環(huán)導致的流量泛洪溢出鏈接其他數(shù)據(jù)中心的WAN，截斷同所有其他數(shù)據(jù)中心之間的流量（如果你有足夠的勇氣使用長距離的集群的話，也會截斷集群心跳線的流量）和存儲響應。你真的愿意將整個IT基礎設施置于風險中來支持一個無論如何連3.5個9的可運行性都無法達到的應用嗎？別忘了，大家都希望服務器管理員可以為服務器打補丁，而打補丁偶爾需要重啟，不是么？

　　故事的寓意：“魔力”產(chǎn)品讓你產(chǎn)生一種錯誤的安全感；就像MySQL數(shù)據(jù)庫集群一樣，好的應用架構和使用真正高可用性的產(chǎn)品才是唯一正確的應對高可用性挑戰(zhàn)的解決方案。