Swift和Ceph都是開源的對象存儲系統。不過，盡管他們有很多相似之處，當選擇其中一個作為OpenStack存儲時有一些差異之處需要考量。
兩種最常見的OpenStack存儲選項分別是作為OpenStack項目一部分的Swift，以及獨立的開源系統Ceph。這兩個選項都提供對象存儲，并且可以免費下載。也因為這個原因，我們可能很難在這兩者之間進行選擇。以下所述是對OpenStack存儲Swift和Ceph進行評估時通常需要考慮的方面。
支持對于Swift和Ceph來說都是一個挑戰——這里有兩種選擇。企業可以增加員工來處理底層硬件和開源軟件，或者購買一個有支持的發布版本，附帶軟件支持和配置的專業知識。
許多廠商都支持Swift，每家都提供自己的OpenStack版本。支持可以是純軟件或者也同時包括硬件，比如購買一家供應商預集成的OpenStack系統。直到幾年前，Ceph都是由初創公司Inktank支持，但現在已經由紅帽全面支持。有很多廠商銷售預集成好的Ceph設備并負責硬件的支持。
采購和支持都是在某種公平競爭的市場環境中。確保售后的附加驅動器價格是否合理，因為某些主流供應商要求驅動器價格上的巨大漲幅。一般來說，Ceph的廠商使用商用現成的驅動器，并允許用戶從分銷商處購買標準的驅動器，而一些Swift廠商則更專有，要求你購買他們的驅動器。
Swift和Ceph的功能成熟度對比
Ceph是一個成熟的產品，已經獲得了很多的使用。但它并不是完美的，因為Ceph的部分組件，如對象存儲守護進程(OSD)的代碼，仍然在大改中。Ceph還支持文件和塊IO訪問模式，并且CERN已經證明了Ceph可以擴展到很大的規模。
Swift也算成熟。然而，大規模的OpenStack部署仍然很罕見，因此Swift的可擴展性在某種程度上還沒有被真正測試。Swift在Ceph之后幾年也進入了該領域，并且之后一直在努力的追趕Ceph。其結果是，一些Swift的開發人員目前主要關注在那些有助于Swift進一步區別于Ceph的功能細節上。
而這目前導致了Swift專有API的發展，該API不但不同于Ceph的API，與亞馬遜簡單存儲系統的API也不相同。然而對于另一套接口的抗拒正在產生，除非有非常有力的理由可以支持這種分歧，否則Ceph的市場份額可能會因此增長。
從路線圖可以看出，Ceph Special Interest Group正在明確的構建更好的方案。紅帽與SanDisk最近一起合作來改善Ceph的SSD和閃存性能，預期硬盤的使用情況在未來幾年內會下降。然而一個已知的Ceph短板是后端流量的緊張可能造成性能的瓶頸。擦除編碼，而不是復制，提高了流量水平，而紅帽和Mellanox的合作伙伴關系使遠程直接內存訪問和快速局域網連接成為可能，從而可以提高吞吐量和響應時間。
據紅帽表示，進一步改進正在進行中。例如，Ceph負責驅動存儲設備的OSD代碼，正在重寫并進行了性能調優。Ceph代碼在結構上已經為軟件定義基礎架構做好了準備，并且可以輕松地虛擬化和復制。這使得Ceph適用于超融合架構配置。
Swift和Ceph在數據一致性上的差異
Swift和Ceph在數據一致性管理上存在差異。Swift提供最終一致性，即一些數據對象從第一次拷貝之后的副本是以異步的方式寫入。這有可能會造成因為未完成的更新而返回錯誤的數據，但當副本位于不同的地理區域時運作良好。
Ceph則使用同步的進程，需要額定數量的副本被寫入才能確認寫入完成。這保證了一致性，但增加了延遲，如果遠程站點必須是定額寫入的一部分。你可以通過選擇合適的副本放置地點或者通過設置上的控制來解決這些問題。這對于Swift的不完整寫入問題也同樣適用，可以用write_affinity的設置強制在多本地寫入的基礎上加上定額。
雖然寫定額的問題對于性能來說有巨大的影響，但這可以通過只使用本地存儲來解決。
在這場Swift和Ceph競爭OpenStack存儲的比賽中，Ceph的贏面很大，至少現在來看是這樣。但是要給出一個完善的OpenStack存儲方案，重要的是要解決塊IO的問題。OpenStack Cinder項目就是為了這個目的，為各種各樣的基于SAN和LAN的網絡存儲提供一個統一的前端。傳統的塊IO軟件，如iSCSI，會在這些地方使用。目前沒有可以同Cinder競爭的軟件棧。
京公網安備 11010502049343號