OpenStack 入門3

OpenStack 的各組件的架構和功能

Nova 組件解析

負責虛擬機建立、管理和銷燬、提供計算資源服務的 Nova；

經過 Nova 能夠實現：

• 訪問虛擬機
• 建立和啓動虛擬機

Nova 是怎麼運做的？除了圖形界面和命令行以外，咱們還須要怎樣去配置和使用 Nova？

1-1. Nova 的架構

Nova-console 和 Nova-consoleauth 這兩個組件，主要是爲了讓用戶可以經過 VNC 客戶端或 SPICE 客戶端來訪問虛擬機的界面。推薦使用 SPICE 客戶端，由於SPICE 客戶端提供了不少高級的特性，比方說，對 USB 設備的支持，SPICE 還支持多屏顯示等等功能，這些特性在桌面虛擬化環境中很是有用處，在桌面雲環境中也很是有用，但使用 SPICE 就須要對 nova.conf 文件作一些修改，好比：

// nova.conf的修改：
[spice]
enabled = True [default] vnc_enabled = False

1-2. 虛擬機的調度機制

• 第一個方面：placement（放置）。 把虛擬機放在哪一個物理機上啓動
• 第二個方面：migration（遷移）。 從哪一個物理機遷移到哪一個物理機上

Nova 有一個組件叫做調度器，Scheduler 直譯過來就是調度器，它實際上只完成了 placement 的工做，migration 其實是由其它組件來協同完成的。

在 OpenStack 的上下文裏，特指這個運行的 nova-compute 服務的機器才叫作宿主機。

1-3. Nova 對虛擬機的調度機制

經過修改 nova.conf 文件修改調度器的配置，nova 默認的這個調度器成爲 filter scheduler，這種調度器分兩步來決定虛擬機的位置。第一步先通過一些 filters，filters 的每一種都表明着一種限制條件，經過這些 filters 選出來一些可用的 host，做爲第二步的輸入；第二步是稱重，其實是對宿主機進行排序。

下面舉個例子進行說明，這裏有一個很是經常使用的 filter 叫做 Ramfilter，Ram：設置超配比例。

[ Nova 對虛擬機的調度機制：]

（1）把全部的 filters 都用上：

scheduler_available_filters = nova.scheduler.filters.all_filters

（2）選擇其中的一部分：

scheduler_default_filter = RetryFilter, AvailabilityZoneFilter, RamFilter, ComputeFilter，ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter

（3）用 Python 實現本身的 filter，老師用 RamFilter 作的例子如圖所示：

對虛擬機進行排序（稱重 weighting）

兩種選擇：

• 但願負載儘量均衡
• 但願負載儘量集中，用盡量少的 host 來承載咱們的虛擬機，咱們使用的 host 就會比較少，那麼運維的成本包括用電、製冷的費用都會比較低

Swift 組件解析

提供對象存儲服務的分佈式存儲 Swift；

[ Swift 的特色：]

1. Swift 歷史比較長
2. Swift 比較獨立（和其餘組件的耦合度比較低；不依賴於第三方的軟件或設備，甚至不依賴於 Keystone 作用戶的認證和受權；）
3. Swift 是作對象存儲的（這裏的對象存儲就是指，採用 RESTful 接口，支持直接從互聯網訪問存儲系統進行數據的讀寫。對象存儲每每採用扁平的數據組織形式，在文件數量不少的狀況下不至於出現明顯的性能衰減，也就是咱們說對象存儲的概念哦

OpenStack 其它的不少項目實現具體功能的時候每每須要依賴於第三方的軟件或設備，好比說 Nova 啓動虛擬機、管理虛擬機就必須經過一個第三方的 Hypervisor，還有 Cinder 提供塊存儲服務必須經過第三方的存儲設備。Swift 就不一樣了，Swift 能夠從上面的 RESTful 接口把堆棧一直管到底，以致於管到最後把數據到底放在哪一個服務器的哪一個硬盤上均可以作到，整個是完整的存儲系統，如今有專門基於 Swift 實現的存儲系統例如 swiftstack；

swift 提供的對象存儲 和 ceph這類分佈式存儲

[ Swift 數據的組織形式：]

扁平的組織形式，Swift 的數據組織形式分爲三級，只有這三級

• Account
• Container
• Object

與能夠分 N 多層可以不斷有文件夾的建立的數據組織形式不同，Swift 的整個存儲結構從邏輯上劃分爲一個個的 Account，而後每一個 Account 底下再分爲一個個的 Container，每一個 Object 其實是放在每一個 Container 底下的。

[ Swift 的接口：]

與 OpenStack 的其它組件的接口很相似，也是 RESTful Web API，總共有四個部分組成。第一個是 HTTP 操做（GET/PUT/DELETE/POST）；第二個是認證信息（主要是身份信息）；第三個是指示資源地址的 URL（具體到 Swift，應該包含存儲系統的域名/地址加上存儲數據的 Account、Container、Object 的整個信息的完整的 URL）；第四個是數據與元數據。

例子：

crul -i -X GET 

https://storage.clouddrive.com/v1/my_account?format=json\-H

"X-Auth-User:jdoe" -H "X-Auth-Key:jdoepassword"

storage.clouddrive.com 是對象存儲的域名或者說地址，接着取 my_account 下面的 Container 的信息，後面帶的是用戶的認證信息 username 和 password 。先看下方返回結果：

根據上圖我能夠發現，API 調用之後返回的結果 Response 主要分爲兩段：1.頭部。有兩個要點，一個是它給出了這個 Account 下面 Container 的數量是 2，而後這個 Account 裏面總共用了多大的存儲空間，用了多少的字節或者說存了多少字節的數據進去，這裏是 14。接着看下面的內容：

根據上圖我能夠發現，這是一個 json 的返回形式，把每個 Container 都列出來了，能夠看到第一個 Container 裏面沒有 Object，因此它佔用的字節數也是 0。

[ Swift 的軟件架構：]

如圖所示：

從上面下來是 Swift API，經過 Proxy Server 來實現，Proxy Server 左右兩邊分別連了兩個東西：一個是作身份認證用的，每每是 Keystone，右邊是一個 Cache 服務，這個 Cache 不去緩存實際的 Object 的數據，緩存的主要是用戶的身份信息，別的會緩存一點其餘的東西，不會去緩存數據，因此 Swift 是沒有緩存的，原生設計就是沒有緩存的；從 Proxy Server 下來會有三個 ring：Object Ring，Container Ring 和 Account Ring，ring 是一致性 HASH 實現。（一致性 HASH 是什麼？ 分佈式存儲系統中爲了把數據分佈到各個節點上，用的一種數據結構就是一致性 HASH，後續會詳細展開探討。）下面是實際提供存儲服務的進程或者說 Server，有 Object Server，Container Server 和 Account Server，有一個統一的稱呼：Storage Server，對這些信息的默認的存儲方式都是三副本。

[ 搭建 Swift 時須要的注意事項：]

Swift 的部署須要注意哪些？一個典型的 Swift 部署像圖裏畫的樣子：

圖所示的是一個小型的 Swift 集羣典型配置，想讓 Swift 進行良好的工做，須要注意一些容易被人去忽視和常常犯錯的地方，避免對 Swift 產生一些錯誤的認識，誤認爲 Swift 可靠性不行或性能不行，注意下面五個點：

1. 採用的是全對等架構，就是每一個節點每一個 Server 都是同樣的，有 Proxy Server，有 Object Server， 有 Container Server 等等都是同樣的。（實際上 Swift 從軟件到部署都是一個全對等的概念在裏面，是 Swift 架構的最突出的特色之一，讓 Swift 可以很好的去作橫向擴展，沒有單點故障）。
2. 怎麼把服務器組織起來呢？實際上，上面它有一個 Load Banlancer，可以把服務器（其實是 Proxy Server）組成一個集羣，Load Banlancer 可以把用戶的這些請求給它分配到各個實際的服務節點上。
3. 每一個服務器是一個zone Swift 是要求分 zone 的，要把服務器存儲區域給隔離開，而後把這些副本放到不一樣的 zone 裏面去，因此這地方小規模集羣通常都是讓每一個 Server 做爲一個 zone。
4. 做爲小規模的部署，服務器的數量最少是5個（官方推薦的最小集羣，達到比較好的效果）。
5. 不要用虛擬機（存數據的地方都不可能說是用虛擬化去作支撐的），不要用 RAID（用服務器用盤陣的時候常常會對它作 RAID，可是作完 RAID 之後會對咱們的 Swift 帶來一些性能上不可預知的結果，Swift 自己具備數據管理的機制）。

[ Swift2.0的新功能：]

存儲策略：讓用戶可以自由的選擇數據的存儲策略

Swift 的存儲策略一部分由搭建存儲系統的 Deployer 決定，另一部分是由使用存儲系統的 Client 決定的，用戶在這個裏面以 Container 爲力度，能夠去指定這個存儲策略。

Cinder 組件解析

提供塊存儲服務的 Cinder；

傳統數據中心的存儲設備常常聽到 SAN 或者盤陣這些詞彙，是經過網絡鏈接給服務器提供存儲空間的一類設備。硬盤對應了一個術語：塊設備，傳統存儲也叫塊存儲。SAN 是典型的塊存儲，還有一類存儲設備叫做 NUS。硬盤或者 LUN 是掛在服務器上的。

若是是在虛擬化環境之下，也能夠像雲硬盤同樣掛載到虛擬機上，做爲虛擬機的一個硬盤，也就是虛擬機的一個卷 Volume。Cinder 是提供塊存儲服務的，有時候也會說 Cinder 提供卷管理或者說是提供卷服務的。

SAN 設備與網絡的兩種鏈接主要有兩種形式：第一種是 Fibre Channel（光纖通道，簡稱 FC），另一種是 iSCSI（是基於以太網協議的）。

若是是 FC，須要在服務器上裝上 HBA 卡，用專用的光纖給它連到存儲設備上。若是是 iSCSI 的話，走的是以太網協議和 IP 協議，因此不須要專用存儲的網絡鏈接了，用 iSCSI 的愈來愈多。

3-1 Cinder的組成架構

如上圖所示，Cinder 的架構仍是很是簡單的，裏面有 Cinder 的 API，是用來提供 RESTful API 的，供客戶端或者是其它組件來訪問；中間還有一個 database，一樣還有消息隊列，Cinder 比較核心的兩個組件：左邊的 Cinder Scheduler 調度器，右邊的 Cinder Volume。

一般狀況下，若是咱們使用了多個存儲設備來作 Cinder 的後端，一般須要運行多個 Volume 的實例，如圖示意：

Scheduler 的任務是在有訪問請求的時候、有建立 Volume 請求的時候選擇經過哪一個 Cinder Volume 實例來建立卷，這就是 Scheduler 和 Volume 的分工。

重點分析一下 Volume，特別須要注意的一點是數據的流向，與 Swift 的區別是比較大的，Swift 對它的操做不只僅是經過 Swift Proxy Server 提供的 RESTful API 進行操做，它的數據也是經過 RESTful API 走的，咱們要把數據放在 Swift 裏面或者從 Swift 裏把數據拿出來，都經過 RESTful Web API。可是在 Cinder 不同，Cinder API 基本上只能提供一些操做和管理功能，是直接經過 FC/iSCSI 傳輸數據到服務器。那 Volume 的做用究竟是什麼呢？數據不會經過 Volume 去走，也不會經過 RESTful API。實際上 Volume 裏邊有一個模塊叫 Volume Driver，這個 driver 針對每個存儲設備都不同，也被稱爲 Volume 插件，這個插件每每是由存儲設備的廠商提供的。Volume 的核心主要是做用在這個 Driver 上，driver 的做用是什麼？Driver 跟咱們一般的單機的操做系統的驅動的含義不同，這裏的 Volume Driver 驅動主要是至關於一個適配的功能，把後端的設備的接口適配成 Cinder 的統一接口。

[ 補充：什麼是軟件定義存儲？]

隨着咱們數據中心的存儲設備數量和種類以及上層應用的種類愈來愈多，上層應用對存儲的需求也各不相同，因此就出現一個問題，怎麼樣去把這些設備給整合起來從而怎麼樣去更好的服務於上層應用，因而就出現了軟件定義存儲的概念。看一張從 EMC 官網上獲得的圖：

軟件定義存儲，一方面是爲了隱藏底下的硬件的異構性，不論咱們用的是什麼硬件，不論咱們用的是什麼規模的硬件，不論咱們用的是什麼型號的硬件，不論咱們用的是哪一個廠商的硬件，只要軟件定義存儲這一套軟件支持，它對上層隱藏了底層的異構性；另一方面是對上層應用的支持，提供了多樣化存儲的接口，好比說常常提到的 Hadoop 的 HDFS，還有提供對象存儲的接口，還有塊存儲的接口，用來支持不一樣的應用。有了這樣一個系統，那麼加存儲設備的人和構建底下這些存儲基礎設施的人就不用去擔憂上層應用會怎麼樣，只須要按照如今存儲規模的需求和性能的需求往上加存儲設備就好了，或者說只要擴大如今的存儲設備的容量就好了，上層應用也不用擔憂底下怎麼樣去適應。只要暴露接口就好了。

OpenStack 的存儲最主要的兩個組件是 Swift（提供的是對象存儲的接口）和 Cinder(提供了一堆 driver，Volume 裏面嵌入的，這些 driver 能夠調用不一樣的存儲設備，只要有 driver 就能夠把存儲設備給鏈接上，實際上就起到了屏蔽底層硬件異構性的做用。第二，Cinder 提供的是塊存儲的接口)，實際上也就是說咱們如今在網頁上這個層面，至少已經支持了最經常使用的兩種存儲接口，正好對應了軟件定義存儲的兩個方面。基於 OpenStack 咱們實際上是能夠作一個軟件定義存儲的系統出來的。

Swift 提供對象存儲時，對底層硬件是否有異構性限制。

 

Neutron 組件解析

軟件定義網絡項目 Neutron；

Nrutron 又被稱爲 OpenStack networking。

有一個概念叫做層（Tier/Layer）。兩種層有什麼區別呢？先說一下傳統的網絡，傳統數據中心的網絡是分爲幾個級別的，首先是服務器接入第一級交換機叫做接入交換機，接入交換機每每是在一個機架的頂部（因此也被稱爲架頂交換機 TOR），多是有堆疊的好比說是兩個交換機來實現的，以下圖所示最上部分的兩個交換機。而後，會接入一個叫做匯聚層的交換機（匯聚交換機），每每是放在一排機架的頂頭位置，這一層每每被叫作匯聚層。而後接入的是核心交換機，把匯聚交換機連起來的交換機就是核心交換機，核心交換機是數據中心很是大的網絡節點，每每也不僅一個。

傳統中心的數據網絡分爲接入層、匯聚層和核心層，也叫做三個層次（Tier）。現在的網絡對三層網絡作了演進。

可是在 OpenStack 裏，層不是指的 Tier，而是協議棧的層，也就是 Layer。根據 ISO 的網絡模型，實際上網絡是分爲七個 Layer，OpenStack 主要關注的是第二和第三層。第二層是數據量層 Datalink，第三層是網絡層 Network。交換機 Switches 是工做在數據量層的典型設備，而路由器 Routers 是典型的工做在網絡層的，Neutron 主要關注這兩層。

假如沒有 OpenStack Neutron ，虛擬化世界的網絡是什麼樣子的？ 會使用虛擬網橋，是一個二層設備，是軟件實現的網橋，不存在物理信號的問題，被認爲是一個虛擬的跑在服務器寄主機內部的交換機，把虛擬機都連在這個交換機上，以下拓撲圖：

若是僅僅是作一個虛擬化的環境，問題卻是不大，但若是放在雲的環境上就會出現問題了，由於雲涉及到租戶之間流量隔離的問題，網橋沒法知足這種需求，網橋徹底是一個連通的，跟一個普通的交換機沒啥區別。那麼，說一說 Nova-network 又是怎麼樣的狀況呢？

Nova-network 在之前的網橋的基礎上，加了一個模塊，所以能夠有兩種工做模式。第一種是：Flat DHCP 工做模式。能夠提供像 DHCP 同樣的功能。

第二種是：基於 VLAN 的隔離。可使用 VLAN 的方式把各類租戶隔離開，勉強知足了雲的需求，在一個對網絡要求不是很高的簡單雲計算環境中使用 Nova-Network 就能夠了。

事實上咱們還有其它的一些需求，好比咱們要實現一個比較大的二層，要實現對流量的控制，Nova-network 就不能知足要求了。那麼，Neutron 在一種很是廣泛的環境中跟 Nova-network 有多大的區別呢？

[ Neutron 有的功能：]

• 提供 VLAN 的隔離
• 提供軟件定義網絡 SDN（好比：L2-in-L3 的隧道，像 VXLAN、GRE 隧道；還支持 OpenFlow 協議）
• 支持第三方的 API 擴展
• 支持第三方的 Plugin 擴展

咱們能夠開發本身的組件、插件放在 Neutron 生態裏，與 Cinder 很是相似。

Neutron 支持租戶建立本身的虛擬網絡，看一個例子如圖：

圖裏有兩個租戶，每一個租戶建立了本身的網絡，有本身的路由器，租戶之間的網絡是隔離的，而且每一個租戶還能夠定義本身網絡的拓撲，這點很重要，復拓撲（Rich Topologies）是開發 Neutron 項目的重要目的。

在傳統的物理網絡架構中，會但願對每層應用都互相使用相對隔離的網絡，而後咱們能夠在上面對每層進行負載均衡或者是作一些集羣的方案，可是在虛擬世界中，若是咱們使用 Nova-network 很難實現。而 Neutron 誕生之後，這個問題就獲得瞭解決。後續學習的 Heat 在工做的過程當中就利用了 Neutron 的功能，是 Neutron 的一個很好的應用案例。

PS：構建一個基於三層架構的Web服務

• 第一層：Web 頁面服務器
• 第二層：應用服務器
• 第三層：數據庫服務器

Horizon 組件解析

提供基於 Web 的一個 GUI 的 Horizon；

Horizon 提供可視化的 GUI 圖形界面。讓用戶去操做這些項目使用的各類資源。Horizon 的內部架構是怎麼樣的？咱們若是要作二次開發，應該怎麼去作？瞭解 Horizon 能夠不妨先去了解 Python 的一個 Web 開發框架 Django。

[ 內部分爲三個層次：]

1. Dashboard
2. PanelGroup
3. Panel

每一組可視化的界面都是 PanelGroup，每個 Dashboard 在 Django 裏都是一個 App，OpenStack 的文件夾裏的 openstackdashboard 文件夾裏有一個 settings.py 文件，裏面有一個變量叫 INSTALLEDAPP 定義了目前存在的這些 dashboard

官方的社區版裏面通常有四個 dashboard

1. openstack_dashboard.dashboards.project // 普通用戶 2. openstack_dashboard.dashboards.admin // 管理員 3. openstack_dashboard.dashboards.settings // 右上角設置面板 4. openstack_dashboard.dashboards.router // 通常是看不見的

 

Glance 組件解析

提供虛擬機鏡像管理和存儲服務的 Glance；

虛擬機鏡像存儲服務的，典型的對象存儲應用

[ Glance 的架構：]

Glance API Server 提供 RESTful API，全部的訪問請求會經過它 Glance Registry Server 組件對鏡像進行註冊，還能夠提供鏡像檢索服務 Glance 可使用不一樣的存儲後端，有亞馬遜的 S3 Store，有 Swift 對象存儲，有 HTTP Store，有 Filesystem Store（Glance 本地的一個文件存儲）

PS：對象存儲這種扁平的數據組織結構的存儲方式必定是未來的一個趨勢，爲何？人在使用計算機的時候會使用一級一級的目錄去把文件塞到不一樣的目錄底下，創建一個樹狀的結構是爲了方便咱們本身去查找。而在寫程序的時候，是經過數據庫去管理這些數據，經過索引去管理這些元數據，並不須要一級一級的目錄結果，Glance 經過 Registry Server 去找到這些鏡像、檢索這些鏡像，因此咱們的程序真正須要的是一個地址加上一個 ID，或者是一個地址加上一個 key。那麼，對象存儲正好就是地址加上 ID。因此說，對象存儲會逐漸取代分佈式文件系統，成爲 Server 端的主流。（PS：固然，塊存儲是被替代不了的）不知道爲何。

[ Glance的緩存機制：]

把 Glance API Server 作橫向擴展，作一個負載均衡的集羣，下面再轉到實際的存儲後端去，可是可能某些鏡像會特別的有不少訪問，這樣的話某一個點的壓力仍是會很大，因而就有了緩存機制，每一個經過 Glance 到達服務器的 Server 端的鏡像，都會緩存到 API Server 上，注意，若是咱們有多個 API Server，隨着用戶訪問請求的增多，被常常訪問的那個同一個鏡像會在每個 API Server 上都有一個，醬紫的話，在後續再有訪問請求的時候就會直接用 API Server 上的鏡像文件，而不會再去訪問到存儲後端上來，這個機制對終端用戶來講是透明的，終端用戶並不清楚這個 Glance 服務獲取的鏡像究竟是存在哪裏的。

[ 緩存管理須要注意的幾個地方：]

• 對 Cache 總量大小的限制（週期性的運行，glance-cache-pruner --image_cache_max_size=*）
• 要清理一些狀態異常的 Cache 文件（glance-cache-cleaner）
• 若是新加了一個 API Server 到負載均衡的集羣環境裏，新的 API Server 上沒有緩存，因此還提供了預取某些熱門鏡像到新增的 API 節點中的機制（glance-cache-manage --host=<HOST> queue-image <IMAGE_ID>）PS：這也是在雲環境中常常會去使用的一種方法
• 咱們能夠手動刪除緩存鏡像來釋放空間

Keystone 組件解析

提供身份認證和受權的 Keystone；

在 OpenStack 裏面 Keystone 有兩個做用。

• 第一個是：權限管理（用戶的建權、受權；涉及到的概念有用戶、租戶、角色），租戶是一組用戶的集合，租戶能夠是一個企業一個部門一個小組等等。租戶與用戶之間每每是多對多的關係。
• 第二個是：服務目錄（服務、端點），OpenStack 的每一個服務須要在 Keystone 裏註冊之後才能提供給用戶去使用，端點 Endpoint 能夠理解爲服務暴露出來的訪問點，，每個端點都對應一個服務的訪問接口的實例。

關於角色 Role，安全領域有一個叫做基於角色的訪問控制，Keystone 也是這樣的一種安全機制，Role 是 Keystone 的訪問機制裏面的核心。那麼對於 Role 怎麼去操做呢？它最重要的命令就是 user-role-add，簡單來講這個命令就是指定某個用戶具備某個角色。還有一個很是重要的用途，那就是實現用戶和租戶多對多的關係。下面舉個例子怎麼樣去實現用戶和租戶之間多對多關係的操做方法。

// 建立租戶tenant1
# keystone tenant-create --name tenant1 --enabled true // 建立另一個租戶tenant2 # keystone tenant -create --name tenant2 --enabled true // 建立兩個用戶 user1 和 user2 和登陸密碼 # keystone user -create --name user1 --tenant -id <tenant-id of tenant1> --pass password --enabled true # keystone user -create --name user2 --tenant -id <tenant-id of tenant2> --pass password --enabled true // user-role-add 命令，這裏的-user-id 其實是 上面的 user2 的 id，-tenant-id 其實是前面咱們的tenant1 的 id，將 user2 加到 tenant1 裏面，tenant1 就對應了兩個用戶：user1 和 user2，user2 就對應了兩個tenant：tenant1 和 tenant2 # keystone user-role-add -user-id 7b32f4fc92704947802d2eca95edff0d -role-id 2493283f09c1475198f2337a47aa398f -tenant-id 0647347fa21d4221b0197cd282465a00

Role 在 Keystone 裏面是一個關鍵的東西。

有一個問題，Keystone 是否解決了 OpenStack 的雲安全問題呢？其實遠遠不夠，它只是實現了對 OpenStack 各類服務的訪問權限的控制。Keystone 不能和雲安全劃等號的。公有云上常見的安全防禦手段有：

• 安全訪問（OpenStack 會暴露出來一些 API 或 Endpoint，客戶是經過 HTTP 協議訪問的，實際上咱們應該容許經過 HTTPS 協議訪問）
• 內置防火牆功能（FWIIS，Firewall as a Service，用戶能夠經過配置內置防火牆讓雲上的和環境或者應用更安全）
• 加密數據存儲（雲的管理員能夠獲取雲存儲上的文件，因此用戶的文件須要加密讓雲的管理員沒法查看、檢索、分析，可是不是全部的客戶端都提供給用戶加密數據存儲的功能）
• 幫助用戶檢測安全情況（主動監測租戶的安全情況並給出提示，給出一些安全防禦的提示，甚至在出現嚴重安全問題的狀況下，會主動去把租戶的服務下線以保證整個雲的安全）

8. 總結

Nova

• nova-console
• nova-consoleauth
• nova-compute
• nova-conductor
• nova-scheduler

Swift

• 對象存儲的特色
• 強調 Swift 的全對等架構
• 極高的可擴展性
• Swift 集羣部署中的注意事項

Cinder

• 提供塊存儲服務或者說卷服務
• 經過 Cinder-volume 裏面的 Driver 支持不一樣的存儲設備

Neutron

• 租用能夠制定本身的 rich toplogy 的虛擬網絡
• 經過各類 agent 和 plugin 實現具體的功能並和第三方設備、軟件對接

Horizon

• 三級代碼組織形式

Glance

• 掌握了 Glance 的鏡像
• 對 Glance 作負載均衡

Keystone

• 經過 Role 進行權限管理
• 經過 Role 將同一個用戶分配到不一樣的 tenant 中

能夠說，OPENSTACK不只是一種產品，更是一種模式。