日前,LinkedIn在Github上基于Apache 2許可證協(xié)議開源了其分布式對象存儲系統(tǒng)Ambry。Ambry是一個是不可變對象的存儲系統(tǒng),非常易于擴展,它能夠存儲KB到GB大小的不可變對象,并且能夠?qū)崿F(xiàn)高吞吐和低延遲,該系統(tǒng)支持跨數(shù)據(jù)中心的雙活部署,并且存儲成本低廉。它特別適于存儲各種媒體內(nèi)容。
據(jù)Linkedin的前工程主管Sriram Subramanian介紹,媒體內(nèi)容在Web中已經(jīng)無處不在,Linkedin中的每項新特性基本上都會與某種類型的媒體內(nèi)容進行交互。這些媒體內(nèi)容會存儲在后端,并且主要會由內(nèi)容分發(fā)網(wǎng)絡(luò)(Content Delivery Networks,CDN)來提供服務(wù),后臺存儲系統(tǒng)會作為CDN的原始服務(wù)器(origin server)。
隨著Linkedin流量的不斷增長,原來所使用的媒體內(nèi)容存儲方案在可擴展性、可用性以及運維方面所遇到的問題越來越多。兩年前,他們著手解決這些問題,而Ambry正是該項工作的結(jié)果。
2013年時的媒體存儲是什么樣的?
LinkedIn之前的系統(tǒng)被稱為媒體服務(wù)器(因為沒有一個像樣的名字),這個系統(tǒng)由兩部分組成,分別是用于媒體文件存儲的Filer以及存儲元數(shù)據(jù)的大型Oracle數(shù)據(jù)庫。這些系統(tǒng)的前端是一些運行在SOLARIS上的無狀態(tài)機器,它們會將請求路由到對應(yīng)的Filer或數(shù)據(jù)庫上。Filer是通過NFS的方式mount到無狀態(tài)機器上的,并使用Java的File API進行遠程訪問。前端會與數(shù)據(jù)中心(DC)里面的一組緩存進行交互,從而保證如果下游系統(tǒng)(Filer/Oracle)出現(xiàn)性能問題或不可用時,前端不會受其影響。
頻繁出現(xiàn)的可用性問題:每次對文件的元數(shù)據(jù)操作出現(xiàn)峰值時,原有的系統(tǒng)都會出現(xiàn)延遲。當訪問大量的小文件時,對元數(shù)據(jù)的操作就會增多。每次文件操作都要經(jīng)過多級的轉(zhuǎn)換(Java、NFS以及Filer),使其很難進行調(diào)試;難以擴展:用來存儲數(shù)據(jù)和元數(shù)據(jù)的底層系統(tǒng)都是單體的。水平擴展元數(shù)據(jù)的存儲是不可能實現(xiàn)的,為數(shù)據(jù)存儲增加硬件也需要很多的手動過程;對小對象和大對象的支持效率低下:媒體數(shù)據(jù)集中包含了數(shù)萬億的小對象(50KB-1MB)也包括數(shù)億的大對象(1MB-1GB)。對于小對象的存儲來說,元數(shù)據(jù)操作的代價是很高昂的,而對于大數(shù)據(jù),原有的系統(tǒng)缺乏端到端的流支持,難以支持新產(chǎn)品的使用場景;平均修復(fù)時間(MTTR,Mean Time To Repair)指標很差:老系統(tǒng)中的大多數(shù)組成部分在很大程度上都是黑盒,這需要獲得支持許可證,并且要通過電話的方式來描述和解決問題,這會影響到MTTR;成本高昂:舊的媒體存儲成本很高,再繼續(xù)擴展的話,成本上已經(jīng)吃不消了。如果想管理媒體的擴展性,就不能延續(xù)該方案了。在這個過程中,Linkedin探索過多種替代方案,最終還是決定自行實現(xiàn)更匹配其需求的解決方案。
Ambry是如何運行呢?
設(shè)計目標
在了解Ambry的設(shè)計和內(nèi)部運行原理之前,明確其設(shè)計目標是很有幫助的,這決定了它的實現(xiàn)方式。
高可用性和水平可擴展:該系統(tǒng)要處理實時流量,會直接影響到站點的可用性,因此它必須具有很高的可用性。另外,還希望新系統(tǒng)能夠盡可能地實現(xiàn)無縫的集群擴展;降低運維的負擔:分布式系統(tǒng)一般都會難以管理,對于頻繁的集群操作,能夠?qū)崿F(xiàn)自動化是非常重要的,這能避免系統(tǒng)成為運維的一種負擔。復(fù)雜的系統(tǒng)通常很難實現(xiàn)自動化并可靠的運行,因此新系統(tǒng)的設(shè)計要簡單、優(yōu)雅并自動化;更低的MTTR:分布式系統(tǒng)出現(xiàn)故障是難以避免的,但是很重要的一點在于快速修復(fù)故障,讓各個子組件啟動并運行。這就需要系統(tǒng)的設(shè)計簡單,并且不會出現(xiàn)單點故障;跨DC雙活:Linkedin有多個數(shù)據(jù)中心,因此所有的系統(tǒng)都要支持雙活配置,這樣的話,系統(tǒng)能夠更新不同數(shù)據(jù)中心中的同一個對象;提升小對象和大對象的效率:請求是由小對象和大對象所組成的,小對象通常是1K到100K,超出這個范圍的對象會位于大對象桶中(bucket)。要同時處理好各種大小的對象,通常來講是很困難的。大量的小對象會給元數(shù)據(jù)帶來很高的負載,造成硬盤碎片,需要很多的隨機IO,而大對象則需要很好的內(nèi)存管理、端到端的流處理和有限的資源使用;廉價:媒體內(nèi)容很快就會占據(jù)很大的存儲空間,它的另外一個特點是舊數(shù)據(jù)會變成“冷”數(shù)據(jù),并不會頻繁訪問。針對這種情況有很多優(yōu)化技術(shù),包括使用密集的硬件(denser hardware)、分層存儲、擦除編碼以及數(shù)據(jù)去重等。在設(shè)計時,Ambry希望媒體內(nèi)容能夠高效存儲在密集型的機器上,并且能夠非常容易地使用其他優(yōu)化成本的方案。概覽
總體上來講,Ambry由三部分組成,分別是用來存儲和檢索數(shù)據(jù)的一組數(shù)據(jù)節(jié)點,路由請求的前端機器(請求會在一些預(yù)處理之后路由到數(shù)據(jù)節(jié)點上)以及協(xié)調(diào)和維護集群的集群管理器。數(shù)據(jù)節(jié)點會在不同節(jié)點之間復(fù)制數(shù)據(jù),同時支持數(shù)據(jù)中心內(nèi)部和數(shù)據(jù)中間之間的復(fù)制。前端提供了支持對象PUT、GET和DELETE操作的HTTP API。另外,前端所使用的路由庫也可以直接用在客戶端中,從而實現(xiàn)更好的性能。在LinkedIn,這些前端節(jié)點會作為CDN的原始服務(wù)器。
API
Ambry提供了REST API,它們適用于大多數(shù)的場景。在有些場景下,需要更好的性能,如果是這樣的話,Ambry也支持在客戶端使用路由庫,直接針對數(shù)據(jù)節(jié)點的流字節(jié)進行讀取和寫入。目前,路由庫是阻塞的(同步),不過Ambry目前正在致力于實現(xiàn)非阻塞(異步)版本,同時也會提供對路由庫的多語言支持。
Clustermap
Clustermap控制拓撲結(jié)構(gòu)、維護狀態(tài)并幫助協(xié)調(diào)集群的操作。Clustermap有兩部分組成:
硬件布局:包含了機器的列表、每臺機器上的磁盤以及每個磁盤的容量。布局還維護資源的狀態(tài)(機器和磁盤)并指定主機名和端口,通過主機名和端口就能連接到數(shù)據(jù)節(jié)點;分區(qū)布局:包含了分區(qū)的列表、它們的位置信息以及狀態(tài)。在Ambry中,分區(qū)有一個數(shù)字表示的ID,副本的列表可以跨數(shù)據(jù)中心。分區(qū)是固定大小的資源,集群間的數(shù)據(jù)重平衡都是在分區(qū)級別進行的。數(shù)據(jù)節(jié)點和前端服務(wù)器都能夠訪問clustermap,并且會始終使用它們當前的視圖來做出決策,這些決策涉及到選擇可用的機器、過濾副本以及識別對象的位置等。
存儲
存儲節(jié)點會用來存放不同分區(qū)的副本。每個存儲節(jié)點會有N塊磁盤,副本會跨磁盤分布存儲。這些副本的結(jié)構(gòu)和管理都是相同的。
在存儲方面,Ambry涵蓋的功能包括如下幾個方面:
持久化:磁盤上的每個副本均被建模為預(yù)先分配的log(preallocated log)。所有新的消息都會按照順序附加到log上,消息是由實際的對象塊(chunk)和相關(guān)的元數(shù)據(jù)(系統(tǒng)和用戶)所組成的。這能夠使寫入操作實現(xiàn)很高的吞吐量,并且避免出現(xiàn)磁盤碎片。Ambry會使用索引將對象id與log中的消息映射起來,索引本身是一組排序的文件片段,條目按照最新使用在前,最舊的條目在后的順序,從而便于高效查找。索引中的每個條目都維護了log中消息的偏移量、消息的屬性以及一些內(nèi)部使用的域。索引中的每個片段會維護一個bloom filter,從而優(yōu)化實際磁盤操作所耗費的時間;零拷貝:通過使用sendfile API,在進行讀取時,字節(jié)從log轉(zhuǎn)移到網(wǎng)絡(luò)的過程中實現(xiàn)了零拷貝。通過避免額外的系統(tǒng)調(diào)用,實現(xiàn)了更好的性能,在這個過程中,會確保字節(jié)不會讀入到用戶內(nèi)存中,不必進行緩存池的管理;恢復(fù):因為系統(tǒng)和機器會出現(xiàn)宕機,磁盤上的數(shù)據(jù)也有可能會損壞,所以有必要實現(xiàn)恢復(fù)(recovery)的功能。在啟動的時候,存儲層會從最后一個已知的檢查點讀取log,并重建索引?;謴?fù)也有助于重建內(nèi)存中的狀態(tài)。Log是恢復(fù)的來源,并且會永久保存;復(fù)制:存儲節(jié)點還需要維護分區(qū)中各副本的同步。每個節(jié)點上都會有一個復(fù)制服務(wù)(replication service),它會負責(zé)保證本地存儲中的副本與所有的遠程副本是同步的。在這里,進行了很多的優(yōu)化,以保證復(fù)制過程的高效可靠。路由/前端
前端服務(wù)器提供了HTTP接口,供客戶端與之通信。除此之外,它們還會負責(zé)為CDN設(shè)置正確的頭信息、進行安全校驗,并將對象以流的形式返回給路由庫和客戶端。
路由所負責(zé)的功能如下所示:
請求管理:請求的端到端生命周期是由路由來進行管理的。路由會處理PUT、GET以及DELETE請求。對于其中的每個請求類型,路由都會跟蹤副本成功和失敗的數(shù)量從而確定Quorum的值、維護分塊的狀態(tài)、生成對象id并在成功或失敗的時候觸發(fā)對應(yīng)的回調(diào);分塊:大對象會分解為塊(chunk),每個塊都能夠跨分區(qū)獨立地進行路由。每個塊都會有一個id來進行唯一標識。路由會生成一個元數(shù)據(jù)對象,其中包含了塊的列表以及它們所需的獲取順序。元數(shù)據(jù)對象存儲為獨立的blob,它的id也會作為blob的id。在讀取的時候,會得到元數(shù)據(jù)對象,然后檢索各個塊并返回給客戶端;故障檢測:故障檢測的邏輯要負責(zé)主動識別宕機或狀態(tài)出問題的資源。資源可以是機器、磁盤或分區(qū)。路由會將出現(xiàn)問題的資源標記為不可用,這樣后續(xù)的請求就不會使用它們了;Quorum:Ambry為寫入和讀取實現(xiàn)了一種多主人(multi-master)的策略。這能夠?qū)崿F(xiàn)更高的可用性并減少端到端的延遲,這是通過減少一個額外的hop來實現(xiàn)的,在基于主從結(jié)構(gòu)(master slave)的系統(tǒng)中,往往會有這個額外的hop。請求通常會發(fā)往M個副本,然后等待至少N個成功的響應(yīng)(這里N<=M)。路由會優(yōu)先使用本地數(shù)據(jù)中心的副本,向其發(fā)送請求,如果本地存儲無法實現(xiàn)所需的Quorum的話,它會代理遠程數(shù)據(jù)中心的訪問;變更捕獲:在每次成功的PUT或DELETE操作之后,路由會生成一個變更捕獲(change capture)。變更捕獲中所包含的信息是blob id以及blob相關(guān)的元數(shù)據(jù),這個信息可以被下游的應(yīng)用所使用。在路由中,典型的PUT和GET操作的流程分別如下所示,系統(tǒng)的實際運行過程會比下述的描述會更復(fù)雜一些:
PUT操作:客戶端會將對象以及一些元數(shù)據(jù)信息以流的形式發(fā)送到前端,當流到達時,前端會將對象進行分塊、選擇可用的分區(qū)、為blob或分塊生成blob id,并將請求分發(fā)給W個副本。然后,前端就開始等待至少Q(mào)個成功的響應(yīng)(Q<=W),等到之后,會將blob id返回給客戶端。如果無法達到足夠的Quorum,那么前端會報告一個錯誤。當然,Ambry也實現(xiàn)了當Quorum失敗的時候,選擇另外一個分區(qū)的功能,從而提升可用性。 GET操作:客戶端通過將id發(fā)送給前端來請求某一個blob。前端會根據(jù)id來確定分區(qū),并在數(shù)據(jù)節(jié)點中檢索blob相關(guān)的塊。對于每個塊,前端會并行發(fā)送R個請求,在將blob或分塊發(fā)送給客戶端之前,前端會等待Q個成功響應(yīng)(Q<=R)。解決運維的難題
分布式系統(tǒng)最困難的在于它的運維,在這個過程中,需要工具、度量并且要進行廣泛地測試,從而保證所有的事情都能符合預(yù)期。在這個過程中,Ambry積累了很多的工具和實踐。
Simoorg:為了模擬各種故障,他們孵化并開源了Simoorg。這是一個分布式的故障引入系統(tǒng),能夠在集群中引入各種故障,如GC暫停、磁盤錯誤、節(jié)點宕機以及網(wǎng)絡(luò)故障,從而校驗在各種情況下,系統(tǒng)的正確性,有助于預(yù)先發(fā)現(xiàn)并修正嚴重的缺陷;生產(chǎn)環(huán)境的正確性測試:當新版本部署到集群中的部分機器進行驗證時,可以進行正確性測試,從而保證生產(chǎn)環(huán)境的健康狀態(tài)。通過加壓訪問所有可用的API(組合使用各種可能出現(xiàn)的輸入?yún)?shù)),確保結(jié)果的正確性;審計:當新的blob寫入到磁盤時,都會產(chǎn)生復(fù)制事件,這個事件包含了blob的信息以及事件的來源。所有存儲節(jié)點的事件都會聚集到Hadoop中,這樣就能審計是否所有的副本都進行了寫入。目前該系統(tǒng)并不是實時的,不過,Ambry規(guī)劃會構(gòu)建一個實時的審計系統(tǒng)。除此之外,Ambry還實現(xiàn)了指標和告警工具,用來幫助識別系統(tǒng)中的異常行為以及維護集群的管理工具。
遷移工作是如何進行的?
團隊需要將所有的媒體內(nèi)容從遺留系統(tǒng)遷移至Ambry,在這個過程中還要服務(wù)于所有的流量,不能出現(xiàn)任何的宕機時間。除此之外,團隊還面臨著多項deadline,了解Ambry是如何組織研發(fā)和部署的,對我們會有一定的指導(dǎo)意義:
當時,公司正在將所有的服務(wù)從Spring RPC方案中剝離出來。從構(gòu)建Ambry開始計算,團隊有四個月的時間支持新的API并移除Spring RPC;一個新的數(shù)據(jù)中心正好需要搭建,Ambry團隊并不想再去部署遺留系統(tǒng)了,因為這會帶來很高的成本。這同時也就意味著為了避免部署遺留系統(tǒng),需要在八個月內(nèi)完成Ambry;最后,團隊希望在數(shù)據(jù)中心里面移除掉Solaris的方案,遺留系統(tǒng)是運行在Solaris上的,它的deadline是一年。Ambry團隊采用了一種特殊的方式來達到這些里程碑節(jié)點。首先,構(gòu)建前端并使用它來代理所有對舊系統(tǒng)的請求,然后再將所有的客戶端遷移到新的前端上。這雖然費了很大的功夫,但是確保了第一個deadline目標的達成。
第二步是讓Ambry能夠以端到端的方式運行,并且只將其部署到新的數(shù)據(jù)中心上,然后將所有的數(shù)據(jù)從舊系統(tǒng)遷移至Ambry。在代碼中,添加了一定的邏輯,確保如果新數(shù)據(jù)中心發(fā)生故障的話,將會使用舊的系統(tǒng)。這可能會產(chǎn)生更多的延遲,但是團隊決定承擔這個風(fēng)險。
在新數(shù)據(jù)中心搭建完成之后,在接下來的幾個月里,團隊不斷運行并穩(wěn)定Ambry?;跍y試和審計結(jié)果,當對新系統(tǒng)完全自信的時候,團隊決定停掉遺留的系統(tǒng)。這樣就在一年的deadline之內(nèi)完成了目標。
在接下來的一年中,Ambry成為了Linkedin中媒體內(nèi)容的唯一來源。它的成功要歸因于周密的規(guī)劃以及漸進式的基礎(chǔ)設(shè)施研發(fā)。
Ambry是如何適應(yīng)Linkedin的生態(tài)系統(tǒng)的?
媒體基礎(chǔ)設(shè)施是針對媒體內(nèi)容的端到端管道,涉及到上傳、存儲、處理、元數(shù)據(jù)管理以及內(nèi)容下載。在基礎(chǔ)設(shè)施中,Ambry是很重要的一個環(huán)節(jié),基礎(chǔ)的穩(wěn)固是非常重要的。在Ambry就緒之后,就可以圍繞著它進行擴展并關(guān)注生態(tài)系統(tǒng)中的其他組成部分。
下一步的研發(fā)計劃
目前,Ambry主要進行中的任務(wù)包括在前端和路由層實現(xiàn)非阻塞、存儲節(jié)點實現(xiàn)機架感知等功能。團隊希望不斷地為Ambry添加新的特性,并且構(gòu)建活躍的開源社區(qū)。完整的未來工作計劃列表可以參見Github上的相關(guān)頁面,如下列出了當前正在進行的或者可能會開展的項目:
非阻塞:阻塞類型的請求通常會占用一個進程,直到請求結(jié)束并且不支持管道。為了達到更高的吞吐量,并且避免大對象所造成的資源枯竭現(xiàn)象,需要將路由和前端變成完全非阻塞的。這樣的話,就能支持更大吞吐量,在操作執(zhí)行時,不再受限于線程資源,從而能夠?qū)崿F(xiàn)更好的可用性。目前,前端實現(xiàn)已經(jīng)完成,正在進行測試。路由庫的代碼預(yù)計也將會很快完成,可以參考其repository來了解最近的更新情況;機架感知:現(xiàn)代的數(shù)據(jù)中心為了降低成本都將機架切換視為很重要的因素。這意味著軟件要足夠智能來應(yīng)對切換故障。Ambry正在構(gòu)建的一項功能就是確保新分區(qū)的副本在跨數(shù)據(jù)中心存放時,能夠遵循機架感知的方式。目前,該項工作正在進行之中;Bucket/Container:Ambry尚不支持命名空間的概念。如果要在群組的級別上強化控制的話,那命名空間是非常有用的。在Ambry中,可能將會引入Bucket或Container的理念。這有助于在bucket級別上定義用戶群組、訪問控制和配額,這種方式會比在對象級別進行維護容易得多;安全:Ambry目前支持數(shù)據(jù)節(jié)點之間的加密,在前端和數(shù)據(jù)節(jié)點之前的通信也可以啟用加密功能。不過,在安全方面,Ambry會有更多的進展,包括REST級別的認證、授權(quán)以及對加密的支持。該項功能預(yù)計會在Bucket/Container實現(xiàn)完成之后開展。對于社區(qū)來講,這個系統(tǒng)會有很大的用處,有助于支持媒體內(nèi)容的實時上傳和媒體服務(wù)的構(gòu)建,詳細的文檔可以參見Github上的相關(guān)頁面。如果讀者有反饋意見或有志于為該項目做出貢獻的話,可以參考其開發(fā)指南。Ambry團隊希望該項目的開發(fā)能夠保持開放的狀態(tài),并幫助社區(qū)使用它來構(gòu)建應(yīng)用程序。另外值得一提的是,2016年度的SIGMOD(Special Interest Group on Management Of Data)已經(jīng)接受了一篇關(guān)于Ambry的論文,該會議將會在六月份舉行,可以瀏覽其網(wǎng)站了解更多信息。