Lustre's Failover Mechanism

• 在 Lustre 中，並沒有像 GPFS 本身就有提供 replication data 寫入的機制，因此必須搭配 DRBD 來達到 replication data 的機制， 並且使用 Heartbeat 來監控電腦是否當機、斷電、網路是否可以連線。一旦發現錯誤，可即時通知 Lustre 的相關 daemon 啟動所謂的 failnode，自動將資料的讀寫轉移到 failnode 上的 OST。
  
  
• 這個部分首先要釐清的是 heartbeat 如何結合 lustre ，是如何告知 lustre 的 daemon 來觸發備援切換的機制。
  
  • 研究結果發現 heartbeat 可採用 ping 或是接 console port (serial port) 的方式來達到偵測指定的節點是否為 alive 的狀態.
    一旦發現指定的節點 failed ，就可以啟動位於/etc/services 底下存在的服務，例如: httpd。
  • 但是問題在於 lustre 的 meta-data server (MGS/MDT)。假設 OSS-1 與 OSS-2 是互相備援的 storage 節點，一旦 OSS-1 掛點，
    那麼根據 heartbeat 設定的結果，OSS-2 就會啟動成為 primary node，此時按照順序來說，OSS-1 應該要先 umount 它的 OST，接著 OSS-2 再 mount 備援的 OST。
  • 這裡會發生的第一個問題是 lustre 檔案系統本身就是仰賴網路連結，一旦網路掛了 (heartbeat ping 不到)，那麼 OSS-1 umount 它的 OST 時，
    meta-data server 就無法馬上得知其底下的OSTs 已經 umount 了，對於 lustre client 來說，它所看到的資訊就會是不正確的。
  • 第二個問題，假設第一個問題解決(譬如說:使用 console port 來做 heartbeat 的偵測)，同樣地，假設 heartbeat 偵測到 OSS-1 故障，
    OSS-1 先 umount，OSS-2 再 mount 備援的 OST，此時 lustre client 若下達 df -h 指令，就會當掉，這是 lustre 的 bug 或是可以說是 lustre 的缺陷。
    client 端無法動態 retrieve Meta-data server 的改變。
    
    
• 針對上述問題，必須要有更好的 framework 來設計整個 lustre 的架構，所有的 primary MGS, primary OSS 都要和 secondary MGS, secondary OSS 分開。
  不能共用同一個 Metadata server, 但是這又會衍伸出新的問題，譬如說 primary OSS-1 失效，secondary 的 meta-data server 與 OSS 啟動，
  那麼 lustre client 必須先將故障的 lustre storage umount，接著再 mount 備援的 lustre storage，這部分有辦法自動執行嗎，當整個 lustre storage pool 很大，
  而且 lustre client 數量很多時，有無更加有效率可以自動切換的方式呢?

• 要做到自動切換, 光靠 heartbeat 與 DRBD 是沒有辦法的. 因為 client 需要先將舊的(failed)的檔案系統 umount, 再 mount 上備援的檔案系統,
  這個步驟需要先手動設定好(甚至使用自訂的程式)才有可能讓系統自動執行, 姑且稱之為 semi-auto failover 吧.
  目前備援機制的流程大致上如下:
  
  1. heartbeat 偵測到 primary 系統故障
  2. Client端 umount 故障的 Lustre File System
  3. heartbeat 啟動預設的服務 (在 heartbeat 的設定檔中, 指定啟動 /etc/services/ 底下的特定程式)
     1. umount 故障的 OSS/OST
     2. DRBD切換 primary 為 secondary)
     3. mount 備援的 OSS/OST 到 備援的 Meta-data server (MGS/MDT) 上
     4. DRBD切換 secondary 為 primary
  4. Client端 mount 備援的 Lustre File System