云數(shù)據(jù)中心已經(jīng)成為當下企業(yè)數(shù)據(jù)中心建設(shè)的主流，各類公共云、專有云和混合云技術(shù)輪番登場。
開源的 OpenStack 作為最火熱的企業(yè)云數(shù)據(jù)中心云平臺管理框架，受到了企業(yè)的日益關(guān)注并且獲得了大量的企業(yè)級應(yīng)用實踐，在產(chǎn)業(yè)互聯(lián)網(wǎng)發(fā)展進程中占據(jù)了越來越多的份額。
但是在實踐中，由于 OpenStack 屬于知識密集型的開源產(chǎn)品，在企業(yè)部署、使用和運維的過程中，往往會遇到各種挑戰(zhàn)。
技術(shù)照進現(xiàn)實，企業(yè)級應(yīng)用尚存難解之結(jié)
目前，OpenStack 在企業(yè)應(yīng)用過程中主要有五個問題：
產(chǎn)品化不足，無法完全滿足企業(yè)用戶的需求
OpenStack 架構(gòu)層面的設(shè)計傾向于做公共云服務(wù)，因此對于很多企業(yè)級的特性未考慮或者考慮不充分，同時開源產(chǎn)品自身產(chǎn)品化能力較低，只提供了基礎(chǔ)功能可用。而商業(yè)環(huán)境中的各項應(yīng)用往往要求其擁有更加完善的運維和運營能力。
這就導(dǎo)致很多企業(yè)通過簡單的搭積木形式利用 OpenStack 和各種輔助開源產(chǎn)品在企業(yè)中推進部署，使得 OpenStack 在很多場景下無法為企業(yè)提供有效的持續(xù)化服務(wù)。
另一方面，OpenStack 的設(shè)計初衷更加偏向解決“ToC”的需求，在實際企業(yè)應(yīng)用中，部門管理、統(tǒng)一認證、權(quán)限控制、工單申請審批、操作審計、計量計費、云上云下計算資源和存儲資源的管理和監(jiān)控等強需求功能缺乏足夠支撐。
OpenStack 原生參考實現(xiàn)無法支持大規(guī)模網(wǎng)絡(luò)
OpenStack Neutron 參考實現(xiàn)的網(wǎng)絡(luò)模型，通過在每個計算節(jié)點和網(wǎng)關(guān)節(jié)點上利用 namespace 來進行 3 層轉(zhuǎn)發(fā)和 DVR，在大規(guī)模集群時，命名空間會占用大量系統(tǒng)資源，同時命名空間的 TCP / IP 協(xié)議棧轉(zhuǎn)發(fā)性能比流表效率低。
此外在參考實現(xiàn)中，使用了大量的 Agent（例如：neutron-openvswitch-agent，dhcp-agent，l3agent），當集群規(guī)模很大時，大量的 Agent 參與的 RPC 會成為瓶頸，并且大量的 Agent 運維也成為管理瓶頸。
OpenStack 對云平臺運維人員要求較高，專業(yè)人才難尋
OpenStack 應(yīng)用日益廣泛，但是初始交付 OpenStack 云平臺后，后期的運維通常需要一個專門的 OpenStack 團隊來維護，需要計算、存儲、網(wǎng)絡(luò)、硬件和軟件等多個方面的專家來共同合作，才能保證 OpenStack 云平臺的后續(xù)正常運轉(zhuǎn)。
而另一方面我們也能看到，目前 OpenStack 的人才可謂一將難求，相關(guān)人才的招聘和培養(yǎng)均需要花費大量的時間和資源，這樣大部分企業(yè)用戶很難自行培養(yǎng)組建出一支高水準、能力強的運維團隊。
OpenStack 中云化數(shù)據(jù)庫商業(yè)化不足
企業(yè)業(yè)務(wù)中對關(guān)系型數(shù)據(jù)庫的需求是不可或缺的，隨著數(shù)據(jù)中心的云化，云化的多租戶的數(shù)據(jù)庫也成為必然，社區(qū)的數(shù)據(jù)庫功能目前其成熟度和可運維程度距離實際的商用需求和使用還有一定的距離。
版本升級問題
諸如企業(yè)內(nèi) OpenStack 版本升級“困難”等非技術(shù)問題也亟待解決，OpenStack 社區(qū)每半年會出一個新的版本，但是企業(yè)對業(yè)務(wù)穩(wěn)定的要求遠高于對版本的追求，每半年升級一次底層系統(tǒng)所帶來的業(yè)務(wù)中斷等問題，讓企業(yè)更傾向于選擇暫不升級。
但當企業(yè)兩年后甚至更長時候后升級平臺， OpenStack 已經(jīng)更新了多個版本，容易造成無法升級的局面。
多角度出發(fā)，推動 OpenStack 技術(shù)與產(chǎn)品演進
OpenStack 本身來說僅僅提供了基礎(chǔ)的計算、存儲和網(wǎng)絡(luò)能力，但是在實際交付中，單純的 IAAS 資源提供無法滿足用戶的業(yè)務(wù)價值需求，它需要做大量的周邊工作。
例如，虛擬機/容器和數(shù)據(jù)的安全、虛擬機/容器和數(shù)據(jù)的災(zāi)備、數(shù)據(jù)的同步、與大數(shù)據(jù)系統(tǒng)的交互、與 PaaS 平臺的配合，應(yīng)用的彈性，VM/容器的自動彈性伸縮、提供成熟的云化關(guān)系型數(shù)據(jù)庫、傳統(tǒng)數(shù)據(jù)庫的使用，以及和不能云化的資源互訪等等。
每一個需求都意味著大量的工作和知識領(lǐng)域的擴充，對提供云服務(wù)的廠商提出了更高的技術(shù)要求和架構(gòu)設(shè)計要求。
在產(chǎn)品化和商業(yè)化方面，例如如何快速進行大規(guī)模部署，如何在大規(guī)模集群下保證管控節(jié)點、計算節(jié)點和網(wǎng)絡(luò)節(jié)點的高性能和高可靠性，如何在發(fā)生各種故障時系統(tǒng)自動恢復(fù)和修復(fù)，如何實現(xiàn) OpenStack 云數(shù)據(jù)中心云上和云下資源的監(jiān)控、審計、告警、自動化或半自動化運維，如何進行 OpenStack 云數(shù)據(jù)中心的平滑擴容等等。
對于大量云計算技術(shù)力量相對薄弱的企業(yè)來說，使用成熟的產(chǎn)品和服務(wù)，遠比獨立推動 OpenStack 的建設(shè)和部署更為有效，想把 OpenStack 用好、用到位，則必須通過相關(guān)廠家將其進行產(chǎn)品化開發(fā)，企業(yè)才能真正方便經(jīng)濟的使用起來。
以筆者所在的研發(fā)與產(chǎn)品團隊為例，團隊成員大多擁有多年同客戶共同探索數(shù)據(jù)中心核心場景需求和相關(guān)產(chǎn)品技術(shù)研發(fā)的經(jīng)驗。
近年來針對 OpenStack 的企業(yè)級應(yīng)用和產(chǎn)品化也進行了大量技術(shù)研究和深入開發(fā)，已可以為用戶提供完整的計算、存儲（塊存儲和對象存儲）、網(wǎng)絡(luò)（SDN）、云化關(guān)系型數(shù)據(jù)庫、PaaS 和災(zāi)備等服務(wù)。
同時核心成員也積極參與到了 OpenStack 社區(qū)技術(shù)研發(fā)當中，最大程度貢獻了自己的力量。
圖1：數(shù)夢工場 OpenStack 產(chǎn)品架構(gòu)一覽
深入?yún)⑴c社區(qū) OpenStack SDN 技術(shù)研發(fā)
圖2：SDN 技術(shù)框架
圖3：優(yōu)化的網(wǎng)關(guān)架構(gòu)
前文提到的業(yè)內(nèi)解決 Neutron 問題的主要辦法是使用 SDN 來進行虛擬網(wǎng)絡(luò)和物理網(wǎng)絡(luò)的管理，并通過 OpenFlow 流表形式指導(dǎo)轉(zhuǎn)發(fā)，減少或不再使用各種 Agent.
但是目前常見 SDN 設(shè)計均采用首包上送控制集群進行處理，在大規(guī)模集群場景下，大量的首包上送會造成對控制集群的大流量沖擊，同時控制集群的 GC 問題也會造成集群的不穩(wěn)定。
并且控制集群采用 OpenFlow 遠程下發(fā)流表到各個計算節(jié)點和網(wǎng)絡(luò)節(jié)點，又占用了大量的帶內(nèi)/帶外帶寬，所以在實際大規(guī)模集群中會遇到很多問題。
我們 SDN 團隊開發(fā)和實現(xiàn)了分層 SDN 控制器，有效的避免了上面常見 SDN 方案遇到的問題，有效的支持了大規(guī)模企業(yè)云數(shù)據(jù)中心的建設(shè)。
它完全使用 X86 服務(wù)器作為云數(shù)據(jù)中心網(wǎng)絡(luò)設(shè)備，傳統(tǒng)交換機僅僅作為純 2 層和 3 層轉(zhuǎn)發(fā)，構(gòu)建了極簡的云數(shù)據(jù)中心，各種云網(wǎng)絡(luò)服務(wù)可以快速實現(xiàn)和更新，網(wǎng)絡(luò)服務(wù)更靈活。
并且根據(jù)實際交付經(jīng)驗，細化了網(wǎng)關(guān)角色，更加適應(yīng)企業(yè)級大規(guī)模數(shù)據(jù)中心網(wǎng)絡(luò)需求。SDN 團隊在 Networking-ovn 項目有一個核心 Core 成員，SDN 團隊成員為 OVS、OVN、Networking-ovn 貢獻了大量的代碼和修復(fù)了多個問題。
可以跨越OpenStack和阿里公共云的混合云彈性伸縮服務(wù)
隨著企業(yè)互聯(lián)網(wǎng)化的深入，企業(yè)的云上業(yè)務(wù)大并發(fā)突發(fā)訪問成為常態(tài)，但是基于企業(yè)專有云成本等考慮，不可能按照峰值配置資源，而公共云就成為臨時彈性資源的不二選擇。
我們團隊基于 Senlin 項目開發(fā)了針對虛擬機和容器的跨云彈性伸縮能力。在大并發(fā)業(yè)務(wù)訪問發(fā)生時，根據(jù)閾值優(yōu)先在本地 OpenStack 云內(nèi)彈性分配虛擬機或容器。
當本地計算資源不足時，自動在阿里公共云進行彈性分配，滿足企業(yè)突發(fā)流量的業(yè)務(wù)需求。
圖4：混合云彈性伸縮
OpenStack容器化，支持一鍵部署
OpenStack 各個組件是一個非常好的微服務(wù)架構(gòu)設(shè)計，各個服務(wù)間通過 RestfulAPI 交付，只要 API 兼容，各個組件間理論上可以獨立升級。
并且 OpenStack 各個組件運行基本上是無狀態(tài)應(yīng)用，配置和運行數(shù)據(jù)通過數(shù)據(jù)庫存儲，所以它進行 Docker 化是非常合適的。
目前我們 OpenStack 組件全部 Docker 化，通過 K8S 進行管理，同時支持一鍵式白屏化大集群部署。
圖5：OpenStack 容器化
圖6：OpenStack 一鍵式自動部署
有人說技術(shù)的發(fā)展就是在翻越一個又一個山峰，OpenStack 相比傳統(tǒng) IT 技術(shù)來說，在企業(yè)級應(yīng)用中可以說才剛剛起步，仍有大量問題亟待找到更好的解決方案，也有大量的課題需要廣大社區(qū)同仁和研發(fā)伙伴通過不斷地“開腦洞”，來推動創(chuàng)新實踐。
比如是否能夠通過在框架中增加調(diào)用流程鏈路跟蹤能力來降低運維難度，或是將微服務(wù)的理念移植到產(chǎn)品當中，這些也許都會變成 OpenStack 在企業(yè)級應(yīng)用乃至產(chǎn)業(yè)云應(yīng)用的新引爆點。
閱讀排行榜
