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

May 20th, 2015

##前言:

本週進入第二個禮拜，開始有一些分散式系統的備份與替換的問題還有論文． 加油吧!!

MIT 6.824 分散式系統 系列文章

6.824: Distributed Systems

##第二週課程:

##關於筆記 Primary/Backup Replication (Remus)

盡量用理解後的中文紀錄，原始筆記在這裡:

  • 關於容錯(Fault Tolerance):
    • 希望能繼續服務儘管有問題發生． 特性如下:
      • 可見性: 即使有問題發生，也希望服務能夠繼續．
      • 正確性: 希望發生問題的時候，服務也跟單機一樣（無錯誤時)正確．
    • 核心想法: 備份，透過兩個或是以上的備份伺服器來預防任何的問題產生．
      • 重要問題:
        • 備份機的狀態?
        • 工作機的狀態如何轉移?
        • 何時要切開與備份機的連接?
        • 異常發生在切開之後？
        • 如何修復與重新連接備份機?
    • 兩個關於備份機的重要動作:
      • State Transfer (狀態轉移)
      • Replicated State Machine: (備份狀態機)

##論文 Remus: High Availability via Asynchronous Virtual Machine Replication

這裏有網頁版本

Remus 的系統特色:

  • 整個系統備份
  • 對於Application與Client而言是透明的．
  • 當運行成功的時候，備份與切換機器就運作順暢

image

圖片元素解釋:

  • Primary: 具有資料，會執行OS與App，並且負責跟Client溝通．
  • Backup: 只有資料，但是不執行OS與App．只有跑一些Remus的code

流程簡介：

  • (1) Primary 跑完 Completed Execution (E1)，並且先不回傳E1結果回client．
  • (2) Primary把結果備份到Backup (背景執行)
  • (3) Backup同步所有目前資料跟Primary一樣．
  • (4) Primary 執行Speculative Exection (E2)，並且先不回傳給client
  • (5) Backup 複製所有結果
  • (6) Primary放出E1結果
  • (7) Backup 把結果存入RAM/Disk.

Remus 特性與檢討:

Remus系統的估計

  • 速度為單機系統的1/2~1/4
  • Check point時間過久
  • 為了要能夠與client溝通，保留結果的時間不能太久

缺點

  • 速度不快:
    • 由於每個Exection都必須等待Backup 複製好相關資料。
    • Check point 至少等花上100ms

如何改善:

  • 減少主機儲存資料
  • 減少狀態的資料量，或是優化資料格式
  • 試著傳送指令而非狀態

##關於Lab2 Part A:ViewService

這一篇有點困難，所以稍微做點筆記:

###題目解釋: 主要要implement 一個具有faul-toerant的key/values services- Viewservice．這個Service有以下的幾個功能:

  • 監控 Primary (指的是原始service) 與 Backup(備份用的Service)是否是正常工作．
  • 正常而言，如果Primary壞了，會自動地把Backup promoted成 primary．此時如果有空的server就會拉近來變成新的Backup．
  • 當新的Primary與Backup上線後，Primary還有一個工作：
    • 備份所有資料庫給Backup
    • 所有的command set傳給Backup去確保Primary與Backup state machine是一致的．

關於ViewService的Primary/Backup轉移範例如下:

  • Primary (Server 1: S1) 發生問題，而Client 送給 S1 一個需求OP1．
  • Primary 轉發OP1 給 Backup(Server 2: S2)， 這個動作是之前提到為了同步的關係．S1會把每個收到的指令透過forward轉給S2
  • 但是由於S2已經被promote成新的Primary．而這時尚未有新的Backup上線．
  • S2 回傳一個Error 給 S1 並且Forward給 Client 說已經沒有Backup Server．
  • ViewService會把S2設定成新的Primary target address 並且把新的指令都直接轉給 S2.

###開始解答:

打開viewsource這個資料夾，主要有幾個需要注意的:

  • server.go :主要code的部分．裡面主要有以下幾個部分需要思考:
    • Ping(): 主要負責的是接受Server的Ping，在其中包含著Server本身的資訊與現在資料的View number
    • Get(): 取得資料
    • Tick(): 這個也就是所謂的定期Heartbeat 也可以說經過一段時間會自動啟動的timer，如果有任何Server掛掉，必須要在這裡處理．
  • test_test.go:本次作業的測試程式，需要好好思考其中代表的涵意

####進階與Server有關的邏輯與含意

這邊可以參考它提供的圖片: image

在這裡也整理一下幾個需要注意的地方:

  • 其中Viewnum代表的涵意：
    • Viewnum代表Server所直接到的一個state或是第幾個View．他應該是一個會慢慢增加的部分．
  • 如何判定Server已經掛了:
    • Viewnum忽然變成0，如果原先的 viewnum已經>0，但是在某些狀況下忽然收到viewnum=0．那麼就是代表Server已經掛掉又重新執行．
    • 每一次Server的Ping，需要紀錄當時的時間．然後在tick裡面去檢查 DeadPings * PingInterval來確認Server是否掛了，但是某些狀況下可以當作是Server 繼續活著 (請看Ack)．
  • 當Server掛掉的處理流程:
    • 如果是Primary掛掉，檢查是否有Backup．如果Backup已經正常在運作了，就把他切換成Primary． 並且把第三台主機當作Backup．
    • 如果是Backup掛掉，一樣會檢查是否有第三台主機，並且把它掛起來．
  • 回應(acknowledgement):
    • 在這裏一次的Get()與 Ping()被視為是一次的回應．並且注意Ping()的viewnum必須要大於0，才能表示他已經開始運作．
    • 如果Primary主機有做Get()，但是卻沒有回應Ping()，在這次的處理必須等待而不能直接把主機關閉．(倒數第二個測試)
  • 伺服器初始化(Initialization):
    • 身為Backup主機，我們必須要確認Backup已經上線了(Online)，唯一的方式就是確保他已經有Ping()一個數值超過0的viewnum
    • 如果Backup沒有初始化，是不能夠當作Primary的(最後的測試)

####心得與改進:

透過這些test case來開始這部分的作業，其實相當的有趣．一開始最令人困擾的是三個function不知道要拿來做什麼．其實題目不算是相當的清楚來解釋每一個步驟． 只能不斷地透過go test一步步來瞭解到底每一個流程，每一個原則會是什麼．這邊算是比較有趣也比較好玩的部分．

此外，由於流程裡要代表的狀態相當的多．一下子要確認主機是否有ack，一下又要確認有沒有init．簡單的做法可以透過許多個flag來代表個別的狀態． 當然，也可以使用狀態機(state machine)的方式方式來開發這次的作業． 只是要有可能會打掉重練的打算．

幾種重練的做法:

寫完作業後，對於論文Remus: High Availability via Asynchronous Virtual Machine Replication也比較容易了解了．

##參考文章:

Buy Me A Coffee

Evan

Attitude is everything