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

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