技術(shù)照進(jìn)現(xiàn)實(shí)，OpenStack企業(yè)級(jí)應(yīng)用的五大難解之結(jié)

原創(chuàng)
作者：葛建壯 2017-08-18 15:57:25

云計(jì)算

OpenStack 開(kāi)源的OpenStack作為最火熱的企業(yè)云數(shù)據(jù)中心云平臺(tái)管理框架，受到了企業(yè)的日益關(guān)注并且獲得了大量的企業(yè)級(jí)應(yīng)用實(shí)踐，在產(chǎn)業(yè)互聯(lián)網(wǎng)發(fā)展進(jìn)程中占據(jù)了越來(lái)越多的份額。但是在實(shí)踐中，由于OpenStack屬于知識(shí)密集型的開(kāi)源產(chǎn)品，在企業(yè)部署、使用和運(yùn)維的過(guò)程中，往往會(huì)遇到各種挑戰(zhàn)。

【51CTO.com原創(chuàng)稿件】云數(shù)據(jù)中心已經(jīng)成為當(dāng)下企業(yè)數(shù)據(jù)中心建設(shè)的主流，各類(lèi)公共云、專(zhuān)有云和混合云技術(shù)輪番登場(chǎng)。開(kāi)源的OpenStack作為最火熱的企業(yè)云數(shù)據(jù)中心云平臺(tái)管理框架，受到了企業(yè)的日益關(guān)注并且獲得了大量的企業(yè)級(jí)應(yīng)用實(shí)踐，在產(chǎn)業(yè)互聯(lián)網(wǎng)發(fā)展進(jìn)程中占據(jù)了越來(lái)越多的份額。但是在實(shí)踐中，由于OpenStack屬于知識(shí)密集型的開(kāi)源產(chǎn)品，在企業(yè)部署、使用和運(yùn)維的過(guò)程中，往往會(huì)遇到各種挑戰(zhàn)。

技術(shù)照進(jìn)現(xiàn)實(shí)，企業(yè)級(jí)應(yīng)用尚存難解之結(jié)

目前，OpenStack在企業(yè)應(yīng)用過(guò)程中主要有五個(gè)問(wèn)題：

1.產(chǎn)品化不足，無(wú)法完全滿足企業(yè)用戶(hù)的需求

OpenStack架構(gòu)層面的設(shè)計(jì)傾向于做公共云服務(wù)，因此對(duì)于很多企業(yè)級(jí)的特性未考慮或者考慮不充分，同時(shí)開(kāi)源產(chǎn)品自身產(chǎn)品化能力較低，只提供了基礎(chǔ)功能可用；而商業(yè)環(huán)境中的各項(xiàng)應(yīng)用往往要求其擁有更加完善的運(yùn)維和運(yùn)營(yíng)能力。

這就導(dǎo)致很多企業(yè)通過(guò)簡(jiǎn)單的搭積木形式利用OpenStack和各種輔助開(kāi)源產(chǎn)品在企業(yè)中推進(jìn)部署，使得OpenStack在很多場(chǎng)景下無(wú)法為企業(yè)提供有效的持續(xù)化服務(wù)。

另一方面，OpenStack的設(shè)計(jì)初衷更加偏向解決“ToC”的需求，在實(shí)際企業(yè)應(yīng)用中，部門(mén)管理、統(tǒng)一認(rèn)證、權(quán)限控制、工單申請(qǐng)審批、操作審計(jì)、計(jì)量計(jì)費(fèi)、云上云下計(jì)算資源和存儲(chǔ)資源的管理和監(jiān)控等強(qiáng)需求功能缺乏足夠支撐。

2.OpenStack原生參考實(shí)現(xiàn)無(wú)法支持大規(guī)模網(wǎng)絡(luò)

OpenStack Neutron參考實(shí)現(xiàn)的網(wǎng)絡(luò)模型，通過(guò)在每個(gè)計(jì)算節(jié)點(diǎn)和網(wǎng)關(guān)節(jié)點(diǎn)上利用namespace來(lái)進(jìn)行3層轉(zhuǎn)發(fā)和DVR，在大規(guī)模集群時(shí)，命名空間會(huì)占用大量系統(tǒng)資源，同時(shí)命名空間的TCP/IP協(xié)議棧轉(zhuǎn)發(fā)性能比流表效率低。此外在參考實(shí)現(xiàn)中，使用了大量的Agent（例如：neutron-openvswitch-agent ,dhcp-agent，l3agent），當(dāng)集群規(guī)模很大時(shí)，大量的Agent參與的RPC會(huì)成為瓶頸，并且大量的Agent運(yùn)維也成為管理瓶頸。

3.OpenStack對(duì)云平臺(tái)運(yùn)維人員要求較高，專(zhuān)業(yè)人才難尋

OpenStack應(yīng)用日益廣泛，但是初始交付OpenStack云平臺(tái)后，后期的運(yùn)維通常需要一個(gè)專(zhuān)門(mén)的OpenStack團(tuán)隊(duì)來(lái)維護(hù)，需要計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)、硬件和軟件等多個(gè)方面的專(zhuān)家來(lái)共同合作，才能保證OpenStack云平臺(tái)的后續(xù)正常運(yùn)轉(zhuǎn)。而另一方面我們也能看到，目前OpenStack的人才可謂一將難求，相關(guān)人才的招聘和培養(yǎng)均需要花費(fèi)大量的時(shí)間和資源，這樣大部分企業(yè)用戶(hù)很難自行培養(yǎng)組建出一支高水準(zhǔn)、能力強(qiáng)的運(yùn)維團(tuán)隊(duì)。

4.OpenStack中云化數(shù)據(jù)庫(kù)商業(yè)化不足

企業(yè)業(yè)務(wù)中對(duì)關(guān)系型數(shù)據(jù)庫(kù)的需求是不可或缺的，隨著數(shù)據(jù)中心的云化，云化的多租戶(hù)的數(shù)據(jù)庫(kù)也成為必然，社區(qū)的數(shù)據(jù)庫(kù)功能目前其成熟度和可運(yùn)維程度距離實(shí)際的商用需求和使用還有一定的距離。

5.版本升級(jí)問(wèn)題

諸如企業(yè)內(nèi)OpenStack版本升級(jí)“困難”等非技術(shù)問(wèn)題也亟待解決，OpenStack社區(qū)每半年會(huì)出一個(gè)新的版本，但是企業(yè)對(duì)業(yè)務(wù)穩(wěn)定的要求遠(yuǎn)高于對(duì)版本的追求，每半年升級(jí)一次底層系統(tǒng)所帶來(lái)的業(yè)務(wù)中斷等問(wèn)題，讓企業(yè)更傾向于選擇暫不升級(jí)。但當(dāng)企業(yè)兩年后甚至更長(zhǎng)時(shí)候后升級(jí)平臺(tái)， OpenStack已經(jīng)更新了多個(gè)版本，容易造成無(wú)法升級(jí)的局面。

多角度出發(fā)，推動(dòng)OpenStack技術(shù)與產(chǎn)品演進(jìn)

OpenStack本身來(lái)說(shuō)僅僅提供了基礎(chǔ)的計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)能力，但是在實(shí)際交付中，單純的IAAS資源提供無(wú)法滿足用戶(hù)的業(yè)務(wù)價(jià)值需求，它需要做大量的周邊工作，例如虛擬機(jī)/容器和數(shù)據(jù)的安全、虛擬機(jī)/容器和數(shù)據(jù)的災(zāi)備、數(shù)據(jù)的同步、與大數(shù)據(jù)系統(tǒng)的交互、與PaaS平臺(tái)的配合，應(yīng)用的彈性，VM/容器的自動(dòng)彈性伸縮、提供成熟的云化關(guān)系型數(shù)據(jù)庫(kù)、傳統(tǒng)數(shù)據(jù)庫(kù)的使用，以及和不能云化的資源互訪等等，每一個(gè)需求都意味著大量的工作和知識(shí)領(lǐng)域的擴(kuò)充，對(duì)提供云服務(wù)的廠商提出了更高的技術(shù)要求和架構(gòu)設(shè)計(jì)要求。

在產(chǎn)品化和商業(yè)化方面，例如如何快速進(jìn)行大規(guī)模部署，如何在大規(guī)模集群下保證管控節(jié)點(diǎn)、計(jì)算節(jié)點(diǎn)和網(wǎng)絡(luò)節(jié)點(diǎn)的高性能和高可靠性，如何在發(fā)生各種故障時(shí)系統(tǒng)自動(dòng)恢復(fù)和修復(fù)，如何實(shí)現(xiàn)OpenStack云數(shù)據(jù)中心云上和云下資源的監(jiān)控、審計(jì)、告警、自動(dòng)化或半自動(dòng)化運(yùn)維，如何進(jìn)行OpenStack云數(shù)據(jù)中心的平滑擴(kuò)容等等，對(duì)于大量云計(jì)算技術(shù)力量相對(duì)薄弱的企業(yè)來(lái)說(shuō)，使用成熟的產(chǎn)品和服務(wù)，遠(yuǎn)比獨(dú)立推動(dòng)OpenStack的建設(shè)和部署更為有效。想把OpenStack用好、用到位，則必須通過(guò)相關(guān)廠家將其進(jìn)行產(chǎn)品化開(kāi)發(fā)，企業(yè)才能真正方便經(jīng)濟(jì)的使用起來(lái)。

以筆者所在的數(shù)夢(mèng)工場(chǎng)研發(fā)與產(chǎn)品團(tuán)隊(duì)為例，團(tuán)隊(duì)成員大多擁有多年同客戶(hù)共同探索數(shù)據(jù)中心核心場(chǎng)景需求和相關(guān)產(chǎn)品技術(shù)研發(fā)的經(jīng)驗(yàn)，近年來(lái)針對(duì)OpenStack的企業(yè)級(jí)應(yīng)用和產(chǎn)品化也進(jìn)行了大量技術(shù)研究和深入開(kāi)發(fā)，已可以為用戶(hù)提供完整的計(jì)算、存儲(chǔ)（塊存儲(chǔ)和對(duì)象存儲(chǔ)）、網(wǎng)絡(luò)（SDN）、云化關(guān)系型數(shù)據(jù)庫(kù)、PaaS和災(zāi)備等服務(wù)，同時(shí)核心成員也積極參與到了OpenStack社區(qū)技術(shù)研發(fā)當(dāng)中，最大程度貢獻(xiàn)了自己的力量。 

數(shù)夢(mèng)工場(chǎng)OpenStack產(chǎn)品架構(gòu)一覽

1.深入?yún)⑴c社區(qū)OpenStack SDN技術(shù)研發(fā)

SDN技術(shù)框架

 優(yōu)化的網(wǎng)關(guān)架構(gòu)

前文提到的業(yè)內(nèi)解決Neutron問(wèn)題的主要辦法是使用SDN來(lái)進(jìn)行虛擬網(wǎng)絡(luò)和物理網(wǎng)絡(luò)的管理，并通過(guò)OpenFlow流表形式指導(dǎo)轉(zhuǎn)發(fā)，減少或不再使用各種Agent。但是目前常見(jiàn)SDN設(shè)計(jì)均采用首包上送控制集群進(jìn)行處理，在大規(guī)模集群場(chǎng)景下，大量的首包上送會(huì)造成對(duì)控制集群的大流量沖擊，同時(shí)控制集群的GC問(wèn)題也會(huì)造成集群的不穩(wěn)定，并且控制集群采用OpenFlow遠(yuǎn)程下發(fā)流表到各個(gè)計(jì)算節(jié)點(diǎn)和網(wǎng)絡(luò)節(jié)點(diǎn)，又占用了大量的帶內(nèi)/帶外帶寬，所以在實(shí)際大規(guī)模集群中會(huì)遇到很多問(wèn)題。

數(shù)夢(mèng)工場(chǎng)SDN團(tuán)隊(duì)開(kāi)發(fā)和實(shí)現(xiàn)了分層SDN控制器，有效的避免了上面常見(jiàn)SDN方案遇到的問(wèn)題，有效的支持了大規(guī)模企業(yè)云數(shù)據(jù)中心的建設(shè)。它完全使用X86服務(wù)器作為云數(shù)據(jù)中心網(wǎng)絡(luò)設(shè)備，傳統(tǒng)交換機(jī)僅僅作為純2層和3層轉(zhuǎn)發(fā)，構(gòu)建了極簡(jiǎn)的云數(shù)據(jù)中心，各種云網(wǎng)絡(luò)服務(wù)可以快速實(shí)現(xiàn)和更新，網(wǎng)絡(luò)服務(wù)更靈活。并且根據(jù)實(shí)際交付經(jīng)驗(yàn)，細(xì)化了網(wǎng)關(guān)角色，更加適應(yīng)企業(yè)級(jí)大規(guī)模數(shù)據(jù)中心網(wǎng)絡(luò)需求。SDN團(tuán)隊(duì)在networking-ovn項(xiàng)目有一個(gè)核心Core成員，SDN團(tuán)隊(duì)成員為OVS、OVN、Networking-ovn貢獻(xiàn)了大量的代碼和修復(fù)了多個(gè)問(wèn)題。

2.可以跨越OpenStack和阿里公共云的混合云彈性伸縮服務(wù)

隨著企業(yè)互聯(lián)網(wǎng)化的深入，企業(yè)的云上業(yè)務(wù)大并發(fā)突發(fā)訪問(wèn)成為常態(tài)，但是基于企業(yè)專(zhuān)有云成本等考慮，不可能按照峰值配置資源，而公共云就成為臨時(shí)彈性資源的不二選擇。

數(shù)夢(mèng)工場(chǎng)團(tuán)隊(duì)基于Senlin項(xiàng)目開(kāi)發(fā)了針對(duì)虛擬機(jī)和容器的跨云彈性伸縮能力。在大并發(fā)業(yè)務(wù)訪問(wèn)發(fā)生時(shí)，根據(jù)閾值優(yōu)先在本地OpenStack云內(nèi)彈性分配虛擬機(jī)或容器；當(dāng)本地計(jì)算資源不足時(shí)，自動(dòng)在阿里公共云進(jìn)行彈性分配，滿足企業(yè)突發(fā)流量的業(yè)務(wù)需求。

混合云彈性伸縮

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

OpenStack各個(gè)組件是一個(gè)非常好的微服務(wù)架構(gòu)設(shè)計(jì)，各個(gè)服務(wù)間通過(guò)RestfulAPI交付，只要API兼容，各個(gè)組件間理論上可以獨(dú)立升級(jí)。并且OpenStack各個(gè)組件運(yùn)行基本上是無(wú)狀態(tài)應(yīng)用，配置和運(yùn)行數(shù)據(jù)通過(guò)數(shù)據(jù)庫(kù)存儲(chǔ)，所以它進(jìn)行Docker化是非常合適的。

目前數(shù)夢(mèng)工場(chǎng)OpenStack組件全部Docker化，通過(guò)K8S進(jìn)行管理，同時(shí)支持一鍵式白屏化大集群部署。

OpenStack容器化

OpenStack一鍵式自動(dòng)部署

有人說(shuō)技術(shù)的發(fā)展就是在翻越一個(gè)又一個(gè)山峰，OpenStack相比傳統(tǒng)IT技術(shù)來(lái)說(shuō)，在企業(yè)級(jí)應(yīng)用中可以說(shuō)才剛剛起步，仍有大量問(wèn)題亟待找到更好的解決方案，也有大量的課題需要廣大社區(qū)同仁和研發(fā)伙伴通過(guò)不斷地“開(kāi)腦洞”，來(lái)推動(dòng)創(chuàng)新實(shí)踐。比如是否能夠通過(guò)在框架中增加調(diào)用流程鏈路跟蹤能力來(lái)降低運(yùn)維難度，或是將微服務(wù)的理念移植到產(chǎn)品當(dāng)中，這些也許都會(huì)變成OpenStack在企業(yè)級(jí)應(yīng)用乃至產(chǎn)業(yè)云應(yīng)用的新引爆點(diǎn)。

【作者簡(jiǎn)介】

葛建壯，2005年開(kāi)始從事數(shù)據(jù)通信行業(yè)，擁有多年網(wǎng)絡(luò)設(shè)計(jì)和開(kāi)發(fā)經(jīng)驗(yàn)；作為架構(gòu)師完整參與設(shè)計(jì)和交付了多款業(yè)內(nèi)領(lǐng)先的SDN產(chǎn)品和NFV產(chǎn)品。2013年開(kāi)始OpenStack相關(guān)研究，并持續(xù)關(guān)注和實(shí)踐。2015年加盟數(shù)夢(mèng)工場(chǎng)，目前擔(dān)任數(shù)夢(mèng)工場(chǎng)混合云產(chǎn)品線首席架構(gòu)師，負(fù)責(zé)數(shù)夢(mèng)工場(chǎng)混合云產(chǎn)品線的產(chǎn)品規(guī)劃和設(shè)計(jì)工作。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】

本文題目：技術(shù)照進(jìn)現(xiàn)實(shí)，OpenStack企業(yè)級(jí)應(yīng)用的五大難解之結(jié)
文章URL：http://uogjgqi.cn/article/cccshjc.html