OpenStack 基礎介紹02——整體架構介紹

今天，咱們繼續來聊 OpenStack 整體架構。希望通過這個章節來讓各位小夥伴，搞清楚 OpenStack 各組件的邏輯關係，各組件之間的通信和部署關係，以及 OpenStack 的工作流程。

1 OpenStack 各組件之間的邏輯關係

邏輯關係圖如下：

需要記住，其中 Compute Node（Nova） 是實際運行虛擬機的節點，Block Storage Node 主要是通過 Cinder 連接的存儲後端（存儲設備），而 Network Node（Neutron） 通常是具有路由等一些網關功能的節點（網路設備）

同時，我們應該認識到 OpenStack 是一個不斷發展的系統，所以 OpenStack 的架構是演進的，舉個例子來說明這個問題：

（1）OpenStack E 版本有 5 個組件，其中：

Compute 是 Nova；Image 是 Glance，為 Nova 提供鏡像存儲服務；Object 是提供 Object 存儲服務的 Swift；Dashboard 是我們平時說的 Horizon；Identity 是 Keystone；

（2）OpenStack F版本則有 7 個組件：

有這七個組件就可以搭出一個相對完整的雲計算環境，其中 Heat、Sahala 是可選的；相對 E 版本，新增加的兩個組件分別是 Block Storage - Cinder 和 Network - Neutron，這兩個組件和 Glance，Swift 之間沒有直接的聯繫，實際上是從 Compute Network 和 Compute Volume 發展出來的。

Neutron 組件並沒有直接的去替換 Compute Network，它是一個相對獨立的，也是非常著名的 SDN 的一個項目，它為 Compute 提供網路連接，提供網路的資源管理這樣一些服務，Block Storage（也就是 Cinder）為 Compute 提供塊存儲服務，替換了 Compute Volume。

2 OpenStack 的 API

OpenStack 的邏輯關係是要各個組件之間的信息傳輸來實現的，而組件之間的信息傳輸主要是通過 OpenStack 之間相互調用 API 來實現的，作為一個操作系統，作為一個框架，它的 API 有著重要的意義。

我們要記住，OpenStack 的 API 是基於 HTTP 協議的，RESTful 的 Web API。

2.1 什麼是 REST

REST 全稱是：Representational State Transfer，即狀態表徵轉換。由 Fielding 博士（HTTP 協議的1.0 和 1.1 版本的主要設計者，Apache 伺服器軟體的作者之一，Apache 基金會的第一任主席）提出。REST 是通過操作資源的表徵來操作資源的狀態。

另外一種 Web 服務介面協議是 SOAP。

兩者的區別，RESTful Web API 的調用非常簡單，但是程序猿們平時編程的時候用 SOAP 可能是基於一些框架在去做，.Net，Java 的這些都已經很成熟了，我們感受不到底層機制的這種複雜性，而 REST 其實和 SOAP 比起來非常之簡潔的，另外一方面，REST 描述的是一種風格、一種架構、一種原則，所以它並沒有規定具體的實踐方式或者說協議。

目前最常見的實現方式就是基於 HTTP 協議實現的 RESTful Web API，我們的 OpenStack 裡面用的就是這種方式。REST 架構裡面對資源的操作，包括：獲取、創建、修改和刪除，正好對應著 HTTP 協議提供的 GET、POST、PUT 和 DELETE 方法，所以用 HTTP 來實現 REST 是比較方便的。

2.2 RESTful Web API 主要有以下三個要點：

（1）資源地址與資源的 URI，即所有資源都通過 URI 得到一個唯一的地址，以便在客戶端和伺服器之間傳輸狀態，比如：http://example.com/resources/。

（2）無狀態交互形式，指的是客戶端和伺服器之間的交互在請求之間是無狀態的，這種無狀態請求可以由任何可用伺服器回答，這十分適合雲計算之類的環境。客戶端可以緩存數據以改進性能。

（3）對資源的操作方法，Web 服務在該資源上所支持的一系列請求方法，比如：POST，GET，PUT，DELETE。

另外 OpenStack 還提供了另外一套 API 以兼容亞馬遜的 EC2，能夠方便應用在兩套系統之間做遷移。

3 OpenStack 組件之間的通信關係

OpenStack 組件之間的通信分為四類：

3.1 基於 HTTP 協議的通信

通過各項目的 API 建立的通信關係，基本上都屬於這一類，這些 API 都是 RESTful Web API，最常見的就是通過 Horizon 或者說命令行介面對各組件進行操作的時候產生的這種通信，然後就是各組件通過 Keystone 對用戶身份進行校驗，進行驗證的時候使用這種通信，還有比如說 Nova Compute 在獲取鏡像的時候和 Glance 之間，對 Glance API 的調用，還有比方說 Swift 數據的讀寫，也是通過這個 HTTP 協議的 RESTful Web API 來進行的。

3.2 基於 AMQP 協議（基於消息隊列協議）的通信

基於 AMQP 協議進行的通信，主要是每個項目內部各個組件之間的通信，比方說 Nova 的 Nova Compute 和 Scheduler 之間，然後 Cinder 的 Scheduler 和 Cinder Volume之間。

需要說明的是，Cinder 是從 Nova Volume 演化出來的，所以 Cinder 和 Nova 之間也有通過 AMQP 協議的通信關係，由於 AMQP 協議進行通信也屬於面向服務的架構，雖然大部分通過 AMQP 協議進行通信的組件屬於同一個項目，但是並不要求它們安裝在同一個節點上，給系統的橫向擴展帶來了很大的好處，可以對其中的各個組件分別按照他們負載的情況進行橫向擴展，因為他們不在一個節點上，分別用不同數量的節點去承載它們的這些服務。

（ AMQP 是一種協議，多用於業務系統，例如 PLM，ERP、MES 等進行數據交換。這是個應用層的開放標準，為面向消息的中間件設計。基於此協議的客戶端與消息中間件可傳遞消息，並不受客戶端/中間件不同產品，不同的開發語言等條件的限制。）

3.3 基於資料庫連接（主要是 SQL 的通信）的通信

通過資料庫連接實現通信，這些通信大多也屬於各個項目內部，也不要求資料庫和項目其它組件安裝在同一個節點上，它也可以分開安裝，還可以專門部署資料庫伺服器，把資料庫服務放到上面，之間通過基於 SQL 的這些連接來進行通信。OpenStack 沒有規定必須使用哪種資料庫，雖然通常用的是 MySQL。

3.4 Native API（基於第三方的 API）的通信

出現在 OpenStack 各組件和第三方的軟硬體之間，比如說，Cinder 和存儲後端之間的通信，Neutron 的 agent 或者說插件和網路設備之間的通信，這些通信都需要調用第三方的設備或第三方軟體的 API，我們稱為它們為 Native API，那麼這個就是我們前面說的基於第三方 API 的通信。

4 OpenStack 的部署架構

前面談到的各種架構基本上都是屬於軟體上的邏輯架構，但是 OpenStack 是個分散式的系統，就得解決從邏輯架構到物理架構的映射的問題，也就是 OpenStack 的各個項目、組件按什麼方式安裝到實際的伺服器節點上去，實際的存儲設備上，如何通過把它們通過網路連接起來，這就是 OpenStack 的部署架構。

OpenStack的部署分為:

（1）單節點部署，通常是用於學習或者是開發；

（2）多節點部署，即集群部署。

OpenStack 的部署架構不是一成不變的，而是根據實際的需求設計不同的實施方案。

在實際生產過程中，我們首先要對計算、網路、存儲所需要的資源進行規劃，雖然說我們現在用的雲計算技術，它比傳統的 IT 架構在資源規劃方面的困難和工作量要小一些，但是還是需要有一個規劃，這裡學習了解一下基本的和複雜的兩種集群部署架構。

4.1 簡單部署架構

這是一個最基本的生產環境所需要的 OpenStack 的部署情況。

（1）關於 Nova 的部署：

Nova-Compute 是控制虛擬機的，是控制和管理虛擬機的，所以必須部署在計算節點上，而 Nova 的其它幾個服務則應該部署在控制節點上，特別需要強調一點，Nova-Compute 和 Nova-Conducter 一定不能部署在同一個節點上，把這兩個分開就是為了解耦。

（2）關於 Neutron 的部署：

Neutron 的一些插件或 Agent 需要部署在網路節點和計算節點上，而其他的部分，比如說 Neutron Server 可以部署在控制節點上。

需要注意的是：

有些服務可以直接部署在 Controller 節點上或者說是直接部署在控制節點上，但是特別需要說明的一點是：Nova 和 Neutron 這兩個組件必須採用分散式部署。

4.2 複雜部署架構

需要掌握三個要點：

（1）規模較大的情況下，把各種管理服務部署到不同的伺服器上。

把這些服務拆開部署到不同的節點上，甚至要把同 一個服務的不同組件也拆開部署，比如說可以把 Nova 的資料庫給獨立拎出來部署成一個 MySQL 資料庫集群，還有 Cinder 裡面的 Scheduler 和 Volume 可以部署到不同的節點上，實際上因為 Swift 項目具有一定的獨立性，所以 Swift 本身就有跨地域部署的生產環境，規模非常之大，跨地域部署，所以它的服務的可用性極高，自然有這種栽培的特性，可以提供 極高可用性和數據持久性 的對象存儲服務。於是乎，很容易的對 OpenStack 的這些服務進行橫向擴展，對 OpenStack 整個系統做橫向擴展，這些讓 OpenStack 具有比較高的負載能力，可以達到一個比較大的規模。所有的這些都得益於 OpenStack 設計的時候採用了 SO 吻合的面向服務的架構，就是 SOA 架構，具體到每個組件如何進行分散式的部署，如何進行橫向擴展。

（2）出於高可用的考慮

生產環境中，通常會把 OpenStack 的同一個服務部署到不同的節點上，形成雙機熱備或者多機熱備的高可用集群。（或者用負載均衡集群）。

（3）在複雜的數據中心環境中，還有很多第三方服務

比方說 LDAP 服務、DNS 服務等等，考慮如何與第三方服務進行對接和集成。比如說，我們可能需要使用 OPEN LDAP 伺服器來作為 Keystone 的認證和健全的後端，這些一般是在管理網路中去完成的。

4.3 三種網路和四種節點

最後，根據實際需要設計不同的實施方案，下面解釋一下 「三種網路和四種節點」

（1）管理網路 + 存儲網路 + 服務網路

—管理網路，是 OpenStack 的管理節點或者說是它的管理服務對其它的節點去進行管理的這樣一個網路，他們之間有 「不同組件之間的 API 調用，虛擬機之間的遷移」 等等；

—存儲網路，是計算節點訪問存儲服務的網路，包括向存儲設備裡面讀寫數據的流量基本上都需要從存儲網路走；

—服務網路，是由 OpenStack 去管理的虛擬機對外提供服務的網路，伺服器上通常都是一台伺服器上帶好幾塊網卡，好幾塊網口，我們可以給各個網路做隔離。隔離的好處是，它們的流量不會交叉，比方說我們在讀寫存儲設備的時候，可能在存儲網路上的流量特別大，但是它不會影響到我們這些節點對外提供服務，同樣，在我們做虛擬機遷移的時候可能在管理網路上它的數據流量會非常大，但是它同樣不會影響到我們這些計算節點對存儲設備的讀寫性能。

（2）四種節點

—控制節點：就是 OpenStack 的管理節點，OpenStack 的大部分服務都是運行在控制節點上的，比如說 Keystone 的認證服務，虛擬機鏡像管理服務 Glance 等等；

—計算節點，計算節點指的是實際運行虛擬機的節點；

—存儲節點，提供對象存儲服務，提供對象存儲的 Swift 的節點或者是 Swift 集群的 Proxy 節點，也可以是其它服務的存儲後端；

—網路節點，實現網關和路由的功能。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！