Ceph vs Swift - 架構剖析

Ceph和Swift，哪種更好？這個問題上大家爭論不休，本文從兩者的架構角度分析兩種方式各自的優缺點，并且給出如何選擇的建議。

當工程師們討論存儲，談到Ceph和Swift時，他們通常都一致認為其中一個非常棒，另外一個卻很糟糕。但問題時，他們在哪個好哪個不好上卻意見不一。

經常會有客戶問我相同的問題，“我們聽說Ceph可以代替其他所有類型的存儲。為什么不能用它做所有事情呢？”

我會在Vancouver的OpenStack Summit大會上從架構角度探討Ceph和Swift，分享在這兩者之間到底該如何抉擇，也會為兩種平臺的解決方案都給出建議。本文，我們一起看看他們的架構細節和不同之處。

深入淺出

Swift在OpenStack開始發展之初就出現了，大概在五年之前。它是OpenStack的核心項目，并且被無數次證明強大且穩定。

問題是，Swift的設計導致在傳輸速度和延遲時間上都不強。造成這個問題的主要原因是Swift集群進出的流量都要通過代理服務器。

另一個原因，也是很多人認為Ceph更好的原因，是Swift不支持塊存儲和文件存儲。

最后，當對象副本不一定同時更新時延遲的問題便會浮現，這會導致請求者在第一次更新某個對象到新版本之后，讀取到的卻仍然是舊版本。這種行為被稱為最終一致性。

另一方面，Ceph也有自己的問題，特別是在云環境上。它的多地域支持，雖然經常被當做優勢來宣傳，但實際上還是master-slave模型。因為只能從master到slave進行復制，所以在多于兩個地域時，基礎架構上的負載分布會很不均衡。

Ceph的兩地域設計也不太實際，因為只支持master上的寫入，而不阻隔slave上的寫入。這樣的配置最嚴重時可能導致整個集群的崩潰。

Ceph的另一個短板是安全性。云計算節點上的RADOS客戶端直接與RADOS服務器交互所使用的網絡與Ceph用于未加密復制流量的網絡相同。如果某個Ceph客戶端節點被入侵，攻擊者便能得到存儲網絡的所有流量。

針對Ceph的弱點，你可能會問，為什么不直接構建一個Ceph集群，擴展到兩個地域呢？一個原因是Ceph只能同步寫入，并且要求寫入節點達到quorum數才能成功返回。

了解這些問題之后，我們來假定有一個集群跨越兩個地域，相隔數千英里，100ms延時，非常慢的網絡連接。假定將兩個副本寫入到本地地域，另外兩個寫入到遠程地域。這時四次副本的quorum數是三次，這就意味著這次寫請求在至少完成一次遠程拷貝前都不會返回。也就意味著即使是很小量的一次寫入也會延遲0.2秒，而大批量寫入則會因為吞吐量限制嚴重受阻。

另一方面，Swift，在與之相同的兩地域架構中，會先在本地寫入，然后基于一致性設計在一段時間里復制到遠程地域。Swift也要求寫入 quorum，但是可以在集群上配置write_affinity設置強制限定寫入quorum在本地地域，因此本地寫入完成后就會成功返回。

那么我們在Ceph和Swift之間如何抉擇呢？

如何選擇？

如果部署只在單一地域，沒有計劃擴展到多個地域的話，Ceph會是很好的選擇。Mirantis OpenStack底層可以選擇Glance或者Cinder。但是，如果要考慮大規模部署的話，Swift比Glance更適合。它的多地域能力會勝過 Ceph的速度和強大的一致性模型。

很多情況下，速度并不是決定因素，安全性則是更大的問題，這時，Swift更適合，它封閉的復制網絡更為安全。另一方面，如果云基礎架構本身已經很安全，存儲安全性優先級便會降低，這時可能Ceph更適合。

與其比來比去，不如在同一個云基礎架構里同時擁有這兩種選擇。比如，可以使用Ceph作為本地高性能存儲，而Swift則作為多地域Glance后臺，這時復制很重要而速度并不關鍵。但是，擁有這兩種選擇的解決方案花費必然更多，因此可能還是需要二選一。

對于很多客戶，我的個人建議是，Mirantis提供了架構設計評估來幫助收集所有需求和參數，提供適合特定使用場景和業務驅動的解決方案，會幫助全面評估所有業務，技術和運營因素。然后你可以權衡這些因素，以及這兩種選擇的優缺點。誰知道呢？你的收獲很可能超過預期。

原文鏈接：Ceph vs Swift – An Architect’s Perspective（翻譯：崔婧雯 校對：魏小紅）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
譯者介紹
崔婧雯，現就職于IBM，高級軟件工程師，負責IBM WebSphere業務流程管理軟件的系統測試工作。曾就職于VMware從事桌面虛擬化產品的質量保證工作。對虛擬化，中間件技術，業務流程管理有濃厚的興趣。

來自：http://dockone.io/article/410