1. GPFS和CEPH的初次亮相

GPFS，是一個高性能的共享并行文件系統(tǒng)，自誕生起，就為高性能、數據共享、開放、安全而生。為了更好的融入IBM光譜存儲大家庭，我有了個更好聽的名字——SPECTRUM SCALE，當然對于我來說，這不僅僅是名字的變更，也意味在我身上，增加了關于閃存、容災、備份、云平臺接入等諸多特性，我扮演的角色更加重要，職能定位也愈加明晰了。關于未來，我也有自己的想法，有更大的愿景，希望能和數據中心的其它小朋友們相處愉快，和諧。

CEPH，是一個00后，名字來源于寵物章魚的一個綽號，頭像就是一只可愛的軟體章魚，有像章魚觸角一樣并發(fā)的超能力。我平常主要活躍在云計算領域，經過多年的脫胎換骨，不斷迭代，我積攢了良好的口碑，好用，穩(wěn)定，關鍵還免費，我可以提供對象，塊和文件級存儲的接口，幾乎可以覆蓋所有…哇，說著說著突然感覺自己原來無所不能呢，當然，目前我還在長身體的階段，很多特性在趨于完善，希望未來我們可以相互促進成長。

2. GPFS的前世今生

作為一款成熟的商業(yè)產品，GPFS的發(fā)展史早已百轉千回了，在揭開GPFS的面紗之前，我們還是先來掃掃盲，復習一下在GPFS集群架構中涉及到的基本概念和組件。

GPFS架構解藕

a) Cluster：GPFS的組成架構，由一系列的節(jié)點和NSD組成，集群的配置文件通常保存在兩臺主備的節(jié)點上。

b) Node：安裝了GPFS軟件的主機，它可以通過直接或者通過網絡訪問其它節(jié)點的方式來訪問存儲，每個節(jié)點在集群配置中有不同的角色。

c) Cluster manager：負責整個集群配置的正確性和完整性，主要負責監(jiān)控磁盤租約，檢測節(jié)點故障和控制節(jié)點的故障恢復，共享配置信息，選舉文件管理節(jié)點等任務。

d) File system manager:維護文件系統(tǒng)中磁盤的可用性信息，管理磁盤空間，文件系統(tǒng)配置，磁盤配額等。

e) Block:一個集群中單個I/O操作和空間分配的最大單位。

f) NSD:提供全局數據訪問的集群組件，如果節(jié)點和磁盤間沒有直接連接，則NSD最好具有主服務節(jié)點和輔服務節(jié)點。

g) Chunk: FPO架構中的概念，它是一組block塊的集合，看起來像一個大的block，一般用于大數據環(huán)境。

h) Failure Group:一組共享故障的磁盤組，當其中一塊盤失效時，整個組會同時失效。

i) Metadata:包括集群配置信息和非用戶數據。

j) Quorum Nodes:用于保持集群活動的仲裁節(jié)點，一般有兩種仲裁方式，節(jié)點仲裁和帶Tiebreakerdisk(心跳盤)的仲裁

上述組件如何有機的組合在一起提供存儲服務呢，把以上組件拼接起來，就可以得到下圖所示的集群大體架構：

GPFS使用方案

基本架構了解了，那怎么用呢？先祭出三張架構圖，業(yè)內人士一看應該懂，不明白沒關系，往下針對這幾張圖稍作解釋：

GPFS在系統(tǒng)架構設計十分靈活，豐富的功能延伸出了多種組網方式，而每種組網方式適配不同的應用模式，常見組網方式包括SAN、NSD、SNC、Remote Cluster和混合組網方式。

Storage Area Network(SAN) Model要求計算節(jié)點直接掛載存儲，并且充當計算節(jié)點、NSD Server、NSD Client三種角色。NSD Server通過存儲網絡或直連的方式連接到存儲設備上，前端通信協議為GE，后端通信協議為FC或Infiniband，適用于小規(guī)模集群。

Network Shared Disk(NSD) Server Model要求計算節(jié)點安裝GPFS軟件，并充當NSD Client角色，使用單獨的服務器充當NSD Server，負責處理I/O。NSD磁盤BuildingBlock的方式，每兩臺服務器通過直連的方式連接到NSD Server上，前端通信協議為10GE或Infiniband，后端通信協議為FC或Infiniband，適用于大規(guī)模集群擴展。

Shared Nothing Cluster(SNC)Model要求計算節(jié)點安裝GPFS軟件，并充當NSD Client角色，使用單獨的服務器充當NSD Server，負責處理I/O。NSD采用服務器自帶硬盤，或者獨立存儲，數據之間不使用寬條帶方式進行分布，而采用FPO方式進行排布。前端通信協議為10GE或Infiniband，后端通信協議為FC或Infiniband。適用于Hadoop和Mapreduce環(huán)境。

Remote Cluster Mount Model要求GPFS提供在多個GPFS集群間共享數據的服務，GPFS在其他集群mount本集群的資源，其訪問磁盤和本地訪問磁盤體驗類似，這種跨集群訪問可以是在一個數據中心也可以是跨遠距離的WAN。在一個多集群配置中每個集群可以進行分別的管理，在簡化管理的同時提供一個多組織數據訪問的視圖。前端通信協議為10GE或Infiniband，后端通信協議為FC或Infiniband，適用于同城或異地部署環(huán)境。

混合組網環(huán)境下，GPFS允許在一個集群中混合部署多種組網環(huán)境，例如集群中部分主機采用Storage Area Network (SAN) Model，部分主機采用Network Shared Disk (NSD) Server Model方式進行組網。當多個組網類型同時存在于一個集群中時，影響的只是集群使用NSD的方式，對于上層主機對數據的訪問沒有影響。

GPFS應用場景

在傳統(tǒng)DB2數據庫雙活方案GDPC的使用場景中，為了實現跨站點的雙活+容災，底層存儲方案選用GPFS，雙站點架構中，兩個站點均配備主機和存儲資源，每個站點的存儲形成一個failure group， 遠程訪問對端存儲采用nsd server的方式訪問，兩個failure group間完全冗余，任何一個站點出現故障都不影響文件系統(tǒng)的正常使用，并通過第三方站點的一臺服務器和nsd作為仲裁節(jié)點，是真正意義上的雙活。

GPFS可以用來替代HDFS作為大數據的底層存儲，GPFS FPO+Symphony作為相對Mapreduce更領先的分布式計算框架，可以更靈活和支持和對接企業(yè)的IT使用場景。

在IBM的部分企業(yè)級云產品中，GPFS FPO也被用來作為私有云產品的底層存儲來使用，用來存儲虛機鏡像和介質，這一點上使用和CEPH也極為相似。

3.CEPH的發(fā)展之路

作為云計算的三架馬車，網絡，存儲，管理平臺，業(yè)界的開源方案里，網絡層面SDN日漸成熟，管理平臺上，Openstack已經創(chuàng)造了一個時代，而CEPH，無疑成為存儲最犀利的開源解決方案。談起它的架構之前，我們有必要先來了解以下這些概念，同時為了更加形象化，我們將部分組件對應到GPFS的組件上來理解，但請注意實際的功能和結構仍然差別巨大。

CEPH架構解藕

a) Ceph monitor——對應quorum + cluster manager:保存CEPH的集群狀態(tài)映射，維護集群的健康狀態(tài)。它分別為每個組件維護映射信息，包括OSD map、MON map、PG map和CRUSH map。所有群集節(jié)點都向MON節(jié)點匯報狀態(tài)信息，并分享它們狀態(tài)中的任何變化。Ceph monitor不存儲數據，這是OSD的任務。

b) OSD——對應NSD: CEPH的對象存儲設備，只要應用程序向Ceph集群發(fā)出寫操作，數據就會被以對象形式存儲在OSD中。這是Ceph集群中唯一能存儲用戶數據的組件，同時用戶也可以發(fā)送讀命令來讀取數據。通常，一個OSD守護進程會被綁定到集群中的一塊物理磁盤，一塊磁盤啟動一個OSD進程，可以對應GPFS的NSD概念。

c) Pool：是存儲對象的邏輯分區(qū)，它規(guī)定了數據冗余的類型和對應的副本分布策略，副本支持兩種類型：副本（replicated）和 糾刪碼（Erasure Code）

d) PG(placement group)——對應Chunk：是一個放置策略組，它是對象的集合，該集合里的所有對象都具有相同的放置策略；簡單點說就是相同PG內的對象都會放到相同的硬盤上；PG是ceph的核心概念， 服務端數據均衡和恢復的最小粒度就是PG；

e) MDS——對應Filesystem manager：Ceph元數據服務器，MDS只為CephFS文件系統(tǒng)跟蹤文件的層次結構和存儲元數據。Ceph塊設備和RADOS并不需要元數據，因此也不需要Ceph MDS守護進程。MDS不直接提供數據給客戶端，從而消除了系統(tǒng)中的故障單點。

f) RADOS：RADOS是Ceph存儲集群的基礎。在Ceph中，所有數據都以對象形式存儲，并且無論是哪種數據類型，RADOS對象存儲都將負責保存這些對象。RADOS層可以確保數據始終保持一致。要做到這一點，須執(zhí)行數據復制、故障檢測和恢復，以及數據遷移和在所有集群節(jié)點實現再平衡。g) RBD：RADOS塊設備，提供持久塊存儲，它是自動精簡配置并可調整大小的，而且將數據分散存儲在多個OSD上。RBD服務已經被封裝成了基于librados的一個原生接口。

h) RGW:RADOS網關接口,RGW提供對象存儲服務。它使用librgw和librados，允許應用程序與Ceph對象存儲建立連接。RGW提供了與Amazon S3和OpenStack Swift兼容的RESTful API。

i) CephFS——對應GPFS文件系統(tǒng)：Ceph文件系統(tǒng)提供了一個使用Ceph存儲集群存儲用戶數據的與POSIX兼容的文件系統(tǒng)。和RBD、RGW一樣，CephFS服務也基于librados封裝了原生接口。

同樣，如果把上述元素和概念按照邏輯進行拼接，可以得到以下這張CEPH的基本架構圖，圖中反映了各個組件的邏輯關系。

CEPH提供了一個理論上無限擴展的集群，客戶端和ceph osd進程通過crush算法來計算數據位置，而不必依賴一個中心查找表，我們知道凡是網絡設備都有并發(fā)連接數據的限制，集中式/單體式的存儲系統(tǒng)，對于大規(guī)模部署來說，很容易達到物理極限，在CEPH的數據訪問機制中，客戶端和osd進程直接通信，提高了性能和系統(tǒng)總容量，消除了單點故障，CEPH客戶端僅在需要時與osd進程建立一個會話。

osd進程加入一個集群，并且報告他們的狀態(tài)，分為up和down兩種狀態(tài)，代表是否可以響應ceph客戶端的需求，如果osd進程失敗，則無法通知ceph monitor它已經down掉，ceph通過周期性的ping OSD進程，確保它正在運行，CEPH授權OSD進程，確定授信的OSD進程是否已關閉，更新cluster map，并報告給CEPH Monitor。

OSD進程也通過crush算法，計算對象的副本應該存放的位置，在一個寫場景中，客戶端使用crush算法計算應該在哪里存放對象，并將對象映射到一個pool和placement group,然后查詢crush map來定位placement group中的主OSD進程。

客戶端將對象寫入主osd的placement group中，然后主osd使用它自己的crush map來找到第二、三個OSD，并且將對象副本寫入第二、第三OSD的placement group中，主OSD在確認對象存儲成功后會給客戶端一個回應。OSD進程完成數據的復制，不需要ceph客戶端參與，保證了數據的高可用性和數據安全。

CephFS從數據中分離出元數據并保存在MDS中，而文件數據保存在CEPH存儲集群的objects中，ceph-mds作為一個進程單獨運行，也可以分布在多個物理主機上，達到高可用和擴展性。

CEPH使用方案

了解了架構和原理，該怎么使用呢？Ceph主要用于完全分布式操作，沒有單點故障，可擴展到exabyte級別，完全免費使用。其采用的位置感知算法和數據復制機制使其具有容錯能力，并且不需要特定的硬件支持，也成為他天生驕傲的資本，大大降低了使用門檻，在貧瘠的物理介質上就可以野蠻生長。一般來說，CEPH主要提供三種使用場景，rbd(block device),對象存儲和CephFS文件系統(tǒng)方式，如下圖所示：

CEPH客戶端使用原生協議與CEPH存儲集群進行交互，CEPH將這些功能打包成librados庫，因此你可以創(chuàng)建自己的CEPH客戶端，CEPH作為分布式存儲，對外提供各類型的標準存儲服務。

CEPH block device的快照功能對于虛擬化和云計算來講很有吸引力，在虛擬機場景中，極具典型的是在Qemu/KVM使用rbd網絡存儲驅動部署CEPH block device，宿主機使用librbd向客戶機提供塊設備服務。而在K8S管理的容器平臺中，Ceph也可以提供標準rbd設備的動態(tài)供給和共享存儲空間。

Scrub是Ceph集群進行的副本間的數據掃描操作，以檢測副本間的數據一致性，包括Scrub和Deep-Scrub，其中Scrub只是對元數據信息進行掃描，相對比較快，而Deep-Scrub不僅對元數據進行掃描，還會對存儲的數據進行掃描，相對比較慢。Ceph集群會定期進行Scrub操作。

當然，Ceph Scrub機制存在的問題。在發(fā)現不一致對象后，缺少策略來自動矯正錯誤，比如如果多數副本達成一致，那么少數副本對象會被同化。Scrub 機制并不能及時解決存儲系統(tǒng)端到端正確的問題，很有可能上層應用早已經讀到錯誤數據，下面一起來看看Scrub的工作流程：

① OSD 會以 PG 為粒度觸發(fā) Scrub流程，觸發(fā)的頻率可以通過選項指定，而一個PG的Scrub啟動都是由該 PG 的 Master 角色所在OSD啟動。

② 一個PG在普通的環(huán)境下會包含幾千個到數十萬個不等的對象，因為Scrub流程需要提取對象的校驗信息然后跟其他副本的校驗信息對比，這期間被校驗對象的數據是不能被修改的。因此一個PG的Scrub流程每次會啟動小部分的對象校驗，Ceph 會以每個對象名的哈希值的部分作為提取因子，每次啟動對象校驗會找到符合本次哈希值的對象，然后進行比較。這也是 Ceph稱其為Chunky Scrub的原因。

③ 在找到待校驗對象集后，發(fā)起者需要發(fā)出請求來鎖定其他副本的這部分對象集。因為每個對象的Master和Replicate節(jié)點在實際寫入到底層存儲引擎的時間會出現一定的差異。這時候，待校驗對象集的發(fā)起者會附帶一個版本發(fā)送給其他副本，直到這些副本節(jié)點與主節(jié)點同步到相同版本。

④ 在確定待校驗對象集在不同節(jié)點都處于相同版本后，發(fā)起者會要求所有節(jié)點都開始計算這個對象集的校驗信息并反饋給發(fā)起者。

⑤ 該校驗信息包括每個對象的元信息如大小、擴展屬性的所有鍵和歷史版本信息等等，在Ceph 中被稱為 ScrubMap。

⑥ 發(fā)起者會比較多個ScrubMap并發(fā)現不一致的對象，不一致對象會被收集最后發(fā)送給 Monitor，最后用戶可以通過Monitor了解Scrub的結果信息。

另外，當用戶在發(fā)現出現不一致的對象時，可以通過“ceph pgrepair [pg_id]”的方式來啟動修復進程，目前的修復僅僅會將主節(jié)點的對象全量復制到副本節(jié)點，因此目前要求用戶手工確認主節(jié)點的對象是“正確副本”。此外，Ceph允許Deep Scrub模式來全量比較對象信息來期望發(fā)現 Ceph 本身或者文件系統(tǒng)問題，這通常會帶來較大的IO負擔，因此在實際生產環(huán)境中很難達到預期效果。

通過上述Scrub流程，大家也會發(fā)現目前的 Scrub機制還存在以下2個問題：

① 在發(fā)現不一致對象后，缺少策略來自動矯正錯誤，比如如果多數副本達成一致，那么少數副本對象會被同化。

② Scrub 機制并不能及時解決存儲系統(tǒng)端到端正確的問題，很有可能上層應用早已經讀到錯誤數據。

對于第一個問題，目前Ceph已經有Blueprint來加強Scrub的修復能力，用戶啟動Repair時會啟動多數副本一致的策略來替代目前的主副本同步策略。

4、GlusterFS和Ceph對比

GlusterFS和Ceph是兩個靈活的存儲系統(tǒng)，有著相似的數據分布能力，在云環(huán)境中表現非常出色。在嘗試了解GlusterFS與Ceph架構之后，我們來看看兩者之間的簡單對比。

縱向擴展和橫向擴展：在云環(huán)境中，必須可以很容易地向服務器添加更多存儲空間以及擴展可用存儲池。Ceph和GlusterFS都可以通過將新存儲設備集成到現有存儲產品中，滿足擴充性能和容量的要求。

高可用性：GlusterFS和Ceph的復制是同時將數據寫入不同的存儲節(jié)點。這樣做的結果是，訪問時間增加，數據可用性也提高。在Ceph中，默認情況下將數據復制到三個不同的節(jié)點，以此確保備份始終可用性。

商品化硬件：GlusterFS和Ceph是在Linux操作系統(tǒng)之上開發(fā)的。因此，對硬件唯一的要求是這些產品具有能夠運行Linux的硬件。任何商品化硬件都可以運行Linux操作系統(tǒng)，結果是使用這些技術的公司可以大大減少在硬件上的投資——如果他們這樣做的話。然而，實際上，許多公司正在投資專門用于運行GlusterFS或Ceph的硬件，因為更快的硬件可以更快地訪問存儲。

去中心化：在云環(huán)境中，永遠不應該有中心點故障。對于存儲，這意味著不應該用一個中央位置存儲元數據。GlusterFS和Ceph實現了元數據訪問去中心化的解決方案，從而降低了存儲訪問的可用性和冗余性。

現在再來談談GlusterFS與Ceph的差異。顧名思義，GlusterFS是來自Linux世界的文件系統(tǒng)，并且遵守所有Portable Operating System Interface標準。盡管你可以將GlusterFS輕松集成到面向Linux的環(huán)境中，但在Windows環(huán)境中集成GlusterFS很難。

Ceph是一種全新的存儲方法，對應于Swift對象存儲。在對象存儲中，應用程序不會寫入文件系統(tǒng)，而是使用存儲中的直接API訪問寫入存儲。因此，應用程序能夠繞過操作系統(tǒng)的功能和限制。如果已經開發(fā)了一個應用程序來寫入Ceph存儲，那么使用哪個操作系統(tǒng)無關緊要。結果表明Ceph存儲在Windows環(huán)境中像在Linux環(huán)境中一樣容易集成。

基于API的存儲訪問并不是應用程序可以訪問Ceph的唯一方式。為了最佳的集成，還有一個Ceph塊設備，它可以在Linux環(huán)境中用作常規(guī)塊設備，使你可以像訪問常規(guī)Linux硬盤一樣來使用Ceph。Ceph還有CephFS，它是針對Linux環(huán)境編寫的Ceph文件系統(tǒng)。

為了比較GlusterFS與Ceph哪個更快已經進行了幾項測試，但迄今為止沒有確切的結論。GlusterFS存儲算法更快，并且由于GlusterFS以磚組織存儲的方式實現了更多的分層，這在某些場景下(尤其是使用非優(yōu)化Ceph)可能導致更快的速度。另一方面，Ceph提供了足夠的定制功能來使其與GlusterFS一樣快。

然而，實踐表明Ceph訪問存儲的不同方法使其成為更流行的技術。更多的公司正在考慮Ceph技術而不是GlusterFS，而且GlusterFS仍然與Red Hat密切相關。例如，SUSE還沒有GlusterFS的商業(yè)實施，而Ceph已經被開源社區(qū)廣泛采用，市場上有各種不同的產品。在某種意義上來說，Ceph確實已經勝過GlusterFS。

5.分布式存儲未來

未來的IT架構是生態(tài)之爭，贏生態(tài)者得天下，就像開放的安卓贏得了眾多開發(fā)者的親賴，繁榮的產品生態(tài)也成就了安卓。運維自動化和智能化運維建設，要求底層IT環(huán)境實現高度整合，自主可控更是對開放性的要求，開放是一個產品的親和力，意味著可以更靈活的融入當前IT環(huán)境，當前云計算的存儲標準接口仍然有開放席位，靜待新的有生力量入駐。

不管是存儲，還是網絡等基礎架構，都在試圖屏蔽底層物理硬件的差異，實現硬件的標準化管理，用軟件定義一切，分布式存儲就是在這樣的趨勢下，贏得了蓬勃發(fā)展的契機，開放的產品接口，豐富的插件，與當前環(huán)境的兼容耦合性，都將成為分布式存儲領域制勝的關鍵，未來分布式存儲在安全性、產品化建設、兼容性、可管理性、穩(wěn)定性上的不懈努力，將是引領分布式存儲占領數據中心存儲江山的重要砝碼。

審核編輯：劉清