Openstack 入門2

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 的認證和健全的後端，這些通常是在管理網絡中去完成的。