引言：開源儲存軟體Ceph和Gluster能夠提供相似的特性並且能夠為使用者節省不小的開支。那麼誰更快？誰又更易用呢？
開源的Ceph及Red Hat旗下的Gluster都是成熟的技術，但興許不久之後就將經歷某種重生了。隨著儲存產業開始向擴充套件性儲存及雲的方向發展，將不斷會有基於這些低價的軟體技術的產品推向市場，而對這些自整合解決方案的補充在近一年來不斷湧現。
Ceph與Gluster在原理上有著本質上的不同。Ceph基於一個名為RADOS的物件儲存系統，使用一系列API將資料以塊(block)、檔案(file)和物件(object)的形式展現。Ceph儲存系統的拓撲結構圍繞著副本與資訊分佈，這使得該系統能夠有效保障資料的完整性。
而Red Hat將Gluster描述為可擴充套件的網路儲存裝置(Scale-out NAS)和物件儲存系統。它使用一個雜湊演算法來計算資料在儲存池中的存放位置，這點跟Ceph很類似。並且這是保證擴充套件性的關鍵。在Gluster中，所有的儲存伺服器使用雜湊演算法完成對特定資料實體的定位。於是資料可以很容易的複製，並且沒有中心後設資料單點這樣一個容易造成訪問瓶頸的部分，這種單點在早期Hadoop上出現，對效能和可靠性造成較大影響。
Ceph與Gluster有著相似的資料分佈能力。Ceph像大多數物件儲存軟體那樣，通過更大的節點集進行資料條帶化處理。這樣的好處是能夠防止資料訪問的瓶頸效應。
因為預設的Ceph塊比較小(僅為64KB)，所以資料流被切分為許多隨機的IO操作。而磁碟在隨機IO的時候一般能夠達到最大值(對HDD而言最多達到150次每秒)，並且這個數值不會隨傳輸的資料大小改變多少。所以對於Ceph而言，設定更大的IO塊意味著能夠一次聚合傳輸更多的資料。
Gluster預設的塊大小是128KB。這是Red Hat聲稱在一項基準測試中Gluster的效能是Ceph的三倍的主要原因。當然，測試者用了一些小技巧，所以測試結果是引數設定及實驗調優的結果。Ceph能夠將塊大小從64KB設定為256KB甚至1MB，這麼做也能使Ceph的效能得到不小的提升。
基準測試的門道相當複雜。塊大小的設定能夠左右Ceph與Gluster的效能對比。想要得到公平的比較結果，就必須依賴第三方不帶任何偏見的進行測試。顯然，Red Hat的報告有著顯著的誤導性。
回頭再來看兩者的擴充套件效能。兩個系統都避免了單節點的存在，因此可以近乎線性的進行擴充套件。重複資料刪除不會對效能造成太大的差異。兩者的伺服器端的壓縮技術減輕了磁碟利用及網路負載雙方面的壓力，並且降低了每個檔案的磁碟IO次數。
Ceph file journals技術能夠向SSD裝置中寫從而使得效能大幅度提升。並且支援快取(Caching)或分層(Tiering)，配置方式可簡可繁。
Ceph在恢復損壞的磁碟時有優勢。因為，Ceph相比Gluster將資料放置在一個更大的節點集中，有更多的裝置(磁碟驅動器)能夠同時輸入副本資料。這將大大縮短資料重建的時間，且不會顯著增加某個磁碟裝置的負載。在大規模的叢集中，這是一個顯著的優勢。
兩個系統的安裝和運維都相當簡單，但如果規劃要做長期的部署則必須花費一些時間認真準備。儲存管理員會發現Inktank為Ceph提供了一些更為精細的操作，因為Ceph對檔案系統、塊訪問以及遠端複製等操作都是採用內建函式的方式，而不像Gluster那樣採用外掛的方式。這給了Ceph很大的優勢，也是為什麼Ceph能夠在安裝上領先Gluster的原因。這能夠很輕鬆的解決塊遷移的問題並且提供單個儲存池的管理。
誠然，兩者在合理的代價下為使用者提供了較強的可選性。兩者的原始碼都是開源且免費的，Inktank和Red Hat公司則提供支援服務及管理工具包。相比傳統的儲存，隨著通用型硬體及儲存裝置(磁碟)價格的不斷下降，Ceph和Gluster都體現出越來越大的價值。
因為很好的功能、不錯的效能以及在價格方面的優勢，Ceph以及Gluster在昂貴的專用儲存之外提供了一種可行的解決方案，可以預見它們將會得到市場的青睞，並且有可能撼動由EMC或NetApp所把持的儲存市場。