http://i.stack.imgur.com/MUtmL.png

(圖片: FDS的優化示意圖,由這裡來的)

##前言:

到了第二個禮拜,其實卡了很久在Lab2b裡面.主要不是因為要判斷的case太多,而是希望把每次的test case找到在論文中的理由或是整個學術上的依據.

MIT 6.824 分散式系統 系列文章

6.824: Distributed Systems

##論文-Flat Datacenter Storage

這是微軟在2012發表的新的分散式計算系統FDS,號稱可以在60秒處理141GB的資料,打敗了當初Yahoo所創下的紀錄.

FDS組成

FDS為了要達到速度快,把繁瑣的檔案系統移除.整個組成相當的簡單 (Blob 與 Tract)

Blob:

Blob 是FDS系統裡面的構成元件.每一個Blob由數個Tract所組成的.

  • 一個Blob 可以包含若干個Tract
  • 一個Blob 擁有一個唯一的GUID

其中Blob 提供以下的API:

  • CreateBlob
  • OpenBlob
  • DeleteBlob
  • CloeBlob

Tract:

FDS裡面最基本的元素.

  • Tract的檔案大小是固定的(預設是8MB)

所有的Tracts 是透過 TractServer來管理,以下為Tract 相關的API:

  • GetBlobSize
  • ExtendBlobSize
  • WriteTract
  • ReadTract
  • WriteTract
  • GetSimultaneousLimit

實際運作上:

  • Blob 並不需要放在同一台電腦上
  • 為了達到速度快,可以把tract放在不同的儲存媒體上.達到類似Raid-0的效果.
  • 用來索引各個tract位置的是TLT(Tract Locator Table)而Metadata Server就是管理TLT的伺服器.

這一篇對於組成的部分有更詳細的解釋

FDS的備份

##第二週下半課程: ##關於Lab2 Part B:he primary/backup key/value service

這一次的作業相當的有趣,由於上一次要識做一個Server與Client間的分派者或是說控制者的角色(稱為Viewserver). 而這次要做的就是另外兩個角色 PBServer 與 Client.

###幾個注意地方:

以下列出幾個比較基礎的地方:

  • PBServer 與 Client 與 ViewServer三方的溝通都必須透過RPC call
  • RPC call rpcname必須注意是要Class.Api. 舉例而言: ViewServer.Ping
  • Client 每個動作都需要先去問ViewServer目前的primary

###開始流程:

  • 完成Server的Get()Put()Ping() (Ping必須在Tick裡面)

  • 每個transaction 必須要透過 primary 把結果傳給 backup ~
  • primary/backup要有傳遞備份資料與互相溝通的RPC 要新增不少個
  • Server需要判別自己的角色是primary或是backup (可以使用 ViewServer.Getme來判別)
  • Server與Client溝通原則:
    • 每一個Client的command,在得到reply == OK 前,必須要不斷地送.
    • 相反的,Server必須要遵循at-most-once原則,要過濾掉重複的request
    • client 不能在每次Get/Put去跟ViewServer詢問目前誰是primary,除非你認為primary 已經死了.
      • 時間內沒回覆?
  • 角色的準則裡面:
    • Primary:
    • Backup:
      • 不能直接回覆client需求,而要回復錯誤

Lab2A 的Client (也就是身為 PBServer的角色) 需要知道自己的所扮演的角色 (Primary/Backup)

  • Get Arg 增加欄位判別需求是來自 server/client 是 primary 才需要ack back
  • 這樣可以避免寫Lab2B 的時候,造成Lab2A的Go test failed.

有趣的思維是:

  • 你必須同時考慮三個角色 (Client/PbServer/Viewserver) 交互關係
  • 必須確保 Lab2A / Lab2B 的測試不能有誤… (相互干擾是一定會的,寫完要回頭看……回頭測試)

資料的同步:

  • Backup剛起來的時候(或是每個一段時間) 需要從Primary備份所有資料庫
  • 每一次的資料變動 (在這個例子裡面是 Put發生的時候),需要馬上把資料傳給Backup

TestBasicFail 經驗分享

你需要完成以下:

image

  1. Remus的Fig1 流程(參考以上):
    1. 定期需要從 Primary -> Backup 所有資料庫 (自行新增RPC)
    2. 每個command 在Primary 完成後,需要先把結果傳給Backup,然後才傳給Client
  2. PBServer 必須知道自己是 Primary 還是 Backup 並且做相關的 Init
  3. Client需要做Repease Request 直到結果是正確的.(注意 每次RPC request 最好有間隔)

你還不需要做:

  1. Hash Put
  2. Repeat AtOnce (後面的測試會有)

TestAtMostOnce passed, 經驗分享:

  1. Client 需要不斷的send request 如果沒有收到result 或是收到空的result
  2. Server 需要過濾重複的指令,並且傳送之前的結果.
    • 所以你需要記住之前的指令與參數確保指令重複.
    • 需要儲存上一次結果.重複指令就回傳
    • 此外,對於重複指令不需要傳到Backup
  3. 忘了提一下,關於Hash的部分演算法是: Hash_Value = hash(Previous_Value_String + Currently_Value_String )

TestFailPut/TestConcurrentSame/TestConcurrentSameUnreliable passed, 經驗分享:

  1. 重點部分, 當client 與primary 溝通,如果發現疑似primary掛掉的狀態.需要跟viewserver詢問新的primary.

心得:

對於FDS的理解還算粗淺,希望隨著課程的了解能夠瞭解更多的資料.而Lab2的作業,整個作業還沒寫完,會持續更新相關的資料.

##參考文章:


Evan

Attitude is everything