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

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

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

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

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

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

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

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

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