GFS，是一個可擴展的分布式文件系統(tǒng)，用于大型的、分布式的、對大量數(shù)據(jù)進行訪問的應用。它運行于廉價的普通硬件上，并提供容錯功能。它可以給大量的用戶提供總體性能較高的服務。
設計概覽
一、設計想定
GFS與過去的分布式文件系統(tǒng)有很多相同的目標，但GFS的設計受到了當前及預期的應用方面的工作量及技術環(huán)境的驅動，這反映了它與早期的文件系統(tǒng)明顯不同的設想。這就需要對傳統(tǒng)的選擇進行重新檢驗并進行完全不同的設計觀點的探索。
GFS與以往的文件系統(tǒng)的不同的觀點如下：
1、部件錯誤不再被當作異常，而是將其作為常見的情況加以處理。因為文件系統(tǒng)由成百上千個用于存儲的機器構成，而這些機器是由廉價的普通部件組成并被大量的客戶機訪問。部件的數(shù)量和質量使得一些機器隨時都有可能無法工作并且有一部分還可能無法恢復。所以實時地監(jiān)控、錯誤檢測、容錯、自動恢復對系統(tǒng)來說必不可少。
2、按照傳統(tǒng)的標準，文件都非常大。長度達幾個GB的文件是很平常的。每個文件通常包含很多應用對象。當經(jīng)常要處理快速增長的、包含數(shù)以萬計的對象、長度達TB的數(shù)據(jù)集時，很難管理成千上萬的KB規(guī)模的文件塊，即使底層文件系統(tǒng)提供支持。因此，設計中操作的參數(shù)、塊的大小必須要重新考慮。對大型的文件的管理一定要能做到高效，對小型的文件也必須支持，但不必優(yōu)化。
3、大部分文件的更新是通過添加新數(shù)據(jù)完成的，而不是改變已存在的數(shù)據(jù)。在一個文件中隨機的操作在實踐中幾乎不存在。一旦寫完，文件就只可讀，很多數(shù)據(jù)都有這些特性。一些數(shù)據(jù)可能組成一個大倉庫以供數(shù)據(jù)分析程序掃描。有些是運行中的程序連續(xù)產(chǎn)生的數(shù)據(jù)流。有些是檔案性質的數(shù)據(jù)，有些是在某個機器上產(chǎn)生、在另外一個機器上處理的中間數(shù)據(jù)。由于這些對大型文件的訪問方式，添加操作成為性能優(yōu)化和原子性保證的焦點。而在客戶機中緩存數(shù)據(jù)塊則失去了吸引力。
4、工作量主要由兩種讀操作構成：對大量數(shù)據(jù)的流方式的讀操作和對少量數(shù)據(jù)的隨機方式的讀操作。在前一種讀操作中，可能要讀幾百KB，通常達1MB和更多。來自同一個客戶的連續(xù)操作通常會讀文件的一個連續(xù)的區(qū)域。隨機的讀操作通常在一個隨機的偏移處讀幾個KB。性能敏感的應用程序通常將對少量數(shù)據(jù)的讀操作進行分類并進行批處理以使得讀操作穩(wěn)定地向前推進，而不要讓它來反反復復地讀。
5、工作量還包含許多對大量數(shù)據(jù)進行的、連續(xù)的、向文件添加數(shù)據(jù)的寫操作。所寫的數(shù)據(jù)的規(guī)模和讀相似。一旦寫完，文件很少改動。在隨機位置對少量數(shù)據(jù)的寫操作也支持，但不必非常高效。
6、系統(tǒng)必須高效地實現(xiàn)定義完好的大量客戶同時向同一個文件的添加操作的語義。
7、高可持續(xù)帶寬比低延遲更重要。
二、系統(tǒng)接口
GFS提供了一個相似地文件系統(tǒng)界面，雖然它沒有像POSⅨ那樣實現(xiàn)標準的API。文件在目錄中按層次組織起來并由路徑名標識。
三、體系結構
一個GFS集群由一個master和大量的chunkserver構成，并被許多客戶（Client）訪問。
Master和chunkserver通常是運行用戶層服務進程的Linux機器。只要資源和可靠性允許，chunkserver和client可以運行在同一個機器上。文件被分成固定大小的塊。每個塊由一個不變的、全局唯一的64位的chunk－h(huán)andle標識，chunk－h(huán)andle是在塊創(chuàng)建時由master分配的。ChunkServer將塊當作Linux文件存儲在本地磁盤并可以讀和寫由chunk－h(huán)andle和位區(qū)間指定的數(shù)據(jù)。出于可靠性考慮，每一個塊被復制到多個chunkserver上。默認情況下，保存3個副本，但這可以由用戶指定。
Master維護文件系統(tǒng)所以的元數(shù)據(jù)（metadata），包括名字空間、訪問控制信息、從文件到塊的映射以及塊的當前位置。它也控制系統(tǒng)范圍的活動，如塊租約（lease）管理，孤兒塊的垃圾收集，chunkserver間的塊遷移。Master定期通過HeartBeat消息與每一個chunkserver通信，給chunkserver傳遞指令并收集它的狀態(tài)。
與每個應用相聯(lián)的GFS客戶代碼實現(xiàn)了文件系統(tǒng)的API并與master和chunkserver通信以代表應用程序讀和寫數(shù)據(jù)。客戶與master的交換只限于對元數(shù)據(jù)（metadata）的操作，所有數(shù)據(jù)方面的通信都直接和chunkserver聯(lián)系。
客戶和chunkserver都不緩存文件數(shù)據(jù)。因為用戶緩存的益處微乎其微，這是由于數(shù)據(jù)太多或工作集太大而無法緩存。不緩存數(shù)據(jù)簡化了客戶程序和整個系統(tǒng)，因為不必考慮緩存的一致性問題。但用戶緩存元數(shù)據(jù)（metadata）。Chunkserver也不必緩存文件，因為塊是作為本地文件存儲的。
架構
GFS的新穎之處并不在于它采用了多么令人驚訝的新技術，而在于它采用廉價的商用計算機集群構建分布式文件系統(tǒng)，在降低成本的同時經(jīng)受了實際應用的考驗。
一個GFS包括一個主服務器（master）和多個塊服務器（chunk?server），這樣一個GFS能夠同時為多個客戶端應用程序（Application）提供文件服務。文件被劃分為固定的塊，由主服務器安排存放到塊服務器的本地硬盤上。主服務器會記錄存放位置等數(shù)據(jù)，并負責維護和管理文件系統(tǒng)，包括塊的租用、垃圾塊的回收以及塊在不同塊服務器之間的遷移。此外，主服務器還周期性地與每個塊服務器通過消息交互，以監(jiān)視運行狀態(tài)或下達命令。應用程序通過與主服務器和塊服務器的交互來實現(xiàn)對應用數(shù)據(jù)的讀寫，應用與主服務器之間的交互僅限于元數(shù)據(jù)，也就是一些控制數(shù)據(jù)，其他的數(shù)據(jù)操作都是直接與塊服務器交互的。這種控制與業(yè)務相分離的架構，在互聯(lián)網(wǎng)產(chǎn)品方案上較為廣泛，也較為成功。
一、單master
只有一個master也極大的簡化了設計并使得master可以根據(jù)全局情況作出精密的塊放置和復制決定。但是必須要將master對
讀和寫的參與減至最少，這樣它才不會成為系統(tǒng)的瓶頸。Client從來不會從master讀和寫文件數(shù)據(jù)。Client只是詢問master它應該和哪個chunkserver聯(lián)系。Client在一段限定的時間內(nèi)將這些信息緩存，在后續(xù)的操作中Client直接和chunkserver交互。
一個簡單的讀操作的交互：
1、client使用固定的塊大小將應用程序指定的文件名和字節(jié)偏移轉換成文件的一個塊索引（chunk?index）。
2、給master發(fā)送一個包含文件名和塊索引的請求。
3、master回應對應的chunk?handle和副本的位置（多個副本）。
4、client以文件名和塊索引為鍵緩存這些信息。（handle和副本的位置）。
5、Client向其中一個副本發(fā)送一個請求，很可能是最近的一個副本。請求指定了chunk?handle（chunkserver以chunk?handle標識chunk）和塊內(nèi)的一個字節(jié)區(qū)間。
6、除非緩存的信息不再有效（cache?for?a?limited?time）或文件被重新打開，否則以后對同一個塊的讀操作不再需要client和master間的交互。
通常Client可以在一個請求中詢問多個chunk的地址，而master也可以很快回應這些請求。
二、塊規(guī)模
塊規(guī)模是設計中的一個關鍵參數(shù)。選擇的是64MB，這比一般的文件系統(tǒng)的塊規(guī)模要大的多。每個塊的副本作為一個普通的Linux文件存儲，在需要的時候可以擴展。
塊規(guī)模較大的好處有：
1、減少client和master之間的交互。因為讀寫同一個塊只是要在開始時向master請求塊位置信息。對于讀寫大型文件這種減少尤為重要。即使對于訪問少量數(shù)據(jù)的隨機讀操作也可以很方便的為一個規(guī)模達幾個TB的工作集緩緩存塊位置信息。
2、Client在一個給定的塊上很可能執(zhí)行多個操作，和一個chunkserver保持較長時間的TCP連接可以減少網(wǎng)絡負載。
3、這減少了master上保存的元數(shù)據(jù)（metadata）的規(guī)模，從而使得可以將metadata放在內(nèi)存中。這又會帶來一些別的好處。
不利的一面：
一個小文件可能只包含一個塊，如果很多Client訪問該文件的話，存儲這些塊的chunkserver將成為訪問的熱點。但在實際應用中，應用程序通常順序地讀包含多個塊的文件，所以這不是一個主要問題。
三、元數(shù)據(jù)（metadata）
master存儲了三種類型的metadata：文件的名字空間和塊的名字空間，從文件到塊的映射，塊的副本的位置。所有的metadata都放在內(nèi)存中。前兩種類型的metadata通過向操作日志登記修改而保持不變，操作日志存儲在master的本地磁盤并在幾個遠程機器上留有副本。使用日志使得可以很簡單地、可靠地更新master的狀態(tài)，即使在master崩潰的情況下也不會有不一致的問題。相反，master在每次啟動以及當有chunkserver加入的時候詢問每個chunkserver的所擁有的塊的情況。
A、內(nèi)存數(shù)據(jù)結構：
因為metadata存儲在內(nèi)存中，所以master的操作很快。進一步，master可以輕易而且高效地定期在后臺掃描它的整個狀態(tài)。這種定期地掃描被用于實現(xiàn)塊垃圾收集、chunkserver出現(xiàn)故障時的副本復制、為平衡負載和磁盤空間而進行的塊遷移。
這種方法的一個潛在的問題就是塊的數(shù)量也即整個系統(tǒng)的容量是否受限與master的內(nèi)存。實際上，這并不是一個嚴重的問題。Master為每個64MB的塊維護的metadata不足64個字節(jié)。除了最后一塊，文件所有的塊都是滿的。類似的，每個文件的名字空間數(shù)據(jù)也不足64個字節(jié)，因為文件名是以一種事先確定的壓縮方式存儲的。如果要支持更大的文件系統(tǒng)，那么增加一些內(nèi)存的方法對于將元數(shù)據(jù)（metadata）保存在內(nèi)存中所獲得的簡單性、可靠性、高性能和靈活性來說，這只是一個很小的代價。
B、塊位置：
master并不為chunkserver所擁有的塊的副本的保存一個不變的記錄。它在啟動時通過簡單的查詢來獲得這些信息。Master可以保持這些信息的更新，因為它控制所有塊的放置并通過HeartBeat消息來監(jiān)控chunkserver的狀態(tài)。
這樣做的好處：因為chunkserver可能加入或離開集群、改變路徑名、崩潰、重啟等，一個集群中有成百個server，這些事件經(jīng)常發(fā)生，這種方法就排除了master與chunkserver之間的同步問題。
另一個原因是：只有chunkserver才能確定它自己到底有哪些塊，由于錯誤，chunkserver中的一些塊可能會很自然的消失，這樣在master中就沒有必要為此保存一個不變的記錄。
C、操作日志：
操作日志包含了對metadata所作的修改的歷史記錄。它作為邏輯時間線定義了并發(fā)操作的執(zhí)行順序。文件、塊以及它們的版本號都由它們被創(chuàng)建時的邏輯時間而唯一地、永久地被標識。
操作日志是如此的重要，必須要將它可靠地保存起來，并且只有在metadata的改變固定下來之后才將變化呈現(xiàn)給用戶。所以將操作日志復制到數(shù)個遠程的機器上，并且只有在將相應的日志記錄寫到本地和遠程的磁盤上之后才回答用戶的請求。
Master可以用操作日志來恢復它的文件系統(tǒng)的狀態(tài)。為了將啟動時間減至最小，日志就必須要比較小。每當日志的長度增長到超過一定的規(guī)模后，master就要檢查它的狀態(tài)，它可以從本地磁盤裝入最近的檢查點來恢復狀態(tài)。
創(chuàng)建一個檢查點比較費時，master的內(nèi)部狀態(tài)是以一種在創(chuàng)建一個檢查點時并不耽誤即將到來的修改操作的方式來組織的。Master切換到一個新的日志文件并在一個單獨的線程中創(chuàng)建檢查點。這個新的檢查點記錄了切換前所有的修改。在一個有數(shù)十萬文件的集群中用一分鐘左右就能完成。創(chuàng)建完后，將它寫入本地和遠程的磁盤。
四、數(shù)據(jù)完整性
名字空間的修改必須是原子性的，它們只能有master處理：名字空間鎖保證了操作的原子性和正確性，而master的操作日志在全局范圍內(nèi)定義了這些操作的順序。
文件區(qū)間的狀態(tài)在修改之后依賴于修改的類型，不論操作成功還是失敗，也不論是不是并發(fā)操作。如果不論從哪個副本上讀，所有的客戶都看到同樣的數(shù)據(jù)，那么文件的這個區(qū)域就是一致的。如果文件的區(qū)域是一致的并且用戶可以看到修改操作所寫的數(shù)據(jù)，那么它就是已定義的。如果修改是在沒有并發(fā)寫操作的影響下完成的，那么受影響的區(qū)域是已定義的，所有的client都能看到寫的內(nèi)容。成功的并發(fā)寫操作是未定義但卻是一致的。失敗的修改將使區(qū)間處于不一致的狀態(tài)。
Write操作在應用程序指定的偏移處寫入數(shù)據(jù)，而record?append操作使得數(shù)據(jù)（記錄）即使在有并發(fā)修改操作的情況下也至少原子性的被加到GFS指定的偏移處，偏移地址被返回給用戶。
在一系列成功的修改操作后，最后的修改操作保證文件區(qū)域是已定義的。GFS通過對所有的副本執(zhí)行同樣順序的修改操作并且使用塊版本號檢測過時的副本（由于chunkserver退出而導致丟失修改）來做到這一點。
因為用戶緩存了會位置信息，所以在更新緩存之前有可能從一個過時的副本中讀取數(shù)據(jù)。但這有緩存的截止時間和文件的重新打開而受到限制。
在修改操作成功后，部件故障仍可以是數(shù)據(jù)受到破壞。GFS通過master和chunkserver間定期的handshake，借助校驗和來檢測對數(shù)據(jù)的破壞。一旦檢測到，就從一個有效的副本盡快重新存儲。只有在GFS檢測前，所有的副本都失效，這個塊才會丟失。
系統(tǒng)交互
1、租約（lease）和修改順序
2、數(shù)據(jù)流
目標是充分利用每個機器的網(wǎng)絡帶寬，避免網(wǎng)絡瓶頸和延遲。
為了有效的利用網(wǎng)絡，將數(shù)據(jù)流和控制流分離。數(shù)據(jù)是以流水線的方式在選定的chunkerserver鏈上線性的傳遞的。每個機器的整個對外帶寬都被用作傳遞數(shù)據(jù)。為避免瓶頸，每個機器在收到數(shù)據(jù)后，將它收到數(shù)據(jù)盡快傳遞給離它最近的機器。
3、原子性的record?Append
GFS提供了一個原子性的添加操作：record?append。在傳統(tǒng)的寫操作中，client指定被寫數(shù)據(jù)的偏移位置，向同一個區(qū)間的并發(fā)的寫操作是不連續(xù)的：區(qū)間有可能包含來自多個client的數(shù)據(jù)碎片。在record?append中，client只是指定數(shù)據(jù)。GFS在其選定的偏移出將數(shù)據(jù)至少原子性的加入文件一次，并將偏移返回給client。
在分布式的應用中，不同機器上的許多client可能會同時向一個文件執(zhí)行添加操作，添加操作被頻繁使用。如果用傳統(tǒng)的write操作，可能需要額外的、復雜的、開銷較大的同步，例如通過分布式鎖管理。工作量中，這些文件通常以多個生產(chǎn)者單個消費者隊列的方式或包含從多個不同client的綜合結果。
Record?append和前面講的write操作的控制流差不多，只是在primary上多了一些邏輯判斷。首先，client將數(shù)據(jù)發(fā)送到文件最后一塊的所有副本上。然后向primary發(fā)送請求。Primary檢查添加操作是否會導致該塊超過最大的規(guī)模（64M）。如果這樣，它將該塊擴充到最大規(guī)模，并告訴其它副本做同樣的事，同時通知client該操作需要在下一個塊上重新嘗試。如果記錄滿足最大規(guī)模的要求，primary就會將數(shù)據(jù)添加到它的副本上，并告訴其它的副本在在同樣的偏移處寫數(shù)據(jù)，最后primary向client報告寫操作成功。如果在任何一個副本上record?append操作失敗，client將重新嘗試該操作。這時候，同一個塊的副本可能包含不同的數(shù)據(jù)，因為有的可能復制了全部的數(shù)據(jù)，有的可能只復制了部分。GFS不能保證所有的副本每個字節(jié)都是一樣的。它只保證每個數(shù)據(jù)作為一個原子單元被寫過至少一次。這個是這樣得出的：操作要是成功，數(shù)據(jù)必須在所有的副本上的同樣的偏移處被寫過。進一步，從這以后，所有的副本至少和記錄一樣長，所以后續(xù)的記錄將被指定到更高的偏移處或者一個不同的塊上，即使另一個副本成了primary。根據(jù)一致性保證，成功的record?append操作的區(qū)間是已定義的。而受到干擾的區(qū)間是不一致的。
4、快照（snapshot）
快照操作幾乎在瞬間構造一個文件和目錄樹的副本，同時將正在進行的其他修改操作對它的影響減至最小。
使用copy-on-write技術來實現(xiàn)snapshot。當master受到一個snapshot請求時，它首先將要snapshot的文件上塊上的lease收回。這使得任何一個向這些塊寫數(shù)據(jù)的操作都必須和master交互以找到擁有l(wèi)ease的副本。這就給master一個創(chuàng)建這個塊的副本的機會。
副本被撤銷或終止后，master在磁盤上登記執(zhí)行的操作，然后復制源文件或目錄樹的metadata以對它的內(nèi)存狀態(tài)實施登記的操作。這個新創(chuàng)建的snapshot文件和源文件（其metadata）指向相同的塊（chunk）。
Snapshot之后，客戶第一次向chunk?c寫的時候，它發(fā)一個請求給master以找到擁有l(wèi)ease的副本。Master注意到chunk?c的引用記數(shù)比1大，它延遲對用戶的響應，選擇一個chunk?handle?C’，然后要求每一有chunk?c的副本的chunkserver創(chuàng)建一個塊C’。每個chunkserver在本地創(chuàng)建chunk?C’避免了網(wǎng)絡開銷。從這以后和對別的塊的操作沒有什么區(qū)別。
操作
MASTER執(zhí)行所有名字空間的操作，除此之外，他還在系統(tǒng)范圍管理數(shù)據(jù)塊的復制：決定數(shù)據(jù)塊的放置方案，產(chǎn)生新數(shù)據(jù)塊并將其備份，和其他系統(tǒng)范圍的操作協(xié)同來確保數(shù)據(jù)備份的完整性，在所有的數(shù)據(jù)塊服務器之間平衡負載并收回沒有使用的存儲空間。
3.1名字空間管理和加鎖
與傳統(tǒng)文件系統(tǒng)不同的是，GFS沒有與每個目錄相關的能列出其所有文件的數(shù)據(jù)結構，它也不支持別名（unix中的硬連接或符號連接），不管是對文件或是目錄。GFS的名字空間邏輯上是從文件元數(shù)據(jù)到路徑名映射的一個查用表。
MASTER在執(zhí)行某個操作前都要獲得一系列鎖，例如，它要對/d1/d2…/dn/leaf執(zhí)行操作，則它必須獲得/d1，/d1/d2，…，/d1/d2/…/dn的讀鎖，/d1/d2…/dn/leaf的讀鎖或寫鎖（其中l(wèi)eaf可以使文件也可以是目錄）。MASTER操作的并行性和數(shù)據(jù)的一致性就是通過這些鎖來實現(xiàn)的。
3.2備份存儲放置策略
一個GFS集群文件系統(tǒng)可能是多層分布的。一般情況下是成千上萬個文件塊服務器分布于不同的機架上，而這些文件塊服務器又被分布于不同機架上的客戶來訪問。因此，不同機架上的兩臺機器之間的通信可能通過一個或多個交換機。數(shù)據(jù)塊冗余配置策略要達到連個目的：最大的數(shù)據(jù)可靠性和可用性，最大的網(wǎng)絡帶寬利用率。因此，如果僅僅把數(shù)據(jù)的拷貝置于不同的機器上很難滿足這兩個要求，必須在不同的機架上進行數(shù)據(jù)備份。這樣即使整個機架被毀或是掉線，也能確保數(shù)據(jù)的正常使用。這也使數(shù)據(jù)傳輸，尤其是讀數(shù)據(jù)，可以充分利用帶寬，訪問到多個機架，而寫操作，則不得不涉及到更多的機架。
3.3產(chǎn)生、重復制、重平衡數(shù)據(jù)塊
當MASTER產(chǎn)生新的數(shù)據(jù)塊時，如何放置新數(shù)據(jù)塊，要考慮如下幾個因素：⑴盡量放置在磁盤利用率低的數(shù)據(jù)塊服務器上，這樣，慢慢地各服務器的磁盤利用率就會達到平衡。⑵盡量控制在一個服務器上的“新創(chuàng)建”的次數(shù)。⑶由于上一小節(jié)討論的原因，需要把數(shù)據(jù)塊放置于不同的機架上。
MASTER在可用的數(shù)據(jù)塊備份低于用戶設定的數(shù)目時需要進行重復制。這種情況源于多種原因：服務器不可用，數(shù)據(jù)被破壞，磁盤被破壞，或者備份數(shù)目被修改。每個被需要重復制的數(shù)據(jù)塊的優(yōu)先級根據(jù)以下幾項確定：第一是現(xiàn)在的數(shù)目距目標的距離，對于能阻塞用戶程序的數(shù)據(jù)塊，也提高它的優(yōu)先級。最后，MASTER按照產(chǎn)生數(shù)據(jù)塊的原則復制數(shù)據(jù)塊，并把它們放到不同的機架內(nèi)的服務器上。
MASTER周期性的平衡各服務器上的負載：它檢查chunk分布和負載平衡，通過這種方式來填充一個新的服務器而不是把其他的內(nèi)容統(tǒng)統(tǒng)放置到它上面帶來大量的寫數(shù)據(jù)。數(shù)據(jù)塊放置的原則與上面討論的相同，此外，MASTER還決定那些數(shù)據(jù)塊要被移除，原則上他會清除那些空閑空間低于平均值的那些服務器。
3.4垃圾收集
在一個文件被刪除之后，GFS并不立即收回磁盤空間，而是等到垃圾收集程序在文件和數(shù)據(jù)塊級的的檢查中收回。
當一個文件被應用程序刪除之后，MASTER會立即記錄下這些變化，但文件所占用的資源卻不會被立即收回，而是重新給文件命了一個隱藏的名字，并附上了刪除的時間戳。在MASTER定期檢查名字空間時，它刪除超過三天（可以設定）的隱藏的文件。在此之前，可以以一個新的名字來讀文件，還可以以前的名字恢復。當隱藏的文件在名字空間中被刪除以后，它在內(nèi)存中的元數(shù)據(jù)即被擦除，這就有效地切斷了他和所有數(shù)據(jù)塊的聯(lián)系。
在一個相似的定期的名字空間檢查中，MASTER確認孤兒數(shù)據(jù)塊（不屬于任何文件）并擦除他的元數(shù)據(jù)，在和MASTER的心跳信息交換中，每個服務器報告他所擁有的數(shù)據(jù)塊，MASTER返回元數(shù)據(jù)不在內(nèi)存的數(shù)據(jù)塊，服務器即可以刪除這些數(shù)據(jù)塊。
3.5過時數(shù)據(jù)的探測
在數(shù)據(jù)更新時如果服務器停機了，那么他所保存的數(shù)據(jù)備份就會過時。對每個數(shù)據(jù)塊，MASTER設置了一個版本號來區(qū)別更新過的數(shù)據(jù)塊和過時的數(shù)據(jù)塊。
當MASTER授權一個新的lease時，他會增加數(shù)據(jù)塊的版本號并會通知更新數(shù)據(jù)備份。MASTER和備份都會記錄下當前的版本號，如果一個備份當時不可用，那么他的版本號不可能提高，當ChunkServer重新啟動并向MASTER報告他的數(shù)據(jù)塊集時，MASTER就會發(fā)現(xiàn)過時的數(shù)據(jù)。
MASTER在定期的垃圾收集程序中清除過時的備份，在此以前，處于效率考慮，在各客戶機應答時，它會認為根本不存在過時的數(shù)據(jù)。作為另一個安全措施，aster在給客戶及關于數(shù)據(jù)塊的應答或是另外一個讀取數(shù)據(jù)的服務器數(shù)據(jù)是都會帶上版本信息，在操作前客戶機和服務器會驗證版本信息以確保得到的是最新的數(shù)據(jù)。
容錯和診斷
4.1高可靠性
⒋1.1快速恢復
不管如何終止服務，MASTER和數(shù)據(jù)塊服務器都會在幾秒鐘內(nèi)恢復狀態(tài)和運行。實際上，不對正常終止和不正常終止進行區(qū)分，服務器進程都會被切斷而終止。客戶機和其他的服務器會經(jīng)歷一個小小的中斷，然后它們的特定請求超時，重新連接重啟的服務器，重新請求。
⒋1.2數(shù)據(jù)塊備份
如上文所討論的，每個數(shù)據(jù)塊都會被備份到放到不同機架上的不同服務器上。對不同的名字空間，用戶可以設置不同的備份級別。在數(shù)據(jù)塊服務器掉線或是數(shù)據(jù)被破壞時，MASTER會按照需要來復制數(shù)據(jù)塊。
⒋1.3MASTER備份
為確保可靠性，MASTER的狀態(tài)、操作記錄和檢查點都在多臺機器上進行了備份。一個操作只有在數(shù)據(jù)塊服務器硬盤上刷新并被記錄在MASTER和其備份的上之后才算是成功的。如果MASTER或是硬盤失敗，系統(tǒng)監(jiān)視器會發(fā)現(xiàn)并通過改變域名啟動它的一個備份機，而客戶機則僅僅是使用規(guī)范的名稱來訪問，并不會發(fā)現(xiàn)MASTER的改變。
4.2數(shù)據(jù)完整性
每個數(shù)據(jù)塊服務器都利用校驗和來檢驗存儲數(shù)據(jù)的完整性。原因：每個服務器隨時都有發(fā)生崩潰的可能性，并且在兩個服務器間比較數(shù)據(jù)塊也是不現(xiàn)實的，同時，在兩臺服務器間拷貝數(shù)據(jù)并不能保證數(shù)據(jù)的一致性。
每個Chunk按64kB的大小分成塊，每個塊有32位的校驗和，校驗和和日志存儲在一起，和用戶數(shù)據(jù)分開。
在讀數(shù)據(jù)時，服務器首先檢查與被讀內(nèi)容相關部分的校驗和，因此，服務器不會傳播錯誤的數(shù)據(jù)。如果所檢查的內(nèi)容和校驗和不符，服務器就會給數(shù)據(jù)請求者返回一個錯誤的信息，并把這個情況報告給MASTER。客戶機就會讀其他的服務器來獲取數(shù)據(jù)，而MASTER則會從其他的拷貝來復制數(shù)據(jù)，等到一個新的拷貝完成時，MASTER就會通知報告錯誤的服務器刪除出錯的數(shù)據(jù)塊。
附加寫數(shù)據(jù)時的校驗和計算優(yōu)化了，因為這是主要的寫操作。只是更新增加部分的校驗和，即使末尾部分的校驗和數(shù)據(jù)已被損壞而沒有檢查出來，新的校驗和與數(shù)據(jù)會不相符，這種沖突在下次使用時將會被檢查出來。
相反，如果是覆蓋現(xiàn)有數(shù)據(jù)的寫，在寫以前，必須檢查第一和最后一個數(shù)據(jù)塊，然后才能執(zhí)行寫操作，最后計算和記錄校驗和。如果在覆蓋以前不先檢查首位數(shù)據(jù)塊，計算出的校驗和則會因為沒被覆蓋的數(shù)據(jù)而產(chǎn)生錯誤。
在空閑時間，服務器會檢查不活躍的數(shù)據(jù)塊的校驗和，這樣可以檢查出不經(jīng)常讀的數(shù)據(jù)的錯誤。一旦錯誤被檢查出來，服務器會拷貝一個正確的數(shù)據(jù)塊來代替錯誤的。
4.3診斷工具
廣泛而細致的診斷日志以微小的代價換取了在問題隔離、診斷、性能分析方面起到了重大的作用。GFS服務器用日志來記錄顯著的事件（例如服務器停機和啟動）和遠程的應答。遠程日志記錄機器之間的請求和應答，通過收集不同機器上的日志記錄，并對它們進行分析恢復，可以完整地重現(xiàn)活動的場景，并用此來進行錯誤分析。
測量
測試環(huán)境
一臺主控機，兩臺主控機備份，16臺數(shù)據(jù)塊服務器，16臺客戶機。
每臺機器：2塊PⅢ1.4G處理器，2G內(nèi)存，2塊80G5400rpm的硬盤，1塊100Mbps全雙工網(wǎng)卡19臺服務器連接到一個HP2524交換機上，16臺客戶機連接到另外一臺交換機上，兩臺交換機通過1G的鏈路相連。
參考資料 >