Ceph：一個 Linux PB 級分散式檔案系統

作為一名儲存行業的架構師，我對檔案系統情有獨鍾。這些系統用來儲存系統的使用者介面，雖然它們傾向於提供一系列類似的功能，但它們還能夠提供差異顯著的功能。Ceph 也不例外，它還提供一些您能在檔案系統中找到的最有趣的功能。

Ceph 最初是一項關於儲存系統的 PhD 研究專案，由 Sage Weil 在 University of California, Santa Cruz（UCSC）實施。但是到了 2010 年 3 月底，您可以在主線 Linux 核心（從 2.6.34 版開始）中找到 Ceph 的身影。雖然 Ceph 可能還不適用於生產環境，但它對測試目的還是非常有用的。本文探討了 Ceph 檔案系統及其獨有的功能，這些功能讓它成為可擴充套件分散式儲存的最有吸引力的備選。

Ceph 目標

為什麼選 “Ceph”？

“Ceph” 對一個檔案系統來說是個奇怪的名字，它打破了大多數人遵循的典型縮寫趨勢。這個名字和 UCSC（Ceph 的誕生地）的吉祥物有關，這個吉祥物是 “Sammy”，一個香蕉色的蛞蝓，就是頭足類中無殼的軟體動物。這些有多觸角的頭足類動物，提供了一個分散式檔案系統的最形象比喻。

開發一個分散式檔案系統需要多方努力，但是如果能準確地解決問題，它就是無價的。Ceph 的目標簡單地定義為：

• 可輕鬆擴充套件到數 PB 容量
• 對多種工作負載的高效能（每秒輸入/輸出操作[IOPS]和頻寬）
• 高可靠性

不幸的是，這些目標之間會互相競爭（例如，可擴充套件性會降低或者抑制效能或者影響可靠性）。Ceph 開發了一些非常有趣的概念（例如，動態元資料分割槽，資料分佈和複製），這些概念在本文中只進行簡短地探討。Ceph 的設計還包括保護單一點故障的容錯功能，它假設大規模（PB 級儲存）儲存故障是常見現象而不是例外情況。最後，它的設計並沒有假設某種特殊工作負載，但是包括適應變化的工作負載，提供最佳效能的能力。它利用 POSIX 的相容性完成所有這些任務，允許它對當前依賴 POSIX 語義（通過以 Ceph 為目標的改進）的應用進行透明的部署。最後，Ceph 是開源分散式儲存，也是主線 Linux 核心（2.6.34）的一部分。

回頁首

Ceph 架構

現在，讓我們探討一下 Ceph 的架構以及高階的核心要素。然後我會拓展到另一層次，說明 Ceph 中一些關鍵的方面，提供更詳細的探討。

Ceph 生態系統可以大致劃分為四部分（見圖 1）：客戶端（資料使用者），元資料伺服器（快取和同步分散式元資料），一個物件儲存叢集（將資料和元資料作為物件儲存，執行其他關鍵職能），以及最後的叢集監視器（執行監視功能）。

圖 1. Ceph 生態系統的概念架構

如圖 1 所示，客戶使用元資料伺服器，執行元資料操作（來確定資料位置）。元資料伺服器管理資料位置，以及在何處儲存新資料。值得注意的是，元資料儲存在一個儲存叢集（標為 “元資料 I/O”）。實際的檔案 I/O 發生在客戶和物件儲存叢集之間。這樣一來，更高層次的 POSIX 功能（例如，開啟、關閉、重新命名）就由元資料伺服器管理，不過 POSIX 功能（例如讀和寫）則直接由物件儲存叢集管理。

另一個架構檢視由圖 2 提供。一系列伺服器通過一個客戶介面訪問 Ceph 生態系統，這就明白了元資料伺服器和物件級儲存器之間的關係。分散式儲存系統可以在一些層中檢視，包括一個儲存裝置的格式（Extent and B-tree-based Object File System [EBOFS] 或者一個備選），還有一個設計用於管理資料複製，故障檢測，恢復，以及隨後的資料遷移的覆蓋管理層，叫做 Reliable Autonomic Distributed Object Storage（RADOS）。最後，監視器用於識別元件故障，包括隨後的通知。

圖 2. Ceph 生態系統簡化後的分層檢視

回頁首

Ceph 元件

瞭解了 Ceph 的概念架構之後，您可以挖掘到另一個層次，瞭解在 Ceph 中實現的主要元件。Ceph 和傳統的檔案系統之間的重要差異之一就是，它將智慧都用在了生態環境而不是檔案系統本身。

圖 3 顯示了一個簡單的 Ceph 生態系統。Ceph Client 是 Ceph 檔案系統的使用者。Ceph Metadata Daemon 提供了元資料伺服器，而 Ceph Object Storage Daemon 提供了實際儲存（對資料和元資料兩者）。最後，Ceph Monitor 提供了叢集管理。要注意的是，Ceph 客戶，物件儲存端點，元資料伺服器（根據檔案系統的容量）可以有許多，而且至少有一對冗餘的監視器。那麼，這個檔案系統是如何分佈的呢？

圖 3. 簡單的 Ceph 生態系統

Ceph 客戶端

核心或使用者空間

早期版本的 Ceph 利用在 User SpacE（FUSE）的 Filesystems，它把檔案系統推入到使用者空間，還可以很大程度上簡化其開發。但是今天，Ceph 已經被整合到主線核心，使其更快速，因為使用者空間上下文交換機對檔案系統 I/O 已經不再需要。

因為 Linux 顯示檔案系統的一個公共介面（通過虛擬檔案系統交換機 [VFS]），Ceph 的使用者透檢視就是透明的。管理員的透檢視肯定是不同的，考慮到很多伺服器會包含儲存系統這一潛在因素（要檢視更多建立 Ceph 叢集的資訊，見 參考資料 部分）。從使用者的角度看，他們訪問大容量的儲存系統，卻不知道下面聚合成一個大容量的儲存池的元資料伺服器，監視器，還有獨立的物件儲存裝置。使用者只是簡單地看到一個安裝點，在這點上可以執行標準檔案 I/O。

Ceph 檔案系統 — 或者至少是客戶端介面 — 在 Linux 核心中實現。值得注意的是，在大多數檔案系統中，所有的控制和智慧在核心的檔案系統源本身中執行。但是，在 Ceph 中，檔案系統的智慧分佈在節點上，這簡化了客戶端介面，併為 Ceph 提供了大規模（甚至動態）擴充套件能力。

Ceph 使用一個有趣的備選，而不是依賴分配列表（將磁碟上的塊對映到指定檔案的元資料）。Linux 透檢視中的一個檔案會分配到一個來自元資料伺服器的 inode number（INO），對於檔案這是一個唯一的識別符號。然後檔案被推入一些物件中（根據檔案的大小）。使用 INO 和 object number（ONO），每個物件都分配到一個物件 ID（OID）。在 OID 上使用一個簡單的雜湊，每個物件都被分配到一個放置組。放置組（標識為 PGID）是一個物件的概念容器。最後，放置組到物件儲存裝置的對映是一個偽隨機對映，使用一個叫做 Controlled Replication Under Scalable Hashing（CRUSH）的演算法。這樣一來，放置組（以及副本）到儲存裝置的對映就不用依賴任何元資料，而是依賴一個偽隨機的對映函式。這種操作是理想的，因為它把儲存的開銷最小化，簡化了分配和資料查詢。

分配的最後元件是叢集對映。叢集對映 是裝置的有效表示，顯示了儲存叢集。有了 PGID 和叢集對映，您就可以定位任何物件。

Ceph 元資料伺服器

元資料伺服器（cmds）的工作就是管理檔案系統的名稱空間。雖然元資料和資料兩者都儲存在物件儲存叢集，但兩者分別管理，支援可擴充套件性。事實上，元資料在一個元資料伺服器叢集上被進一步拆分，元資料伺服器能夠自適應地複製和分配名稱空間，避免出現熱點。如圖 4 所示，元資料伺服器管理名稱空間部分，可以（為冗餘和效能）進行重疊。元資料伺服器到名稱空間的對映在 Ceph 中使用動態子樹邏輯分割槽執行，它允許 Ceph 對變化的工作負載進行調整（在元資料伺服器之間遷移名稱空間）同時保留效能的位置。

圖 4. 元資料伺服器的 Ceph 名稱空間的分割槽

但是因為每個元資料伺服器只是簡單地管理客戶端人口的名稱空間，它的主要應用就是一個智慧元資料快取（因為實際的元資料最終儲存在物件儲存叢集中）。進行寫操作的元資料被快取在一個短期的日誌中，它最終還是被推入物理儲存器中。這個動作允許元資料伺服器將最近的元資料回饋給客戶（這在元資料操作中很常見）。這個日誌對故障恢復也很有用：如果元資料伺服器發生故障，它的日誌就會被重放，保證元資料安全儲存在磁碟上。

元資料伺服器管理 inode 空間，將檔名轉變為元資料。元資料伺服器將檔名轉變為索引節點，檔案大小，和 Ceph 客戶端用於檔案 I/O 的分段資料（佈局）。

Ceph 監視器

Ceph 包含實施叢集對映管理的監視器，但是故障管理的一些要素是在物件儲存本身中執行的。當物件儲存裝置發生故障或者新裝置新增時，監視器就檢測和維護一個有效的叢集對映。這個功能按一種分佈的方式執行，這種方式中對映升級可以和當前的流量通訊。Ceph 使用 Paxos，它是一系列分散式共識演算法。

Ceph 物件儲存

和傳統的物件儲存類似，Ceph 儲存節點不僅包括儲存，還包括智慧。傳統的驅動是隻響應來自啟動者的命令的簡單目標。但是物件儲存裝置是智慧裝置，它能作為目標和啟動者，支援與其他物件儲存裝置的通訊和合作。

從儲存角度來看，Ceph 物件儲存裝置執行從物件到塊的對映（在客戶端的檔案系統層中常常執行的任務）。這個動作允許本地實體以最佳方式決定怎樣儲存一個物件。Ceph 的早期版本在一個名為 EBOFS 的本地儲存器上實現一個自定義低階檔案系統。這個系統實現一個到底層儲存的非標準介面，這個底層儲存已針對物件語義和其他特性（例如對磁碟提交的非同步通知）調優。今天，B-tree 檔案系統（BTRFS）可以被用於儲存節點，它已經實現了部分必要功能（例如嵌入式完整性）。

因為 Ceph 客戶實現 CRUSH，而且對磁碟上的檔案對映塊一無所知，下面的儲存裝置就能安全地管理物件到塊的對映。這允許儲存節點複製資料（當發現一個裝置出現故障時）。分配故障恢復也允許儲存系統擴充套件，因為故障檢測和恢復跨生態系統分配。Ceph 稱其為 RADOS（見 圖 3）。

回頁首

其他有趣功能

如果檔案系統的動態和自適應特性不夠，Ceph 還執行一些使用者可視的有趣功能。使用者可以建立快照，例如，在 Ceph 的任何子目錄上（包括所有內容）。檔案和容量計算可以在子目錄級別上執行，它報告一個給定子目錄（以及其包含的內容）的儲存大小和檔案數量。

回頁首

Ceph 的地位和未來

雖然 Ceph 現在被整合在主線 Linux 核心中，但只是標識為實驗性的。在這種狀態下的檔案系統對測試是有用的，但是對生產環境沒有做好準備。但是考慮到 Ceph 加入到 Linux 核心的行列，還有其建立人想繼續研發的動機，不久之後它應該就能用於解決您的海量儲存需要了。

回頁首

其他分散式檔案系統

Ceph 在分散式檔案系統空間中並不是唯一的，但它在管理大容量儲存生態環境的方法上是獨一無二的。分散式檔案系統的其他例子包括 Google File System（GFS），General Parallel File System（GPFS），還有 Lustre，這隻提到了一部分。Ceph 背後的想法為分散式檔案系統提供了一個有趣的未來，因為海量級別儲存導致了海量儲存問題的唯一挑戰。

回頁首

展望未來

Ceph 不只是一個檔案系統，還是一個有企業級功能的物件儲存生態環境。在 參考資料 部分中，您將會找到如何設定一個簡單 Ceph 叢集（包括元資料伺服器，物件儲存伺服器和監視器）的資訊。Ceph 填補了分散式儲存中的空白，看到這個開源產品如何在未來演變也將會是很有趣的。

來源：http://www.ibm.com/developerworks/cn/linux/l-ceph/

Ceph架構剖析

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 Storage Device，提供儲存資源。
• 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(Placement Group)，再由PG對映到OSD set。每個Pool有多個PG，每個Object通過計算hash值並取模得到它所對應的PG。PG再對映到一組OSD（OSD的個數由Pool 的副本數決定），第一個OSD是Primary，剩下的都是Replicas。

資料對映(Data Placement)的方式決定了儲存系統的效能和擴充套件性。(Pool, PG) → OSD set 的對映由四個因素決定：

• 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，得到一份Authoritative History(完整的、全序的操作序列)，並讓其他Replicas同意這份Authoritative History(也就是其他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.2 高擴充套件性

• 高度並行。沒有單箇中心控制組件。所有負載都能動態的劃分到各個伺服器上。把更多的功能放到OSD上，讓OSD更智慧。
• 自管理。容易擴充套件、升級、替換。當元件發生故障時，自動進行資料的重新複製。當元件發生變化時(新增/刪除)，自動進行資料的重分佈。

5. 測試

相關推薦