企業級雲管理平臺的架構實現與落地實踐、趨勢分析

企業級雲管理平臺的架構實現與落地實踐、趨勢分析

4月23日天雲軟體技術開放日已圓滿落幕,接下來幾天將陸續放出沙龍期間技術大牛們的乾貨分享現場實錄及相關檔案,敬請關注。此文為第一篇,由天雲軟體產品總監馬俊帶來的IaaS專題:企業級雲管理平臺的架構實現與落地實踐、趨勢分析,以下為演講實錄。

馬俊:我給大家介紹一下雲管平臺,OpenStack現在比較流行,企業級客戶IT架構在OpenStack上會有一個雲管的平臺,整個業界對雲系統建設也都是怎麼認識的。

我們看其實最下面有一個虛擬化的層,這裡面有Vsphere、KVM、XenServer,然後在上面技術架構層上發生了變化,最開始從Vcenter逐漸發展成OpenStack,我們發現需要個雲管平臺,這個平臺把底下的不同技術架構進行統一管理,整個業界也都是按照這個層次來進行IT系統建設。現在OpenStack比較流行的,企業使用者上了OpenStack以後,在CMP上的需求就出來了,單單通過OpenStack或者vCenter這樣的技術架構是不能解決使用者在管理上的需求的。

我們看一下企業級雲管理平臺的架構,這是我們的架構,核心是CMDB和排程,向下強調的是對異構雲端計算資源的管理。對於企業來說CMDB非常重要,可以存放IT資源資訊。還有一個排程的模組,這是我們CMP產品的核心,對於企業客戶來說怎麼樣把資源管理好,這就是一個排程問題。我們還有監控模組,因為我們看到有很多客戶有監控的需求。去年開始容器比較火,很多人問容器放在CMP管理還是放在其他系統管理,後面我們探討一下像容器是否應該放到CMP裡管理。下面分析一下我們解決過的客戶需求,我相信大家做專案也遇到過。

我們說有CMP,要實現統一管理統一的配置。這樣就會解決很多問題,傳統的多資料中心管理,如果沒有用統一的管理平臺,使用者操作起來會比較麻煩。這樣最簡單的需求就是我們上CMP,為了管理多資料中心,多資源池。這是我們實際客戶的案例,假如沒有CMP,其實從管理角度來說非常麻煩,這裡對OpenStack和vcenter複雜的架構,對上面支撐應用,這是實際的場景。

客戶傳統IT裡面有小型機,把小型機放在CMP裡面管理。我們需要把小型機資源放到CMDB裡頭,對於不同型別的小型機通過不同的技術來進行管理。這是我們實際客戶上的專案一個截圖,把小型機也放在CMDB裡頭管理。

如果客戶已經有了OpenStack,已經有了vCenter,接著客戶要上一個CMP,希望直接把資源同步到CMP上。這是順理成章的事情,我們有這樣的功能,比如說客戶已經有了OpenStack,直接上了CMP以後,通過CMP就可以直接進行管理。

很多專案裡頭客戶提到了很多網管的要求,客戶希望把網管的需求加在CMP裡,這是給客戶做了資料中心機房的視覺化檢視。可以看到機架背板的情況。

另外對於虛擬化來說特別重要的步驟,對於雲管來說怎麼樣把資源使用率發揮到最大,一個研發的資源,它的超賣係數可能是平均的水平,一個生產環境它的超賣係數可能是最低的,對於整個虛擬化資源管理,這個超賣係數跟我們說的排程有關係。

這張圖,這是物理使用的資源,對於虛擬化來講,已分配超過物理資源的數量,這個就是說為什麼我們用虛擬化,只要使用率低於物理的最大值,我們就可以繼續分配資源,這是雲管平臺特別明顯的管理作用。

我們看到雲管就是看會不會排程,雲的特性就是有彈性,底下是多個資源池,怎麼把資源池資源使用率發揮到最大,我們通過CMP做一些事情,我們看到哪些機器晚上可以關機的,比如說這臺機器上有兩個虛擬機器,可以遷移到另外的主機上,可以把這個物理機進行關機,這是基於能源節省的排程方式。

這是基於時間的排程方式,桌面雲的業務,這個業務白天才執行,私有云的業務,有些業務可以跑在晚上的,其實這是典型雲彈性的需求,桌面雲的這些資源在晚上的時候是不使用的,可以把私有云業務遷移到桌面雲上跑,白天再把這些業務遷到私有云上,白天跑桌面業務,實現跨雲的彈性,這個跟虛擬化軟體跟OpenStack沒有什麼關係了,完全是一個雲管的排程功能。

這是我們系統裡面做的一個排程,我們用YARN做的排程,YARN是Hadoop的模組,裡面有對任務的排程,我們進行了擴充套件,把排程擴充套件到虛擬機器上,進而做成了我們的排程模組。

舉例說明我們的CPU資源排程,比如說有系統預留,有執行中使用的等等。我們有系統預留的引數,調整這些引數,資源使用率達到最大,達到物理資源和業務效能保持平衡。

還有一個更高的需求,就是充分體現雲的特性,可以做自動的伸縮,這個也是我們客戶的案例。我們說很多做虛擬化資源池的,或者OpenStack的軟體,都是基於物理資源來做的,我們看到這個例子裡面我們基於應用的效能指標做的,這是業務每秒的併發數,這個併發數達到一千的時候會進行自動伸縮,這個依賴於底下的資源池形具有彈性的能力,通過雲管平臺能夠把虛擬化資源使用率達到最大,而且方便業務系統使用雲的特性。

這個我們應用之後,應用部署在虛擬機器上,做應用編排的視覺化。現在更多用Docker來做,之前用虛擬機器做。建一個自動伸縮組,伸縮組編排自動部署,這是基於虛擬機器應用的編排。

我們看到涉及到運管它有很多流程的管理,這個流程管理也是比較重要的,這是一個客戶實際的案例,這樣的一個流程,雲管跟OpenStack有很大區別,在這進行一個業務資源使用率的計算,這都是依賴於CMP的排程系統提供的。我舉個例子,使用者申請了資源,這個資源給業務系統使用,但是這個業務系統資源使用率非常低,業務系統進行擴容的時候,依賴於雲管平臺提供的排程,得出業務系統資源使用率什麼情況,領導進行審批的時候就可以決定這個業務系統是否做擴容,這對管理人員是很好的幫助。

跟傳統的OA系統、4A的系統有一些介面的,要和這些系統去做一些同步。把雲管和網管、OA、自動認證的系統對接,這樣客戶的IT管理上,就會形成統一的使用者體系和監控體系。

這個也是企業客戶提出來的,因為企業客戶用了雲管,希望把網管功能都放在雲管上,這是我們給客戶做的儲存的管理。

這個完全是一個網管的需求,給客戶做一個網管的拓撲。和雲相關做出來一個虛擬機器之後,要和防火牆、負載均衡有一些關聯。比如說我們現在可以用OpenStack的NFV提供的虛擬網路裝置介面去做,但是對於有些使用者來說它的網路裝置不是用NSF,是物理裝置,這時候需要同這些物理裝置進行對接。

這是我們給客戶做得自服務的門戶,每個客戶對門戶需求都是不一樣的,我們基本上按照客戶需求去做一些定製合作。

我們CMP產品以API方式提供,這樣可以和客戶的OA整合,和網管整合,和PAAS平臺進行整合,這是對於產品級的CMP的需求,不是專案級的,客戶需要有這樣的產品,客戶自己去做整合,包括UI介面的定製,客戶也可以自己去做。

下面我介紹一下CMP後續的發展。其實看到我們自己做的一些工作,我們的雲管平臺,也在向微服務化方向改造,這樣我們做整合、開發測試和上線比較方便。這裡面是我們把雲管平臺拆分成一些微服務化。

這個是涉及到排程,涉及到人工智慧的方向。左邊這個大圖是完全基於我們系統的資料,然後人工做的一個分析,這個分析目的其實為了業務系統擴容,給客戶提供一些建議。2011年客戶的網管使用情況,2012年客戶的網管使用情況,推算出來客戶每個季度儲存、記憶體等資源使用情況,我們以後可以基於機器學習做這樣的事情,這個帶來比較好的客戶投資收益。傳統不是這樣的,傳統完全根據業務口需求進行擴容。以後基於機器學習,上了CMP以後,基於CMP的資料做一些機器學習的分析。

這個也是一樣,左邊這個圖也都不是基於機器學習去做的,這個基於雲管,雲管有一個特性,它可以把資源池虛擬化的資源使用率達到最大,這是分析之前的,超賣係數是多少,CPU超賣多少。第二行是分析之後的,這種工作原先我們做了一個演算法模型,通過這個演算法模型做分析,這個演算法模型依賴於業務系統,每個月業務系統都會進行變化,其實這個模型也要變化,我們做的時候比較累,可能每半年調整一次模型。將來我們基於機器學習讓這個計算模型自己調整,這樣可以把它的虛擬化資源池使用率調到最大。

這個相當於大IT的概念,雙模IT中傳統的有網管,探索式的有IAAS和PAAS,使用者想把IAAS和PAAS在一起管理,上一個IT的管理平臺,然後把傳統網管、IaaS和PaaS統一起來,將來雲管會成為一個大的IT管理平臺。

下面介紹一些我們案例,我們做運營商比較多,比如說中國移動、中國聯通、教育、政府公共事業,我列出的客戶需求也是從這些案例中抽取出來的。這是我們做得最大的就是聯通的沃雲,這個承載非常多,是全國性的,去年年底達到25萬CPU的規模。我就介紹這些,謝謝大家。

Q&A環節

Q:負載均衡那一塊講一下。

A:第一種通過Open Stack的neutron元件裡面的負載均衡,前提是上了OpenStack可以通過軟體來做。但是如果沒使用OpenStack,傳統都是通過硬體來實現的,比如說客戶用的是F5,這時候需要跟F5進行對接,這時候完全是客戶定製化的需求了。

Q:就對接演算法嗎?

A:也不全是對接演算法,還要對接其他功能。OpenStack完全依賴於neutron的設計,它提供的演算法並不多,如果對接物理裝置提供的演算法比較多了,因為這是傳統的負載均衡設計能夠提供的負載均衡能力。比如說基於源IP、基於最小會話數等等的都可以。這種定製化的功能會非常多,因為OpenStack是一個標準軟體,你可以實現一個傳統的CMP,基於F5去做要根據不同專案去做定製。
 

Q:你們在排程異構資源的難點是什麼?你們排程異構資源怎麼去做?

A:難點在於一個是同步,一個是大資料量處理。CMP能進行操作,資源池也能進行操作,同步處理不好會遇到很多麻煩的。另外就是大資料量處理,我們管理幾千臺物理機,上面虛擬機器就更多了,這種大資料量處理非常複雜,在我們系統架構裡面我們有一個rabbitmq,其實是一個快取的訊息處理方式,OpenStack的rabbitmq也是一樣的。我們通過訊息佇列來去處理。異構管理比較難的地方,最開始比較難就是同步。

Q:你是實時更新狀態還是手動更新?

A:系統自動去做的,如果Open Stack限定在20臺機器以內,對監控要求比較高,在運營商使用者上Vcenter管得資源都是上千臺,一旦量級上去對於CMP整個同步能力要求非常高,這裡頭也涉及到監控,物理資源達到千級規模,它的虛擬資源更多了,對於監控也是比較關鍵的地方。

Q:我這塊有兩個問題,第一個咱們資源排程這塊我有兩個想跟你確認的,咱們跨平臺的角度。跨什麼平臺都可以嗎?

A:可以。

Q:跨資料中心嗎?

A:可以。這裡面有一些網路改造工作,跨多個資料中心,多個資料中心生產網路要通,否則跨另外一個資料中心沒有意義。我們考慮和業務的相關性,我會把業務很多屬性作為排程的依據,我們說像vCenter和OpenStack基本上考慮都是基於資源做排程,很多的客戶,我接觸到的,包括我們OpenStack很多合作伙伴的客戶,他們都不喜歡用排程,也不喜歡用這些雲的一些特性,因為OpenStack和vCenter都是針對資源的的,會導致業務執行出錯,我們用業務屬性,再結合資源屬性做排程。

Q:咱們對儲存資源做一定的監控,管理和排程,這塊咱們做到什麼程度?

A:我們對SAN儲存、物件儲存、NAS儲存都對接過。

Q:我們對接到儲存廠商管理端還是?

A:比如說SAN儲存,基於國際上SMIS的協議去做,這個協議是開放的,但是不同的儲存廠商對這個協議支援不一樣。舉個例子有的儲存廠商,不同型號也不一樣,它可能對這個協議支援到70%,有的只能支援20%的功能。對於NAS儲存和物件儲存比較新的,這個可以實現100%。

Q:就是我們整個SAN儲存管理是基於SMIS做的是吧?

A:對。