Google File System II: Dawn of the Multiplying Master Nodes

kingzone_2008發表於2012-08-27

谷歌定製的檔案系統迫於前所未有的壓力,因此谷歌醞釀著一個替代產品。

很明顯,作為早些時候宣佈的“caffeine”架構的一部分,GFS的全面修改正處於測試階段。

在ACM的一次訪談中,Google的Sean Quinlan說,GFS誕生近10年來已經做了許多超出其預期的工作。

“考慮到Google的操作的數量級已經遠遠超過其設計能力,它的持久力是極為突出的。儘管谷歌目前支援的應用程式組合不是在90年代末期所能想象的到的。”Quinlan說道。Quinlan是曾任職GFS的技術leader兩年,目前是Google的首席工程師。

然而GFS可以更好的支援一部分應用。GFS設計用於處理諸如web抓取和索引等批量作業,因此並不適用於Gmail和YouTube等需要與使用者實時互動資料的應用。

“高頻寬比低延遲更加重要”,GFS論文中提到。“大多數目標應用是以較高速率處理大量資料,極少有對單個讀寫操作的嚴格的響應時間需求。”但是這種情況在過去10年中發生了變化,退一步說,雖然Google一直致力於其面向公眾的應用程式以使GFS的缺點最小化,但是Quinlan 和公司正重新研發一種新的檔案系統。

GFS中,一個主節點(master node)監督資料在一系列分散式chunkservers之間的傳播。Chunkservers中儲存著資料塊,每塊64MB。

問題是(至少是對於要求低延遲的應用)只有一個主節點。Quinlan指出,“GFS的一個缺點與其原始設計有關,單個點的故障對於批量處理的應用來說未必造成嚴重後果,但是對於對延遲要求較高的應用(如視訊服務)是不可接受的。”

最開始,GFS甚至沒有針對主節點崩潰的故障恢復機制。必須收工恢復主節點,以致服務中斷達一個小時。後來新增了自動故障恢復機制,仍存在明顯的服務中斷。據Quinlan所說,中斷開始時有幾分鐘,目前已降到大約10秒鐘。

這仍然很高。

“儘管這幾個例項(必須提供故障恢復和錯誤恢復)對於批處理情況是可接受的,但是從面向使用者的應用的延遲的角度來看確實不可接受的。”

甚至系統正常執行,仍存在延遲。“在設計時,有些地方為了提高吞吐量,我們把成千上萬的操作加入佇列中並處理它們。這樣有較高的吞吐量,卻犧牲了延遲。經常會遇到等待幾秒鐘才執行作業的情況。”

GFS與MapReduce(Google的分散式資料分析平臺)吻合很好。但是看來Google已經直接跳到BigTable(Google的實時分散式資料庫)了。目前,BigTable處理大多數負載。

“我們的使用者基礎正從基於MapReduce的世界向基於BigTable的互動世界遷移。Gmail就是一個明顯的例子。就GFS而言,視訊應用倒是顯得沒那麼嚴重,因為視訊使用流資料,這意味著可以快取。儘管如此,試圖在一個設計用於批處理環境的檔案系統的基礎上建立一個互動式的資料庫總是不合時宜的。”

另一個問題是,單個主節點只能處理有限數量的檔案。主節點中儲存著chunkservers中檔案的後設資料,其上限是主節點的儲存大小。換句話說,一個主節點可容納的檔案數是有限的。

Google在其新的檔案系統GFS II中解決了這兩個問題。Quinlin和他的團隊正在研發一個不僅擁有分散式從節點(slaves),而且擁有分散式主節點的系統。它的從節點可以儲存更小的檔案。塊從64MB減小到1MB。

這主要考慮了單點故障,但在某種程度上也解決了檔案數量問題。更多的主節點不僅意味著提供了冗餘,同時還可以儲存更多的後設資料。Quinlan提到:“分散式主節點允許你增加檔案數量,這與機器數量一致。

Quinlan提出,檔案縮小至1MB讓我們可以適應未來10年的變化。“我的直覺是平均1MB的檔案大小要比平均64MB檔案大小適用於更多的情況。理論上講,你可能會想到一個擁有更小檔案大小的設計方案,但是1MB在我們的環境中貌似一個不錯的折中選擇。”

為什麼Google一開始不把GFS設計成分散式主節點呢?Quinlan認為這並不是疏忽。

Quinlan說:“單主節點方案是最初決定中的一個,主要是為了簡化整體設計。也就是說,從一開始就研發一種擁有分散式主節點的檔案系統是非常困難的且研發週期將非常長。”

“同時,單主節點方案對工程師們來說可以簡化許多問題。集中控制同步(replication)和垃圾回收,許多其他活動也更加簡單。”

因此,Google短期內研發了GFS。10年過去了,GFS的升級不可避免。

Quinlan說,“毫無疑問,GFS當前面臨許多挑戰。Google的工程師們在過去的兩年中致力於研發一種基於BigTable的分散式主節點系統,以解決GFS所面臨的棘手問題。

除了Google帝國(the Google empire)之外,GFS、MapReduce和BigTable還導致了開源專案Hadoop的誕生。Hadoop以應用於Yahoo!,Facebook和Microsoft Bing等眾多專案中。

Quinlan相信,GFS II將超越GFS。“現在看來,儘管GFS在不停地調整以適應新的需求,但是GFS II將在未來幾年中迅速發展。”


原文地址:Google File System II

相關文章