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

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

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

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

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

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

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

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

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