Ceph架構剖析

來源：UnitedStack有云  做者：朱榮澤

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具備完善的社區設施和發佈流程[1](每三個月發佈一個穩定版本) 。

目前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 StorageDevice，提供存儲資源。

·        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(PlacementGroup)，再由PG映射到OSD set。每一個Pool有多個PG，每一個Object經過計算hash值並取模獲得它所對應的PG。PG再映射到一組OSD（OSD的個數由Pool 的副本數決定），第一個OSD是Primary，剩下的都是Replicas。

數據映射(Data Placement)的方式決定了存儲系統的性能和擴展性。(Pool, PG) → OSDset 的映射由四個因素決定：

·        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，獲得一份AuthoritativeHistory(完整的、全序的操做序列)，並讓其餘Replicas贊成這份AuthoritativeHistory(也就是其餘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.3 高擴展性

·        高度並行。沒有單箇中心控制組件。全部負載都能動態的劃分到各個服務器上。把更多的功能放到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

磁盤數	隨機寫			隨機讀
	Ceph	RAID10	性能比	Ceph	RAID10	性能比
24	1075	3772	28%	6045	4679	129%
12	665	1633	40%	2939	4340	67%
6	413	832	49%	909	1445	62%
4	328	559	58%	666	815	81%
2	120	273	43%	319	503	63%

5.3 吞吐率

磁盤數	順序寫(MB/S)			順序讀(MB/S)
	Ceph	RAID10	性能比	Ceph	RAID10	性能比
24	299	879	33%	617	1843	33%
12	212	703	30%	445	1126	39%
6	81	308	26%	233	709	32%
4	67	284	23%	170	469	36%
2	34	153	22%	90	240	37%

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的對接。

 

[1]  http://www.ustack.com/blog/ceph-distributed-block-storage/#2_Ceph

[2]  http://ceph.com/community/results-from-the-ceph-census/

 

本文來源：UnitedStack有云