DRDB 和 NFS：故障轉移恢復期間的 NFS 停機時間

我對 DRBD 和 NFS 還很陌生，並且正在測試一個帶有心跳的 DRDB 伺服器以用於我們公司的 NFS 共享。

整個設置執行良好，NFS 狀態目錄與實際共享一起在 DRDB 共享上執行。

我遇到的問題來自我正在測試的故障轉移場景。在故障轉移場景中，我創建了一個問題，即在 node1 上禁用網路連接（ifconfig eth0 down）。故障轉移非常棒，大約在 5 秒內完成了它的工作，但是當我恢復它時（ifconfig eth0 啟動，如果它停止，則服務心跳啟動）它需要 3-5 分鐘才能恢復，在此期間 NFS共享不可用。

在 Web 環境中，這 3-5 分鐘對於停機時間非常重要。這是正常的嗎？我究竟做錯了什麼？

我在下面粘貼了我們的 drbd.conf 文件。

resource r0 {
protocol C;
startup {
   degr-wfc-timeout 60;    # 1 minute.
 }
 disk {
   on-io-error   detach;
 }
 net {
 }
 syncer {
   rate 10M;
   al-extents 257;
 }
on tsa-dev-nfstest1 {                # ** EDIT ** the hostname of server 1 (un
  device     /dev/drbd0;        #
  disk       /dev/sdc1;         # ** EDIT ** data partition on server 1
  address    10.61.2.176:7788; # ** EDIT ** IP address on server 1
  meta-disk  /dev/sdb1[0];      # ** EDIT ** 128MB partition for DRBD on serve
 }
on tsa-dev-nfstest2 {                # ** EDIT ** the hostname of server 2 (un
  device    /dev/drbd0;         #
  disk      /dev/sdc1;          # ** EDIT ** data partition on server 2
  address   10.61.2.177:7788;  # ** EDIT ** IP address on server 2
  meta-disk /dev/sdb1[0];       # ** EDIT ** 128MB partition for DRBD on serve
 }
}

您的心跳資源組是否包含 NFS 服務的邏輯 IP？

它應該是您最後一個“上升”的資源和第一個“下降”的資源。您的客戶端應使用此 IP 訪問 NFS 服務。

如果您定義了 IP，您可能會嘗試為 IPAddr 使用其他資源類型（據我所知是 IPAddr2）。那個在 IP 堆棧上的行為有點不同。

基本上這兩種類型都應該在 IP 出現後進行 arp-broadcast - 以確保連接的路由器和交換機重新學習它們的 MAC 表，以便他們知道在故障轉移發生後將數據包轉發到哪裡。

在某些 NFS 實現中，您還應該顯式地解析您已經連接的客戶端。為此，您還必須將連接的客戶端數據鏡像到您的備用節點。

引用自：https://serverfault.com/questions/290423