NCTU CStack：OpenStack 與 Ceph 的整合與應用

國立交通大學

資訊科學與工程研究所

碩 士 論 文

NCTU CStack：OpenStack 與 Ceph 的整合與應用

NCTU CStack:An integration and application of

OpenStack and Ceph

研 究 生：蔡權昱

指導教授：蔡錫鈞 教授

NCTU CStack：OpenStack 與 Ceph 的整合與應用

NCTU CStack:An integration and application of

OpenStack and Ceph

研 究 生：蔡權昱

Student:Chuan-Yu Tsai

指導教授 ：蔡錫鈞

Advisor:Shi-Chun Tsai

國立交通大學

資訊科學與工程研究所

碩士論文

A Thesis

Submitted to Institute of Computer Science and Engineering

College of Computer Science

National Chiao Tung University

in partial Fulfillment of the Requirements

for the Degree of

Master

in

Computer Science

November 2012

Hsinchu, Taiwan, Republic of China

摘

要

雲端運算是近年來非常熱門的話題，隨著需要處理的資料愈來愈龐大，各個機構所設置

的資訊中心也愈來愈複雜。因此，關於資料如何安全的保存，以及硬體設備如何有效的

利用，也變成非常重要的議題。

在資料安全性方面，Ceph 為一新崛起的分散式儲存系統，設計之初即把把底層的硬

體離線維護視為常態，並不會因為小數量的機器故障而造成整個系統停擺，進而提供了

很好的資料安全性。

在硬體利用率方面，虛擬化是一個很好的解決方式。傳統的虛擬化軟體可以在一台

機器上開啟多台虛擬設備，但若要管理一堆虛擬機的集合，分配不同的虛擬機給不同的

單位使用，以及處理虛擬機與實體機的網路連線等，則非常麻煩。因此，虛擬化的主要

廠商皆推出了相對應的產品，如 VMware ESXi 搭配 vCenter 來建構虛擬化的資料中心，

或是 Microsoft Windows Server 的 Hyper-V 以及 Citrix XenServer 等，都可以快速的提供

企業自己的私有雲服務，但是昂貴的授權費用，以及對硬體設備的規格需求相對嚴苛的

限制，也讓不少機構望之卻步。

OpenStack 為近年由 NASA 和 Rackspace 共同開發的開放原始碼軟體，可提供任何

人建立免費的雲端運算服務。我們利用了 OpenStack 可快速建立私有雲的特性，搭配了

Ceph 分散式儲存系統，在交通大學資訊技術服務中心建立了一個名為 NCTU CStack 的

系統，提供免費且高度彈性化的校園雲端運算和雲端儲存服務。

本文包含了基本的 OpenStack 和 Ceph 配置與部署。我們提出新的虛擬機網路模式

(PHA)，讓運算節點可以使用私有 IP 提供服務，大量節省 IP 的消耗，並且在正常使用

情境下仍然保有 HA 模式的各種好處；另外使用 rgwauthAPI 來整合兩個系統上專案和

帳號的權限，讓 OpenStack 可對外提供相容 Amazon S3 協定的物件儲存服務。

Abstract

Recent years, cloud computing becomes a hot topic. With the rapid growth of information day

by day, the more complex data centers will be set by various institutions. Therefore, how to save

data safely and utilize hardware devices efficiently are important issues.

Ceph is a new brand of distributed file system. At the design phase, Ceph regards the fault

of underlying hardware as normal, and no need to shutoff the whole system when a few machine

is scheduled for maintenance offline, thus Ceph can quite ensure the safety of data.

Virtualization is a good way to improve the hardware utilization. Traditional virtualization

software can easily boot multiple virtual machines on a single server, however, it is hard to

man-age so many virtual machines, deal with the network connection between virtual machines and

different host servers. Hence all the major virtualization companies release corresponding

prod-ucts, such as using VMware ESXi with vCenter to construct the virtualization data center. The

other suits, for example Hyper-V role in Microsoft Windows Server and the Citrix XenServer,

can quickly provide enterprise private cloud services, but many institutions may flinch from

expensive licensing fees and stringent restrictions about hardware specifications.

OpenStack is an open source software which is developed by NASA and Rackspace at first.

Anyone can use OpenStack to create a free cloud computing services quickly. At last, we

estab-lish a private cloud named NCTU CStack system in NCTU ITSC. NCTU CStack is integrated by

OpenStack and Ceph storage backend, providing free, highly-flexible campus cloud computing

and storage services.

This thesis includes the basic configuration and deployment flow about OpenStack and

Ceph. We design the new networking mode(PHA), using PHA mode can greatly reduce the

consumption of public IP, and it works like HA mode in most scenario. Moreover, we use

rg-wauthAPI to integrate the authentication between OpenStack and Ceph, and make our system

support the object storage service which is Amazon S3 API compatible.

致 謝

時光荏苒，轉眼間碩士班生活已接近尾聲，從懵懂的大學生到有自己想法的研究

生，這段時間內因為有許多人的支持與協助，我才得以完成碩士論文研究。首先要謝謝

我的指導教授蔡錫鈞老師，老師的管理風格富有彈性，讓我自由選擇喜歡的研究主題，

做實務不忘理論，是我在您身上學習到的精神。研究過程中難免會遇到瓶頸，對於任何

研究上的需求，老師總是全力支援，從”要玩就玩真的”這句話中，我不斷被老師的熱

忱所感染，您的鼓勵是我持續向前的動力。學業之外，老師也時常關心學生在異鄉的起

居及家庭狀況，讓我這個外地遊子倍感溫馨。謝謝交大資訊技術服務中心俊憲學長及所

有幫助維護系統運作的工程師，因為有你們的幫忙，這篇論文才能順利完成。

很感謝在交大兩年裡，曾經幫助我的人，特別是實驗室裡每天生活在一起的大家。

特別謝謝名全學長聽我預報論文，教導我投影片製作技巧，並且處理實驗室的大小疑難

雜症，讓實驗室得以順利運作；雖然相處的時間很短，但也謝謝昶諄學長熱心地替剛進

實驗室的我指點迷津，開啟我的實驗室生活；謝謝李睿學長總是在我閱讀論文遭遇瓶頸

時替我理清演算法細節；謝謝旻錚學長總是在我報告問題回答不出來時解救我，並且總

是熱心的跟我討論及整理研究的可行方向。

也感謝一同互相幫忙兩年的宜謙，你總是可以跟我即時討論新的想法，給我許多不

錯的點子，恭喜我們順利走過這兩年，完成學業。實驗室的方智誼與邱韜瑋以及其他碩

一學弟們當然也不能忘記，你們的協助我銘記在心，真心祝福你們研究順利。

離家到新竹求學，婉馨的支持與陪伴是我前進的力量，因為有妳的歡笑聲，在我陷

入低潮時才能鼓勵我並使我重拾研究的熱情。最後，謹以此文獻給我摯愛的雙親。

目 錄

第一章 緒論... 1

1.1 研究背景與動機...

1

1.2 系統發展之目標與成果...

2

1.3 各章節介紹...

4

第二章 背景知識... 6

2.1 雲端運算...

6

2.2 OpenStack ...

7

2.3 Ceph ...

7

2.3.1

Ceph 服務 ...

8

2.4 指令碼說明... 10

第三章 系統架構... 11

3.1 CStack 系統 ... 11

3.2 Ceph 系統架構 ... 12

3.3 修改後的虛擬機網路架構... 13

第四章 CStack 系統安裝步驟 ... 18

4.1 Ceph 安裝細節 ... 18

4.1.1

Ceph 擴展方法 ... 19

4.2 OpenStack 安裝細節 ... 20

4.2.1

Controller 安裝步驟 ... 20

4.2.2

Glance 安裝步驟 ... 26

4.2.3

Nova-volume 安裝步驟... 29

4.2.4

Compute Workers 安裝步驟 ... 31

4.3 nova.conf... 37

第五章 Dashboard 與 RADOS gateway 的整合 ... 41

5.1 安裝 Radosgw... 41

5.1.1

安裝 Vanish... 42

5.2 Swift 的認證與授權... 44

5.2.1

rgwauthAPI ... 45

5.2.2

Dashboard Patches ... 46

第六章 Dashboard 操作介面 ... 55

6.1 專案頁面... 55

6.1.1

運算管理... 56

6.1.2

物件儲存... 62

6.2 管理者頁面... 64

6.3 設定... 66

6.3.1

憑證使用方法... 66

第七章 結論... 71

附錄 A Ceph 相關檔案 ... 76

附錄 B OpenStack 相關檔案 ... 87

表 目 錄

2.1

一個簡單的 Placement Rule 例子 . . . .

9

2.2

Ceph 提供了三種常見的網路儲存方式的解決方案 . . . .

9

3.1

傳統、傳統 HA 模式以及 PHA 模式的網路架構比較表 . . . .

16

圖 目 錄

1.1

CStack 部屬示意圖 . . . .

3

1.2

運算節點示意圖 . . . .

4

1.3

Ceph cluster 示意圖

. . . .

5

2.1

以此圖為例，圖中所標示數字為管理者定義每台 OSD 的權重 (Weight)，

因為 BetaSite1 的 OSD 容量為 A9r 的 2.5 倍，因此我們可以將此資訊寫進

Placement Rule 中，利用權重控制每台機器所存放的檔案大小，並控制

PG 的 Replica 需要放置一份到 BetaSite1，其餘兩份則存放至 A9r 中，避

免因為 BetaSite1 的 Switch 故障，使得有部分檔案暫時無法存取。 . . . .

8

3.1

CStack 系統概念圖 . . . .

12

3.2

CStack 系統佈署架構圖 . . . .

13

3.3

Ceph 與 OpenStack 關係圖

. . . .

14

3.4

虛擬機網路互動關係圖 (Provider View) . . . .

15

3.5

P-HA 網路模式下的三種使用情況：(1) 同專案的虛擬機之間的網路流量。

(2) 沒有公開 IP 的虛擬機往 Internet 的流量需經過 NAT。(3) 有公開 IP 的

虛擬機可直接與 Gateway 溝通。 . . . .

17

5.1

RADOS gateway 認證示意圖 . . . .

44

5.2

rgwauthAPI sequence diagram . . . .

45

6.1

登入首頁 http://openstack.nctu.edu.tw/ . . . .

55

6.2

專案：總覽 . . . .

56

6.3

專案：映像 & 快照 . . . .

57

6.4

專案：建立新虛擬機 & 配額使用情形 . . . .

58

6.5

專案：存取 & 安全性 . . . .

59

6.6

編輯安全性群組規則 . . . .

60

6.7

執行個體 & 容量 . . . .

61

6.8

上圖：容器頁面。下圖：Show Keys 頁面。 . . . .

62

6.9

上圖：在 CloudBerry Explorer 上建立帳號來存取我們的物件儲存服務。

下圖：使用 CloudBerry Explorer 的連線畫面。 . . . .

63

6.10 上圖：在 Gladinet Cloud Desktop Management Console 上建立帳號來存取

我們的物件儲存服務。下圖：使用 Gladinet 掛載好的磁碟 Y: 來列出容器

內的物件。 . . . .

64

6.11 管理者：所有執行個體列表

. . . .

65

6.12 管理者：專案列表 . . . .

65

6.13 管理者：屬於 CCIS 專案的使用者列表 . . . .

66

6.14 設定：更新使用者資料與密碼 . . . .

67

6.15 設定：下載 OpenStack RC 檔 . . . .

67

第 一 章

緒論

從第一台電腦被發明以來，人們使用電腦的習慣一直隨著科技演進而改變著。從早

期的 IBM 大型電腦 (Mainframe) 時期，使用者利用終端機連線回大型電腦工作，所有工

作都在遠端的大型電腦裡完成，僅有輸入輸出功能的終端機幾乎沒有任何運算能力。一

直到積體電路的出現，電腦主機的體積逐漸縮小，價格也越來越便宜，人們才開始負擔

得起購買自己的電腦。

二十世紀末，個人電腦 (Personal Compute) 運算能力越來越強，雖然各種軟體如雨

後春筍般被開發出來，但是可以執行的程式和可以處理的資料規模，還是受限於個人電

腦的規格等級。此外，這時的網路也尚在萌芽階段，頻寬與普及率仍不足以方便的使

用，文件檔案的分享依然大量利用可移除式裝置，不同電腦之間檔案的同步與保存成為

一個熱門的議題。

二十一世紀，情況又大大改變了，網路已成為大部分人日常生活中不可或缺的一部

份。隨著高速網路的普及，網路徹底的顛覆了人們使用電腦的習慣，有些作業系統甚至

直接與瀏覽器結合，讓使用者靠一個瀏覽器就可以在網路上完成文書、上網、遊戲、會

議、多媒體等所有原本在本機端處理的工作。

處理資料的核心又再一次回到了遠端的機房，只是這一次負責服務的不再是一台大

型的超強電腦，而是遍步世界各地的電腦群集 (cluster)。各種支援橫向擴展 (scale-out)

的軟體與系統開始被研究和使用，每天共同處理著高達數以 Pera Byte 計的資料，如何

有效率的處理這些資料，以及如何有效率的管理處理這些資料的機器，其中不少研究方

向值得我們去探討。

1.1

研究背景與動機

隨著網路速度的持續發展，使用者越來越習慣在網路上完成所有日常工作，而不用

去擔心本地機器的運算能力強不強或是儲存空間夠不夠的問題，因此網路服務提供商

相對的就必須持續增加自己的機器數量來維持一定的運算能力，以及購買更多的儲存

設備。

然而維護越來越多的機器設備除了會導致管理成本快速增加，機器的部署配置與相

關的網路設定也會造成維護人員的負擔。另外，某些服務並非常態性的被使用 (如年節

的網路訂票、報稅，學校的選課等)，這些需求如果使用專門的機器來提供服務，會導

致離峰時段機器的閒置，電力的浪費，硬體使用沒有效率。

虛擬化提供了一個解決上述問題的途徑。近年來硬體虛擬化技術的成熟，讓虛擬化

的效率獲得提升，一台實體機器上可以執行數台至數十台獨立的虛擬機來提供不同的

服務。透過各種虛擬化軟體，可以隔離實體機器上的各種服務，經由虛擬機的動態遷移

(Migration) 可以隨時調整實體機器的負載，讓使用效率變高，確實解決了不少問題。

可是隨著虛擬化軟體的使用，管理人員必須同時管理實體機器與虛擬機器之間，以

及虛擬機器與虛擬機器使用者之間的關係，系統複雜程度反而比以前來的高。隨著服務

規模的擴大、機器的增加，這些軟體昂貴的授權費用也額外造成不少的負擔。

另外一個解決辦法是使用現有的雲端運算服務，如 Amazon AWS EC2、Microsoft

Azure Platform 或是 Hinet Hicloud 等。利用租用雲端運算能力 (虛擬機) 與儲存空間來

架設所需的伺服器，或是直接利用現有雲端廠商提供的平台 (如 Google App Engine、

Heroku) 來撰寫程式，付出可接受的費用將底層的維護管理成本外包，自己只需要專心

在服務的開發及宣傳，並且享有快速擴展規模，根據使用量付費等好處。

可是此方式仍然有相當大的隱憂，常見的則是因為資料隱私性的關係，許多單位組

織不願意將資料放到遠端的公有雲上，而且根據使用量的增加，相關的費用也會逐漸提

高，我們也無法針對雲端系統要求客製化的動作，這些原因也是許多人轉而使用雲端運

算軟體來架設私有雲的原因。

1.2

系統發展之目標與成果

我們希望在不用添購太多最新的硬體的前提之下，利用交大資訊技術服務中心現有

的硬體設備，以及搭配免費的 Open Source 雲端運算軟體－ OpenStack Essex 來建立交

通大學的私有雲，提供校內師生一個可快速使用，且可彈性擴展的雲端運算服務。

考量到 OpenStack Swift 僅能提供物件儲存的服務，我們整和了 OpenStack 以及另一

個發展中的分散式檔案系統－ Ceph，來取代 Swift。除了提供原本的物件儲存功能之

外，進一步藉由 Ceph 可以提供多種網路儲存解決方案的特性，當作 OpenStack 各個單

元的儲存後端，讓 OpenStack 裡需要額外儲存空間的服務例如：Image、Volume、虛擬

機的 shared storage 等，都能與 Ceph 做整合。使用 Ceph 來負責所有的儲存工作，管理

者就不用擔心是否有哪個服務的可用空間即將用罄，也不需要依據不同服務的特性而

為 OpenStack 架設不同的網路儲存服務。

除了參考先前 Sébastien[21] 對於 OpenStack 裡的部分服務和 Ceph 的整合過程之外，

我們另外撰寫了一個 Python 模組－ rgwauthAPI，來負責同步 OpenStack 與 Ceph 的專案

和帳號的權限；Ceph RADOS 是 Ceph 上提供物件儲存的服務名稱，我們修改 OpenStack

Dashboard(Horizon) 使其可以直接使用 Ceph RADOS Gateway 所提供的 Swift API，並使

用相同的權限認證對外提供相容於 Amazon S3 的物件儲存服務。

另外考量到日漸枯竭的 IPv4 位址，我們修改了 OpenStack 的 network 子系統，發展

了第三種網路模式：PHA 模式，讓運算節點可以使用私有 IP 提供服務，大量節省 IP 的

消耗，並且在正常使用情境下仍然保有 HA 模式的各種好處 (如避免單點錯誤)，而且在

這種模式之下，比傳統 HA 模式能提供更好的安全性，可以避免為了支援虛擬機動態遷

移而產生的連接端口暴露。

圖 1.1: CStack 部屬示意圖

我們最終在交大資訊技術服務中心部署了一個完整的雲端運算和儲存系統 (圖

1.1)，我們利用 20 台由台達電子 (Delta Electronics, Inc) 捐贈的客製化機器和 4 台 HP

DL360-G5 來運行 Ceph 檔案系統，提供約 28TB 的儲存空間 (圖 1.3)；另外使用 1 台 HP

DL380-G5 以及兩台 Acer 380 F2 運算節點共擁有 56 個核心跟 176GB 的記憶體來提供虛

擬機使用，兩台 HP DL380-G5 當作控制節點以及提供物件儲存服務 (圖 1.2)，整個系統

已經上線供中心工程師以及有相關課程需要的老師及學生們使用。

圖 1.2: 運算節點示意圖

1.3

各章節介紹

第二章一開始介紹了雲端運算的相關定義，並說明我們的系統是歸類為哪一種類型

的雲端服務；另外我們也介紹了 NCTU CStack 的兩大子系統－ OpenStack、Ceph 的相

關背景細節，和子系統內的專案介紹。

第三節則是將 NCTU CStack 系統做一個大綱上的介紹，並藉著不同的面相來說明

系統的組成元件、使用情境和部署架構，並在 3.3節將虛擬機網路架構獨立出來特別說

明，幫助後續章節的理解。

第四章我們依照順序分別介紹了 Ceph 儲存後端和 OpenStack 各個專案的安裝細節，

以及在各小節後面補充兩個系統的整合方式和測試方法，並且在 4.3節說明 OpenStack

裡最重要的設定檔 nova.conf 中幾個相當重要的參數以及觀念。

第五章專注在說明使用 Ceph 來提供 OpenStack 物件儲存服務的部分，並且針對兩

個系統權限上問題來說明並提出解決辦法。

我們在第六章呈現最終的成果，並將原本的功能以及新的功能以圖片搭配說明來作

呈現，介紹 NCTU CStack 的使用方式。

最後，將在第七章作個簡單的結論。

第 二 章

背景知識

這個章節將說明有關雲端運算的基本解釋，並且介紹我們使用的兩個主要系統

OpenStack 和 Ceph 的開發歷史以及用途。

2.1

雲端運算

雲端運算 (Cloud Computing) 為近年來很熱門的一個研究領域，美國國家標準技術

研究所 NIST 有對他作了以下三種服務模型的定義 [19]：SaaS、PaaS 以及 IaaS，其中

IaaS(Infrastructure as a Service) 模型即是我們的系統 NCTU CStack 提供的服務種類，我

們提供了運算 (開啟虛擬機)、儲存、網路等資源給使用者在上面運行任意的軟體或作業

系統，使用者不需要對底層的硬體架構做任何的管理，只需專注於開發或維護作業系統

及其上面提供的服務。

關於部署的型態，我們屬於 NIST 定義的 Private Cloud，我們的系統並不對外開放，

只提供校內的師生使用。而且為了與傳統的線上虛擬私有主機 (VPS) 做出區分，NIST

也定義了雲端運算的幾種基本特性：

1. On-demand self-service －使用者可以自行依照需求，不用透過管理者而取的額外

所需的資源，如網路硬碟、新的虛擬機等。

2. Broad network access －提供一個標準的存取方式，不論運算能力的好壞，讓各式

各樣的機器都可以使用雲端服務。

3. Resource pooling －資源將以一個大集合的方式來提供 (pooled resources)，使用者

僅能控制很粗淺的選項，但無法得知細節。例如使用者開啟虛擬機器時無法得知

實體機器確切的位置，但可以指定想開啟哪一個洲或是哪一個資料中心的虛擬機

器。

4. Rapid elasticity －大部分的功能都要可以彈性的甚至自動的取得或釋放，對使用者

來說相當於可以無限制的使用。

5. Measured service －使用的資源要可以被控管，並產生使用明細，讓管理者跟使用

者可以自由地察看，並掌握使用量。

我們的系統因為是使用 OpenStack 來建置，因此也符合了上述所列的五種特性。

2.2

OpenStack

OpenStack 為 2010 年 NASA 與 Rackspace 共同推出的系統，以 Python 語言撰寫，並

使用 Apache 授權開放原始碼，讓所有人都可以利用這套系統自由的部署自己的雲端運

算與儲存環境 [16]。目前的支援廠商已經超過 150 家，其中包含了 AT&T、IBM、Intel、

HP、Cisco 等著名廠商，並以大約每半年推出一次新版本的速度更新中，最新的穩定

版本 Folsom(第六版) 在 2012 年九月底釋出，有超過 330 作者替 Folsom 貢獻原始碼，

相較於 Essex(第五版) 大致上為 Diablo(第四版) 的穩定性更新和錯誤修正 [14]，Folsom

在每個專案上皆有相當多的功能更新，並新增了兩個獨立的專案－網路及磁碟 (Block

Device)，讓 OpenStack 的運作更臻完善。

OpenStack 一 開 始 由 Nova 與 Swift 兩 個 專 案 組 成，各 自 提 供 雲 端 運 算 與 資 料 儲

存的功能，接著發展到目前已分成數個核心專案，分別有：Nova 運算、Swift 物件

儲存、Glance 映像、Keystone 認證、Nova-network 網路 (Quantum)、Nova-volume 磁碟

(Cinder)、Dashboard 網頁管理等，這些核心專案再搭配資料庫服務 (如 MySQL、SQLite)

以及 Advanced Message Queuing Protocol(AMQP) 服務 (如 RabbitMQ、Apache Qpid) 和

Web VNC 服務 (如 noVNC) 等許多其他 Linux 上的其他服務一起組成一個雲端運算系

統。

各個專案的運作細節，以及部署方式將會在本論文後續篇幅使用到時一起介紹，亦

可參考 1.3節查詢。

2.3

Ceph

Ceph 是 Sage A. Weil 等人在 2006 年發表的一個擁有高度延展性、良好效能的分散

式檔案系統 [23]。整個系統在良好的物件儲存能力基礎上，進而再提供 Block Storage 和

File Storage，提供現有雲端服務多元化的支援。

Ceph 在設計之初即考慮可靠性問題，並把底層設備的硬體錯誤視為正常且一定會

發生的現象，因此設計了多項錯誤偵測機制，確保資料的正確性。除了一般的硬體錯

誤，作業系統會自動回報之外，Ceph 系統包含了小部分 Monitor Cluster，主動檢查是否

發生間斷性的網路問題，監控整個系統的狀態，也負責管理系統設備的增減，讓管理者

可以動態的新增機器來擴充儲存空間，也不用擔心小部分的機器異常離線而導致整個

檔案系統損毀。

Ceph 將檔案切成數個物件，合併數個物件成一個存放集合 (Placement Group)，管理

者可以自訂 PG 的 Replica 數量，並利用 Placement Rule 來決定 Replica 的存放位置 (如

圖 2.1)，管理者可以將實體機器的部署情形 (如那些機器使用共同的電源迴路、Switch)

與檔案備援機制共同考慮，進一步提高資料安全程度。

Placement Rule 由一連串有階層關係的 Controlled Replication Under Scalable

Hash-ing(CRUSH) Map[24] 所組成，表 2.1是個簡單的例子：管理者可以在不同規模的設備分

類中用 CRUSH Map 來亂數選擇所需數量的大單位，然後從被選擇出來的大單位中再遞

迴的選擇所需的小單位，最後把這個 rule 執行完畢就會擁有一推最終單位，物件就會被

儲存在這些最終單位上。

圖 2.1: 以此圖為例，圖中所標示數字為管理者定義每台 OSD 的權重 (Weight)，因為

BetaSite1 的 OSD 容量為 A9r 的 2.5 倍，因此我們可以將此資訊寫進 Placement Rule 中，

利用權重控制每台機器所存放的檔案大小，並控制 PG 的 Replica 需要放置一份到

BetaSite1，其餘兩份則存放至 A9r 中，避免因為 BetaSite1 的 Switch 故障，使得有部分

檔案暫時無法存取。

2.3.1

Ceph 服務

RADOS(Reliable Autonomic Distributed Object Storage) 為 Ceph 的物件儲存服務的名

稱，是 Ceph 其他服務的後端，存放這些物件的機器就叫做 Object Storage Device(OSD)，

Action

Resulting Vector

說明

take(root)

Default

從 root 開始

select(1,room)

Room2

在機房這個單位挑選一個機房

select(3,cabinet)

cab21 cab23 cab24

從上面 Room2 這個機房裡面再挑選三個機櫃

select(1,disk)

disk2107 disk2313 disk2437

從上面挑選出來的機櫃中各自挑選一個磁碟

emit

送出結果

Table 2.1: 一個簡單的 Placement Rule 例子

是 Ceph 裡實際負責儲存資料的基本單位，OSD Cluster 底層可以選擇使用 XFS、Btrfs

等主流的檔案系統。存取 RADOS 上的物件除了可以使用 rados 這個指令，Ceph 也提供

了 python-rados、java-rados 等語言的 library 可供使用。

RBD(RADOS Block Device) 可將多個 RADOS 上的物件集合成系統上的一個 Block

Device 來使用，存取的方式可透過 Linux 2.6.36 之後內建的 Kernel Module 或是 librbd

library。使用 RBD 指令建立的 Block Device 可依需求變動大小、建立快照。

Ceph FS 是 Ceph 提供的另一種服務型態 -File Storage，利用 Ceph 的分散式檔案系統

協定，使用者可利用 Linux Kernel 內的 Ceph Client 或透過 User-Space 的 Ceph-FUSE 來

掛載 Ceph FS。Ceph 上的 Metadata Server Cluster(MDS) 負責處理檔案系統的 inode、紀

錄檔案大小、修改時間、檔案權限等等的資訊，MDS 除了利用 Memory Cache 來加速

metadata 的處理與回應，也會將它寫入 journal，存回 OSD Cluster 來避免資料遺失。

RADOS Gateway 利用了 Apache/Nginx 等 Web Server 對外釋出了 RADOS 的另一種存

取方式 -ReST Interface。使用者可以透過 OpenStack Swift API 或是 Amazon S3 API 來向

RADOS Gateway 請求服務，RADOS Gateway 負責將物件轉送給後端的 Ceph RADOS，

或是從後端取出物件供使用者下載，並完成與使用者的連線對話。表 2.2比較了 Ceph

的各種服務與常見的儲存服務的對應關係 [18]。

Object Storage

Block Storage (SAN)

File Storage (NAS)

Ceph RADOS

Ceph RADOS Block Device(RBD)

Ceph FS

Amazon S3

Amazon Elastic Block Storage(EBS)

OpenStack Swift

OpenStack Nova-Volume (Cinder)

iSCSI, AoE

NFS, Samba

2.4

指令碼說明

由於本論文之後的內容將會充滿執行指令與顯示結果，我們將所有的指令皆以有底

色的方框表示，並且在沒有特別指名的情況之下，命令提示字元 # 開頭的指令皆代表以

root 身分執行，且指令執行時所在的主機名稱將顯示在命令提示字元之前：範例如下：

沒有底色的方框代表指令執行結果，或是編輯器修改的內容 (設定檔)。

此外，NCTU CStack 系統不論 Ceph 或是 OpenStack 皆安裝在 Ubuntu 12.04 amd64 的

作業系統上，因此我們介紹一下本篇論文常用的指令：

1. aptitude - Ubuntu 內建的套件管理程式，install 參數後接著欲安裝的套件名稱

Host1# aptitude install <Package1> <Package2> ...

2. vim - 額外安裝的純文字編輯軟體

3. scp - 遠端檔案複製軟體，將檔案從第一個參數複製到第二個參數，參數內冒號之

前代表主機名，冒號之後代表檔名

Host1# scp <Local source file> Host2:<Remote destination file> Host1# scp Host2:<Remote source file> <Local destination file>

4. tee - 將標準輸入的資料流寫入指定的檔案內，加上 -a 參數代表不會覆寫檔案，僅

將資料流加入檔案末端

5. chown - 改變檔案的擁有者跟擁有群組

第 三 章

系統架構

本章將描述我們建置的 NCTU CStack 系統的整體架構，以及 Ceph 系統的子架構，

和介紹虛擬機的網路架構。

3.1

CStack 系統

圖 3.1是從 OpenStack Compute Administration Manual[15] 的 Logic Architecture 修改

而來。右半部四個獨立的方框是標準的 OpenStack 元件，由 Dashboard 提供網頁介面

接受使用者的建立虛擬機需求，和管理者的維護操作，由 Image 元件提供使用者指定

的映像檔給運算節點利用 Compute service 來運行虛擬機，且所有的元件的互動皆透過

Identity 元件來進行認證及授權，如此提供了 IaaS 所需的基本元素。

有鑑於傳統的 OpenStack 有多個元件需要額外獨立的儲存空間，如存放開機映像

檔的 Image provider、存放動態磁碟的 Volume provider、支援虛擬機動態遷移所需的

共享儲存空間 (shared storage)，以及原本的物件儲存服務 (Swift) 等，若是各別安裝規

劃，除了系統複雜度極高之外，後續空間的維護以及擴張也是相當麻煩。因此我們

整合了 Ceph 與 OpenStack，讓 Ceph RADOS Gateway 搭配我們撰寫的 rgwauthAPI-這個

Dashboard 模組，取代了原本的 OpenStack 物件儲存服務，並可以和 Identity 上的權限

同步，更進一步對外提供相容於 Amazon AWS S3 的物件儲存服務 (參考第 5章)；也利

用了 Ceph RBD 來當作開機映像檔和動態磁碟的儲存後端，統一使用 Ceph 來管理所有

OpenStack 產生的資料，節省管理者的負擔 (參考 4.2.2、4.2.3小節)；共享儲存空間則使

用 Cephfs 搭配 NFS 來提供，經過單一的 NFS Server 轉送 (Reexport) 的共享儲存空間則

是可以穩定的讓每台運算節點使用 (參考 4.2.4小節)。

觀念上的元件區分有助於我們選擇那些元件要安裝在同一台實體機器上。以使用

情境來說明，我們的系統除了可以提供 IaaS 的使用者透過 Dashboard 來開啟虛擬機外，

也讓 Object Proxy Server 提供了物件儲存的服務，當然，一般的使用者也可以直接使

用虛擬機上架設的服務。實際上，我們將實體機器分成兩個 cluster 以及兩台管理節

點。由 Intel Xeon E5310 以上的機器搭配 48GB 以上的記憶體組成運算節點 (Compute

Workers) 來提供虛擬機們穩定的運作環境；由擁有 16GB 記憶體的客製化機器提供分散

式的 Ceph 來提供可高度水平擴展的儲存空間；另外兩台管理節點各扮演著 Controller

或 Object Storage Proxy 的功能。這些組成了一個完整的雲端運算與儲存的基礎建設 (圖

3.2)。

圖 3.1: CStack 系統概念圖

3.2

Ceph 系統架構

圖 3.3顯示了 Ceph 分散式檔案系統由三個部分組成：Object Storage Device(OSD) 來

負責所有的物件儲存，Metadata Server(MDS) 負責提供 Ceph FS 來讓遠端設備掛載使

用，Monitor 則負責管理整個 Ceph 和監控所有機器的運行狀況。

另外，圖 3.3也顯示了 NCTU CStack 系統中 OpenStack 內的服務和 Ceph 之間的關

係。我們使用 Ceph FS 來當作共享儲存 (shared storage) 用來存放虛擬機資料，讓虛擬

機擁有動態遷移 (live migration) 的能力；使用 Ceph RADOS Block Device(RBD) 來當作

Image 服務和 Volume 服務的後端，比起存放在服務端的本機硬碟增加了映像檔和快照

的資料可靠性；另外使用 Ceph RADOS Gateway 來取代 OpenStack Swift 程式，除了免

圖 3.2: CStack 系統佈署架構圖

於同時安裝兩個分散式檔案系統，降低系統複雜度之外，還可以比 Swift 提供更多的功

能。這樣的架構可以讓整個 CStack 系統都充分利用 Ceph 這個可靠的分散式檔案系統的

好處。

3.3

修改後的虛擬機網路架構

圖 3.4是參考 Vishvananda[7] 在"Networking in Nova" 文中的圖修改而來的，它反映

了 NCTU CStack 系統中不同專案 (tenant) 的虛擬機之間的網路互動關係。我們使用了

OpenStack 裡的的 VLAN 模式，搭配 High Availability Option，擁有一個安全且高可用性

的網路環境，但為了管理上的方便，在沒有安全疑慮下我們僅使用一台 Switch

_來供虛

擬機和 Nova 的服務程式使用。

如同右上角三種線條所示，我們使用 Tagged VLAN Switch 來將 Nova 服務所在的網

路 (VLAN ID 0) 與虛擬機們使用到的網路 (VLAN ID > 100) 切開，虛擬機若遭受外部網

路攻陷時，並沒辦法假裝成 Nova 服務的一部份來竊取其他人的資料 [22]；同時虛擬機

之間也用不同的 VLAN ID 區分，不同專案的虛擬機也無法互相偷聽，避免掉一些常見

的網路攻擊 (如 ARP spoofing 等) 在專案間快速擴散的危險。

傳統 OpenStack 的網路架構僅用單一的節點安裝 nova-network 服務來處理 (轉送)

_{若是在系統的規模成長之後必須使用多台 Switch，Switch 之間互相連接的連接埠必須設定為 Trunk}

模式，傳送不同 VLAN 的封包。

圖 3.3: Ceph 與 OpenStack 關係圖

所有虛擬機與外部網路的流量，但這意味著一旦 nova-network 服務停止或機器離線維

修，所有使用者即與虛擬機立刻失去聯繫。High Availability(HA) Option 就是為了避免

單點錯誤 (SPOF) 即造成整個 OpenStack 的虛擬機網路完全癱瘓所設計的模式。由圖

3.4上的三個實體節點所示，每個運算節點 (Compute Worker) 除了安裝啟動虛擬機必要

的 nova-compute 服務之外，我們也安裝了 nova-network 服務來開啟 HA Option，讓每個

虛擬機的網路直接利用宿主機轉送出去，如此就不會因為一台機器的停擺而造成所有

虛擬機的網路中斷。另外，metadata-api 也是因應這種模式下而需要每一台運算節點都

安裝的服務，詳情請參考 4.3節的 Metadata API 子小節。

除此之外，為了提高系統安全性，以及實際使用情形的限制，我們建立了一種名為

部分 HA(PHA) 的網路模式。在此環境之下，我們延用了舊有的 HA 模式，並讓每一台

運算節點都只有私有 IP，讓使用者依照專案需求再動態的綁定公開 IP 到運算節點上，

若日後運算節點的數量一多，可以替單位裏原本就不夠多的 IPv4 省下可觀的消耗，也

避免了外部網路可以直接連線到運算節點的風險。

表 3.1顯示了三種虛擬機網路模式的優缺點。沒有使用 HA 模式的網路模式下，擁有

最多單點錯誤的風險，而傳統的 HA 模式又似乎已趨近完美，不但不需要額外的 NAT

主機，而且也避免了所有單點錯誤的情形，但唯一美中不足的是，他需要大量的公開

IP 供運算節點使用。相較之下，我們的 PHA 模式就符合大部分的使用者需求。

圖 3.5顯示了從專案角度來看待虛擬機的網路架構。一般來說，擁有公開 IP 的虛擬

機通常為整個專案 cluster 的進入點，也常常是專案裡負責對外提供服務的重要機器，

圖 3.4: 虛擬機網路互動關係圖 (Provider View)

在 PHA 模式下這種機器的流量可直接經由運算節點傳送到網路上的實體 Gateway，確

保高度可用性；另一方面，由於虛擬機與宿主機的網路卡互相以橋接 (bridge) 模式相

連，可視為在同一個實體網路下，所以同專案虛擬機之間的網路流量皆是經由實體交

換器來轉送，也不會有單點錯誤的問題；所以在我們的 PHA 模式下，我們節省了大量

的公開 IP，讓運算節點以及那些沒有公開 IP 的虛擬機一樣，在有對外連線需求時改用

NAT 主機，而這樣的需求通常是在更新系統套件，或是需要對外連線的時候，而這種

情形相較之下是比較不重要，也不常發生的。

此外，由於 OpenStack 在做虛擬機動態遷移時，需要儘量使來源端與目的端的

運算節點的相關設定保持一致，其中一點是必須讓運算節點上的 VNC 服務聆聽在

0.0.0.0(vncserver_listen=0.0.0.0)[8]，這樣做是為了避免虛擬機遷移之後，VNC 服務無法

使用原本的 IP 而造成遷移失敗。可是這樣的設定在傳統 HA 網路模式上會造成 VNC 服

務的暴露；反觀我們的 PHA 模式的網路架構，卻可以很好的支援這個需求。因為運算

節點上並沒有公開 IP，外部網路無法直接存取 VNC 服務，至於那些擁有浮動 IP 的運算

節點，所有存取浮動 IP 的連線皆會被導入虛擬機上，也無法存取到 VNC 服務，進而提

供了比傳統 HA 網路模式更好的安全性。

因此我們使用這種 PHA 模式，必要的時候也可以與傳統 HA 模式混合使用，以符合

SPOF

Another

NAT Server

Public IP

per Host

Service

Exposure

傳統

無 HA

fixed IP inner flow

! (dhcp flow)

V

(Network Host)

fixed IP outbound flow

V

w/ floating IP

V

傳統

HA

fixed IP inner flow

V

V

fixed IP outbound flow

w/ floating IP

PHA

fixed IP inner flow

V

fixed IP outbound flow

V

w/ floating IP

Table 3.1: 傳統、傳統 HA 模式以及 PHA 模式的網路架構比較表

圖 3.5: P-HA 網路模式下的三種使用情況：(1) 同專案的虛擬機之間的網路流量。(2)

沒有公開 IP 的虛擬機往 Internet 的流量需經過 NAT。(3) 有公開 IP 的虛擬機可直接與

Gateway 溝通。

第 四 章

CStack 系統安裝步驟

由於整合過的 CStack 系統頗具規模，因此我們將其拆成幾個章節來做介紹。

在本章先介紹 Ceph 的基本安裝，接著會在 4.2節介紹 OpenStack 安裝步驟與 Ceph

的整合方法，這樣我們就可以利用 OpenStack 和 Ceph 部署一個基礎的 IaaS 服務了。最

後到了 4.3節，我們會針對 nova.conf 裡幾個重要的設定來做說明，並針對我們新增的參

數來解釋其用法和意義。

4.1

Ceph 安裝細節

Ceph 分散式檔案系統是整個 NCTU CStack 系統中最重要的部分，因此我們需要先

安裝好才能進行後續的步驟。

1. 在所有機器上面匯入套件金鑰，並且加入 Ceph 官方套件庫

# wget -q -O- https://raw.github.com/ceph/ceph/master/keys/release.asc \ | sudo aptkey add

-# tee /etc/apt/sources.list.d/ceph.list <<EOF deb http://ceph.com/debian/ precise main deb-src http://ceph.com/debian/ precise main EOF

2. 在所有機器上面更新套件庫，安裝 Ceph。

# aptitude update; aptitude install ceph

3. Ceph 會使用 hostname 來溝通，為了降低複雜度，我們不需要架設自己的 DNS，

而是讓所有機器使用同一份 /etc/hosts [附錄 A.1]。

mon1# vim /etc/hosts

mon1# scp /etc/hosts slave*:/etc/hosts

4. Ceph 的某些管理指令 (如 mkcephfs) 會從管理節點 (monitor node) 直接使用 ssh 連

到 Cluster 內的其他的節點來執行命令，所以我們使用 ssh-keygen 來替管理節點上

的 root 產生連線所需的金鑰，並使用 ssh-copy-id 來把金鑰複製到其他 slave 機器

上。

mon1# ssh-keygen -d

mon1# ssh-copy-id root@slave*

mon1# ssh slave* uname // 測 試 ssh 連 線 是 否 不 需 要 輸 入密碼

5. Ceph 使用 ceph.conf 這個設定檔來定義整個系統的架構、參數等，撰寫符合所需

的設定檔 [附錄 A.2]，並同步到所有的 Ceph node 上。

mon1# vim /etc/ceph/ceph.conf

mon1# scp /etc/ceph/ceph.conf slave*:/etc/ceph/ceph.conf

6. 至此，我們可以來格式化 Ceph 了，ceph.conf 上面指定的 btrf devs 將會被重新格

式化，請注意填寫是否正確。

mon1# mkcephfs -v -a -c /etc/ceph/ceph.conf --mkbtrfs

7. 若過程中沒有任何錯誤，則 ceph.conf 上 keyring 所指定的位置應該會產生出正確

的 keyring 檔。

mon1# ceph auth list // 列 出 所 有 的keyrings

8. 將 Ceph 的所有元件啟動，並確認 Ceph 的狀態。

mon1# /etc/init.d/ceph -a start

mon1# ceph health // 顯 示 簡 單 的 健 康狀態 mon1# ceph -s // 顯 示 詳 細 的狀態

mon1# ceph -w // 持 續觀看

9. Ceph 有個特點就是可以根據實體機器的部署配置，決定 PG replica 的儲存方式

(參考 2.3小節)；我們先編寫 crush.nctu.txt [附錄 A.3]，然後編譯成 Ceph 看得懂的

CRUSH map，套用完成後可使用 ceph osd tree 確認結果。

// 編 譯 crush map

mon1# crushtool -c /etc/ceph/crush/crush.nctu.txt -o /etc/ceph/crush/crush.nctu // 令 crush map 生 效

mon1# ceph osd setcrushmap -i /etc/ceph/crush/crush.nctu // 查 看 套 用 新 的 crush map 後 的結果

mon1# ceph osd tree

10. 最後我們可以依照需求，設定各個儲存池 (pool) 所需的 replica 數量。

mon1# ceph osd pool set <pool> size 3

如此 Ceph 的安裝到這邊告一段落。

4.1.1

Ceph 擴展方法

由於 Ceph 擁有高度擴展的能力，因此我們可以在 Ceph 儲存空間不夠時，利用增加

Object Storage Device(OSD) 的方式來彈性增加儲存空間，或是依照其他需求來動態增加

Monitor 節點以及 Metadata server 節點的數量。具體做法可以參考官方文件 [3]，或是使

用附錄 A.6 - mkosd 這個 script 來快速增加一個 OSD 節點。

4.2

OpenStack 安裝細節

OpenStack 本身是一個 cloud manager，除了負責管理虛擬機的建立與刪除，也要管

理虛擬機開機所需的映像檔 (image)，以及額外掛載到虛擬機上的虛擬磁碟 (volume)，

服務雖然多樣且完整，但是不同的服務各自使用不同的資料儲存方式，會造成管理上的

複雜化，以及資源使用沒有效率。

在這一節，我們將參考這個網站 [6] 使用 Ubuntu 12.04 Precise 的官方套件來安裝

OpenStack Essex，每一小節後會有一段介紹該服務如何與 Ceph 結合 [21]，讓所有需要

儲存空間的服務後端都改成使用 Ceph-這一個分散式，可靠的物件儲存系統。

4.2.1

Controller 安裝步驟

我們安裝的 Controller 提供的服務包含了 Keystone 認證系統，Dashboard 介面，和

Nova APIs，scheduler 等，因此這部分的介紹主要包含軟體安裝，Keystone 設定，Nova

設定。

1. 這邊安裝 Nova Controller 幾個最重要的元件：各種 API daemon，scheduler，vnc 元

件 (因為 Nova-vncproxy 僅有很少的瀏覽器支援，Essex 版本後改用 novnc[17])，和

一些會用到的 python 函式庫。

# aptitude install nova-api-ec2 nova-api-os-compute nova-api-os-volume \

nova-cert nova-common nova-console nova-consoleauth nova-ajax-console-proxy \ nova-scheduler python-django-nova python-nova python-nova-adminclient \ python-novaclient nova-objectstore python-novnc novnc python-numpy nova-doc

2. Essex 版本後，一些重要的系統操作 (如設定 iptables，mount 虛擬機的 image 等)

預設使用一個 wrap 程式來代為呼叫，確認 nova-rootwrap 指令有無加入 sudoers，

並指定 NOPASSWD(不需輸入密碼)。

# visudo

// 增 加 下 面這行

nova ALL=(root) NOPASSWD: /sbin/vgs,/usr/bin/nova-rootwrap,/sbin/iptables-restore,/sbin/iptables-save

3. 安裝 OpenStack Dashboard (code name: horizon)。

# aptitude install libapache2-mod-wsgi openstack-dashboard openstackx \

openstack-dashboard-ubuntu-theme python-django-openstack python-openstack-common

# aptitude install keystone python-keystone curl python-mysqldb python-dateutil

5. 習慣使用 Amazon ec2 服務的人可安裝 Eucalyptus tool(另一套管理系統，有安裝

nova-api-ec2 就可使用) 來控制你的 OpenStack，另外我們還需要 AMQP Server，

Database。

# aptitude install euca2ools rabbitmq-server mysql-server

6. 設定 MySQL 要 listen 的 address，以及建立 nova、Glance 服務會用到的資料表

# sed -i 's/127.0.0.1/192.168.100.1/g' /etc/mysql/my.cnf # mysql -uroot -p

# 建 立nova 資料庫 CREATE DATABASE nova;

# 設 定nova 資 料 庫 的 使 用 者 帳 號 及密碼

GRANT ALL PRIVILEGES ON nova.* TO 'root'@'%' IDENTIFIED BY '<<yournovadbpw>>'; # 建 立glance 資料庫

CREATE DATABASE glance;

# 設 定glance 資 料 庫 的 使 用 者 帳 號 及密碼

GRANT ALL PRIVILEGES ON glance.* TO 'root'@'%' IDENTIFIED BY '<<yourglancedbpw>>'; # 讓 改 變生效

FLUSH PRIVILEGES; quit;

7. OpenStack Essex 使用 Keystone 來負責所有的帳號 (User)、專案 (Tenant/Project)、

身分 (Role) 的管理，接著我們來修改 Keystone 設定。

# vim /etc/keystone/keystone.conf

[DEFAULT]

bind_host = 192.168.100.1 // Keystone 服 務 listen 在private network 上

admin_token = <<yourkeystonetoken>> // 管 理Keystone 上 的 tenants, users, role 的 最 終密碼 ...

[catalog] // 註 解 下 面這行

#driver = keystone.catalog.backends.sql.Catalog

// 預 設 catalog存 放 在 database 上，在 大 規 模 佈 署 OpenStack 時 (endpoint 較 多)，這 樣 做 較 有 效率。 // 但 我 們 使 用templated catalog file，簡 單 的 修 改 檔 案 內 容 即 可 管 理catalog。

driver = keystone.catalog.backends.templated.TemplatedCatalog template_file = /etc/keystone/default_catalog.templates

8. 編輯 templated catalog file [附錄 B.1]。

OpenStack 也 使 用 Keystone 來 定 義 所 有 服 務 的 總 類 (catalog)， 以 及 存 取 入 口

(endpoint)；舉例來說，我們之後會在 image 服務 (Glance) 的設定檔上註明，使用

keystone 認證 (即 Glance 將不會維護任何的帳號密碼和權限)，並且在 Keystone

catalog 註冊一個 image 的服務存取入口，因此任何想要使用 OpenStack 的 image

服務的人 (或其他服務)，都可以先跟 Keystone 做認證取得授權後，再向 catalog 查

詢 Glacne 的存取入口為何，進而正確使用該服務。

OpenStack 的服務使用 ReST 介面來做溝通，任何一個服務使用者 (可能是人或另

一個服務) 需要知道每個服務的位址 (URL) 和連接端口 (port)，才能正確地使用該

服務。catalog 即定義了所有服務的 endpoint(存取入口)。

為了安全性，除了要開放給 User 使用的 API 之外，所有服務都將設定成 listen 在

192.168 網段下，因此我們在這邊必須 endpoint 的描述從 localhost 改成 controller(或

192.168.100.1)，若有些服務如 image、volume 不是由 controller 提供，也需改成相

對應的 hostname 或 IP，這樣之後才能正常連線。

另外加入 (註冊)object-store 的 endpoint，讓 Dashboard 提供" 物件儲存" 的功能。

# vim /etc/keystone/default_catalog.templates ... // 加 入 object-store endpoint。 catalog.RegionOne.object-store.publicURL = http://s3.nctu.edu.tw/auth catalog.RegionOne.object-store.adminURL = http://s3.nctu.edu.tw/auth catalog.RegionOne.object-store.internalURL = http://s3.nctu.edu.tw/auth catalog.RegionOne.object-store.name = Swift Service

9. 接下來初始化 Keystone 的 database，並將權限設定好。

# keystone-manage db_sync

# chown keystone:keystone /var/lib/keystone/keystone.db # chmod 640 /var/lib/keystone/keystone.db

# /etc/init.d/keystone restart

10. 到目前為止，已經安裝好 Keystone 服務，我們可以設定環境變數來簡化執行

Keystone client 所需要的參數，確認 keystone 服務能否正常使用。

# vim .keystonerc

// 設 定 好 Keystone client 會 使 用 的 兩 個參數 export SERVICE_TOKEN=<<yourkeystonetoken>>

export SERVICE_ENDPOINT=http://controller:35357/v2.0/

# . .keystonerc // bash shell 使 用"." 讀 入 環 境變數 # keystone user-list

\\ 因 為 尚 未 建 立 任 何 user，正 常 的 話 會 顯 示 空 的 user list +----+---+---+---+

| id | enabled | email | name | +----+---+---+---+ +----+---+---+---+

11. 接著可以來新增專案 (Tenant)，使用者 (User) 了。這邊我們可以使用 devstack 所提

供的 script[13] 來快速建立幾個基本的專案跟使用者。執行 script 前可針對想產生

的帳號密碼稍作修改，該 script 的註解寫得相當清楚，建議可以全部看過。

# . .keystonerc // 讀 入 環 境變數 # vim keystone_data.sh

// 預 設 這 個 script 所 建 立 的 user 皆 使 用 相 同 的 密 碼 ($ADMIN_PASSWORD)， // 這 邊 我 們 稍 作 修 改 各 自 使 用 不 同 的 密碼。

...

ADMIN_PASSWORD=${ADMIN_PASSWORD:-<<youradminpw>>} // 自 訂 user: admin 的密碼 DEMO_PASSWORD=${DEMO_PASSWORD:-<<yourdemopw>>} // 增 加 這 行 定 義 user: demo 的密碼 // service user(eg. nova, glance) 也 使 用 不 同 的密碼

SERVICE_PASSWORD=${SERVICE_PASSWORD:-<<yourservicepw>>} ...

DEMO_USER=$(get_id keystone user-create --name=demo \

--pass="$DEMO_PASSWORD" \ // 使 用 剛 剛 定 義 的 $DEMO_PASSWORD

# bash keystone_data.sh // 執 行 結 果 沒 有 顯 示 任 何 東 西 即 為 建 立成功 # keystone user-list // 確 認 我 們 剛 剛 建 立 的 user

+---+---+---+---+

| id | enabled | email | name |

+---+---+---+---+ | 4146a6ade427467380cb0c8120604373 | True | [email protected] | admin | | 4f81b14bee8d4637af31fd606145c452 | True | [email protected] | glance | | a37a9074a70d4b78b756dbed11359105 | True | [email protected] | nova | | a9d4eb6a28414a0f9b3e65e3a87a14b9 | True | [email protected] | demo | +---+---+---+---+

12. 可使用一個小 script TUG.sh 顯示 Tenants、Users、Roles 的全部對應關係 [附錄 B.

2]

# bash TUG.sh

Tenant: fc280a91aa7a400fad3fb92f4e203a82 ================= service User: nova => a37a9074a70d4b78b756dbed11359105

Role: admin => dda74ea9cbdd4b13b23dbf61fc2647b2 User: glance => 4f81b14bee8d4637af31fd606145c452

Role: admin => dda74ea9cbdd4b13b23dbf61fc2647b2 Tenant: f433c5e046ec43ec9cdfa035a4bbd56c ================= admin

User: admin => 4146a6ade427467380cb0c8120604373

Role: admin => dda74ea9cbdd4b13b23dbf61fc2647b2

Role: KeystoneServiceAdmin => c3bdc07586994e04aa38a9dff1057054 Role: KeystoneAdmin => 68fb24354d374422a0fccbc474a53bd7

13. Keystone 的設定到此結束，接著我們需要處理 nova 的設定，但因 nova.conf 為

OpenStack 裡最重要的設定檔之一，請參考 4.3節來做設定。

# vim /etc/nova/nova.conf

14. api-paste.ini 定義了 nova 提供的各種 api(eg. EC2, Openstack, Metadata...) 要如何運

作，這邊只需針對 nova 如何向 Keystone 溝通的部分做設定。

# vim /etc/nova/api-paste.ini ...

[filter:authtoken]

// 須 注 意 我 們 的 Keystone 是 listen 在 192.168 網 段，這 裡 需 改 成 controller， // 不 能 使 用 原 本 的 localhost。

service_host = controller auth_host = controller

auth_uri = http://controller:5000/

// 這 邊 我 們 使 用 剛 剛 用 script 建 立 的 service user(nova) 來 跟keystone 做 溝 通 即可。 admin_tenant_name = service

admin_user = nova

admin_password = <<yourservicepw>>

15. 接著修改 Apache2 以及 Dashboard 的設定檔。

# vim /etc/apache2/conf.d/openstack-dashboard.conf

# Allow from all

Allow from 140.113.0.0/16 // 限 定 校 內 IP 讀取。

# vim /etc/openstack-dashboard/local_settings.py

ENABLE_JUJU_PANEL = False // 關 掉 沒 用 到 的 JUJU頁面。 ...

OPENSTACK_HOST = "192.168.100.1" // 指 定 Keystone 所 listen 的 位址。

16. 如此 nova 的設定也告一段落，我們可以將 nova db 初始化，然後重開 Controller 上

所有的服務，接著下一些指令測試 nova 的功能，照慣例還是需要先設定環境變數

(或是執行時指定一堆參數)。

# nova-manage db sync

# for a in keystone nova-api-ec2 nova-api-os-compute nova-api-os-volume \ nova-objectstore nova-scheduler nova-novncproxy nova-cert nova-console \ nova-consoleauth apache2; \

do sudo service "$a" restart; done # /etc/init.d/novnc restart

# nova --os_username admin --os_password <<youradminpw>> --os_tenant_name admin \ --os_auth_url http://controller:35357/v2.0/ list

# vim .novarc export NOVA_URL="http://controller:35357/v2.0/" export NOVA_VERSION="1.1" export NOVA_API_KEY="<<yourservicepw>>" export NOVA_USERNAME="nova" export NOVA_PROJECT_ID="service" # . .novarc

# nova list; nova image-list; nova volume-list

+----+---+---+---+ | ID | Name | Status | Networks | +----+---+---+---+ +----+---+---+---+

+---+---+---+---+ | ID | Name | Status | Server | +---+---+---+---+ +---+---+---+---+ +----+---+---+---+---+---+ | ID | Status | Display Name | Size | Volume Type | Attached to | +----+---+---+---+---+---+ +----+---+---+---+---+---+

限制專案可以使用的運算節點

有時候因為安全性的需求，或是實體機器的運用規劃，我們會希望將實體的運算

節點做分群，然後限制某些專案的虛擬機只能運行在特定的運算節點上。Essex 版的

OpenStack 可以利用兩種方式來達到這樣的需求，一個是利用 Zone 的切割，另一個是

使用 Scheduler。因為 Multiple Zone 的部署通常是使用在超大規模 (如跨地區) 的環境，

因此部署成本也相當昂貴 [20]，所以我們利用原有的 Filter Scheduler 搭配自行撰寫的

mapping filter 來達成這個功能。

Scheduler 在 OpenStack 的角色是負責決定新的虛擬機會被建立在哪一台運算節點

上，而 Filter Scheduler 則是先利用 filters 來過濾運算節點，接著利用 weighting 來決定

這些可供使用的運算節點候選人的偏好順序 [9]。雖然 OpenStack 提供了許多內建的

filters，但是並沒有辦法達到我們的需求，因此我們額外撰寫一個 project-host-filter 來處

理專案與實體運算節點的對應關係 (請參考附錄 B.6)。

project-host-filter 維護了一個 Map 資料結構如下：

PHMap = {

# when no project matches, choose from following hosts 'Default': {

'compute-1', 'compute-2', 'compute-3', },

# specify project(tenant) id and dedicated hosts '2bd91f3a4df64427815f721cd663267a': { # pacas 'compute-1', }, }

利用自訂這個資料結構，我們就可以過濾出符合限制的運算節點有哪些。使用的方

法也很簡單，只需在 nova.conf 加入欲使用的 filter 即可：

scheduler_default_filters=ProjectHostFilter,RamFilter

另外，scheduler 其實也負責調度新建立的磁碟是由哪一台 nova-volume 來負責提供，

可是官方的 Filter Scheduler(nova.scheduler.filter_scheduler.FilterScheduler) 並沒有實作調

度磁碟的函式 schedule_create_volume，這樣會導致建立磁碟時狀態一直顯示為 creating，

無法正常建立磁碟。因此我們建立新的 Scheduler 繼承自原本的 Filter Scheduler，並實

作磁碟調度函式 (請參考 B.5)，如此就可以使用 Filter Scheduler 的功能，並確保其他功

能正常。使用方式只需在 nova.conf 加入一行即可；

4.2.2

Glance 安裝步驟

OpenStack 建立虛擬機的時候，需要指定虛擬機的開機映像檔，映像檔可以是任意

的作業系統安裝光碟，或是一個預先安裝好作業系統的虛擬硬碟，來讓虛擬機直接使

用該硬碟開機。一些主流的 Linux 作業系統都有替這種需求額外提供各種格式的映像

檔 [10]，我們也可以製作符合自己需求的映像檔上傳到 OpenStack 使用。除此之外，

OpenStack 也讓使用者可以在任何時刻對虛擬機執行快照 (snapshot)，將虛擬機當時的

硬碟內容完全複製起來，當成另一份映像檔供使用者使用

_。

Glance 就是負責管理及儲存所有虛擬機的開機映像檔及快照的服務，我們將在這一

小節來說明他的安裝步驟。

1. 安裝 Glance 套件並設定 glance-api.conf 使其使用 Keystone 認證 [12]。

# aptitude install glance glance-api glance-client glance-common glance-registry # aptitude install python-keystone python-keystoneclient

# vim /etc/glance/glance-api.conf bind_host = 192.168.100.1 // listen 在 192.168 網 段 registry_host = 192.168.100.1 workers = 8 ... rabbit_host = controller qpid_host = controller ... [paste_deploy]

flavor = keystone // 使 用 Keystone 認 證

2. 設定 glance-registry。

1

_{OpenStack 裡的 Image 或 Snapshot 類似於 VMware 裡的 Template(樣板)，是可用來開啟另外的虛擬機，}

# vim glance-registry.conf

bind_host = 192.168.100.1 // listen 在 192.168 網 段 #sql_connection = sqlite:////var/lib/glance/glance.sqlite

sql_connection = mysql://root:<<yourglancedbpw>>@controller/glance // 使 用 mysql ...

[paste_deploy]

flavor = keystone // 使 用 Keystone 認 證

3. 設定 glance-api-paste.ini，glance-registry-paste.ini 這兩個檔案。這邊須注意目前官

方的文件仍建議使用 glance_auth_token:filter_factory，這是已過時的寫法，請使用

Ubuntu 內建的設定檔即可。

// 這 邊 我 們 使 用 剛 剛 利 用 Keystone 建 立 的 service user(glance) 來 跟 keystone 做 溝 通 即可。 admin_tenant_name = service admin_user = glance admin_password = <<yourservicepw>>

4. 設定檔已修改完畢，我們可以初始化 glance 的資料庫。

5. 重開 Glance 所有服務，然後一樣要設定好環境變數，就可以列出目前 Glance 上的

映像檔，測試看看運作是否正確。Glance 的安裝到這邊告一段落，這邊須注意的

是我們還沒設定好跟 Ceph 整合的部分，所以暫時還不能上傳映像檔。

# service glance-api restart && service glance-registry restart # vim .glancerc export OS_AUTH_URL=http://controller:5000/v2.0/ export SERVICE_ENDPOINT=http://controller:35357/v2.0 export OS_AUTH_STRATEGY=keystone # glance rc export OS_USERNAME=glance export OS_PASSWORD=<<yourservicepw>> export OS_TENANT_NAME=service # . .glancerc # glance index

ID Name Disk Format Container Format Size --- --- --- ---

---Glance with Ceph RBD

Glance 服務提供了很多方式存放虛擬機的映像檔，因為映像檔本身就可以看成是

一個大的 object，所以除了可以設定要存放在本地磁碟上，也支援放到常見的 object

storage service，如 Swift、Amazon S3

，以及，存放到 Ceph 上：

1. 要讓 Glance 使用 Ceph 當儲存後端需要先在 Ceph 端建立一個供 Glance 使用的帳

號與儲存池 (pool)，以及將 Ceph 金鑰 (keyring) 複製回 Glance 主機供 Glance 程式

使用。

// 到 Ceph 上 建 立 要 讓 Glance 存 放 映 像 檔 的 pool，名 為 images。 ceph-mon# rados mkpool images

// 建 立 Glance 要 使 用 的 帳 號 (client.glance) 與 金 鑰 檔，設 定 帳 號 權 限 為 只 能 存 取 images pool。 ceph-mon# ceph-authtool --create-keyring image.keyring

ceph-mon# ceph-authtool --gen-key --name client.glance image.keyring

ceph-mon# ceph auth add client.glance mon 'allow r' osd 'allow rwx pool=images' \ -i image.keyring

// 將 金 鑰 檔 拷 貝 回 Glance 主 機，並 設 定 權限。

ceph-mon# scp image.keyring root@glance:/etc/glance/image.keyring glance# chown glance:glance image.keyring

glance# chmod 600 image.keyring

// 定 義 client.glance 這 個 使 用 者 的 金 鑰 位置。 glance# vim /etc/ceph/ceph.conf

[client.glance]

keyring = /etc/glance/image.keyring

2. 接著設定 Glance 使用我們剛剛建立的帳號來存取 Ceph RBD 上的 images 儲存池

(pool)。

# vim /etc/glance/glance-api.conf

default_store = rbd ...

rbd_store_ceph_conf = /etc/ceph/ceph.conf // 後 端 使 用 Ceph RBD rbd_store_user = glance

rbd_store_pool = images rbd_store_chunk_size = 8

3. 如此就完成了 Glance 與 Ceph 的整合，重開服務後就可以試著上傳一個映像檔了。

glance# service glance-api restart; service glance-registry restart // 載 入 執 行 glance 指 令 所 需 的 環 境設定

glance# . .glancerc glance# glance index

// 下 載 Ubuntu 12.04 的 雲 端 版 本 映 像檔。

glance# wget

amd64-disk1.img

// 上 傳 一 個 公 開 的 映 像檔。

glance# glance add name="Ubuntu 12.04 cloud\" is_public=true container_format=ovf \ disk_format=qcow2 < ./precise-server-cloudimg-amd64-disk1.img

glance# glance index

ID Name Disk Format Container Format Size --- ---- --- ---df23d532-9143-234 Ubuntu 12.04 cloud qcow2 ovf 230752256

4.2.3

Nova-volume 安裝步驟

Nova-volume 服務提供了虛擬機額外的邏輯磁碟，除了可以在虛擬機開機後動態的

增減虛擬機上的磁碟，Essex 版的 OpenStack 也支援使用 volume 來讓虛擬機開機，這個

服務因為相當重要，因此到了 OpenStack 下一個版本 Folsom 將獨立成一個核心專案－

Cinder。我們來介紹他的安裝步驟，以及如何將它處理的 volume 存放到 Ceph 上。

1. 先安裝好 nova-volume 套件，設定檔則修改向 Keystone 認證的部分即可。

# aptitude install nova-volume # vim /etc/nova/api-paste.ini ... [filter:authtoken]service_host = controller auth_host = controller auth_uri = http://controller:5000/ admin_tenant_name = service admin_user = nova admin_password = <<yourservicepw>>

Nova-volume with Ceph RBD

Nova-volume 預設使用 iSCSI 協定和名為 nova-volumes 的 LVM volume group 來儲存

虛擬磁碟 (volume) 的資料

_{，但這樣的問題是容易遇到 iSCSI 伺服器的效能瓶頸，而且}

得另外維護 iSCSI 伺服器，增加管理上的複雜度。

因為虛擬磁碟與虛擬機的開機映像檔性質類似，皆是一份巨大的檔案 (或者看成一

個物件)，因此我們希望統一使用 Ceph RBD 來當作 volume 的儲存後端，以下說明設定

步驟：

1. 在 Ceph 上建立一個名為 volume 的儲存池 (pool) 給 Nova-volume 來存放所有的資

料，並且建立一個使用者 (client.volume) 權限設定成只能存取 volume pool，再把

產生的金鑰 (keyring) 複製回運行 Nova-volume 的機器。

ceph-mon# rados mkpool volume // 建 立 帳 號 及 設 定 權限。

ceph-mon# ceph-authtool --create-keyring volume.keyring

ceph-mon# ceph-authtool --gen-key --name client.volume volume.keyring

ceph-mon# ceph auth add client.volume mon 'allow r' osd 'allow rwx pool=volume' \ -i volume.keyring

// 複 製 回 nova-volume 主機。

ceph-mon# scp volume.keyring root@volume:/etc/nova/volume.keyring // 回 到 nova-volume 主 機，修 改 金 鑰 權限。

volume# chmod 600 /etc/nova/volume.keyring volume# chown nova:nova /etc/nova/volume.keyring

2. 參考 4.1節加入 Ceph 官方套件庫。

3. 安裝 ceph-common 套件，並建立 ceph.conf 設定檔 [附錄 A.2] 指明 Nova-volume 所

使用的 Ceph client 以及金鑰檔位置。

// 安 裝 操 作 RADOS 所 需指令

volume# aptitude install ceph-common

// 因 為 rados 指 令 預 設 會 讀 取 這 個 位 置 的 設 定 檔，所 以 我 們 在 這 邊 建立。 volume# vim /etc/ceph/ceph.conf

// 指 定 nova-volume 所 使 用 的 帳 號 (client.volume) 及 金 鑰 位置。 [client.volume]

keyring = /etc/nova/volume.keyring

// 測 試 可 否 正 常 執 行 rados 指令。

volume# sudo -u nova rados --id volume -p volume ls

4. 接著要稍微修改 nova-volume 的啟動程序，讓 rados 用我們剛剛建立的 client.volume

身分來存取 Ceph[21]。

volume# vim /etc/init/nova-volume.conf

\\ 添 加 env CEPH_ARGS=\"--id volume\"

exec su -s /bin/sh -c "exec env CEPH_ARGS=\"--id volume\" nova-volume --flagfile=/ etc/nova/nova.conf" nova

5. 修改/etc/nova/nova.conf，讓 nova-volume 使用 Ceph RBD(RADOS) 來存放 volume。

# nova-volume use Ceph RBD backend

volume_driver=nova.volume.driver.RBDDriver rbd_pool=volume

rbd_user=volume

6. 接著重啟 nova-volume 就完成了，可以試著建立一個 1G 大小的 volume，並到

Ceph 上看看結果。

volume# service nova-volume restart // 載 入 執 行 nova 指 令 時 所 需 的 環 境設定 volume# . .novarc