wiki:lustre_failover

Version 11 (modified by chris, 16 years ago) (diff)

--

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
    4. DRBD切換 primary 為 secondary)
  1. mount 備援的 OSS/OST 到 備援的 Meta-data server (MGS/MDT) 上
    1. DRBD切換 secondary 為 primary
    2. Client端 mount 備援的 Lustre File System