1. 介紹

雲硬碟是IaaS雲平臺的重要組成部分，雲硬碟給虛擬機器提供了持久的塊儲存裝置。目前的AWS 的EBS(Elastic Block store)給Amazon的EC2例項提供了高可用高可靠的塊級儲存卷，EBS適合於一些需要訪問塊裝置的應用，比如資料庫、檔案系統等。 在OpenStack中，可以使用Ceph、Sheepdog、GlusterFS作為雲硬碟的開源解決方案，下面我們來了解Ceph的架構。

Ceph是統一儲存系統，支援三種介面。

• Object：有原生的API，而且也相容Swift和S3的API
• Block：支援精簡配置、快照、克隆
• File：Posix介面，支援快照

Ceph也是分散式儲存系統，它的特點是：

• 高擴充套件性：使用普通x86伺服器，支援10~1000臺伺服器，支援TB到PB級的擴充套件。
• 高可靠性：沒有單點故障，多資料副本，自動管理，自動修復。
• 高效能：資料分佈均衡，並行化度高。對於objects storage和block storage,不需要元資料伺服器。

2. 背景

目前Inktank公司掌控Ceph的開發，但Ceph是開源的，遵循LGPL協議。Inktank還積極整合Ceph和其他雲端計算和大資料平臺，目前Ceph支援OpenStack、CloudStack、OpenNebula、Hadoop等。

當前Ceph的最新穩定版本0.67(Dumpling),它的objects storage和block storage已經足夠穩定，而且Ceph社群還在繼續開發新功能，包括跨機房部署和容災、支援Erasure encoding等。Ceph具有完善的社群設施和釋出流程

目前Ceph有很多使用者案列，這是2013.03月Inktank公司在郵件列表中做的調查，共收到了81份有效反饋[2]。從調查中可以看到有26%的使用者在生產環境中使用Ceph，有37%的使用者在私有云中使用Ceph，還有有16%的使用者在公有云中使用Ceph。

 
目前Ceph最大的使用者案例是Dreamhost的Object Service，目前總容量是3PB，可靠性達到99.99999%，資料存放採用三副本，它的價格比S3還便宜。下圖中，左邊是Inktank的合作伙伴，右邊是Inktank的使用者。

3. 架構

3.1 元件

Ceph的底層是RADOS，它的意思是“A reliable, autonomous, distributed object storage”。 RADOS由兩個元件組成：

• OSD： Object Storage Device，提供儲存資源。
• Monitor：維護整個Ceph叢集的全域性狀態。

RADOS具有很強的擴充套件性和可程式設計性，Ceph基於RADOS開發了
Object Storage、Block Storage、FileSystem。Ceph另外兩個元件是：

• MDS：用於儲存CephFS的元資料。
• RADOS Gateway：對外提供REST介面，相容S3和Swift的API。

3.2 對映

Ceph的名稱空間是 (Pool, Object)，每個Object都會對映到一組OSD中(由這組OSD儲存這個Object)：

(Pool, Object) → (Pool, PG) → OSD set → Disk

Ceph中Pools的屬性有：

• Object的副本數
• Placement Groups的數量
• 所使用的CRUSH Ruleset

在Ceph中，Object先對映到PG(Placement Group)，再由PG對映到OSD set。每個Pool有多個PG，每個Object通過計算hash值並取模得到它所對應的PG。PG再對映到一組OSD（OSD的個數由Pool 的副本數決定），第一個OSD是Primary，剩下的都是Replicas。

資料對映(Data Placement)的方式決定了儲存系統的效能和擴充套件性。(Pool, PG) → OSD set 的對映由四個因素決定：

• CRUSH演算法：一種偽隨機演算法。
• OSD MAP：包含當前所有Pool的狀態和所有OSD的狀態。
• CRUSH MAP：包含當前磁碟、伺服器、機架的層級結構。
• CRUSH Rules：資料對映的策略。這些策略可以靈活的設定object存放的區域。比如可以指定 pool1中所有objecst放置在機架1上，所有objects的第1個副本放置在機架1上的伺服器A上，第2個副本分佈在機架1上的伺服器B上。 pool2中所有的object分佈在機架2、3、4上，所有Object的第1個副本分佈在機架2的伺服器上，第2個副本分佈在機架3的服 器上，第3個副本分佈在機架4的伺服器上。

Client從Monitors中得到CRUSH MAP、OSD MAP、CRUSH Ruleset，然後使用CRUSH演算法計算出Object所在的OSD set。所以Ceph不需要Name伺服器，Client直接和OSD進行通訊。虛擬碼如下所示：

  locator = object_name
  obj_hash = hash(locator)
  pg = obj_hash % num_pg
  osds_for_pg = crush(pg)  # returns a list of osds
  primary = osds_for_pg[0]
  replicas = osds_for_pg[1:]

這種資料對映的優點是：

• 把Object分成組，這降低了需要追蹤和處理metadata的數量(在全域性的層面上，我們不需要追蹤和處理每個object的metadata和placement，只需要管理PG的metadata就可以了。PG的數量級遠遠低於object的數量級)。
• 增加PG的數量可以均衡每個OSD的負載，提高並行度。
• 分隔故障域，提高資料的可靠性。

3.3 強一致性

• Ceph的讀寫操作採用Primary-Replica模型，Client只向Object所對應OSD set的Primary發起讀寫請求，這保證了資料的強一致性。
• 由於每個Object都只有一個Primary OSD，因此對Object的更新都是順序的，不存在同步問題。
• 當Primary收到Object的寫請求時，它負責把資料傳送給其他Replicas，只要這個資料被儲存在所有的OSD上時，Primary才應答Object的寫請求，這保證了副本的一致性。

3.4 容錯性

在分散式系統中，常見的故障有網路中斷、掉電、伺服器宕機、硬碟故障等，Ceph能夠容忍這些故障，並進行自動修復，保證資料的可靠性和系統可用性。

• Monitors是Ceph管家，維護著Ceph的全域性狀態。Monitors的功能和zookeeper類似，它們使用Quorum和Paxos演算法去建立全域性狀態的共識。
• OSDs可以進行自動修復，而且是並行修復。

故障檢測：

OSD之間有心跳檢測，當OSD A檢測到OSD B沒有迴應時，會報告給Monitors說OSD B無法連線，則Monitors給OSD B標記為down狀態，並更新OSD Map。當過了M秒之後還是無法連線到OSD B，則Monitors給OSD B標記為out狀態(表明OSD B不能工作），並更新OSD Map。

備註：可以在Ceph中配置M的值。

故障恢復：

1. 當某個PG對應的OSD set中有一個OSD被標記為down時(假如是Primary被標記為down，則某個Replica會成為新的Primary，並處理所有讀寫 object請求)，則該PG處於active+degraded狀態，也就是當前PG有效的副本數是N-1。
2. 過了M秒之後，假如還是無法連線該OSD，則它被標記為out，Ceph會重新計算PG到OSD set的對映(當有新的OSD加入到叢集時，也會重新計算所有PG到OSD set的對映)，以此保證PG的有效副本數是N。
3. 新OSD set的Primary先從舊的OSD set中收集PG log，得到一份Authoritative History(完整的、全序的操作序列)，並讓其他Replicas同意這份Authoritative History(也就是其他Replicas對PG的所有objects的狀態達成一致)，這個過程叫做Peering。
4. 當Peering過程完成之後，PG進 入active+recoverying狀態，Primary會遷移和同步那些降級的objects到所有的replicas上，保證這些objects 的副本數為N。

4. 優點

4.1 高效能

• Client和Server直接通訊，不需要代理和轉發
• 多個OSD帶來的高併發度。objects是分佈在所有OSD上。
• 負載均衡。每個OSD都有權重值(現在以容量為權重)。
• client不需要負責副本的複製(由primary負責),這降低了client的網路消耗。

4.2 高可靠性

• 資料多副本。可配置的per-pool副本策略和故障域佈局，支援強一致性。
• 沒有單點故障。可以忍受許多種故障場景；防止腦裂；單個元件可以滾動升級並在線替換。
• 所有故障的檢測和自動恢復。恢復不需要人工介入，在恢復期間，可以保持正常的資料訪問。
• 並行恢復。並行的恢復機制極大的降低了資料恢復時間，提高資料的可靠性。

4.2 高擴充套件性

• 高度並行。沒有單箇中心控制組件。所有負載都能動態的劃分到各個伺服器上。把更多的功能放到OSD上，讓OSD更智慧。
• 自管理。容易擴充套件、升級、替換。當元件發生故障時，自動進行資料的重新複製。當元件發生變化時(新增/刪除)，自動進行資料的重分佈。

5. 測試

使用fio測試RBD的IOPS，使用dd測試RBD的吞吐率，下面是測試的引數：

• fio的引數：bs=4K, ioengine=libaio, iodepth=32, numjobs=16, direct=1
• dd的引數：bs=512M,oflag=direct

我們的測試伺服器是AWS上最強的例項：

• 117GB記憶體
• 雙路 E5-2650,共16核
• 24 * 2TB 硬碟

伺服器上的作業系統是Ubuntu 13.04，安裝Ceph Cuttlefish 0.61版，副本數設定為2，RBD中的塊大小設定為1M。為了對比，同時還對軟體RAID10進行了測試。下面表格中的效能比是Ceph與RAID10效能之間的比較。

5.1 注意

因為使用的是AWS上的虛擬機器，所以它(Xen)掛載的磁碟都是設定了Cache的。因此下面測試的資料並不能真實反應物理磁碟的真實效能，僅供與RAID10進行對比。

5.2 IOPS

5.3 吞吐率

5.4 結果分析

從測試結果中，我們看到在單機情況下，RBD的效能不如RAID10，這是為什麼？我們可以通過三種方法找到原因：

• 閱讀Ceph原始碼，檢視I/O路徑
• 使用blktrace檢視I/O操作的執行
• 使用iostat觀察硬碟的讀寫情況

RBD的I/O路徑很長，要經過網路、檔案系統、磁碟：

Librbd -> networking -> OSD -> FileSystem -> Disk

Client的每個寫操作在OSD中要經過8種執行緒，寫操作下發到OSD之後，會產生2~3個磁碟seek操作：

• 把寫操作記錄到OSD的Journal檔案上(Journal是為了保證寫操作的原子性)。
• 把寫操作更新到Object對應的檔案上。
• 把寫操作記錄到PG Log檔案上。

我使用fio向RBD不斷寫入資料，然後使用iostat觀察磁碟的讀寫情況。在1分鐘之內，fio向RBD寫入了3667 MB的資料，24塊硬碟則被寫入了16084 MB的資料，被讀取了288 MB的資料。

向RBD寫入1MB資料 = 向硬碟寫入4.39MB資料 + 讀取0.08MB資料

6. 結論

在單機情況下，RBD的效能不如傳統的RAID10，這是因為RBD的I/O路徑很複雜，導致效率很低。但是Ceph的優勢在於它的擴充套件性，它的效能會隨著磁碟數量線性增長，因此在多機的情況下，RBD的IOPS和吞吐率會高於單機的RAID10(不過效能會受限於網路的頻寬)。

如前所述，Ceph優勢顯著，使用它能夠降低硬體成本和運維成本，但它的複雜性會帶來一定的學習成本。

Ceph的特點使得它非常適合於雲端計算，那麼OpenStack使用Ceph的效果如何？下期《Ceph與OpenStack》將會介紹Ceph的自動化部署、Ceph與OpenStack的對接。