在雲計算生(shēng)态系統中(zhōng)，有兩種類型的用戶需要使用雲計算資(zī)源：傳統型(Traditional IT applications)和在互聯網大(dà)潮下(xià)逐漸崛起雲計算應用型(Cloud-aware applications)。國外(wài)廣爲流傳的一(yī)個比喻是：在傳統服務模式下(xià)，可以想象服務器就是IT的寵物(wù)(Pets)，給他們取名字，精心撫養長大(dà)，當他們生(shēng)病了，你得修複他們;在新形态的應用服務模型中(zhōng)，虛拟機被看做是農場中(zhōng)的公牛(Cattle)，名字通常都是編号，當他們生(shēng)病了，你就殺掉他，用一(yī)頭新牛代替。VMWare和OpenStack的雲計算Vision、功能、特點對比正式這個戰争或者說趨勢的一(yī)個生(shēng)動寫照。未來的應用架構應該像對待農場中(zhōng)的公牛一(yī)樣：VMware的“保養”、保護虛拟機的各種功能比較雲計算型應用模式可能會逐漸變得越來越不那麽重要。本文在國外(wài)廣泛流傳，熱議不斷，中(zhōng)國社區意譯分(fēn)享給大(dà)家，歡迎積極讨論。
本文中(zhōng)内容具體(tǐ)包括以下(xià)幾個部分(fēn)：設計、功能集、客戶用例和價值，每點都以十分(fēn)來評價，最終我(wǒ)們将以總分(fēn)來決定赢家。
第一(yī)回合：設計
VMware軟件套件是自底向上的架構，下(xià)端邊界爲虛拟機管理器。像VMware的vSphere和vCloud director産品都是依賴于免費的ESX(i) 虛拟機管理器， ESX(i)虛拟機管理器爲他們提供了非常優秀的部署架構。本身VMware的軟件套件也是經過全面測試過的，并且都有單一(yī)部署框架。總的來說，VMware的産品由于其架構的健壯性，很多高規格用戶在多數據中(zhōng)心規模的環境中(zhōng)都有使用。換句話(huà)說，VMware的軟件系統是封閉的，并且軟件的發展路線是完全遵循VMware自己的發展目标，用戶或消費者在此方面沒有任何控制權。
OpenStack作爲一(yī)個開(kāi)源系統，沒有任何一(yī)家單獨的公司在控制OpenStack的發展路線。本身OpenStack是年輕的，還不滿三周歲，但是他卻具有巨大(dà)的市場動力，與此同時，很多大(dà)公司都在支持OpenStack發展(詳見：OpenStack支持者)。有了如此多公司的資(zī)源投入，OpenStack的發展是多元化的。然而這也帶來了問題，就是OpenStack部署和架構的實施和維護成本較比VMware有了陡然提高，與此同時，由于相對快速的版本更新速度，技術支持文檔不能跟上産品的腳步。
VMware在設計方面稍占優勢，這源于它優秀的文檔資(zī)料以及便捷易用的部署和管理接口。OpenStack在這個方面也在緊追不舍，并且在硬件和虛拟機管理層其保持了它自身的靈活性，更是提供了多廠商(shāng)支持。
第二回合：功能
VMware vMotion
vMotion是vSphere DRS、DPM和主機維護三大(dà)功能的合集。其中(zhōng)虛拟機動态遷移允許将一(yī)台虛拟機在零關機的情況下(xià)由一(yī)台宿主機遷移到另一(yī)台上，這原本是需要共享存儲的支持的，但在vSphere 5.1中(zhōng)，VMware已經不需要通過共享存儲實現動态遷移了。當一(yī)台虛拟機由一(yī)個宿主機遷移到另一(yī)個上時，虛拟機的内存狀态和數據都要同步遷移過去(qù)。如果是共享存儲的情況，實際上數據是不需要進行遷移的，隻需要變化指向數據存儲的鏈接而已。這在加速了遷移速度的同時也減少了在複制過程中(zhōng)網絡的負載。
OpenStack 動态遷移
KVM動态遷移允許一(yī)個虛拟機由一(yī)個虛拟機管理器遷移到另一(yī)個，說的詳細一(yī)點，你可以來來回回将一(yī)台虛拟機在AMD架構主機與Intel架構主機上進行遷移，但是需要注意的是，64位的虛拟主機隻能被遷移到64位的宿主機上，但是32位的則有32位和64位兩種選擇。在動态遷移過程中(zhōng)，不能再對虛拟機進行操作，但是虛拟機内的用戶還是可以在虛拟機内部繼續進行工(gōng)作的。KVM主要還是依賴于共享存儲，某種程度上，這相對來說是需要一(yī)些資(zī)金投入的。
動态遷移需求：
虛拟機存儲需要放(fàng)在分(fēn)布式文件系統之上，如NFS或在GlusterFSLibvirt必須要開(kāi)啓listen flag每一(yī)個計算節點(虛拟機管理器)都必須在同一(yī)個網絡/子網當中(zhōng)計算節點間的認證必須提前完成配置DFS的挂載節點在每一(yī)個計算節點必須保持一(yī)緻
OpenStack塊存儲遷移
在OpenStack當中(zhōng)，KVM支持塊存儲遷移，這也就是說虛拟機遷移不是必須需要共享存儲的支持的。在塊遷移的場景下(xià)，虛拟機的内存狀态與數據都将被遷移，但是遷移操作也需要消耗兩端的CPU資(zī)源并且操作花費時間較比共享存儲來說要長一(yī)些。在某些用戶場景當中(zhōng)，如果我(wǒ)們比較關注于主機的可維護性，并且不想花費過多經費，那麽應用塊存儲遷移将是好的解決方案。同時，如果在沒有共享存儲的環境中(zhōng)，我(wǒ)們想對計算節點進行内核維護、安全升級，那麽保證虛拟機服務不被打斷，塊存儲遷移也是理想選擇。
用戶場景：
用戶沒有分(fēn)布式文件系統，可能是由于企業的資(zī)金支持或者網絡延遲，但是卻想實現虛拟機的高可用性。
VMware DRS 和 DPM
基于vMotion，DRS可以動态監控虛機機及宿主機的當前使用狀況，并且爲宿主機的負載均衡提供支持。
用戶場景：
部署階段：可以對監控虛拟機執行自定義自動化腳本監控階段：DRS可以在ESX(i)主機上分(fēn)布式部署虛拟機，并且持續監控活躍虛拟機和可用資(zī)源，以動态遷移虛拟機來實現資(zī)源利用率最大(dà)化
基于vMotion， DPM将虛拟機從低負載宿主機遷移掉，并且關閉以達到減少電能損耗。當負載增長，DPM将宿主機重啓，并且部署新的虛拟機以滿足負載需要。
OpenStack 調度器
OpenStack包含了對于compute和volume的調度器，通過一(yī)系列的管理員(yuán)設定的規則參數和過濾器，OpenStack調度器将虛拟機部署到合适的宿主機上。在過濾器方面，調度器是非常靈活的，用戶可以自己完成JSON格式的過濾器，并且過濾器還包含很多預定義的過濾器。雖然OpenStack調度器非常靈活，但是還是不能完全替代DRS，原因如下(xià)：
VMware High Availability(高可用)
在vSphere中(zhōng)，虛拟機級别的高可用性是允許在虛拟機或者ESX(i)主機出錯時，在不同宿主機部署相同的虛拟機。這裏不要和容錯(FT)機制混淆，高可用的意義在于當有一(yī)些東西出錯了，可以在一(yī)定時間内自我(wǒ)修複。高可用是在硬件出問題的時候保證虛拟機的正常個工(gōng)作，如果真的出錯了，那麽隻能在不同的ESX(i)主機上啓動虛拟機，這也可能造成服務的中(zhōng)斷。
OpenStack High Availability(高可用)
目前并沒有官方聲明OpenStack支持虛拟機級别的高可用性，這個特性在Folsom版本被提出，但是後續又(yòu)被放(fàng)棄了。目前OpenStack有一(yī)個孵化項目Evacuate, 其作用是爲OpenStack提供虛拟機級别高可用支持。
VMware Fault Tolerance(容錯)
VMware容錯機制是通過監控虛拟機的狀态和所有變化，将這些變化同步到第二台備份ESX(i)服務器之上。容錯的概念在于無論是主還是從宿主機出現問題，隻要一(yī)方能正常工(gōng)作，那麽宿主機上的虛拟機都保持正常工(gōng)作。抛開(kāi)營銷中(zhōng)的噱頭，這種機制還是無法解決虛拟機中(zhōng)的應用程序崩潰，因爲一(yī)旦一(yī)方崩潰，則這個變化也會同步到從節點，當你停止虛拟機的服務去(qù)修複它，從節點也會同樣停止服務。所以這個機制隻能保證單點失效的問題不再出現，而真正的應用層面的容錯則需要MSCS或者WCS來解決。考慮到其他方面如最高資(zī)源使用、内存、硬盤、CPU、帶寬的容錯，這些方面都有局限性，并且是使用量相對比較小(xiǎo)的功能。如實現這些則這需要雙倍的内存，由于内存不能跨主機複制，并且還需要CPU lockstepping去(qù)同步每一(yī)個CPU指令。這将導緻隻有單獨一(yī)個虛拟CPU被容錯機制所監控。
OpenStack Fault Tolerance(容錯)
在OpenStack中(zhōng)沒有針對于容錯的功能，并且截至目前也沒有計劃去(qù)完成這些功能。未來，KVM也不再支持鏡像操作功能。
我(wǒ)們可以看到，在功能的支持方面和功能細節，OpenStack與VMware還是有差距的，但是這對OpenStack還是有優勢的，因爲較比VMware的昂貴價格，OpenStack免費、開(kāi)放(fàng)的優勢顯現出來。VMware高投入帶來的功能，OpenStack大(dà)部分(fēn)可以免費提供給客戶。
從VMware在功能方面的領先可以看出，VMware還在繼續研發除了vMotion、高可用、容錯以外(wài)其他的新功能去(qù)保護他們的虛拟機;OpenStack一(yī)方面跟随VMware的腳步，另一(yī)方面他們投入精力在支持更多硬件廠商(shāng)解決方案的上面。
第三回合：用例
在我(wǒ)們評價上述功能的價值之前，首先我(wǒ)們需要考慮用例問題。在雲計算生(shēng)态系統中(zhōng)，有兩種類型的用戶需要使用雲計算資(zī)源：傳統型和雲計算應用型。雲計算應用型用戶将自己處理HA和DR策略，而傳統型用戶将依賴于雲平台提供的HA和DR。看下(xià)面出自VMware雲計算架構文章的圖表。
雲計算型應用共同特點
分(fēn)布式無狀态、軟狀态失效切換在應用端擴展性在應用端
傳統型應用共同特點
客戶端-服務器架構難以橫向擴展失效切換在服務端擴展性在服務端
傳統型應用将需要如FT、VM級别的高可用性、自動病毒掃描等功能，而雲計算型應用則不需要，當一(yī)台虛拟機出問題後，新的一(yī)台虛拟機将替代它。
Pet vs. Cattle
換一(yī)種思路去(qù)想這件事，那就可以從微軟 William Baker的出名文章 Pets vs. Cattle 的比喻看出OpenStack和Vmware的關系。
比喻是這樣說的：在傳統服務模式下(xià)，你可以想象你的主機就是你的寵物(wù)，你給他們取名字，比如dusty、cern等等，他們被精心撫養長大(dà)。當他們生(shēng)病了，你得修複他們。在雲計算型應用服務模型中(zhōng)，虛拟機被看做是農場中(zhōng)的公牛，他們的名字通常都是編号，牛和牛長得也差不多，當他們生(shēng)病了，你就殺掉他，用一(yī)頭新牛代替。
未來的雲應用架構應該像對待農場中(zhōng)的公牛一(yī)樣。VMware的保養、保護虛拟機的各種功能較比雲計算型應用模式變得越來越不那麽重要了。
在這輪比賽中(zhōng)，OpenStack追了上來，雖然VMware有很多OpenStack所不具有的功能，但是針對雲計算型應用，這些功能變得不那麽重要。未來，你很可能爲那些你用不上的、不可控的VMware添加功能買單。
第四回合：價值
現在是最後一(yī)回合，我(wǒ)們将決定比賽結果。雖然，OpenStack還是VMware更有價值，這個問題并沒有很清晰的答案，并且答案也取決于部署規模。雖然OpenStack是免費使用的，但是他需要有大(dà)量工(gōng)程資(zī)源和領域專家才行，并且他還需要很多架構和搭建方面的工(gōng)作，因爲它支持很多部署場景，并且安裝過程都不盡相同。VMware則需要花費一(yī)些經費購買權限，并且相對來說更加容易安裝和運行，另外(wài)較比命令行，VMware則學習成本更低一(yī)些。
總得來說，OpenStack入門門檻較高，但是随着項目規模的擴大(dà)，你将從中(zhōng)受益，因爲不必支付高額的版權費用。VMware雖然在小(xiǎo)規模安裝時相對容易，但是随着規模擴大(dà)，事情就變了。這就是說，随着雲應用大(dà)規模化，大(dà)家也更加熟悉OpenStack，那麽OpenStack的入門門檻就低得多了。
在雲計算領域，OpenStack和VMware這兩位重量級玩家，VMware在功能和架構上稍微領先，但是OpenStack作爲一(yī)隻弱旅，卻在第三回合迎頭趕上并在最後一(yī)回合給予對方毀滅性打擊。