雲端儲存---ceph簡介架構原理和一些基本概念

阿新 • • 發佈：2019-01-26

我們在上篇文章已經對比了不同的儲存系統之間的區別，本章開始逐步深入記錄Ceph的學習和運用。

Ceph簡介

Ceph是一個分散式儲存系統，提供物件，塊和檔案儲存，是一個免費開源軟體的儲存解決方案，可以部署於普通的x86相容伺服器上，可用於解決統一儲存的io問題。Ceph誕生於2004年，最早是SageWeil一項關於儲存系統的PhD研究專案，致力於開發下一代高效能分散式檔案系統的專案。隨著雲端計算的發展，ceph乘上了OpenStack的春風，進而成為了開源社群受關注較高的專案之一。
該系統被設計成自動修復和智慧管理，希望減低管理員和預算開銷。
想達到的目標：沒有單點故障的完全分散式儲存系統，使資料能容錯和無縫的複製，可擴充套件EB水平(EB,PB,TB,GB)

Ceph同時支援塊、檔案、物件介面，支援PB級別擴充套件，規格上可部署到上千臺通用伺服器。物件S3和Swift寫入的資料是相互可讀取的。

Ceph的優點

CRUSH演算法
Crush演算法是ceph的兩大創新之一，簡單來說，ceph摒棄了傳統的集中式儲存元資料定址的方案，轉而使用CRUSH演算法完成資料的定址操作。CRUSH在一致性雜湊基礎上很好的考慮了容災域的隔離，能夠實現各類負載的副本放置規則，例如跨機房、機架感知等。Crush演算法有相當強大的擴充套件性，理論上支援數千個儲存節點。

高可用
Ceph中的資料副本數量可以由管理員自行定義，並可以通過CRUSH演算法指定副本的物理儲存位置以分隔故障域，支援資料強一致性； ceph可以忍受多種故障場景並自動嘗試並行修復。

高擴充套件性
Ceph不同於swift，客戶端所有的讀寫操作都要經過代理節點。一旦叢集併發量增大時，代理節點很容易成為單點瓶頸。Ceph本身並沒有主控節點，擴充套件起來比較容易，並且理論上，它的效能會隨著磁碟數量的增加而線性增長。

特性豐富
Ceph支援三種呼叫介面：物件儲存，塊儲存，檔案系統掛載。三種方式可以一同使用。在國內一些公司的雲環境中，通常會採用ceph作為openstack的唯一後端儲存來提升資料轉發效率。

Ceph的儲存實現架構

Ceph系統可以大致劃分為兩大部分，客戶端和服務端，客戶端包含了四種介面，服務端包含了元資料伺服器，物件儲存叢集和叢集監視器：

客戶端

面向使用者的使用提供介面，目前有三種儲存方式介面提供，物件儲存 RGW(rados gateway)、塊儲存 RBD(rados block device) 和檔案儲存 CephFS。
塊儲存和檔案儲存都是基於物件儲存來進行封裝實現的，塊儲存和檔案儲存的底層還是物件儲存。

物件儲存（RGW:RADOS gateway）

Ceph 物件儲存服務提供了 REST 風格的 API ，它有與 Amazon S3 和 OpenStack Swift 相容的介面。也就是通常意義的鍵值儲存，其介面就是簡單的GET、PUT、DEL和其他擴充套件;
RADOSGW是一套基於當前流行的RESTFUL協議的閘道器，並且相容S3和Swift。

塊儲存（RBD：RADOS block device）

RBD通過Linux核心客戶端和QEMU/KVM驅動來提供一個分散式的塊裝置。
RBD 是通過librbd庫對應用提供塊儲存，主要面向雲平臺的虛擬機器提供虛擬磁碟；RBD類似傳統的SAN儲存，提供資料塊級別的訪問；
目前 RBD 提供了兩個介面，一種是直接在使用者態實現，通過 QEMU Driver 供 KVM 虛擬機器使用。另一種是在作業系統核心態實現了一個核心模組。通過該模組可以把塊裝置對映給物理主機，由物理主機直接訪問。

檔案儲存（CEPH FS）

CEPH FS通過Linux核心客戶端和FUSE來提供一個相容POSIX的檔案系統。
Ceph 檔案系統服務提供了相容 POSIX 的檔案系統，可以直接掛載為使用者空間檔案系統。它跟傳統的檔案系統如Ext4是一個型別，區別在於分散式儲存提供了並行化的能力；

原生介面

除了以上3種儲存介面，還可以直接使用 librados 的原生介面，直接和RADOS通訊；
原生介面的優點是是它直接和和應用程式碼整合，操作檔案很方便；但它的問題是它不會主動為上傳的資料分片；一個1G的大物件上傳，落到 Ceph 的儲存磁碟上就是1G的檔案；
而以上三個介面是具有分片功能（即:條帶化 file-striping)

服務端

元資料伺服器

主要是實現叢集元資料的分散式管理

物件儲存叢集

因為ceph的三種儲存介面都是通過物件儲存實現的，物件儲存叢集將資料和元資料作為物件儲存，執行其他關鍵職能。
物件儲存叢集的核心元件是RADOS (Reliable, AutonomicDistributed Object Store)。

叢集監視器

執行監視功能，保證叢集的健康執行和告警

客戶端和服務端互動

它們之間的結構和互動如圖:

從架構圖中可以看到最底層的是RADOS，RADOS自身是一個完整的分散式物件儲存系統，它具有可靠、智慧、分散式等特性，Ceph所有的儲存功能都是基於RADOS實現，所以Ceph的高可靠、高可拓展、高效能、高自動化都是由這一層來提供的，使用者資料的儲存最終也都是通過這一層來進行儲存的，RADOS可以說就是Ceph的核心。

RADOS系統主要由兩部分組成，分別是OSD和Monitor。

RADOS採用C++開發，所提供的原生Librados API包括C和C++兩種。Ceph的上層應用呼叫本機上的librados API，再由後者通過socket與RADOS叢集中的其他節點通訊並完成各種操作。

基於RADOS層的上一層是LIBRADOS，LIBRADOS是一個庫，它允許應用程式通過訪問該庫來與RADOS系統進行互動，支援多種程式語言，比如C、C++、Python等。

基於LIBRADOS層開發的又可以看到有三層，分別是RADOSGW、RBD和CEPH FS。

RADOS GateWay、RBD其作用是在librados庫的基礎上提供抽象層次更高、更便於應用或客戶端使用的上層介面。
其中，RADOS GW是一個提供與Amazon S3和Swift相容的RESTful API的gateway，以供相應的物件儲存應用開發使用。RBD則提供了一個標準的塊裝置介面，常用於在虛擬化的場景下為虛擬機器建立volume。
目前，Red Hat已經將RBD驅動整合在KVM/QEMU中，以提高虛擬機器訪問效能。
這兩種方式目前在雲端計算中應用的比較多。
CEPHFS則提供了POSIX介面，使用者可直接通過客戶端掛載使用。它是核心態的程式，所以無需呼叫使用者空間的librados庫。它通過核心中的net模組來與Rados進行互動。通過FUSE掛載到客戶端的儲存系統使用起來跟本地硬碟的使用方式一致，使用掛載路徑即可訪問。

Ceph的物理部署

服務端 RADOS 叢集主要由兩種節點組成：一種是為數眾多的、負責完成資料儲存和維護功能的OSD（Object Storage Device），另一種則是若干個負責完成系統狀態檢測和維護的monitor。

Monitor

Monitor 叢集提供了整個儲存系統的節點資訊等全域性的配置資訊，通過 Paxos 演算法保持資料的一致性。

OSD

Pool是儲存物件的邏輯分割槽，它規定了資料冗餘的型別和對應的副本分佈策略；支援兩種型別：副本（replicated）和糾刪碼（ Erasure Code）；目前我們公司內部使用的Pool都是副本型別（3副本）；

PG（ placement group）是一個放置策略組，它是物件的集合，該集合裡的所有物件都具有相同的放置策略；簡單點說就是相同PG內的物件都會放到相同的硬碟上； PG是 ceph的核心概念，服務端資料均衡和恢復的最小粒度就是PG；

OSD是負責物理儲存的程序，一般配置成和磁碟一一對應，一塊磁碟啟動一個OSD程序；

下面這張圖形象的描繪了它們之間的關係：

一個Pool裡有很多PG，
一個PG裡包含一堆物件；一個物件只能屬於一個PG；
PG有主從之分，一個PG分佈在不同的OSD上（針對三副本型別）

Ceph的元件詳解

Ceph的核心元件包括Ceph OSD、Ceph Monitor和Ceph MDS。

Ceph OSD

OSD的英文全稱是Object Storage Device，它的主要功能是儲存資料、複製資料、平衡資料、恢復資料等，與其它OSD間進行心跳檢查等，並將一些變化情況上報給Ceph Monitor。一般情況下一塊硬碟對應一個OSD，由OSD來對硬碟儲存進行管理，當然一個分割槽也可以成為一個OSD。

Ceph OSD的架構實現由物理磁碟驅動器、Linux檔案系統和Ceph OSD服務組成，對於Ceph OSD Deamon而言，Linux檔案系統顯性的支援了其拓展性，一般Linux檔案系統有好幾種，比如有BTRFS、XFS、Ext4等，BTRFS雖然有很多優點特性，但現在還沒達到生產環境所需的穩定性，一般比較推薦使用XFS。

OSD是強一致性的分散式儲存，它的讀寫流程如下圖

　Ceph的讀寫操作採用主從模型，客戶端要讀寫資料時，只能向物件所對應的主osd節點發起請求。主節點在接受到寫請求時，會同步的向從OSD中寫入資料。當所有的OSD節點都寫入完成後，主節點才會向客戶端報告寫入完成的資訊。因此保證了主從節點資料的高度一致性。而讀取的時候，客戶端也只會向主osd節點發起讀請求，並不會有類似於資料庫中的讀寫分離的情況出現，這也是出於強一致性的考慮。由於所有寫操作都要交給主osd節點來處理，所以在資料量很大時，效能可能會比較慢，為了克服這個問題以及讓ceph能支援事物，每個osd節點都包含了一個journal檔案。

伴隨OSD的還有一個概念叫做Journal盤，一般寫資料到Ceph叢集時，都是先將資料寫入到Journal盤中，然後每隔一段時間比如5秒再將Journal盤中的資料重新整理到檔案系統中。一般為了使讀寫時延更小，Journal盤都是採用SSD，一般分配10G以上，當然分配多點那是更好，Ceph中引入Journal盤的概念是因為Journal允許Ceph OSD功能很快做小的寫操作；一個隨機寫入首先寫入在上一個連續型別的journal，然後重新整理到檔案系統，這給了檔案系統足夠的時間來合併寫入磁碟，一般情況下使用SSD作為OSD的journal可以有效緩衝突發負載。

在ceph中，每一個osd程序都可稱作是一個osd節點，也就是說，每臺儲存伺服器上可能包含了眾多的osd節點，每個osd節點監聽不同的埠，類似於在同一臺伺服器上跑多個mysql或redis。每個osd節點可以設定一個目錄作為實際儲存區域，也可以是一個分割槽，一整塊硬碟。如下圖，當前這臺機器上跑了兩個osd程序，每個osd監聽4個埠，分別用於接收客戶請求、傳輸資料、傳送心跳、同步資料等操作。

如上圖所示，osd節點預設監聽tcp的6800到6803埠，如果同一臺伺服器上有多個osd節點，則依次往後排序。

　　在生產環境中的osd最少可能都有上百個，所以每個osd都有一個全域性的編號，類似osd0，osd1，osd2……..序號根據osd誕生的順序排列，並且是全域性唯一的。儲存了相同PG的osd節點除了向mon節點發送心跳外，還會互相傳送心跳資訊以檢測pg資料副本是否正常。

之前在介紹資料流向時說過，每個osd節點都包含一個journal檔案，如下圖：

預設大小為5G，也就說每建立一個osd節點，還沒使用就要被journal佔走5G的空間。這個值是可以調整的，具體大小要依osd的總大小而定。

　　Journal的作用類似於mysql innodb引擎中的事物日誌系統。當有突發的大量寫入操作時，ceph可以先把一些零散的，隨機的IO請求儲存到快取中進行合併，然後再統一向核心發起IO請求。這樣做效率會比較高，但是一旦osd節點崩潰，快取中的資料就會丟失，所以資料在還未寫進硬碟中時，都會記錄到journal中，當osd崩潰後重新啟動時，會自動嘗試從journal恢復因崩潰丟失的快取資料。因此journal的io是非常密集的，而且由於一個數據要io兩次，很大程度上也損耗了硬體的io效能，所以通常在生產環境中，使用ssd來單獨儲存journal檔案以提高ceph讀寫效能。

Ceph Monitor

由該英文名字我們可以知道它是一個監視器，負責監視Ceph叢集，維護Ceph叢集的健康狀態，同時維護著Ceph叢集中的各種Map圖，比如OSD Map、Monitor Map、PG Map和CRUSH Map，這些Map統稱為Cluster Map，Cluster Map是RADOS的關鍵資料結構，管理叢集中的所有成員、關係、屬性等資訊以及資料的分發，比如當用戶需要儲存資料到Ceph叢集時，OSD需要先通過Monitor獲取最新的Map圖，然後根據Map圖和object id等計算出資料最終儲存的位置。

Mon節點監控著整個ceph叢集的狀態資訊，監聽於tcp的6789埠。每一個ceph叢集中至少要有一個Mon節點，官方推薦每個叢集至少部署三臺。Mon節點中儲存了最新的版本叢集資料分佈圖（cluster map）的主副本。客戶端在使用時，需要掛載mon節點的6789埠，下載最新的cluster map，通過crush演算法獲得叢集中各osd的IP地址，然後再與osd節點直接建立連線來傳輸資料。所以對於ceph來說，並不需要有集中式的主節點用於計算與定址，客戶端分攤了這部分工作。而且客戶端也可以直接和osd通訊，省去了中間代理伺服器的額外開銷。

　　Mon節點之間使用Paxos演算法來保持各節點cluster map的一致性；各mon節點的功能總體上是一樣的，相互間的關係可以被簡單理解為主備關係。如果主mon節點損壞，其他mon存活節點超過半數時，叢集還可以正常執行。當故障mon節點恢復時，會主動向其他mon節點拉取最新的cluster map。

　　Mon節點並不會主動輪詢各個osd的當前狀態，相反，osd只有在一些特殊情況才會上報自己的資訊，平常只會簡單的傳送心跳。特殊情況包括：1、新的OSD被加入叢集；2、某個OSD發現自身或其他OSD發生異常。Mon節點在收到這些上報資訊時，則會更新cluster map資訊並加以擴散。

　　cluster map資訊是以非同步且lazy的形式擴散的。monitor並不會在每一次cluster map版本更新後都將新版本廣播至全體OSD，而是在有OSD向自己上報資訊時，將更新回覆給對方。類似的，各個OSD也是在和其他OSD通訊時，如果發現對方的osd中持有的cluster map版本較低，則把自己更新的版本傳送給對方。

推薦使用以下的架構

這裡的ceph除了管理網段外，設了兩個網段，一個用於客戶端讀寫傳輸資料。另一個用於各OSD節點之間同步資料和傳送心跳資訊等。這樣做的好處是可以分擔網絡卡的IO壓力。否則在資料清洗時，客戶端的讀寫速度會變得極為緩慢。

Ceph MDS

全稱是Ceph MetaData Server，Mds是ceph叢集中的元資料伺服器，而通常它都不是必須的，因為只有在使用cephfs的時候才需要它，物件儲存和塊儲存裝置是不需要使用該服務的，而目前雲端計算中用的更廣泛的是另外兩種儲存方式。

Mds雖然是元資料伺服器，但是它不負責儲存元資料，元資料也是被切成物件存在各個osd節點中的，如下圖：

在建立CEPHFS時，要至少建立兩個POOL，一個用於存放資料，另一個用於存放元資料。Mds只是負責接受使用者的元資料查詢請求，然後從osd中把資料取出來對映進自己的記憶體中供客戶訪問。所以mds其實類似一個代理快取伺服器，替osd分擔了使用者的訪問壓力,如下圖：

Ceph與雲平臺的關係

Ceph已經成為OpenStack後端儲存標配，OpenStack作為IaaS系統，涉及到儲存的部分主要是塊儲存服務模組、物件儲存服務模組、映象管理模組和計算服務模組，對應為其中的Cinder、Swift、Glance和Nova四個專案。

Ceph RBD塊儲存是以獨立卷的方式掛接到OpenStcak Cinder模組，主要用作資料盤，這種方式主要通過Cinder Driver實現，刪除虛擬機器時卷依然存在。Nova對接Ceph時，Ceph RBD塊儲存卷需要與虛擬機器繫結，所以刪除虛擬機器時卷也刪除，一般用作啟動盤。Ceph也可以和Glance對接用於映象卷。Keystone作為OpenStack物件Swift的認證模組，支援Ceph通過RADOSGW閘道器認證，給OpenStcak提供Swift儲存服務。

Ceph社群已經把Ceph 的RBD塊儲存映象支援功能擴充套件到Docker中。在Docker中Ceph的RBD映象功能主要是負責把RBD映象通過非同步通訊的方式從一個Ceph叢集複製到另一個Ceph叢集，用於對Docker映象容災保護和恢復。

Ceph內部資料儲存檢視

在Ceph儲存系統中，Cehp的基礎服務架構主要包括了Object Storage Device(OSD)，Monitor和MDS。
提供了Librados原生物件基礎庫、Librbd塊儲存庫、基於S3 和Swift相容的Librgw物件庫和Libceph檔案系統庫。
搭建一臺Ceph系統至少需要1個Ceph Monitor和2個Ceph OSD。
一個Cluster可邏輯上劃分為多個Pool。
一個 Pool由若干個邏輯 PG( Placement Group)組成，Pool內的副本數量也是可以設定的。

Ceph底層是物件系統，所以一個檔案會被切分為多個Object，每個Object會被對映到一個PG，每個 PG 會對映到一組 OSD(Object Storage Device)，其中第一個OSD 是主，其餘的是備，OSD間通過心跳來相互監控存活狀態。引入PG概念後，OSD只和PG相關，不但簡化了OSD的資料儲存，而且實現了Object到OSD的動態對映，OSD的新增和故障不影響Object的對映。

Ceph資料如何儲存

在Ceph儲存系統中，資料儲存分三個對映過程
首先要將使用者要操作的file，對映為RADOS能夠處理的object。就是簡單的按照object的size對file進行切分，相當於RAID中的條帶化過程。
接著把Object對映到PG，在file被對映為一個或多個object之後，就需要將每個object獨立地對映到一個PG中去。
第三次對映就是將作為object的邏輯組織單元的PG對映到資料的實際儲存單元OSD。

檔案存入時，首先把File切分為RADOS層面的Object，每個Object一般為2MB或4MB(大小可設定)。每個Object通過雜湊演算法對映到唯一的PG。每個PG通過Crush演算法對映到實際儲存單元OSD，PG和OSD間是多對多的對映關係。OSD在物理上可劃分到多個故障域中，故障域可以跨機櫃和伺服器，通過策略配置使PG的不同副本位於不同的故障域中。

Ceph資料分佈演算法

在分散式儲存系統中比較關注的一點是如何使得資料能夠分佈得更加均衡，常見的資料分佈演算法有一致性Hash和Ceph的Crush演算法。Crush是一種偽隨機的控制資料分佈、複製的演算法，Ceph是為大規模分散式儲存而設計的，資料分佈演算法必須能夠滿足在大規模的叢集下資料依然能夠快速的準確的計算存放位置，同時能夠在硬體故障或擴充套件硬體裝置時做到儘可能小的資料遷移，Ceph的CRUSH演算法就是精心為這些特性設計的，可以說CRUSH演算法也是Ceph的核心之一。

Ceph以私有Client方式對外提供服務，支援Linux使用者態(Fuse)和核心態(VFS)方式，Clinet還實現資料切片，通過Crush演算法定位物件位置，並進行資料的讀寫。但在測試中，通常在Ceph伺服器端將Ceph配置成NFS服務的ExportFS，通過標準NFS介面匯出目錄。 CephFS 支援POSIX、HDFS、NFS、CIFS服務介面，其中NFS和CIFS通過外接閘道器實現(通過Clinet匯出)。

在PG通過Crush演算法對映到資料的實際儲存單元OSD時，需求通過Crush Map、Crush Rules和Crush演算法配合才能完成。

Cluster Map用來記錄全域性系統狀態記資料結構，由Crush Map和OSD Map兩部分組成。 Crush Map包含當前磁碟、伺服器、機架的層級結構，OSD Map包含當前所有Pool的狀態和所有OSD的狀態。

Crush Rules就是資料對映的策略，決定了每個資料物件有多少個副本，這些副本如何儲存。

Crush演算法是一種偽隨機演算法，通過權重決定資料存放（如跨機房、機架感知等），通常採用基於容量的權重。Crush演算法支援副本和EC兩種資料冗餘方式，還提供了四種不同型別的Bucket(Uniform、List、Tree、Straw)，大多數情況下的都採用Straw。

在說明CRUSH演算法的基本原理之前，先介紹幾個概念和它們之間的關係。

儲存資料與object的關係：當用戶要將資料儲存到Ceph叢集時，儲存資料都會被分割成多個object，每個object都有一個object id，每個object的大小是可以設定的，預設是4MB，object可以看成是Ceph儲存的最小儲存單元。

object與pg的關係：由於object的數量很多，所以Ceph引入了pg的概念用於管理object，每個object最後都會通過CRUSH計算對映到某個pg中，一個pg可以包含多個object。

pg與osd的關係：pg也需要通過CRUSH計算對映到osd中去儲存，如果是二副本的，則每個pg都會對映到二個osd，比如[osd.1,osd.2]，那麼osd.1是存放該pg的主副本，osd.2是存放該pg的從副本，保證了資料的冗餘。

pg和pgp的關係：pg是用來存放object的，pgp相當於是pg存放osd的一種排列組合，我舉個例子，比如有3個osd，osd.1、osd.2和osd.3，副本數是2，如果pgp的數目為1，那麼pg存放的osd組合就只有一種，可能是[osd.1,osd.2]，那麼所有的pg主從副本分別存放到osd.1和osd.2，如果pgp設為2，那麼其osd組合可以兩種，可能是[osd.1,osd.2]和[osd.1,osd.3]，是不是很像我們高中數學學過的排列組合，pgp就是代表這個意思。一般來說應該將pg和pgp的數量設定為相等。這樣說可能不夠明顯，我們通過一組實驗來體會下：

先建立一個名為testpool包含6個PG和6個PGP的儲存池
ceph osd pool create testpool 6 6
通過寫資料後我們檢視下pg的分佈情況，使用以下命令：

ceph pg dump pgs | grep ^1 | awk ‘{print $1,$ 2,$15}’
dumped pgs in format plain
1.1 75 [3,6,0]
1.0 83 [7,0,6]
1.3 144 [4,1,2]
1.2 146 [7,4,1]
1.5 86 [4,6,3]
1.4 80 [3,0,4]
第1列為pg的id，第2列為該pg所儲存的物件數目，第3列為該pg所在的osd

我們擴大PG再看看
ceph osd pool set testpool pg_num 12
再次用上面的命令查詢分佈情況：
1.1 37 [3,6,0]
1.9 38 [3,6,0]
1.0 41 [7,0,6]
1.8 42 [7,0,6]
1.3 48 [4,1,2]
1.b 48 [4,1,2]
1.7 48 [4,1,2]
1.2 48 [7,4,1]
1.6 49 [7,4,1]
1.a 49 [7,4,1]
1.5 86 [4,6,3]
1.4 80 [3,0,4]
我們可以看到pg的數量增加到12個了，pg1.1的物件數量本來是75的，現在是37個，可以看到它把物件數分給新增的pg1.9了，剛好是38，加起來是75，而且可以看到pg1.1和pg1.9的osd盤是一樣的。
而且可以看到osd盤的組合還是那6種。

我們增加pgp的數量來看下，使用命令：
ceph osd pool set testpool pgp_num 12
再看下
1.a 49 [1,2,6]
1.b 48 [1,6,2]
1.1 37 [3,6,0]
1.0 41 [7,0,6]
1.3 48 [4,1,2]
1.2 48 [7,4,1]
1.5 86 [4,6,3]
1.4 80 [3,0,4]
1.7 48 [1,6,0]
1.6 49 [3,6,7]
1.9 38 [1,4,2]
1.8 42 [1,2,3]
再看pg1.1和pg1.9，可以看到pg1.9不在[3,6,0]上，而在[1,4,2]上了，該組合是新加的，可以知道增加pgp_num其實是增加了osd盤的組合。

通過實驗總結：
（1）PG是指定儲存池儲存物件的目錄有多少個，PGP是儲存池PG的OSD分佈組合個數
（2）PG的增加會引起PG內的資料進行分裂，分裂相同的OSD上新生成的PG當中
（3）PGP的增加會引起部分PG的分佈進行變化，但是不會引起PG內物件的變動

pg和pool的關係：pool也是一個邏輯儲存概念，我們建立儲存池pool的時候，都需要指定pg和pgp的數量，邏輯上來說pg是屬於某個儲存池的，就有點像object是屬於某個pg的。

以下這個圖表明瞭儲存資料，object、pg、pool、osd、儲存磁碟的關係

本質上CRUSH演算法是根據儲存裝置的權重來計算資料物件的分佈的，權重的設計可以根據該磁碟的容量和讀寫速度來設定，比如根據容量大小可以將1T的硬碟裝置權重設為1，2T的就設為2，在計算過程中，CRUSH是根據Cluster Map、資料分佈策略和一個隨機數共同決定陣列最終的儲存位置的。

Cluster Map裡的內容資訊包括儲存叢集中可用的儲存資源及其相互之間的空間層次關係，比如叢集中有多少個支架，每個支架中有多少個伺服器，每個伺服器有多少塊磁碟用以OSD等。

資料分佈策略是指可以通過Ceph管理者通過配置資訊指定資料分佈的一些特點，比如管理者配置的故障域是Host，也就意味著當有一臺Host起不來時，資料能夠不丟失，CRUSH可以通過將每個pg的主從副本分別存放在不同Host的OSD上即可達到，不單單可以指定Host，還可以指定機架等故障域，除了故障域，還有選擇資料冗餘的方式，比如副本數或糾刪碼。

下面這個式子簡單的表明CRUSH的計算表示式：

CRUSH(X) -> (osd.1,osd.2…..osd.n)

式子中的X就是一個隨機數。

下面通過一個計算PG ID的示例來看CRUSH的一個計算過程：

（1）Client輸入Pool ID和物件ID；

（2）CRUSH獲得物件ID並對其進行Hash運算；

（3）CRUSH計算OSD的個數，Hash取模獲得PG的ID，比如0x48；

（4）CRUSH取得該Pool的ID，比如是1；

（5）CRUSH預先考慮到Pool ID相同的PG ID，比如1.48。

物件的定址過程

查詢物件在叢集中的儲存的位置，具體分為兩步：
第一步，物件到PG的對映；將物件的id 通過hash對映，然後用PG總數對hash值取模得到pg id：

pg_ id = hash( object_ id ) % pg_num

第二步，PG到osd列表對映; 通過crush演算法計算PG上的物件分佈到哪些OSD硬碟上；

CRUSH(PG_ID) =⇒ OSD

CRUSH演算法是 ceph的精華所在；

crush的目標

先看看crush演算法的希望達成的目標：
資料均勻的分佈到叢集中；
需要考慮各個OSD權重的不同（根據讀寫效能的差異，磁碟的容量的大小差異等設定不同的權重）
當有OSD損壞需要資料遷移時，資料的遷移量儘可能的少；

crush演算法過程

簡單說下crush演算法的過程：
第一步輸入PG id、可供選擇的OSD id 列表，和一個常量，通過一個偽隨機演算法，得到一個隨機數，偽隨機演算法保證了同一個key總是得到相同的隨機數，從而保證每次計算的儲存位置不會改變；

CRUSH_HASH( PG_ID, OSD_ID, r ) = draw

第二步將上面得到的隨機數和每個OSD的權重相乘，然後挑出乘積最大的那個OSD；

 ( draw &0xffff ) * osd_weight = osd_straw

在樣本容量足夠大之後，這個隨機數對挑中的結果不再有影響，起決定性影響的是OSD的權重，也就是說，OSD的權重越大，被挑中的概率越大。
到這裡了我們再看看crush演算法如何達成的目標：
通過隨機演算法讓資料均衡分佈，乘以權重讓挑選的結果考慮了權重；而如果出現故障OSD，只需要恢復這個OSD上的資料，不在這個節點上的資料不需移動；

crush優缺點

聊到這裡，crush演算法的優缺點就明顯了：
優點：
輸入元資料（ cluster map、 placement rule）較少，可以應對大規模叢集。
可以應對叢集的擴容和縮容。
採用以概率為基礎的統計上的均衡，在大規模叢集中可以實現資料均衡

缺點
在小規模叢集中，會有一定的資料不均衡現象（權重的影響低，主要起作用的是偽隨機演算法）。
看清楚了定址的過程，就明白為啥PG不能輕易變更了；PG是定址第一步中的取模引數，變更PG會導致物件的PG id 都發生變化，從而導致整個叢集的資料遷移；

Ceph 是Sega本人的博士論文作品, 其博士論文被整理成三篇短論文，其中一篇就是 CRUSH
CRUSH論文標題為《CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data》，介紹了CRUSH的設計與實現細節。

（PS：另外兩篇是 RADOS和 CephFS, 分別講 Ceph 的伺服器實現和 Ceph 檔案系統的細節實現）

錯誤檢測和恢復

錯誤檢測
利用心跳
上報monitor
更新map

錯誤恢復
主osd主持恢復工作
若主osd掛掉，二級osd選擇一個頂上

資料條帶化

由於儲存裝置吞吐量的限制，影響效能和可伸縮性。
跨多個儲存裝置的連續塊條帶化儲存資訊，以提高吞吐量和效能
Ceph條帶化相似於RAID0
注意：ceph條帶化屬於client端，不在RADOS範疇

注意：條帶化是獨立於物件副本的。由於CRUSH副本物件跨越OSDs，所以條帶自動的被複制。

條帶化引數

Object Size:
足夠大可以容納條帶單元，必須容納一個或者多個條帶單元。（如2MB，4MB）
Stripe Width:
一個條帶單元的大小，除了最後一個，其他必須一樣大（如64K）
Stripe Count:
連續寫入一系列的物件的個數（如4個）
注意：
引數一旦設定不可改變，提前做好效能測試

Ceph的高階功能

Ceph支援豐富的儲存功能，從分散式系統最基本的橫向擴充套件、動態伸縮、冗餘容災、負載平衡等，到生產環境滾動升級、多儲存池、延遲刪除等，再到高大上的Ceph叢集、快照、EC糾刪碼、跨儲存池快取等，下面我們簡單介紹幾個關鍵特性。

Ceph基於統一儲存系統設計，支援三種介面。File檔案系統支援POSIX、HDFS、NFS、CIFS服務介面，Block塊服務支援精簡配置、COW快照、克隆，物件服務支援原生的Object API、也相容Swift和S3的API。

在Ceph storage 2中，提供全球物件儲存叢集，支援單個名稱空間，並支援在多Region地區執行的叢集之間提供了資料同步，包含Region內主Zone到從Zone資料同步(可同步資料和元資料)和不同Region間資料同步(只能同步元資料，包含閘道器使用者和桶資訊、但不包含桶內的物件)。

哪些公司在使用Ceph

紅帽
美國預測分析公司FICO
澳大利亞的莫納什大學 500PB
樂視，一點資訊，今日頭條，滴滴，青雲等

Ceph僅僅是OpenStack後端儲存標配，目前很多儲存廠商、大企業都基於Ceph技術開發或搭建儲存系統，我們首先看看幾家儲存廠商的產品，如HopeBay和SanDisk。

Hope Bay科技是一家專注於雲平臺的科技公司，擁有ArkEase Pro儲存服務平臺、ArkFlex資料儲存平臺、Ark Express儲存閘道器和ArkVoice企業雲端語音錄製平臺。在ArkFlex資料儲存平臺中，Hope Bay對Ceph檔案系統進行改良，將CIFS、NFS、iSCSI建構在Ceph RBD之上。

SanDisk收購Fusion-io之後相繼推出ioControl混合式儲存陣列和InfiniFlash系列快閃記憶體。剝離相關業務到新成立新NextGen公司，SanDisk通過InfiniFlash系列快閃記憶體主攻快閃記憶體市場，其中就有一款機型InfiniFlash System IF500採用Ceph技術(IF100硬體和InfiniFlash OS Ceph橫向擴充套件軟體)，同時提供物件儲存與塊儲存服務。SanDisk的儲存策略是比較開放，低端儲存IF100(純硬體形態)整合了Nexenta的基於ZFS檔案系統開源NexentaStor軟體(支援NAS和iSCSI)，而高階的IF700則使用了Fusion-io時期的 ION Accelerator資料庫加速軟體。

此外，很多大型企業也採用Ceph構建構建雲平臺和分散式儲存解決方案，也正是因為Ceph和OpenStack的深度整合，使得Ceph和OpenStack配合被網際網路公司用來搭建雲平臺。

樂視基於OpenStack 和Ceph(RBD塊儲存和RADOSGW物件)搭建樂視雲平臺；寶德雲也基於OpenStack、Ceph(RBD塊儲存和CephFS) 和Docker構建。電商eBay也採用Ceph和 OpenStack 建設私有云，每個Ceph叢集容量都高達數 PB 級別，這些叢集主要為 OpenStack 服務。同時，eBay 團隊在NAS雲化投入逐漸加大，CephFS有可能作為NAS 雲化的不二之選。

攜程基於Ceph搭建PB級雲物件儲存，浪潮AS13000系列儲存也是基於Ceph開發，思科UCS流媒體服務儲存也是基於Ceph物件儲存，雅虎基於Ceph搭建雲物件儲存。聯通研究院、CERN實驗室、United Stack等也基於Ceph搭建了開發環境。

Ceph已經支援雲Ready: 隨著雲端計算的發展，首先Ceph搭上了OpenStack這隻大船，預示著Ceph已經完全雲Ready。接著Ceph受到Intel、SanDisk、思科、Yahoo等公司支援，尤其是RedHat以重金收購Inktank公司，將其作為發展的主方向。通過多年發展，RadHat也明確了Ceph和Gluster側重點和發展方向，Gluster更專注於檔案，Ceph更專注於塊和物件。

Ceph社群力量支援:Ceph社群現在已經有很多廠商參入進來，從Intel、思科、SanDisk等這樣的巨頭，到United Stack這樣的Startup公司，再到電信、大學、研究所這類非儲存領域的公司或單位，Ceph的參與隊伍越來越龐大。

Ceph功能的不斷完善: Ceph的效能不斷得到提升，儲存特性也不斷豐富，甚至可以與傳統專業儲存媲美，完備的儲存服務和低廉的投資成本，使得越來越多的企業和單位選用Ceph提供儲存服務。

SDS和分散式架構: Ceph軟體與硬體平臺之間完全解耦，對企業來說搭建Ceph儲存系統的門檻是逐漸變低，部署簡單基於Linux Ubuntu和標準X86平臺。Ceph與儲存Sandisk、寶德，雲端計算United Stack、攜程和樂視等公司的成功實踐，也為Ceph的廣泛應用打下參考基礎。

Ceph二次開發可優化的地方

內網傳輸的加密安全問題
優化Ceph對levelDB迭代器的使用