頻道欄目
首頁 > 資訊 > 云計算 > 正文

OpenStack架構分析與實踐

19-02-13        來源:[db:作者]  
收藏   我要投稿

OpenStack架構分析與實踐

OpenStack以每年兩個版本的速度不斷迅速演進,所以對于OpenStack的架構而言,也是不斷向前發展的;仡櫼幌翬版本的OpenStack,它只有5個組件:Nova、Galnce、Swift、Horizon和Keystone;當發展到F版本后,其核心組件發展到了7個,比E版本多了Neutron和Cinder兩個組件,它們分別實現Compute Network和Compute Volume的功能,但是從后續的發展中可以看出,它們遠遠超出了Compute Network和Compute Volume所支持的功能。

一、業務架構設計思路

OpenStck做的比較好的一點就是架構設計比較通過,對于不同的模塊,其業務架構設計方面一般滿足以下設計思路:

REST API接收外部請求

Scheduler負責調度服務

Worker負責任務分配

Driver負責任務實現

消息隊列負責組件內部通信

數據庫服務

接下來分別介紹一下上述設計思路。

REST API接收外部請求。OpenStack中的邏輯關系是要各個組件之間的信息傳輸來實現的,而不同的組件間的消息的傳遞與交互是通過各個組件的REST API進行的?梢岳斫鉃,REST API是所有服務的入口,它對外接收客戶發來的REST請求,對內實現請求轉發。

REST API還有一個好處就是可以對外隱藏內部實現細節,提供統一的訪問接口,由于其模塊化的設計,REST API可以很方便的與第三方系統進行集成;在大規模環境下,REST API可以采用分布式部署的方式,從而極大的提高了API的高可用。

Scheduler負責調度服務。這里所說的Scheduler只是一個統稱,并不是說每一個組件中都有一個xxx-scheduler的服務,但是大部分組件中都有一個提供類似功能的服務,它可能是單獨存在,也有可能是與其他的服務柔和在一起共同提供服務。

我們以Nova為例來說明一下Scheduler的調度服務。當我們創建虛擬機時,往往需要選擇出合適的計算節點,然后在這個節點上進行虛擬機的創建,那么,這里對節點的篩選就需要借助nova-scheduler的調度功能。

Worker負責工作服務。上面提到的Scheduler只會負責任務的分配,它有點類似于公司中的項目經理,它會統籌大家的工作,把工作分配給合適的人去做,而Worker才是真正執行相關任務的服務。例如:在Nova中,Worker就是nova-compute服務;在Heat中,heat-engine就是Worker,在許多組件中,我們可以把xxx-engine看作是不同的Worker。

當把負責調度的Scheduler和負責工作的Worker分開后,就使得OpenStack更加容易擴展,這也使得我們可以從不同的方面考慮如何去提高系統的并發性與應對大規模請求的場景。

Driver負責任務實現。為了擁抱不同的技術,OpenStack采用了大量的Driver,例如,在Nova組件中,nova-compute服務可以支持多種不同的Hypervisor,用戶可以根據需要通過配置文件進行配置,當修改完配置文件后,只需要重新啟動一下服務即可;在Glance組件中,它支持多種存儲后端,如:本地文件系統、Ceph、Cinder和Swift等。

其實說白了,之所以可以支持各種不同的Driver,是因為不同的組件會有各自的Driver框架,用戶只需要把符合需求的Driver配置好即可使用。Driver框架的存在,也降低了上層開發人員對底層知識的要求。上層開發人員無需關心底層Driver是如何實現的,關于Diver的實現完全可以交給專的人員去做。

消息隊列負責組件內部通信。通過前幾章節的學習相信大家對這個并不會感到陌生,消息隊列的產生,極大的解耦了同一組件的不同服務,使得它們可以實現分布式獨立部署。在生產中,我們經常使用的消息隊列調用方式有:同步調用和異步調用。

同步調用,從調用關系上來看,是REST API直接調用組件內部服務,以Nova為例,同步調用就是nova-api服務直接調用nova-scheduler且等待返回結果。在這種方式下,當后端面沒有返回響應時,REST API服務將一直處于等待狀態。

異步調用,與同步調用相反,即,當REST請求發出后,發送方并不會等待接收方的響應而是直接返回。

數據庫服務。OpenStack中每一個組件都需要維護各自的狀態信息,所以各個組件后端都會有一個數據庫服務與之對應。

二、部署架構設計思路

模塊化的業務架構極大的將不同組件進行了解耦,正因如此,也使得同一組件不同服務之間實現解耦。這樣以來,非但不同的組件可以實現分布式部署,就連同一組件的不同服務的也可以實現分布式部署,近幾年隨著容器技術的興趣,OpenStack組件分離及服務模塊化的設計更加容易實現容器化部署。

提示:社區中已經有一個針對OpenStack部署的較為成熟的容器化部署方案,這個項目的名字叫Kolla。

拋開容器化,我們看一下OpenStack有著怎么樣的一個部署上的設計思路。

上一節是從邏輯關系及相互之間的通信關系分析了OpenStack的業務設計架構,屬于上層的軟件邏輯架構,眾所周知,OpenStack是一個分布式的系統,它就得解決上層邏輯與底層物理架構映射的問題,除此之外,還需要考慮如何才能合理的將不同組件安裝到實際的物理服務器上、同一組件不同服務應該如何進行部署等問題。

OpenStack的部署粗略的可以分為兩種:

All-in-One部署。適用于開發環境、學習環境。因為OpenStack發展速度比較快,如果我們對某個組件比較感興趣,可以通過此種方式快速搭建一套含有此組件的OpenStack環境。目前關于快速搭建的工具主要有:DevStack 和RDO兩種。另外,通過Fuel也可以實現快速搭建,但這種方式在使用方面比較笨重。

分布式部署。也可以稱作集群部署,即,將不同的組件及同一組件的不同服務分別進行部署,可以部署在同一個物理服務器上,也可以根據實現需要部署到不同的物理服務器上。

雖然我們這里提到了兩種部署方式,但是OpenStack的部署也不是一成不變的,而是需要根據實際的生產實踐需求設計不同的落地方案。在真正的生產中部署時,需要對OpenStack中的計算、網絡、存儲等資源提前進行規劃,針對不同的規劃方案,又延伸出兩種部署架構:簡單部署架構和復雜部署架構。

簡單部署架構

這是一個滿足簡單生產環境的簡易部署方案,對于此種方案的部署而言,一般節點角色較為簡單,網絡設置也不是特別復雜。其架構設計如下:

1. 節點角色

僅包含控制節點、計算節點、存儲節點。對于OpenStack的大多數服務而言,它們都部署在控制節點上,例如認證服務、鏡像服務等,控制節點也可以稱為管理節點,主要用于調度本節點及其他節點上的相關服務;計算節點是指虛擬機運行時所在的物理服務器;存儲節點主要用于提供存儲服務,特別像Ceph這種分布式存儲,一般會將存儲單獨部署在存儲節點上。

這里沒有提到網絡節點,實際上,網絡節點在OpenStack中是非常重要的,網絡出了問題,那么很多服務都將無法正常運行。為什么這里沒有單獨提到“網絡節點”這一角色呢,因為網絡節點往往可以與控制節點部署在一起。另外,存儲節點也是必需單獨部署的,這需要看我們使用是什么樣的存儲結構,一般來說,存儲節點也是可以與計算節點部署在一起的,例如,當我們使用Sheepdog作為后端存儲時,可以將之與計算節點部署在一起。

2. 網絡部署

雖然網絡既可以單獨部署,也可以與其他的節點一起部署,這里還是需要單獨來說明一下,因為網絡規劃的好處,極大的影響了整個云平臺穩定性、安全性與可維護性。

這里我們暫且將部署網絡服務的節點稱為網絡節點吧(雖然它有可能與上面提到的節點角色有所重疊)。網絡節點部署時一般分為三類:管理網、存儲網、數據網和上聯網。

管理網。它負責管理節點與其他節點間的通信,管理節點可以通過這個網絡實現對其他服務的管理。

存儲網。是計算節點訪問存儲節點的網絡,其他節點向存儲設備中讀寫數據時都會走這個網絡。

數據網。也稱作內部網,用于OpenStack內部組件通信使用。在云平臺中的同一個物理服務器上,可能同時存在著大量的虛擬機,不同虛擬機之間需要進行通信,那么諸如此類的內部通信,就需要經過數據網。

上聯網。也有人稱之為外網,可以對外提供服務的網絡。

以上就是簡單部署架構,從這里看,雖然是簡單部署,但還是遵循著分布式部署的思想,組件、服務分布式部署,網絡按功能進行劃分并進行部署。上述簡單部署可以滿足對云平臺要求不高的用戶,在上述部署方案中,并沒有考慮高可用的問題,也沒有考慮多區域的問題等高級而又復雜的特性。

3.復雜部署架構

此種部署方式可以說是在前一種部署方式的基礎之上進行設計與實現的。針對上述簡單部署架構,在復雜架構設計時,首先需要考慮的問題就是高可用問題,高可用的實現方式有多種,可以將同一組件部署到不同的節點上來實現高可用,也可以通過第三方工具實現高可見。Pacemaker + Cronsyc是一種較為常見的高可用方式,前者實現對資源的管理,后者為前者提供通信服務。容器技術出現后,社區也采取了積極的態度,借助K8S的高可用架構也可以實現OpenStack的高可用,此種部署方案需要將OpenStack的組件部署到容器中。

另外,還需要考慮大規模高并發的情況。針對大規模的場景,我們需要把管理服務分別部署到不同的物理節點上,還可以考慮將同一組件的不同服務也進行剝離實現分布式部署,這樣以來,就可以很容易的實現對OpenStack不同服務進行水平擴展。如:某一時刻有大量創建虛擬機的請求到達,我們可以對水平擴展相關的Nova服務(nova-api、nova-scheduler、nova-conductor和nova-compute)以提高應對高并發的能力。

三、平臺用戶角色設計

OpenStack中功能眾多,可以為我們提供IaaS服務,而一個完整的IaaS服務需要提供以下功能:

平臺可以進行計費

允許平臺的所有者在平臺中進行服務注冊

允許開發人員、運維人員各自創建并存儲他們的自定義鏡像

允許運營管理員配置與修改平臺的基礎架構

基于上述功能,我們可以將OpenStack最基本的平臺用戶角色表示為 如圖所示。

圖: 用戶角色及功能對應關系示意

平臺中共有四類用戶角色:開發人員,運維人員、Owner和運營人員,并每不同的人員分配了各自所需的功能。

對于一個完整的云平臺而言,在設計方面離不開上面所提到的三類設計。友好的角色設計、良好的業務架構及靈活可變的部署方式,是云平臺設計之初就必需仔細考慮的問題,三者缺少一者,必將使得平臺的易用性和可操作性大打折扣。

提示:對于角色來說,不同的云平臺可以根據自身情況自定義一些角色,從而達到對不同人員進行資源隔離的目的,從而也增加了云平臺的安全性。

相關TAG標簽
上一篇:臺積電:絕大多數7nm客戶都會轉向6nm_IT新聞_博客園
下一篇:最后一頁
相關文章
圖文推薦

關于我們 | 聯系我們 | 廣告服務 | 投資合作 | 版權申明 | 在線幫助 | 網站地圖 | 作品發布 | Vip技術培訓 | 舉報中心

版權所有: 紅黑聯盟--致力于做實用的IT技術學習網站

美女MM131爽爽爽毛片