[[136762]]

像Yahoo、Facebook這樣的企業都需要存儲數億級的用戶圖片，他們都在為實現這個目標而努力，Yahoo將非結構數據的MObStor對象存儲系統轉移到了Ceph上，并且正在部署***的基于Ceph的系統—云對象存儲，Yahoo在數百個PB級規模上操作，顯然已經是業內老大。

任何超級巨頭們都不會等待IT產業技術的自我更新，來滿足自己應用的需求，但是當一個可替代的開源項目成長足夠成熟，巨頭們通常會從自己的軟件到其他棧上做跨越式部署。從雅虎的門戶網站上我們可以清晰的看到，Yahoo的重心從自己研發的對象存儲轉移到了即將成為exascale級別的系統，這個系統基于開源項目Ceph，一種Swiss army knife的存儲。

這樣的跨越并不常見，因為這些超級公司更傾向去超越技術規模的限制，不論是他們自己的技術還是開源項目，當然通常是開源項目。但這種情況確實存在。比如說這周早些時候談到的平臺，媒體巨頭Netflix，它一直使用Cassandra NoSQL 數據庫的一個自定義版本來作為控制流媒體服務和用戶交互的后端，去年秋天，它將端口從DataStax轉移到Cassandra的商業級別的 variant上。而Yahoo正在進行一次更大的跨越，他們將自己研發的用于非結構數據的MObStor對象存儲系統轉移到了Ceph上，Yahoo的架構副總監說，他們這次的變化是經過慎重考慮的。

所有的信息技術都從cat圖片開始

雅虎是對象存儲領域規模上的創新者，就如同Facebook和他的Haystack系統，Amazon和他的S3系統，Mosso Cloud Files系統曾經是Rackspace Hosting的Swift對象存儲的基礎，而現在已成為OpenStack云控制器的一部分。Yahoo和Facebook都要存儲數億級別的用戶圖片，處理PB級別的容量，這就迫使他們開發自己的系統，實現更高效的圖片存儲功能，亞馬遜和Rackspace假設，創建云應用的用戶同樣希望將豐富的媒體嵌入到圖片上，所以他們想將對象存儲變成他們公有云的一部分。

上面提到的所有對象存儲系統，Haystack、 MObStor、 S3、Cloud Files/Swift， 他們被開發都是因為文件系統中常規存儲陣列都存在非常大系統開銷，這是因為用來跟蹤對象的元數據存在于集群中。對象存儲剛好忽略了文件系統，并將所有數據放在同一個bucket里，然后使用一個key，比如文件名或web的地址，在集群中找到該數據。這樣可以使元數據的開銷更小，因為沒有文件系統與之抗衡。

十幾年前，早期的雅虎圖片服務器是由一個特殊的存儲系統來處理非結構數據，其之后是一個由Yahoo開發，被稱為MObStor的系統，它是一個用起來更加復雜、更具有普遍性的對象存儲系統，Yahoo于2009年的夏天***公開提及MObStor。2005年，雅虎的圖片分享網站Flickr急需一種類似于對象存儲的技術，然而當時MObStor被雅虎應用程序用來儲存JavaScript和HTML代碼以及富媒體，在2010年夏天，雅虎的工程師更新了MObStor，這在當時非常先進，這也是在六個月內系統的處理能力增長了4X(倍)的一個因素。當Yahoo揭露MObSto的時候，它仍在運作，而且運行在專用系統Direct Object Repository Architecture (DORA)上，DORA是針對MObStor的一個新后端，被稱作是一個集群對象存儲系統，它在很多方面與Ceph非常相似。MObStor是DORA 后端系統的接口，Yahoo的程序員寫這個系統是因為他們需要存儲非結構性內容，比如照片、視頻和其他類似的數據。DORA是運行在普通硬件和存儲應用上的，雅虎當時還不太明確這些意味著什么，但是DORA后端特點允許Yahoo在更廉價的系統上做對象存儲，這也就說明了一切。

我們將在數百個PB級規模上操作，我不知道其他Ceph社區是否還會這樣做。如果我們不是***的，那么我們就會成為***的產品用戶，而且我們很可能會去尋找適合我們規模的版本。你只需要看雅虎這個規模的數據，不用看傳統的那些。

經過一些改進，McMillen說貫穿Yahoo所有的服務和中心數據，如果將對象、塊和文件存儲疊加在一起，這將是一個exabyte級別的存儲。在發布過的一篇微博中說到，Yahoo從MObStor遷移到Ceph上是因為Flickr上的照片分享服務，公司說那有250億個對象，將近500PB的照片、視頻、郵件和博客帖子。這些都是為用戶存儲的，并且存儲量仍以每年百分之20-25速度增長。

根據McMillen所述，MObStor具有“完整特性”，它廣泛部署于雅虎。那么如果MObStor真的被廣泛應用和被看好，為什么Yahoo卻熱衷于一個新的技術了?不管怎樣這些都涉及到了錢。

首先，MObStor是一個閉源項目，這意味著雅虎不得不獨立完成創建、擴展和所有支撐工具。與之對應的是Yahoo所創的Hadoop數據分析平臺，這是一個開源項目，在這個平臺有一群資深的工程師，他們在不斷改進平臺上的所有的layer，這體現出了社區的價值。

"我想說，轉向Ceph的最主要是因為我們僅僅想降低存儲費用"，McMillen解釋,"我們的存儲已經增長了許多，我們在盡可能得縮減成本，盡可能得擁有更多的選擇，而不是堅守著一個系統，一種技術或一種硬件架構。

原始的MObStor對象存儲是運行在存儲陣列上，存儲陣列上有動態保護RAID數據，保證了文件安全。隨著DORA的使用，雅虎增加了選項，用來復制存儲集群中陣列之間的數據。RAID和復制帶來了一個很大的開銷，而 McMillen卻不愿意透漏出任何有關MObStor與Ceph在這個方面對比的詳細信息。但他卻說過，對傳統對象存儲系統的檢查發現，這個開銷對三路復制來說為200%，伴隨著糾刪碼技術運用到Ceph及其他的對象存儲，能將開銷降低到40-60%，這些能在雅虎安裝調試Ceph中看到，McMillen說最接近的40%的開銷在糾刪碼保護校驗來確定數據的原始性。這個意味著雅虎在Ceph上存儲容量的開銷是用傳統對象存儲的一半，而且還是三副本。

MObStor/DORA不支持糾刪碼，雅虎不得不將這個移植到該系統上，這可意味著大量的開發和測試的工作量的產生。另一方面Ceph是一個 exascale級部署設計，它有糾刪碼技術以確保數據的內建。(有了糾刪碼，少量無結構數據碎片和分散存儲，或者如果一部分丟失，糾刪碼算法可以重建丟失數據)

#p#

云對象存儲

雅虎正在部署***的基于Ceph的系統，它被稱為云對象存儲，從去年秋天開始，它已經被雅虎stack的Flickr部門試驗。Flickr在管理上有“多PB級別”的Ceph容量，在本年度雅虎計劃增加10個基數來達到“輕量過百PB級別”，據McMillen所說，當推出基于Ceph的云對象存儲，將其隸屬于Flickr、雅虎郵箱、Tumblr(輕量博客)。(McMillen說Flickr會有更多的存儲量，其中的一分部還會在MObstor中保留一段時間)

雅虎也曾經關注過swift和Gluster文件系統，還有那些為尋找新的對象存儲系統的特有選擇，最終他們將注意力放在了Ceph上。首先，McMillen說Ceph有吸引力的地方是將支持對象和塊存儲兩者于一身，如果Ceph社區永遠如此高效處理問題，在未來某一天(很有希望)Ceph同樣支持文件系統存儲。

“并不是所有雅虎的存儲都適合對象存儲，但是很多卻適合”，McMillen說到，“我們正在使用塊存儲，但是他們卻沒有對象存儲走的遠。我們非常喜歡Ceph，除了它因糾刪碼而產生的低成本和它是一個開源項目，在開發者的社區發展非常迅速外，還因為它是一個同時具有塊存儲和對象存儲能力的單一存儲系統。所以代替塊、對象分開的存儲系統，我們可以靈活掌握一種技術棧而獲得兩種使用方法。而且如果Ceph有一個穩定的文件系統，我們今天絕對會使用它。”

Ceph社區(后臺是Red Hat，其已經在一年前以175 百萬獲得Ceph管理Inktank)仍在專注它 。

McMillen說，當Ceph可以從單個集群擴展到exabyte級存儲系統，雅虎將Ceph應用于pod架構，這會比一個單一集群具有更好的性能預測性和錯誤隔離性，效果如下：

在雅虎云對象存儲上，每一個節點(被稱作一個對象存儲設備)，有60TB的存儲，這都是基于X86的服務器。雅虎已經嘗試過每個節點配置12-72個設備，對于COS服務，Yahoo沒有透露其硬件配置。每個集群有54個這樣的節點，總容量可達3.2 pb。為了向外擴展這些服務，雅虎復制pods并使用哈希算法來打破利用糾刪碼橫跨pods和節點的無結構數據。

依賴這些應用，雅虎正在使用常規的硬件驅動和磁盤，他們使用的是shingled magnetic recording (SMR)技術，在容量和花費上都不同;SSDs也被部署到了COS服務來提供更高的I/O率。

雅虎正在Ceph的variant上使用8/3糾刪碼，這說明8份中的3份共享對象的服務或者驅動可以失敗卻仍然可以訪問的到。這是常規級別的糾刪碼在Ceph上應用的。但是雅虎已經計劃了一個針對Ceph的11/3糾刪碼variant，這意味著11個中的3個驅動或者服務可以失敗，更重要的是這個可以減少40%的讀寫延遲。(根據McMillen的說法，雅虎計劃把這項改進回饋給Ceph社區，通過這個方法，它能讓自己參與到“Hummer” 代碼稀釋中)公司已經做出了一系列調整來使Ceph表現出更好的性能，如下圖：

#p#

加入了糾刪碼的更改，雅虎已經想出一個共享bucket索引的方法，那就是一個索引保持跟蹤對象存儲到一個bucket(這是針對對象存儲容量單位的亞馬遜術語)正常Ceph是在一個單一的服務器節點上實現bucket索引，但是雅虎的工程師為了高可用性和性能方面的改進，已經解決了如何切分和跨節點傳播。當有磁盤或服務器失效，數據恢復完成，雅虎想出一個在恢復數據時將延遲的速率限制到60%的方法。

與此同時，雅虎自支持Ceph的實現，但是McMillen說公司與RehHat關系非常好，而且也不反對使用RedHat做一些技術支持。但是雅虎正處于一個大量消耗的時期，而這與超大規模Ceph有關，也許自支持是他們現在唯一的選擇。

“我們將在數百個PB級規模上操作，我不知道其他Ceph社區是否還會這樣做”，McMillen說。“如果我們不是***的，那么我們就會成為***的產品用戶，而且我們很可能會去尋找適合我們規模的版本。你只需要看雅虎這個規模的數據，不用看傳統級別。我們正致力于解決所有這些問題，我相信社區會從中受益。