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

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

第一回合：設計

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

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

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

第二回合：功能

VMware vMotion

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

OpenStack 動態遷移

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

動態遷移需求：

• 虛擬機存儲需要放在分布式文件系統之上，如NFS或在GlusterFS
• Libvirt必須要開啟listen flag
• 每一個計算節點(虛擬機管理器)都必須在同一個網絡/子網當中
• 計算節點間的認證必須提前完成配置
• DFS的掛載節點在每一個計算節點必須保持一致

OpenStack塊存儲遷移

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

用戶場景：

用戶沒有分布式文件系統，可能是由于企業的資金支持或者網絡延遲，但是卻想實現虛擬機的高可用性。

VMware DRS 和 DPM

基于vMotion，DRS可以動態監控虛機機及宿主機的當前使用狀況，并且為宿主機的負載均衡提供支持。

用戶場景：

• 部署階段：可以對監控虛擬機執行自定義自動化腳本
• 監控階段：DRS可以在ESX(i)主機上分布式部署虛擬機，并且持續監控活躍虛擬機和可用資源，以動態遷移虛擬機來實現資源利用率最大化

基于vMotion， DPM將虛擬機從低負載宿主機遷移掉，并且關閉以達到減少電能損耗。當負載增長，DPM將宿主機重啟，并且部署新的虛擬機以滿足負載需要。

OpenStack 調度器

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

調度器用于選擇哪個宿主機進行虛擬機部署的靜態參考數據來源于Nova的數據庫。換句話說，就是發現宿主機已經有了4臺虛擬機了，那么我們需要選擇一個新的宿主機去部署下一臺虛擬機。

調度器只能在虛擬機部署階段影響部署的位置，一旦部署完成，虛擬機運行后則無法挪動虛擬機了。如果需要基于動態數據進行調度，那么調度器需要與外部監控解決方案如Nagios合作。總而言之，目前OpenStack調度器將只會對部署虛擬機環節有影響。

VMware High Availability(高可用)

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

OpenStack High Availability(高可用)

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

VMware Fault Tolerance(容錯)

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

OpenStack Fault Tolerance(容錯)

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

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

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

本文轉載自