TheGoogleFileSystem中文版_第1頁
TheGoogleFileSystem中文版_第2頁
TheGoogleFileSystem中文版_第3頁
TheGoogleFileSystem中文版_第4頁
TheGoogleFileSystem中文版_第5頁
已閱讀5頁,還剩21頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡介

1、1 the google file system中文版譯者: alex 摘要我們設(shè)計(jì)并實(shí)現(xiàn)了google 文件系統(tǒng)( gfs ),一個面向大規(guī)模數(shù)據(jù)密集型應(yīng)用的、可伸縮的分布式文件系統(tǒng)。gfs雖然運(yùn)行在廉價的普遍硬件設(shè)備上,但是它依然了提供災(zāi)難冗余的能力,為大量客戶機(jī)提供了高性能的服務(wù)。雖然 gfs的設(shè)計(jì)目標(biāo)與許多傳統(tǒng)的分布式文件系統(tǒng)有很多相同之處,但是,我們的設(shè)計(jì)還是以我們對自己的應(yīng)用的負(fù)載情況和技術(shù)環(huán)境的分析為基礎(chǔ)的,不管現(xiàn)在還是將來,gfs和早期的分布式文件系統(tǒng)的設(shè)想都有明顯的不同。所以我們重新審視了傳統(tǒng)文件系統(tǒng)在設(shè)計(jì)上的折衷選擇,衍生出了完全不同的設(shè)計(jì)思路。gfs完全滿足了我們對存儲的

2、需求。gfs作為存儲平臺已經(jīng)被廣泛的部署在google 內(nèi)部,存儲我們的服務(wù)產(chǎn)生和處理的數(shù)據(jù),同時還用于那些需要大規(guī)模數(shù)據(jù)集的研究和開發(fā)工作。目前為止,最大的一個集群利用數(shù)千臺機(jī)器的數(shù)千個硬盤,提供了數(shù)百tb的存儲空間,同時為數(shù)百個客戶機(jī)服務(wù)。在本論文中,我們展示了能夠支持分布式應(yīng)用的文件系統(tǒng)接口的擴(kuò)展,討論我們設(shè)計(jì)的許多方面,最后列出了小規(guī)模性能測試以及真實(shí)生產(chǎn)系統(tǒng)中性能相關(guān)數(shù)據(jù)。分類和主題描述d 4: 3d 分布文件系統(tǒng)常用術(shù)語設(shè)計(jì),可靠性,性能,測量關(guān)鍵詞容錯,可伸縮性,數(shù)據(jù)存儲,集群存儲1簡介為了滿足 google 迅速增長的數(shù)據(jù)處理需求,我們設(shè)計(jì)并實(shí)現(xiàn)了google 文件系統(tǒng) (go

3、ogle file system gfs) 。gfs與傳統(tǒng)的分布式文件系統(tǒng)有著很多相同的設(shè)計(jì)目標(biāo),比如,性能、可伸縮性、可靠性以及可用性。但是,我們的設(shè)計(jì)還基于我們對我們自己的應(yīng)用的負(fù)載情況和技術(shù)環(huán)境的觀察的影響,不管現(xiàn)在還是將來,gfs和早期文件系統(tǒng)的假設(shè)都有明顯的不同。所以我們重新審視了傳統(tǒng)文件系統(tǒng)在設(shè)計(jì)上的折衷選擇,衍生出了完全不同的設(shè)計(jì)思路。首先,組件失效被認(rèn)為是常態(tài)事件,而不是意外事件。gfs包括幾百甚至幾千臺普通的廉價設(shè)備組裝的存儲機(jī)器,同時被相當(dāng)數(shù)量的客戶機(jī)訪問。gfs組件的數(shù)量和質(zhì)量導(dǎo)致在事實(shí)上,任何給定時間內(nèi)都有可能發(fā)生某些組件無法工作,某些組件無法從它們目前的失效狀態(tài)中恢復(fù)

4、。我們遇到過各種各樣的問題,比如應(yīng)用程序bug、操作系統(tǒng)的bug、人為失誤,甚至還有硬盤、內(nèi)存、連接器、網(wǎng)絡(luò)以及電源失效等造成的問題。所以,持續(xù)的監(jiān)控、錯誤偵測、災(zāi)難冗余以及自動恢復(fù)的機(jī)制必須集成在gfs中。其次,以通常的標(biāo)準(zhǔn)衡量,我們的文件非常巨大。數(shù)gb的文件非常普遍。每個文件通常都包含許多應(yīng)用程序?qū)ο?,比如web 文檔。當(dāng)我們經(jīng)常需要處理快速增長的、并且由數(shù)億個對象構(gòu)成的、數(shù)以tb的數(shù)據(jù)集時,采用管理數(shù)億個kb大小的小文件的方式是非常不明智的,盡管有些文件系統(tǒng)支持這樣的管理方式。因此,設(shè)計(jì)的假設(shè)條件和參數(shù),比如i/o操作和 block 的尺寸都需要重新考慮。第三,絕大部分文件的修改是采用

5、在文件尾部追加數(shù)據(jù),而不是覆蓋原有數(shù)據(jù)的方式。對文件的隨機(jī)寫入操作在實(shí)際中幾乎不存在。一旦寫完之后,對文件的操作就只有讀,而且通常是按順序讀。大量的數(shù)據(jù)符合這些特性,比如:數(shù)據(jù)分析程序掃描的超大的數(shù)據(jù)2 集;正在運(yùn)行的應(yīng)用程序生成的連續(xù)的數(shù)據(jù)流;存檔的數(shù)據(jù);由一臺機(jī)器生成、另外一臺機(jī)器處理的中間數(shù)據(jù),這些中間數(shù)據(jù)的處理可能是同時進(jìn)行的、也可能是后續(xù)才處理的。對于這種針對海量文件的訪問模式,客戶端對數(shù)據(jù)塊緩存是沒有意義的,數(shù)據(jù)的追加操作是性能優(yōu)化和原子性保證的主要考量因素。第四,應(yīng)用程序和文件系統(tǒng)api 的協(xié)同設(shè)計(jì)提高了整個系統(tǒng)的靈活性。比如,我們放松了對 gfs一致性模型的要求,這樣就減輕了文

6、件系統(tǒng)對應(yīng)用程序的苛刻要求,大大簡化了gfs的設(shè)計(jì)。我們引入了原子性的記錄追加操作,從而保證多個客戶端能夠同時進(jìn)行追加操作,不需要額外的同步操作來保證數(shù)據(jù)的一致性。本文后面還有對這些問題的細(xì)節(jié)的詳細(xì)討論。 google 已經(jīng)針對不同的應(yīng)用部署了多套gfs集群。最大的一個集群擁有超過1000 個存儲節(jié)點(diǎn),超過300tb 的硬盤空間,被不同機(jī)器上的數(shù)百個客戶端連續(xù)不斷的頻繁訪問。2設(shè)計(jì)概述2.1設(shè)計(jì)預(yù)期在設(shè)計(jì)滿足我們需求的文件系統(tǒng)時候,我們的設(shè)計(jì)目標(biāo)既有機(jī)會、又有挑戰(zhàn)。之前我們已經(jīng)提到了一些需要關(guān)注的關(guān)鍵點(diǎn),這里我們將設(shè)計(jì)的預(yù)期目標(biāo)的細(xì)節(jié)展開討論。系統(tǒng)由許多廉價的普通組件組成,組件失效是一種常態(tài)。

7、系統(tǒng)必須持續(xù)監(jiān)控自身的狀態(tài),它必須將組件失效作為一種常態(tài),能夠迅速地偵測、冗余并恢復(fù)失效的組件。系統(tǒng)存儲一定數(shù)量的大文件。我們預(yù)期會有幾百萬文件,文件的大小通常在100mb 或者以上。數(shù)個gb 大小的文件也是普遍存在,并且要能夠被有效的管理。系統(tǒng)也必須支持小文件,但是不需要針對小文件做專門的優(yōu)化。系統(tǒng)的工作負(fù)載主要由兩種讀操作組成:大規(guī)模的流式讀取和小規(guī)模的隨機(jī)讀取。大規(guī)模的流式讀取通常一次讀取數(shù)百kb的數(shù)據(jù),更常見的是一次讀取1mb 甚至更多的數(shù)據(jù)。來自同一個客戶機(jī)的連續(xù)操作通常是讀取同一個文件中連續(xù)的一個區(qū)域。小規(guī)模的隨機(jī)讀取通常是在文件某個隨機(jī)的位置讀取幾個kb數(shù)據(jù)。如果應(yīng)用程序?qū)π阅芊?/p>

8、常關(guān)注,通常的做法是把小規(guī)模的隨機(jī)讀取操作合并并排序,之后按順序批量讀取,這樣就避免了在文件中前后來回的移動讀取位置。系統(tǒng)的工作負(fù)載還包括許多大規(guī)模的、順序的、數(shù)據(jù)追加方式的寫操作。一般情況下,每次寫入的數(shù)據(jù)的大小和大規(guī)模讀類似。數(shù)據(jù)一旦被寫入后,文件就很少會被修改了。系統(tǒng)支持小規(guī)模的隨機(jī)位置寫入操作,但是可能效率不彰。系統(tǒng)必須高效的、行為定義明確的(alex 注: well-defined )實(shí)現(xiàn)多客戶端并行追加數(shù)據(jù)到同一個文件里的語意。我們的文件通常被用于” 生產(chǎn)者 -消費(fèi)者 “ 隊(duì)列,或者其它多路文件合并操作。通常會有數(shù)百個生產(chǎn)者,每個生產(chǎn)者進(jìn)程運(yùn)行在一臺機(jī)器上,同時對一個文件進(jìn)行追加操

9、作。使用最小的同步開銷來實(shí)現(xiàn)的原子的多路追加數(shù)據(jù)操作是必不可少的。文件可以在稍后讀取,或者是消費(fèi)者在追加的操作的同時讀取文件。高性能的穩(wěn)定網(wǎng)絡(luò)帶寬遠(yuǎn)比低延遲重要。我們的目標(biāo)程序絕大部分要求能夠高速率的、大批量的處理數(shù)據(jù),極少有程序?qū)我坏淖x寫操作有嚴(yán)格的響應(yīng)時間要求。2.2接口3 gfs提供了一套類似傳統(tǒng)文件系統(tǒng)的api接口函數(shù),雖然并不是嚴(yán)格按照posix等標(biāo)準(zhǔn)api的形式實(shí)現(xiàn)的。文件以分層目錄的形式組織,用路徑名來標(biāo)識。我們支持常用的操作,如創(chuàng)建新文件、刪除文件、打開文件、關(guān)閉文件、讀和寫文件。另外, gfs提供了快照和記錄追加操作??煺找院艿偷某杀緞?chuàng)建一個文件或者目錄樹的拷貝。記錄追加操

10、作允許多個客戶端同時對一個文件進(jìn)行數(shù)據(jù)追加操作,同時保證每個客戶端的追加操作都是原子性的。這對于實(shí)現(xiàn)多路結(jié)果合并,以及” 生產(chǎn)者 -消費(fèi)者 ” 隊(duì)列非常有用,多個客戶端可以在不需要額外的同步鎖定的情況下,同時對一個文件追加數(shù)據(jù)。我們發(fā)現(xiàn)這些類型的文件對于構(gòu)建大型分布應(yīng)用是非常重要的??煺蘸陀涗涀芳硬僮鲗⒃?.4和 3.3 節(jié)分別討論。2.3架構(gòu)一個 gfs集群包含一個單獨(dú)的master 節(jié)點(diǎn)(alex 注:這里的一個單獨(dú)的master 節(jié)點(diǎn)的含義是 gfs系統(tǒng)中只存在一個邏輯上的master 組件。后面我們還會提到master 節(jié)點(diǎn)復(fù)制,因此,為了理解方便,我們把master 節(jié)點(diǎn)視為一個邏輯

11、上的概念,一個邏輯的master 節(jié)點(diǎn)包括兩臺物理主機(jī),即兩臺master 服務(wù)器)、 多臺 chunk 服務(wù)器,并且同時被多個客戶端訪問,如圖1所示。所有的這些機(jī)器通常都是普通的linux機(jī)器,運(yùn)行著用戶級別(user-level)的服務(wù)進(jìn)程。我們可以很容易的把chunk 服務(wù)器和客戶端都放在同一臺機(jī)器上,前提是機(jī)器資源允許,并且我們能夠接受不可靠的應(yīng)用程序代碼帶來的穩(wěn)定性降低的風(fēng)險(xiǎn)。gfs存儲的文件都被分割成固定大小的chunk。在 chunk 創(chuàng)建的時候, master 服務(wù)器會給每個 chunk 分配一個不變的、全球唯一的64 位的 chunk 標(biāo)識。 chunk 服務(wù)器把chunk

12、以linux 文件的形式保存在本地硬盤上,并且根據(jù)指定的chunk 標(biāo)識和字節(jié)范圍來讀寫塊數(shù)據(jù)。出于可靠性的考慮,每個塊都會復(fù)制到多個塊服務(wù)器上。缺省情況下,我們使用 3 個存儲復(fù)制節(jié)點(diǎn),不過用戶可以為不同的文件命名空間設(shè)定不同的復(fù)制級別。master 節(jié)點(diǎn)管理所有的文件系統(tǒng)元數(shù)據(jù)。這些元數(shù)據(jù)包括名字空間、訪問控制信息、文件和 chunk 的映射信息、以及當(dāng)前chunk 的位置信息。 master 節(jié)點(diǎn)還管理著系統(tǒng)范圍內(nèi)的活動,比如,chunk 租用管理 (alex 注: bdb 也有關(guān)于lease 的描述,不知道是否相同)、孤兒 chunk(alex 注: orphaned chunks )

13、的回收、以及chunk 在 chunk 服務(wù)器之間的遷移。master 節(jié)點(diǎn)使用心跳信息周期地和每個chunk 服務(wù)器通訊,發(fā)送指令到各個chunk 服務(wù)器并接收 chunk 服務(wù)器的狀態(tài)信息。 gfs客戶端代碼以庫的形式被鏈接到客戶程序里??蛻舳舜a實(shí)現(xiàn)了gfs文件系統(tǒng)的api接口函數(shù)、應(yīng)用程序與master 節(jié)點(diǎn)和 chunk 服務(wù)器通訊、以及對數(shù)據(jù)進(jìn)行讀寫操作??蛻舳撕蚼aster 節(jié)點(diǎn)的通信只獲取元數(shù)據(jù),所有的數(shù)據(jù)操作都是由客戶端直接和chunk 服4 務(wù)器進(jìn)行交互的。我們不提供posix標(biāo)準(zhǔn)的 api的功能,因此,gfs api調(diào)用不需要深入到linux vnode 級別。無論是客戶

14、端還是chunk服務(wù)器都不需要緩存文件數(shù)據(jù)。客戶端緩存數(shù)據(jù)幾乎沒有什么用處,因?yàn)榇蟛糠殖绦蛞匆粤鞯姆绞阶x取一個巨大文件,要么工作集太大根本無法被緩存。無需考慮緩存相關(guān)的問題也簡化了客戶端和整個系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)。(不過,客戶端會緩存元數(shù)據(jù)。)chunk 服務(wù)器不需要緩存文件數(shù)據(jù)的原因是,chunk 以本地文件的方式保存, linux 操作系統(tǒng)的文件系統(tǒng)緩存會把經(jīng)常訪問的數(shù)據(jù)緩存在內(nèi)存中。2.4單一 master節(jié)點(diǎn)單一的 master 節(jié)點(diǎn)的策略大大簡化了我們的設(shè)計(jì)。單一的master 節(jié)點(diǎn)可以通過全局的信息精確定位chunk 的位置以及進(jìn)行復(fù)制決策。另外,我們必須減少對master 節(jié)點(diǎn)的讀

15、寫,避免 master 節(jié)點(diǎn)成為系統(tǒng)的瓶頸。客戶端并不通過master 節(jié)點(diǎn)讀寫文件數(shù)據(jù)。反之,客戶端向master 節(jié)點(diǎn)詢問它應(yīng)該聯(lián)系的chunk 服務(wù)器??蛻舳藢⑦@些元數(shù)據(jù)信息緩存一段時間,后續(xù)的操作將直接和chunk 服務(wù)器進(jìn)行數(shù)據(jù)讀寫操作。我們利用圖1 解釋一下一次簡單讀取的流程。首先,客戶端把文件名和程序指定的字節(jié)偏移,根據(jù)固定的chunk 大小,轉(zhuǎn)換成文件的chunk 索引。然后,它把文件名和chunk 索引發(fā)送給 master 節(jié)點(diǎn)。 master 節(jié)點(diǎn)將相應(yīng)的chunk 標(biāo)識和副本的位置信息發(fā)還給客戶端??蛻舳擞梦募蚦hunk 索引作為key 緩存這些信息。之后客戶端發(fā)送請

16、求到其中的一個副本處,一般會選擇最近的。請求信息包含了chunk的標(biāo)識和字節(jié)范圍。在對這個chunk 的后續(xù)讀取操作中,客戶端不必再和master 節(jié)點(diǎn)通訊了,除非緩存的元數(shù)據(jù)信息過期或者文件被重新打開。實(shí)際上,客戶端通常會在一次請求中查詢多個chunk 信息, master 節(jié)點(diǎn)的回應(yīng)也可能包含了緊跟著這些被請求的chunk 后面的 chunk 的信息。在實(shí)際應(yīng)用中,這些額外的信息在沒有任何代價的情況下,避免了客戶端和 master 節(jié)點(diǎn)未來可能會發(fā)生的幾次通訊。2.5chunk 尺寸chunk 的大小是關(guān)鍵的設(shè)計(jì)參數(shù)之一。我們選擇了64mb,這個尺寸遠(yuǎn)遠(yuǎn)大于一般文件系統(tǒng)的 block si

17、ze。每個 chunk的副本都以普通linux文件的形式保存在chunk服務(wù)器上,只有在需要的時候才擴(kuò)大。惰性空間分配策略避免了因內(nèi)部碎片造成的空間浪費(fèi),內(nèi)部碎片或許是對選擇這么大的chunk 尺寸最具爭議一點(diǎn)。選擇較大的chunk 尺寸有幾個重要的優(yōu)點(diǎn)。首先,它減少了客戶端和master 節(jié)點(diǎn)通訊的需求,因?yàn)橹恍枰淮魏蚼ater 節(jié)點(diǎn)的通信就可以獲取chunk 的位置信息,之后就可以對同一個chunk 進(jìn)行多次的讀寫操作。這種方式對降低我們的工作負(fù)載來說效果顯著,因?yàn)槲覀兊膽?yīng)用程序通常是連續(xù)讀寫大文件。即使是小規(guī)模的隨機(jī)讀取,采用較大的chunk尺寸也帶來明顯的好處,客戶端可以輕松的緩存一

18、個數(shù)tb的工作數(shù)據(jù)集所有的chunk 位置信息。其次,采用較大的chunk 尺寸,客戶端能夠?qū)σ粋€塊進(jìn)行多次操作,這樣就可以通過與 chunk 服務(wù)器保持較長時間的tcp連接來減少網(wǎng)絡(luò)負(fù)載。第三,選用較大的chunk 尺寸減少了master 節(jié)點(diǎn)需要保存的元數(shù)據(jù)的數(shù)量。這就允許我們把元數(shù)據(jù)全部放在內(nèi)存中,在 2.6.1 節(jié)我們會討論元數(shù)據(jù)全部放在內(nèi)存中帶來的額外的好處。另一方面,即使配合惰性空間分配,采用較大的chunk尺寸也有其缺陷。小文件包含較少的 chunk,甚至只有一個chunk。當(dāng)有許多的客戶端對同一個小文件進(jìn)行多次的訪問時,存儲這些chunk 的 chunk 服務(wù)器就會變成熱點(diǎn)。在

19、實(shí)際應(yīng)用中,由于我們的程序通常是連續(xù)的讀取包含多個chunk 的大文件,熱點(diǎn)還不是主要的問題。5 然而, 當(dāng)我們第一次把gfs用于批處理隊(duì)列系統(tǒng)的時候,熱點(diǎn)的問題還是產(chǎn)生了:一個可執(zhí)行文件在gfs上保存為 single-chunk 文件,之后這個可執(zhí)行文件在數(shù)百臺機(jī)器上同時啟動。存放這個可執(zhí)行文件的幾個chunk 服務(wù)器被數(shù)百個客戶端的并發(fā)請求訪問導(dǎo)致系統(tǒng)局部過載。我們通過使用更大的復(fù)制參數(shù)來保存可執(zhí)行文件,以及錯開批處理隊(duì)列系統(tǒng)程序的啟動時間的方法解決了這個問題。一個可能的長效解決方案是,在這種的情況下,允許客戶端從其它客戶端讀取數(shù)據(jù)。2.6元數(shù)據(jù)master 服務(wù)器 (alex 注:注意邏

20、輯的master 節(jié)點(diǎn)和物理的master 服務(wù)器的區(qū)別。后續(xù)我們談的是每個master 服務(wù)器的行為,如存儲、內(nèi)存等等,因此我們將全部使用物理名稱) 存儲 3 種主要類型的元數(shù)據(jù),包括:文件和chunk 的命名空間、文件和chunk 的對應(yīng)關(guān)系、每個chunk 副本的存放地點(diǎn)。所有的元數(shù)據(jù)都保存在master 服務(wù)器的內(nèi)存中。前兩種類型的元數(shù)據(jù)(命名空間、文件和chunk 的對應(yīng)關(guān)系)同時也會以記錄變更日志的方式記錄在操作系統(tǒng)的系統(tǒng)日志文件中,日志文件存儲在本地磁盤上,同時日志會被復(fù)制到其它的遠(yuǎn)程 master 服務(wù)器上。采用保存變更日志的方式,我們能夠簡單可靠的更新master 服務(wù)器的狀

21、態(tài),并且不用擔(dān)心master 服務(wù)器崩潰導(dǎo)致數(shù)據(jù)不一致的風(fēng)險(xiǎn)。master 服務(wù)器不會持久保存chunk 位置信息。 master 服務(wù)器在啟動時,或者有新的chunk 服務(wù)器加入時,向各個 chunk 服務(wù)器輪詢它們所存儲的chunk 的信息。2.6.1內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)因?yàn)樵獢?shù)據(jù)保存在內(nèi)存中,所以master 服務(wù)器的操作速度非??臁2⑶?,master 服務(wù)器可以在后臺簡單而高效的周期性掃描自己保存的全部狀態(tài)信息。這種周期性的狀態(tài)掃描也用于實(shí)現(xiàn)chunk 垃圾收集、在chunk 服務(wù)器失效的時重新復(fù)制數(shù)據(jù)、通過chunk 的遷移實(shí)現(xiàn)跨 chunk 服務(wù)器的負(fù)載均衡以及磁盤使用狀況統(tǒng)計(jì)等功能。

22、4.3 和 4.4 章節(jié)將深入討論這些行為。將元數(shù)據(jù)全部保存在內(nèi)存中的方法有潛在問題:chunk 的數(shù)量以及整個系統(tǒng)的承載能力都受限于master 服務(wù)器所擁有的內(nèi)存大小。但是在實(shí)際應(yīng)用中,這并不是一個嚴(yán)重的問題。 master 服務(wù)器只需要不到64 個字節(jié)的元數(shù)據(jù)就能夠管理一個64mb 的 chunk。由于大多數(shù)文件都包含多個chunk,因此絕大多數(shù)chunk 都是滿的,除了文件的最后一個chunk是部分填充的。同樣的,每個文件的在命名空間中的數(shù)據(jù)大小通常在64 字節(jié)以下,因?yàn)楸4娴奈募怯们熬Y壓縮算法壓縮過的。即便是需要支持更大的文件系統(tǒng),為master 服務(wù)器增加額外內(nèi)存的費(fèi)用是很少的

23、,而通過增加有限的費(fèi)用,我們就能夠把元數(shù)據(jù)全部保存在內(nèi)存里,增強(qiáng)了系統(tǒng)的簡潔性、可靠性、高性能和靈活性。2.6.2chunk 位置信息master 服務(wù)器并不保存持久化保存哪個chunk 服務(wù)器存有指定chunk 的副本的信息。master 服務(wù)器只是在啟動的時候輪詢chunk 服務(wù)器以獲取這些信息。master 服務(wù)器能夠保證它持有的信息始終是最新的,因?yàn)樗刂屏怂械腸hunk 位置的分配,而且通過周期性的心跳信息監(jiān)控chunk 服務(wù)器的狀態(tài)。最初設(shè)計(jì)時,我們試圖把chunk 的位置信息持久的保存在master 服務(wù)器上,但是后來我們發(fā)現(xiàn)在啟動的時候輪詢chunk 服務(wù)器,之后定期輪詢更新

24、的方式更簡單。這種設(shè)計(jì)簡化了在有chunk 服務(wù)器加入集群、離開集群、更名、失效、以及重啟的時候,master 服務(wù)6 器和 chunk 服務(wù)器數(shù)據(jù)同步的問題。在一個擁有數(shù)百臺服務(wù)器的集群中,這類事件會頻繁的發(fā)生??梢詮牧硗庖粋€角度去理解這個設(shè)計(jì)決策:只有chunk 服務(wù)器才能最終確定一個chunk是否在它的硬盤上。我們從沒有考慮過在master 服務(wù)器上維護(hù)一個這些信息的全局視圖,因?yàn)?chunk 服務(wù)器的錯誤可能會導(dǎo)致chunk 自動消失 (比如,硬盤損壞了或者無法訪問了),亦或者操作人員可能會重命名一個chunk 服務(wù)器。2.6.3操作日志操作日志包含了關(guān)鍵的元數(shù)據(jù)變更歷史記錄。這對 g

25、fs非常重要。這不僅僅是因?yàn)椴僮魅罩臼窃獢?shù)據(jù)唯一的持久化存儲記錄,它也作為判斷同步操作順序的邏輯時間基線(alex注:也就是通過邏輯日志的序號作為操作發(fā)生的邏輯時間,類似于事務(wù)系統(tǒng)中的lsn )。文件和 chunk,連同它們的版本(參考 4.5 節(jié)),都由它們創(chuàng)建的邏輯時間唯一的、永久的標(biāo)識。操作日志非常重要,我們必須確保日志文件的完整,確保只有在元數(shù)據(jù)的變化被持久化后,日志才對客戶端是可見的。否則,即使chunk 本身沒有出現(xiàn)任何問題,我們?nèi)杂锌赡軄G失整個文件系統(tǒng),或者丟失客戶端最近的操作。所以,我們會把日志復(fù)制到多臺遠(yuǎn)程機(jī)器,并且只有把相應(yīng)的日志記錄寫入到本地以及遠(yuǎn)程機(jī)器的硬盤后,才會響應(yīng)

26、客戶端的操作請求。 master 服務(wù)器會收集多個日志記錄后批量處理,以減少寫入磁盤和復(fù)制對系統(tǒng)整體性能的影響。master 服務(wù)器在災(zāi)難恢復(fù)時,通過重演操作日志把文件系統(tǒng)恢復(fù)到最近的狀態(tài)。為了縮短 master 啟動的時間,我們必須使日志足夠小(alex 注:即重演系統(tǒng)操作的日志量盡量的少)。 master 服務(wù)器在日志增長到一定量時對系統(tǒng)狀態(tài)做一次checkpoint(alex 注:checkpoint 是一種行為,一種對數(shù)據(jù)庫狀態(tài)作一次快照的行為), 將所有的狀態(tài)數(shù)據(jù)寫入一個 checkpoint 文件 (alex 注:并刪除之前的日志文件)。在災(zāi)難恢復(fù)的時候,master 服務(wù)器就通過

27、從磁盤上讀取這個checkpoint 文件,以及重演checkpoint 之后的有限個日志文件就能夠恢復(fù)系統(tǒng)。checkpoint 文件以 壓縮 b-樹形勢的數(shù)據(jù)結(jié)構(gòu)存儲,可以直接映射到內(nèi)存,在用于命名空間查詢時無需額外的解析。這大大提高了恢復(fù)速度,增強(qiáng)了可用性。由于創(chuàng)建一個checkpoint 文件需要一定的時間,所以master 服務(wù)器的內(nèi)部狀態(tài)被組織為一種格式,這種格式要確保在checkpoint 過程中不會阻塞正在進(jìn)行的修改操作。master服務(wù)器使用獨(dú)立的線程切換到新的日志文件和創(chuàng)建新的checkpoint 文件。新的checkpoint文件包括切換前所有的修改。對于一個包含數(shù)百萬個

28、文件的集群,創(chuàng)建一個checkpoint 文件需要 1 分鐘左右的時間。創(chuàng)建完成后,checkpoint 文件會被寫入在本地和遠(yuǎn)程的硬盤里。master 服務(wù)器恢復(fù)只需要最新的checkpoint 文件和后續(xù)的日志文件。舊的checkpoint文件和日志文件可以被刪除,但是為了應(yīng)對災(zāi)難性的故障(alex 注: catastrophes ,數(shù)據(jù)備份相關(guān)文檔中經(jīng)常會遇到這個詞,表示一種超出預(yù)期范圍的災(zāi)難性事件),我們通常會多保存一些歷史文件。checkpoint 失敗不會對正確性產(chǎn)生任何影響,因?yàn)榛謴?fù)功能的代碼可以檢測并跳過沒有完成的checkpoint 文件。2.7一致性模型gfs支持一個寬松的

29、一致性模型,這個模型能夠很好的支撐我們的高度分布的應(yīng)用,同時還保持了相對簡單且容易實(shí)現(xiàn)的優(yōu)點(diǎn)。本節(jié)我們討論gfs的一致性的保障機(jī)制,以及對應(yīng)用程序的意義。我們也著重描述了gfs如何管理這些一致性保障機(jī)制,但是實(shí)現(xiàn)的細(xì)節(jié)將在本論文的其它部分討論。7 2.7.1gfs一致性保障機(jī)制文件命名空間的修改(例如,文件創(chuàng)建)是原子性的。它們僅由master 節(jié)點(diǎn)的控制:命名空間鎖提供了原子性和正確性(4.1 章)的保障; master 節(jié)點(diǎn)的操作日志定義了這些操作在全局的順序(2.6.3 章)。數(shù)據(jù)修改后文件region(alex 注: region 這個詞用中文非常難以表達(dá),我認(rèn)為應(yīng)該是修改操作所涉及的

30、文件中的某個范圍)的狀態(tài)取決于操作的類型、成功與否、 以及是否同步修改。 表 1 總結(jié)了各種操作的結(jié)果。如果所有客戶端,無論從哪個副本讀取,讀到的數(shù)據(jù)都一樣,那么我們認(rèn)為文件region 是“ 一致的 ” ;如果對文件的數(shù)據(jù)修改之后,region 是一致的,并且客戶端能夠看到寫入操作全部的內(nèi)容,那么這個region 是“ 已定義的 ” 。當(dāng)一個數(shù)據(jù)修改操作成功執(zhí)行,并且沒有受到同時執(zhí)行的其它寫入操作的干擾,那么影響的region 就是已定義的 (隱含了一致性):所有的客戶端都可以看到寫入的內(nèi)容。并行修改操作成功完成之后, region 處于一致的、未定義的狀態(tài):所有的客戶端看到同樣的數(shù)據(jù),但是

31、無法讀到任何一次寫入操作寫入的數(shù)據(jù)。通常情況下,文件region 內(nèi)包含了來自多個修改操作的、混雜的數(shù)據(jù)片段。失敗的修改操作導(dǎo)致一個region 處于不一致狀態(tài) (同時也是未定義的):不同的客戶在不同的時間會看到不同的數(shù)據(jù)。后面我們將描述應(yīng)用如何區(qū)分已定義和未定義的 region。應(yīng)用程序沒有必要再去細(xì)分未定義region 的不同類型。數(shù)據(jù)修改操作分為寫入或者記錄追加兩種。寫入操作把數(shù)據(jù)寫在應(yīng)用程序指定的文件偏移位置上。即使有多個修改操作并行執(zhí)行時,記錄追加操作至少可以把數(shù)據(jù)原子性的追加到文件中一次,但是偏移位置是由gfs選擇的( 3.3 章) (alex 注:這句話有點(diǎn)費(fèi)解,其含義是所有的追

32、加寫入都會成功,但是有可能被執(zhí)行了多次,而且每次追加的文件偏移量由 gfs自己計(jì)算) 。(相比而言,通常說的追加操作寫的偏移位置是文件的尾部。)gfs返回給客戶端一個偏移量,表示了包含了寫入記錄的、已定義的region 的起點(diǎn)。另外,gfs可能會在文件中間插入填充數(shù)據(jù)或者重復(fù)記錄。這些數(shù)據(jù)占據(jù)的文件region 被認(rèn)定是不一致的,這些數(shù)據(jù)通常比用戶數(shù)據(jù)小的多。經(jīng)過了一系列的成功的修改操作之后,gfs確保被修改的文件region 是已定義的, 并且包含最后一次修改操作寫入的數(shù)據(jù)。gfs通過以下措施確保上述行為:(a) 對 chunk 的所有副本的修改操作順序一致(3.1 章),( b)使用 ch

33、unk 的版本號來檢測副本是否因?yàn)樗诘?chunk 服務(wù)器宕機(jī)( 4.5 章)而錯過了修改操作而導(dǎo)致其失效。失效的副本不會再進(jìn)行任何修改操作,master 服務(wù)器也不再返回這個chunk 副本的位置信息給客戶端。它們會被垃圾收集系統(tǒng)盡快回收。由于 chunk位置信息會被客戶端緩存,所以在信息刷新前,客戶端有可能從一個失效的副本讀取了數(shù)據(jù)。在緩存的超時時間和文件下一次被打開的時間之間存在一個時間窗,文件再次被打開后會清除緩存中與該文件有關(guān)的所有chunk 位置信息。而且,由于我們的文件大多數(shù)都是只進(jìn)行追加操作的,所以,一個失效的副本通常返回一個提前結(jié)束的chunk而不是過期的數(shù)據(jù)。當(dāng)一個re

34、ader(alex 注:本文中將用到兩個專有名詞,reader 和writer ,分別表示執(zhí)行g(shù)fs讀取和寫入操作的程序)重新嘗試并聯(lián)絡(luò)master 服務(wù)器時,它就會立刻得到最新的chunk 位置信息。8 即使在修改操作成功執(zhí)行很長時間之后,組件的失效也可能損壞或者刪除數(shù)據(jù)。gfs通過 master 服務(wù)器和所有chunk 服務(wù)器的定期 “ 握手 ” 來找到失效的chunk 服務(wù)器,并且使用checksum 來校驗(yàn)數(shù)據(jù)是否損壞(5.2 章)。一旦發(fā)現(xiàn)問題,數(shù)據(jù)要盡快利用有效的副本進(jìn)行恢復(fù)( 4.3 章)。只有當(dāng)一個chunk 的所有副本在gfs檢測到錯誤并采取應(yīng)對措施之前全部丟失,這個chun

35、k 才會不可逆轉(zhuǎn)的丟失。在一般情況下gfs的反應(yīng)時間( alex 注:指 master節(jié)點(diǎn)檢測到錯誤并采取應(yīng)對措施)是幾分鐘。即使在這種情況下,chunk 也只是不可用了,而不是損壞了:應(yīng)用程序會收到明確的錯誤信息而不是損壞的數(shù)據(jù)。2.7.2程序的實(shí)現(xiàn)使用 gfs的應(yīng)用程序可以利用一些簡單技術(shù)實(shí)現(xiàn)這個寬松的一致性模型,這些技術(shù)也用來實(shí)現(xiàn)一些其它的目標(biāo)功能,包括:盡量采用追加寫入而不是覆蓋,checkpoint,自驗(yàn)證的寫入操作,自標(biāo)識的記錄。在實(shí)際應(yīng)用中,我們所有的應(yīng)用程序?qū)ξ募膶懭氩僮鞫际潜M量采用數(shù)據(jù)追加方式,而不是覆蓋方式。 一種典型的應(yīng)用,應(yīng)用程序從頭到尾寫入數(shù)據(jù),生成了一個文件。寫入

36、所有數(shù) 據(jù) 之 后 , 應(yīng) 用 程 序 自 動 將 文 件 改 名 為 一 個 永 久 保 存 的 文 件 名 , 或 者 周 期 性 的 作checkpoint ,記錄成功寫入了多少數(shù)據(jù)。checkpoint 文件可以包含程序級別的校驗(yàn)和。readers僅校驗(yàn)并處理上個checkpoint 之后產(chǎn)生的文件region,這些文件region 的狀態(tài)一定是已定義的。這個方法滿足了我們一致性和并發(fā)處理的要求。追加寫入比隨機(jī)位置寫入更加有效率,對應(yīng)用程序的失敗處理更具有彈性。checkpoint 可以讓writer以漸進(jìn)的方式重新開始,并且可以防止reader 處理已經(jīng)被成功寫入,但是從應(yīng)用程序的角

37、度來看還并未完成的數(shù)據(jù)。我們再來分析另一種典型的應(yīng)用。許多應(yīng)用程序并行的追加數(shù)據(jù)到同一個文件,比如進(jìn)行結(jié)果的合并或者是一個生產(chǎn)者-消費(fèi)者隊(duì)列。記錄追加方式的“ 至少一次追加” 的特性保證了 writer 的輸出。 readers使用下面的方法來處理偶然性的填充數(shù)據(jù)和重復(fù)內(nèi)容。writers在每條寫入的記錄中都包含了額外的信息,例如checksum,用來驗(yàn)證它的有效性。reader可以利用 checksum識別和拋棄額外的填充數(shù)據(jù)和記錄片段。如果應(yīng)用不能容忍偶爾的重復(fù)內(nèi)容 (比如,如果這些重復(fù)數(shù)據(jù)觸發(fā)了非冪等操作),可以用記錄的唯一標(biāo)識符來過濾它們,這些唯一標(biāo)識符通常用于命名程序中處理的實(shí)體對象

38、,例如web 文檔。這些記錄i/o功能 (alex 注: these functionalities for record i/o)(除了剔除重復(fù)數(shù)據(jù))都包含在我們的程序共享的庫中,并且適用于google 內(nèi)部的其它的文件接口實(shí)現(xiàn)。所以,相同序列的記錄,加上一些偶爾出現(xiàn)的重復(fù)數(shù)據(jù),都被分發(fā)到reader 了。3系統(tǒng)交互我們在設(shè)計(jì)這個系統(tǒng)時,一個重要的原則是最小化所有操作和master 節(jié)點(diǎn)的交互。帶著這樣的設(shè)計(jì)理念,我們現(xiàn)在描述一下客戶機(jī)、master 服務(wù)器和chunk 服務(wù)器如何進(jìn)行交互,以實(shí)現(xiàn)數(shù)據(jù)修改操作、原子的記錄追加操作以及快照功能。3.1租約( lease )和變更順序(alex

39、注: lease 是數(shù)據(jù)庫中的一個術(shù)語)變更是一個會改變chunk內(nèi)容或者元數(shù)據(jù)的操作,比如寫入操作或者記錄追加操作。變更操作會在chunk 的所有副本上執(zhí)行。我們使用租約(lease)機(jī)制來保持多個副本間變更順序的一致性。master 節(jié)點(diǎn)為 chunk 的一個副本建立一個租約,我們把這個副本叫做主chunk。主 chunk 對 chunk 的所有更改操作進(jìn)行序列化。所有的副本都遵從這個序列進(jìn)行修9 改操作。因此,修改操作全局的順序首先由master 節(jié)點(diǎn)選擇的租約的順序決定,然后由租約中主 chunk 分配的序列號決定。設(shè)計(jì)租約機(jī)制的目的是為了最小化master 節(jié)點(diǎn)的管理負(fù)擔(dān)。租約的初始

40、超時設(shè)置為60秒。不過,只要chunk 被修改了,主chunk 就可以申請更長的租期,通常會得到master 節(jié)點(diǎn)的確認(rèn)并收到租約延長的時間。這些租約延長請求和批準(zhǔn)的信息通常都是附加在master節(jié)點(diǎn)和 chunk 服務(wù)器之間的心跳消息中來傳遞。有時master 節(jié)點(diǎn)會試圖提前取消租約(例如, master 節(jié)點(diǎn)想取消在一個已經(jīng)被改名的文件上的修改操作)。即使master 節(jié)點(diǎn)和主chunk 失去聯(lián)系,它仍然可以安全地在舊的租約到期后和另外一個chunk 副本簽訂新的租約。在圖 2 中,我們依據(jù)步驟編號,展現(xiàn)寫入操作的控制流程。1.客戶機(jī)向 master 節(jié)點(diǎn)詢問哪一個chunk 服務(wù)器持有當(dāng)

41、前的租約,以及其它副本的位置。如果沒有一個chunk 持有租約, master 節(jié)點(diǎn)就選擇其中一個副本建立一個租約(這個步驟在圖上沒有顯示)。2.master 節(jié)點(diǎn)將主chunk 的標(biāo)識符以及其它副本 (又稱為secondary 副本、二級副本)的位置返回給客戶機(jī)??蛻魴C(jī)緩存這些數(shù)據(jù)以便后續(xù)的操作。只有在主chunk不可用,或者主chunk 回復(fù)信息表明它已不再持有租約的時候,客戶機(jī)才需要重新跟master 節(jié)點(diǎn)聯(lián)系。3.客戶機(jī)把數(shù)據(jù)推送到所有的副本上。客戶機(jī)可以以任意的順序推送數(shù)據(jù)。chunk 服務(wù)器接收到數(shù)據(jù)并保存在它的內(nèi)部lru緩存中,一直到數(shù)據(jù)被使用或者過期交換出去。由于數(shù)據(jù)流的網(wǎng)絡(luò)傳

42、輸負(fù)載非常高,通過分離數(shù)據(jù)流和控制流,我們可以基于網(wǎng)絡(luò)拓?fù)淝闆r對數(shù)據(jù)流進(jìn)行規(guī)劃,提高系統(tǒng)性能,而不用去理會哪個chunk服務(wù)器保存了主chunk。3.2 章節(jié)會進(jìn)一步討論這點(diǎn)。4.當(dāng)所有的副本都確認(rèn)接收到了數(shù)據(jù),客戶機(jī)發(fā)送寫請求到主chunk服務(wù)器。這個請求標(biāo)識了早前推送到所有副本的數(shù)據(jù)。主chunk為接收到的所有操作分配連續(xù)的序列號,這些操作可能來自不同的客戶機(jī),序列號保證了操作順序執(zhí)行。它以序列號的順序把操作應(yīng)用到它自己的本地狀態(tài)中(alex 注:也就是在本地執(zhí)行這些操作,這句話按字面翻譯有點(diǎn)費(fèi)解,也許應(yīng)該翻譯為“ 它順序執(zhí)行這些操作,并更新自己的狀態(tài) ” )。5.主 chunk把寫請求傳

43、遞到所有的二級副本。每個二級副本依照主chunk分配的序列號以相同的順序執(zhí)行這些操作。6.所有的二級副本回復(fù)主chunk,它們已經(jīng)完成了操作。10 7.主 chunk 服務(wù)器 (alex 注:即主chunk 所在的 chunk 服務(wù)器) 回復(fù)客戶機(jī)。任何副本產(chǎn)生的任何錯誤都會返回給客戶機(jī)。在出現(xiàn)錯誤的情況下,寫入操作可能在主chunk 和一些二級副本執(zhí)行成功。(如果操作在主chunk 上失敗了,操作就不會被分配序列號,也不會被傳遞。)客戶端的請求被確認(rèn)為失敗,被修改的region 處于不一致的狀態(tài)。我們的客戶機(jī)代碼通過重復(fù)執(zhí)行失敗的操作來處理這樣的錯誤。在從頭開始重復(fù)執(zhí)行之前,客戶機(jī)會先從步驟

44、(3)到步驟( 7)做幾次嘗試。如果應(yīng)用程序一次寫入的數(shù)據(jù)量很大,或者數(shù)據(jù)跨越了多個chunk,gfs客戶機(jī)代碼會把它們分成多個寫操作。這些操作都遵循前面描述的控制流程,但是可能會被其它客戶機(jī)上同時進(jìn)行的操作打斷或者覆蓋。因此,共享的文件region 的尾部可能包含來自不同客戶機(jī)的數(shù)據(jù)片段,盡管如此,由于這些分解后的寫入操作在所有的副本上都以相同的順序執(zhí)行完成, chunk 的所有副本都是一致的。這使文件region 處于 2.7 節(jié)描述的一致的、但是未定義的狀態(tài)。3.2數(shù)據(jù)流為了提高網(wǎng)絡(luò)效率,我們采取了把數(shù)據(jù)流和控制流分開的措施。在控制流從客戶機(jī)到主 chunk、然后再到所有二級副本的同時,

45、數(shù)據(jù)以管道的方式,順序的沿著一個精心選擇的 chunk 服務(wù)器鏈推送。我們的目標(biāo)是充分利用每臺機(jī)器的帶寬,避免網(wǎng)絡(luò)瓶頸和高延時的連接,最小化推送所有數(shù)據(jù)的延時。為了充分利用每臺機(jī)器的帶寬,數(shù)據(jù)沿著一個chunk 服務(wù)器鏈順序的推送,而不是以其它拓?fù)湫问椒稚⑼扑停ɡ?,樹型拓?fù)浣Y(jié)構(gòu))。線性推送模式下,每臺機(jī)器所有的出口帶寬都用于以最快的速度傳輸數(shù)據(jù),而不是在多個接受者之間分配帶寬。為了盡可能的避免出現(xiàn)網(wǎng)絡(luò)瓶頸和高延遲的鏈接(eg, inter-switch 最有可能出現(xiàn)類似問題),每臺機(jī)器都盡量的在網(wǎng)絡(luò)拓?fù)渲羞x擇一臺還沒有接收到數(shù)據(jù)的、離自己最近的機(jī)器作為目標(biāo)推送數(shù)據(jù)。假設(shè)客戶機(jī)把數(shù)據(jù)從chun

46、k 服務(wù)器 s1推送到 s4。它把數(shù)據(jù)推送到最近的chunk服務(wù)器 s1。s1把數(shù)據(jù)推送到s2,因?yàn)?s2和 s4中最接近的機(jī)器是s2。同樣的, s2把數(shù)據(jù)傳遞給s3和 s4之間更近的機(jī)器,依次類推推送下去。我們的網(wǎng)絡(luò)拓?fù)浞浅:唵?,通過ip地址就可以計(jì)算出節(jié)點(diǎn)的“ 距離 ” 。最后,我們利用基于tcp連接的、管道式數(shù)據(jù)推送方式來最小化延遲。chunk 服務(wù)器接收到數(shù)據(jù)后,馬上開始向前推送。管道方式的數(shù)據(jù)推送對我們幫助很大,因?yàn)槲覀儾捎萌p工的交換網(wǎng)絡(luò)。接收到數(shù)據(jù)后立刻向前推送不會降低接收的速度。在沒有網(wǎng)絡(luò)擁塞的情況下,傳送b 字節(jié)的數(shù)據(jù)到r 個副本的理想時間是b/t+rl ,t 是網(wǎng)絡(luò)的吞吐量

47、,l 是在兩臺機(jī)器數(shù)據(jù)傳輸?shù)难舆t。通常情況下,我們的網(wǎng)絡(luò)連接速度是100mbps(t), l 將遠(yuǎn)小于1ms。因此, 1mb 的數(shù)據(jù)在理想情況下80ms 左右就能分發(fā)出去。3.33 原子的記錄追加gfs提供了一種原子的數(shù)據(jù)追加操作 記錄追加。傳統(tǒng)方式的寫入操作,客戶程序會指定數(shù)據(jù)寫入的偏移量。對同一個region 的并行寫入操作不是串行的:region 尾部可能會包含多個不同客戶機(jī)寫入的數(shù)據(jù)片段。使用記錄追加,客戶機(jī)只需要指定要寫入的數(shù)據(jù)。gfs保證至少有一次原子的寫入操作成功執(zhí)行(即寫入一個順序的byte 流),寫入的數(shù)據(jù)追加到 gfs指定的偏移位置上,之后gfs返回這個偏移量給客戶機(jī)。這類

48、似于在unix 操作系統(tǒng)編程環(huán)境中,對以o_append模式打開的文件,多個并發(fā)寫操作在沒有競態(tài)條件時的行為。11 記錄追加在我們的分布應(yīng)用中非常頻繁的使用,在這些分布式應(yīng)用中,通常有很多的客戶機(jī)并行地對同一個文件追加寫入數(shù)據(jù)。如果我們采用傳統(tǒng)方式的文件寫入操作,客戶機(jī)需要額外的復(fù)雜、昂貴的同步機(jī)制,例如使用一個分布式的鎖管理器。在我們的工作中,這樣的文件通常用于多個生產(chǎn)者/單一消費(fèi)者的隊(duì)列系統(tǒng),或者是合并了來自多個客戶機(jī)的數(shù)據(jù)的結(jié)果文件。記錄追加是一種修改操作,它也遵循3.1 節(jié)描述的控制流程,除了在主chunk 有些額外的控制邏輯。客戶機(jī)把數(shù)據(jù)推送給文件最后一個chunk 的所有副本,之后

49、發(fā)送請求給主chunk。主 chunk 會檢查這次記錄追加操作是否會使chunk 超過最大尺寸(64mb)。如果超過了最大尺寸,主chunk 首先將當(dāng)前chunk 填充到最大尺寸,之后通知所有二級副本做同樣的操作,然后回復(fù)客戶機(jī)要求其對下一個chunk 重新進(jìn)行記錄追加操作。(記錄追加的數(shù)據(jù)大小嚴(yán)格控制在chunk 最大尺寸的1/4 ,這樣即使在最壞情況下,數(shù)據(jù)碎片的數(shù)量仍然在可控的范圍。)通常情況下追加的記錄不超過chunk 的最大尺寸,主chunk 把數(shù)據(jù)追加到自己的副本內(nèi),然后通知二級副本把數(shù)據(jù)寫在跟主chunk 一樣的位置上,最后回復(fù)客戶機(jī)操作成功。如果記錄追加操作在任何一個副本上失敗

50、了,客戶端就需要重新進(jìn)行操作。重新進(jìn)行記錄追加的結(jié)果是,同一個chunk 的不同副本可能包含不同的數(shù)據(jù) 重復(fù)包含一個記錄全部或者部分的數(shù)據(jù)。gfs并不保證 chunk的所有副本在字節(jié)級別是完全一致的。它只保證數(shù)據(jù)作為一個整體原子的被至少寫入一次。這個特性可以通過簡單觀察推導(dǎo)出來:如果操作成功執(zhí)行,數(shù)據(jù)一定已經(jīng)寫入到chunk 的所有副本的相同偏移位置上。這之后,所有的副本至少都到了記錄尾部的長度,任何后續(xù)的記錄都會追加到更大的偏移地址,或者是不同的chunk 上,即使其它的chunk 副本被 master 節(jié)點(diǎn)選為了主chunk。就我們的一致性保障模型而言,記錄追加操作成功寫入數(shù)據(jù)的regio

51、n 是已定義的(因此也是一致的),反之則是不一致的(因此也就是未定義的)。正如我們在2.7.2 節(jié)討論的,我們的程序可以處理不一致的區(qū)域。3.43 快照(alex 注:這一節(jié)非常難以理解,總的來說依次講述了什么是快照、快照使用的cow技術(shù)、快照如何不干擾當(dāng)前操作)快照操作幾乎可以瞬間完成對一個文件或者目錄樹(“ 源” )做一個拷貝,并且?guī)缀醪粫φ谶M(jìn)行的其它操作造成任何干擾。我們的用戶可以使用快照迅速的創(chuàng)建一個巨大的數(shù)據(jù)集的分支拷貝 (而且經(jīng)常是遞歸的拷貝拷貝),或者是在做實(shí)驗(yàn)性的數(shù)據(jù)操作之前,使用快照操作備份當(dāng)前狀態(tài),這樣之后就可以輕松的提交或者回滾到備份時的狀態(tài)。就像 afs (alex

52、 注: afs ,即 andrew file system,一種分布式文件系統(tǒng)),我們用標(biāo)準(zhǔn)的 copy-on-write 技術(shù)實(shí)現(xiàn)快照。當(dāng)master 節(jié)點(diǎn)收到一個快照請求,它首先取消作快照的文件的所有chunk 的租約。這個措施保證了后續(xù)對這些chunk 的寫操作都必須與master 交互交互以找到租約持有者。這就給master 節(jié)點(diǎn)一個率先創(chuàng)建chunk 的新拷貝的機(jī)會。租約取消或者過期之后,master 節(jié)點(diǎn)把這個操作以日志的方式記錄到硬盤上。然后,master 節(jié)點(diǎn)通過復(fù)制源文件或者目錄的元數(shù)據(jù)的方式,把這條日志記錄的變化反映到保存在內(nèi)存的狀態(tài)中。新創(chuàng)建的快照文件和源文件指向完全相同

53、的chunk 地址。在快照操作之后,當(dāng)客戶機(jī)第一次想寫入數(shù)據(jù)到chunk c,它首先會發(fā)送一個請求到master 節(jié)點(diǎn)查詢當(dāng)前的租約持有者。master 節(jié)點(diǎn)注意到chunke c的引用計(jì)數(shù)超過了1(alex注:不太明白為什么會大于1.難道是 snapshot 沒有釋放引用計(jì)數(shù)?)。master 節(jié)點(diǎn)不會馬上12 回復(fù)客戶機(jī)的請求,而是選擇一個新的chunk 句柄 c。之后, master 節(jié)點(diǎn)要求每個擁有chunk c當(dāng)前副本的chunk 服務(wù)器創(chuàng)建一個叫做c的新 chunk。通過在源chunk 所在 chunk服務(wù)器上創(chuàng)建新的chunk,我們確保數(shù)據(jù)在本地而不是通過網(wǎng)絡(luò)復(fù)制(我們的硬盤比我

54、們的100mb 以太網(wǎng)大約快3 倍) 。從這點(diǎn)來講,請求的處理方式和任何其它c(diǎn)hunk沒什么不同:master 節(jié)點(diǎn)確保新chunk c的一個副本擁有租約,之后回復(fù)客戶機(jī),客戶機(jī)得到回復(fù)后就可以正常的寫這個chunk,而不必理會它是從一個已存在的chunk 克隆出來的。4master節(jié)點(diǎn)的操作master 節(jié)點(diǎn)執(zhí)行所有的名稱空間操作。此外,它還管理著整個系統(tǒng)里所有chunk 的副本:它決定chunk 的存儲位置,創(chuàng)建新chunk 和它的副本,協(xié)調(diào)各種各樣的系統(tǒng)活動以保證 chunk 被完全復(fù)制,在所有的chunk 服務(wù)器之間的進(jìn)行負(fù)載均衡,回收不再使用的存儲空間。本節(jié)我們討論上述的主題。4.1

55、名稱空間管理和鎖master 節(jié)點(diǎn)的很多操作會花費(fèi)很長的時間:比如,快照操作必須取消chunk 服務(wù)器上快照所涉及的所有的chunk 的租約。我們不希望在這些操作的運(yùn)行時,延緩了其它的master 節(jié)點(diǎn)的操作。因此,我們允許多個操作同時進(jìn)行,使用名稱空間的region 上的鎖來保證執(zhí)行的正確順序。不同于許多傳統(tǒng)文件系統(tǒng),gfs沒有針對每個目錄實(shí)現(xiàn)能夠列出目錄下所有文件的數(shù)據(jù)結(jié)構(gòu)。 gfs也不支持文件或者目錄的鏈接(即unix 術(shù)語中的硬鏈接或者符號鏈接)。在邏輯上, gfs的名稱空間就是一個全路徑和元數(shù)據(jù)映射關(guān)系的查找表。利用前綴壓縮,這個表可以高效的存儲在內(nèi)存中。在存儲名稱空間的樹型結(jié)構(gòu)上,

56、每個節(jié)點(diǎn)(絕對路徑的文件名或絕對路徑的目錄名)都有一個關(guān)聯(lián)的讀寫鎖。每個 master 節(jié)點(diǎn)的操作在開始之前都要獲得一系列的鎖。通常情況下,如果一個操作涉及 /d1/d2/ /dn/leaf,那么操作首先要獲得目錄/d1 ,/d1/d2 , ,/d1/d2/ /dn的讀鎖,以及 /d1/d2/ /dn/leaf 的讀寫鎖。注意,根據(jù)操作的不同,leaf 可以是一個文件,也可以是一個目錄。現(xiàn)在,我們演示一下在/home/user 被快照到 /save/user 的時候,鎖機(jī)制如何防止創(chuàng)建文件/home/user/foo??煺詹僮鳙@取/home 和 /save 的讀取鎖,以及/home/user

57、和/save/user 的寫入鎖。文件創(chuàng)建操作獲得/home 和/home/user 的讀取鎖,以及/home/user/foo的寫入鎖。這兩個操作要順序執(zhí)行,因?yàn)樗鼈冊噲D獲取的/home/user 的鎖是相互沖突。文件創(chuàng)建操作不需要獲取父目錄的寫入鎖,因?yàn)檫@里沒有” 目錄 ” ,或者類似inode 等用來禁止修改的數(shù)據(jù)結(jié)構(gòu)。文件名的讀取鎖足以防止父目錄被刪除。采用這種鎖方案的優(yōu)點(diǎn)是支持對同一目錄的并行操作。比如,可以再同一個目錄下同時創(chuàng)建多個文件:每一個操作都獲取一個目錄名的上的讀取鎖和文件名上的寫入鎖。目錄名的讀取鎖足以的防止目錄被刪除、改名以及被快照。文件名的寫入鎖序列化文件創(chuàng)建操作,確

58、保不會多次創(chuàng)建同名的文件。因?yàn)槊Q空間可能有很多節(jié)點(diǎn),讀寫鎖采用惰性分配策略,在不再使用的時候立刻被刪除。同樣,鎖的獲取也要依據(jù)一個全局一致的順序來避免死鎖:首先按名稱空間的層次排序,在同一個層次內(nèi)按字典順序排序。4.2副本的位置gfs集群是高度分布的多層布局結(jié)構(gòu),而不是平面結(jié)構(gòu)。典型的拓?fù)浣Y(jié)構(gòu)是有數(shù)百個chunk服務(wù)器安裝在許多機(jī)架上。chunk 服務(wù)器被來自同一或者不同機(jī)架上的數(shù)百個客戶機(jī)13 輪流訪問。不同機(jī)架上的兩臺機(jī)器間的通訊可能跨越一個或多個網(wǎng)絡(luò)交換機(jī)。另外,機(jī)架的出入帶寬可能比機(jī)架內(nèi)所有機(jī)器加和在一起的帶寬要小。多層分布架構(gòu)對數(shù)據(jù)的靈活性、可靠性以及可用性方面提出特有的挑戰(zhàn)。 c

59、hunk 副本位置選擇的策略服務(wù)兩大目標(biāo):最大化數(shù)據(jù)可靠性和可用性,最大化網(wǎng)絡(luò)帶寬利用率。為了實(shí)現(xiàn)這兩個目的,僅僅是在多臺機(jī)器上分別存儲這些副本是不夠的,這只能預(yù)防硬盤損壞或者機(jī)器失效帶來的影響,以及最大化每臺機(jī)器的網(wǎng)絡(luò)帶寬利用率。我們必須在多個機(jī)架間分布儲存chunk 的副本。這保證chunk 的一些副本在整個機(jī)架被破壞或掉線(比如,共享資源,如電源或者網(wǎng)絡(luò)交換機(jī)造成的問題)的情況下依然存在且保持可用狀態(tài)。這還意味著在網(wǎng)絡(luò)流量方面,尤其是針對chunk 的讀操作,能夠有效利用多個機(jī)架的整合帶寬。另一方面,寫操作必須和多個機(jī)架上的設(shè)備進(jìn)行網(wǎng)絡(luò)通信,但是這個代價是我們愿意付出的。4.3創(chuàng)建,重新

60、復(fù)制,重新負(fù)載均衡chunk 的副本有三個用途:chunk 創(chuàng)建,重新復(fù)制和重新負(fù)載均衡。當(dāng) master 節(jié)點(diǎn)創(chuàng)建一個chunk 時,它會選擇在哪里放置初始的空的副本。master 節(jié)點(diǎn)會考慮幾個因素。(1)我們希望在低于平均硬盤使用率的chunk 服務(wù)器上存儲新的副本。這樣的做法最終能夠平衡chunk 服務(wù)器之間的硬盤使用率。(2) 我們希望限制在每個chunk服務(wù)器上 ” 最近 ” 的 chunk 創(chuàng)建操作的次數(shù)。雖然創(chuàng)建操作本身是廉價的,但是創(chuàng)建操作也意味著隨之會有大量的寫入數(shù)據(jù)的操作,因?yàn)閏hunk 在 writer 真正寫入數(shù)據(jù)的時候才被創(chuàng)建,而在我們的” 追加一次,讀取多次” 的

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論