Ceph和Swift的比較 為什麼他們沒有撕逼

2021-08-04 11:36:37 字數 2697 閱讀 8711

ceph andswift: why we are not fighting

原文:ceph andswift: why weare not fighting

作者 :chmouelboudjnah

翻譯:bbsee[[email protected]]    

一下()中的內容均為譯者加入的

我剛剛從在香港舉行的openstack峰會上回來。和往常一樣,這次峰會上我和很多人進行了激烈的交流、聽了聽展示會,或者和大家一起展望一下彼此都熱衷的一些軟體的未來。

在和不同的人交流的過程中我發現這樣乙個常見的問題:人們想知道是不是「ceph比swift更加優秀」。

我從2023年被安排到swift專案組,之前openstack甚至只是乙個設想,到現在作為核心開發人員,很明顯我的回答是有傾向性的。

我可以理解當有可以作為更優選項的產品出現時,人們轉而選擇這個產品(的行為)。這是我們科技技術很正常的一種演變。我還記得當時,(讓我們)追憶一下,linux剛剛興起的時候,我頑固地堅持結合我的lynx和我的一些工具使用linux終端,放棄x11系統,因為我真的看不到它的優勢何在,現在我很高興地使用者mac

os x系統。

但是ceph和swift事實上並沒有相互競爭:它們是兩種不同的技術,每一種都有不同的設計目的。雖然這兩者之間有一些重疊的特性,但是他們二者有著不同的應用場景並且能在同一次部署中相處的很融洽。

特性比較:

從乙個高水平的角度來看,這兩種物件儲存技術之間最主要的區別在於:

ceph:

swift:

ceph做了大量的事情,不僅僅是物件儲存。ceph能作為一種開源的塊儲存(一種提供遠端虛擬磁碟的方式)來使用,這正是人們被它所吸引的地方。ceph在(塊儲存)這方面做的非常傑出,因此他似乎成為了一項部署openstack時非常受歡迎的塊儲存系統選項,總之,這是openstack和開源社群的一次雙贏。

ceph之所以能實現塊儲存源自它的強一致性,確保在給客戶端返回"ok"的響應之前,你要寫入的所有資料都被寫到了磁碟上。採用c開發使得ceph的效能最優化,與此同時,由於他的設計模式,使得客戶端(clients)能直接和儲存伺服器(osds)互動。

共享檔案系統的構建是一項尚未完成的工作,到目前為止(2023年)還沒有為生產環境做好準備。但是,一旦它成功了,它將解決過去幾十年人們努力嘗試解決的困難又複雜的問題。

另一方面,swift,只做一件事,並且做得非常好。它唯一的追求就是做好物件儲存並提供一種rest風格的api來訪問它。它是最終一致性的。這意味著,當硬體環境發生故障時(這是乙個集群不可避免的),swift會回退以提供高利用率的資料訪問。swift的最終一致性最有可能體現在當硬體出現故障時讀取被覆蓋寫的物件時,以及查詢乙個在同時建立了很物件的container(swift容器)物件列表時。

這種最終一致性也允許在跨度很廣的地理空間上部署swift集群。這不僅僅是「回放日誌」式的複製,它更允許部署者針對不同region的同步或者非同步複製進行集群配置。swift的**伺服器們能夠感知當前它們所處的是哪個region,這就允許當有新的資料被寫入時部署者可以優化吞吐量或者資料的散布。

使用python開發swift對於部署者來說有巨大的優勢,不僅僅是因為語言本身,而是因為它與能嵌入wsgi管道的靈活的中間外掛程式更加契合。同時也可以非常輕鬆地將swift插入一系列不同的認證系統,允許所有型別的中介軟體修改它的行為並且結合具體的功能。

和python相似的是,swift擁有乙個稱之為"內建電池"的思想體系,你擁有所有型別的中介軟體做著不同的事情,使得swift更可靠地替代s3。

最後乙個swift的優勢是它已被證實能在超大規模生產中、在大量不同的公共的雲中執行並且執行非常得良好。

另一方面,ceph實現物件儲存的方式是通過它的radosgateway(物件閘道器)而與api無關,ceph擁有健壯的**s3的api,它沒有全規模的pythonwsgi系統那樣強大並且不支援模組化。將它作為閘道器的問題是必須始終模擬或者遵循swift的api,但是它的核心api是定義良好的,穩定的並且向後相容的,當然這不包括所有和swift一起裝配的中介軟體

使用場景

如何你只能選擇其中一種,並且你有塊儲存需求,你肯定會選擇使用ceph。如果你只是物件儲存這樣的使用場景,那麼我建議你使用使用swift。

話說回來,如果你是兩者都想使用的那種應用場景,不過一些開發團隊不太希望在不同的系統上管理兩個不同的集群。如果你想在一些簡單的應用場景使用s3

api或者swift api,rdosgw(rados gateway

物件閘道器)能是乙個非常不錯的選擇,但是這並不能為你提供乙個功能完備的物件儲存系統。另外一點值得考慮的是通過radosgw儲存的物件無法從塊儲存系統獲取,因為他們有著不同使用方式,他們將在不同的硬體上存放(通過ceph的智慧型模組化放置技術).

到了最後,使用者希望有選擇的餘地,同時,感謝redhatglusterteam(紅帽主儲存團隊),swift現在擁有了乙個多後端系統,在那裡你可以擁有乙個不同的、高效支援ceph作為物件儲存伺服器的儲存後端系統。

目前我們還沒有完全做到這一點(swift多後端系統嵌入ceph),swift和ceph的開發者們曾經一起討論嘗試找出如何嵌入,但是,最後,這將為終端使用者提供最小管理的選擇。總結

不要再認為swift和ceph是對手了。這兩者都是優秀的、各有特定任務的開源專案。主要競爭是專有軟體解決方案導致廠商鎖定,swift和ceph強大的社群和大家熱烈的討論都是都是解決大多數挑戰很好的解決方案。

感謝swiftstack、rackspace和inktank上的朋友們(還有我的同事們)查閱我的這次發帖。

Swift 和 C 的語法比較

昨天看到jacob leverich 寫了一篇文章 swift is a lot like scala 介紹swift 和 scala 的語法對比,從這篇文章的確可以看到swift 的語法和 scala 高度的相似。由於本人在搞ios開發之前增加搞過多年的.net 開發,於是技癢,昨晚抽了點時間寫了...

Swift中Tuple的比較

swift中tuple的比較遵循如下規則 1 被比較的tuple中包含的元素個數必須一樣,並且對應元素的型別也必須一樣 2 比較的結果由整個tuple的比較結果來決定。比如,如果是相等比較,那麼必須兩個tuple中的所有元素相等才行 4,dog 4,dog true because 4 is equ...

bash profile和 bashrc的什麼區別

etc profile 此檔案為系統的每個使用者設定環境資訊,當使用者第一次登入時,該檔案被執行.並從 etc profile.d目錄的配置檔案中蒐集shell的設定.etc bashrc 為每乙個執行bash shell的使用者執行此檔案.當bash shell被開啟時,該檔案被讀取.bash p...