1. GPFS和CEPH的初次亮相

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

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

2. GPFS的前世今生

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

GPFS架構解藕

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

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

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

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

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

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

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

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

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

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

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

GPFS使用方案

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

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

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

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

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

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

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

GPFS應用場景

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

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

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

3.CEPH的發展之路

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

CEPH架構解藕

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

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

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

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

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

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

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

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

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

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

osd進程加入一個集群，并且報告他們的狀態，分為up和down兩種狀態，代表是否可以響應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文件系統方式，如下圖所示：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4、GlusterFS和Ceph對比

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

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

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

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

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

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

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

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

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

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

5.分布式存儲未來

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

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

審核編輯：劉清