谷歌GFS論文筆記

• • 前言
  • master
  • chunkserver
  • 一致性模型
  • • data integrity
  • 下線
  • mmap讀寫鎖
  • • FAQ
  • 參考鏈接

---

前言

本篇文章主要講解谷歌經典論文The Google File System，它構建在廉價的普通pc服務器上，并且可以自動容災容錯。其對于整個存儲界具有里程碑的意義。

master

• GFS 為了簡化設計，在整個系統中只有一個 master 進行管理。Master 不提供讀寫操作，它只會告訴 client，它所請求操作的文件在哪個 chunkserver 上，然后 client 會根據 master 提供的信息，與對應的 chunkserver 進行通信。
  • 為了保證同一時刻只有一臺Master，GFS使用Chubby進行選主。
• master保存所有的元數據，并且以最快的時間可以把服務起來為目的。這里的元數據主要指：
  • chunk的元數據（全局唯一ID，版本號，每個副本對應的chunkserver，引用計數）
  • 文件及chunk命名空間，文件到chunk之間的映射，的由于GFS一般都是大文件，所以一般Master的內存不會時瓶頸。
• master只有一個節點，如果這個節點掛了，會在別的機器再起一個服務，同時修改DNS
  • 有一些shadow節點，在master生成原數據的時候，也會把那些原數據同步過來，但是會比master節點慢一點，我理解是如果master掛掉了，可以快速的再起一個。

除了負責管理chunk的元數據信息并和client和chunkserver通信，Master還負責以下事情：

負載均衡：考慮failure domain，負載均衡等因素，GFS會將chunk的不同副本放在不同的chunkserver上：

當Master新創建一個副本的時候，Master考慮所有chunk的繁忙程度以及當前承載chunk的數量，并且考慮failure domain，將chunk放在合適的chunkserver上

當chunkserver由于某種原因下線，chunk的副本少于某種數量，Master會負責重新復制一個chunk副本，這個也會根據當前chunk的繁忙程度以及副本修復的緊急程度來判斷，并且會限制副本拷貝的速率

Master會定期掃描副本分布情況，重新進行副本分配

垃圾回收：GFS采用延時回收的機制，當一個文件被刪除后，物理存儲并不會立即刪除，而是會等待一段時間。并且系統對chunk維護了版本號，過期的chunk可以通過版本號檢測出來。

快照：GFS通過COW的方式生成快照，只有客戶端修改chunk的時候，才需要在chunkServer中拷貝chunk數據生成新的chunk

chunkserver

ChunkServer中每個chunk為64M，相對較大，“append-at-least-once semantics”簡化了chunkServer的復雜程度。對于每個chunk，必須將所有的副本全部寫入成功，才視為寫入成功。下面我們主要介紹追加流程：

客戶端向master請求chunk所在的chunkserver，這里面包含Master對主chunkserver的lease分配

master返回chunk副本信息給客戶端，客戶端負責緩存

客戶端將追加請求發送到每一個副本（數據流在三副本內部鏈式傳遞，從而充分利用網絡帶寬），每一個chunkserver會在內部的LRU中緩存數據

當所有的副本都收到了數據，客戶端發起寫請求給主chunkserver，由于主副本可能收到多個客氣戶端對同一個chunk的并發追加操作，主副本將確定操作順序

主副本將所有的請求發送給備副本，備副本會根據主副本的順序執行寫操作

備副本寫入成功之后回復主副本

主副本應答客戶端，如果出錯，客戶端負責重試

一致性模型

• 無論數據是單點寫但是并發寫，只要寫成功了，都是原子性，一致性的，如果出錯則是不一致的。
• GFG主要是為了追加（append）而不是改寫（overwrite）而設計的。這么做的原因一方面是實現起來簡單，一致性模型也簡單，另一方面是上層的應用Bigtable主要就是用追加寫，GFS對Record append的保證是defined but interspersed with inconsistent，注意以下幾點：
  • GFS的追加寫只保證“同一紀錄至少成功寫入一次”，有可能一些副本出現了多條記錄，而失敗的副本出現了“padding”記錄。所以上層應用需要保證正確性，Bigtable通過事務日志和子表記錄sstable元數據的方式保證正確性
  • 由于GFS支持并發追加，多個客戶端的順序是無法保證的，客戶端的連續追加記錄也有可能被其他客戶端打斷

data integrity

Master使用租約機制，將chunk的寫操作授權給chunkserver，擁有租約的chunk稱為主ChunkServer。一般來講，租約的有效期比較長，如60秒，只要美歐出現異常，主ChunkServer可以不斷的向Master請求延長租約。GFS對每個chunk維護了一個版本好，每次給chunk授權的或續約的時候chunk版本好會加1，因此如果某個從ChunkServer因為某種故障下線了，再上線后Master發現其上的chunk的版本號過低，會進行垃圾回收。

append的時候由主ChunkServer確定寫入的offset，由于append-at-least-once semantics，可能從副本上會有很多padding記錄

GFS的典型應用場景是追加寫而不是覆蓋寫（6.3.3介紹了兩者的比較），為了追求極致的性能，其寫保證是append-at-least-once semantics，可能出現的場景是，因為重試等場景，某些chunkserver對某個chunk追加寫了多次，因此，上層業務為了應對GFS的追加寫造成的inconsistency做出了很多努力，如自己增加校驗，自己在確保寫入成功之后rename文件，在寫入成功一段之后增加checkpoint，包括checksum等

chunk對自己每個文件都有checksum，會隨著讀發給leaderchunk, 如果發現不一致，就會報錯

下線

GFS的chunk分配在哪個ChunkServer是由Master動態根據當前整個系統的負載決定的。因此比ceph打的更散，根據Section 6.2.5的描述，kill掉兩個ChunkServer之后，就有266個chunk成為單點了。單點chunk在系統修復中擁有搞優先級。

根據GFS的IO流程圖Figure 2，任何的副本寫入不成功，都會導致客戶端認為當前寫入操作失敗，并進行重試，如果是因為某種原因ChunkServer故障了，這這時其上的Chunk處于不可服務的狀態。6.2.2詳述了ChunkServer寫入失敗后恢復的速度。

to minimize the impact of failures on running applications, we boost the priority of any chunk that is blocking client progress.

故障ChunkServer中正在被Client訪問的chunk擁有高的修復優先級。

mmap讀寫鎖

論文提到了，如果磁盤有page in操作，會持有讀鎖，這時mmap操作想要持有的寫鎖會被阻塞住。GFS的解決辦法是使用pread代替mmap，但是這樣會額外代理一次pread的拷貝開銷。

涉及到的名詞有

page-in/page-out：When pages are written to disk, the event is called a page-out, and when pages are returned to physical memory, the event is called a page-in

Monitoring Virtual Memory with vmstat 把vmstat也可以一起看看

cache/buffer

mmap/pread比較，開銷

Linux Memory Mapped System Call Performance

Linux對內存的管理, 以及page fault的概念

FAQ

單點master可靠嗎？

• google后來也知道這東西不可靠，比如一個宕機了還要啟動另一個為主，還要換DNS，這里面有手動的成分
• 后來谷歌把master換成集群了

參考鏈接

GFS 閱讀筆記

6.824FAQ 6.824的每一個地方都值得仔細看看

7.深入淺出 GFS（四）

3.8 GFS的一致性6.824的課上是如何講GFS如何處理一致性問題的，也就是append-at-least-once semantics

總結

以上是生活随笔為你收集整理的谷歌GFS论文笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。