OpenStack架構分析與實踐
OpenStack以每年兩個版本的速度不斷迅速演進，所以對於OpenStack的架構而言，也是不斷向前發展的。回顧一下E版本的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和運營人員，並每不同的人員分配了各自所需的功能。
對於一個完整的雲平臺而言，在設計方面離不開上面所提到的三類設計。友好的角色設計、良好的業務架構及靈活可變的部署方式，是雲平臺設計之初就必需仔細考慮的問題，三者缺少一者，必將使得平臺的易用性和可操作性大打折扣。
提示：對於角色來說，不同的雲平臺可以根據自身情況自定義一些角色，從而達到對不同人員進行資源隔離的目的，從而也增加了雲平臺的安全性。