在雲計算生(shēng)态系統中，有兩種類型的用(yòng)戶需要(yào / yāo)使用(yòng)雲計算資源：傳統型(Traditional IT applications)和在互聯網大潮下(xià)逐漸崛起雲計算應用(yòng)型(Cloud-aware applications)。國外廣爲流傳的一個比喻是：在傳統服務模式下(xià)，可(kě)以想象服務器就(jiù)是IT的寵物(Pets)，給他們取名字，精心撫養長大，當他們生(shēng)病了，你(nǐ)得(dé / de / děi)修複他們;在新形态的應用(yòng)服務模型中，虛拟機被看做是農場中的公牛(Cattle)，名字通常都是編号，當他們生(shēng)病了，你(nǐ)就(jiù)殺掉他，用(yòng)一頭新牛代替。VMWare和OpenStack的雲計算Vision、功能(néng)、特點對(duì)比正式這個戰争或者說趨勢的一個生(shēng)動寫照。未來的應用(yòng)架構應該像對(duì)待農場中的公牛一樣：VMware的“保養”、保護虛拟機的各種功能(néng)比較雲計算型應用(yòng)模式可(kě)能(néng)會(huì)逐漸變得(dé / de / děi)越來越不那(nà)麽重要(yào / yāo)。本文在國外廣泛流傳，熱議不斷，中國社區意譯分享給大家(jiā)，歡迎積極讨論。

      本文中内容具體包括以下(xià)幾個部分：設計、功能(néng)集、客戶用(yòng)例和價值，每點都以十(shí)分來評價，最終我們将以總分來決定赢家(jiā)。

      第一回合：設計

      VMware軟件套件是自(zì)底向上的架構，下(xià)端邊界爲虛拟機管理器。像VMware的vSphere和vCloud director産品都是依賴于(yú)免費的ESX(i) 虛拟機管理器， ESX(i)虛拟機管理器爲他們提供了非常優秀的部署架構。本身VMware的軟件套件也是經過(guò)全面測試過(guò)的，并且都有單一部署框架。總的來說，VMware的産品由于(yú)其(qí)架構的健壯性，很多高規格用(yòng)戶在多數據中心規模的環境中都有使用(yòng)。換句話說，VMware的軟件系統是封閉的，并且軟件的發(fā／fà)展路線是完全遵循VMware自(zì)己的發(fā／fà)展目标，用(yòng)戶或消費者在此方面沒有任何控制權。

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

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

      第二回合：功能(néng)

      VMware vMotion

      vMotion是vSphere DRS、DPM和主機維護三大功能(néng)的合集。其(qí)中虛拟機動态遷移允許将一台虛拟機在零關機的情況下(xià)由一台宿主機遷移到另一台上，這原本是需要(yào / yāo)共享存儲的支持的，但在vSphere 5.1中，VMware已經不需要(yào / yāo)通過(guò)共享存儲實現動态遷移了。當一台虛拟機由一個宿主機遷移到另一個上時，虛拟機的内存狀态和數據都要(yào / yāo)同步遷移過(guò)去(qù)。如(rú)果是共享存儲的情況，實際上數據是不需要(yào / yāo)進行(háng / xíng)遷移的，隻需要(yào / yāo)變化指向數據存儲的鏈接而(ér)已。這在加速了遷移速度的同時也減少了在複制過(guò)程中網絡的負載。

      OpenStack 動态遷移

      KVM動态遷移允許一個虛拟機由一個虛拟機管理器遷移到另一個，說的詳細一點，你(nǐ)可(kě)以來來回回将一台虛拟機在AMD架構主機與Intel架構主機上進行(háng / xíng)遷移，但是需要(yào / yāo)注意的是，64位的虛拟主機隻能(néng)被遷移到64位的宿主機上，但是32位的則有32位和64位兩種選擇。在動态遷移過(guò)程中，不能(néng)再對(duì)虛拟機進行(háng / xíng)操作，但是虛拟機内的用(yòng)戶還是可(kě)以在虛拟機内部繼續進行(háng / xíng)工作的。KVM主要(yào / yāo)還是依賴于(yú)共享存儲，某種程度上，這相對(duì)來說是需要(yào / yāo)一些資金投入的。

      動态遷移需求：

      虛拟機存儲需要(yào / yāo)放在分布式文件系統之上，如(rú)NFS或在GlusterFSLibvirt必須要(yào / yāo)開啓listen flag每一個計算節點(虛拟機管理器)都必須在同一個網絡/子網當中計算節點間的認證必須提前完成配置DFS的挂載節點在每一個計算節點必須保持一緻

      OpenStack塊存儲遷移

      在OpenStack當中，KVM支持塊存儲遷移，這也就(jiù)是說虛拟機遷移不是必須需要(yào / yāo)共享存儲的支持的。在塊遷移的場景下(xià)，虛拟機的内存狀态與數據都将被遷移，但是遷移操作也需要(yào / yāo)消耗兩端的CPU資源并且操作花費時間較比共享存儲來說要(yào / yāo)長一些。在某些用(yòng)戶場景當中，如(rú)果我們比較關注于(yú)主機的可(kě)維護性，并且不想花費過(guò)多經費，那(nà)麽應用(yòng)塊存儲遷移将是好的解決方案。同時，如(rú)果在沒有共享存儲的環境中，我們想對(duì)計算節點進行(háng / xíng)内核維護、安全升級，那(nà)麽保證虛拟機服務不被打斷，塊存儲遷移也是理想選擇。

      用(yòng)戶場景：

      用(yòng)戶沒有分布式文件系統，可(kě)能(néng)是由于(yú)企業的資金支持或者網絡延遲，但是卻想實現虛拟機的高可(kě)用(yòng)性。

      VMware DRS 和 DPM

      基于(yú)vMotion，DRS可(kě)以動态監控虛機機及宿主機的當前使用(yòng)狀況，并且爲宿主機的負載均衡提供支持。

      用(yòng)戶場景：

      部署階段：可(kě)以對(duì)監控虛拟機執行(háng / xíng)自(zì)定義自(zì)動化腳本監控階段：DRS可(kě)以在ESX(i)主機上分布式部署虛拟機，并且持續監控活躍虛拟機和可(kě)用(yòng)資源，以動态遷移虛拟機來實現資源利用(yòng)率最大化

      基于(yú)vMotion， DPM将虛拟機從低負載宿主機遷移掉，并且關閉以達到減少電能(néng)損耗。當負載增長，DPM将宿主機重啓，并且部署新的虛拟機以滿足負載需要(yào / yāo)。

      OpenStack 調度器

      OpenStack包含了對(duì)于(yú)compute和volume的調度器，通過(guò)一系列的管理員設定的規則參數和過(guò)濾器，OpenStack調度器将虛拟機部署到合适的宿主機上。在過(guò)濾器方面，調度器是非常靈活的，用(yòng)戶可(kě)以自(zì)己完成JSON格式的過(guò)濾器，并且過(guò)濾器還包含很多預定義的過(guò)濾器。雖然OpenStack調度器非常靈活，但是還是不能(néng)完全替代DRS，原因如(rú)下(xià)：

      VMware High Availability(高可(kě)用(yòng))

      在vSphere中，虛拟機級别的高可(kě)用(yòng)性是允許在虛拟機或者ESX(i)主機出錯時，在不同宿主機部署相同的虛拟機。這裏(lǐ)不要(yào / yāo)和容錯(FT)機制混淆，高可(kě)用(yòng)的意義在于(yú)當有一些東西出錯了，可(kě)以在一定時間内自(zì)我修複。高可(kě)用(yòng)是在硬件出問題的時候保證虛拟機的正常個工作，如(rú)果真的出錯了，那(nà)麽隻能(néng)在不同的ESX(i)主機上啓動虛拟機，這也可(kě)能(néng)造成服務的中斷。

      OpenStack High Availability(高可(kě)用(yòng))

目前并沒有官方聲明OpenStack支持虛拟機級别的高可(kě)用(yòng)性，這個特性在Folsom版本被提出，但是後(hòu)續又被放棄了。目前OpenStack有一個孵化項目Evacuate, 其(qí)作用(yòng)是爲OpenStack提供虛拟機級别高可(kě)用(yòng)支持。

      VMware Fault Tolerance(容錯)

      VMware容錯機制是通過(guò)監控虛拟機的狀态和所(suǒ)有變化，将這些變化同步到第二台備份ESX(i)服務器之上。容錯的概念在于(yú)無論是主還是從宿主機出現問題，隻要(yào / yāo)一方能(néng)正常工作，那(nà)麽宿主機上的虛拟機都保持正常工作。抛開營銷中的噱頭，這種機制還是無法解決虛拟機中的應用(yòng)程序崩潰，因爲一旦一方崩潰，則這個變化也會(huì)同步到從節點，當你(nǐ)停止虛拟機的服務去(qù)修複它，從節點也會(huì)同樣停止服務。所(suǒ)以這個機制隻能(néng)保證單點失效的問題不再出現，而(ér)真正的應用(yòng)層面的容錯則需要(yào / yāo)MSCS或者WCS來解決。考慮到其(qí)他方面如(rú)最高資源使用(yòng)、内存、硬盤、CPU、帶寬的容錯，這些方面都有局限性，并且是使用(yòng)量相對(duì)比較小的功能(néng)。如(rú)實現這些則這需要(yào / yāo)雙倍的内存，由于(yú)内存不能(néng)跨主機複制，并且還需要(yào / yāo)CPU lockstepping去(qù)同步每一個CPU指令。這将導緻隻有單獨一個虛拟CPU被容錯機制所(suǒ)監控。

      OpenStack Fault Tolerance(容錯)

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

      我們可(kě)以看到，在功能(néng)的支持方面和功能(néng)細節，OpenStack與VMware還是有差距的，但是這對(duì)OpenStack還是有優勢的，因爲較比VMware的昂貴價格，OpenStack免費、開放的優勢顯現出來。VMware高投入帶來的功能(néng)，OpenStack大部分可(kě)以免費提供給客戶。

      從VMware在功能(néng)方面的領先可(kě)以看出，VMware還在繼續研發(fā／fà)除了vMotion、高可(kě)用(yòng)、容錯以外其(qí)他的新功能(néng)去(qù)保護他們的虛拟機;OpenStack一方面跟随VMware的腳步，另一方面他們投入精力在支持更多硬件廠商解決方案的上面。

      第三回合：用(yòng)例

在我們評價上述功能(néng)的價值之前，首先我們需要(yào / yāo)考慮用(yòng)例問題。在雲計算生(shēng)态系統中，有兩種類型的用(yòng)戶需要(yào / yāo)使用(yòng)雲計算資源：傳統型和雲計算應用(yòng)型。雲計算應用(yòng)型用(yòng)戶将自(zì)己處理HA和DR策略，而(ér)傳統型用(yòng)戶将依賴于(yú)雲平台提供的HA和DR。看下(xià)面出自(zì)VMware雲計算架構文章的圖表。

      雲計算型應用(yòng)共同特點

      分布式無狀态、軟狀态失效切換在應用(yòng)端擴展性在應用(yòng)端

      傳統型應用(yòng)共同特點

      客戶端-服務器架構難以橫向擴展失效切換在服務端擴展性在服務端

      傳統型應用(yòng)将需要(yào / yāo)如(rú)FT、VM級别的高可(kě)用(yòng)性、自(zì)動病毒掃描等功能(néng)，而(ér)雲計算型應用(yòng)則不需要(yào / yāo)，當一台虛拟機出問題後(hòu)，新的一台虛拟機将替代它。

Pet vs. Cattle

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

      比喻是這樣說的：在傳統服務模式下(xià)，你(nǐ)可(kě)以想象你(nǐ)的主機就(jiù)是你(nǐ)的寵物，你(nǐ)給他們取名字，比如(rú)dusty、cern等等，他們被精心撫養長大。當他們生(shēng)病了，你(nǐ)得(dé / de / děi)修複他們。在雲計算型應用(yòng)服務模型中，虛拟機被看做是農場中的公牛，他們的名字通常都是編号，牛和牛長得(dé / de / děi)也差不多，當他們生(shēng)病了，你(nǐ)就(jiù)殺掉他，用(yòng)一頭新牛代替。

      未來的雲應用(yòng)架構應該像對(duì)待農場中的公牛一樣。VMware的保養、保護虛拟機的各種功能(néng)較比雲計算型應用(yòng)模式變得(dé / de / děi)越來越不那(nà)麽重要(yào / yāo)了。

      在這輪比賽中，OpenStack追了上來，雖然VMware有很多OpenStack所(suǒ)不具有的功能(néng)，但是針對(duì)雲計算型應用(yòng)，這些功能(néng)變得(dé / de / děi)不那(nà)麽重要(yào / yāo)。未來，你(nǐ)很可(kě)能(néng)爲那(nà)些你(nǐ)用(yòng)不上的、不可(kě)控的VMware添加功能(néng)買單。

      第四回合：價值

      現在是最後(hòu)一回合，我們将決定比賽結果。雖然，OpenStack還是VMware更有價值，這個問題并沒有很清晰的答案，并且答案也取決于(yú)部署規模。雖然OpenStack是免費使用(yòng)的，但是他需要(yào / yāo)有大量工程資源和領域專家(jiā)才行(háng / xíng)，并且他還需要(yào / yāo)很多架構和搭建方面的工作，因爲它支持很多部署場景，并且安裝過(guò)程都不盡相同。VMware則需要(yào / yāo)花費一些經費購買權限，并且相對(duì)來說更加容易安裝和運行(háng / xíng)，另外較比命令行(háng / xíng)，VMware則學習成本更低一些。

      總得(dé / de / děi)來說，OpenStack入門門檻較高，但是随着(zhe／zhuó／zhāo／zháo)項目規模的擴大，你(nǐ)将從中受益，因爲不必支付高額的版權費用(yòng)。VMware雖然在小規模安裝時相對(duì)容易，但是随着(zhe／zhuó／zhāo／zháo)規模擴大，事(shì)情就(jiù)變了。這就(jiù)是說，随着(zhe／zhuó／zhāo／zháo)雲應用(yòng)大規模化，大家(jiā)也更加熟悉OpenStack，那(nà)麽OpenStack的入門門檻就(jiù)低得(dé / de / děi)多了。

      在雲計算領域，OpenStack和VMware這兩位重量級玩家(jiā)，VMware在功能(néng)和架構上稍微領先，但是OpenStack作爲一隻弱旅，卻在第三回合迎頭趕上并在最後(hòu)一回合給予對(duì)方毀滅性打擊。