Ceph RadosGW 對象存儲集群的部署與優化

陳陽，王丹

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

0 引言

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

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

1 Ceph的基本架構

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

圖1 Ceph基本架構

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

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

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

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

2 高可用的RadosGW部署架構

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

圖2 RadosGW集群部署架構

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

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

3 異構存儲環境下的優化

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

3.1 RadosGW數據類型與存儲方式

（1）Rados 對象

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

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

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

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

（2）RadosGW 對象

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

圖3 RadosGW對象的存儲結構

（3）存儲桶索引

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

3.2 異構環境下的數據放置策略

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

圖4 數據放置策略

（1）使用SSD 存儲Key-value 數據

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

（2）使用HDD 驅動器存儲data 數據

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

（3）使用SSD 存儲Bluestore 的WAL 數據

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

4 結語

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