編者按：通過多年的發展，VMWare在虛擬化市場處于領軍地位，很多企業部署了VMWare虛擬化方案，隨著OpenStack云計算平臺的快速崛起，很多企業都面臨一個問題：能否、以及如何整合VMWare和OpenStack來最佳化已有的投資和對接未來的趨勢？來自RackSpace的Kenneth Hui從不同角度分享了他的思考，而且給出了VMware vSphere與OpenStack整合的推薦方案。
在過去12個月中，“OpenStack 目前已經在風口浪尖之上” 這句話我們已經從運營商或分析師口中聽到了?可事實上，很多公司仍在評估OpenStack并且試圖確定如何將OpenStack與公司的IT策略整合。這也符合云計算等前沿技術的發展規律，個人的觀點是：OpenStack正在經歷由技術創新、實踐向主流應用普及的發展過程。
我也和很多在早期就開始評估或在小型項目中應用OpenStack的公司談過，他們的大多數如今還是VMware的忠實客戶，并且運行的也都是傳統應用，他們非常明白OpenStack不可忽視，但是他們很難真正理解OpenStack的真正價值，也很難理解它是如何影響他們的vSphere環境的。我們談話中最常出現的問題如下：
OpenStack作為一個開源的虛擬機管理器，它能否替代我當前的ESXi 服務器么？在OpenStack和vSphere之間，有沒有一些特色功能的差異？如高可用性、vMotion，分布式資源調度等。我們能否或者應否將OpenStack與vSphere混合使用？有沒有一些原因讓我們同時運行OpenStack和vSphere？
我對于這些問題的答案通常從三個方面來說明問題的答案：
最開始對于我個人來說，當我與客戶談起vSphere和OpenStack時，重點要強調的就是傳統應用架構與云計算架構的設計理念的不同。在這里，我想把重點放在基于虛擬化技術的傳統應用架構上來，如ESX虛擬機管理器和vSphere，他們作為虛擬化技術的突出代表，可以在少數大型服務器之上虛擬化出很多小型服務器。這種工作機制在應用是單一架構時表現得相當不錯，如Oracle或者Microsoft Exchange。今天，每一個這種傳統類型應用都包裹在一個單獨的虛擬機之中，只能通過ESXi虛擬機管理器擴展應用規模。在傳統架構下，高可用的實現可以通過集群應用來實現，比如Oracle的Real Application Clusters；然而這同時也是非常復雜且昂貴的，并且大多數應用不支持集群式部署。大多數VMware用戶則會選擇將應用服務器作為虛擬機運行在vSphere集群之上，依賴于vSphere的高可用性和vMotion來提供基礎架構的恢復和冗余。誠然這些解決辦法都可以實現高可用，但是他們都需要特定的部署架構，如依賴共享存儲等，這也一定程度地給架構的擴展性帶來挑戰。
云計算，較比傳統虛擬化技術而言，更加適合不同類型的應用，如MongoDB和Hadoop。 像OpenStack這樣的云平臺，在最初就被設計成適應分布式應用的架構，應用的組件在OpenStack平臺中跨越了多個物理或虛擬設備。這些類型的應用也被設計成隨著規模的增加，可以通過添加應用實例或者重新平衡應用實例間的負載；另一個云計算平臺背后的設計原則是，鑒于應用的分布式特性，應用彈性控制權是掌握在應用自身手里而不在底層基礎架構平臺手中。OpenStack這種設計常常被VMware領域的同學們所誤解為是它的確定或者不成熟的地方，“缺乏”如vSphere 高可用這種功能被看作是OpenStack還沒有在生產級領域準備好。
但是，這是傳統應用架構與云計算架構的設計理念不同所帶來的誤解。在云上運行的分布式應用（業內稱此類型應用為“原生云應用”）已經降低了應用部署花費和可用性的門檻。通過將應用的彈性化需求轉移，云平臺不再需要共享所有資源的架構如應用共享存儲。這種改變促進了用戶對構建高可擴展性云平臺的需求，不單單是基礎架構層，架構需要設計成包含多層以更加適合下一代大規模應用的部署。
消費模式
一旦客戶了解了以上兩種架構設計原則的不同，我們就可以開始討論不同架構的消費模式問題了。這里也將區分這兩種消費模式的不同。比如：
除了在我們自己的數據中心上運行裸機服務器和虛擬化技術，公司可以應用主機托管產品，如Rackspace的專用vCenter產品或在VMware的vCloud混合云產品。這兩者都是建立在VMware技術基礎之上，為用戶提供虛擬化解決方案。兩者的設計架構都較適用于那些不需要塊數部署的、不依賴虛擬化基礎設施提供彈性和可擴展性的傳統型應用。
相比之下，云計算型架構的消費模式通常開始于公有云的使用，將來向私有云部署上擴展。在這里，我們關注的重點仍是通過常用商用硬件能夠實現快速資源供給、高可擴展、適應下一代應用的云架構。
vSphere與OpenStack整合
到目前為止我們應該很清楚了，VMware vSphere與OpenStack兩者任何一個都無法滿足多種應用類型。Rackspace就有一些用戶，由于他們應用的分布式本質，用戶已經將應用放到基于OpenStack的共有云或私有云之上了。相反，大多數用戶都運營著傳統型應用，這些應用通常運行在裸機或在虛擬化架構之上，并且它們并不那么容易地去遷移到如OpenStack這樣的云架構之上。對于這些用戶，共存、非替代可能是應用OpenStack的正確之道。這條混合之路通常伴隨三種解決方案，如下：
孤島型架構是用戶選擇最多的。通常，這種方案涉及到保存在vSphere上的現有遺留傳統應用和在獨立OpenStack云上建立新應用的抉擇。雖然這是最最無痛的融合OpenStack的解決方案，但是它保持了IT基礎架構的孤島劣勢，并且增加了運維和復雜性，通常我們需要兩個獨立團隊去維護這兩套獨立系統，這也會帶來額外的開銷。
另一種解決方案是基于VMware已完成的工作將vSphere與OpenStack相集成。這種方案類似于孤島型解決方案，傳統型應用仍然運行在vSphere之上，而新的下一代應用則運行在新的虛擬機管理器之上，如KVM或在XEN。在這種情況下，OpenStack成為多虛擬機管理器的控制平臺，它將允許新創建的應用被分配到最適合他們的虛擬機管理平臺之上。這種架構的主要缺點是vSphere與OpenStack整合這種方案非常新，這帶來了很多問題，比如兩平臺的整合邊緣過于粗糙仍需改進，比如平臺的資源如何調度等問題仍然需要解決。
上圖是Rackspace給出的OpenStack與vSphere混合解決方案。在分離管理平臺這方面，這種架構非常像孤島型架構，此外，它還保證不同類型應用可以被部署到合適的虛擬機管理平臺之上。
這里的目標是保持架構的獨立，整合兩個環境的運維團隊使他們可以共同工作來打造一個集成的平臺。這其中的一個關鍵是應用技術，如Rackspace的RackConnect把這些基礎架構連接起來，使每個架構都可以與其他架構協同工作。這里舉一個例子，一個應用運行在基于OpenStack的Rackspace私有云之上，通過RackConnect與運行在vSphere集群上的Oracle數據庫相連接。
京公網安備 11010502049343號