6.824分佈式系統[2]-GFS案例學習

準備工做

閱讀：GFS論文

背景

• GFS是Google在2003年發出的經典論文，其做爲分佈式文件系統,實際應用在Google的MapReduce框架實現中,做爲原始數據和最終結果存儲的基礎服務。

• 爲其餘上層基礎系統好比BigTable提供服務,Hadoop中的HDFS就是其開源實現。

• 這篇文章討論了諸如一致性、容錯、網絡性能等分佈式系統工程中的經典問題，啓發了後續不少分佈式文件系統的發展。

爲何閱讀GFS的論文

• GFS使用了map/reduce的架構

• 好的性能 & 良好的並行I/O性能

• 其是一篇好的系統論文:從apps到網絡都有細節說明

• 包含分佈式的許多概念：performance, fault-tolerance, consistency

• 使用普遍（Bigtable、Spanner、Hadoop）

一致性是什麼

• 一致性是保證分佈式系統正確的條件。在有多個副本，而且併發下變得尤爲困難。

• 一致性是分佈式系統中最關鍵的問題，基本全部分佈式系統都必須討論這個問題。

• 考慮若是在一個程序中寫，可是在另外一個程序的副本中讀取的狀況。

  • 強的一致性會保證在另外一個程序中讀取到的必定是發生在最後一次寫入以後。

  • 弱的一致性沒法對其進行保證，可能會讀取到過期的數據。

• 強一致性能夠保證讀到最新的寫信息，可是對性能確定會形成影響，好的系統設計就是在這兩點中進行平衡。

理想的一致性模型

分佈式文件系統須要達成的「理想的「一致性就是多節點上面操做文件表現處理單機跟本地文件系統同樣。

• 若是兩個應用程序同時寫入同一文件怎麼辦？

  • 在單機，數據經常有一些混合的內容。即兩個程序的處理多是交錯的。

• 若是兩個應用程序同時寫入同一目錄怎麼辦

  • 在單機，使用了鎖。一個應用程序處理完畢後，再處理第二個。

• 挑戰

  • 多磁盤

  • 機器故障，操做沒法完成。

  • 網絡分區，可能不可以到達全部的機器和磁盤。

• 挑戰難以解決的緣由

  • 須要客戶端和服務器之間的通訊

  • 協議可能會變得複雜

不一樣的模型一致性考慮不一樣的權衡

+ 可串行性(serializability)
+ 順序一致性(sequential consistency)
+ 線性一致性(linearizability)
+ 單項一致性模型(entry consistency)
+ 鬆散一致性(release consistency)

GFS的目標

• GFS中節點失效就是常見的（天天1000臺機器中大約3臺失效）

• 高性能：大量

• 有效的使用網絡

設計

• master存儲（directories, files, names）

• 存儲64MB的塊，每一個塊就做爲一個linux文件。

• 每一個塊在三臺服務器上面作備份（保證可用性，負載均衡）

• 塊爲何這麼大（攤銷間接費用、減小master中的狀態大小）

• master掌握目錄的層次結構

  • 文件夾中有哪些文件

  • 對於文件，維護信息:哪些節點存儲了此文件。

  • master在內存中維護狀態（每一個塊的64字節元數據）

  • 主數據庫具備用於元數據的私有、可恢復數據庫

    • 操做日誌刷新到磁盤

    • 檢查點

    • master快速恢復

• • shadow masters略微落後於master

客戶端讀

• 發送文件名和塊索引給master

• master回覆具備該塊的服務器集

  • 回覆版本號

  • client緩存信息

• 請求塊服務器

  • 版本號（若是版本號錯誤，從新鏈接master）

primary

primary是一個副本節點中比較高級的節點。

修改現有文件

• client請求master 塊的位置 和primary的位置

• master回覆塊服務器，版本以及primary的位置

• client根據網絡拓撲計算副本鏈

• 客戶端將數據發送到第一個副本節點，而後此副本節點轉發給其餘人

• 副本節點會ack，代表數據已被接收

• client 告訴primary寫入數據

• primary分配序列號並寫入

  • primary 告訴其餘副本寫入

  • 所有成功後，回覆client

• 若是另外一個客戶端併發在同一位置寫入數據，該怎麼辦？

  • c1 與c2 可能會交替的寫入，結果是一致性的，可是不能保證的。

添加文件

• client 請求master 塊的位置。

• client將數據發送給副本，可是沒有指定偏移量。

• 當數據在全部的塊服務器上後，client聯繫primary

• primary分配序列號

• primary檢查是否可以恰好添加到一個塊中

• primary爲添加選擇偏移量，進行添加

• 轉發請求到其餘副本

• 失敗後進行重試

  • 不能使用下一個可用偏移量，由於在失敗的節點中可能會有空字節。

• GFS支持原子操做，保證至少一次添加，主Chunk服務器選擇記錄須要添加到的文件位置，而後發送給其餘副本。

• 若是和一個副本的聯繫失敗，那麼主Chunk服務器會告訴客戶端重試，若是重試成功，有些副本會出現追加兩次的狀況(由於這個副本追加成功兩次)。

• 當GFS要去填塞chunk的邊緣時，若是追加操做跨越chunk的邊緣，那麼文件也可能存在空洞。

失敗狀況

塊服務器的失敗會引發client重試。
master失敗會致使GFS不可用，shadow master會服務只讀的狀態。可能會返回過期的數據。

總結

性能，容錯，一致性（performance, fault-tolerance, consistency）的案例研究

• 優點

  • 大量的順序讀取和寫入

  • 追加文件高效

  • 大的吞吐量

  • 數據容錯（3個副本）

• 劣勢

  • master服務器的容錯

  • 小文件（master服務器的瓶頸）

  • client會看到過期的數據（弱的一致性）

  • 追加可能重複

GFS案例問答

爲何添加數據執行至少一次"at-least-once"語義，而不是精準的一次？

實現困難，primary須要保留重複的狀態。狀態必須在服務器之間複製，以便若是primary出現故障, 此信息不會丟失。

應用程序如何知道塊的哪些是有數據的塊，哪些是重複的數據

能夠在有效記錄的開頭作標識（magic number）就能夠知道有數據的塊。
檢測重複的塊能夠爲每一個記錄都有一個特殊的UID標識。

論文中提到的reference counts是什麼意思

• 他們是實現快照copy-on-write（寫時複製）的一部分。

• 當GFS建立快照時，它不復制塊，而是增長每一個塊的引用計數器。這使得建立快照的成本不高。 若是客戶端寫入了一個塊，而且主服務器注意到引用計數大於1，此時，主服務器會首先建立一個副本，以便客戶端能夠更新副本（而不是快照的一部分）。

參考資料

• my blog