-
DRBD w CentOS 6
W środowiskach biznesowych ciągłość pracy systemów komputerowych odgrywa bardzo dużą rolę. Każdy, nawet najmniejszy przestój może być niezwykle kosztowny. W takich przypadkach dobrze jest stosować rozwiązania klastrowe, które zapewniają wysoką niezawodność i wydajność. W dzisiejszym artykule omówię DRBD, które jest często stosowane w klastrach wysoko-dostępnych (HA). DRBD (Distributed Replicated Block Device) jest to programowa replikacja urządzeń blokowych (takich jak dyski twarde, partycje, woluminy logiczne) z wykorzystaniem sieci. Wszystkie zmiany są replikowane na bierząco w sposób ciągły. Proces ten przebiega blokowo, co zmniejsza ilość danych koniecznych do przeniesienia na inny nośnik (nie dokonywane są modyfikacje całego systemu plików, tylko pojedyńczych bloków). Dzięki temu, rozwiązanie to zapewnia dobry poziom wydajności. Dosyć teorii, czas na instalację. Potrzebujemy pakiet drbd oraz kmod-drbd. Występują one w różnych wersjach. Najnowsza to 8.4. Osobiście skorzystałem z repozytorium „elrepo” oraz wersji nieco starszej, bowiem 8.3.
yum install drbd83-utils kmod-drbd83
dla nowszej wersji tj. 8.4
yum install drbd84-utils kmod-drbd84
Po instalacji przystępujemy do konfiguracji. Najlepierw edytujemy plik „/etc/drbd.d/global_common.conf” i dodajemy do niego następujące wpisy.
global { usage-count no; }
resource repdata2 {
protocol C;
startup { wfc-timeout 0; degr-wfc-timeout 120; }
disk { on-io-error detach; } # or panic, ...
net { cram-hmac-alg "sha1"; shared-secret "versecretnaszehaslo"; } # don't forget to choose a secret for auth !
syncer { rate 10M; }
on node1 {
device /dev/drbd1;
disk /dev/VG-node1/drbd-main2;
address 10.0.2.235:7788;
meta-disk internal;
}
on node2 {
device /dev/drbd1;
disk /dev/VG-node2/drbd-main2;
address 10.0.2.155:7788;
meta-disk internal;
}
}
resource- nazwa naszego replikowanego zasobu
device- określamy nazwę dla urzędzenia blokowego drbd
disk- nasz fizyczny dysk (zalecany lvm)
address- adres ip i port dla danego „noda”
shared-secret- hasło, które musi być takie same w konfiguracji wszystkich „nodów” (elementów klastra)Po zapisaniu kopiujemy plik „/etc/drbd.d/global_common.conf” na drugą maszynę w klastrze.
scp /etc/drbd.d/global_common.conf root@node2:/etc/drbd.d
Następnie tworzymy sumy kontrolne i właściwe urządzenie drbd. Wpierw na pierwszej maszynie:
drbdadm create-md repdata2
[root@node1 ~]# drbdadm create-md repdata2
md_offset 10737414144
al_offset 10737381376
bm_offset 10737053696Found some data
==> This might destroy existing data! <==
Do you want to proceed?
[need to type 'yes' to confirm]
Writing meta data...
initializing activity log
NOT initialized bitmap
New drbd meta data block successfully created.To samo na drugiej:
drbdadm create-md repdata2
Oto efekt:
[root@node2 drbd.d]# drbdadm create-md repdata2
Writing meta data...
initializing activity log
NOT initialized bitmap
New drbd meta data block successfully created.Następnie startujemy demona drbd na obydwu serwerach.
service drbd start
Wydając polecenie „cat /proc/drbd” na obydwu nodach dostaniemy wyniki podobne do tych poniżej:
[root@node1 drbd.d]# cat /proc/drbd
version: 8.3.15 (api:88/proto:86-97)
GIT-hash: 0ce4d235fc02b5c53c1c52c53433d11a694eab8c build by phil@Build64R6, 2012-12-20 20:09:511: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r-----
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:1048508[root@node2 drbd.d]# cat /proc/drbd
version: 8.3.15 (api:88/proto:86-97)
GIT-hash: 0ce4d235fc02b5c53c1c52c53433d11a694eab8c build by phil@Build64R6, 2012-12-20 20:09:511: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r-----
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:1048508Widzimy, że w tej chwili obydwie maszyny oznaczone są jako slave. Należy na serwerze głównym wydać następujące polecenie:
drbdadm -- --overwrite-data-of-peer primary repdata2
Teraz ponownie sprawdzamy „noda1” poleceniem „cat /proc/drbd”
[root@node1 drbd.d]# cat /proc/drbd
version: 8.3.15 (api:88/proto:86-97)
GIT-hash: 0ce4d235fc02b5c53c1c52c53433d11a694eab8c build by phil@Build64R6, 2012-12-20 20:09:511: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
ns:45056 nr:0 dw:0 dr:45720 al:0 bm:2 lo:0 pe:2 ua:0 ap:0 ep:1 wo:f oos:1003708
[>....................] sync'ed: 4.3% (1003708/1048508)K
finish: 0:01:28 speed: 11,200 (11,200) K/sec
i widzimy, że jest ustawiony jako „primary” i że trwa odbuda/synchronizacja drbd. Możemy na serwerze głównym podmontować nowy zasób. Zakładam, że posiadamy wolny katalog „/mnt/drbd” i nie formatowaliśmy wcześniej „partycji” drbd.mkfs.ext4 /dev/drbd1 ; mount /dev/drbd1 /mnt/drbd W tym samym momencie nie możemy podmontować naszego zasobu do serwera slave. Aby to wykonać na serwerze primary należy wydać następujące polecenie:
drbdadm secondary repdata2 ; umount /mnt/drbd
Następnie na secondary:
drbdadm primary repdata2 ; mount /dev/drbd1 /mnt/drbd
Aby ponownie wrócić do pierwotnego układu, na serwerze secondary wydajemy polecenie:
drbdadm secondary repdata2 ; umount /mnt/drbd
a na primary:
drbdadm primary repdata2 ; mount /dev/drbd1 /mnt/drbd
W razie niejasności lub problemów, proszę o kontakt. Życzę wysokiej dostępności 🙂
Wszystkie zamieszczone w serwisie tutoriale stanowią własność CentOS.com.pl oraz ich autorów. Zabrania się kopiowania fragmentów lub całych artykułów bez naszej zgody. Istnieje od tego odstępstwo, o ile zostanie podany link zwrotny i prawowity autor.
Witam, ciekawy artykuł, dziękuje, mam jednak pytanie, rozumiem że mała zmiana w dużym pliku np ISO, AVI, nie będzie wymagała przesłania całego pliku, nie będzie też problemów w przypadku serwerów WWW, ale ciekawi mnie jak wygląda replikacja bazy danych. Fizycznie też mamy pliki, można skonfigurować 2 serwery które komunikują się ze sobą, można cyklicznie wykonywać zrzut bazy i przenosić, ale czy przy DRBD możliwe będzie (w przypadku potrzeby) wystartowanie serwera bazodanowego z drugiego nośnika i czy wszystkie dane bez problemów będą dostępne?
Witam
W momencie gdy pierwszy node (primary) będzie aktywny, nie będzie możliwości podmontowania zasobu drbd na drugim nodzie (secondary). Dopiero po odmontowaniu i zmianie go na secondary, będzie można podmontować zasób na drugiej maszynie.