2024谷歌文件系統(tǒng)說(shuō)明

GoogleFileSystem中文版目錄TOC\o"1-2"\h\u3008 1251201. 132572. 174783. 1119231 158722 265772.1 2272202.2 321502.3 3282052原文：well- 3279182.4Master 5202852.5 5322362.6 6238318Chunk 6320362.6.2Chunk 799232.6.3 7134610 71168012 7100252.7 82664517Master 9195622.7.2 10233163 10105673.1 1021813.2 12921020ChunkChunk 1287033.3 137523.4 14108944Master 145334.1 15182524.2 15121464.3 16158934.4 171269924metadata 17232104.5 18283635 18301915.1 184135.2 20307725.3 2142866 21139886.1 2123246.2 23197926.3工作負(fù)荷分析(Workload 263024629 26252026.3.2Chunk 27212026.3.3vs. 28258156.3.4Master 29154997 2998778 3014649 31GoogleFileSystem我們?cè)O(shè)計(jì)并實(shí)現(xiàn)了GoogleGFSGFS雖然運(yùn)行在廉價(jià)的普遍硬件設(shè)備上，但是它依然了提供災(zāi)難冗余的能力，為大量客戶機(jī)提供了高性能的GFS的設(shè)計(jì)目標(biāo)與許多傳統(tǒng)的分布式文件系統(tǒng)有很多相同之處，但是，我們的設(shè)計(jì)還是以我們對(duì)自己的應(yīng)用的負(fù)載情況和技術(shù)環(huán)境的分析為基礎(chǔ)的，不管現(xiàn)在還是將來(lái)，GFS和早期的分布式文件系統(tǒng)的設(shè)GFS完全滿足了我們對(duì)存儲(chǔ)的需求。GFSGoogle內(nèi)部，存儲(chǔ)我們的利用數(shù)千臺(tái)機(jī)器的數(shù)千個(gè)硬盤，提供了數(shù)百TB的存儲(chǔ)空間，同時(shí)為數(shù)百個(gè)客戶機(jī)服務(wù)。D43—DGoogleGoogle文件系統(tǒng)(GoogleFileSystem–GFS和早期文件系統(tǒng)的假設(shè)都有明顯的不同。所以我們重新審視了傳統(tǒng)文件系統(tǒng)在設(shè)計(jì)上的折衷選擇，衍生GoogleGoogleFileSystem1.0GoogleGoogleFileSystem1.0GSubugGS中。webTB的數(shù)據(jù)KB大小的小文件的方式是非常不明智的，盡管有些文件系統(tǒng)支持這樣的管理方式。I/OBlock的尺寸都需要重新考慮。性模型的要求，這樣就減輕了文件系統(tǒng)對(duì)應(yīng)用程序的苛刻要求，大大簡(jiǎn)化了GFS的設(shè)計(jì)。我們引入了原子性GoogleGFS1000KB數(shù)據(jù)。3.43.3節(jié)分別討論。GFSMaster節(jié)點(diǎn)3Chunk2原文：well-3MasterGFSMasterMaster節(jié)點(diǎn)復(fù)制，MasterMaster節(jié)點(diǎn)包括兩臺(tái)物理主機(jī)Chunk服務(wù)器和客戶端都放在同一臺(tái)機(jī)器上，前提是機(jī)器資源允許，并且我們能夠接受不可靠的應(yīng)用程GFS存儲(chǔ)的文件都被分割成固定大小的ChunkChunk創(chuàng)建的時(shí)候，MasterChunk分64位的Chunk標(biāo)識(shí)。Chunk服務(wù)器把ChunkLinux文件的形式保存在本地硬盤Chunk標(biāo)識(shí)和字節(jié)范圍來(lái)讀寫塊數(shù)據(jù)。出于可靠性的考慮，每個(gè)塊都會(huì)復(fù)制到多個(gè)塊服3個(gè)存儲(chǔ)復(fù)制節(jié)點(diǎn)，不過(guò)用戶可以為不同的文件命名空間設(shè)定不同的復(fù)制級(jí)MasterChunk的映Chunk5ChunkChunk服務(wù)器之間的遷移。MasterChunk服務(wù)器通訊，發(fā)送指令到各個(gè)Chunk服務(wù)器并接收Chunk服務(wù)器的狀態(tài)信息。GFSGFSAPI接口函數(shù)、Master節(jié)點(diǎn)和ChunkMaster節(jié)點(diǎn)的通信只獲取能，因此，GFSAPILinuxvnode級(jí)別。4BDBlease5原文：orphaned6Master單一的Master節(jié)點(diǎn)的策略大大簡(jiǎn)化了我們的設(shè)計(jì)。單一的Master節(jié)點(diǎn)可以通過(guò)全局的信息精確定位ChunkMaster節(jié)點(diǎn)的讀寫，避免Master節(jié)點(diǎn)成為系統(tǒng)的瓶MasterMaster節(jié)點(diǎn)詢問(wèn)它應(yīng)該聯(lián)系的Chunk服務(wù)器。Chunk服務(wù)器進(jìn)行數(shù)據(jù)讀寫操作。1解釋一下一次簡(jiǎn)單讀取的流程。首先，客戶端把文件名和程序指定的字節(jié)偏移，根據(jù)固定ChunkChunkChunkMaster節(jié)點(diǎn)。Master節(jié)Chunk標(biāo)識(shí)和副本的位置信息發(fā)還給客戶端。客戶端用文件名和Chunkkey緩存這些信Chunk的標(biāo)識(shí)和字節(jié)范圍。在對(duì)這個(gè)ChunkMaster節(jié)點(diǎn)通訊了，除非緩存的元數(shù)據(jù)信息過(guò)期或Chunk信息，Master節(jié)點(diǎn)的回應(yīng)也可能包含了緊跟著這些被請(qǐng)求的Chunk后面的Chunk的信息。在實(shí)際應(yīng)用中，這些額外的信息在沒(méi)有任何代價(jià)的情Master節(jié)點(diǎn)未來(lái)可能會(huì)發(fā)生的幾次通訊。64MB每個(gè)Chunk的副本都以普通Linux文件的形式保存在Chunk服務(wù)器上，只有在需要的時(shí)候才擴(kuò)大。惰性空間Chunk尺寸最具爭(zhēng)議一點(diǎn)。ChunkMaster節(jié)點(diǎn)通訊的需求，因?yàn)橹恍枰淮魏蚆ater節(jié)點(diǎn)的通信就可以獲取Chunk的位置信息，之后就可以對(duì)同一個(gè)Chunk進(jìn)行多次的讀寫操ChunkTB的工作數(shù)據(jù)集所有的ChunkChunk尺寸，客戶端能夠?qū)σ粋€(gè)塊進(jìn)行多次操作，這樣就可以Chunk。當(dāng)有許多的客戶端對(duì)同一個(gè)小文件進(jìn)行多次的訪問(wèn)時(shí)，存儲(chǔ)這些Chunk的ChunkChunk的大文件，熱點(diǎn)還不是主GFS用于批處理隊(duì)列系統(tǒng)的時(shí)候，熱點(diǎn)的問(wèn)題還是產(chǎn)生了：一個(gè)可執(zhí)行文件在GFSsingle-chunk文件，之后這個(gè)可執(zhí)行文件在數(shù)百臺(tái)機(jī)器上同時(shí)啟動(dòng)。存放這個(gè)可執(zhí)行文件的幾Chunk服務(wù)器被數(shù)百個(gè)客戶端的并發(fā)請(qǐng)求訪問(wèn)導(dǎo)致系統(tǒng)局部過(guò)載。我們通過(guò)使用更大的復(fù)制參數(shù)來(lái)保存可Mser7存儲(chǔ)3ChukChukChukMser8同時(shí)也制到其它的遠(yuǎn)程MserMseraeraer服務(wù)器不會(huì)持久保存hukaer服務(wù)器在啟動(dòng)時(shí)，或者有新的Chuk服務(wù)器加入時(shí)，向各個(gè)Chuk服務(wù)器輪詢它們所存儲(chǔ)的Chunk的信息。服務(wù)器失效的時(shí)重新復(fù)制數(shù)據(jù)、通過(guò)Chunk的遷移實(shí)現(xiàn)跨Chunk服務(wù)器的負(fù)載均衡以及磁盤使用狀況統(tǒng)計(jì)等功能。4.34.4章節(jié)將深入討論這些行為。Chunk64Master服務(wù)器增加額外內(nèi)存的費(fèi)用是很少的，而通過(guò)增加有限的7MasterMasterMaster服務(wù)器的行為，如存儲(chǔ)、內(nèi)存等等，因8ChunkGoogleGoogleFileSystem1.0GoogleGoogleFileSystem1.0ChunkMaster服務(wù)器并不保存持久化保存哪個(gè)ChunkChunk的副本的信息。Master服務(wù)器只是Chunk服務(wù)器以獲取這些信息。Master服務(wù)器能夠保證它持有的信息始終是最新的，因?yàn)镃hunk位置的分配，而且通過(guò)周期性的心跳信息監(jiān)控Chunk服務(wù)器的狀態(tài)。時(shí)候輪詢Chunk服務(wù)器，之后定期輪詢更新的方式更簡(jiǎn)單。這種設(shè)計(jì)簡(jiǎn)化了在有Chunk服務(wù)器加入集群、離開(kāi)集群、更名、失效、以及重啟的時(shí)候，MasterChunk服務(wù)器數(shù)據(jù)同步的問(wèn)題。在一個(gè)擁有數(shù)百臺(tái)Chunk服務(wù)器才能最終確定一個(gè)Chunk是否在它的硬盤Chunk自動(dòng)消失(比如，硬盤損壞了或者無(wú)法訪問(wèn)了)，亦或者操作人員可能會(huì)重命名一個(gè)Chunk服務(wù)器。操作日志包含了關(guān)鍵的元數(shù)據(jù)變更歷史記錄。這對(duì)GFS非常重要。這不僅僅是因?yàn)椴僮魅罩臼窃獢?shù)據(jù)唯一的持久化存儲(chǔ)記錄，它也作為判斷同步操作順序的邏輯時(shí)間基線9。文件和Chunk，連同它們的版本(參考4.5節(jié))，都由它們創(chuàng)建的邏輯時(shí)間唯一的、永久的標(biāo)識(shí)。Chunk本身沒(méi)有出現(xiàn)任何問(wèn)題，我們?nèi)杂锌赡軄G失整個(gè)文件系統(tǒng)，或者丟失客戶機(jī)器的硬盤后，才會(huì)響應(yīng)客戶端的操作請(qǐng)求。Master服務(wù)器會(huì)收集多個(gè)日志記錄后批量處理，以減少寫入磁有的狀態(tài)數(shù)據(jù)寫入一個(gè)Checkpoint文件12。在災(zāi)難恢復(fù)的時(shí)候，Master服務(wù)器就通過(guò)從磁盤上讀取這個(gè)CheckpointCheckpoint之后的有限個(gè)日志文件就能夠恢復(fù)系統(tǒng)。CheckpointB-樹(shù)91011Checkpoint12CheckpointMaster服務(wù)器的內(nèi)部狀態(tài)被組織為一種格式，這Checkpoint過(guò)程中不會(huì)阻塞正在進(jìn)行的修改操作。Master服務(wù)器使用獨(dú)立的線程切換到新的日志文件和創(chuàng)建新的Checkpoint文件。新的Checkpoint文件包括切換前所有的修改。對(duì)于一個(gè)包含數(shù)百萬(wàn)個(gè)Checkpoint1分鐘左右的時(shí)間。創(chuàng)建完成后，Checkpoint文件會(huì)被寫入在本MasterCheckpoint文件和后續(xù)的日志文件。舊的Checkpoint文件和日志文件可Checkpoint文件。GFS支持一個(gè)寬松的一致性模型，這個(gè)模型能夠很好的支撐我們的高度分布的應(yīng)用，同時(shí)還保持了相對(duì)簡(jiǎn)單且容易實(shí)現(xiàn)的優(yōu)點(diǎn)。本節(jié)我們討論GFS的一致性的保障機(jī)制，以及對(duì)應(yīng)用程序的意義。我們也著重描述GFS如何管理這些一致性保障機(jī)制，但是實(shí)現(xiàn)的細(xì)節(jié)將在本論文的其它部分討論。GFS原子性和正確性（4.1章）的保障；Master節(jié)點(diǎn)的操作日志定義了這些操作在全局的順序（2.6.3章。數(shù)據(jù)修改后文件region141總結(jié)了各種操作如果所有客戶端，無(wú)論從哪個(gè)副本讀取，讀到的數(shù)據(jù)都一樣，那么我們認(rèn)為文件regionregion就是13catastrophes14regionregionregion處于regionregion的不同類型。另外，GFSregion被認(rèn)定是不一致的，經(jīng)過(guò)了一系列的成功的修改操作之后，GFSregion是已定義的，并且包含最后一次修（a）（b）而導(dǎo)致其失效。失效的副本不會(huì)再進(jìn)行任何修改操作，MasterChunk副本的位置信息由于ChunkChunk位置信息。而且，由于我們的文件大多數(shù)都是只進(jìn)行追加操作的，所以，一個(gè)失效的副Chunk位置信息。即使在修改操作成功執(zhí)行很長(zhǎng)時(shí)間之后，組件的失效也可能損壞或者刪除數(shù)據(jù)。GFSMaster服務(wù)ChunkChunkChecksum來(lái)校驗(yàn)數(shù)據(jù)是否損壞（5.2章。一旦發(fā)現(xiàn)問(wèn)題，數(shù)據(jù)要盡快利用有效的副本進(jìn)行恢復(fù)（4.3章Chunk的所有副本GFSChunkGFS的16本文中將用到兩個(gè)專有名詞，ReaderWriterGFS17Master使用GFS的應(yīng)用程序可以利用一些簡(jiǎn)單技術(shù)實(shí)現(xiàn)這個(gè)寬松的一致性模型，這些技術(shù)也用來(lái)實(shí)現(xiàn)一些其它包含程序級(jí)別的校驗(yàn)和。Readers僅校驗(yàn)并處理上個(gè)Checkpoint之后產(chǎn)生的文件regionregion的狀對(duì)應(yīng)用程序的失敗處理更具有彈性。CheckpointWriterReader者是一個(gè)生產(chǎn)者-Writer的輸出。Readers使用下面的方法來(lái)處理偶然性的填充數(shù)據(jù)和重復(fù)內(nèi)容。Writers在每條寫入的記錄中都包含了額外的信息，例如Checksum，用來(lái)驗(yàn)證它的有效性。ReaderChecksum識(shí)別和拋棄額外的填充數(shù)據(jù)和記錄片段。如果們的程序共享的庫(kù)中，并且適用于Google內(nèi)部的其它的文件接口實(shí)現(xiàn)。所以，相同序列的記錄，加上一些偶Reader了。帶著這樣的設(shè)計(jì)理念，我們現(xiàn)在描述一下客戶機(jī)、MasterChunk服務(wù)器如何進(jìn)行交互，以實(shí)現(xiàn)變更是一個(gè)會(huì)改變Chunk18ThesefunctionalitiesforrecordI/O19leaseChunkChunkChunk的所有更改操作進(jìn)行序列化。Master節(jié)點(diǎn)選擇的租約的順序決定，然后由租約中主Chunk分配的序列號(hào)決定。Master60秒。不過(guò)，只要ChunkChunkMaster節(jié)點(diǎn)的確認(rèn)并收到租約延長(zhǎng)的時(shí)間。Master節(jié)點(diǎn)和Chunk服務(wù)器之間的心跳消息中來(lái)傳遞。有時(shí)Master節(jié)點(diǎn)會(huì)試圖提前取消租約（例如，Master節(jié)點(diǎn)想取消在一個(gè)已經(jīng)被改名的文件上的修改操作。即使Master節(jié)點(diǎn)和主ChunkChunk副本簽訂新的租約。MasterChunkMasterChunk的標(biāo)識(shí)符以及其它副本（secondary副本、二級(jí)副本）的位置返回給客戶Chunk不可用，或者主Chunk回復(fù)信息表明它已不再持Master節(jié)點(diǎn)聯(lián)系?？蛻魴C(jī)把數(shù)據(jù)推送到所有的副本上?？蛻魴C(jī)可以以任意的順序推送數(shù)據(jù)。Chunk服務(wù)器接收到數(shù)據(jù)并保Chunk服務(wù)器保存了主Chunk。3.2章節(jié)會(huì)進(jìn)一步討論這點(diǎn)。Chunk服務(wù)器。這個(gè)請(qǐng)求標(biāo)識(shí)了早前推送到Chunk為接收到的所有操作分配連續(xù)的序列號(hào)，這些操作可能來(lái)自不同的客戶機(jī)，序列ChunkChunk分配的序列號(hào)以相同的順序執(zhí)行所有的二級(jí)副本回復(fù)主ChunkChunk服務(wù)器20回復(fù)客戶機(jī)。任何副本產(chǎn)生的任何錯(cuò)誤都會(huì)返回給客戶機(jī)。在出現(xiàn)錯(cuò)誤的情況下，寫Chunk（Chunk上失敗了，操作就不會(huì)被分配序列region的尾部可能包含來(lái)自不同客戶機(jī)的數(shù)據(jù)片段，盡管如此，由于這些分解后的寫入操Chunk、然后再Chunk服務(wù)器鏈推送。我們的目標(biāo)為了盡可能的避免出現(xiàn)網(wǎng)絡(luò)瓶頸和高延遲的鏈接（eg，inter-switch最有可能出現(xiàn)類似問(wèn)題，每臺(tái)機(jī)器S4S2。同樣的，S2S3和S4之間更近的機(jī)器，依次類推推送下去。我們IPTCP連接的、管道式數(shù)據(jù)推送方式來(lái)最小化延遲。Chunk服務(wù)器接收到數(shù)據(jù)后，20ChunkChunk立刻向前推送不會(huì)降低接收的速度。在沒(méi)有網(wǎng)絡(luò)擁塞的情況下，傳送B字節(jié)的數(shù)據(jù)到R（T，LGFS提供了一種原子的數(shù)據(jù)追加操作–記錄追加。傳統(tǒng)方式的寫入操作，客戶程序會(huì)指定數(shù)據(jù)寫入的偏使用記錄追加，客戶機(jī)只需要指定要寫入的數(shù)據(jù)。GFS保證至少有一次原子的寫入操作成功執(zhí)行（即寫入一byte流GFS指定的偏移位置上，之后GFS返回這個(gè)偏移量給客戶機(jī)。這類似UnixO_APPEND模式打開(kāi)的文件，多個(gè)并發(fā)寫操作在沒(méi)有競(jìng)態(tài)條件時(shí)的行3.1Chunk有些額外的控制邏輯?？虲hunk的所有副本，之后發(fā)送請(qǐng)求給主ChunkChunk會(huì)檢查這次記錄追（64MBChunk重新進(jìn)行記錄追加操）ChunkChunk把數(shù)據(jù)追加到自己的副本內(nèi)，然后通知二級(jí)副本把數(shù)據(jù)寫在跟主Chunk一樣的位置上，最后回復(fù)客戶機(jī)操作成功。同一個(gè)ChunkGFS并不保證ChunkChunk的所有副本的相同偏移位置上。這之Chunk上，即使其它的Chunk副本被Master節(jié)點(diǎn)選為了主Chunk。就我們的一致性保障模型而言，記錄追加）就像AFS（alex注：AFSAndrewFileSystem，一種分布式文件系統(tǒng)copy-on-write保證了后續(xù)對(duì)這些ChunkMasterMaster節(jié)點(diǎn)一個(gè)率先創(chuàng)建Chunk的新拷貝的機(jī)會(huì)。和源文件指向完全相同的Chunk地址。Master節(jié)點(diǎn)注意到ChunkC122Master節(jié)點(diǎn)不會(huì)馬上回復(fù)客戶機(jī)的請(qǐng)求，而是選擇一個(gè)新的Chunk句柄C`。之后，MasterChunkCChunk服務(wù)器創(chuàng)建一C`的新ChunkChunk所在Chunk服務(wù)器上創(chuàng)建新的Chunk，我們確保數(shù)據(jù)在本地而不是通沒(méi)什么不同：MasterChunkC`的一個(gè)副本擁有租約，之后回復(fù)客戶機(jī)，客戶機(jī)得到回復(fù)后就可以正常的寫這個(gè)Chunk，而不必理會(huì)它是從一個(gè)已存在的Chunk克隆出來(lái)的。MasterMasterChunkChunk21COW221.SnapshotMasterChunk服務(wù)器上快照所涉及的所有region上的鎖來(lái)保證執(zhí)行的正確順序。支持文件或者目錄的鏈接（Unix術(shù)語(yǔ)中的硬鏈接或者符號(hào)鏈接。在邏輯上，GFS的名稱空間就是一個(gè)全每個(gè)Master節(jié)點(diǎn)的操作在開(kāi)始之前都要獲得一系列的鎖。通常情況下，如果一個(gè)操作涉及意，根據(jù)操作的不同，leaf可以是一個(gè)文件，也可以是一個(gè)目錄。現(xiàn)在，我們演示一下在/home/user被快照到/save/user的時(shí)候，鎖機(jī)制如何防止創(chuàng)建文件/home/user/foo。快照操作獲取/home和/save的讀取鎖，以及/home/user和/save/user的寫入鎖。文件創(chuàng)建操作獲得/home和GFS集群是高度分布的多層布局結(jié)構(gòu)，而不是平面結(jié)構(gòu)。典型的拓?fù)浣Y(jié)構(gòu)是有數(shù)百個(gè)Chunk服務(wù)器安裝在許多機(jī)架上。Chunk服務(wù)器被來(lái)自同一或者不同機(jī)架上的數(shù)百個(gè)客戶機(jī)輪流訪問(wèn)。不同機(jī)架上的兩臺(tái)機(jī)器Chunk副本位置選擇的策略服務(wù)兩大目標(biāo)：最大化數(shù)據(jù)可靠性和可用性，最大化網(wǎng)絡(luò)帶寬利用率。為了ChunkChunkChunk的讀操作，能夠有效利用多個(gè)機(jī)架的Master節(jié)點(diǎn)創(chuàng)建一個(gè)Chunk時(shí)，它會(huì)選擇在哪里放置初始的空的副本。MasterChunkChunk創(chuàng)建操作的次數(shù)。雖然創(chuàng)建操作本身是廉價(jià)的，但是創(chuàng)建操作也意味著隨之會(huì)有大量的寫入數(shù)據(jù)的操作，因?yàn)镃hunkWriter真正寫入數(shù)據(jù)的時(shí)候才被創(chuàng)建，而在我們的“追加一次，讀取多次”的工作模式下，Chunk一旦寫入成功之后就會(huì)變?yōu)橹蛔x的了。Chunk的有效副本數(shù)量少于用戶指定的復(fù)制因數(shù)的時(shí)候，Master節(jié)點(diǎn)會(huì)重新復(fù)制它。這可能是由幾個(gè)Chunk服務(wù)器不可用了，Chunk服務(wù)器報(bào)告它所存儲(chǔ)的一個(gè)副本損壞了，Chunk服務(wù)器的一個(gè)磁盤因?yàn)殄e(cuò)誤不可用了，或者Chunk副本的復(fù)制因數(shù)提高了。每個(gè)需要被重新復(fù)制的Chunk都會(huì)根據(jù)幾個(gè)因素進(jìn)行排序。一個(gè)因素是Chunk現(xiàn)有副本數(shù)量和復(fù)制因數(shù)相差多少。例如，丟失兩個(gè)副本的Chunk比丟Chunk有更高的優(yōu)先級(jí)。另外，我們優(yōu)先重新復(fù)制活躍（live）Chunk而不是最近剛被刪除的文件的Chunk（4.4節(jié)Chunk對(duì)正在運(yùn)行的應(yīng)用程序的影響，我們提Chunk的優(yōu)先級(jí)。Chunk服務(wù)器上的正在進(jìn)行的克隆操作的數(shù)量、在機(jī)架間分布副本。為了防止克隆產(chǎn)生的網(wǎng)絡(luò)流量大大超過(guò)客戶機(jī)的流量，Master節(jié)點(diǎn)對(duì)Chunk服務(wù)器上的同時(shí)進(jìn)行的克隆操作的數(shù)量都進(jìn)行了限制。另外，Chunk服務(wù)器通過(guò)調(diào)節(jié)Chunk服務(wù)器讀請(qǐng)求的頻率來(lái)限制它用于克隆操作的帶寬。MasterChunk填滿它，以至于過(guò)載。新副本的存儲(chǔ)位置選擇策略和上面討論的相當(dāng)一個(gè)文件被應(yīng)用程序刪除時(shí)，Master節(jié)點(diǎn)象對(duì)待其它修改操作一樣，立刻把刪除操作以日志的方式記錄下來(lái)。但是，Master節(jié)點(diǎn)并不馬上回收資源，而是把文件名改為一個(gè)包含刪除時(shí)間戳的、隱藏的名字。當(dāng)Master節(jié)點(diǎn)對(duì)文件系統(tǒng)命名空間做常規(guī)掃描的時(shí)候，它會(huì)刪除所有三天前的隱藏文件（這個(gè)時(shí)間間隔是可以元數(shù)據(jù)才會(huì)被刪除。這也有效的切斷了文件和它包含的所有Chunk的連接23。Chunk名字空間做類似的常規(guī)掃描時(shí)，MasterChunk（Chunk）并刪除它們的元數(shù)據(jù)。ChunkMasterChunk子集的信息，Master節(jié)點(diǎn)回復(fù)Chunk服務(wù)器哪些Chunk在MasterChunk服務(wù)器可以任Chunk的副本。GFS系統(tǒng)中是非常ChunkMaster服務(wù)器上的文件到塊的映射表中。我們也可以很輕易的得到所有ChunkLinux文件的形式存儲(chǔ)在Chunk服務(wù)器的指定目錄下。Master垃圾回收方式簡(jiǎn)單可靠。ChunkChunk服務(wù)器創(chuàng)建成功，某些Chunk服務(wù)器上創(chuàng)建失敗，失敗的副本處于無(wú)法被MasterMaster節(jié)點(diǎn)必須重新發(fā)送失敗的刪除消息，包括自身的和Chunk服務(wù)器的24。垃圾回收提供了一致的、可靠的清除無(wú)用副本的方法。第二，垃圾回收把Master節(jié)點(diǎn)規(guī)律性的后臺(tái)活動(dòng)中，比如，例行掃描和與Chunk服務(wù)器握手等。因此，操作被批量的執(zhí)行，開(kāi)銷會(huì)被分散。另外，垃圾回收在Master節(jié)點(diǎn)相對(duì)空閑的時(shí)候完成。這樣Master23原文：Thiseffectivelyseversitslinkstoallits24metadataChunk服務(wù)器失效時(shí)，Chunk的副本有可能因錯(cuò)失了一些修改操作而過(guò)期失效。Master節(jié)點(diǎn)保存了每Chunk的版本號(hào)，用來(lái)區(qū)分當(dāng)前的副本和過(guò)期副本。副本。Master節(jié)點(diǎn)和這些副本都把新的版本號(hào)記錄在它們持久化存儲(chǔ)的狀態(tài)信息中。這個(gè)動(dòng)作發(fā)生在任何客Chunk開(kāi)始寫之前。如果某個(gè)副本所在的Chunk服務(wù)器正好處于失效狀態(tài)，那么副本的版本號(hào)就不會(huì)被增加。Master節(jié)點(diǎn)在這個(gè)ChunkMaster節(jié)點(diǎn)報(bào)告它Chunk的集合以及相應(yīng)的版本號(hào)的時(shí)候，就會(huì)檢測(cè)出它包含過(guò)期的ChunkMaster節(jié)點(diǎn)看到一個(gè)比它記錄的版本號(hào)更高的版本號(hào)，Master節(jié)點(diǎn)會(huì)認(rèn)為它和Chunk服務(wù)器簽訂租約的操作失敗了，因此會(huì)選擇Master節(jié)點(diǎn)在例行的垃圾回收過(guò)程中移除所有的過(guò)期失效副本。在此之前，Master節(jié)點(diǎn)在回復(fù)客戶機(jī)的Chunk信息請(qǐng)求的時(shí)候，簡(jiǎn)單的認(rèn)為那些過(guò)期的塊根本就不存在。另外一重保障措施是，Master節(jié)點(diǎn)在通知ChunkChunk服務(wù)器從哪個(gè)Chunk服務(wù)器進(jìn)行克隆時(shí)，消息中都附帶我們?cè)谠O(shè)計(jì)GFS時(shí)遇到的最大挑戰(zhàn)之一是如何處理頻繁發(fā)生的組件失效。組件的數(shù)量和質(zhì)量讓這些問(wèn)題些挑戰(zhàn)，以及當(dāng)組件失效不可避免的發(fā)生時(shí)，用GFS自帶工具診斷系統(tǒng)故障。Master服務(wù)器和Chunk服務(wù)器是如何關(guān)閉的，它們都被設(shè)計(jì)為可以在數(shù)秒鐘內(nèi)恢復(fù)它們的狀態(tài)并重kill掉進(jìn)程來(lái)關(guān)閉服務(wù)器。客戶重試這個(gè)請(qǐng)求。6.6.2章節(jié)記錄了實(shí)測(cè)的啟動(dòng)時(shí)間。Chunk正如之前討論的，每個(gè)ChunkChunk服務(wù)器上。用戶可以為文件命名空節(jié)）發(fā)現(xiàn)了已經(jīng)損壞的數(shù)據(jù)，MasterChunk都被完整復(fù)制26ChunkMaster為了保證Master服務(wù)器的可靠性，Master服務(wù)器的狀態(tài)也要復(fù)制。Master服務(wù)器所有的操作日志和checkpointMaster服務(wù)器狀態(tài)的修改操作能夠提交成功的前提是，操作日志程所在的機(jī)器或者磁盤失效了，處于GFS系統(tǒng)外部的監(jiān)控進(jìn)程會(huì)在其它的存有完整操作日志的機(jī)器上啟動(dòng)一MasterMaster節(jié)點(diǎn)。供文件系統(tǒng)的只讀訪問(wèn)。它們是影子，而不是鏡像，所以它們的數(shù)據(jù)可能比“主”Master服務(wù)器更新要慢，125aminor26Chunk27ErasurecodesbufferMasterChunk服務(wù)器上讀取的，因此，應(yīng)用程序不“影子”Master服務(wù)器為了保持自身狀態(tài)是最新的，它會(huì)讀取一份當(dāng)前正在進(jìn)行的操作的日志副本，并MasterMasterMasterChunk服務(wù)器輪詢數(shù)據(jù)（之后定期拉數(shù)據(jù)Chunk副本的位置信MasterChunkMaster服務(wù)器因創(chuàng)建MasterMaster服務(wù)器通信來(lái)更新自身狀態(tài)。每個(gè)Chunk服務(wù)器都使用Checksum來(lái)檢查保存的數(shù)據(jù)是否損壞。考慮到一個(gè)GFS集群通常都有好幾百臺(tái)機(jī)器、幾千塊硬盤，磁盤損壞導(dǎo)致數(shù)據(jù)在讀寫過(guò)程中損壞或者丟失是非常常見(jiàn)的（7節(jié)講了一個(gè)原因。我們可以通過(guò)別的Chunk副本來(lái)解決數(shù)據(jù)損壞問(wèn)題，但是跨越Chunk服務(wù)器比較副本來(lái)檢查數(shù)據(jù)是否損壞很不實(shí)際。另外，GFS允許有歧義的副本存在：GFS修改操作的語(yǔ)義，特別是早先討論過(guò)的原子紀(jì)錄追加的操作，并不保證副本完全相同(alexbyte-wise完全一致的)Chunk服務(wù)器必須獨(dú)立維Checksum來(lái)校驗(yàn)自己的副本的完整性。Chunk64KB32Checksum。和其它元數(shù)據(jù)一樣，Checksum與其它的用戶數(shù)據(jù)是分開(kāi)的，并且保存在內(nèi)存和硬盤上，同時(shí)也記錄操作日志。Chunk服務(wù)器之前，Chunk服務(wù)器會(huì)校驗(yàn)讀取操作ChecksumChunk服務(wù)器不會(huì)把錯(cuò)誤數(shù)據(jù)傳遞到其它的機(jī)器上。如果發(fā)生某個(gè)塊的Checksum不正確，ChunkMaster服務(wù)器這個(gè)錯(cuò)誤。作為回應(yīng)，請(qǐng)求者應(yīng)當(dāng)從其它副本讀取數(shù)據(jù)，MasterMaster服務(wù)器通知副本錯(cuò)誤的Chunk服務(wù)器刪掉錯(cuò)誤的副本。幾個(gè)塊，而我們只需要讀取一小部分額外的相關(guān)數(shù)據(jù)進(jìn)行校驗(yàn)。GFS客戶端代碼通過(guò)每次把讀取操作都對(duì)齊ChecksumblockChunk服務(wù)器上，ChecksumI/O操作，ChecksumI/O操作同時(shí)進(jìn)行。ChecksumChunk（與之對(duì)應(yīng)的是覆蓋現(xiàn)有數(shù)據(jù)的寫入操作Checksum，并且用所有的追加來(lái)的新Checksum塊來(lái)計(jì)算新的ChecksumChecksumChunk，我們必須讀取和校驗(yàn)被覆蓋的第一個(gè)和最后一個(gè)塊，然后再執(zhí)行寫操作；操作完成之后再重新計(jì)算和寫入新的Checksum。如果我們不校驗(yàn)第一個(gè)和最Checksum可能會(huì)隱藏沒(méi)有被覆蓋區(qū)域內(nèi)的數(shù)據(jù)錯(cuò)誤。Chunk服務(wù)器空閑的時(shí)候，它會(huì)掃描和校驗(yàn)每個(gè)不活動(dòng)的Chunk的內(nèi)容。這使得我們能夠發(fā)現(xiàn)很少被同時(shí)也只需要很小的開(kāi)銷。沒(méi)有日志的幫助，我們很難理解短暫的、不重復(fù)的機(jī)器之間的消息交互。GFS的RPC日志包含了網(wǎng)絡(luò)上發(fā)生的所有請(qǐng)求和響應(yīng)的詳細(xì)記錄，但是不包括讀寫的文件數(shù)據(jù)。通過(guò)匹配請(qǐng)求本節(jié)中，我們將使用一些小規(guī)?；鶞?zhǔn)測(cè)試來(lái)展現(xiàn)GFSGoogle內(nèi)部使用的真實(shí)的GFS1Master服務(wù)器，2Master服務(wù)器復(fù)制節(jié)點(diǎn)，16臺(tái)Chunk16個(gè)客戶機(jī)組GFSGFS集群有數(shù)百個(gè)Chunk服務(wù)器和數(shù)百個(gè)客戶機(jī)。HP2524交換機(jī)。GFS1916臺(tái)1Gbps的線路連接。N個(gè)客戶機(jī)從GFS320GB4MBregion的32GB10%Linux的文件系統(tǒng)緩沖。我們的測(cè)試結(jié)95%的可靠性，因?yàn)橛袝r(shí)候測(cè)量會(huì)不夠精確。3（a）N1Gbps的鏈125MB/S12.5MB/s10MB/s，也80%1694MB/s，大約是理論整體讀取速度極限值的75%6MB/s80%降低到了75%，主要Chunk服務(wù)器的幾率也增加了，導(dǎo)致整體的讀取效N個(gè)客戶機(jī)同時(shí)向N1MB1GB的數(shù)據(jù)。3（b）67MB/s，因?yàn)槲覀冃枰衙恳籦yte16個(gè)Chunk3個(gè)上，而每個(gè)Chunk12.5MB/s。Chunk服務(wù)器時(shí)采用的管道模式不相適應(yīng)。從一個(gè)副本到另一個(gè)副本的數(shù)據(jù)傳輸2.2MB/sChunk服務(wù)器的幾率也增加了。而且，1616個(gè)客戶機(jī)并行讀取要大得多，因?yàn)槊總€(gè)寫入都會(huì)3（c）顯示了記錄追加操作的性能。N個(gè)客戶機(jī)同時(shí)追加數(shù)據(jù)到一個(gè)文件。記錄追加操作的性能受限Chunk的Chunk服務(wù)器的帶寬，而與客戶機(jī)的數(shù)量無(wú)關(guān)。記錄追加的速度由一個(gè)客戶機(jī)N個(gè)客戶機(jī)同時(shí)追加數(shù)據(jù)到M個(gè)共享文件中，這里NM都是數(shù)十或者數(shù)百以上。所以，在我們的實(shí)際應(yīng)用中，Chunk服務(wù)器的網(wǎng)絡(luò)擁塞并沒(méi)有成為一個(gè)Chunk服務(wù)器的某個(gè)文件正在寫入，客戶機(jī)會(huì)去寫另外一個(gè)文件。MBTB的數(shù)據(jù)，之后進(jìn)行轉(zhuǎn)化或者分析，最后把結(jié)果寫回到集群中。集群BB的TB的數(shù)據(jù)集。在這兩個(gè)案例中，一ChunkTB的硬盤空間；兩個(gè)集群雖18TB52TB的文件數(shù)據(jù)。B上有大量的死文件。所謂“死文件”是指文件被刪除了B存儲(chǔ)的文件較大，因此它的Chunk數(shù)量也比較多。ChunkGB的元數(shù)據(jù)，大多數(shù)是來(lái)自用戶數(shù)據(jù)的、64KBChecksum。Chunk服務(wù)器上其它的元數(shù)據(jù)是Chunk4.5節(jié)描述過(guò)。據(jù)。這和我們?cè)O(shè)想的是一樣的，Master服務(wù)器的內(nèi)存大小在實(shí)際應(yīng)用中并不會(huì)成為GFS系統(tǒng)容量的瓶頸。大多數(shù)文件的元數(shù)據(jù)都是以前綴壓縮模式存放的文件名。Master服務(wù)器上存放的其它元數(shù)據(jù)包括了文件的所有者和權(quán)限、文件到Chunk的映射關(guān)系，以及每一個(gè)ChunkChunk，我們都保存了當(dāng)前的副本位置以及對(duì)它的引用計(jì)數(shù)，這個(gè)引用計(jì)數(shù)用于實(shí)現(xiàn)寫時(shí)拷貝（COW，copy-on-writeMaster服務(wù)器，并獲取到所有Chunk近都因?yàn)樯?jí)新版本的GFS重新啟動(dòng)過(guò)了。100MB/sChunk300MB/s。A80Bs的網(wǎng)絡(luò)配置可以支持7MBsB支持的峰值讀取速度是100B，0MB。Master3的數(shù)據(jù)顯示了發(fā)送到Master200500個(gè)。Master服務(wù)器可以輕松Master服務(wù)器的處理能力不是系統(tǒng)的瓶頸。Chunk服務(wù)器失效了，一些Chunk副本的數(shù)量可能會(huì)低于復(fù)制因子指定的數(shù)量，我們必須通過(guò)克ChunkChunk副本所花費(fèi)的時(shí)間取決于資源的數(shù)量。B上的一個(gè)ChunkKillChunk15000個(gè)Chunk，600GBGFS調(diào)度決策提供修正空間，91個(gè)（Chunk40%，每個(gè)克隆操作最多允6.25MB/s（50mbpsChunk23.2440MB/s。KillChunkChunk16000Chunk，共2分鐘內(nèi)恢復(fù)到至少有兩個(gè)副本；現(xiàn)在集群被帶入到另外一個(gè)狀態(tài)，在這個(gè)狀態(tài)下，系統(tǒng)可以容忍另Chunk服務(wù)器失效而不丟失數(shù)據(jù)。工作負(fù)荷分析(WorkloadGFS6.2節(jié)中的類似，但是不完全相同。集群X用于研究和開(kāi)發(fā)，集群Y用于生產(chǎn)數(shù)據(jù)處理。GFS文件系統(tǒng)產(chǎn)生的全部工作負(fù)載。它們不包含那些為了實(shí)現(xiàn)客戶端請(qǐng)求而在服務(wù)器間交互的請(qǐng)求，也不包GFS內(nèi)部的后臺(tái)活動(dòng)相關(guān)的請(qǐng)求，比如前向轉(zhuǎn)發(fā)的寫操作，或者重新負(fù)載均衡等操作。GFSRPCIO操作的統(tǒng)計(jì)信息。例如，GFS客RPCRPC請(qǐng)求推導(dǎo)出原始的讀應(yīng)該避免從我們的工作負(fù)荷數(shù)據(jù)中過(guò)度的歸納出普遍的結(jié)論29Google完全控制著GFS和使用GFS28原文：Sinceouraccesspatternsarehighlystylized,weexpectanyerrortobeinthe29Chunk表4顯示了操作按涉及的數(shù)據(jù)量大小的分布情況。讀取操作按操作涉及的數(shù)據(jù)量大小呈現(xiàn)了雙峰分布。小的讀取操作（64KB）一般是由查找操作的客戶端發(fā)起的，目的在于從巨大的文件中查找小塊的數(shù)據(jù)。大的讀取操作（512KB）一般是從頭到尾順序的讀取整個(gè)文件。Y上，有相當(dāng)數(shù)量的讀操作沒(méi)有返回任何的數(shù)據(jù)。在我們的