亞馬遜S3和Dynamo

當亞馬遜開始建立其網絡服務平臺時，該公司比谷歌有更多不同的應用問題。

直到最近，像GFS一樣，Dynamo還沒有直接暴露給客戶。如同亞馬遜首席技術官Werner Vogels在其2007年的博客的解釋，它是存儲服務和其他高度公開給亞馬遜客戶的亞馬遜云計算服務的基礎，包括亞馬遜的簡單存儲服務(S3)和 SimpleDB。但在今年1月18日，亞馬遜推出了一個叫做DynamoDB的數據庫服務，基于最新改進的Dynamo。它給客戶一個如“NoSQL” 數據庫的直接接口。

Dynamo與GFS和HDFS有一些相同的地方：它同樣是設計成為了高可用性而不關注數據在跨系統交換時的一致性，還為了運行在亞馬遜大量集合的硬件上。但是相似性到此為止，因為對Dynamo的要求完全不同。

亞馬遜需要一種可以處理更多用途的數據訪問的文件系統——比如像是亞馬遜自己的電子商務功能，包括顧客購物車，和其他交易型的系統。公司需要更細微和動態的對數據的訪問。比起對大數據流的優化，需求更傾向于對稍小元素的更隨機的訪問，比如類似網頁的訪問。

根據Vogels和他的團隊在2007年10月操作系統原理大會的座談會上發表的報告，“Dynamo面向那種需要儲存相對小的(通常小于1M)目標的應用。”比起為讀取的優化，Dynamo更是被設計成“隨時可寫的”，數據輸入高度可用——正好與谷歌的模型相反。

“對于一些亞馬遜的服務”，亞馬遜Dynamo開發組在報告中寫道，“拒絕客戶更新可能導致很差的用戶體驗。例如，購物車服務必須允許顧客從購物車中添加和移除物品即使是在網絡和服務器發生故障時。”與此同時，基于Dynamo的服務可以應用到更大的數據集——事實上，亞馬遜提供了比Dynamo更好的以S3為基礎的基于Hadoop的Elastic MapReduce服務。

為了達到這些要求，Dynamo的架構幾乎與GFS有天壤之別——它更接近與一個對等系統而不是主從方式。Dynamo同樣逆轉了對一致性的處理，去除了讓系統在數據寫入后解決復制問題，取而代之的是在執行讀取數據時解決沖突問題。因此，Dynamo從不拒絕數據寫入，不管是新數據還是對現有數據的改動，副本立即更新。

由于擔心中央主服務器出錯而造成麻煩(根據以往服務中斷的經驗)和亞馬遜為其云服務添加設備的速度，Vogel的團隊選擇了一種分散的復制方法。它是基于自管理的數據分割方案，使用了一致性哈希的概念。每個Dynamo集群內的資源都被映射成一個連續的環狀地址空間，系統中的每個存儲節點在被添加到集群中時都被賦予一個隨機值——在Dynamo環中表示其“位置”的值。在集群內存儲節點數量的基礎上，每個節點根據其位置負責地址空間中的一個塊。當存儲節點被添加到環中時，它們接管了地址空間中的塊，環中在它們兩側的節點調整它們所負責的部分。由于亞馬遜擔心當更新更好的硬件加入集群后存儲系統的不平衡負載問題，Dynamo允許將多個虛擬節點分配到每個物理節點上，讓集群中的更好的系統更好地分享地址空間。

當數據被寫入到Dynamo時——通過一個“put”請求——系統會給要寫入的數據分配一個鍵值。這個值是通過128位MD5哈希得到的;哈希的值 作為數據在環中的一個地址。負責該地址的數據節點會變成該數據的“協調節點”，負責處理對它的請求并把數據復制提交給環中的其他節點。

這將使請求散布到系統中的所有節點。在其中一個節點發生錯誤時，它在環上的虛擬相鄰節點開始接受請求，用它們的副本填補空白。

接下來是Dynamo的一致性檢查方案。當一個“get”請求由客戶端程序發出時，Dynamo調查它的節點來找到誰有所請求數據的副本。帶有副本 的每個節點響應，提供上次改動的信息，基于一個向量時鐘——一個追蹤數據變化依賴關系的版本控制系統。依照調查的設置，請求處理器可以等待第一個響應并返 回(如果應用程序數據繁忙而且沖突的風險很低——像Hadoop程序一樣)或者可以等待兩個，三個或者更多響應。對于存儲節點的多個響應，處理器進行檢查 從而找出哪一個是最新的并提醒陳舊節點從最新的節點處復制數據，或者合并無沖突的編輯的版本。該方案大多數情況下彈性很強——如果節點死了，而新的已經在 線，那么最新的數據將被復制到新節點上。

Dynamo最新的改進，DynamoDB的創立，就是為什么亞馬遜內部開發者沒有自己采用Dynamo作為他們應用的基礎的結果，取而代之的則是，依靠建立在它之上的服務——S3，SimpleDB和Elastic Block Storage。亞馬遜在2011年四月中斷時所面臨的問題就是安裝在集群間的副本高于應用套件——在亞馬遜Elastic Block Storage，副本超過了可用的額外容量，而不是Dynamo本身的問題。

Dynamo的總體穩定性使它成為開源界模仿者的靈感，就像GFS一樣。Facebook依賴于Cassandra，一個基于Dynamo的Apache項目。Basho的Riak “NoSQL”數據庫同樣來源于Dynamo架構。

微軟的Azure DFS

當微軟推出Azure平臺即服務時，它也面臨著一系列類似亞馬遜那樣的需求——包括大量的多用途存儲。但應為它是平臺即服務，Azure不會像亞馬遜的EC2那樣向其客戶透露過多內部結構。而且作為一個平臺專門建立來服務云客戶比為了某個特定任務來建立更有好處。

因此，在一些方面，Azure的存儲架構類似于亞馬遜的——它的目的是處理各種尺寸的“對象”，表和其他類型的數據，并提供顆粒級的快速訪問。替代 了在存儲節點自身處理邏輯和物理的數據映射，Azure的存儲架構把邏輯和物理數據分區分到了系統的不同層。當傳入的數據請求通過一個邏輯地址被分發時， 或“分區”，分布式文件系統自身分解成GB大小的塊，或“擴展”。其結果是一種亞馬遜和谷歌混合的方法。

如同微軟的Brad Calder在他的Azure存儲架構概覽中描述的那樣，Azure使用了一種類似于Dynamo的識別數據位置的驗證系統。但不是讓應用或服務直接接觸 存儲節點，請求是通過一個保存數據分區映射的前段層分發的，就類似于HDFS的名字節點。與HDFS不同，Azure使用多個前端服務器，通過它們載入均 衡的請求。前端服務器處理所有的從客戶端應用程序的認證請求，并處理與下一層之間的聯系——分區層。

每個Azure存儲空間的邏輯塊都由一個分區服務器管理，它可以追蹤哪個DFS區間存儲著數據。分區服務器為其特定的存儲對象處理讀取和寫入。這些 對象的物理存儲是遍布DFS區間的，因此每個分區服務器都可以訪問DFS中的所有區間。除了緩沖前端服務器的讀寫請求，分區服務器還可以將請求數據緩存在 內存中，因此重復的請求可以在不驚動底層文件系統的情況下得到響應。這將對小的，頻繁的請求提高性能，比如呈現一個網頁。

每個分區的所有元數據都被復制回一套“分區主”服務器上，如果分區服務器出錯會提供信息的備份——如果一臺壞了，它的分區會動態傳遞至其他分區服務器。這些分區主服務區還監視Azure存儲集群上每個分區服務器的工作量，分區主服務器可以動態重新分配分區。

Azure不同于其他大型分布式文件系統，它更嚴格地強調數據寫入的一致性。當寫入送至DFS時，數據復制開始，但不是GFS和HDFS那種懶散的 復制。每個存儲區間都有一個初級的DFS服務器管理并復制到多個二級服務器;一個DFS服務器可以是一個區間子集的初級服務器和其他區間的二級服務器。當 一個分區服務器向DFS送出一個寫請求，它將于初級服務器聯系獲取數據要寫入的區間，初級服務器再傳遞給二級服務器。當數據被三個二級服務器成功復制后， 該次寫入才被報告為成功。

與分區層一樣，Azure DFS在物理層上使用均衡負載，以防系統被大量輸入輸出卡死。每個分區服務器都監視著它訪問的初級區間服務器的工作量，當初級DFS服務器到警告線時，分區服務器開始將讀取請求重新定向至二級服務器，并把寫入重新定向至其他服務器的區間上。

“分布式”的下一階段

分布式文件系統很難保證永久正常運行時間。在大多數情況下，由于保持副本同步所需帶寬的數量，DFS只在同一數據中心內復制。但是，在某些情況下， 數據中心內的復制就不管用了，比如說當整個數據中心被迫下線或是當初主服務器出錯時，備用網絡未能及時切換。在八月，由于變壓器爆炸，微軟和亞馬遜在都柏 林的數據中心都被迫下線——它創造了一個啟用備用發電機的峰值。

像GFS和Hadoop這樣對復制更緩慢的系統可以在兩個數據中心之間異步處理復制;例如，使用“機架感知”，Hadoop集群可設置成指向一個外面的數據節點，元數據可以傳送至遠程檢查點或備份節點(至少在理論上)。但對于更多的動態數據，這種類型的復制將難以管理。

這正是微軟在九月發布一個叫做“地域復制”特性的原因之一。地域復制可以將兩個相隔數百英里的數據中心的客戶數據同步。不是微軟在數據中心內使用的緊密耦合復制，地域復制是異步發生的。兩個Azure數據中心必須在同一地區;例如，在美國中北部的數據中心通過Azure Portal安裝的一個程序的數據可以被復制到美國中南部。

亞馬遜的情況是，公司在服務層級上可以在可用區域間復制而不是下行至Dynamo架構。雖然亞馬遜沒有公布它如何處理自己的地域復制，但是給客戶提供了把EBS存儲“快照”給一個遠程S3數據“桶”的能力。

這就是亞馬遜和谷歌在不斷發展的分布式文件系統都普遍采取的方法：在以它們為基礎的服務上修復調整，而不是在基礎架構上。雖然谷歌給GFS添加了一個分布式主系統，并做出了其他調整以適應其日益增長的數據量，但是谷歌系統的基本架構仍像是2003年時的樣子。

但長期來看，文件系統本身也許更注重于成為數據的保管處而不是由程序直接接觸的東西。在與Ars的一次采訪中，數據庫先驅(VoltDB的創始人) 邁克爾·斯通布雷克表示，隨著“大數據”應用程序數據量的繼續上升，服務器內存將成為“新的磁盤”，文件系統將成為儲存應用程序活動性日志的地方——“新 的磁帶”。當云巨頭們在他們的數據中心上推行更高的效率和性能時，他們已經越來越多地朝著固態硬盤和大量系統內存的方向邁進了。