Ceph分布式存儲系統在OpenStack云平臺的設計與實現

席 磊

中國廣播電視網絡有限公司 北京市100045

引言

隨著Openstack云平臺的快速推廣實踐，其規模也逐步擴大，上層業務系統的數據總量迅速增加。傳統數據存儲方式已難以滿足當前企業對存儲系統的需求，致使存儲逐漸成為了云平臺發展的瓶頸。Ceph等基于軟件定義的分布式存儲技術打破了傳統存儲系統軟硬件緊耦合的狀況，將軟件從硬件存儲中抽象出來；將存儲作為云平臺中按需分配、實時調度的動態資源；通過文件存儲、塊存儲和對象存儲三種不同接口方式的存儲類型，支撐了云平臺的多種訪問方式；在擴展性、伸縮性、安全性和容錯機制等方面較之傳統存儲系統都有很大提升。軟件定義的分布式存儲系統正不斷替代傳統的存儲系統，成為企業構建云平臺的首選存儲架構。

Ceph是一種開源軟件定義分布式存儲系統，因為其優秀的設計理念及統一存儲（同時提供塊、對象、文件三種接口）的特點被人們接受，已發展為穩定可商用的統一存儲，得到廣泛的應用和發展，是目前云操作系統OpenStack環境下的主流存儲系統。

2 Cpeh基本原理及架構

Ceph是一種為優秀性能、可靠性和可擴展性設計的統一的、分布式的存儲系統。“統一”代表Ceph具備一套存儲系統同時提供對象、塊和文件系統三種存儲接口的能力，可滿足不同應用需求的前提下簡化部署和運維。而“分布式”則意味著真正的無中心結構和沒有理論上限的系統規模可擴展性。

Ceph是目前OpenStack社區中最受重視的存儲方案，具有諸多優勢，如擴展能力、可靠性、自維護等。文章將對Ceph的邏輯架構、核心組件、關鍵工作流程等進行扼要介紹。

2.1 Ceph的邏輯架構

Ceph的邏輯架構層次參見圖1。自下而上的三層結構分別如下。

圖1 Ceph存儲架構圖

2.1.1 RADOS基礎存儲系統

可靠、自動化、分布式的對象存儲（Reliable，Autonomic，Distributed Object Store）是Ceph集群的基礎，Ceph中的一切數據最終都以對象的形式存儲，而RADOS就是用來實現這些對象存儲的。RADOS層為數據一致性及可靠性提供保證。

2.1.2 LIBRADOS基礎庫層

LIBRADOS對RADOS進 行抽象和封裝，并向上層提供API，以便直接基于RADOS進行應用開發，實現對RADOS系統的管理和配置。

2.1.3 應用接口層

這一層包括RADOS GW（RADOS Gateway）、RBD（Reliable Block Device）和Ceph FS（Ceph File System）三個部分，在librados庫的基礎上提供抽象層次更高、更便于應用或客戶端使用的上層接口。其中，RADOS GW提供對象存儲應用開發接口，它有與Amazon S3和OpenStack Swift兼容的接口；RBD提供標準的塊設備接口，RBD類似傳統的SAN存儲，提供數據塊級別的訪問；Ceph FS提供文件存儲應用開發接口，兼容POSIX的文件系統，可以直接掛載為用戶空間文件系統。

2.2 RADOS的核心組件

Ceph的高可用、高可靠、無單點故障、分布式對象存儲等一系列特性均由RADOS提供。RADOS主要由OSD、Monitor、MDS（只有文件系統才需要）三類節點組成。

2.2.1 OSD（Ceph對象存儲設備）

OSD是Ceph集群中存儲用戶數據并響應客戶端讀操作請求的唯一組件，負責將實際數據以對象的形式存儲在Ceph集群節點的物理磁盤上，它是Ceph中最重要的一個組件。OSD的數量最多，一般與物理磁盤數量相等。OSD可以被抽象為兩個組成部分，即系統部分和守護進程（OSD deamon）部分。OSD的系統部分實際為一臺至少包括一個單核的處理器、一定數量的內存、一塊硬盤以及一張網卡的計算機。守護進程（OSD deamon）負責完成OSD的所有邏輯功能，包括與monitor和其他OSD deamon通信以維護更新系統狀態，與其他OSD共同完成數據的存儲和維護，與client通信完成各種數據對象操作。

2.2.2 Monitor（Ceph監視器）

Monitor通過一系列map（包括OSD、MONITOR、PG、CRUSH、CLUSTER等的map）跟蹤并維護整個集群的狀態，Monitor不實際存儲數據，其數量較OSD少很多。

2.2.3 MDS（元數據服務器）

MDS元數據服務器不直接提供任何數據，數據都由OSD為客戶端提供。MDS用于緩存和同步分布式元數據，管理文件系統的名稱空間。

2.3 Ceph數據存儲流程

先介紹幾個概念：

（1）File：客戶端需要存儲或者訪問的對象文件。

（2）Ojbect：RADOS所 看到的“對象”。RADOS將File切分成統一大小得到的對象文件，以便實現底層存儲的組織管理。

（3）PG（Placement Group，歸置組）：對object的存儲進行組織和位置映射，可理解為一個邏輯容器，包含多個Ojbect，同時映射到多個OSD上，一個PG會被映射到n個OSD上，而每個OSD上都會承載大量的PG，PG和OSD之間是“多對多”映射關系。PG是Ceph實現可伸縮性及高性能的關鍵，沒有PG而直接在OSD上對數百萬計的對象進行復制和傳播既困難又消耗計算資源。

RADOS尋址過程中的三次映射如圖2所示，分別是：File到Object的映射、Object到PG的映射、PG到OSD的映射。

圖2 Ceph存儲流程示意圖

2.3.1 File到object映射

這次映射將用戶操作的file映射為RADOS能夠處理的Object。

Client客戶端先聯系Monitor節點并獲取cluster map副本，通過map得到集群的狀態和配置信息；將文件轉換為size一致、可以被RADOS高效管理的Object，一份Object擁有一個ID號。

2.3.2 Object到PG映射

通過將對象oid和PG共同經過哈希函數計算，確認對象Object存放在哪個PG中，實現Object和PG之間的近似均勻映射。Object和PG是多對一的關系。

2.3.3 PG到OSD映射

這次映射通過Crush算法將PG映射給存取數據的主OSD中，主OSD再備份數據到輔助OSD中。PG和OSD是多 對 多 的關系。至此，Ceph完成了從File到Object、PG和OSD的 三 次 映射過程，整個過程中客戶端通過自身計算資源進行尋址，無需訪問元數據服務器查表的數據尋址機制，實現去中心化，避免了單點故障、性能瓶頸、伸縮的物理限制，這種數據存儲和取回機制是Ceph獨有的。

3 Ceph分布式存儲的設計與實現

大規模Ceph分布式存儲系統的規劃設計及實現是一個復雜的過程，要考慮的問題很多，如不同類型（塊、文件、對象）存儲接口的選擇、存儲網絡設計規劃、Ceph的對接方案、硬件配置如何在性能和成本之間取得平衡等等一系列問題，而這些都需在充分了解平臺自身業務特性的基礎上，提出個性化的解決方案。下面對Ceph在OpenStack云平 臺 中的 設計、優化改進及部署實現進行論述。

3.1 基于ISCSI的Ceph塊存儲實現

ISCSI（Internet Small Computer System Interface）是 一 種成熟的技術方式，常見的各種系統（包括操作系統和應用系統）一般都對ISCSI有很好的支持。

Ceph集群支持三種形式的存儲接口：文件、對象、塊，其中塊接口（RBD）與SCSI塊設備讀寫所要求的接口一致，因此可以作為ISCSI服務的后端存儲設備。基于ISCSI的Ceph塊存儲在OpenStack云平臺中的實現方法，對接方式為Ceph分布式塊存儲集群通過ISCSI對接虛擬化層，虛擬化層再通過相應驅動 對 接OpenStack的Cinder、Nova組件，為虛擬機提供本地系統和數據盤服務。

ISCSI是 一 種SAN（Storage area network）協議，使用TCP/IP協議來傳遞SCSI命令與響應，它定義了SCSI指令集在IP網絡中傳輸的封裝方式。ISCSI為C/S結構，客戶端稱為Initiator，服務端稱為target。

3.1.1 ISCSI target

即磁盤陣列或其他裝有磁盤的存儲設備。它是一個端點，不啟動會話，而是等待發起者的命令，并提供所需的輸入/輸出數據傳輸。

3.1.2 ISCSI initiator

就是能夠使用target的客戶端，它是啟動SCSI會話的端點，發送SCSI命令，通常是服務器。也就是說，想要連接到ISCSI target的服務器，必須安裝ISCSI initiator的相關功能才能夠使用ISCSI target提供的硬盤。

Ceph基 于ISCSI協 議 對 接 虛擬化層的邏輯架構分為三層，分別是ISCSI客戶端（計算節點）、ISCSI網關、Ceph集群。ISCSI target對 接Ceph的RBD接口，為上層計算節點ISCSI initiator提供服務，實現計算節點通過ISCSI訪問底層存儲，進行卷的創建、修改、刪除等管理性操作。如圖3所示。

圖3 ISCSI協議使用Ceph RBD基本架構圖

圖4 ceph存儲網絡系統網絡拓撲圖

3.2 巧用Crush分組，避免存儲后端網絡瓶頸

在存儲網絡規劃中，首先需將各網絡平面分開，一般劃分4張網絡平面，分別是IPMI管理網、千兆帶內管理網、存儲前端網絡（萬兆）、存儲后端網絡（萬兆）。IPMI管理網及千兆帶內管理網流量較低，我們不做討論。不論是存儲前端或后端網絡，一般情況下依據各分布式存儲集群的數量，每個集群后端采用數量不等的48口萬兆交換機采用兩兩級聯的方式提供服務，網口采用雙網口綁定Bond4的方式提供。其中，存儲后端網絡由于存在大量的數據重構，流量極高，需要進行針對性的設計考慮。下面介紹一種在大規模Ceph集群組網過程中，利用Crush分組機制避免交換機成為后端網絡瓶頸的設計思路。

對于節點數量少于48的分布式存儲集群，使用2臺48口萬兆交換機AB即可，AB之間使用主備模式，各節點的兩萬兆后端網絡也使用bond4模式進行雙上聯，后端網絡的重構數據不會跨交換機流動。

但對于節點數量大于48而小于96的分布式存儲集群，存儲后端存儲網絡共使用4臺48口萬兆交換機ABCD，使用2根40Gb/s級聯線將交換機AB連接一起做堆疊，交換機CD之間同理，這種情況下，后端網絡的重構數據將在交換機AB之間流動，極端情況下可能形成網絡擁塞。

針對該問題，可以通過Ceph分布式集群進行Crush分組進行規避。以集群規模為60節點為例，按照20節點為一組，分為三組，仍提供一個數據存儲池。其中前2組連接一個萬兆交換機A，第三組連接第二個萬兆交換機B，A與B使用兩根40Gb/s級 聯線 連 接，Crush分 組原理決定了各個分組之間幾乎沒有數據流動，因為一份數據的副本或糾刪塊均在一個組內。所以兩交換機之間的級聯線只會有心跳數據通過，不會存在業務數據量通過，也就不會成為網絡瓶頸。如圖5所示。

圖5 Ceph存儲后端網絡示意圖

3.3 SSD+HDD靈活混搭，匹配全業務需求

要滿足虛擬機上各業務系統對所掛載的云硬盤差異化性能需求，如對IO需求、延遲大小、網絡吞吐能力、并發訪問等，使用單一配置的Ceph存儲節點難以達到要求，建議在官方文檔提倡使用SSD+HDD混搭的模式的基礎上，將SSD和HDD以不同比例進行混搭，形成不同能力的存儲資源池，從而在性能和成本之間取得平衡。具體項目中可通過調整Ceph分布式塊存儲集群Crush-Map，設置Crush ruleset來將不同類型磁盤劃分到同一個存儲資源池，從而制作成高速（highpool）、中速（midpool）、低速（lowpool）三組邏輯存儲池，對外提供不同性能的云硬盤服務；并結合基于帶寬、IOPS兩種策略的QoS，達到更加合理、均衡的使用塊存儲服務。

3.4 小文件聚合存儲，優化存儲性能

如果存儲系統中存在海量小文件，每個小文件存儲都會執行一次全寫流程，當大量小文件并發訪問時，將導致磁盤壓力加劇，Ceph系統性能下降。

針對該問題，可設計一種將小文件聚合存儲的功能，將小對象聚合為大的，基本思路是將新創建的小文件以緊密排列的方式（以4KB對齊）寫入到一類特殊的文件（聚合文件）中。在讀文件時也不再讀取小文件的對象，而是從聚合文件的對象中讀取源文件數據，每個聚合文件包含多個聚合對象（4MB）。客戶端發送的讀請求會將小文件所在對象讀入緩存，提高后續小文件的緩存命中率，有效地縮短了I/O路徑。

小文件聚合存儲有效降低小文件寫入磁盤次數、減輕寫數據壓力；方便落盤和減少磁盤碎片化，同時提升小IO的性能；提高磁盤使用率，讀小文件時將所在對象讀入緩存，提高讀命中率、縮短讀I/O路徑。

結束語

總體而言，Ceph作為目前OpenStack環境下的最受關注的存儲系統，通過有針對性的設計與優化，可以滿足Iaas平臺對于存儲系統的需求。但Ceph在管理便捷性、性能優化、業務場景適配等方面仍有許多可發掘的空間，同時企業對于自身存儲需求也需要不斷的發掘，最終使Ceph性能得以最大化，為企業提供更加穩定可靠的存儲服務。