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

雲數據中心已經成爲當下企業數據中心建設的主流,各種公共雲、專有云和混合雲技術輪番登場。開源的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對雲平臺運維人員要求較高,專業人才難尋ide

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技術框架

OpenStack企業級應用

 優化的網關架構

前文提到的業內解決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年×××數夢工場,目前擔任數夢工場混合雲產品線首席架構師,負責數夢工場混合雲產品線的產品規劃和設計工做。

相關文章
相關標籤/搜索