OpenStack入門之擴充套件話題

一、OpenStack 入門 之 基礎知識

二、OpenStack 入門 之 基本元件

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

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

五、OpenStack 入門 之 實際操作

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

七、OpenStack 入門 之 若干討論

寫在前面

學習目標：

• 瞭解 OpenStack 的自動化部署
• 瞭解 Hadoop 雲化時存在的問題
• 瞭解 Ceph 的簡介及 Ceph 在 OpenStack 中的應用
• 瞭解 OpenStack 與 Docker

本次筆記的內容有：

• OpenStack 自動化部署
• Hadoop 雲化時存在的問題
• 基於 OpenStack 實現 Hadoop 雲化
• Ceph 簡介
• Ceph 在 OpenStack 中的應用
• OpenStack 與 Docker

1. OpenStack自動化部署

做一些基於 OpenStack 的開發工作，如果花太多時間在部署環境和除錯上是不太恰當的，不過 OpenStack 提供了一些自動化部署的工具。

[ 自動化部署分為三個層次：]

1. 單節點的自動安裝。經常用於準備一個開發環境，甚至可以在一臺筆記本上就可以完成一個 OpenStack 環境的搭建，常用的工具是 DevStack
2. 叢集化安裝。最常用的工具是 puppet，puppet 不是 OpenStack 社群的東西，但是與 OpenStack 結合的比較緊密，用 puppet 來安裝 OpenStack 也比較常見
3. 多個叢集的安裝和部署。常見的工具是由 Mirantic 推出的 fuel，在運營商和做託管雲業務的公司裡面顯得尤為重要，因為他們可能要面對不同的客戶，要管理很多的 OpenStack 叢集

2. Hadoop雲化時存在的問題

之前的 Sahara 就是用來支援 Hadoop 雲化的。那麼，Hadoop 的雲化到底需要解決什麼問題？

Hadoop 是用來做大資料處理的一個工具，Hadoop 有自己的生態圈，非常龐大，其中最重要的兩個軟體是 HDFS 分散式檔案系統 和 MapReduce 任務排程框架。 HDFS 把檔案分成塊，把塊分成三個副本放在不同的節點上，形成一個高可靠性的檔案系統，MapReduce 把我們提交的資料和處理的任務 job 拆成不同的 task 分發到不同的節點上，以實現並行的處理，MapReduce 最大的特點就是能夠把任務排程到離資料近的節點上，儘量的來減少資料在網路之間的傳輸，可以使用通用的廉價的 x86 伺服器和網路裝置來構建一個資料並行處理的系統。

Hadoop 使用的時候也有一個現實的問題：在生產環境使用的時候安裝、部署、除錯的工作很多，想要能把 Hadoop 雲化，能夠實現像 AWS 的 EMR 裡面那樣通過輕鬆的點點按鈕就能在雲端 provision 出一個 Hadoop 叢集來。那麼，實現這個目標會遇到什麼問題呢？

OpenStack 有自己的虛擬機器排程，Hadoop 裡面有自己的任務排程，這是兩個不同層次的資源排程。Hadoop 的 HDFS 的三個副本會在三個虛擬機器裡面，如果是跑在一臺物理機上，如果物理機壞了那麼三個副本就會消失，並沒有達到它的可靠性的目的。

Hadoop 社群裡面有一個開源的子專案叫作 Hadoop Virtual Extensions 簡稱 HVE，是由 VMware 主導的，主要組成部分如圖所示：

3. 基於OpenStack實現Hadoop雲化

Sahara 有兩種模式，分別從部署管理和提供資料處理服務兩個層次上對 Hadoop 雲化做了一些工作。

Hadoop 節點會利用本地磁碟來構建一個分散式檔案系統如圖所示

虛擬機器的本地根硬碟（Linux 上的 BDA）往往是臨時的，它的生命週期往往和虛擬機器的 Instance 的生命週期是一樣的，如果我們在 Hadoop 雲化的時候採用根硬碟來構建 HDFS 的話，虛擬機器就會在需要的時候建立、不需要的時候就銷燬了，那麼 HDFS 裡的資料便也會沒了，這是不行滴。我們可以有另外一種選擇：不使用根硬碟去構建 HDFS，而是使用 Cinder 提供的捲來做。但是這樣還存在一個問題，那就是 MapReduce 會盡量把資料排程到離資料近的節點上去減少網路中資料的傳輸，而 Cinder 的卷通常都是通過網路來實現的，所以它就沒有把 Hadoop 的優點利用起來，反而增加了網路的負擔。Hadoop 通常又是基於通用的商用的廉價的網路裝置來實現並行處理的，這樣勢必會降低整個 Hadoop 叢集的效能。

總結出這對矛盾就是：如果使用本地的根硬碟，它的資料會丟失；如果使用Cinder，又會給網路帶來很大的壓力，而且降低了資料處理的速度。

[ 最正確的做法應該是：]

在 Hadoop 叢集裡面仍然使用本地的根硬碟來構建 HDFS，但是把資料來源放在 Swift 裡面，也就是說我們上傳要處理的原始資料，還有要上傳要執行的 Job 的時候並不是把它存到 HDFS 裡面而是上傳到 Swift 裡面，然後Hadoop 叢集 provision 出來以後，要執行 Job 的時候再從 Swift 裡把這些資料讀出來，處理完之後再把結果儲存到 Swift 裡邊。然後由虛擬機器構建的 Hadoop 叢集就可以銷燬了，那些根硬碟同時被銷燬了也沒有關係（因為我們的資料已經在 Swift 裡面了）。如下圖所示：

Hadoop 和 Swift 的整合現在已經做到了 Hadoop 社群的開源專案裡面了。一說到 Hadoop 的雲化，不得不提到 VMware 的 BDE（Big Data Extensions），這個 BDE 和 OpenStack 的 Sahara 非常像，但是在各個方面都做得比 Sahara 好很多，而且和 HVE 的整合非常好。

4. Ceph簡介

上面說到了 Hadoop 與 OpenStack 的結合，Hadoop 經常被認為是用來作大資料處理的，大資料基礎設施的另外一方面是大資料的儲存。說到 OpenStack 的儲存，除了 Swift 以外還有 Ceph 系統。

Ceph 經常被用來作為 RBD 裝置，提供塊儲存服務從架構上來說，Ceph 從上往下分為三個層次，如圖所示：

Swift 裡面更像我們傳統說的檔案的概念，我們把檔案上傳到 Swift 裡面，作為一個物件存在那裡，這也是它跟傳統的檔案系統作區分的一個概念。Ceph 的 Object 實際上是把一個檔案給拆成了很多個 Object 分別放到底層的儲存裝置上，這個 Object 與普通的一個檔案 Object 所指的東西是完全不一樣的。其實底層實現的整個架構它的機制也是不一樣的，Ceph 最下面的一層就是 RADOS 這一套物件儲存，它本身就是一個完整的儲存系統，所有 Ceph 系統中儲存的使用者資料事實上最後都是落實到這層上來存的。Ceph 裡面所聲稱的這些高可靠性高可擴充套件性高效能高自動化等等特性也是由這層提供的，這層底層的硬體實際上是由大量的儲存節點組成的，可以是 x86 伺服器也可以是 ARM 的，它的核心是一個叫做 OSD 的東西，這個 OSD 是 Object Storage daemon。Ceph 裡面的 OSD 雖然指的是 daemon（一個軟體、一個服務程式），和 Cinder 裡面定義的 OSD（object storage device）之間有很強的對應關係，可以認為是 Object Storage Device 簡略的一個版本

[ 整個 RADOS 系統可以分為以下幾個部分：邏輯結構 ]

• OSDs 整個系統的基石
• Monitors 監控整個系統的狀態
• Clients 客戶端，如果沒有這個客戶端，整個資料的讀寫會難以實現

[ Ceph 系統中的定址流程：]

1. 把這個檔案拆成若干個 Objects
2. 把這個 Objects 放到我們的PG組裡面
3. 每個組通過一個 CRUSH 演算法給它對映到不同的 OSD 上，

有一個比較大的特點，它的每一步都是通過計算得到的，中間沒有查表，這就讓 Ceph 的擴充套件性比較好

接著

在 RADOS 上面有一個叫作 LIBRADOS 這樣一個庫，這個庫提供了一組可以直接訪問 RADOS 系統的 API，這個地方是 RADOS 不是訪問整個 Ceph。實際上說的 Ceph 的介面又是通過什麼樣的東西來提供的呢？實際上是通過再上面的一個層次，這個層次包括三個部分，一個是 RADOS 的 Gateway，第二個是 RBD 的模組，第三個是 CEPH FS（file system）。

RADOS 的 Gateway 是把底層的物件儲存系統往外再次進行封裝，提供一個相容 Swift、相容 Amazon S3 的物件儲存的介面，這個介面也是 HTTP 的，另外一部分就是我們前面說的 RBD 的塊裝置，經常被作為 Cinder 的後端給虛擬機器提供卷，第三塊是 CEPH FS ,在 Ceph 的基礎上封裝了一個 POSIX 介面，形成了一個檔案系統

Ceph 的架構、Ceph 的資料儲存流程，注意區分兩類物件儲存以及 object 在不同場合的概念的不同。

5. Ceph在OpenStack中的應用

[ Ceph受歡迎的原因：]

• 通過 Cinder 為虛擬機器提供廉價的塊儲存服務。基於 x86，搭建分散式塊儲存系統（強調是塊儲存，因為它有強一致性的要求，有高效能的要求，這些在物件儲存的裡面是沒有的，在HDFS裡面也是比較弱的）。Cinder 支援 Ceph 提供的RBD裝置，有了 Cinder 和 Ceph 的結合在搭建OpenStack叢集的時候就不用去買儲存裝置了，可以直接用Ceph基於x86硬體普通的這種伺服器，就可以搭一個塊儲存系統，提供給虛擬機器去使用（提供給虛擬機器做卷），成本低。在很多情況下，Ceph 的效能甚至超過了很多專業的儲存裝置。
• Ceph 提供 Swift 相容的物件儲存介面，如果要實施一個 OpenStack 的部署，可以用同一套儲存系統來做塊和物件的儲存，並不一定非要去安裝一套 Swift。那麼，有了 Ceph 以後還需不要 Swift？ Ceph 第一適合的是做塊儲存，是強一致性，Swift 預設是最終一致性，Swift 更符合物件儲存的場景，Swift 有針對物件儲存的先進的 Feature 比如說 Storage Policy 可以供使用者去選擇資料的儲存策略，在很多商用的物件儲存裝置裡都是沒有的，所以說 Swift 在物件儲存領域裡是非常領先的，而且天生就是支援多租戶的，與 OpenStack 的結合非常完美。
• OpenStack 所有儲存都支援 Ceph 作為後端

[ 關於對 Swift 或 Ceph 的選擇：]

案例1：規模小，節點數量少的使用 Ceph，因為 Swift 至少要用到5個節點，划不來。

案例2：需要提供雲盤的服務，做雲盤就意味著要面對大量的使用者，還希望使用者的體驗好，可以讓使用者來選擇資料怎麼存，這個時候選擇 Swift 是更好的，一方面對於這種規模化部署的支援比較好，第二方面它有一些先進的 Feature，第三方面它的價格成本比 Ceph 要低一些

6. OpenStack與Docker

Container 技術

Hypervisor 在傳統的意義上是指可以在一個宿主機上建立一個環境，這個環境裡面我們可以建立一些虛擬機器，虛擬機器裡面可以裝客戶作業系統 Guest OS ，然後這上面再裝我們的中介軟體和應用等等。其實還有另外一種虛擬化技術，就是不用在裡面再安裝 Guest OS，直接基於宿主機的作業系統來做在上面做一些運營環境的隔離，做一些資源的劃分等等，然後每一個形成一個容器，然後再讓這些應用跑到這些容器裡面，容器之間實際上底層是共享一個作業系統的，甚至可以共享一些公用的庫。和傳統的 Hypervisor 的方式來比，它有一個比較大的優勢就是省去了 Guest OS 的開銷，也有它的劣勢比如裡面只能使用和宿主機相同的作業系統，而沒有辦法再裝像 Windows 等別的作業系統，甚至是同一個作業系統的不同的版本都會很困難，因為他的底層機制就不支援在裡邊再裝一個作業系統的機制，直接用的就是宿主機的東西，這個就是我們說的 Container 技術，Linux 底下有一個比較著名的 Container 名字就直接叫作 Linux Container（LXC）

隨著 Docker 的發展，Container 技術一下就火起來了。What is Docker？（Google YI XIA NI JIU Know）

[ OpenStack 與 Docker 的結合：]

• 使用 Swift 做 Docker 映象的儲存後端
• 用 Nova 排程和管理 Docker 容器
• 使用 Heat 實現 Docker 容器
• 使用 Heat 實現 Docker 的 Orchestration
• 基於 Neutron 設計與實現適用於 Docker 的 SDN 方案
• 用 Glance 來管理 Docker 的映象