drbd 配置
DRBD(Distributed Replicated Block Device),DRBD 號稱是 "網絡 RAID",開源軟件,由
LINBIT 公司開發。DRBD實際上是一種塊設備的實現,主要被用于Linux平臺下的高可用(HA)方案之中。他有內核模塊和相關程序而組成,通過網絡通信來同步鏡像整個設備,有點類似于一個網絡RAID-1的功能。也就是說當你將數據寫入本地的DRBD設備上的文件系統時,數據會同時被發送到網絡中的另外一臺主機之上,并以完全相同的形式記錄在文件系統中。本地節點與遠程節點的數據可以保證實時的同步,并保證IO的一致性。所以當本地節點的主機出現故障時,遠程節點的主機上還會保留有一份完全相同的數據,可以繼續使用,以達到高可用的目的.
復制模式：三種
????A：數據一旦寫入磁盤并且發送到網絡則認為完成寫入。特點：快，易丟數據。
????B：收到對端"接收"的信號就認為寫完成。半同步。
????C：收到對端"寫入"信號才認為完成寫操作。特點：數據完整，應用最廣。
軟件下載:http://oss.linbit.com/drbd 官網http://www.drbd.org
實驗環境：rhel6.5 selinux and iptables disabled
主機：server2 172.25.12.2
server3 172.25.12.3
解決軟件依賴性:yum install gcc flex rpm-build kernel-devel -y
tar zxf drbd-8.4.3.tar.gz
cd drbd-8.4.0
./configure --enable-spec --with-km
rpmbuild -bb drbd.spec????#編譯生成 drbd rpm 包
rpmbuild -bb drbd-km.spec #編譯 drbd 內核模塊
error: File /root/rpmbuild/SOURCES/drbd-8.4.3.tar.gz: No such file or directory
cp drbd-8.4.0.tar.gz rpmbuild/SOURCES/
?
[root@server2 drbd-8.4.3]# cd ~/rpmbuild/RPMS/x86_64/
[root@server2 x86_64]# ls
drbd-8.4.3-2.el6.x86_64.rpm
drbd-bash-completion-8.4.3-2.el6.x86_64.rpm
drbd-debuginfo-8.4.3-2.el6.x86_64.rpm
drbd-heartbeat-8.4.3-2.el6.x86_64.rpm
drbd-km-2.6.32_431.el6.x86_64-8.4.3-2.el6.x86_64.rpm
drbd-km-debuginfo-8.4.3-2.el6.x86_64.rpm
drbd-pacemaker-8.4.3-2.el6.x86_64.rpm
drbd-udev-8.4.3-2.el6.x86_64.rpm
drbd-utils-8.4.3-2.el6.x86_64.rpm
drbd-xen-8.4.3-2.el6.x86_64.rpm
scp * server2:
yum install *
在兩臺機上準備好相同大小的磁盤。名字不一定一樣
配置兩臺主機
resource wwwdata {
meta-disk internal;
device /dev/drbd1;
syncer {
verify-alg sha1;
}
on server2.example.com {
disk /dev/drbd_vg/drbd_lv;
address 172.25.12.2:7789;
}
on server3.example.com {
disk /dev/drbd_vg/drbd_lv;
address 172.25.12.3:7789;
}
}
拷貝到另一節點scp wwwdata.res server3:/etc/drbd.d/
DRBD將數據的各種信息塊保存在一個專用的區域里,這些metadata包括了
a,DRBD設備的大小
b,產生的標識
c,活動日志
d,快速同步的位圖
metadata的存儲方式有內部和外部兩種方式,使用哪種配置都是在資源配置中定義的
內部metadata:內部metadata存放在同一塊硬盤或分區的最后的位置上
優點:metadata和數據是緊密聯系在一起的,如果硬盤損壞,metadata同樣就沒有了,同樣在恢復
的時候,metadata也會一起被恢復回來
缺點: 如果底層設備是單一的磁盤，沒有做raid，也不是lvm等，那么可能會造成性能影響。metadata和數據在同一塊硬盤上,對于寫操作的吞吐量會帶來負面的影響,因為應用程序的寫請求會觸發metadata的更新,這樣寫操作就會造成兩次額外的磁頭讀寫移動。
外部metadata:外部的metadata存放在和數據磁盤分開的獨立的塊設備上
優點:對于一些寫操作可以對一些潛在的行為提供一些改進
缺點:metadata和數據不是聯系在一起的,所以如果數據盤出現故障,在更換新盤的時候就需要人工干預操作來進行現有node新硬盤的同步了。
配置注意點：meta-disk external;
meta-disk /dev/sdb2 [0];
?
在兩臺主機上分別執行以下命令:
drbdadm create-md wwwdata
/etc/init.d/drbd start ????????#這里兩個同時起，不然單個節點會等代另一結點的反應
開機不自啟動。手動起就好。
將 server3設置為 primary 節點,并同步數據:(在 server3 主機執行以下命令)
drbdsetup /dev/drbd1 primary --force
或者drbdadm --overwrite-data-of-peer primary wwwdata
在兩臺主機上查看同步狀態: watch cat /proc/drbd
[root@server3 drbd.d]# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by root@server2.example.com, 2015-03-13 17:17:17
?
1: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
ns:679604 nr:0 dw:0 dr:680600 al:0 bm:41 lo:0 pe:1 ua:1 ap:0 ep:1 wo:f oos:365500
????[============>.......] sync'ed: 65.1% (365500/1044412)K
????finish: 0:00:21 speed: 17,356 (17,408) K/sec
?
數據同步結束后創建文件系統:mkfs.ext4 /dev/drbd1
掛載文件系統:mount /dev/drbd1 /var/www/html
@轉換主從關系
drbdadm primary wwwdata
注意:兩臺主機上的/dev/drbd1 不能同時掛載,只有狀態為 primary 時,才能被掛載使用,而此時另一方的狀態為 secondary.
?
腦裂：
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問題，具體解決策略是根據配置中的設置來進行的
?
腦裂發生時處理：
- 從節點：
明確自己是從節點：drbdadm secondary data0
放手資源：drbdadm --discard-my-data connect data0
- 主節點：
????連接資源：drbdadm connect data0
- 檢測狀態：cat /proc/drbd
- 我在處理的過程中出現了個105的錯誤，是地址被占，兩邊重啟就好了。
?
節點宕機：
- secondary節點
primary將臨時性的與secondary斷開連接，cs狀態應該會變成WFConnection， 也就是等待連接的狀態。這時候primary會繼續對外提供服務，并在meta-data里面記錄下從失去secondary連接后所有變化過的 block的信息。當secondary重新啟動并連接上primary后，primary –> secondary的re-synchnorisation會自動開始。不過在re-synchnorisation過程中，primary和 secondary的數據是不一致狀態的。也就是說，如果這個時候primary節點也crash了的話，secondary是沒辦法切換成 primary的。也就是說，如果沒有其他備份的話，將丟失所有數據 - primary節點
一般情況下，primary的crash和secondary的crash所帶來的影響對drbd來說基本上是差不多的。唯一的區別就是需要多操作一步將 secondary節點switch成primary節點先對外提供服務。這個switch的過程drbd自己是不會完成的，需要我們人為干預進行一些操作才能完成。當crash的原primary節點修復并重新啟動連接到現在的primary后，會以secondary存在，并開始re-synchnorisation這段時間變化的數據
?
磁盤處理：
- 如果在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我這里模擬測試下，一切正常的：
把從節點的磁盤，先分離后。
破壞了原來的數據dd if=/dev/zero of=/dev/sdb1 bs=1M count=300
drbdadm create-md data1
drbdadm invalidate data1
drbdadm attach data1
cat /proc/drbd
?
- 另為drbd也可以用來遷移大量的 數據，但必須用作 external的方式保存元數據。
在實驗環境中server2.example.com 中有原來的數據，需要遷移到server1.example.com。
在兩邊正常配置就行，但是drbd裸設備不能格式化。不然數據就丟了。
drbdadm create-md data1
1044 dd if=/dev/zero of=/dev/sdb1 bs=1M count=10
1045 drbdadm create-md data1
1046 /etc/init.d/drbd start
1047 cat /proc/drbd
1051 drbdsetup /dev/drbd2 primary –force
注意點：當兩邊的磁盤不一樣大時，通常遷移到新盤的大一些。Drbd會大的磁盤縮小至對端小磁盤一樣大。當數據同步完成之后。就可以恢復回來。
/etc/init.d/drbd stop
e2fsck -f /dev/vg0/lv0
resize2fs /dev/vg0/lv0
- 資源管理
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容量，我覺得用的比較少。這里我并沒有測試，因為我一開始就把/dev/drbd2格成ext4了，沒法在線縮容量。
容量收縮比擴容操作要危險得多，因為該操作更容易造成數據丟失。在收縮resource的容量之前，必須先收縮drbd設備之上的容量，也就是文件系統的大小。如果上層文件系統不支持收縮，那么resource也沒辦法收縮容量。
如果在配置drbd的時候將meta信息配置成internal的，那么在進行容量收縮的時候，千萬別只計算自身數據所需要的空間大小，還要將drbd的meta信息所需要的空間大小加上。
當文件系統收縮好以后，就可以在線通過以下命令來重設resource的大小： drbdadm –size=***G resize resource_name。在收縮的resource的大小之后，你就可以自行收縮釋放底層設備空間（如果支持的話）
如果打算停機狀態下收縮容量，可以通過以下步驟進行：沒試過，備用
（1）在線收縮文件系統
（2）停用drbd的resource：drbdadm down resourcec_name
（3）導出drbd的metadata信息（在所有節點都需要進行）：drbdadm dump-md resource_name > /path_you_want_to_save/file_name
（4）在所有節點收縮底層設備
（5）更改上面dump出來的meta信息的la-size-sect項到收縮后的大小（是換算成sector的數量后的數值）
（6）如果使用的是internal來配置meta-data信息，則需要重新創建meta-data:drbdadm create-md resource_name
（7）將之前導出并修改好的meta信息重新導入drbd（摘錄自linbit官方網站的一段導入代碼）： drbdmeta_cmd=$(drbdadm -d dump-md test-disk)
${drbdmeta_cmd/dump-md/restore-md} /path_you_want_to_save/file_name
（8）啟動resource：drbdadm up resource_name?
Heartbeat和drbd結合：
結合之前配置的heartbeat就行：
但是drbd必須要建立起來，才能HA切換
server2.example.com IPaddr::192.168.88.200/24/eth0 drbddisk::data0 Filesystem::/dev/drbd1::/data::ext4
一行命令搞定，注意順序不能錯:
data0????資源名稱。
/dev/drbd1 裸設備
/data 掛載點
ext4 文件系統類型
?
?
?
?
?
????????????????????????????????????????????????????????????????
????????????????????????????????????????????????????淺淡
????????????????????????????????????????????????????1138122262@qq.com
轉載于:https://www.cnblogs.com/wxl-dede/p/5114696.html
總結
- 上一篇： IDEA 连接 GIT OSCHINA
- 下一篇： MySQL常用简单小命令