Archiv pro štítek: DRBD

Vysoká dostupnost dat bez diskového pole

Stalo se to ve 3 hodiny ráno, zvoní telefon. Na druhém konci kamarád s tím, že odešel souborový server a firma stojí. Zkrátím to. Provoz jsme obnovili krátce po sedmé ráno a to jen díky tomu, že jsem měl náhradní server s kompatibilními disky. A teď co s tím aby se to příště nestalo…

Zadání je jednoduché: Postavit řešení, které bude sloužit jako souborový (Samba) server a bude odolné vůči výpadku jednoho serveru.
Pokračování textu

Střípky ze stavby centrálního úložiště

Úkládání dat a zajištění jejich bezpečnosti a dostupnosti je docela složitá disciplína a věnuje se jí hodně lidí. Existuje spousta řešení jak ukládat data – některá jsou levná, jiná drahá, některá spolehlivá a jiná zase nespolehlivá (přičemž spolehlivost a cena spolu velmi často vůbec, ale vůbec nesouvisí).

Před nějakou dobou jsme si přestali stačit s ukládáním dat na lokální disky a museli jsme řešit rozumné úložiště zajišťující dostupnost dat pro víc počítačů v provozu 24×7 bez možnosti větší odstávky. Rozpočet jsme měli omezený, požadavky relativně vysoké.

Požadavky na nové úložiště

Naše nároky na úložiště:

- odolnost proti výpadku HW, v případě selhání HW naštveme mooooc lidí a přijít o data si v žádném případě nemůžeme dovolit,
- rozumný výkon pro provoz virtuálních serverů a servírování dat pro aplikace v nich běžící (weby, maily a podobné úlohy, databáze jsou na vyhrazených serverech),
- možnost růstu – nechci skončit na tom, že nebude kam píchnout další disky,
- možnost upgrade bez výpadku služeb nebo jen s minimálním,
- známá technologie – nechceme blackbox o kterém nic nevíme,
- data budeme tlačit po ethernetu, NFS, iSCSI nebo AoE
- podporu od dodavatele HW,
- raw prostor min. 4TB
- cena do 300k Kč

S kolegy jsme pracovali pro distributora SUNu jako technici, takže víme jak to chodí s HW pro enterprise sféru. Věděli jsme tedy celkem přesně co nechceme – low-end řadu libovolného diskového pole. Low-end disková pole jsou většinou dost omezené záležitosti ve stylu „za hodně peněz málo muziky, hlavně když to má tu správnou samolepku“. Použitelná řešení od velkých výrobců HW (SUN, IBM, HP, NetApp) začínají zase na cenách mimo náš rozpočet :-(

Výběr skončil na řešení s využitím dvou serverů mezi kterými budou replikována data pomocí DRBD.

Architektura zvoleného řešení

Zvolená varianta nakonec dopadla následujícím způsobem. Pořídíme dva servery s dostatečnou diskovou kapacitou. Nainstalujeme na ně Linux, data budeme replikovat pomocí DRBD v režimu Primary-Secondary. Data budou vystavená přes NFS a iSCSI nebo AoE. Vysokou dostupnost zajistí heartbeat.

Výběr vhodného hardware

Hardware jsme vybrali od Supermicro, mají case, který umožňuje zastrkat až 24 hot-swap disků. V kombinaci s kvalitním RAIDem Areca 1680 s 2GiB cache zálohované baterkou máme dostatečně prostoru i výkonu. Uvedená RAID karta zvládne SATA i SAS, máme variantu s externím SAS portem, takže případné rozšíření až vyčerpáme všech 24 pozic pro disky je velmi snadné – připojíme externí box s disky a pokračujeme dál.

Pro DRBD je nutné zajistit aby byly oba servery stejně silné – nelze si říct, že na Secondary server použiju nějaký slabší (a hlavně levnější) stroj. Koupili jsme tedy oba servery v identické konfiguraci a se supportem na 3 roky, oprava další pracovní den po nahlášení. V případě výpadku jednoho serveru můžeme bez problémů fungovat na jeho dvojčeti.
K serverům jsme koupili i management rozhraní, které umožňuje po síti přes IPMI rozhraní i jejich vzdálený restart. To je velmi důležité – když se server sekne, tak aby mohl druhý fungující server převzít kontrolu, můsí mít možnost násilného restartu. Konfigurace tohoto mechanismu označovaného jako STONITH je popsaná v článku na STONITH – když se oba nody HA clusteru nedohodnout a musí se vzájemně sestřelit.

Instalace a konfigurace OS

Konfigurace sítě

Konfigurace síťe je relativně snadná, pokud si nepromícháte kabely při propojování :-)

Mezi servery doporučuji nepoužívat žádné další prvky – propojte je pěkně na přímo. Používáme tzv. „bonding“ kdy jsou spojené dvě síťové karty do jedné virtuální. Linux pak zajišťuje rozkládání zátěže mezi ně a v případě výpadku jedné z nich i převedení veškerého provozu na tu zbývající kartu.

Pro bonding jsem vybral dvě různé karty, jedna integrovaná na desce, druhá v PCIe slotu. Konfiguraci stačí zapsat do standardních konfiguračních souborů CentOSu a on už její nahození zajistí při každém startu sám.

Pro přímou komunikaci mezi servery používáme rozhraní bond0 a pro komunikaci s klienty bond1.

[root@node1 ~]# grep bond /etc/modprobe.conf
alias bond0 bonding
alias bond1 bonding
options bonding mode=balance-rr miimon=100

[root@node1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth0
BOOTPROTO=none
HWADDR=00:30:48:B9:6B:50
ONBOOT=yes
TYPE=Ethernet
SLAVE=yes
MASTER=bond0
USERCTL=no

[root@node1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth5
DEVICE=eth2
BOOTPROTO=none
HWADDR=00:30:48:9C:2C:80
ONBOOT=yes
TYPE=Ethernet
SLAVE=yes
MASTER=bond0
USERCTL=no

[root@node1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond1
BOOTPROTO=none
ONBOOT=yes
USERCTL=no
IPADDR=172.16.1.100
NETMASK=255.255.255.0

Každý ze serverů má tedy rozhraní bond0 pro komunikaci s druhým serverem a oba stroje jsou propojené napřímo. Další rozhraní je bond1, které slouží pro servírování dat klientům a poslední rozhraní je libovolné volné připojené do management síťě aby bylo možné stroje spravovat. Do management síťe je také zapojené management rozhraní serverů a raid karet.

Při konfiguraci síťe také nezapomeňte na nastevení iptables. Při jejich konfiguraci upravuji soubor /etc/sysconfig/iptables a následně aktualizuji konfiguraci pomocí iptables-restore < /etc/sysconfig/iptables. Jakmile zkusíte použít „klikací“ nástroj system-config-security, tak vám konfiguraci iptables totálně rozseká a znefunkční (proto také na uvedený soubor nastavuji atribut „i“ – chattr +i …).

Jumbo Frames

Aby byla zajištěna maximální propustnost sítě, doporučuji začít používat tzv. Jumbo Frames. Výchozí velikost je 1500b, podle toho jaké máte síťové karty a switche po cestě doporučuji použít vyšší hodnoty. Náš switch bez problémů zvládne velikost rámce 16k, intelky síťovký zvládají 9k – nastavil jsem tedy pro všechny sítťovky velikost MTU 9000.

DRBD

Konfiguraci DRBD 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 stačí.

Konfigurace DRBD pro naše použití je trochu specifická – na svazcích exportovaných z HW RAIDu mám nasazené LVM. V něm vytvořené volumy a ty jsou použité jako zařízení pro DRBD. Mám takto udělané 3 DRDB zařízení (podle konkrétních diskových skupin kde každá je určená pro jiná data) a nad nimi je zase nasazené LVM a v něm vytvořené volumy na kterých je souborový systém.

O první úroveň LVM se stará přímo distribuce – nahazuje ho při startu CentOS standardními skripty. DRBD nahazuje heartbeat, po naběhnutí DRBD heartbeat nahodí druhou úroveň LVM, připojí souborový systém a začne startovat další služby (IP adresy, NFS, AoE). Heartbeat má nastavená pravidla tak aby nahazoval služby tam kde je DRBD ve stavu Primary. Nemůže se tedy stát, že by na node0 nahodil DRBD a připojil souborový systém a na node1 nahodil NFS.

Jestli se vám zdá zbytečné nasadit LVM pod i nad DRBD, tak napište proč to tak nemůže být :-) Mě připadá variabilita takového řešení docela dobrým důvodem – mohu stěhovat data kam chci a jak chci aniž by to klienti poznali a zvětšování prostoru také není úplně k zahození.

LVM na DRBD

Pokud budete chtít tak jako já nacpat LVM na DRBD svazek, je nutné to povolit v konfiguraci /etc/lvm/lvm.conf – v sekci devices jsem upravil:

preferred_names = [ "^/dev/drbd", "^/dev/sd", "^/dev/mapper/" ]
filter = [ "a|/dev/drbd.*|","a|/dev/sd.*|","r|.*|" ]

Heartbeat

Instalaci Heartbeatu a Pacemakeru zvládnete pravděpodobně sami, na Internetu je k nalezení docela dost návodů. Jeden z možných: http://www.clusterlabs.org/wiki/Install
Docela pěkný popis konfigurace je také k nalezení na webu Novellu o SLESu.

Servery jsem propojil přes RS232 abych měl zaručený paralelní komunikační kanál k síťovým kartám – pro cluster je to docela důležité. Poižitá konfigurace heartbeatu (/etc/ha.d/ha.cf):

use_logd off
logfile /var/log/ha.log
debugfile /var/log/ha.debug
keepalive 1
warntime 10
deadtime 30
initdead 120
udpport 694
bcast bond0
baud 19200
serial /dev/ttyS0
node node0.domain.tld
node node1.domain.tld
auto_failback on
crm respawn
apiauth         mgmtd   uid=root
respawn         root    /usr/lib64/heartbeat/mgmtd -v
respawn         root    /usr/lib64/heartbeat/hbagent

Zajímavé části konfigurace CRM:

DRBD

Nejdřív si v clusteru nadefinuji jednotlivé svazky DRBD:

primitive drbd0 ocf:heartbeat:drbd \
	params drbd_resource="r0" \
	op stop interval="0" timeout="180"
primitive drbd1 ocf:heartbeat:drbd \
	params drbd_resource="r1" \
	op stop interval="0" timeout="180"
primitive drbd2 ocf:heartbeat:drbd \
	params drbd_resource="r2" \
	op stop interval="0" timeout="180"

Chci aby všechny DRBD svazky nabíhaly do Primary stavu na stejném serveru, proto jsem je seskupil do grp_drbd. Svazky nahazuji najednou a pouze tak aby byl vždy jeden server ve stavu Master (~Primary pro DRBD, definice ms_drbd). Spouštím je na preferovaném uzlu clusteru (pravidlo loc-drbd). Protože je cluster symetrický a nastavený do režimu failover, bude v případě nedostupnosti tohoto uzlu (node1.domain.tld) použit uzel druhý.

group grp_drbd drbd0 drbd1 drbd2 \
  meta migration-threshold="2" failure-timeout="180s"

ms ms_drbd grp_drbd \
  params clone_max="2" clone_node_max="1" master_max="1" \
master_node_max="1" notify="yes" globally_unique="false" target_role="stopped" \
  meta target-role="Started"

location loc-drbd ms_drbd \
  rule $id="loc-drbd-rule" $role="Master" inf: #uname eq node1.domain.tld

Jak jsem psal, nad drbd je zase LVM, je třeba ho tedy také nadefinovat. V rámci zjednodušení následného zapisování pravidel případně rozšiřování konfigurace jsem všechny LVM svazky vsadil do jedné skupiny (grp_lvm).

primitive lvmdrbd0 ocf:heartbeat:LVM \
  params volgrpname="vgrep0" exclusive="truemeta" start="45" stop="45"
primitive lvmdrbd1 ocf:heartbeat:LVM \
  params volgrpname="vgrep1" exclusive="truemeta" start="45" stop="45"
primitive lvmdrbd2 ocf:heartbeat:LVM \
  params volgrpname="vgrep2" exclusive="truemeta" start="45" stop="45"

group grp_lvm lvmdrbd0 lvmdrbd1 lvmdrbd2 \
  meta target-role="Started"

Souborové systémy na tomto LVM je třeba také připojit, zase to musí obsloužit Heartbeat:

primitive fs1 ocf:heartbeat:Filesystem \
  params device="/dev/vgrep0/lv0" fstype="xfs" directory="/export/d0" options="noatime"
primitive fs2 ocf:heartbeat:Filesystem \
  params device="/dev/vgrep1/lv0" fstype="xfs" directory="/export/d1" options="noatime"
primitive fs3 ocf:heartbeat:Filesystem \
  params device="/dev/vgrep2/lv0" fstype="xfs" directory="/export/d2" options="noatime"
primitive fs4 ocf:heartbeat:Filesystem \
  params device="/dev/vgrep2/lv1" fstype="xfs" directory="/export/clust" options="noatime"

group grp_fs fs1 fs2 fs3 fs4 \
  meta target-role="Started"

Aby všechny služby startovaly na správné straně clusteru, tedy na té kde je DRBD ve stavu Primary, je třeba nadefinovat „colocation“ pravidla:

colocation grp_fs_on_grp_drbd inf: grp_fs ms_drbd:Master
colocation grp_lvm_on_grp_drbd inf: grp_lvm ms_drbd:Master
colocation grp_vps_on_grp_drbd inf: grp_vps ms_drbd:Master

Služby sice nastartují na správné straně, ale asi v nesprávném pořadí, proto ještě pořadí explicitně určím:

order ord_grp_fs_after_grp_lvm inf: grp_lvm:start grp_fs:start
order ord_grp_lvm_after_ms_drbd inf: ms_drbd:promote grp_lvm:start

Jak vidíte, pravidla popisující na které straně cluster nahodí služby a v jakém pořadí zapisuji již jen přes skupiny – je to tak přehlednější. Názvy těch pravidel se snažím volit co nejvíc popisné abych se v tom snadno orientoval, stejně jako v případě názvů skupin a služeb.

Export dat ke klientům

Ata over Ethernet – AoE

Na straně serveru je nutné nainstalovat vblade (teda nutné, existují i jiné aoe targety, ale vblade znám), který zajistí export dat. Exportovaná dat jsou obrazy disků pro XEN, tedy velké soubory.
Veškerá konfigurace vblade se zadává při startu, je tedy třeba jí zapsat do CRM. Pro spouštění je možné použít skript ocf:heartbeat:AoEtarget, ale ten neumožňuje zadání dalších příznaků, které jsou pro mě důležité, -d a -s. Umožňují totiž v novém vblade exportovat data s příznakem O_DIRECT a O_SYNC. Skript jsem tedy upravil a pojmenoval AoEtargetKl. Poslední verze vblade je důležitá – chová se stabilněji. Při provozu doporučuji věnovat trochu času čtení dokumentace a ladění sítě pro kombinaci vblade a Jumbo Frames.

primitive aoedomU1 ocf:heartbeat:AoEtargetKl \
  params binary="/usr/local/sbin/vblade" \
device="/export/d1/domU1.img" nic="bond1" shelf="11" slot="0" vbladeparams="-d -s"
primitive aoedomU2 ocf:heartbeat:AoEtargetKl \
  params binary="/usr/local/sbin/vblade" \
device="/export/d1/domU2.img" nic="bond1" shelf="12" slot="0" vbladeparams="-d -s"
group grp_aoe aoedomU1 aoedomU2
	meta target-role="Started"
colocation grp_aoe_on_grp_drbd inf: grp_aoe ms_drbd:Master
order ord_grp_aoe_after_grp_fs inf: grp_fs:start grp_aoe:start

Docela prima u AoE je, že na straně klienta se při spouštění (tedy modprobe aoe) dá zadat parametr jak dlouho má klient čekat na timeout serveru. Přehození clusteru z jednoho nodu na druhý tedy aoe přežije velmi snadno, stačí nastavit rozumný timeout a není nutné řešit multipathing.

NFS

Konfigurace NFS bude v dalším zápisku.

Konfigurace DRBD a řešení situace „Split-Brain“

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

STONITH – když se oba nody HA clusteru nedohodnout a musí se vzájemně sestřelit

STONITH je mechanismus k řešení sporů ohledně přístupu ke zdrojům/službám clusteru. V rámci clusteru se musí vždy jednotlivé uzly dohodnout kde která služba poběží – tzv. fencing. Pokud se uzly dohodnou, vše je v pořádku. Když se náhodou nedohodnou, přijde ke slovu STONITH – sestřelení protějšího uzlu, který danou službu zadržuje a nechce vydat.

Konkrétní případ:

Při konfiguraci NFS clusteru jsem nastavil všechny potřebné služby – spouštění DRDB, LVM, Filesystem, IP adresy pro NFS a NFS samotné. DRBD je v režimu primary/slave = služba může běžet pouze na jednom z uzlů clusteru. Při studeném startu clusteru vše naběhlo správně a fungovalo, ovšem při migraci služby mezi uzly clusteru vždy nastala situace, že stávající aktivní uzel nechtěl uvolnit souborový systém aby se odmountoval a proto nešlo přehodit DRBD na druhý uzel. Cluster to vyřešil jednoduše – několikrát zkusil zda umount projde a když zjistil, že ne tak odstřelil porouchaný uzel (ten který nechtěl uvolnit filesystem).

Cluster po odstřelení vadného uzlu mohl správně nahodit DRDB, LVM, přimountovat souborový systém, nahodit IP a nfsd a vše bylo v pořádku. Tedy dokud jsem nechtěl zase přemigrovat služby zpátky po naběhnutí odstřeleného uzlu – vše se opakovalo.

STONITH mechanismus v tomto případě „řešil“ situaci rozbitého skriptu pro nfs. Závadu jsem vyřešil – opravil jsem rozbitý skript pro ovládání NFS. Skript pro ovládání NFS totiž při ukončení nechal běžet některé procesy a ty neuvolnily souborový systém. Na tom všem to selhávalo.

Má konfigurace STONITH je následující:

Servery a jejich management rozhraní přístupné po síti přes IPMI:

  • server: node0.domain.tld, IPMI: 179.100.1.72
  • server: node1.domain.tld, IPMI: 179.100.1.70

V management rozhraní každého serveru jsem vytvořil uživatele „stonith“ s právy pro restart serveru.
Přes program crmadmin jsem v konfiguraci CRM vytvořil 2x stonith resource – vždy pro daný server. Pomocí pravidel (location) jsem každý resource umístil na protější uzel – tak aby služba pro restart barzini.klenot.eu běžela na uzlu tommasino a naopak.

primitive stonith-node1 stonith:external/ipmi \
        params hostname="node1.domain.tld" ipaddr="179.100.1.70"\
                      userid="stonith" passwd="HESLO" interface="lan"
primitive stonith-node0 stonith:external/ipmi \
        params hostname="node0.domain.tld" ipaddr="179.100.1.72"\
                      userid="stonith" passwd="HESLO" interface="lan"
location loc-stonith-node1 stonith-node1 \
        rule $id="loc-stonith-node1-rule" -inf: #uname ne node0.domain.tld
location loc-stonith-node0 stonith-node0 \
        rule $id="loc-stonith-node0-rule" -inf: #uname ne node1.domain.tld

Postup úpravy konfigurace clusteru

Nejdříve si vypíšu dostupné stonith moduly:

[root@barzini ~]# crm ra list stonith
apcmaster               apcsmart                baytech
bladehpi                cyclades                external/drac5
external/hmchttp        external/ibmrsa         external/ibmrsa-telnet
external/ipmi           external/kdumpcheck     external/rackpdu
external/riloe          external/sbd            external/ssh
external/vmware         external/xen0           external/xen0-ha
ibmhmc                  ipmilan                 meatware
null                    nw_rpc100s              rcd_serial
rps10                   ssh                     suicide
wti_nps                 

Protože mám dostupné IPMI na serverech přes lokální síť, použiju external/ipmi modul. Možnosti konfigurace modulu zjistím následujícím příkazem:

[root@barzini ~]# crm ra meta external/ipmi stonith
IPMI STONITH external device (stonith:external/ipmi)

IPMI-based host reset

Parameters (* denotes required, [] the default):

hostname (string): Hostname
    The name of the host to be managed by this STONITH device

ipaddr (string): IP Address
    The IP address of the STONITH device

userid (string): Login
    The username used for logging in to the STONITH device

passwd (string): Password
    The password used for logging in to the STONITH device

interface (string): IPMI interface
    IPMI interface to use, such as "lan" or "lanplus"

Operations' defaults (advisory minimum):

    start    timeout=15
    stop     timeout=15
    status   timeout=15
    monitor  timeout=15 interval=15

Spustím tedy konfiguraci a napíši potřebné „příkazy“ pro vytvoření stonith zařízení, výsledek mohu ověřovat příkazem „show“, který vypíše aktuální stav. Konfiguraci potvrdím příkazem „commit“ a protože pracuji na živé konfiguraci běžícího clusteru, budou okamžitě nově vytvořená zařízení stonith spuštěna na správných uzlech clusteru:

[root@barzini ~]# crm configure
crm(live)configure# primitive stonith...
...
...
crm(live)configure# commit

Na závěr by bylo vhodné STONITH otestovat – pro základní test stačí na jednom z uzlů násilně zabít heartbeat pomocí „pkill -9 heartbeat“.

Sdílené úložiště pro HA cluster

Při konfiguraci vysoké dostupnosti služby pomocí HA clusteru (napřílad Heartbeat) každý pravděpodobně narazí na potřebu sdíleného úložiště. Toto sdílené úložiště musí být dostupné ze všech uzlů clusteru, možností jak to řešeit je více. Nejpoužívanější variantou v tzv. enterprise sféře je hardwarové diskové pole s více řadiči a v některých případech i vícecestným připojením k jednotlivým serverům (uzlům clusteru). Disové pole se dříve připojovalo přes SCSI rozhraní, které je dnes považováno za mrtvé. Náhradou za SCSI je Fibre Channel rozhraní využívající optických vláken. Toto řešení je léty provozu v těch nejnáročnějších podmínkách perfektně prověřené, ale je drahé a mnoho menších zákazníků na něj nemá – ceny se pohybují v milionech až desítkách milionů korun v závislosti na požadované konfiguraci.

Levnější variantou může být připojení diskového úložiště přes ethernet v kombinaci s levnějším HW diskovým polem, které umožní připojení dvou serverů pro HA cluster úložiště a nad ním lze pototé postavit HA cluster pro požadovanou službu ( úložišti se pak uzly clusteru připojují např přes NFS, iSCSI nebo jiný vhodný protokol). V situaci kdy nechceme nebo nemůžeme použít klasické HW diskové pole možné použít DRBD.

Základní funkčnost DRBD si lze představit jako RAID1 (mirror) přes síť. Blokové zařízení DRBD se z hlediska uživatele chová podobně jako sdílené diskové pole připojené ke oboum počítačům najednou – je možné na zařízení vytvářet souborový systém, PV lvm nebo využívat přímo dané zařízení jako „raw“ device. Od verze 0.8 umožňuje DRDB režim Primary/Primary což znamená, že lze k „mirroru“ vytvořenému přes DRBD přistupovat z obou uzlů drdb clusteru a rovnoceně na ně zapisovat. Tato vlastnot nové verze DRBD umožňuje implemetovat takové věci jako je souborový systém GFS nebo OCFS2 a tím zpřístupnit data na obou uzlech clusteru. Také je možné provádět živou migraci virtuálních strojů (domU) XENu.

[img_assist|nid=5|title=Architektura DRBD|desc=|link=none|align=center|width=320|height=295]

HW implementace propojení

  • Fibre Channel – klasika v enterprise sféře používající nejčastěji 1Gbps (dnes již zastaralé), 2Gbps, 4Gbps nebo 8Gbps rychlost připojení optickým vláknem.
  • SCSI – UltraSCSI 160 nebo UltraSCSI 320 připojení bylo dříve často používané, dnes je již nahrazeno FC nebo SAS připojením. Se SCSI se u nových zařízení nepotkáte.
  • SAS – pokračování SCSI (Serial Attached SCSI), v určité míře kompatibilní se SATA. Podrobný popis je dostupný na Wikipedii.

Připojení přes síť

  • iSCSI – protokol zpřístupňující vzdálená disková zařízení přes TCP/IP. Protokol je směrovatelný a použitelný na velké vzdálenosti. Existují specializované HBA pro iSCSI do serverů. Některá pole implementují iSCSI nativně. V případě, že pole iSCSI neimplementuje a je nutné jeho využití, je možné postavit HA Cluster ze serverů nad klasickým polem připojeným přes SAS nebo FC, který bude iSCSI zpřístupňovat.
  • GNBD/NBD – v Linuxu nativní způsob jak vyexportovat z HA clusteru diskové zařízení, které je poté možné v klientovi používat podobně jako lokální disk. Server exportující NBD zařízení musí podobně jako v případě iSCSI fungovat v režimu HA clusteru. Menší zajímavost: NBD vytvořil český programátor Pavel Machek. GNBD/NBD je tedy zajímavý způsob připojení úložiště do klienta a sám musí být v režimu HA clusteru nad nějakým konkrétním úložištěm – nejčastěji nad DRBD nebo klasickým diskovým polem.
  • DRBD je software na úrovni linuxového jádra implementující blokové zařízení, které umožňuje sdílet data mezi dvěmi počítači. Základní funkčnost DRBD si lze představit jako RAID1 (mirror) přes síť.
  • Síťový souborový systém je také jednou z možností jak implementovat úložiště pro vysoce dostupné služby. Reálné využití v unixovém světě najde pravděpodobně NFS. Samozřejmě je třeba počítat s HA clusterem i na serverech nabízejicích síťový souborový systém.
  • „Vlastní řešení“ – některé programy implementují vlastní způsob řešení sdílení dat. Jako příklad lze uvést adresářové servery (LDAP), které lokálně využívají například berkley db a mezi jednotlivými uzly data replikují v režimu tzv. multimaster replikace. To znamená, že změna zapsaná na jakýkoliv uzel clusteru se okamžitě promítne do ostatních uzlů. Další možností je například replikace paměti používaná u aplikačního serveru Glassfish, který si informace o sezení (session) předává mezi jednotlivými uzly. V případě Glassfishe je možné replikaci paměti nahradit HADB což je vlastně HA cluster databáze, která podobnou replikaci zajišťuje sama (a není limitována takovou věcí jako je RAM aplikačních serverů).