[MOOCS][Golang]MIT6_824 Distributed Systems Week2(Lec2/Lab2B)

June 5th, 2015

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.Get與 me來判別)
  • 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的作業，整個作業還沒寫完，會持續更新相關的資料．

##參考文章:

Buy Me A Coffee

Evan

Attitude is everything