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

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

讓我們來關心一下關于HA產品的傳說與現實情況：

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

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

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

現在讓我帶來另外一種數據觀點：我們最近經歷了一次由一個站內STP協議錯誤導致的轉發循環。在網管系統（NMS）及時發現問題和一個操作員現場支持的情況下，恢復時間花費了將近30分鐘。不可否認，這其中一些時間花在了收集便于事后處理分析的證據上。

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

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