Ceph是呼聲很高的開源分散式的SDS產品儲存系統。同時提供物件儲存、塊儲存和檔案系統儲存三種功能，滿足不同應用需求。Ceph使用C++語言開發，遵循LGPL協議開源。Sage Weil(Ceph論文發表者)於2011年創立了以Inktank公司主導Ceph的開發和社群維護。2014年Redhat收購 inktank公司，併發布Inktank Ceph企業版，業務場景聚焦雲、備份和歸檔，支援物件和塊儲存應用。從此出現Ceph開源社群版本和Redhat企業版。

      OceanStor 9000是國內比較流行的商業分散式檔案系統，基於華為上一代CSS-F海量儲存系統而演進，在架構上拋棄了元資料節點，從而採用分散式全對稱架構。在媒資、高效能運算、大資料和視訊監控都有很多成功案例和交付經驗。今天我們花點時間討論下Ceph和9000儲存架構、應用場景和相容性等方面的差異。

Cehp的基礎服務架構

      Cehp的基礎服務架構主要包括了ObjectStorage Device(OSD)，Monitor和MDS。基於此，Ceph提供了Librados原生物件基礎庫、Librbd塊儲存庫、Librgw基於S3和Swift相容的物件庫和Libceph檔案系統庫。

      OSD(Object Storage Device)負責儲存資料，處理資料複製、資料恢復、資料再均衡以及通過心跳機制監測其它OSD狀況並報告給Ceph Monitors。

      Monitor負責監控叢集狀態，包括監控自身狀態、叢集OSD狀態、PlacementGroup（儲存組織和位置對映）狀態、CRUSH狀態(Controlled Replication Under Scalable Hashing，一種偽隨機資料分佈演算法)。同時，Monitor還會記錄它們的每一個歷史狀態改變版本資訊，以確定叢集該遵循哪個版本。

      MDS負責檔案系統的元資料儲存和管理，也就是如前所說，塊儲存和物件儲存服務是不需要這個模組的。MDS負責提供標準的POSIX檔案訪問介面。

      搭建一臺Ceph系統至少需要1個Ceph Monitor和2個Ceph OSD邏輯角色，而Ceph Metadata server僅僅是執行CephFS時儲存檔案元資料。但在物理部署上，這些邏輯角色可以執行在同一臺物理機上的。Ceph儲存資料預設是2副本拷貝，所以不管是提供Object、Block還是File system服務，最小的Ceph系統需要2臺OSD儲存伺服器。

9000的基礎服務架構

      9000是一個比較龐大的集群系統，在內部又由很多個負責不同角色的小叢集組成。這些叢集都部署在普通儲存節點之上，ISM、CMS和Monitoring叢集分別負責GUI管理配置、系統叢集管理和狀態監控，節點處於Active Standby模式保證系統可靠性。

      CA(Client Agent)負責檔案系統協議的語義解析執行，是檔案系統業務發動機，檔案切片、資料組合都由CA完成。9000支援標準CIFS、NFS和私有客戶端；在私有客戶端場景下，CA/SCA安裝在伺服器上，基於VFS檔案系統開發併兼容Posix介面標準。

      MDS(MetaData Service)管理檔案系統的元資料，在9000中元資料和使用者資料都保持在儲存節點上，元資料採用高可靠多副本儲存。元資料管理服務管理著整個系統的元資料和檔案資料的佈局資訊，負責系統的資源分配。每個儲存節點都是元資料節點。

      客戶端對物件服務的請求，通過OSC物件介面服務來響應，首先查詢OMD物件儲存元資料，然後根據查詢結果獲取物件位置並讀寫對於物件。OMD以叢集的模式提供物件元資料服務，部署在每個物件儲存物理節點上。

      OBS是整個系統的基礎伺服器系統，基於物件儲存系統，資料通過Key-Value的形式儲存在磁碟上，基於OBS系統提供上層NAS和Object儲存服務。OBS-C是客戶端、負責資料的操作；OBS-S是服務端、提供資料儲存服務，資料以物件的形式存放在資料子域中。

Cehp的軟體體系架構

(1)基礎儲存系統RADOS

RADOS(Reliable, Autonomic, Distributed Object Store)一層本身就是一個完整的物件儲存系統，包括Cehp的基礎服務(MDS，OSD，Monitor)，所有儲存在Ceph系統中的使用者資料事實上最終都是由這一層來儲存的。而Ceph的高可靠、高可擴充套件、高效能、高自動化等等特性本質上也是由這一層所提供的。因此，理解RADOS是理解Ceph的基礎與關鍵。

      RADOS在物理形態上由大量的儲存裝置節點組成，每個節點擁有自己的硬體資源(CPU、記憶體、硬碟、網路)，並執行著作業系統和檔案系統。

(2)基礎庫librados

      這一層的功能是對RADOS進行抽象和封裝，並向上層提供不同API，以便直接基於RADOS進行原生物件或上層物件、塊和檔案應用開發。特別要注意的是，RADOS是一個物件儲存系統，因此，基於librados實現的API也只是針對物件儲存功能的。

      RADOS所提供的原生librados API包括C和C++兩種。Librados在部署上和基於其上開發的應用位於同一臺機器。應用呼叫本機上的librados API，再由後者通過socket與RADOS叢集中的節點通訊並完成各種操作。

(3)高層儲存應用介面

      這一層包括了RADOSGW(RADOS Gateway)、 RBD(Reliable Block Device)和Ceph FS(Ceph File System)三個部分，其作用是在librados庫的基礎上提供抽象層次更高、更便於應用或客戶端使用的上層介面。

      RADOS GW是一個提供與Amazon S3和Swift相容的RESTful API的gateway，以供相應的物件儲存應用開發使用。RADOS GW提供的API抽象層次更高，但功能則不如librados強大。因此，開發者應針對自己的需求選擇使用。

      RBD則提供了一個標準的塊裝置介面，常用於在虛擬化的場景下為虛擬機器建立volume。如前所述，Red Hat已經將RBD驅動整合在KVM/QEMU中，以提高虛擬機器訪問效能。

      CephFS是一個POSIX相容的分散式檔案系統。目前還處在開發狀態，因而Ceph官網並不推薦將其用於生產環境中。

(4)伺服器客戶端層

      這一層就是不同場景下對於Ceph各個應用介面的各種應用方式，例如基於librados直接開發的物件儲存應用，基於RADOS GW開發的物件儲存應用，基於RBD實現的雲硬碟等等。

      Ceph Client是基於Fuse層(User SpacE)和VFS檔案系統開發，相容Posix介面標準。在Ceph儲存系統中，Ceph Metadata Daemon 提供了元資料伺服器，而Ceph Object Storage Daemon 提供了資料和元資料的實際儲存。Ceph對DFS、Block和Object資料寫入和讀取，都需Client利用Crush演算法(負責叢集中的資料放置和檢索的演算法)完成儲存位置計算和資料組裝。

9000的軟體體系架構

(1)基礎服務層

      OBS是整個系統的基礎伺服器系統，資料通過Key-Value的形式儲存在磁碟上，基於OBS系統提供上層NAS和Object儲存服務。採用Key-Value方式進行編址及儲存，可以減少原來LBA方式的元資料儲存量。

(2)資料處理層

      基於OBS基礎服務層，通過資料處理層構建NAS和Object服務。NAS的主要核心模組是MDS元資料服務和CA資料服務，每次資料請求都需要CA查詢不同節點上的不同元資料定位請求檔案的位置，並把從每個儲存節點讀取到的資料進行彙總，統一返回給客戶端。Object的主要可行模組是OSC物件介面服務和OMD物件儲存元資料服務。

(3)儲存服務層

      9000提供NAS和物件兩種型別服務，同時提供了豐富的儲存增值服務。物件包括資料重刪、多版本、多租戶、Swift和S3等服務；NAS包括快照、檔案複製、分級儲存、負載均衡等增值服務和HDFS、NDMP等服務。

由於9000叢集管理、監控等服務都是採用1 Active主2 Standby備模式，且EC演算法等要求，所以9000儲存系統支援最少3節點起配；當NAS和物件共存時，做小節點是5節點起配。檔案和物件元資料相互分離，但使用者資料空間是共享的。

OpenStack的相容和支援

      Ceph儲存軟體最常見的用途之一是作為OpenStack雲端儲存後端，另一個用途是在 RADOS中存放和檢索VM映象(OpenStack Glance映象服務)。目前以HP、Dell、Intel等為代表的企業IT領導廠商和以Mirantis、eNovance、UnitedStack為代表的OpenStack社群新興廠商，都將Ceph作為重要的乃至於首選的開源儲存解決方案。

      Ceph事實上是目前OpenStack生態系統中呼聲最高的開源儲存解決方案。Ceph的物件儲存(Object Storage)可以對接網盤等應用業務；塊裝置儲存(Block Device Storage)可以對接(IaaS)，例如OpenStack、CloudStack、Zstack、Eucalyptus以及KVM虛擬化等主流的IaaS雲平臺軟體，檔案系統(CephFS)尚不成熟。

      目前已經與QEMU虛機化(硬體虛擬化)整合，通過相關命令呼叫管理Ceph塊儲存服務(RBD)。支援通過對OpenStacklibvirt和QEMU之間的配置，來實現對KVM、XEN、LXC、VirtualBOX等各種虛機映象管理。

      支援通過libvirt將Ceph塊儲存服務(RBD)加入到OpenStack，已經完成與Glance(VM映象管理)、Cinder(塊儲存)整合。通過Glance儲存虛機映象到CephRBD或者通過Cinder啟動虛機。

      Ceph物件(Object Gateway)目前支援Amazon S3和OpenStack Swift，整合支援了OpenStack的keystone身份認證。

      9000目前計劃支援Openstack Malina NAS介面，實現也Openstack進行對接。另外也支援Amazon S3和OpenStack Swift，整合支援了OpenStack的keystone身份認證。由於目前9000還不支援SAN儲存，所以無法實現與OpenStack Glance映象整合。

學習總結

      Ceph基礎庫Librados和高層應用都提供了API，但是二者面向的使用者物件不同。librados API更底層，沒有賬戶、容器等等高階概念，它更適合對儲存系統理解深刻並進行功能定製和效能深度優化的儲存高階使用者；而RADOS Gateway等的高階應用API則更加適合應用的開發者。下面我們對Ceph和9000儲存系統進行簡單對比。

      擴充套件性: Ceph針對的場景主要是大規模和分散式儲存，資料量級一般希望PB級別以上，儲存節點成千上萬。9000目前最大支援288節點、60PB容量，據悉未來規劃切平臺到RH系列X86伺服器之後，在節點上應該無限制。

      系統架構: 9000和Ceph在架構上很相似，分散式、全對稱、X86商業硬體的SDS架構，儲存層資料基於物件儲存在磁碟上。區別在於9000整合CA資料訪問客戶端，對外提供標準的CIFS和NFS，可以相容Windows、Linux、Unix和Mac OS等系統，支援NAS和Object儲存服務；Ceph需要單獨的伺服器客戶端，目前主要相容Linux主流系統。

      應用場景: Ceph支援NAS、SAN和Object服務，服務介面更豐富，但主要提供SAN和Object儲存，一般用於和OpenStack雲對接，聚焦備份和歸檔；9000支援NAS和Object服務，針對大資料、媒資和HPC場景設計，所以主要用於高頻寬媒資編輯、基因測序、視訊監控和容量資源池等場景，兩者應用場景有些不同。

      可靠性和容量利用率: Ceph採用Crush演算法(類似EC)和雙副本方法儲存資料，但是Ceph資料儲存和檢索處理都在Clinet端處理，在資料讀寫過程中可能對Clinet伺服器端的效能有些影響。9000也是採用EC(Erasure Code)和多副本技術，所以在可靠性和容量使用率上與Ceph基本一致；但9000資料的切片和聚合都在儲存上實現，對主機沒有什麼影響。

      軟體特性: Ceph和9000都實現了檔案快照、HDFS等特性，但是檔案分級、檔案複製、NDMP等在Ceph中暫時還沒看到。Ceph實現了塊儲存快照、Thin和複製等功能。雖然說Ceph在NAS功能上比較欠缺，但目前Ceph發展的策略是從Block、Object到FilesyStem。

      統一管理: 目前Ceph採用CLI和配置檔案方式完成系統配置和管理，這基本上是開源專案的典型一個特點，對運維管理人員要求比較高。9000支援統一GUI管理、配置和監控，比較方便運維。但是Ceph在雲集成方面的能力值得9000學習和借鑑。