日前，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)性能問題或不可用時，前端不會受其影響。
在這個過程中，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ū)的功能，從而提升可用性。
解決運維的難題
分布式系統(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)站了解更多信息。
京公網(wǎng)安備 11010502049343號