雲數據中心已經成為當下企業數據中心建設的主流，各類公共雲、專有雲和混合雲技術輪番登場。開源的OpenStack作為最火熱的企業雲數據中心雲平臺管理框架，受到了企業的日益關註並且獲得了大量的企業級應用實踐，在產業互聯網發展進程中占據了越來越多的份額。但是在實踐中，由於OpenStack屬於知識密集型的開源產品，在企業部署、使用和運維的過程中，往往會遇到各種挑戰。

技術照進現實，企業級應用尚存難解之結

目前，OpenStack在企業應用過程中主要有五個問題：

1.產品化不足，無法完全滿足企業用戶的需求

OpenStack架構層面的設計傾向於做公共雲服務，因此對於很多企業級的特性未考慮或者考慮不充分，同時開源產品自身產品化能力較低，只提供了基礎功能可用；而商業環境中的各項應用往往要求其擁有更加完善的運維和運營能力。

這就導致很多企業通過簡單的搭積木形式利用OpenStack和各種輔助開源產品在企業中推進部署，使得OpenStack在很多場景下無法為企業提供有效的持續化服務。

另一方面，OpenStack的設計初衷更加偏向解決“ToC”的需求，在實際企業應用中，部門管理、統一認證、權限控制、工單申請審批、操作審計、計量計費、雲上雲下計算資源和存儲資源的管理和監控等強需求功能缺乏足夠支撐。

2.OpenStack原生參考實現無法支持大規模網絡

OpenStack Neutron參考實現的網絡模型，通過在每個計算節點和網關節點上利用namespace來進行3層轉發和DVR，在大規模集群時，命名空間會占用大量系統資源，同時命名空間的TCP/IP協議棧轉發性能比流表效率低。此外在參考實現中，使用了大量的Agent（例如：neutron-openvswitch-agent ,dhcp-agent，l3agent），當集群規模很大時，大量的Agent參與的RPC會成為瓶頸，並且大量的Agent運維也成為管理瓶頸。

3.OpenStack對雲平臺運維人員要求較高，專業人才難尋

OpenStack應用日益廣泛，但是初始交付OpenStack雲平臺後，後期的運維通常需要一個專門的OpenStack團隊來維護，需要計算、存儲、網絡、硬件和軟件等多個方面的專家來共同合作，才能保證OpenStack雲平臺的後續正常運轉。而另一方面我們也能看到，目前OpenStack的人才可謂一將難求，相關人才的招聘和培養均需要花費大量的時間和資源，這樣大部分企業用戶很難自行培養組建出一支高水準、能力強的運維團隊。

4.OpenStack中雲化數據庫商業化不足

企業業務中對關系型數據庫的需求是不可或缺的，隨著數據中心的雲化，雲化的多租戶的數據庫也成為必然，社區的數據庫功能目前其成熟度和可運維程度距離實際的商用需求和使用還有一定的距離。

5.版本升級問題

諸如企業內OpenStack版本升級“困難”等非技術問題也亟待解決，OpenStack社區每半年會出一個新的版本，但是企業對業務穩定的要求遠高於對版本的追求，每半年升級一次底層系統所帶來的業務中斷等問題，讓企業更傾向於選擇暫不升級。但當企業兩年後甚至更長時候後升級平臺， OpenStack已經更新了多個版本，容易造成無法升級的局面。

多角度出發，推動OpenStack技術與產品演進

OpenStack本身來說僅僅提供了基礎的計算、存儲和網絡能力，但是在實際交付中，單純的IAAS資源提供無法滿足用戶的業務價值需求，它需要做大量的周邊工作，例如虛擬機/容器和數據的安全、虛擬機/容器和數據的災備、數據的同步、與大數據系統的交互、與PaaS平臺的配合，應用的彈性，VM/容器的自動彈性伸縮、提供成熟的雲化關系型數據庫、傳統數據庫的使用，以及和不能雲化的資源互訪等等，每一個需求都意味著大量的工作和知識領域的擴充，對提供雲服務的廠商提出了更高的技術要求和架構設計要求。

在產品化和商業化方面，例如如何快速進行大規模部署，如何在大規模集群下保證管控節點、計算節點和網絡節點的高性能和高可靠性，如何在發生各種故障時系統自動恢復和修復，如何實現OpenStack雲數據中心雲上和雲下資源的監控、審計、告警、自動化或半自動化運維，如何進行OpenStack雲數據中心的平滑擴容等等，對於大量雲計算技術力量相對薄弱的企業來說，使用成熟的產品和服務，遠比獨立推動OpenStack的建設和部署更為有效。想把OpenStack用好、用到位，則必須通過相關廠家將其進行產品化開發，企業才能真正方便經濟的使用起來。

以筆者所在的數夢工場研發與產品團隊為例，團隊成員大多擁有多年同客戶共同探索數據中心核心場景需求和相關產品技術研發的經驗，近年來針對OpenStack的企業級應用和產品化也進行了大量技術研究和深入開發，已可以為用戶提供完整的計算、存儲（塊存儲和對象存儲）、網絡（SDN）、雲化關系型數據庫、PaaS和災備等服務，同時核心成員也積極參與到了OpenStack社區技術研發當中，最大程度貢獻了自己的力量。

數夢工場OpenStack產品架構一覽

1.深入參與社區OpenStack SDN技術研發

SDN技術框架

優化的網關架構

前文提到的業內解決Neutron問題的主要辦法是使用SDN來進行虛擬網絡和物理網絡的管理，並通過OpenFlow流表形式指導轉發，減少或不再使用各種Agent。但是目前常見SDN設計均采用首包上送控制集群進行處理，在大規模集群場景下，大量的首包上送會造成對控制集群的大流量沖擊，同時控制集群的GC問題也會造成集群的不穩定，並且控制集群采用OpenFlow遠程下發流表到各個計算節點和網絡節點，又占用了大量的帶內/帶外帶寬，所以在實際大規模集群中會遇到很多問題。

數夢工場SDN團隊開發和實現了分層SDN控制器，有效的避免了上面常見SDN方案遇到的問題，有效的支持了大規模企業雲數據中心的建設。它完全使用X86服務器作為雲數據中心網絡設備，傳統交換機僅僅作為純2層和3層轉發，構建了極簡的雲數據中心，各種雲網絡服務可以快速實現和更新，網絡服務更靈活。並且根據實際交付經驗，細化了網關角色，更加適應企業級大規模數據中心網絡需求。SDN團隊在networking-ovn項目有一個核心Core成員，SDN團隊成員為OVS、OVN、Networking-ovn貢獻了大量的代碼和修復了多個問題。

2.可以跨越OpenStack和阿裏公共雲的混合雲彈性伸縮服務

隨著企業互聯網化的深入，企業的雲上業務大並發突發訪問成為常態，但是基於企業專有雲成本等考慮，不可能按照峰值配置資源，而公共雲就成為臨時彈性資源的不二選擇。

數夢工場團隊基於Senlin項目開發了針對虛擬機和容器的跨雲彈性伸縮能力。在大並發業務訪問發生時，根據閾值優先在本地OpenStack雲內彈性分配虛擬機或容器；當本地計算資源不足時，自動在阿裏公共雲進行彈性分配，滿足企業突發流量的業務需求。

混合雲彈性伸縮

3.OpenStack容器化，支持一鍵部署

OpenStack各個組件是一個非常好的微服務架構設計，各個服務間通過RestfulAPI交付，只要API兼容，各個組件間理論上可以獨立升級。並且OpenStack各個組件運行基本上是無狀態應用，配置和運行數據通過數據庫存儲，所以它進行Docker化是非常合適的。

目前數夢工場OpenStack組件全部Docker化，通過K8S進行管理，同時支持一鍵式白屏化大集群部署。

OpenStack容器化

OpenStack一鍵式自動部署

有人說技術的發展就是在翻越一個又一個山峰，OpenStack相比傳統IT技術來說，在企業級應用中可以說才剛剛起步，仍有大量問題亟待找到更好的解決方案，也有大量的課題需要廣大社區同仁和研發夥伴通過不斷地“開腦洞”，來推動創新實踐。比如是否能夠通過在框架中增加調用流程鏈路跟蹤能力來降低運維難度，或是將微服務的理念移植到產品當中，這些也許都會變成OpenStack在企業級應用乃至產業雲應用的新引爆點。

【作者簡介】

葛建壯，2005年開始從事數據通信行業，擁有多年網絡設計和開發經驗；作為架構師完整參與設計和交付了多款業內領先的SDN產品和NFV產品。2013年開始OpenStack相關研究，並持續關註和實踐。2015年加盟數夢工場，目前擔任數夢工場混合雲產品線首席架構師，負責數夢工場混合雲產品線的產品規劃和設計工作。

技術照進現實，OpenStack企業級應用的五大難解之結