title: GFS 小結

tags:

• GFS
• 分布式

categories:

• paper
• 分布式

comments: true
date: 2017-06-12 17:00:00

提到分布式系統(tǒng)，有一個無法繞開的話題—— Google 三駕馬車傲绣。本文就 GFS 概括介紹造成。

設計思路

與傳統(tǒng)的分布式系統(tǒng)相比墓毒，在大方向上查排，GFS 同樣追求高性能、高可靠性芽腾、高可用性歉提，同時 Google 基于自身的生產(chǎn)環(huán)境、技術環(huán)境狠持，有一些特殊的設計思路疟位。

1. 組件失效是常態(tài)化的，而非意外喘垂。在 GFS 成百上千的集群中甜刻，隨時隨地都可能發(fā)生故障導致機器宕機甚至無法恢復绍撞，所以，監(jiān)控得院、容災傻铣、自動恢復是必須整合在 GFS 中的。

2. 文件巨大祥绞。GB 級別的數(shù)據(jù)非常普遍矾柜，所以設計的過程中 I/O、Block 尺寸等指標應以此為參考就谜。

3. 絕大多數(shù)文件的寫操作都是追加（Append）怪蔑，而非修改（Overwrite）。通常的文件場景是順序寫丧荐，且順序讀缆瓣。

4. 應用程序 client 和 GFS API 協(xié)同設計，提高靈活性虹统。

設計架構

GFS 架構比較簡單弓坞，一個 GFS 集群一般由一個 master 、多個 chunkserver 和多個 clients 組成车荔，在 GFS 中渡冻，所有文件被切分成若干個 chunk，并且每個 chunk 擁有唯一不變的標識（在 chunk 創(chuàng)建時忧便，由 master 負責分配），所有 chunk 都實際存儲在 chunkserver 的磁盤上珠增。為了容災超歌，每個 chunk 都會被復制到多個 chunkserver。
系統(tǒng)架構如下：

GFS 架構

在整個集群中巍举，為了簡化設計，master 是單節(jié)點凝垛，它管理著所有文件系統(tǒng)的所有 metadata：命名空間懊悯、訪問控制信息、文件和 chunk 的映射關系梦皮、chunk 的存儲位置炭分。同時 master 還管理系統(tǒng)范圍內的各種活動：chunk 創(chuàng)建、復制届氢、遷移欠窒、回收覆旭，chunk lease 等等退子，是系統(tǒng)中最核心的部分岖妄，后面會繼續(xù)進一步描述 master 是如何工作的。

Chunkserver 真正存儲著所有 chunk寂祥，chunkserver 依托于 linux 文件系統(tǒng)荐虐，所以它本身不需要緩存文件數(shù)據(jù)，直接利用 linux 系統(tǒng)的數(shù)據(jù)緩存丸凭，簡化了設計福扬。

Master 詳解

Master 是整個 GFS 的核心，這里重點介紹下 master 的存儲以及工作惜犀。

Metadata

所有的元數(shù)據(jù)都存儲在 Master 的內存中铛碑，以保證 Master 的性能。大部分元數(shù)據(jù)同時會以變更記錄的形式保存到操作日志中虽界，操作日志會在本地磁盤中持久化同時被復制到其他的 Master 上（雖然是 single master汽烦，但是會有備份節(jié)點備份 Master 的相關數(shù)據(jù)，比如操作日志莉御、checkpoint 文件撇吞，以保證可靠性）。

Master 會在后臺周期性的掃描所保存的狀態(tài)信息礁叔，因為全部在內存中牍颈，所以效率非常高。通過這種周期性的掃描琅关，master 實現(xiàn) chunk 回收煮岁、chunkserver 宕機時 chunk 的復制、以及遷移 chunk 涣易，實現(xiàn) chunkserver 的負載均衡人乓。

但是， chunk 的位置信息不會被持久化都毒，而是在每次 master 啟動時（以及啟動后定期執(zhí)行）色罚，或有 chunkserver 加入時，master 會輪訓所有 chunkserver 獲取所有的 chunk 信息然后保存在內存中账劲。這種方式簡化了 master 和 chunkserver 的數(shù)據(jù)同步戳护，當然數(shù)據(jù)定期輪訓的缺點就是實時性稍差。

操作日式是元數(shù)據(jù)唯一的持久化記錄瀑焦，它還定義了并發(fā)操作的執(zhí)行順序的邏輯時間線腌且，所以操作日志的完整性得到保證，才能保證 GFS 的可靠性榛瓮，否則會丟失文件或者 client 的操作铺董。因此操作日志會被復制到多臺備份節(jié)點，而且，只有 master 把操作日志持久化到本地并且復制到遠程之后精续，才會響應客戶端的請求坝锰，保證數(shù)據(jù)不丟失。

隨著時間的增長重付，操作日志會越來越大顷级，當日止增長到一定量時，master 會將所有的系統(tǒng)狀態(tài)做一次 checkpoint（可以理解為持久化某一個時間點的全部狀態(tài)數(shù)據(jù)）确垫，后續(xù)的操作變更會寫入到新的日志文件弓颈，這樣在重啟或災難恢復時，master 只需要加載最新的 checkpoint 文件到內存删掀，然后重新執(zhí)行最新的一部分操作日志即可翔冀。（這也是比較通用的一種災備方法，定期做 checkpoint披泪，然后重新記錄操作日志橘蜜，恢復時基于 checkpoint + operation log）

Checkpoint 文件以壓縮 B- 樹的結構存儲，能直接映射到內存付呕，無需額外解析计福，大幅提升了速度。同時創(chuàng)建 checkpoint 時徽职，master 會啟動獨立的線程象颖，不會阻塞正在進行的操作。

Operation

Master 節(jié)點執(zhí)行所有的命名空間管理姆钉、chunk管理以及負責垃圾回收说订。

命名空間管理

Master 在操作命名空間是基于鎖實現(xiàn)的，在操作對應的文件或目錄時潮瓶，會給對應的文件/目錄加讀鎖以及讀寫鎖陶冷，eg：對于一個 /home/usr/zhaif 的操作，會依次給父目錄 /home毯辅，/home/usr 加讀鎖埂伦，讀鎖可以防止正在讀取得文件、父目錄被刪除思恐、改名沾谜，同時給 /home/usr/zhaif 加讀鎖或寫鎖（根據(jù)操作類型），當對操作目標的操作是修改類操作時胀莹，會加寫鎖基跑，保證并發(fā)場景下互斥寫。

Chunk 管理

上文提到描焰，master 會負責 chunk 副本的存儲位置媳否，即存儲在哪些 chunkserver 上，master 會最大化的保證數(shù)據(jù)可靠性，同時最大化利用網(wǎng)絡帶寬篱竭。

在創(chuàng)建一個 chunk 時力图，master 選擇存儲空副本的初始位置時，會考慮一下幾點：

1. 傾向于選擇硬盤使用率低于平均水平的 chunkserver
2. 限制每個 chunkserver 最近一段時間的創(chuàng)建次數(shù)室抽。因為創(chuàng)建后往往意味著后續(xù)大量的寫入。
3. 分散在多機架

除了管理 chunk 副本的存儲位置靡努，master 會在 chunk 有效副本數(shù)小于指定數(shù)量時重新復制 chunk 副本坪圾，以保證數(shù)據(jù)可靠性。

最后惑朦，Master 會定期對所有副本負載均衡兽泄，檢查當前副本分布情況，然后移動副本位置以更搞笑的利用硬盤空間和負載漾月。

垃圾回收

GFS 的文件刪除不會立刻回收物理空間病梢，而是惰性的（現(xiàn)如今，惰性回收在存儲系統(tǒng)中是一種比較常見的策略梁肿，比如 redis 回收過期數(shù)據(jù)蜓陌，分配的內存空間）。這種回收機制使系統(tǒng)更簡單吩蔑、更可靠钮热、更高效。

當一個文件被刪除時烛芬，master 只是將文件改名隧期，標記為已刪除。Master 會對命名空間做定期掃描赘娄，會刪除一定時間前標記刪除的文件仆潮，同時刪除其在命名空間中的記錄以及相關元數(shù)據(jù)，此時一個文件才被真正的刪除遣臼。

Master 在常規(guī)定期掃描的過程中會發(fā)現(xiàn)一些孤兒 chunk性置，即不被任何文件包含的 chunk，然后刪除他們的元數(shù)據(jù)揍堰。Chunkserver 在和 master 定期交互時蚌讼，匯報了其所有的 chunk 信息，master 會告知其不存在的 chunk个榕，chunkserver 得知后會刪除這些 chunk 副本篡石。

這種惰性刪除的主要問題是空間利用率，尤其的在存儲空間緊缺時西采。所以 GFS 也提供了通過顯示的再刪除一次已經(jīng)刪除的文件來加速空間回收凰萨，另外也允許用戶根據(jù)需要對不同的目錄設置不同的回收策略，eg：指定用些目錄的刪除策略為即時刪除，而不是惰性刪除胖眷。

失效副本檢測

Master 的寫操作是基于 lease 機制（后文介紹）武通，當 master 每次分配 lease 時都會增加對應的 chunk 的版本號，然后所用最新的副本珊搀，通過版本號區(qū)分當前的和過期的副本冶忱。

讀寫操作實現(xiàn)

GFS 在設計是采用 client 和 API 協(xié)同設計的思路，所以在讀寫過程中 client 也不單純是發(fā)讀請求或寫請求境析，還包括其他一些操作囚枪。

讀實現(xiàn)

Client 不通過 master 節(jié)點讀寫文件，而是從 master 那獲取讀寫操作的需要聯(lián)系的 chunkserver劳淆，為了避免頻率的和 master 聯(lián)系链沼，client 會緩存 從 master 獲取的 metadata，后續(xù)操作直接和 chunkserver 溝通實現(xiàn)讀寫沛鸵。一次簡單的讀流程如下：

1. Client 把要讀去的文件名和 offset括勺，根據(jù)配置的 chunk 大小，計算出文件的 chunk 索引曲掰，然后加文件名和索引一起發(fā)送到 master疾捍，master 會返回對應 chunk 副本位置信息，client 以文件名+chunk索引作為 key 緩存此數(shù)據(jù)栏妖。

2. 之后 client 會直接和包含此 chunk 的 chunkserver 聯(lián)系獲得文件數(shù)據(jù)拾氓。

3. 實際上，client 一般會在一次請求中查詢多個 chunk 信息底哥，而 master 的 response 中也一般會包含所請求 chunk 之后的一些 chunk 信息咙鞍，以盡量減少 client 和 master 之間的通訊。

寫實現(xiàn)

相較于讀操作趾徽，寫實現(xiàn)更為復雜一些续滋。所有的寫入操作會在所有 chunk 的副本上執(zhí)行，GFS 采用 lease 機制來保證多個 chunk 副本之間變更順序一致孵奶。

Master 會選擇一個副本分配 lease疲酌，擁有這個 lease 的 chunk 被稱為 primary，其他副本則是 secondary了袁。Primary 會將對 chunk 的操作序列化朗恳，然后其他 secondary 按也這個序列執(zhí)行修改，從而保證所有副本變更一致载绿。

Lease 有效期初始為 60s粥诫，primary chunk 在完成修改操作后可以申請延長 lease 有效期，同樣的 master 在一些情況下可以提起取消 lease崭庸。Master 和 chunkserver 之間會有定期的心跳監(jiān)測怀浆，傳遞心跳信息是可以帶上這些 lease 的驗證請求或者批準信息谊囚。Lease 機制極大的簡化的 master 的負擔，將寫操作保證數(shù)據(jù)一致性的工作分擔給 chunkserver执赡，使得 master 變得很輕量镰踏。

下圖是一次寫操作的流程：

寫實現(xiàn)

1. Client 向 master 詢問要修改的 chunk 被哪個 chunkserver 持有 lease，以及 chunk 其他副本的位置信息沙合。
2. Master 返回 primary 以及 secondary 給 client奠伪。
3. Client 把所有數(shù)據(jù)推送給 primary 和 secondary，注意這里推送的只有數(shù)據(jù)首懈。
4. 當所有副本都確認收到數(shù)據(jù)后绊率，client 發(fā)送寫請求給 primary，primary 為來自不同 client 的操作分配序號猜拾，保證操作順序執(zhí)行即舌。
5. Primary 把寫請求發(fā)送到 secondary佣盒，secondary 按照 primary 分配的序號順序執(zhí)行所有操作
6. 當 Secondary 執(zhí)行完后回復 primary 執(zhí)行結果挎袜。
7. Primary 回復 client 執(zhí)行結果。

GFS 將寫操作拆分為數(shù)據(jù)流（對應3）和控制流（對應4）肥惭，數(shù)據(jù)流以 Pipline 的方式推送到所有副本盯仪。

原子記錄追加

GFS 同時提供了一個種原子的寫入操作——記錄追加。相比普通的寫入操作蜜葱，追加只需指定要寫入的數(shù)據(jù)全景，不需要提供偏移量（即要寫入的位置）。GFS 會保證追加操作至少一次原子性寫入牵囤。記錄追加的控制流程同上文描述基本相同爸黄，卻別在于 primary 會檢測此次追加后 chunk 是否超過最大值，如果達到最大值揭鳞，primary 會先將當前 chunk 填充滿炕贵，然后同步給 secondary 同樣操作，然后回復 client 要求其對下一個 chunk 重新執(zhí)行追加操作野崇。

原子記錄追加操作在避免了使用一個分布式鎖帶來的開銷称开，對于多 producer，單 consumer的場景以及合并多個來源文件的場景很契合乓梨。

一致性

GFS 是一個分布式系統(tǒng)鳖轰，為了更好的 AP，一定程度上降低了對 C 的要求扶镀，其一致性模型是比較寬松蕴侣。下圖是變更后文件狀態(tài)，其中：

• consistent 表示所有 client 從任意副本讀取得數(shù)據(jù)相同

• defined 表示在數(shù)據(jù)變更后臭觉，如果是 consistent睛蛛，并且 client 能夠讀取到它的所有變更

  
  
  文件 region 相關操作后的狀態(tài)

從上文的寫入數(shù)據(jù)流程可以發(fā)現(xiàn)鹦马，串行的寫數(shù)據(jù)secondary 和 primary 操作順序是一直的，如果成功忆肾，則一定是 defined荸频，如果失敗，則不一致客冈，比如 primary 寫成功了旭从，而有一個 secondary 寫失敗。同樣的道理场仲，在并行場景下和悦，寫失敗會不一致，但是成功的話只能保證一致渠缕，因為并發(fā)操作可能會導致一個文件 region 內包含來自多個 client 的寫操作鸽素，所以是 undefined.

記錄追加操作是原子的，GFS對于此操作能保證的是 至少一次成功 語義亦鳞，所以有可能會在某個副本上發(fā)生多次追加馍忽，但是 GFS 返回給 client 的 offset 都是 defined region 的起點，如果這期間在某個副本的操作被重復追加了燕差，此時它的 offset 會比其他大遭笋，后續(xù)的操作對所有副本都會從這個最大的 offset 開始追加，或者被追加到其他 chunk 上徒探，因此對于記錄追加操作而言瓦呼，如果執(zhí)行成功，文件 region 狀態(tài)是定義的但會有部分不一致测暗。

GFS 通過 Checksum 叫校驗數(shù)據(jù)是否損壞央串，比如因為宕機丟失了一些修改操作而導致失效，此時 master 會標記失效碗啄，不在返回給 client 失效的副本位置信息质和，并盡快回收。 對于已經(jīng)被 client 緩存的失效副本信息挫掏，當 client 訪問這個失效副本時侦另，一個失效副本會返回提前結束的 chunk，從而 client 能得知重新聯(lián)系 master 獲取最新的位置信息尉共。

另外褒傅，正如上文所述， master 也會和 chunkserver 通過心跳來檢測宕機袄友，并校驗數(shù)據(jù)有效性殿托，在發(fā)現(xiàn)問題后會盡快恢復。

高可用性

GFS 通過快速恢復和復制保證整個集群的高可用性剧蚣，無論 master 還是 chunkserver 都可以在數(shù)秒內重啟并恢復狀態(tài)支竹。

Chunk 復制

Chunk 會被復制到不同的機架上的不同 chunkserver旋廷，當某臺 chunkserver 失效或者其上的 chunk 已損壞時，master 會繼續(xù)復制已有的副本礼搁，保證每個 chunk 的可用性饶碘。

Master 復制

Master 服務器的狀態(tài)會被復制，它所有的操作日志馒吴、checkpoint 文件都會被復制到多臺機器扎运，對 master 服務器的狀態(tài)的任何操作都要等操作日志被復制到備份節(jié)點后本機磁盤后才會被提交生效。所以 Master 宕機后饮戳，重啟后不會有任何數(shù)據(jù)丟失豪治，如果無法重啟或磁盤故障，則可以選擇擁有全部操作日志的備份節(jié)點啟動一個新的 master 進程扯罐。由此可以保證 master 的可靠性负拟。

同時，還存在一些 shadow master歹河，在 master 宕機時能可以提供 read-only 服務掩浙，但要比 master 慢一些（通常不到 1s），它們通過讀取操作日志副本的并順序執(zhí)行方式保證其和 master 以相同的方式變更启泣。同樣的涣脚，shadow master 也會和 chunkserver 定期交互檢測 chunkserver狀態(tài)示辈、拉取數(shù)據(jù)寥茫。