陳陽，王丹

（1.四川大學計算機學院，成都610065；2.中國核動力研究設計院，成都610213）

0 引言

Ceph 誕生于2003 年，由加州大學Sage Weil 作為其博士學位項目開發(fā)，2006 年Ceph 通過LGPL 協(xié)議正式開源。經(jīng)過全世界科研工作者和開源社區(qū)十余年的迭代開發(fā)，Ceph 從最初單一的分布式文件系統(tǒng)，成長為可以同時支持文件存儲、對象存儲、塊存儲的，并具有高性能、高可靠性、高擴展的分布式存儲系統(tǒng)。

對象存儲作為云計算IaaS 層面的基礎服務，通過扁平化的結(jié)構(gòu)，提供了海量數(shù)據(jù)存儲、無限擴容等能力，被各大云計算廠商推薦用于存儲海量非結(jié)構(gòu)化數(shù)據(jù)。RadosGW 作為Ceph 的重要組件之一，對用戶提供了兼容S3、Swift 對象存儲協(xié)議的RESTful 網(wǎng)關(guān)，并被廣泛的用于私有云對象存儲系統(tǒng)的核心解決方案。雖然RadosGW 已經(jīng)提供了完整的兼容S3 以及Swift協(xié)議的對象存儲接口，但是在實際的部署以及集群調(diào)優(yōu)過程中，仍然面臨不小的挑戰(zhàn)。本文則從Ceph 基本架構(gòu)的角度出發(fā)，提出一種高可用的集群部署方案，并根據(jù)RadosGW 數(shù)據(jù)存儲結(jié)構(gòu)以及存儲引擎的基本特性角度出發(fā)，對RadosGW 集群的性能進行優(yōu)化。

1 Ceph的基本架構(gòu)

Ceph 分布式存儲系統(tǒng)的基本架構(gòu)如圖1 所示，從整體來看可以分為Rados 以及Cliens 兩個部分。其中，Rados 是一個完整的對等節(jié)點分布式存儲系統(tǒng)，數(shù)據(jù)均以對象的形式存儲與Rados 集群中。Rados 實現(xiàn)了對象的分布式存儲、數(shù)據(jù)冗余、故障恢復以及集群狀態(tài)監(jiān)控等存儲系統(tǒng)的核心功能。Ceph 項目中提供了三個Clients，分別是提供文件存儲服務的MDS（Meta Data Server）、提供對象存儲服務的RadosGW（Rados Gateway）以及提供塊存儲服務的RBD（Rados Block Device），均可以根據(jù)需要單獨部署。Clients 通過librados訪問底層Rados 集群，將數(shù)據(jù)持久化到Rados 集群中。通過使用librados，可以迅速將Rados 作為基本分布式存儲引擎，擴展自己的存儲相關(guān)應用。

圖1 Ceph基本架構(gòu)

Rados 的核心組件包括Monitor、OSD。其中：

（1）Monitor：監(jiān)控整個集群的健康狀態(tài)，保存了Rados 集群CRUSH Map、PG Map、OSD Map 等集群拓撲數(shù)據(jù)。Monitor 之間采用主備模式，通過Paxos 協(xié)議選舉確定主Monitor。各Monitor 之間的數(shù)據(jù)也通過Paxos協(xié)議確保一致性。

（2）OSD（Object Storage Device）：管理物理存儲介質(zhì)，提供了的數(shù)據(jù)存儲、數(shù)據(jù)恢復等基本功能。通常情況下一個物理磁盤對應一個OSD 進程，或者一個分區(qū)對應一個OSD 進程。Rados 層的對象通過將對象Key做Hash 運算再取模的方式，分布到邏輯結(jié)構(gòu)PG 之中，PG 再次通過CRUSH 算法[1]，被分布到實際的OSD中。OSD 可選擇配置兩種不同類型的存儲后端，即Filestore 以及Bluestore。Filestore 將數(shù)據(jù)以文件的形式存儲于文件系統(tǒng)中；Bluestore 直接接管塊設備，上層業(yè)務對數(shù)據(jù)的訪問不會經(jīng)過文件系統(tǒng)等中間層。

Ceph 通過Rados 層實現(xiàn)分布式系統(tǒng)的核心功能，并通過librados 擴展外部應用的方式實現(xiàn)了底層存儲引擎與Clients 之間的解耦。同時，在Clients 層相關(guān)應用的設計也支持分布式的高可用部署模式。

2 高可用的RadosGW部署架構(gòu)

在部署RadosGW 集群的時，高可用性是集群架構(gòu)設計中需要著重考慮的因素，即當物理主機發(fā)生節(jié)點故障后，是否會影響整個服務的可用性。同時，也需要充分考慮集群節(jié)點維護是否會對服務的可用性產(chǎn)生影響。針對Ceph 集群的特點，圖2 提出一種典型的RadosGW 集群部署架構(gòu)。

圖2 RadosGW集群部署架構(gòu)

Rados 層，從數(shù)據(jù)可用性角度來看，Rados 實現(xiàn)了對象的分布式存儲以及數(shù)據(jù)冗余，通過合理的設置冗余規(guī)則，可以做到在OSD 主機或存儲介質(zhì)損壞時，集群能通過冗余副本對對象數(shù)據(jù)進行恢復保證了數(shù)據(jù)的可用性；由于Monitor 采用Paxos 一致性協(xié)議[2]，為了保證算法正常工作，需要保證Monitor 數(shù)量為基數(shù)，3 臺Monitor 既保證Monitor 的高可用性，也滿足Paxos 協(xié)議的要求。同時從節(jié)約成本的角度考慮，Monitor 實例可以和OSD 實例在同一臺主機上混合部署；其余的OSD主機，根據(jù)規(guī)劃容量進行部署，集群需要擴容時，可動態(tài)增加OSD 主機數(shù)量，滿足橫向擴展的要求。

Clients 層，采用了兩個RadosGW 實例，兩個實例之間采用主備模式，通過Keepalived[3]保持兩個實例之間的心跳檢測?？蛻舳送ㄟ^VIP 訪問RESTful 接口，當主節(jié)點故障時，備節(jié)點會主動接管主節(jié)點的VIP，從而將客戶請求引導至備節(jié)點，從而避免RadosGW 實例產(chǎn)生單點故障，保證了集群的高可用性。

3 異構(gòu)存儲環(huán)境下的優(yōu)化

對于存儲系統(tǒng)而言，更換性能更高的存儲介質(zhì)，可以帶來顯著的效果提升。傳統(tǒng)的HDD 驅(qū)動器因其機械結(jié)構(gòu)的限制，在隨機小I/O 的場景下性能低下，即使在順序I/O 的場景下，與SSD 驅(qū)動器相比也有數(shù)倍的差距。近年來SSD 驅(qū)動器發(fā)展迅速，但是“容量價格比”仍遠高于傳統(tǒng)HDD 驅(qū)動器。因此完全采用SSD 驅(qū)動器會使存儲系統(tǒng)的成本顯著的增加。異構(gòu)存儲的方案，通過分析RadosGW 數(shù)據(jù)的存儲結(jié)構(gòu)，可以根據(jù)不同數(shù)據(jù)的類型，靈活安排各類數(shù)據(jù)的存儲介質(zhì)進行分層存儲，使整個存儲系統(tǒng)在性能和價格之間找到平衡點。

3.1 RadosGW數(shù)據(jù)類型與存儲方式

（1）Rados 對象

Rados 的每一個對象包含3 種類型的數(shù)據(jù)。分別為xattrs、omap 以及data，其中：

①xattrs：對象擴展屬性，在Rados 采用Filestore 后端時，存儲于文件系統(tǒng)擴展屬性中；在采用Bluestore 后端時，以Key-value 的形式存儲于Kv 數(shù)據(jù)庫中（Rocks-DB 或LevelDB）。

②omap：與對象擴展屬性相似，但無論采用何種后端，均存儲于Kv 數(shù)據(jù)庫中。

③data：對象的數(shù)據(jù)，在采用Filestore 后端時，data部分以文件的形式存儲于文件系統(tǒng)當中；在采用Bluestore 后端時，直接存儲在物理介質(zhì)上。

（2）RadosGW 對象

為了避免訪問產(chǎn)生熱點，并增加對象并行讀寫效率，RadosGW 會將用戶對象拆分為多個Rados 對象后再存入Rados 集群中。如圖3 所示，用戶的對象會被拆分為一個Head Object 與不等數(shù)量的Shadow Objects進行存儲。其中Head Object 中除了保存數(shù)據(jù)之外，同時再對象xattrs 中存放了對象的相關(guān)屬性，如：對象大小、修改時間、acl 控制信息、manifest 等，并通過manifest 信息指向了對象的Shadow Objects。Shadow Object只在data 部分存有數(shù)據(jù)，xattrs 與omap 數(shù)據(jù)為空。

圖3 RadosGW對象的存儲結(jié)構(gòu)

（3）存儲桶索引

存儲桶是用戶存放對象的基本單元，RadosGW 為每一個用戶的桶維護了一套索引信息，主要存放了對象的Key 以及對象的Size 信息。存儲桶的索引信息，保存在存儲桶對應索引對象的omap 結(jié)構(gòu)中，其實質(zhì)則是以Key-value 的形式存儲于Kv 數(shù)據(jù)庫中。為了避免寫入時，多個并發(fā)請求對索引對象的對象鎖爭用現(xiàn)象從而引起熱點問題，RadosGW 支持一個存儲桶對應多個索引對象，單個對象的索引信息通過對對象Key進行Hash 運算后，被映射到不同的索引對象中存放。

3.2 異構(gòu)環(huán)境下的數(shù)據(jù)放置策略

Bluestore 支持靈活的配置block.db、block.data、block.wal 三個分區(qū)對應的物理塊設備。其中block.data分區(qū)存儲Rados 對象的data 數(shù)據(jù)；block.db 分區(qū)存儲Rados 對象的xattrs、omap 數(shù)據(jù)，其實質(zhì)是將Key-value 數(shù)據(jù)存放于Kv 數(shù)據(jù)庫中，可選擇RocksDB 或者LevelDB。如圖4 所示，通過對SSD 驅(qū)動器劃分多個分區(qū)的方式，達到使用單塊SSD 驅(qū)動器存放多個OSD 的block.db、block.wal 數(shù)據(jù)的目的，從而實現(xiàn)下列的優(yōu)化措施。

圖4 數(shù)據(jù)放置策略

（1）使用SSD 存儲Key-value 數(shù)據(jù)

RadosGW 構(gòu)建的對象存儲系統(tǒng)中，相較于RBD 構(gòu)建的塊存儲系統(tǒng)，一個顯著的特點是存在大量的Keyvalue 鍵值對，如對象xattrs 數(shù)據(jù)，存儲桶索引等。不同于對象data 數(shù)據(jù)大部分是連續(xù)的數(shù)據(jù)，Key-value 數(shù)據(jù)是高度離散化的，會帶來大量隨機I/O。在Rados 層使用Bluestore 后端存儲時，這些數(shù)據(jù)實質(zhì)上存儲于Kv數(shù)據(jù)庫，如RocksDB 中。雖然RocksDB 采用LSMTree[4]的存儲結(jié)構(gòu)，將眾多隨機寫入轉(zhuǎn)換成順序?qū)懭?，但是compaction 過程仍然會帶來顯著的I/O 開銷。因此針對Key-value 數(shù)據(jù)的存儲，使用SSD 驅(qū)動器較于HDD 驅(qū)動器會獲得顯著的性能提升。

（2）使用HDD 驅(qū)動器存儲data 數(shù)據(jù)

對象的data 數(shù)據(jù)以二進制形式保存，數(shù)據(jù)是連續(xù)的，在數(shù)據(jù)寫入驅(qū)動器的過程中是順序I/O。HDD 驅(qū)動器因其機械結(jié)構(gòu)的原因，在處理順序I/O 的時尋道時延較處理隨機I/O 時大大減小，順序I/O 的處理效率遠高于隨機I/O 的效率。同時，對象的data 數(shù)據(jù)的數(shù)據(jù)量遠遠高于xattrs 數(shù)據(jù)與omap 數(shù)據(jù)的數(shù)據(jù)量，采用SSD 驅(qū)動器存儲data 數(shù)據(jù)，在成本上不具有優(yōu)勢，所以對象data 數(shù)據(jù)適合采用HDD 驅(qū)動器存儲。

（3）使用SSD 存儲Bluestore 的WAL 數(shù)據(jù)

在數(shù)據(jù)落盤的整個流程中，會經(jīng)歷數(shù)據(jù)落盤、更新索引信息等多個階段。在整個寫入過程中如果因為磁盤故障、主機宕機等不可預期事件的發(fā)生，導致寫入流程沒有經(jīng)歷完所有階段即被打斷，則會造成磁盤臟數(shù)據(jù)的產(chǎn)生。Bluestore 后端在寫入數(shù)據(jù)時將寫入操作封裝成完整事物預先寫入到WAL 中，在進行落盤操作有故障發(fā)生時，可以通過重放WAL 達到恢復的目的，保證了數(shù)據(jù)寫入的原子性。WAL 數(shù)據(jù)量較小，可以通過將WAL 數(shù)據(jù)存儲于SSD 驅(qū)動器的方式來加速Bluestore 的寫入過程。

4 結(jié)語

基于Ceph RadosGW 的對象存儲系統(tǒng)，因其高性能、高可靠性以及高可擴展性的特點，適用于企業(yè)私有云環(huán)境對象存儲系統(tǒng)的構(gòu)建。針對Ceph 集群本身的特點，合理設計集群物理架構(gòu)，可以消除單點故障實現(xiàn)服務的高可用性，減少故障時間；采用異構(gòu)存儲架構(gòu)并合理配置不同類型數(shù)據(jù)的存儲介質(zhì)，能夠在可控的成本范圍內(nèi)，提升集群性能，滿足企業(yè)日常應用的需求。