Google File System

第三課的準備是閱讀論文GFS。該論文是分散式系統中經典論文之一。

讀完做一點小總結。

GFS的feature

1. 非POXIS介面API，支援對檔案和資料夾的建立，讀，寫，增加，重新命名和建立快照操作。

2. 有多個商用Linux機器做節點，稱為chunk server，資料存放在chunk server上。

3. 有一個master節點，用於傳送控制指令。

4. client通過呼叫API，和master做控制命令交換，和check server 做資料交換。

5. 對Append操作友好，對小檔案隨機讀寫不友好。

6. 重新命名和Recore Append是原子操作。

7. 讀操作可能返回不一致資料。

GFS的一些實現細節

1. 讀寫最小單位是所謂的64M大小的chunk。chunk存放在chunk server上。

2. 每個chunk 用64位唯一的handle表示。

3. master節點存放控制資訊/chunk位置在記憶體中，同時持久化operation log用於recover。

4. master節點以一定策略決定chunk 的replacement，保證chunk均勻分佈。

5. chunk server在restart的時候傳送其本機上chunk資訊。

6. chunk server隨時可能宕機，master節點通過heartbeat訊息報活。

7. 每個chunk有三份拷貝。其中一個稱為primary。對chunk資料的更改順序，統一由primary統籌，然後apply到其他拷貝。

8 每個chunk又分為64KB的block，每個block包含checksum，用於資料完整性檢查。

GFS的讀操作

1. client 把檔名和要讀取的byte位移，通過API，對映成該檔案中的chunk 序號。

2. client 傳送包含檔名和chunk序號的請求資訊給master，master返回chunk handle和所有拷貝所在的位置。

3. client會cache master返回的資訊。

4. client傳送請求到其中一個拷貝，根據策略，可能是離client較近的一個。

5. 拷貝所在的chunk server根據chunk handle和offset返回資料給client。

6. 接下來的讀操作無需master介入，除非cache失效或者檔案重新開啟。

GFS的寫操作

寫操作很類似2PC。

1. client 詢問master 某chunk的primary 位置，以及其他replica位置。

2. master 返回primary和sencondary replica的位置，圖中的A，B和C。client會cache這些資訊，除非與primary失聯，或者primary告知自己以及失去primary地位。

3. client傳送所有要寫的資料到A，B和C。這些chunk server會暫存這些資料，直到被下面的步驟用到或者過期。注意這時候寫操作依然進行中，並沒有生效。

4. 當A，B和C表示暫存完成，client傳送正式的寫請求給primary，告知暫存完成。primary於是給其收到的所有資料更改賦予一個序列號，然後依次應用到本地拷貝。

5. primary 傳送寫請求到其他拷貝，並要求按同樣序列應用到各自拷貝中。

6. secondary拷貝向primary表示，應用成功。

7. primary向client表示，寫完成。

在遇到寫錯誤時，3）-7）可能會多次重試。失敗後將重新從1）開始。

寫操作是不安全的。如果有多個client同時寫同一個地方，該區域將變成“Consistent but undefined”，就是說所有client最終看到同樣的結果，但是資料亂了。

但是所謂的“Record Append”是安全的。在Record Append中，client僅僅指明這是一個Append操作，並不指明offset。GFS選擇一個offset寫入資料，並返回該offset給client。

和普通寫一樣，client把資料推送到所有的拷貝，然後傳送寫請求給primary。

primary 檢查 append是否會使當前chunk超過最大64M限制。如果是，當前chunk pad到最大size，然後告知其他拷貝做同樣操作，並回復client，表示操作應在下一個chunk重試。

如果並沒有超過64M限制，primary 把資料放入拷貝，並告知其他拷貝，資料要寫在“exact the same offset as primary”，也就是說，必須和我primary保持絕對一致的offset。

如果上面任意一步錯誤，client將重試。這種行為可能造成拷貝之間並不是完全一致。chunk中可能包含record中的一些重複資料。GFS在這裡通過重試能保證的是，資料存在所有拷貝中的某些chunk中，有同樣的offset，並且只有當所有步驟完成後，primary返回的offset被認為是該Record的“defined start”。這中間可能包含無定義的，不一致資訊。

而client在讀取的時候，可以通過checksum來判斷資料的重複性和一致性。