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

一、OpenStack 入門 之 基礎知識

二、OpenStack 入門 之 基本元件

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

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

五、OpenStack 入門 之 實際操作

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

七、OpenStack 入門 之 若干討論

寫在前面

學習目標：

• 掌握 OpenStack 的各元件的架構和功能

本次筆記的內容有：

• Nova 元件解析
• Swift 元件解析
• Cinder 元件解析
• Neutron 元件解析
• Horizon 元件解析
• Glance 元件解析
• Keystone 元件解析

是常用的 7 個元件：

• 負責虛擬機器建立、管理和銷燬、提供計算資源服務的 Nova；
• 提供物件儲存服務的分散式儲存 Swift；
• 提供塊儲存服務的 Cinder；
• 提供虛擬機器映象管理和儲存服務的 Glance；
• 軟體定義網路專案 Neutron；
• 提供身份認證和授權的 Keystone；
• 提供基於 Web 的一個 GUI 的 Horizon；

OpenStack 每半年進行一次整合釋出，版本號從 A 開始，按字母表順序逐步提升，每個整合釋出版本都包括若干個專案，A 版本是 Nova 和 Swift。

1. 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 就會比較少，那麼運維的成本包括用電、製冷的費用都會比較低

2. Swift元件解析

[ Swift 的特點：]

1. Swift 歷史比較長
2. Swift 比較獨立（和其他元件的耦合度比較低；不依賴於第三方的軟體或裝置，甚至不依賴於 Keystone 做使用者的認證和授權；）
3. Swift 是做物件儲存的（這裡的物件儲存就是指，採用 RESTful 介面，支援直接從網際網路訪問儲存系統進行資料的讀寫。物件儲存往往採用扁平的資料組織形式，在檔案數量很多的情況下不至於出現明顯的效能衰減，也就是我們說物件儲存的概念哦

OpenStack 其它的很多專案實現具體功能的時候往往需要依賴於第三方的軟體或裝置，比如說 Nova 啟動虛擬機器、管理虛擬機器就必須通過一個第三方的 Hypervisor，還有 Cinder 提供塊儲存服務必須通過第三方的儲存裝置。Swift 就不同了，Swift 可以從上面的 RESTful 介面把堆疊一直管到底，以至於管到最後把資料到底放在哪個伺服器的哪個硬碟上都可以做到，整個是完整的儲存系統，現在有專門基於 Swift 實現的儲存系統例如 swiftstack

[ 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 為力度，可以去指定這個儲存策略。

3. 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 我們其實是可以做一個軟體定義儲存的系統出來的。

4. 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 頁面伺服器
• 第二層：應用伺服器
• 第三層：資料庫伺服器

5. 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 // 一般是看不見的

6. 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：這也是在雲環境中經常會去使用的一種方法
• 我們可以手動刪除快取映象來釋放空間

7. 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 中