摘要：和的云計(jì)算功能特點(diǎn)對比正式這個戰(zhàn)爭或者說趨勢的一個生動寫照。總而言之，目前調(diào)度器將只會對部署虛擬機(jī)環(huán)節(jié)有影響。目前有一個孵化項(xiàng)目其作用是為提供虛擬機(jī)級別高可用支持。容錯在中沒有針對于容錯的功能，并且截至目前也沒有計(jì)劃去完成這些功能。

OpenStack中國社區(qū)編者按：在云計(jì)算生態(tài)系統(tǒng)中，有兩種類型的用戶需要使用云計(jì)算資源：傳統(tǒng)型(Traditional IT applications)和在互聯(lián)網(wǎng)大潮下逐漸崛起云計(jì)算應(yīng)用型(Cloud-aware applications)。國外廣為流傳的一個比喻是：在傳統(tǒng)服務(wù)模式下，可以想象服務(wù)器就是IT的寵物（Pets），給他們?nèi)∶?，精心撫養(yǎng)長大，當(dāng)他們生病了，你得修復(fù)他們；在新形態(tài)的應(yīng)用服務(wù)模型中，虛擬機(jī)被看做是農(nóng)場中的公牛(Cattle)，名字通常都是編號，當(dāng)他們生病了，你就殺掉他，用一頭新牛代替。VMWare和OpenStack的云計(jì)算Vision、功能、特點(diǎn)對比正式這個戰(zhàn)爭或者說趨勢的一個生動寫照。未來的應(yīng)用架構(gòu)應(yīng)該像對待農(nóng)場中的公牛一樣：VMware的“保養(yǎng)”、保護(hù)虛擬機(jī)的各種功能較比云計(jì)算型應(yīng)用模式可能會逐漸變得越來越不那么重要。本文在國外廣泛流傳，熱議不斷，中國社區(qū)意譯分享給大家，歡迎積極討論。

全文如下：

在Cloud領(lǐng)域，我們討論最多的就是VMware與OpenStack的對比。事實(shí)上，這也是那些想使用OpenStack的人們熱議的話題。我已經(jīng)在SF Bay OpenStack會議中多次針對這個話題做了討論，會議中很多朋友都希望我把這些討論寫下來。為了讓讀者能夠更好地了解本文的內(nèi)容，我決定通過兩大云計(jì)算產(chǎn)品在數(shù)據(jù)中心應(yīng)用的關(guān)鍵點(diǎn)對比的方式去完成本文的內(nèi)容，內(nèi)容可能包括：開放與非開放的軟件系統(tǒng)，企業(yè)級傳統(tǒng)應(yīng)用與云計(jì)算應(yīng)用，自由軟件與授權(quán)軟件，通過嚴(yán)格功能測試的產(chǎn)品與開放性功能的產(chǎn)品等。

本文中內(nèi)容具體包括以下幾個部分：設(shè)計(jì)、功能集、客戶用例和價值，每點(diǎn)都以十分來評價，最終我們將以總分來決定贏家。

VMware軟件套件是自底向上的架構(gòu)，下端邊界為虛擬機(jī)管理器。像VMware的vSphere和vCloud director產(chǎn)品都是依賴于免費(fèi)的ESX(i) 虛擬機(jī)管理器， ESX(i)虛擬機(jī)管理器為他們提供了非常優(yōu)秀的部署架構(gòu)。本身VMware的軟件套件也是經(jīng)過全面測試過的，并且都有單一部署框架。總的來說，VMware的產(chǎn)品由于其架構(gòu)的健壯性，很多高規(guī)格用戶在多數(shù)據(jù)中心規(guī)模的環(huán)境中都有使用。換句話說，VMware的軟件系統(tǒng)是封閉的，并且軟件的發(fā)展路線是完全遵循VMware自己的發(fā)展目標(biāo)，用戶或消費(fèi)者在此方面沒有任何控制權(quán)。

OpenStack作為一個開源系統(tǒng)，沒有任何一家多帶帶的公司在控制OpenStack的發(fā)展路線。本身OpenStack是年輕的，還不滿三周歲，但是他卻具有巨大的市場動力，與此同時，很多大公司都在支持OpenStack發(fā)展（詳見：OpenStack支持者）。有了如此多公司的資源投入，OpenStack的發(fā)展是多元化的。然而這也帶來了問題，就是OpenStack部署和架構(gòu)的實(shí)施和維護(hù)成本較比VMware有了陡然提高，與此同時，由于相對快速的版本更新速度，技術(shù)支持文檔不能跟上產(chǎn)品的腳步。

VMware在設(shè)計(jì)方面稍占優(yōu)勢，這源于它優(yōu)秀的文檔資料以及便捷易用的部署和管理接口。OpenStack在這個方面也在緊追不舍，并且在硬件和虛擬機(jī)管理層其保持了它自身的靈活性，更是提供了多廠商支持。

VMware vMotion

vMotion是vSphere DRS、DPM和主機(jī)維護(hù)三大功能的合集。其中虛擬機(jī)動態(tài)遷移允許將一臺虛擬機(jī)在零關(guān)機(jī)的情況下由一臺宿主機(jī)遷移到另一臺上，這原本是需要共享存儲的支持的，但在vSphere 5.1中，VMware已經(jīng)不需要通過共享存儲實(shí)現(xiàn)動態(tài)遷移了。當(dāng)一臺虛擬機(jī)由一個宿主機(jī)遷移到另一個上時，虛擬機(jī)的內(nèi)存狀態(tài)和數(shù)據(jù)都要同步遷移過去。如果是共享存儲的情況，實(shí)際上數(shù)據(jù)是不需要進(jìn)行遷移的，只需要變化指向數(shù)據(jù)存儲的鏈接而已。這在加速了遷移速度的同時也減少了在復(fù)制過程中網(wǎng)絡(luò)的負(fù)載。

OpenStack 動態(tài)遷移

KVM動態(tài)遷移允許一個虛擬機(jī)由一個虛擬機(jī)管理器遷移到另一個，說的詳細(xì)一點(diǎn)，你可以來來回回將一臺虛擬機(jī)在AMD架構(gòu)主機(jī)與Intel架構(gòu)主機(jī)上進(jìn)行遷移，但是需要注意的是，64位的虛擬主機(jī)只能被遷移到64位的宿主機(jī)上，但是32位的則有32位和64位兩種選擇。在動態(tài)遷移過程中，不能再對虛擬機(jī)進(jìn)行操作，但是虛擬機(jī)內(nèi)的用戶還是可以在虛擬機(jī)內(nèi)部繼續(xù)進(jìn)行工作的。KVM主要還是依賴于共享存儲，某種程度上，這相對來說是需要一些資金投入的。

動態(tài)遷移需求：

• 虛擬機(jī)存儲需要放在分布式文件系統(tǒng)之上，如NFS或在GlusterFS
• Libvirt必須要開啟listen flag
• 每一個計(jì)算節(jié)點(diǎn)（虛擬機(jī)管理器）都必須在同一個網(wǎng)絡(luò)/子網(wǎng)當(dāng)中
• 計(jì)算節(jié)點(diǎn)間的認(rèn)證必須提前完成配置
• DFS的掛載節(jié)點(diǎn)在每一個計(jì)算節(jié)點(diǎn)必須保持一致

OpenStack塊存儲遷移

在OpenStack當(dāng)中，KVM支持塊存儲遷移，這也就是說虛擬機(jī)遷移不是必須需要共享存儲的支持的。在塊遷移的場景下，虛擬機(jī)的內(nèi)存狀態(tài)與數(shù)據(jù)都將被遷移，但是遷移操作也需要消耗兩端的CPU資源并且操作花費(fèi)時間較比共享存儲來說要長一些。在某些用戶場景當(dāng)中，如果我們比較關(guān)注于主機(jī)的可維護(hù)性，并且不想花費(fèi)過多經(jīng)費(fèi)，那么應(yīng)用塊存儲遷移將是好的解決方案。同時，如果在沒有共享存儲的環(huán)境中，我們想對計(jì)算節(jié)點(diǎn)進(jìn)行內(nèi)核維護(hù)、安全升級，那么保證虛擬機(jī)服務(wù)不被打斷，塊存儲遷移也是理想選擇。

用戶場景：

用戶沒有分布式文件系統(tǒng)，可能是由于企業(yè)的資金支持或者網(wǎng)絡(luò)延遲，但是卻想實(shí)現(xiàn)虛擬機(jī)的高可用性。

VMware DRS 和 DPM

基于vMotion，DRS可以動態(tài)監(jiān)控虛機(jī)機(jī)及宿主機(jī)的當(dāng)前使用狀況，并且為宿主機(jī)的負(fù)載均衡提供支持。

用戶場景：

• 部署階段：可以對監(jiān)控虛擬機(jī)執(zhí)行自定義自動化腳本
• 監(jiān)控階段：DRS可以在ESX(i)主機(jī)上分布式部署虛擬機(jī)，并且持續(xù)監(jiān)控活躍虛擬機(jī)和可用資源，以動態(tài)遷移虛擬機(jī)來實(shí)現(xiàn)資源利用率較大化

基于vMotion， DPM將虛擬機(jī)從低負(fù)載宿主機(jī)遷移掉，并且關(guān)閉以達(dá)到減少電能損耗。當(dāng)負(fù)載增長，DPM將宿主機(jī)重啟，并且部署新的虛擬機(jī)以滿足負(fù)載需要。

OpenStack 調(diào)度器

OpenStack包含了對于compute和volume的調(diào)度器，通過一系列的管理員設(shè)定的規(guī)則參數(shù)和過濾器，OpenStack調(diào)度器將虛擬機(jī)部署到合適的宿主機(jī)上。在過濾器方面，調(diào)度器是非常靈活的，用戶可以自己完成JSON格式的過濾器，并且過濾器還包含很多預(yù)定義的過濾器。雖然OpenStack調(diào)度器非常靈活，但是還是不能完全替代DRS，原因如下：

• 調(diào)度器用于選擇哪個宿主機(jī)進(jìn)行虛擬機(jī)部署的靜態(tài)參考數(shù)據(jù)來源于Nova的數(shù)據(jù)庫。換句話說，就是發(fā)現(xiàn)宿主機(jī)已經(jīng)有了4臺虛擬機(jī)了，那么我們需要選擇一個新的宿主機(jī)去部署下一臺虛擬機(jī)。
• 調(diào)度器只能在虛擬機(jī)部署階段影響部署的位置，一旦部署完成，虛擬機(jī)運(yùn)行后則無法挪動虛擬機(jī)了。如果需要基于動態(tài)數(shù)據(jù)進(jìn)行調(diào)度，那么調(diào)度器需要與外部監(jiān)控解決方案如Nagios合作?？偠灾?，目前OpenStack調(diào)度器將只會對部署虛擬機(jī)環(huán)節(jié)有影響。

VMware High Availability(高可用)

在vSphere中，虛擬機(jī)級別的高可用性是允許在虛擬機(jī)或者ESX(i)主機(jī)出錯時，在不同宿主機(jī)部署相同的虛擬機(jī)。這里不要和容錯（FT）機(jī)制混淆，高可用的意義在于當(dāng)有一些東西出錯了，可以在一定時間內(nèi)自我修復(fù)。高可用是在硬件出問題的時候保證虛擬機(jī)的正常個工作，如果真的出錯了，那么只能在不同的ESX(i)主機(jī)上啟動虛擬機(jī)，這也可能造成服務(wù)的中斷。

OpenStack High Availability(高可用)

目前并沒有官方聲明OpenStack支持虛擬機(jī)級別的高可用性，這個特性在Folsom版本被提出，但是后續(xù)又被放棄了。目前OpenStack有一個孵化項(xiàng)目Evacuate, 其作用是為OpenStack提供虛擬機(jī)級別高可用支持。

VMware Fault Tolerance（容錯）

VMware容錯機(jī)制是通過監(jiān)控虛擬機(jī)的狀態(tài)和所有變化，將這些變化同步到第二臺備份ESX(i)服務(wù)器之上。容錯的概念在于無論是主還是從宿主機(jī)出現(xiàn)問題，只要一方能正常工作，那么宿主機(jī)上的虛擬機(jī)都保持正常工作。拋開營銷中的噱頭，這種機(jī)制還是無法解決虛擬機(jī)中的應(yīng)用程序崩潰，因?yàn)橐坏┮环奖罎ⅲ瑒t這個變化也會同步到從節(jié)點(diǎn)，當(dāng)你停止虛擬機(jī)的服務(wù)去修復(fù)它，從節(jié)點(diǎn)也會同樣停止服務(wù)。所以這個機(jī)制只能保證單點(diǎn)失效的問題不再出現(xiàn)，而真正的應(yīng)用層面的容錯則需要MSCS或者WCS來解決。考慮到其他方面如較高資源使用、內(nèi)存、硬盤、CPU、帶寬的容錯，這些方面都有局限性，并且是使用量相對比較小的功能。如實(shí)現(xiàn)這些則這需要雙倍的內(nèi)存，由于內(nèi)存不能跨主機(jī)復(fù)制，并且還需要CPU lockstepping去同步每一個CPU指令。這將導(dǎo)致只有多帶帶一個虛擬CPU被容錯機(jī)制所監(jiān)控。

OpenStack Fault Tolerance（容錯）

在OpenStack中沒有針對于容錯的功能，并且截至目前也沒有計(jì)劃去完成這些功能。未來，KVM也不再支持鏡像操作功能。

我們可以看到，在功能的支持方面和功能細(xì)節(jié)，OpenStack與VMware還是有差距的，但是這對OpenStack還是有優(yōu)勢的，因?yàn)檩^比VMware的昂貴價格，OpenStack免費(fèi)、開放的優(yōu)勢顯現(xiàn)出來。VMware高投入帶來的功能，OpenStack大部分可以免費(fèi)提供給客戶。

從VMware在功能方面的領(lǐng)先可以看出，VMware還在繼續(xù)研發(fā)除了vMotion、高可用、容錯以外其他的新功能去保護(hù)他們的虛擬機(jī)；OpenStack一方面跟隨VMware的腳步，另一方面他們投入精力在支持更多硬件廠商解決方案的上面。

在我們評價上述功能的價值之前，首先我們需要考慮用例問題。在云計(jì)算生態(tài)系統(tǒng)中，有兩種類型的用戶需要使用云計(jì)算資源：傳統(tǒng)型和云計(jì)算應(yīng)用型。云計(jì)算應(yīng)用型用戶將自己處理HA和DR策略，而傳統(tǒng)型用戶將依賴于云平臺提供的HA和DR。看下面出自VMware云計(jì)算架構(gòu)文章的圖表。

云計(jì)算型應(yīng)用共同特點(diǎn)

• 分布式
• 無狀態(tài)、軟狀態(tài)
• 失效切換在應(yīng)用端
• 擴(kuò)展性在應(yīng)用端

傳統(tǒng)型應(yīng)用共同特點(diǎn)

• 客戶端-服務(wù)器架構(gòu)
• 難以橫向擴(kuò)展
• 失效切換在服務(wù)端
• 擴(kuò)展性在服務(wù)端

傳統(tǒng)型應(yīng)用將需要如FT、VM級別的高可用性、自動病毒掃描等功能，而云計(jì)算型應(yīng)用則不需要，當(dāng)一臺虛擬機(jī)出問題后，新的一臺虛擬機(jī)將替代它。

Pet vs. Cattle

換一種思路去想這件事，那就可以從微軟 William Baker的出名文章 Pets vs. Cattle 的比喻看出OpenStack和Vmware的關(guān)系。

比喻是這樣說的：在傳統(tǒng)服務(wù)模式下，你可以想象你的主機(jī)就是你的寵物，你給他們?nèi)∶郑热鏳usty、cern等等，他們被精心撫養(yǎng)長大。當(dāng)他們生病了，你得修復(fù)他們。在云計(jì)算型應(yīng)用服務(wù)模型中，虛擬機(jī)被看做是農(nóng)場中的公牛，他們的名字通常都是編號，牛和牛長得也差不多，當(dāng)他們生病了，你就殺掉他，用一頭新牛代替。

未來的云應(yīng)用架構(gòu)應(yīng)該像對待農(nóng)場中的公牛一樣。VMware的保養(yǎng)、保護(hù)虛擬機(jī)的各種功能較比云計(jì)算型應(yīng)用模式變得越來越不那么重要了。

?

在這輪比賽中，OpenStack追了上來，雖然VMware有很多OpenStack所不具有的功能，但是針對云計(jì)算型應(yīng)用，這些功能變得不那么重要。未來，你很可能為那些你用不上的、不可控的VMware添加功能買單。

現(xiàn)在是最后一回合，我們將決定比賽結(jié)果。雖然，OpenStack還是VMware更有價值，這個問題并沒有很清晰的答案，并且答案也取決于部署規(guī)模。雖然OpenStack是免費(fèi)使用的，但是他需要有大量工程資源和領(lǐng)域?qū)＜也判?，并且他還需要很多架構(gòu)和搭建方面的工作，因?yàn)樗С趾芏嗖渴饒鼍?，并且安裝過程都不盡相同。VMware則需要花費(fèi)一些經(jīng)費(fèi)購買權(quán)限，并且相對來說更加容易安裝和運(yùn)行，另外較比命令行，VMware則學(xué)習(xí)成本更低一些。

總得來說，OpenStack入門門檻較高，但是隨著項(xiàng)目規(guī)模的擴(kuò)大，你將從中受益，因?yàn)椴槐刂Ц陡哳~的版權(quán)費(fèi)用。VMware雖然在小規(guī)模安裝時相對容易，但是隨著規(guī)模擴(kuò)大，事情就變了。這就是說，隨著云應(yīng)用大規(guī)?；?，大家也更加熟悉OpenStack，那么OpenStack的入門門檻就低得多了。

在云計(jì)算領(lǐng)域，OpenStack和VMware這兩位重量級玩家，VMware在功能和架構(gòu)上稍微領(lǐng)先，但是OpenStack作為一只弱旅，卻在第三回合迎頭趕上并在最后一回合給予對方毀滅性打擊。

后記

巧合的是，在寫這篇文章的時候，VMware股價在一月29日一天就下跌了22%,市場分析稱VMware缺乏清晰、優(yōu)秀的云計(jì)算策略。

我也了解為什么大家不同意我的給分，并且不明我為何在四輪對比中權(quán)重相同。說實(shí)話，這個評分不是那么完美，也沒有那么客觀，但是他有他的存在的意義，他讓這場云計(jì)算這場戰(zhàn)爭變得更加有趣，請大家積極評論并提出您的觀點(diǎn)。

OpenStack社區(qū)：Toby Ford

這是一篇非常出色的深入挖掘兩者區(qū)別的文章，比如 Pets vs. Cattle的比喻就非常好，另外，我認(rèn)為評價標(biāo)準(zhǔn)應(yīng)該再增加幾個緯度。

在DRS與OS Scheduler對比中，目前，DRS對比OpenStack Scheduler是有優(yōu)勢的，因?yàn)镈RS采用各種關(guān)鍵指標(biāo)去決策部署虛擬機(jī)時的主機(jī)節(jié)點(diǎn)選擇，另外，DRS還會對虛擬機(jī)整個生命周期進(jìn)行監(jiān)控。

但是，DRS是封閉的，這些權(quán)重指標(biāo)都無法配置，舉一個簡單的例子：如果在晚上很短的時間內(nèi)，CPU的負(fù)載突然增高，這并不意味著我們需要將虛擬機(jī)遷移到另一臺宿主機(jī)之上，或者如果管理員知道在未來一段時間將會虛擬機(jī)將會發(fā)生一些問題而又不想DRS介入其中，這就變得非常難辦了。相反，OpenStack Scheduler則會逐步與DRS拉開距離，特別是當(dāng)其變得更加可擴(kuò)展。

針對為什么說vMotion采用動態(tài)/全生命周期地去維護(hù)虛擬機(jī)很重要：vMotion/DRS/HA都是處理傳統(tǒng)型虛擬機(jī)的必備功能，顯而易見，這跟虛擬機(jī)的類別其實(shí)沒什么關(guān)系，而我要說的是vMotion/DRS 對于資源的較大化利用還是很重要的。

在我們的實(shí)際環(huán)境中，我就因?yàn)樾枰远x調(diào)度規(guī)則而不得不關(guān)閉了DRS，雖然我們自定義了調(diào)度規(guī)則，但是VMware的升級使這種自定義的調(diào)度器變得非常難以維護(hù)。

我想要說的是，OpenStack不單單面向cattle模式的應(yīng)用場景，對于處理pets模式的虛擬機(jī)也會越來越好。