Pro DRBD vyberte na obou serverech stejně velké diskové oddíly, ideálně nějaké pod RAID1 (např /dev/md3). Na dvou počítačích můžete mít více DRBD mirrorů, takže se nemusíte nějak moc omezovat. Kompletní dokumentaci k DRBD najdete na webu www.drbd.org.
Ukázka mé konfigurace DRBD a postupu zprovoznění, soubor /etc/drbd.conf:
global { usage-count no; }
common { syncer { rate 100M; } }
resource mysql {
protocol C;
device /dev/drbd1;
disk /dev/md3;
meta-disk internal;
startup {
wfc-timeout 20;
degr-wfc-timeout 120;
become-primary-on both; # Enable this *after* initial testing
}
net {
cram-hmac-alg sha1;
shared-secret "pai0eeRo";
max-buffers 2048;
ko-count 4;
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
}
on clemenza.klenot.eu {
address 172.16.100.10:7790; #clemenza-clust
}
on tessio.klenot.eu {
address 172.16.100.11:7790; #tessio-clust
}
disk {
on-io-error detach;
fencing resource-and-stonith;
}
handlers {
outdate-peer "/usr/lib/heartbeat/drbd-peer-outdater -t 5";
}
}
Po vytvoření konfiguračního souboru vytvořte na obou počítačích DRBD RAID:
[root@tessio cluster]# drbdadm create-md mysql v08 Magic number not found v07 Magic number not found v07 Magic number not found v08 Magic number not found Writing meta data... initialising activity log NOT initialized bitmap New drbd meta data block sucessfully created.
Dále na obou počítačích proveďte start DRBD příkazem:
[root@tessio cluster]# /etc/init.d/drbd start Starting DRBD resources: [ d(mysql) s(mysql) n(mysql) ].
Zkontrolujte stav DRBD v souboru /proc/drbd:
[root@tessio cluster]# cat /proc/drbd
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by buildsvn@c5-x8664-build, 2008-10-03 11:30:32
1: cs:Connected st: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 oos:987772
Pokud jste ve stavu, že se nesynchronizuje DRBD mezi počítači, ale vidíte Inconsistent/Inconsistent, můžete DRBD stopnout, spustit níže uvedený příkaz (jen na nově vytvářeném DRBD zařízení, přijdete o data!) a pak znovu DRBD nahodit.
[root@tessio cluster]# drbdadm detach mysql # ručně zastavíme konkrétní DRBD zařízení
[root@tessio cluster]# drbdadm disconnect mysql
[root@tessio cluster]# drbdadm -- 6::::1 set-gi mysql # přinutíme DRBD aby si myslelo, že jsou oba disky UpToDate
previously 0000000000000004:0000000000000000:0000000000000000:0000000000000000:0:0:0:1:0:1
set GI to 0000000000000006:0000000000000000:0000000000000000:0000000000000000:1:0:0:1:0:1
Write new GI to disk?
[need to type 'yes' to confirm] yes
[root@tessio cluster]# /etc/init.d/drbd reload # nahodíme DRBD
Reloading DRBD configuration.
[root@tessio cluster]# drbdadm primary mysql # nahodíme DRBD zařízení do stavu Primary
[root@tessio cluster]# cat /proc/drbd # ověříme stav
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by buildsvn@c5-x8664-build, 2008-10-03 11:30:32
1: cs:Connected st:Primary/Primary ds:UpToDate/UpToDate C r---
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 oos:987772
Pokud byste se snažili vytvořit drbd zařízení na někde kde už bylo, dostanete podobné hlášení:
[root@clemenza ~]# drbdadm create-md mysql md_offset 1011544064 al_offset 1011511296 bm_offset 1011478528 Found ext2 filesystem which uses 987772 kB current configuration leaves usable 987772 kB ==> This might destroy existing data! < == Do you want to proceed? [need to type 'yes' to confirm] yes v07 Magic number not found v07 Magic number not found You want me to create a v08 style flexible-size internal meta data block. There apears to be a v08 flexible-size internal meta data block already in place on /dev/md2 at byte offset 1011544064 Do you really want to overwrite the existing v08 meta-data? [need to type 'yes' to confirm] yes Writing meta data... initialising activity log NOT initialized bitmap New drbd meta data block sucessfully created.
Split brain a oprava
Pokud se dostanete do situace kdy se vám rozpadne DRBD a nastane tzv. „split brain“ kdy DRBD neví kde jsou aktuální data, bude rozhodnutí na vás.
Při přesunu serverů a změně síťové konfigurace se mi podařilo na obou serverech nabootovat a spustit virtuální stroj – to znamená, že nakaždém uzlu clusteru běžel jeden stroj v XENu a servery spolu přes DRBD nekomunikovaly. Tak došlo k porušení integrity dat na „sdíleném“ úložišti a po opravě sítě DRBD nenastartovalo správně:
[root@clemenza ~]# /etc/init.d/drbd start Starting DRBD resources: [ d(mysql) s(mysql) n(mysql)]. degr-wfc-timeout has to be shorter than wfc-timeout degr-wfc-timeout implicitly set to wfc-timeout (20s) degr-wfc-timeout has to be shorter than wfc-timeout degr-wfc-timeout implicitly set to wfc-timeout (20s) .......... *************************************************************** DRBD's startup script waits for the peer node(s) to appear. - In case this node was already a degraded cluster before the reboot the timeout is 120 seconds. [degr-wfc-timeout] - If the peer was available before the reboot the timeout will expire after 20 seconds. [wfc-timeout] (These values are for resource 'mysql-data'; 0 sec -> wait forever) To abort waiting enter 'yes' [ 19]: /dev/drbd1: State change failed: (-2) Refusing to be Primary without at least one UpToDate disk Command '/sbin/drbdsetup /dev/drbd1 primary' terminated with exit code 17 command exited with code 17
Startovací skript nenahodil některá sdálená úložiště, proto jsem se podíval na stav do /proc/drbd na obou serverech, stav byl u obou stejný:
[root@clemenza ~]# cat /proc/drbd
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by buildsvn@c5-x8664-build, 2008-10-03 11:30:32
1: cs:WFConnection st:Secondary/Unknown ds:Consistent/DUnknown C s---
ns:0 nr:0 dw:0 dr:0 al:0 bm:1 lo:0 pe:0 ua:0 ap:0 oos:48835976
V logu /var/log/messages najdete pravděpodobně podobné hlášení:
May 10 17:54:58 tessio kernel: drbd1: Split-Brain detected, dropping connection! May 10 17:54:58 tessio kernel: drbd1: self B45D64BD11EEDD92:020B5BBE576A3AAD:FCBF81E5FC307650:CA9A394126491F41 May 10 17:54:58 tessio kernel: drbd1: peer 4CE6BCAD514CEF86:020B5BBE576A3AAD:FCBF81E5FC307651:FCBF81E5FC307650 May 10 17:54:58 tessio kernel: drbd1: helper command: /sbin/drbdadm split-brain May 10 17:54:58 tessio kernel: drbd1: conn( WFReportParams -> Disconnecting ) May 10 17:54:58 tessio kernel: drbd1: error receiving ReportState, l: 4!
Pokud dojde k takovéto situaci, zastavte vše co by mohlo s daným drbd zařízením praocvat. Určitě na obou serverech přepněte drbd zařízení do RO – secondary:
[root@tessio ~]# drbdadm -- secondary mysql # přepneme zařízení do RO režimu
Na obou strojích byly tedy aktuální data, ale na každém trochu jiná. No a je na adminovi aby se rozhodl. Proto jsem na jednom serveru, který jsem si prohlásil za sekundární, spustil následující sadu příkazů:
[root@clemenza ~]# drbdadm -- disconnect mysql # odpojení drbd zařízení od síťě [root@clemenza ~]# drbdadm -- --discard-my-data connect mysql # zneplatnění dat na tomto serveru a připojíme se
Na druhém stroji, který jsem prohlásil za primární (zdroj dat) jsem spustil:
[root@tessio ~]# drbdadm -- disconnect mysql # odpojíme od sítě [root@tessio ~]# drbdadm -- connect mysql # zkusíme připojit
Po provedení těchto příkazů se začalo dané úložitě synchronizovat. Výpis ukazuje trochu jiné hodnoty u ostatních úložišť, ty jsem přepnul do stavy primary-primary ručně pomocí drbdadm — primary resource případně syncnul výše popsaným postupem. Pokud se vám plete výpis Primary/Secondary a Inconsistent/UpToDate tak se přesvědčete pomocí programu iostat o tom kdo čte a kdo zapisuje. První uvedená hodnota je lokální stroj, kde výpis provádíte, hodnota za lomítkem je jeho protějšek. Primar/Secondary určuje na kterém serveru můžete zapistovat, Inconsistent/UpToDate určuje který má data v pořádku. Můžete zapisovat do drbd zařízení i na nekonzistentním serveru, přes síť si to spolu servery vyříkají.
[root@clemenza ~]# cat /proc/drbd
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by buildsvn@c5-x8664-build, 2008-10-03 11:30:32
1: cs:SyncTarget st:Primary/Secondary ds:Inconsistent/UpToDate C r---
ns:0 nr:36899264 dw:36899264 dr:0 al:0 bm:2253 lo:0 pe:96 ua:0 ap:0 oos:11936712
[==============>.....] sync'ed: 75.6% (11656/47691)M
finish: 0:06:06 speed: 32,552 (30,696) K/sec
Related posts:
[...] a jednu z možností řešení situace kdy se DRBD rozpadne jsem popsal v jiném článku na blogu: Konfigurace DRBD a řešení situace „Split-Brain“, pro pochopení způsobu konfigurace to snad [...]
Děkuji za velmi užitečný článek. Najít o této problematice nějaké aktuální informace, natož v češtině, je jinak docela problém.
Jak je zabráněno tomu, aby vznikl split-brain v normální situaci, jako třeba výpadek napájení (resp. vypnutí serverů po signálu z UPS)? To je ořetřeno těmi timeouty, tj. každý server při bootu čeká nějakou dobu, jestli se objeví ten druhý? To je pak asi potřeba vypnout veškeré fsck, protože síť startuje až potom… i když možná se s tím cluster vyrovná, jen dojde k dočasnému přepnutí mastera…
Ještě jeden dotaz: když máte „become-primary-on both“, tak nad tím používáte nějaký cluster filesystem, nebo to je kvůli živé migraci XENu? O DRBD jsou občas zvěsti, že je to pomalé, nestabilní apod., což si myslím, že závisí hlavně na konkrétních verzích jádra a DRBD modulu. Máte to na nějaké běžné distribuci, nebo to řešíte vlastní kompilací těchto věcí? Ale možná moc v
Ohledně split-brain:
Pokud dojde ke korektnímu vypnutí, split-brain nehrozí. Problémem ani nemusí být (a asi většinou není, prakticky vyzkoušeno několika desítkami restartů během různých synchronizací a přenosů dat:-)) hard reset mašiny. Co téměř spolehlivě povede k split-brain je nastartování nodů clusteru bez vzájemného propojení a automatický start DRBD.
Jak split-brain předejít?
1) redundantní propojení serverů (bonding)
2) nestartovat automaticky DRBD init skriptem, ale například přes heartbeat, který má možnost nadefinovat různá pravidla pro kontrolu zda je vše v pořádku, až když ověří, že je vše ok, nahodí DRBD, když zjistí, že je i DRBD ok, nahodí požadované uzly do stavu Master.
3) Z hlediska bezpečnosti dat je nutné vhodně vybrat protokol komunikace – přesněji zvolit C, který zajistí potvrzení zápisu dat až po tom co jsou zapsána skutečně na disku na obou serverech
4) nastavení wfc-timeout na 0 – neomezeně dlouho bude blokován start čekáním až nastartuje druhý uzel clusteru
…
Je vhodné použít handler split-brain cmd na notifikaci situace split-brain, buď aby se o tom dověděl cluster(např heartbeat) nebo třeba hned admin a ručně to pořešil (popis možností automatického zotavení je dostupný na webu drbd: http://www.drbd.org/docs/working/).
K fsck – doporučuji zvážit volbu FS, některé (ext2/3) mají fsck na hodiny až dny dle velikosti FS.
Oba uzly jsou Primary kvůli živé migraci XENu (oba servery jsou zároveň dom0). Aktuálně nám tato konfigurace nikde neběží – z důvodu náročnosti na diskovou kapacitu jsme pořídili redundantní centrální storage a domU startují z něj. Centrální úložiště je také DRBD, ale data jsou exportována přes NFS a iSCSI.
Používáme CentOS, ohledně nestability – DRBD nám běží v produkčním režimu u zákazníka a vše je v pořádku.