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