drbd理論

DRBD理論

 

DRBD(Distributed Replicated Block Device),DRBD 號稱是 「網絡 RAID」,開源軟件,由

LINBIT 公司開發。

 

DRBD工做原理：

DRBD是一種塊設備,能夠被用於高可用(HA)之中.他有內核模塊和相關程序而組成,經過網絡通訊來同步鏡像整個設備，它相似於一個網絡(磁盤陣列)RAID-1功能。

當你將數據寫入本地 文件系統時（DRBD Primary）,數據還將會被髮送到網絡中另外一臺主機上（DRBD Secondary）.以相同的形式記錄在一個文件系統中。本地(主節點)與遠程主機(備節點)的數據能夠保證明時同步.當本地系統出現故障時,遠程主機上還會保留有一份相同的數據,能夠繼續使用.在高可用(HA)中使用DRBD功能,能夠代替使用一個共享盤陣。

由於數據同時存在於本地主機和遠程主機上,切換時,遠程主機只要使用它上面的那份備份數據,就能夠繼續進行服務了。

  每一個設備（drbd 提供了不止一個設備）都有一個狀態，多是‘主’狀態或‘從’狀態。在主節點上，應用程序應能運行和訪問drbd設備（/dev/drbd*）。每次寫入都會發往本地磁盤設備和從節點設備中。從節點只能簡單地把數據寫入它的磁盤設備上。 讀取數據一般在本地進行。 若是主節點發生故障，心跳（heartbeat或corosync）將會把從節點轉換到主狀態，並啓動其上的應用程序。（若是您將它和無日誌FS 一塊兒使用，則須要運行fsck）。若是發生故障的節點恢復工做，它就會成爲新的從節點，並且必須使本身的內容與主節點的內容保持同步。固然，這些操做不會干擾到後臺的服務。

 

 

單主模式

在單主模式下,任何資源在任何特定的時間,集羣中只存在一個主節點。正是由於這樣在集羣中只能有一個節點能夠隨時操做數據,這種模式可用在任何的文件系統上(EXT三、EXT四、XFS

等等)。部署 DRBD 單主節點模式可保證集羣的高可用性(fail-over 遇故障轉移的能力)

 

雙主模式

這是 DRBD8.0 以後的新特性。

在雙主模式下,任何資源在任何特定的時間,集羣中都存在兩個主節點。猶豫雙方數據存在併發的可能性,這種模式須要一個共享的集羣文件系統,利用分佈式的鎖機制進行管理,如 GFS 和

OCFS2。

部署雙主模式時,DRBD 是負載均衡的集羣,這就須要從兩個併發的主節點中選取一個首選的訪問數據。這種模式默認是禁用的,若是要是用的話必須在配置文件中進行聲明。

 

複製模式

 (1) 協議 A  異步複製本地寫成功後當即返回，數據放在發送buffer中，可能丟失

一旦本地磁盤寫入已經完成,數據包已在發送隊列中,則寫被認爲是完成的 。在一個

節點發生故障時,可能發生數據丟失,由於被寫入到遠程節點上的數據可能仍在發送隊列。儘管,

在故障轉移節點上的數據是一致的,但沒有及時更新。這一般是用於地理上分開的節點。

    (2) 協議 B 半同步複製本地寫成功並將數據發送到對方後當即返回，若是雙機掉電，數據可能丟失

一旦本地磁盤寫入已完成且複製數據包達到了對等節點則認爲寫在主節點上被認爲是

完成的。數據丟失可能發生在參加的兩個節點同時故障的狀況下,由於在飛行中的數據可能不會

被提交到磁盤。

    (3) 協議 C 同步複製本地和對方寫成功確認後返回。若是雙機掉電或磁盤同時損壞，則數據可能丟失

只有在本地和遠程節點的磁盤已經確認了寫操做完成,寫才被認爲完成。沒有任何數

據丟失,因此這是一個羣集節點的流行模式,但 I/O 吞吐量依賴於網絡帶寬。

簡言之:

A 數據一旦寫入磁盤併發送到網絡中就認爲完成了寫入操做。

B 收到接收確認就認爲完成了寫入操做。

C 收到寫入確認就認爲完成了寫入操做。

就目前而言應用最多和應用最普遍的爲協議 C。但選擇C協議將影響流量，從而影響網絡時延。爲了數據可靠性，咱們在生產環境中仍是用C協議。

 

 

 

工做原理圖：

 

DRBD是linux的內核的存儲層中的一個分佈式存儲系統，可用使用DRBD在兩臺Linux服務器之間共享塊設備，共享文件系統和數據

 

 

 

簡單說一下DRBD主要功能，DRBD 負責接收數據，把數據寫到本地磁盤，而後經過網絡將一樣的數據發送給另外一個主機，另外一個主機再將數據存到本身的磁盤中。

 

 

DRBD 配置工具

drbdadm：高級管理工具，管理/etc/drbd.conf，向drbdsetup和drbdmeta發送指令。

drbdsetup：配置裝載進kernel的DRBD模塊，平時不多直接用。

drbdmeta：管理META數據結構，平時不多直接用。

· 

DRBD 配置文件

   DRBD的主配置文件爲/etc/drbd.conf；爲了管理的便捷性，目前一般會將些配置文件分紅多個部分，且都保存至/etc/drbd.d目錄中，主配置文件中僅使用"include"指令將這些配置文件片段整合起來。一般，/etc/drbd.d目錄中的配置文件爲global_common.conf和全部以.res結尾的文件。其中global_common.conf中主要定義global段和common段，而每個.res的文件用於定義一個資源。

在配置文件中，global段僅能出現一次，且若是全部的配置信息都保存至同一個配置文件中而不分開爲多個文件的話，global段必須位於配置文件的最開始處。目前global段中能夠定義的參數僅有minor-count, dialog-refresh, disable-ip-verification和usage-count。

   common段則用於定義被每個資源默認繼承的參數，能夠在資源定義中使用的參數均可以在common段中定義。實際應用中，common段並不是必須，但建議將多個資源共享的參數定義爲common段中的參數以下降配置文件的複雜度。

   resource段則用於定義drbd資源，每一個資源一般定義在一個單獨的位於/etc/drbd.d目錄中的以.res結尾的文件中。資源在定義時必須爲其命名，名字能夠由非空白的ASCII字符組成。每個資源段的定義中至少要包含兩個host子段，以定義此資源關聯至的節點，其它參數都可以從common段或drbd的默認中進行繼承而無須定義。

 

 

解決腦裂(split brain)問題:

在「雙機熱備」高可用(HA)系統中,當聯繫2個節點的「心跳線」斷開時,原本爲一總體、動做協調的HA系統,就分裂成爲2個獨立的個體。因爲相互 失去了聯繫,都覺得是對方出了故障,2個節點上的HA軟件像「裂腦人」同樣,「本能」地爭搶「共享資源」、爭起「應用服務」,就會發生嚴重後果:或者共享資源被瓜分、2邊「服務」都起不來了;或者2邊「服務」都起來了,但同時讀寫「共享存儲」,致使數據損壞 (常見如數據庫輪詢着的聯機日誌出錯)。

對付HA系統「裂腦」的對策大概有如下幾條:

1)添加冗餘的心跳線,例如雙線條線。儘可能減小「裂腦」發生機會。

2)啓用磁盤鎖。正在服務一方鎖住共享磁盤,「裂腦」發生時,讓對方徹底「搶不走」共享磁盤資源。但使用鎖磁盤也會有一個不小的問題,若是佔用共享盤的一 方不主動「解鎖」,另外一方就永遠得不到共享磁盤。現實中假如服務節點忽然死機或崩潰,就不可能執行解鎖命令。後備節點也就接管不了共享資源和應用服務。於 是有人在HA中設計了「智能」鎖。即,正在服務的一方只在發現心跳線所有斷開(察覺不到對端)時才啓用磁盤鎖。平時就不上鎖了。

3)設置仲裁機制。例如設置參考IP(如網關IP),小心跳線徹底斷開時,2個節點都各自ping一下 參

考IP,不通則代表斷點就出在本端,不只「心跳」、還兼對外「服務」的本端網絡鏈路斷了,即便啓動(或繼續)應用服務也沒有用了,那就主動放棄競爭,讓 可以ping通參考IP的一端去起服務。更保險一些,ping不通參考IP的一方乾脆就自我重啓,以完全釋放有可能還佔用着的那些共享資源。