DRBD概念、原理和問題
底層設備支持：
DRBD需要構建在底層設備之上，然後構建出一個塊設備出來。對於用戶來說，一個DRBD設備，就像是一塊物理的磁盤，可以在商脈內創建文件系統。DRBD所支持的底層設備有以下這些類：
1、一個磁盤，或者是磁盤的某一個分區；
2、一個soft raid 設備；
3、一個LVM的邏輯卷；
4、一個EVMS（Enterprise Volume Management System，企業卷管理系統）的卷；
5、其他任何的塊設備。
配置簡介
1、全局配置項（global）
基本上我們可以做的也就是配置usage-count是yes還是no了，usage-count參數其實只是為了讓linbit公司收集目前drbd的使用情況。當drbd在安裝和升級的時候會通過http協議發送信息到linbit公司的服務器上面。
2、公共配置項（common）
這裏的common，指的是drbd所管理的多個資源之間的common。配置項裏面主要是配置drbd的所有resource可以設置為相同的參數項，比如protocol，syncer等等。
3、資源配置項（resource）
resource項中配置的是drbd所管理的所有資源，包括節點的ip信息，底層存儲設備名稱，設備大小，meta信息存放方式，drbd對外提供的設備名等等。每一個resource中都需要配置在每一個節點的信息，而不是單獨本節點的信息。實際上，在drbd的整個集群中，每一個節點上面的drbd.conf文件需要是完全一致的。
另外，resource還有很多其他的內部配置項：
net：網絡配置相關的內容，可以設置是否允許雙主節點（allow-two-primaries）等。
startup：啟動時候的相關設置，比如設置啟動後誰作為primary（或者兩者都是primary：become-primary-on both）
syncer：同步相關的設置。可以設置“重新”同步（re-synchronization）速度（rate）設置，也可以設置是否在線校驗節點之間的數據一致性（verify-alg 檢測算法有md5，sha1以及crc32等）。數據校驗可能是一個比較重要的事情，在打開在線校驗功能後，我們可以通過相關命令（drbdadm verify resource_name）來啟動在線校驗。在校驗過程中，drbd會記錄下節點之間不一致的block，但是不會阻塞任何行為，即使是在該不一致的block上面的io請求。當不一致的block發生後，drbd就需要有re-synchronization動作，而syncer裏面設置的rate項，主要就是用於re-synchronization的時候，因為如果有大量不一致的數據的時候，我們不可能將所有帶寬都分配給drbd做re-synchronization，這樣會影響對外提提供服務。rate的設置和還需要考慮IO能力的影響。如果我們會有一個千兆網絡出口，但是我們的磁盤IO能力每秒只有50M，那麽實際的處理能力就只有50M，一般來說，設置網絡IO能力和磁盤IO能力中最小者的30%的帶寬給re-synchronization是比較合適的（官方說明）。另外，drbd還提供了一個臨時的rate更改命令，可以臨時性的更改syncer的rate值：drbdsetup /dev/drbd0 syncer -r 100M。這樣就臨時的設置了re-synchronization的速度為100M。不過在re-synchronization結束之後，你需要通過drbdadm adjust resource_name 來讓drbd按照配置中的rate來工作。
資源管理
1、增加resource的大小：
當遇到我們的drbd resource設備容量不夠的時候，而且我們的底層設備支持在線增大容量的時候（比如使用lvm的情況下），我們可以先增大底層設備的大小，然後再通過drbdadm resize resource_name來實現對resource的擴容。但是這裏有一點需要註意的就是只有在單primary模式下可以這樣做，而且需要先在所有節點上都增大底層設備的容量。然後僅在primary節點上執行resize命令。在執行了resize命令後，將觸發一次當前primary節點到其他所有secondary節點的re-synchronization。
如果我們在drbd非工作狀態下對底層設備進行了擴容，然後再啟動drbd，將不需要執行resize命令（當然前提是在配置文件中沒有對disk參數項指定大小），drbd自己會知道已經增大了容量。
在進行底層設備的增容操作的時候千萬不要修改到原設備上面的數據，尤其是drbd的meta信息，否則有可能毀掉所有數據。
2、收縮resource容量：
容量收縮比擴容操作要危險得多，因為該操作更容易造成數據丟失。在收縮resource的容量之前，必須先收縮drbd設備之上的容量，也就是文件系統的大小。如果上層文件系統不支持收縮，那麽resource也沒辦法收縮容量。
如果在配置drbd的時候將meta信息配置成internal的，那麽在進行容量收縮的時候，千萬別只計算自身數據所需要的空間大小，還要將drbd的meta信息所需要的空間大小加上。
當文件系統收縮好以後，就可以在線通過以下命令來重設resource的大小：drbdadm — –size=***G resize resource_name。在收縮的resource的大小之後，你就可以自行收縮釋放底層設備空間（如果支持的話）。
如果打算停機狀態下收縮容量，可以通過以下步驟進行：
a、在線收縮文件系統
b、停用drbd的resource：drbdadm down resourcec_name
c、導出drbd的metadata信息（在所有節點都需要進行）：drbdadm dump-md resource_name > /path_you_want_to_save/file_name
d、在所有節點收縮底層設備
e、更改上面dump出來的meta信息的la-size-sect項到收縮後的大小（是換算成sector的數量後的數值）
f、如果使用的是internal來配置meta-data信息，則需要重新創建meta-data:drbdadm create-md resource_name
g、將之前導出並修改好的meta信息重新導入drbd（摘錄自linbit官方網站的一段導入代碼）：
drbdmeta_cmd=$(drbdadm -d dump-md test-disk)
${drbdmeta_cmd/dump-md/restore-md} /path_you_want_to_save/file_name
h、啟動resource：drbdadm up resource_name
磁盤損壞
1、detach resource
如果在resource的disk配置項中配置了on_io_error為pass_on的話，那麽drbd在遇到磁盤損壞後不會自己detach底層設備。也就是說需要我們手動執行detach的命令（drbdadm detach resource_name），然後再查看當前各節點的ds信息。可以通過cat /proc/drbd來查看，也可以通過專有命令來查看：drbdadm dstat resource_name。當發現損壞的那方已經是Diskless後，即可。如果我們沒有配置on_io_error或者配置成detach的話，那麽上面的操作將會由自動進行。
另外，如果磁盤損壞的節點是當前主節點，那麽我們需要進行節點切換的操作後再進行上面的操作。
2、更換磁盤
當detach了resource之後，就是更換磁盤了。如果我們使用的是internal的meta-data，那麽在換好磁盤後，只需要重新創建mata-data（drbdadm create-md resource_name），再將resource attach上（drbdadm attach resource_name），然後drbd就會馬上開始從當前primary節點到本節點的re-synchronisation。數據同步的實時狀況可以通過 /proc/drbd文件的內容獲得。
不過，如果我們使用的不是internal的meta-data保存方式，也就是說我們的meta-data是保存在resource之外的地方的。那麽我們在完成上面的操作（重建meta-data）之後，還需要進行一項操作來觸發re-synchnorisation，所需命令為：drbdadm invalidate resource_name 。
節點crash（或計劃內維護）
1、secondary節點
如果是secondary接待你crash，那麽primary將臨時性的與secondary斷開連接，cs狀態應該會變成WFConnection，也就是等待連接的狀態。這時候primary會繼續對外提供服務，並在meta-data裏面記錄下從失去secondary連接後所有變化過的block的信息。當secondary重新啟動並連接上primary後，primary –> secondary的re-synchnorisation會自動開始。不過在re-synchnorisation過程中，primary和secondary的數據是不一致狀態的。也就是說，如果這個時候primary節點也crash了的話，secondary是沒辦法切換成primary的。也就是說，如果沒有其他備份的話，將丟失所有數據。
2、primary節點
一般情況下，primary的crash和secondary的crash所帶來的影響對drbd來說基本上是差不多的。唯一的區別就是需要多操作一步將secondary節點switch成primary節點先對外提供服務。這個switch的過程drbd自己是不會完成的，需要我們人為幹預進行一些操作才能完成。當crash的原primary節點修復並重新啟動連接到現在的primary後，會以secondary存在，並開始re-synchnorisation這段時間變化的數據。
在primary節點crash的情況下，drbd可以保證同步到原secondary的數據的一致性，這樣就避免了當primary節點crash之後，secondary因為數據的不一致性而無法wcitch成primary或者即使切換成primary後因為不一致的數據無法提供正常的服務的問題。
3、節點永久性損壞（需要更換機器或重新安裝相關軟件的情況）
當某一個節點因為硬件（或軟件）的問題，導致某一節點已經無法再輕易修復並提供服務，也就是說我們所面對的是需要更換主機（或從OS層開始重新安裝）的問題。在遇到這樣的問題後，我們所需要做的是重新提供一臺和原節點差不多的機器，重新開始安裝os，安裝相關軟件，從現有整提供服務的節點上copy出drbd的配置文件（/etc/drbd.conf），創建meta-data信息，然後啟動drbd服務，以一個secondary的身份連接到現有的primary上面，後面就會自動開始re-synchnorisation。
split brain的處理
split brain實際上是指在某種情況下，造成drbd的兩個節點斷開了連接，都以primary的身份來運行。當drbd某primary節點連接對方節點準備發送信息的時候如果發現對方也是primary狀態，那麽會會立刻自行斷開連接，並認定當前已經發生split brain了，這時候他會在系統日誌中記錄以下信息：“Split-Brain detected,dropping connection!”當發生split brain之後，如果查看連接狀態，其中至少會有一個是StandAlone狀態，另外一個可能也是StandAlone（如果是同時發現split brain狀態），也有可能是WFConnection的狀態。
如果我們在配置文件中配置了自動解決split brain（好像linbit不推薦這樣做），drbd會自行解決split brain問題，具體解決策略是根據配置中的設置來進行的。
如果沒有配置split brain自動解決方案，我們可以手動解決。首先我們必須要確定哪一邊應該作為解決問題後的primary，一旦確定好這一點，那麽我們同時也就確定接受丟失在split brain之後另外一個節點上面所做的所有數據變更了。當這些確定下來後，我們就可以通過以下操作來恢復了：
a、首先在確定要作為secondary的節點上面切換成secondary並放棄該資源的數據：
drbdadm secondary resource_name
drbdadm — –discard-my-data connect resource_name
b、在要作為primary的節點重新連接secondary（如果這個節點當前的連接狀態為WFConnection的話，可以省略）
drbdadm connect resource_name
當作完這些動作之後，從新的primary到secondary的re-synchnorisation會自動開始。
meta data存放地點的比較
1、internal meta-data（meta-data和數據存放在同一個底層設備之上）
優點：一旦meta-data創建之後，就和實際數據綁在了一起，在維護上會更簡單方便，不用擔心meta-data會因為某些操作而丟失。另外在硬盤損壞丟失數據的同時，meta-data也跟著一起丟失，當更換硬盤之後，只需要執行重建meta-data的命令即可，丟失的數據會很容易的從其他節點同步過來。
缺點：如果底層設備是單一的磁盤，沒有做raid，也不是lvm等，那麽可能會造成性能影響。因為每一次寫io都需要更新meta-data裏面的信息，那麽每次寫io都會有兩次，而且肯定會有磁頭的較大尋道移動，因為meta-data都是記錄在dice設備的最末端的，這樣就會造成寫io的性能降低。
2、external meta data（meta-data存放在獨立的，與存放數據的設備分開的設備之上）
優點：與internal meta-data的缺點完全相對，可以解決寫io的爭用問題。
缺點：由於meta-data存放在與數據設備分開的地方，就意味著當磁盤損壞更換磁盤之後，必須手動發起全量同步的操作。也就是管理維護會稍微麻煩那麽一點點，很小的一點點。
如果我們希望在已經存在數據的設備上面建立drbd的資源，並且不希望丟失該設備上面的數據，又沒辦法增大底層設備的容量，而且上層文件系統又沒辦法收縮的話，我們就只能將meta data創建成external方式。
轉自：http://net.it168.com/a2008/1222/260/000000260851_2.shtml
DRBD概念、原理和問題