OpenStack入門之基礎元件

一、OpenStack 入門 之 基礎知識

二、OpenStack 入門 之 基本元件

三、OpenStack 入門 之 各元件解析（基礎）

四、OpenStack 入門 之 各元件解析（進階）

五、OpenStack 入門 之 實際操作

六、OpenStack 入門 之 擴充套件話題

七、OpenStack 入門 之 若干討論

寫在前面

學習目標：

• 瞭解 OpenStack 各元件的邏輯關係；
• 瞭解 OpenStack 的各元件的通訊和部署關係；
• 瞭解 OpenStack 的工作流程；

本次筆記的內容有：

• OpenStack 元件間的邏輯關係；
• OpenStack 的API；
• OpenStack 元件間的通訊關係；
• OpenStack 中幾種不同的儲存；
• OpenStack 的工作流程；
• OpenStack 的部署架構；

OpenStack 各元件之間的關係有：邏輯關係，通訊關係，部署關係…

1. OpenStack元件之間的邏輯關係

OpenStack 是一個不斷髮展的系統，所以 OpenStack 的架構是演進的，舉個例子：

E 版本有5個元件

Compute 是 Nova；Image 是 Glance（為 Nova 提供映象儲存服務）；Object 是提供 Object 儲存服務的 Swift；Dashboard 是我們平時說的 Horizon；Identity 是 Keystone；

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 有著重要的意義。

基於 HTTP 協議，RESTful Web API；

[ 什麼是 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 是比較方便的。

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

1. 資源地址與資源的 URI。比如：http://example.com/resources/
2. 傳輸資源的表現形式。指的是 Web 服務接受與返回的網際網路媒體型別，比如：JSON，XML 等，其中 JSON 具有輕量級的特點，移動網際網路的飛速發展輕量級的協議非常受歡迎，JSON 得到了廣泛的應用
3. 對資源的操作。Web 服務在該資源上所支援的一系列請求方法，比如：POST,GET,PUT,DELETE

下面以 OpenStack Swift 的介面作為一個例子來說明：

首先，用 curl 命令訪問一個 http 服務
crul -i -X GET http://storage.clouddrive.com/v1/my_account?format=json\ -H 
"X-Auth-User:jdoe" -H "X-Auth-Key:jdoepassword"

返回結果：

它是一個 HTTP 響應的頭部，有 Account 的細節資訊，包括這個 Account 有多少個 Container 有多少個 Object，佔用了多少位元組的儲存空間等等

然後是 JOSN 格式的內容，列出了這個 Account 下面的 Container

[ 呼叫及除錯 API 的幾種方式：]

• 第一種方式：curl 命令（linux 下傳送 HTTP 請求並接受響應的命令列工具），這種方式其實用的比較少，比較麻煩
• 第二種方式：比較常用的 OpenStack 命令列客戶端，每一個 OpenStack 專案都有一個 Python 寫的命令列客戶端
• 第三種方式：用 Firefox 或 Chrome 瀏覽器的 REST 的客戶端（圖形介面的，瀏覽器外掛）
• 第四種方式：用 OpenStack 的 SDK，可以不用手動寫程式碼傳送 HTTP 請求呼叫 REST 介面，還省去了一些管理諸如 Token 等資料的工作，能夠很方便地基於 OpenStack 做開發，那麼 OpenStack 官方提供的是 Python 的 SDK，當然還有第三方提供的 SDK 比如說支援 Java 的著名的 Jclouds，還有支援 Node.js、Ruby、.Net 的等等

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

3. OpenStack元件間的通訊關係

[ OpenStack 元件之間的通訊分為四類：]

• 基於 HTTP 協議
• 基於 AMQP 協議（基於高階訊息佇列協議）
• 基於資料庫連線（主要是 SQL 的通訊）
• Native API（基於第三方的 API）

有一張圖需要了解一下：

Compute Node 是實際執行虛擬機器的節點； Block Storage Node 主要是 Cinder 連線的儲存後端（儲存裝置）； Network Node 通常是具有路由等一些閘道器功能的節點（網路裝置）。

[ 基於 HTTP 協議進行通訊：]

通過各專案的 API 建立的通訊關係，基本上都屬於這一類，這些 API 都是 RESTful Web API，最常見的就是通過 Horizon 或者命令列介面對各元件進行操作的時候產生的這種通訊，然後就是各元件通過 Keystone 對使用者身份進行校驗的時候使用這種通訊，還有比如說 Nova Compute 在獲取映象的時候對 Glance API 的呼叫，還有比方說 Swift 資料的讀寫，也是通過這個 HTTP 協議的 RESTful Web API 來進行的。

[ 基於高階訊息佇列協議：]

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

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

（ AMQP 是一種協議，OpenStack 沒有規定它是用什麼實現，我們經常使用的是 Private MQ，實際上使用者也可以根據自身的情況選擇其它的訊息中介軟體。）

[ 基於 SQL 的通訊：]

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

[ 通過 Native API 實現通訊：]

出現在 OpenStack 各元件和第三方的軟硬體之間，比如說，Cinder 和儲存後端之間的通訊，Neutron 的 agent 或者說外掛和網路裝置之間的通訊，這些通訊都需要呼叫第三方的裝置或第三方軟體的 API，我們稱它們為 Native API，就是前面說的基於第三方 API 的通訊。

4. OpenStack幾種不同的儲存

[ OpenStack的儲存服務分為三種：Glance、Swift、Cinder ]

• Glance（映象儲存）是一個映象儲存管理服務，本身不具備儲存的功能；
• Cinder （塊儲存）提供塊儲存的介面；本身也不提供資料的儲存，後面也需要接一個儲存的後端，像 EMC 的散裝置，華為的儲存裝置，NetApp 的儲存裝置可以做它的後端。還有一個比較火的開源分散式儲存叫 Ceph，Ceph 也提供塊儲存服務，也可以用來作為 Cinder 的後端。Cinder 的作用就是為 OpenStack 提供塊儲存的介面，有個很重要的功能叫卷管理功能，虛擬機器並不直接去使用儲存裝置（並不直接去使用後端的儲存系統），使用的是虛擬機器上的塊裝置（卷 Volume），實際上 Cinder 就是建立和管理這些 Volume 並且把它掛載到虛擬機器上。Cinder 是從 Nova Volume 裡面獨立出來的，獨立出來之後很受各種儲存廠商的歡迎，可以通過寫 Cinder Driver 的形式把自己的儲存裝置納入到 OpenStack 的生態圈裡面去。
• Swift （物件儲存）提供的是物件儲存服務，具有像亞馬遜 IWSS3 的特點，提供通過RESTful API 的方式去訪問資料，這樣做是為了解決兩個問題：（1）我們可以直接去訪問一個儲存，而不需要在通過自己開發的 Web 伺服器去做一次資料的轉發，否則對伺服器的負載來說是一種壓力。（2）在我們的大資料時代，當資料量特別大的時候，如果我們用檔案系統就會出現問題，檔案的數量激增以後，儲存的效能會急劇下降，而物件儲存實際上則是解決這個問題的，物件儲存拋棄了那種目錄樹的結構，用一種扁平化的結構去管理資料。Swift 實際上只有三層結構，即 Account、Container、Object。Object 就是最終的那個資料了，就是檔案，前面有兩級管理，一級是 Container 容器，它把 Object 放到容器裡面，然後再上面一級是 Account，是和賬戶去關聯的，Container 相當於是把這些 Object 做了分類，用 Account 去跟賬戶關聯起來。

[ 三種儲存的概念：檔案儲存、塊儲存、物件儲存 ]

• 檔案儲存：有 POSIX 介面或者 POSIX 相容的介面的，可以被認為它是一個檔案系統，比較典型的分散式檔案系統有像 Glance 的 FS，Hadoop 裡的 HDFS
• 塊儲存：電腦上的一個盤格式化之後是一個檔案系統，那麼在格式化之前是一個塊裝置，也就是塊儲存，實際上我們在資料中心裡面，像 EMC 的很多裝置，像華為的一些叫作 SAN 的裝置，像 NetApp 的一些裝置，如果是散儲存一般來說就是提供塊儲存的；
• 物件儲存：物件儲存的典型代表是亞馬遜的 AWS S3，它的介面不是 POSIX，也不是像一塊硬碟那樣作為一個塊儲存的介面，是通過 RESTful Web API 去訪問的，對於應用開發者來說優勢在於可以很方便的去訪問儲存裡面存的資料，物件儲存裡存的資料通常叫做 Object，實際上它就是 File，但是物件儲存裡面為了和檔案系統做一個區別，便被叫作物件 Object

5. OpenStack工作流程

這裡以建立一個虛擬機器為例來了解 OpenStack 是如何工作的，下面的圖是 OpenStack 建立虛擬機器整個工作過程：

[ 下面進行簡要的文字說明：]

總共有 28 個步驟，主要是和 Nova 相關的，實際上在 Keystone Glance Neutron Cinder Swift 等元件內部還有很多小步驟，加起來恐怕有50多個步驟。現在主要看這28個基本步驟，這裡的大部分資訊發表在來自 ilearnstack 網站上的一篇文章，在 Dashboard 上建立虛擬機器的過程.

1. 第 1 步，首先，Horizon 或者是命令列工具向 keystone 發起了 REST 呼叫，並且把使用者名稱和密碼發給 Keystone；
2. 第 2 步，Keystone 對接收到的使用者名稱及其密碼進行驗證，並生成 Token，這個 Token 在後面為其他元件傳送 REST 呼叫時使用；
3. 第 3 步，Horizon 或者命令列客戶端把啟動虛擬機器操作或者在命令列上敲的 nova boot 命令，包括上一步說的 Token 轉化成 RESTful Web API 傳送給 Nova-API；
4. 第 4 步，Nova-API 收到請求之後向Keystone 驗證客戶端發來的 Token 的合法性，這就是說 Nova 和 Keystone 之間有一個互動了；
5. 第 5 步，Keystone 驗證完 Token 之後，將使用者的角色和許可權返回給 Nova，也是返回到 Nova-API；
6. 第 6 步，是 Nova-API與 Nova Database 之間有一個互動的過程；
7. 第 7 步，是 Nova Database 為新的虛擬機器例項建立一條記錄，並且將結果返回給 Nova-API。
8. 第 8 步，Nova-API 通過 AMQP 向 Nova-Scheduler 傳送一個同步遠端呼叫請求，這裡的同步遠端呼叫請求實際上是 AMQP 協議裡的叫作 rpc.call request，這地方是同步呼叫，同步呼叫的意思就是，它傳送完請求以後就一直在等待，一直等待到這個佇列（訊息佇列）裡面給它返回來結果，所以就是在等待獲得新的虛擬機器例項的條目和 Host ID，Host ID 是虛擬機器將來要啟動的寄主機的 ID；
9. 第 9 步，Nova-Scheduler 從訊息佇列裡面取出請求，因為中間有 AMQP 元件在這，所以 Nova 的其他各個元件之間的互動基本上都是通過 AMQP 來做的，實際上 AMQP 的實現用的是 RabbitMQ；
10. 第 10 步，是 Nova-Scheduler 與 Nova Database 進行互動並且挑選出一臺適合的宿主機來啟動這個虛擬機器，（挑選的過程很複雜）；
11. 第 11 步，是 Nova-Scheduler 通過 AMQP 返回給前面的 Nova-API 的呼叫，並且將宿主機的 ID 傳送給它；
12. 第 12 步，是 Nova-Scheduler 通過訊息佇列，向 Nova-Compute 發出一個在上述宿主機上啟動虛擬機器的非同步呼叫請求，這裡是非同步呼叫請求（Nova-Schduler 把請求傳送到訊息佇列裡面以後它就返回了，就不用再等待這個請求給它返回結果，在 AMQP 裡面是 rpc-cast 這個請求）；
13. 第 13 步，是 Nova-Compute 從佇列裡面取該請求；
14. 第 14 步，是 Nova-Compute 通過訊息佇列向 Nova-Conducter 傳送一個 rpc.call 同步呼叫請求獲取虛擬機器的資訊（包括宿主機的 ID，虛擬機器配置資訊有記憶體大小、CPU 配置、硬碟大小等等）；
15. 第 15 步，Nova-Conducter 從佇列裡取出上述請求；
16. 第 16 步，Nova-Conducter 與資料庫進行互動；
17. 第 17 步，Nova-Conducter 返回前面 Nova-Compute 請求的這些資訊；
18. 第 18 步，Nova-Compute 從訊息佇列裡面取出 Nova-Conducter 返回的資訊，也就是同步呼叫到這裡就結束了；
19. 第 19 步，是 Nova-Compute 向 Glance-API 發出帶有 Token 的 REST 請求，去請求這個映象資料；
20. 第 20 步，是 Glance-API 向 Keystone 去驗證這個 Token 的合法性，在前面有類似的步驟（Nova 去驗證 Token 的合法性，其實在 19 步和 20 步兩步裡面還有很多細節比如說，如果是 Swift 來儲存 Glance 的映象，中間還有 Swift 和 Glance 之間的互動，Glance 內部也有一些互動）；
21. 第 21 步，是 Nova-Compute 獲取映象的後設資料，前面幾步相當於把映象的後設資料給獲取了，知道了映象是從哪裡來的長什麼樣的。後面的 22 到 24 步這幾步是為虛擬機器去準備網路，還是以 Nova-Compute 為中心的；
22. 第 22 步，是 Nova-Compute 向 Neutron API 傳送帶有 Token 的 REST 請求進行網路配置，並獲得分配給待建立的這個虛擬機器的 IP 地址，這中間其實 Neutron 做了一些工作，也有很多細節；
23. 第 23 步，Neutron Server 向 Keystone 去驗證 Token 的合法性；
24. 第 24 步，Nova-Compute 就獲得了網路的配置資訊，後面這幾步是給虛擬機器去準備虛擬機器的硬碟，也就是前面提到過的卷儲存或塊儲存；
25. 第 25 步，是 Nova-Compute 呼叫 Cinder-API 的 RESTful 介面給虛擬機器掛載卷，也就是塊裝置或者是虛擬硬碟；
26. 第 26 步，跟上面的 Glance 和 Neutron 類似，Cinder-API 也要向 Keystone 去驗證，這個Token 的合法性；
27. 第 27 步，Nova-Compute 就會得到這個虛擬機器的塊儲存的資訊；經過 27 個步驟，這樣建立一個虛擬機器所需要的各種資訊和條件才正式地準備完畢；
28. 第 28 步，Nova-Compute 去呼叫 Hypervisor 或者 Libvirt 的介面建立虛擬機器，當然，在 Libvirt 或者說是 Hypervisor 去建立虛擬機器的過程中，內部也是一個非常複雜的過程；

[ 虛擬機器建立的四個階段：]

1. scheduling
2. networking
3. block_ device_mapping
4. spawing

[ 幾種通訊關係的體現：]

• 各個元件 API 之間的呼叫，這就屬於 HTTP 通訊；
• Nova 和 Neutron 內部各個元件的通訊屬於通過 AMQP 協議的通訊；
• 中間頻繁的讀寫資料庫的操作屬於資料庫連線進行通訊的；
• Nova 與 Hypervisor 或者說 Libvirt 互動屬於通過 Native API 即第三方介面去進行通訊的，還有一個就是在給虛擬機器準備 Volume 的過程中 Cinder 還需要和儲存裝置進行互動，這中間也需要用到 Native API 或者是第三方介面；

6. OpenStack的部署架構

前面已經從邏輯關係、通訊關係分析了OpenStack 各元件之間的關係，並且也介紹了 OpenStack 的 API 和儲存。

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

[ OpenStack的部署分為：]

• 單節點部署，通常是用於學習或者是開發
• 多節點部署（叢集部署）

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

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

6-1. 簡單部署架構

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

[ 關於三種網路和四種節點：]

（1）綠色的管理網路 + 藍色的儲存網路 + 黃色的服務網路

• 管理網路 是 OpenStack 的管理節點（管理服務）對其它的節點進行管理的網路，它們之間有 “不同元件之間的 API 呼叫，虛擬機器之間的遷移” ；
• 儲存網路 是計算節點訪問儲存服務的網路，向儲存裝置裡面讀寫資料的流量基本上都需要從儲存網路走；
• 服務網路 是由 OpenStack 管理的虛擬機器對外提供服務的網路，伺服器上通常都是一臺伺服器上帶好幾塊網路卡/網口，我們可以給各個網路做隔離。隔離的好處是，它們的流量不會交叉，比方說我們在讀寫儲存裝置的時候，可能在儲存網路上的流量特別大，但是它不會影響到我們這些節點的對外提供服務，同樣，在我們做虛擬機器遷移的時候可能在管理網路上的資料流量會非常大，但是它同樣不會影響到我們這些計算節點對儲存裝置的讀寫效能。

（2）四種節點：

• 控制節點（OpenStack 的管理節點，OpenStack 的大部分服務都是執行在控制節點上的，比如說 Keystone 的認證服務，虛擬機器映象管理服務 Glance 等等）
• 計算節點（計算節點指的是實際執行虛擬機器的節點）
• 儲存節點（提供物件儲存服務，提供物件儲存的 Swift 節點或是 Swift 叢集的 Proxy 節點，也可以是其它服務的儲存後端）
• 網路節點（實現閘道器和路由的功能）

有些服務可以直接部署在 Controller 節點上，但是需要說明的是： Nova 和 Neutron 這兩個元件必須採用分散式部署。對於 Nova：Nova-Compute 是控制虛擬機器的，是控制和管理虛擬機器的，所以必須部署在計算節點上，而 Nova 的其它幾個服務則應該部署在控制節點上，特別強調，Nova-Compute 和 Nova-Conducter 一定不能部署在同一個節點上，把這兩個分開就是為了解耦。 對於 Neutron：Neutron 的一些外掛或 Agent 需要部署在網路節點和計算節點上，而其他的部分，比如說 Neutron Server 可以部署在控制節點上

6-2. 複雜部署架構

[ 需要掌握三個要點：]

1. 規模較大的情況下，把各種管理服務部署到不同的伺服器上。把這些 服務拆開部署 到不同的節點上，甚至要把同 一個服務的不同元件也拆開部署，比如說可以把 Nova 的資料庫給獨立擰出來部署成一個 MySQL 資料庫叢集，還有 Cinder 裡面的 Scheduler 和 Volume 可以部署到不同的節點上，實際上因為 Swift 專案具有一定的獨立性，所以 Swift 本身就有跨地域部署的生產環境，規模非常大又可以跨地域部署，所以它服務的可用性極高，有栽培的特性，可以提供 極高可用性和資料永續性 的物件儲存服務。於是乎，很容易對 OpenStack 的服務進行橫向擴充套件乃至對 OpenStack 的整個系統做橫向擴充套件。這些讓 OpenStack 具有比較高的負載能力，可以達到一個比較大的規模。所有的這些都得益於 OpenStack 設計的時候採用了 SO 吻合的面向服務的架構，就是 SOA 架構，具體到每個元件如何進行分散式的部署，如何進行橫向擴充套件。
2. 出於高可用的考慮，生產環境中我們會把 OpenStack 的同一個服務部署到不同的節點上，形成雙機熱備或者多機熱備的高可用叢集。（或者用負載均衡叢集）。
3. 在複雜的資料中心環境中，還有很多第三方服務，比方說 LDAP 服務、DNS 服務等等，考慮如何與第三方服務進行對接和整合。比如說，我們可能需要使用 OPEN LDAP 伺服器來作為 Keystone 的認證和健全的後端，這些一般是在管理網路中去完成的。