谷歌GFS論文筆記

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

---

前言

本篇文章主要講解谷歌經(jīng)典論文The Google File System，它構(gòu)建在廉價(jià)的普通pc服務(wù)器上，并且可以自動容災(zāi)容錯(cuò)。其對于整個(gè)存儲界具有里程碑的意義。

master

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

除了負(fù)責(zé)管理chunk的元數(shù)據(jù)信息并和client和chunkserver通信，Master還負(fù)責(zé)以下事情：

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

當(dāng)Master新創(chuàng)建一個(gè)副本的時(shí)候，Master考慮所有chunk的繁忙程度以及當(dāng)前承載chunk的數(shù)量，并且考慮failure domain，將chunk放在合適的chunkserver上

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

Master會定期掃描副本分布情況，重新進(jìn)行副本分配

垃圾回收：GFS采用延時(shí)回收的機(jī)制，當(dāng)一個(gè)文件被刪除后，物理存儲并不會立即刪除，而是會等待一段時(shí)間。并且系統(tǒng)對chunk維護(hù)了版本號，過期的chunk可以通過版本號檢測出來。

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

chunkserver

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

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

master返回chunk副本信息給客戶端，客戶端負(fù)責(zé)緩存

客戶端將追加請求發(fā)送到每一個(gè)副本（數(shù)據(jù)流在三副本內(nèi)部鏈?zhǔn)絺鬟f，從而充分利用網(wǎng)絡(luò)帶寬），每一個(gè)chunkserver會在內(nèi)部的LRU中緩存數(shù)據(jù)

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

主副本將所有的請求發(fā)送給備副本，備副本會根據(jù)主副本的順序執(zhí)行寫操作

備副本寫入成功之后回復(fù)主副本

主副本應(yīng)答客戶端，如果出錯(cuò)，客戶端負(fù)責(zé)重試

一致性模型

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

data integrity

Master使用租約機(jī)制，將chunk的寫操作授權(quán)給chunkserver，擁有租約的chunk稱為主ChunkServer。一般來講，租約的有效期比較長，如60秒，只要美歐出現(xiàn)異常，主ChunkServer可以不斷的向Master請求延長租約。GFS對每個(gè)chunk維護(hù)了一個(gè)版本好，每次給chunk授權(quán)的或續(xù)約的時(shí)候chunk版本好會加1，因此如果某個(gè)從ChunkServer因?yàn)槟撤N故障下線了，再上線后Master發(fā)現(xiàn)其上的chunk的版本號過低，會進(jìn)行垃圾回收。

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

GFS的典型應(yīng)用場景是追加寫而不是覆蓋寫（6.3.3介紹了兩者的比較），為了追求極致的性能，其寫保證是append-at-least-once semantics，可能出現(xiàn)的場景是，因?yàn)橹卦嚨葓鼍?#xff0c;某些chunkserver對某個(gè)chunk追加寫了多次，因此，上層業(yè)務(wù)為了應(yīng)對GFS的追加寫造成的inconsistency做出了很多努力，如自己增加校驗(yàn)，自己在確保寫入成功之后rename文件，在寫入成功一段之后增加checkpoint，包括checksum等

chunk對自己每個(gè)文件都有checksum，會隨著讀發(fā)給leaderchunk, 如果發(fā)現(xiàn)不一致，就會報(bào)錯(cuò)

下線

GFS的chunk分配在哪個(gè)ChunkServer是由Master動態(tài)根據(jù)當(dāng)前整個(gè)系統(tǒng)的負(fù)載決定的。因此比ceph打的更散，根據(jù)Section 6.2.5的描述，kill掉兩個(gè)ChunkServer之后，就有266個(gè)chunk成為單點(diǎn)了。單點(diǎn)chunk在系統(tǒng)修復(fù)中擁有搞優(yōu)先級。

根據(jù)GFS的IO流程圖Figure 2，任何的副本寫入不成功，都會導(dǎo)致客戶端認(rèn)為當(dāng)前寫入操作失敗，并進(jìn)行重試，如果是因?yàn)槟撤N原因ChunkServer故障了，這這時(shí)其上的Chunk處于不可服務(wù)的狀態(tài)。6.2.2詳述了ChunkServer寫入失敗后恢復(fù)的速度。

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

故障ChunkServer中正在被Client訪問的chunk擁有高的修復(fù)優(yōu)先級。

mmap讀寫鎖

論文提到了，如果磁盤有page in操作，會持有讀鎖，這時(shí)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對內(nèi)存的管理, 以及page fault的概念

FAQ

單點(diǎn)master可靠嗎？

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

參考鏈接

GFS 閱讀筆記

6.824FAQ 6.824的每一個(gè)地方都值得仔細(xì)看看

7.深入淺出 GFS（四）

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。