一、 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.
二、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 的接口作為一個例子來說明：
1 首先，用 curl 命令訪問一個 http 服務 2 crul -i -X GET http://storage.clouddrive.com/v1/my_account?format=json\ -H
3 "X-Auth-User:jdoe" -H "X-Auth-Key:jdoepassword"
返回結果：
它是一個 HTTP 響應的頭部，有 Account 的細節信息，包括這個 Account 有多少個 ，Container 有多少個 Object，占用了多少字節的存儲空間等等。
然后是 JOSN 格式的內容，列出了這個 Account 下面的 Container
調用及調試 API 的幾種方式：
1 第一種方式：curl 命令（linux 下發送 HTTP 請求並接受響應的命令行工具），這種方式其實用的比較少，比較麻煩 2 第二種方式：比較常用的 OpenStack 命令行客戶端，每一個 OpenStack 項目都有一個 Python 寫的命令行客戶端 3 第三種方式：用 Firefox 或 Chrome 瀏覽器的 REST 的客戶端（圖形界面的，瀏覽器插件） 4 第四種方式：用 OpenStack 的 SDK，可以不用手動寫代碼發送 HTTP 請求調用 REST 接口，還省去了一些管理諸如 Token 等數據的工作，能夠很方便地基於 OpenStack 做開發，
那么 OpenStack 官方提供的是 Python 的 SDK，當然還有第三方提供的 SDK 比如說支持 Java 的著名的 Jclouds，還有支持 Node.js、Ruby、.Net 等等
OpenStack 還提供了另外一套 API 兼容亞馬遜的 EC2，能夠方便應用在兩套系統之間做遷移。
三、OpenStack組件間的通信關系
OpenStack 組件之間的通信分為四類：
1 基於 HTTP 協議 2 基於 AMQP(Advanced Message Queuing Protocol，一個提供統一消息服務的應用層標准高級消息隊列協議) 協議（基於消息隊列協議） 3 基於數據庫連接（主要是 SQL 的通信） 4 Native API（基於第三方的 API）
有個概念需要了解一下：
1 Compute Node 是實際運行虛擬機的節點 2 Block Storage Node 主要是 Cinder 連接的存儲后端（存儲設備） 3 Network Node 通常是具有路由等一些網關功能的節點（網絡設備）
3-1. 基於HTTP協議進行通信
通過各項目的 API 建立的通信關系，基本上都屬於這一類，這些 API 都是 RESTful Web API，最常見的就是通過 Horizon 或者說命令行接口對各組件進行操作的時候產生的這種通信，
然后就是各組件通過 Keystone 對用戶身份進行校驗，進行驗證的時候使用這種通信，還有比如說 Nova Compute 在獲取鏡像的時候和 Glance 之間，對 Glance API 的調用，
還有比方說 Swift 數據的讀寫，也是通過這個 HTTP 協議的 RESTful Web API 來進行的。
3-2. 基於高級消息隊列協議
基於 AMQP 協議進行的通信，主要是每個項目內部各個組件之間的通信，比方說 Nova 的 Nova Compute 和 Scheduler 之間，然后 Cinder 的 Scheduler 和 Cinder Volume之間。
需要說明的是，Cinder 是從 Nova Volume 演化出來的，所以 Cinder 和 Nova 之間也有通過 AMQP 協議的通信關系，由於 AMQP 協議進行通信也屬於面向服務的架構，
雖然大部分通過 AMQP 協議進行通信的組件屬於同一個項目，但是並不要求它們安裝在同一個節點上，給系統的橫向擴展帶來了很大的好處，
可以對其中的各個組件分別按照他們負載的情況進行橫向擴展，因為他們不在一個節點上，分別用不同數量的節點去承載它們的這些服務。
（ AMQP 是一種協議，OpenStack 沒有規定它是用什么實現，我們經常使用的是 Private MQ，實際上用戶也可以根據自身的情況選擇其它的消息中間件。）
3-3. 基於SQL的通信
通過數據庫連接實現通信，這些通信大多也屬於各個項目內部，也不要求數據庫和項目其它組件安裝在同一個節點上，它也可以分開安裝，還可以專門部署數據庫服務器，
把數據庫服務放到上面，之間通過基於 SQL 的這些連接來進行通信。OpenStack 沒有規定必須使用哪種數據庫，雖然通常用的是 MySQL
3-4. 通過Native API實現通信
出現在 OpenStack 各組件和第三方的軟硬件之間，比如說，Cinder 和存儲后端之間的通信，Neutron 的 agent 或者說插件和網絡設備之間的通信，
這些通信都需要調用第三方的設備或第三方軟件的 API，我們稱為它們為 Native API，那么這個就是我們前面說的基於第三方 API 的通信。
四、OpenStack幾種不同的存儲
OpenStack的存儲服務分為三種：
Glance：
Glance（鏡像存儲）是一個鏡像存儲管理服務，本身不具備存儲的功能；
Swift：
Swift （對象存儲）提供的是對象存儲服務，同樣的具有像亞馬遜 IWSS3 的特點，提供通過RESTful API 的方式去訪問數據，
這樣做是為了解決兩個問題：第一個，我們可以直接去訪問一個存儲，而不需要在通過自己開發的 Web 服務器去做一次數據的轉發，否則對服務器的負載來說是一種壓力。
第二個，在我們的大數據時代，當數據量特別大的時候，如果我們用文件系統就會出現問題：文件的數量激增以后，存儲的性能會急劇下降，而對象存儲實際上則是解決這個問題的，
對象存儲拋棄了那種目錄樹的結構，用一種扁平化的結構去管理數據。Swift 實際上只有三層結構，即 Account、Container、Object。Object 就是最終的那個數據了，
就是文件，前面有兩級管理，一級是 Container 容器，它把 Object 放到容器里面，然后再上面一級是 Account，是和賬戶去關聯的，Container 相當於是把這些 Object 做了分類，
用 Account 去跟賬戶關聯起來。
Cinder：
Cinder （塊存儲）提供塊存儲的接口；本身也不提供數據的存儲，后面也需要接一個存儲的后端，像 EMC 的散設備，華為的存儲設備，NetApp 的存儲設備可以做它的后端。
還有一個比較火的開源分布式存儲叫 Ceph，Ceph 也提供塊存儲服務，也可以用來作為 Cinder 的后端。Cinder 的作用就是為 OpenStack 提供塊存儲的接口，
有個很重要的功能叫卷管理功能，虛擬機並不直接去使用存儲設備（並不直接去使用后端的存儲系統），使用的是虛擬機上的塊設備（卷 Volume），
實際上 Cinder 就是創建和管理這些 Volume 並且把它掛載到虛擬機上。Cinder 是從 Nova Volume 里面獨立出來的，獨立出來之后很受各種存儲廠商的歡迎，
可以通過寫 Cinder Driver 的形式把自己的存儲設備納入到 OpenStack 的生態圈里面去。
三種存儲的概念：
文件存儲：
有 POSIX 接口或者 POSIX 兼容的接口，就可認為它是一個文件系統，比較典型的分布式文件系統有像 Glance 的 FS，Hadoop 里的 HDFS
塊存儲：
電腦上的一個盤格式化之后是一個文件系統，那么在格式化之前是一個塊設備，也就是塊存儲，實際上我們在數據中心里面，像 EMC 的很多設備，
像華為的一些叫作 SAN 的設備，像 NetApp 的一些設備，如果是散存儲一般來說就是提供塊存儲的；
對象存儲：
對象存儲的典型代表是亞馬遜的 AWS S3，它的接口不是 POSIX，也不是像一塊硬盤那樣作為一個塊存儲的接口，是通過 RESTful Web API 去訪問的，
對於應用開發者來說優勢在於可以很方便的去訪問存儲里面存的數據，對象存儲里存的數據通常叫做 Object，實際上它就是 File，
但是對象存儲里面為了和文件系統做一個區別，便被叫作對象 Object。
五、 OpenStack工作流程
這里以創建一個虛擬機為例來了解 OpenStack 是如何工作的，下面的圖是 OpenStack 創建虛擬機整個工作過程：
下面進行簡要的文字說明：
1 登錄界面或命令行通過RESTful API向keystone獲取認證信息。 2 keystone通過用戶請求認證信息，並生成auth-token返回給對應的認證請求。 3 界面或命令行通過RESTful API向nova-api發送一個boot instance的請求（攜帶auth-token）。 4 nova-api接受請求后向keystone發送認證請求，查看token是否為有效用戶和token。 5 keystone驗證token是否有效，如有效則返回有效的認證和對應的角色（注：有些操作需要有角色權限才能操作）。 6 通過認證后nova-api和數據庫通訊。 7 初始化新建虛擬機的數據庫記錄。 8 nova-api通過rpc.call向nova-scheduler請求是否有創建虛擬機的資源(Host ID)。 9 nova-scheduler進程偵聽消息隊列，獲取nova-api的請求。 10 nova-scheduler通過查詢nova數據庫中計算資源的情況，並通過調度算法計算符合虛擬機創建需要的主機。 11 對於有符合虛擬機創建的主機，nova-scheduler更新數據庫中虛擬機對應的物理主機信息。 12 nova-scheduler通過rpc.cast向nova-compute發送對應的創建虛擬機請求的消息。 13 nova-compute會從對應的消息隊列中獲取創建虛擬機請求的消息。 14 nova-compute通過rpc.call向nova-conductor請求獲取虛擬機消息。（Flavor） 15 nova-conductor從消息隊隊列中拿到nova-compute請求消息。 16 nova-conductor根據消息查詢虛擬機對應的信息。 17 nova-conductor從數據庫中獲得虛擬機對應信息。 18 nova-conductor把虛擬機信息通過消息的方式發送到消息隊列中。 19 nova-compute從對應的消息隊列中獲取虛擬機信息消息。 20 nova-compute通過keystone的RESTfull API拿到認證的token，並通過HTTP請求glance-api獲取創建虛擬機所需要鏡像。 21 glance-api向keystone認證token是否有效，並返回驗證結果。 22 token驗證通過，nova-compute獲得虛擬機鏡像信息(URL)。 23 nova-compute通過keystone的RESTfull API拿到認證k的token，並通過HTTP請求neutron-server獲取創建虛擬機所需要的網絡信息。 24 neutron-server向keystone認證token是否有效，並返回驗證結果。 25 token驗證通過，nova-compute獲得虛擬機網絡信息。 26 nova-compute通過keystone的RESTfull API拿到認證的token，並通過HTTP請求cinder-api獲取創建虛擬機所需要的持久化存儲信息。 27 cinder-api向keystone認證token是否有效，並返回驗證結果。 28 token驗證通過，nova-compute獲得虛擬機持久化存儲信息。 29 nova-compute根據instance的信息調用配置的虛擬化驅動來創建虛擬機。
注：
keystone
User：指使用Openstack service的用戶，可以是人、服務、系統，但凡使用了Openstack service的對象都可以稱為User。 Project(Tenant)：可以理解為一個人、或服務所擁有的 資源集合 。在一個Project(Tenant)中可以包含多個User，每一個User都會根據權限的划分來使用Project(Tenant)中的資源。比如通過Nova創建虛擬機時要指定到某個Project中，在Cinder創建卷也要指定到某個Project中。User訪問Project的資源前，必須要與該Project關聯，並且指定User在Project下的Role。 Role：用於划分權限。可以通過給User指定Role，使User獲得Role對應的操作權限。Keystone返回給User的Token包含了Role列表，被訪問的Services會判斷訪問它的User和User提供的Token中所包含的Role。系統默認使用管理Role admin和成員Role _member_ Policy：OpenStack對User的驗證除了OpenStack的身份驗證以外，還需要鑒別User對某個Service是否有訪問權限。Policy機制就是用來控制User對Tenant中資源(包括Services)的操作權限。對於Keystone service來說，Policy就是一個JSON文件，默認是/etc/keystone/policy.json。通過配置這個文件，Keystone Service實現了對User基於Role的權限管理。 Token：是一個字符串表示，作為訪問資源的令牌。Token包含了在 指定范圍和有效時間內 可以被訪問的資源。EG. 在Nova中一個tenant可以是一些虛擬機，在Swift和Glance中一個tenant可以是一些鏡像存儲，在Network中一個tenant可以是一些網絡資源。Token一般被User持有。 Credentials：用於確認用戶身份的憑證 Authentication：確定用戶身份的過程 Service：Openstack service，即Openstack中運行的組件服務。 Endpoint：一個可以通過網絡來訪問和定位某個Openstack service的地址，通常是一個URL。比如，當Nova需要訪問Glance服務去獲取image 時，Nova通過訪問Keystone拿到Glance的endpoint，然后通過訪問該endpoint去獲取Glance服務。我們可以通過Endpoint的region屬性去定義多個region。Endpoint 該使用對象分為三類： admin url –> 給admin用戶使用，Post：35357
internal url –> OpenStack內部服務使用來跟別的服務通信，Port：5000
public url –> 其它用戶可以訪問的地址，Post：5000 創建完service后創建API EndPoint. 在openstack中，每一個service都有三種end points. Admin, public, internal。 Admin是用作管理用途的，如它能夠修改user/tenant(project)。 public 是讓客戶調用的，比如可以部署在外網上讓客戶可以管理自己的雲。 internal是openstack內部調用的。
三種endpoints 在網絡上開放的權限一般也不同。Admin通常只能對內網開放，public通常可以對外網開放internal通常只能對安裝有openstack對服務的機器開放。
一個實例：
1 用戶alice登錄keystone系統（password或者token的方式），獲取一個臨時的token和catalog服務目錄
（v3版本登錄時，如果沒有指定scope，project或者domain，獲取的臨時token沒有任何權限，不能查詢project或者catalog）。 2 alice通過臨時token獲取自己的所有的project列表。 3 alice選定一個project，然后指定project重新登錄，獲取一個正式的token，同時獲得服務列表的endpoint，用戶選定一個endpoint，
在HTTP消息頭中攜帶token，然后發送請求（如果用戶知道project name或者project id可以直接第3步登錄）。 4 消息到達endpoint之后，由服務端（nova）的keystone中間件（pipeline中的filter：authtoken）向keystone發送一個驗證token的請求。
（token類型：uuid需要在keystone驗證token，pki類型的token本身是包含用戶詳細信息的加密串，可以在服務端完成驗證） 5 keystone驗證token成功之后，將token對應用戶的詳細信息，例如：role，username，userid等，返回給服務端（nova）。 6 服務端（nova）完成請求，例如：創建虛擬機。 7 服務端返回請求結果給alice。
cinder：
cinder主要組成:
1 Cinder-api 是 cinder 服務的 endpoint，提供 rest 接口，負責處理 client 請求，並將 RPC 請求發送至 cinder-scheduler 組件。 2 Cinder-scheduler 負責 cinder 請求調度，其核心部分就是 scheduler_driver, 作為 scheduler manager 的 driver，負責 cinder-volume 具體的調度處理，
發送 cinder RPC 請求到選擇的 cinder-volume。 3 Cinder-volume 負責具體的 volume 請求處理，由不同后端存儲提供 volume 存儲空間。
neutron
neutron主要組成：
1.Neutron-server可以理解為一個專門用來接收Neutron REST API調用的服務器，然后負責將不同的rest api分發到不同的neutron-plugin上。 2.Neutron-plugin可以理解為不同網絡功能實現的入口，各個廠商可以開發自己的plugin。Neutron-plugin接收neutron-server分發過來的REST API，向neutron database完成一些信息的注冊，然后將具體要執行的業務操作和參數通知給自身對應的neutron agent。 3.Neutron-agent可以直觀地理解為neutron-plugin在設備上的代理，接收相應的neutron-plugin通知的業務操作和參數，並轉換為具體的設備級操作，以指導設備的動作。當設備本地發生問題時，neutron-agent會將情況通知給neutron-plugin。 4.Neutron database，顧名思義就是Neutron的數據庫，一些業務相關的參數都存在這里。 5.Network provider，即為實際執行功能的網絡設備，一般為虛擬交換機（OVS或者Linux Bridge）。
虛擬機創建的四個階段：
1 scheduling 2 networking 3 block_ device_mapping 4 spawing
幾種通信關系的體現：
1 各個組件 API 之間的調用，這就屬於 HTTP 通信； 2 Nova 和 Neutron 內部各個組件的通信屬於通過 AMQP 協議的通信； 3 中間頻繁的讀寫數據庫的操作屬於數據庫連接進行通信的； 4 Nova 與 Hypervisor 或者說 Libvirt 交互屬於通過 Native API 即第三方接口去進行通信的，還有一個就是在給虛擬機准備 Volume 的過程中 Cinder 還需要和存儲設備進行交互，
這中間也需要用到 Native API 或者是第三方接口；
六、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 的認證和健全的后端，這些一般是在管理網絡中去完成的。
轉：http://blog.csdn.net/q123_xi/article/details/78550273?locationNum=10&fps=1