HA (High Availability) cluster építése
1 Elméleti alapok
1.1 Computer cluster – számítógép fürt
Egymással összekapcsolt számítógépek, amelyek együttműködve a fürt számára definiált funkciókat valósítják meg. A fürtön belüli gépek kívülről nem látszanak. A fürt mint egyetlen entitás nyújt szolgáltatásokat.
1.2 HA Clusters (Nagy rendelkezésre állású fürtök, feladatátvételi fürtök)
Olyan számítógép fürtök, amelyek a fürtők által nyújtott szolgáltatások rendelkezésre állását próbálják meg növelni. A szolgáltatásokat általában a fürt egyik tagja nyújtja, míg a többi tag annak meghibásodása esetén átveszi a szerepét, így növelve a szolgáltatások rendelkezésre állását.
1.2.1 HA cluster modellek
- Shared disk (Megosztott lemezes) modell – a fürt rendelkezik egy adattárolóval, amelyet a fürttagok egy közös interfészen keresztül érhetnek el konkurens módon.
- Shared nothing (Megosztott elem nélküli) modell – Minden logikai és fizikai egységet egyszerre csak egy fürttag birtokolhat.
- Replicated storage (Replikált lemezes) modell - Általában 2 fürttagból álló fürt, ahol egy fürttag (elsődleges fürttag) nyújtja a szolgáltatást és tükrözi az adatokat a többi (másodlagos) fürt számára. Ha az elsődleges fürttag kiesik, akkor egy másodlagos veszi át a szerepít (elsődlegessé válik).
1.2.2 HA cluster fogalmak
- failover – a szolgáltatások kiszolgálásának átvétele a meghibásodott fürttagtól.
- failback – a szolgáltatások kiszolgálásának visszaadása a megjavított fürttagnak.
- split barin – bizonyos meghibásodások esetén előfordulhat, hogy a fürt több partícióra esik szét, amely partíciók nem tudnak egymásról, így mindegyik partíció fürtöt fog képezni és megpróbálja nyújtani az eredeti fürt szolgáltatásait. Ez igen hamar az adatok korrupciójához és hibás kiszolgáláshoz vezet.
- STOMITH (Sooth The Other Machine In The Head) – split barin elkerülését célzó technika. Hiba esetén a hibás fürttagot egy másik fürttag újraindítja (fejbe lövi).
- Quorum - split barin elkerülését célzó technika. Amennyiben a fürt több részre esik szét akkor csak a legtöbb fürttagot tartalmazó rész működjön (ezen fürttagok alkotnak quorumot). Amennyiben a fürttagok száma páros, azért, hogy a többség biztosítva legyen a fürthöz hozzávesznek egy erőforrást (általában merevlemez (quorum disk)) amely fürttagként viselkedik.
- Erőforrás - erőforrásnak nevezhetünk minden olyan logikai vagy fizikai eszközt és szolgáltatást amelyet a fürt használ/kezel.
- CRM (Cluter Resource Management, Fürt erőforrás menedzsment) - A fürt erőforrásinak kezelését megvalósító eszköz.
2 HA cluster építése mysql szerver számára
2.1 felhasznált eszközök
Több program segítségével oldottam meg a feladatot. A fürtöt a Pacemaker CRM projekt segítségével OpenAIS fürt keretrendzsert felhasználva készítettem. Mivel az OpenAIS shared nothing modell alapján működik, a szerver adatainak a tükrözését a fürttagokra a DRBD projekt segítségével oldottam meg.
Ezen projektek mindegyikére igaz, hogy nem rendelkeznek stabil APIval, így az itt leírtak újrafelhasználhatósága korlátolt.
2.1.1 Pacemaker
Nagy rendelkezésre állású fürtökhöz készült CRM rendszer. A Linux HA projekt CRM részének leválasztásából fejlődött ki. két fürt keretrendszerrel képes együttműködni:
- heartbeat - a Linux HA project része, használata nem ajánlott.
- OpenAIS - ajánlott keretrendszer
2.1.2 OpenAIS
Az OpenAIS a Corosync általános fürt keretrendszert felhasználó, nagy rendelkezésre állású fürt keretrendszert megvalósító eszköz.
2.1.3 DRBD (Distributed Replicated Block Device)
Nagy rendelkezésre állás fürtökhöz készített, megosztott elem nélküli, replikált lemezes modellt követő, blokk eszközök tükrözésére való eszköz. A tükrözés valós idejű, transzparens (azaz a fürttagok számára átlátszó módon történik). Képes szinkron és aszinkron működésre is.
2.2 A példa rövid leírása
A példában 2 csomópontból álló replikált lemezes modellű fürtöt fogok létrehozni,amely, mysql szerver szolgáltatást fog nyújtani. Ehhez Ubuntu 9.10-es szervert használok. A szolgáltatást nyújtó programokat egy külön partíción helyezem el amelyet a /services mappába mountolok. Ezt a partíciót fogom DRBD segítségével tükrözni. Ezután konfigurálom az OpenaAIS keretrendszereket a csomópontokon, majd amikor a még nem beállított fürt felállat az OpeanAIS segítségével, konfigurálom a csomópontokat a Pacemaker használatával.
(Itt jegyezném meg, hogy az OpenAIS APIja nagyon erősen változik a fejlesztése közben. A neten található dokumentumok által használt programok (pl.: aiskeygen) jó része egyáltalán nem található meg az általam használt OpenAIS verzióban, így az alatta lévő Corosync segítségével konfiguráltam a csomópontokat. A konfiguráció menete (a konkrét parancsok, beállító fájlok) nem változik, csupán a programokat hívják másképp.
2.3 A példa
Először feltelepítetjük az Ubuntu 9.10 szervert mindkét csomópontra. A csomópontokban egy merevlemez van. Telepítés közben az alábbi módon particionáljuk a csomópontokat (/etc/fsab kimenet)
2.3.1 A csomópontok partíciói
# / was on /dev/sda2 during installation UUID=8125069d-3233-4792-b603-3b121a68a7bf / ext3 relatime,errors=remount-ro 0 1 # /boot was on /dev/sda1 during installation UUID=f9cf0557-9fad-4d02-a99b-4717f3889354 /boot ext2 relatime 0 2 # /drbd was on /dev/sda5 during installation UUID=b75b3bee-5ae7-4a98-bf86-cb1560b4c925 /drbd ext3 relatime 0 2 # /service was on /dev/sda6 during installation UUID=ba8ff678-27a4-4027-94cb-86cd6d7175c7 /service ext3 relatime 0 2 # swap was on /dev/sda3 during installation UUID=66723736-ffcc-43c9-aec9-3a21c3d67a0f none swap sw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0 /dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0 0
2.3.2 A szükséges programok telepítése
Telepítés után először felrakjuka szükséges programokat:
sudo apt-get install drbd8-utils pacemaker-openais mysql-server apache2
A DRBD minden tükrözött blokk eszközéhez szükség van egy partícióra ahol a partícióhoz tartozó DRBD metaadatokat a program tárolhatja. A tükrözendő adatokat az sda6 partíción tároljuk, amit a /service csatolási pontra mountolunk. A partícióhoz tartozó metaadatokat pedig z sda5 partíción fogjuk tárolni.
2.3.3 A DRBD és a hálózat beállítása
Mivel azt szeretnénk, hogy a Pacemaker mountolja majd a DRBD meghajtóit, ezért ki kell szedni a hozzájuk tartozó fstab bejegyzéseket.
# / was on /dev/sda2 during installation UUID=8125069d-3233-4792-b603-3b121a68a7bf / ext3 relatime,errors=remount-ro 0 1 # /boot was on /dev/sda1 during installation UUID=f9cf0557-9fad-4d02-a99b-4717f3889354 /boot ext2 relatime 0 2 # /drbd was on /dev/sda5 during installation # UUID=b75b3bee-5ae7-4a98-bf86-cb1560b4c925 /drbd ext3 relatime 0 2 # /service was on /dev/sda6 during installation # UUID=ba8ff678-27a4-4027-94cb-86cd6d7175c7 /service ext3 relatime 0 2 # swap was on /dev/sda3 during installation UUID=66723736-ffcc-43c9-aec9-3a21c3d67a0f none swap sw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0 /dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0 0
2.3.3.1 A metaadat partíció törlése
A metaadat partíciójának üresnek kell lennie, ha valamiért adat volt rajta azt töröljük:
sudo dd if=/dev/zero of=/dev/sda5
2.3.3.2 A hálózat konfigurálása
Ezután konfiguráljuk a hálózatot. Két hálózatot fogunk létrehozni. Egyet a DRBD adatforgalmához, egyet pedig a Pacemaker adatforgalmához (ezt lehet majd kívülről is elérni). Hozzuk létre a 2 hálózatot:
sudo nano /etc/network/interfaces
(az alpha csomópont adatai példaként)
auto eth1 iface eth1 inet static address 10.100.100.163 netmask 255.255.255.0 gateway 192.168.0.1 dns-nameservers gateway 192.168.0.1 auto eth2 iface eth2 inet static address 192.168.56.101 netmask 255.255.255.0
2.3.3.3 A hosztnevek beállítása
A DRBD konfigurációs fájljaiban a csomópontokra hivatkozni fogunk a neveikkel amit a DRBD hosztnévként is értelmez ezért be kell állítanunk ezeket hosztneveket:
sudo nano /etc/hosts
192.168.56.101 alpha.loc alpha 192.168.56.102 beta.loc beta
2.3.3.4 A DRBD konfigurációs fájljának beállítása
Ezután létrehozzuk a DRBD konfigurációs fájlját. Egy erőforrást fogunk létrehozni (r0), amiben beállítjuk a 2 csomópont adatait, sé azt, hogy hogyan használja őket a DRBD. Az adatokat szinkron módon akarjuk tükrözni, azaz az elsődleges csomópont írásának befejezése addig blokkolódik, amíg a másodlagos csomóponton az írás be nem fejeződött (protocol C). A csomópont 60 másodpercig vár mielőtt átváltana (degr-wfc-timeout 60). A kapcsolat titkosított ahol a közös kulcsot beállíthatjuk (shared-secret). Diszk hiba esetén szeretnék, ha lekapcsolná azt (on-io-error detach). Megadjuk mindkét csomóponton, hogy mely partíciókat akarjuk tükrözni, illetve melyek a metaadatok partíciói. Megadjuk, hogy milyen néven hozzon létre a DRBD blokkeszköz bejeygzést a /dev/ könyvtárba (drbd0). Megadjuk a csomópontok IP címeit és portszámát. (Ne felejtsük el átengedni a forgalmat a tűzfalon).
sudo nano /etc/drbd.conf
common { syncer { rate 10M; } } resource r0 { protocol C; startup { wfc-timeout 30; degr-wfc-timeout 60; } disk { on-io-error detach; } syncer { rate 10M; al-extents 257; } net { cram-hmac-alg sha1; shared-secret "seeeecreeet"; } on alpha { #hostname device /dev/drbd0; disk /dev/sda6; #The partition you want to mirror address 192.168.56.101:7788; # the cluster interconnect IP meta-disk /dev/sda5 [0]; #The partition for the meta-data } on beta { device /dev/drbd0; disk /dev/sda6; address 192.168.56.102:7788; meta-disk /dev/sda5 [0]; } }
2.3.3.5 A DRBD kernelmodul betöltése
A DRBD modulját tartalmazza az alap ubuntu telepítés, de alapból nincs bekapcsolva (ezt ellenőrizhetjük a lsmod | grep drbd paranccsal) ezért azt be kell kapcsolnunk.
sudo modprobe drbd
Mivel a drbd szeretné használni a tükrözött és a metaadat partíciókat (sda6, sda5), ha azok mountolva vannak umountoljuk őket.
sudo umount /dev/sda5 /dev sda6 /service /drbd
2.3.3.6 Az erőforrás létrehozása és használatba vétele
Most már készen állunk arra, hogy a konfigurációs fájl alapján létrehozzuk az erőforrásunkat (r0).
sudo drbdadm create-md r0
Ha valamiért nem sikerült, akkor újbóli próbálkozás előtt ne felejtsük el törölni a metaadatokat tároló partíció adatait (sudo dd if=/dev/zero of=/dev/sda5).
Ezután csatoljuk az erőforrást, szinkronizáljuk és csatlakozunk hozzá.
sudo drbdadm attach r0 sudo drbdadm syncer r0 sudo drbdadm connect r0
Ha ez idáig sikerült az egyik csomóponton, akkor az idáig megtett lépéseket meg kell ismételnünk a másik csomóponton (ha még nem tettük meg).
Ha mindkét csomópontot beállítottuk akkor ellenőrizhetjük a csomópontok állapotát:
sudo drbd-overview
a várt kimenet:
0:r0 Connected Secondary/Secondary Inconsistent/Inconsistent C r---
2.3.3.7 Az erőforrás szinkronizálása a csomópontok között
Jelenleg a DRBD még nem tudja, hogy melyik csomópontot szeretnénk elsődlegessé tenni, ezért mindkettő másodlagos (Secondary/Secondary), és az adatok még nincsenek szinkronizálva (Inconsistent/Inconsistent).
Amelyik csomópontott szeretnénk elsődlegessé tenni, adjuk ki a következő parancsot:
sudo drbdadm -- --overwrite-data-of-peer primary all
Ez elsődlegessé teszi a csomópontot, és mekezdi az adatok szinkronizációját. Ezt ellenőrizhetjük is a drbd-overview segítségével. HA a szinkronizáció befejeződött, akkor a következőhöz hasonló kimenetet kapunk:
0:r0 Connected Primary/Secondary UpToDate/UpToDate C r---
2.3.3.8 A /etc/fstab kiegészítése
Hogy a failover működhessen, engedélyeznünk kell a drbd0 eszköz csatolását a /services csatolási pontra. Nyissuk meg a /etc/fstab fájlt:
sudo nano /etc/fstab
és adjuk hozzá a következő sort:
/dev/drbd0 /service ext3 defaults 0 2
A DRBDvel kapcsolatos beállításokat ezzel befejeztük.
2.3.4 Az OpenaAIS (Corosync) beállítása
A szócikk írásának pillanatában a Pacemakerhez tartozó OpanAIS verziót csak Cororsync programokon keresztül lehet beállítani, mivel több az OpenAIS beállításához lényeges programot eltüntettek ebből az OpenAIS verzióból.
2.3.4.1 Atentikációs kulcs generálása és beállítása minden csomóponton
Először autentikációs kulcsot generálunk a fürt számára és azt beállítjuk minden csomóponton. Ehhez először 1 csomóponton legeneráljuk a kulcsot:
sudo corosync-keygen
majd átmásoljuk ezt a kulcsot a többi csomópontra és beállítjuk a másolatok jogosultságait.
Azon a gépen amelyen létrehoztuk a fájlt (pl.: alpha) lépjünk be a másik gépre (beta).
scp /etc/corosync/authkey beta:
Állísuk be a másolat jogosultságait a béta csomóponton:
sudo mv ~/authkey /etc/corosync/authkey sudo chown root:root /etc/corosync/authkey sudo chmod 400 /etc/corosync/authkey
2.3.4.2 A Corosync konfigurációs fájljainak létrehozása/módosítása
Az Ubuntu 9.10-es verziója a telepítés után rendelkezik egy példaértékekkel beállított /etc/corosync/corosync.conf konfigurációs fájllal. Nekünk ez ehhez a példához jórészt megfelel. Csupán az interface rész bindnetadress alpontját kell módosítani. Ide a helyi alhálózat címe kell (amely a Pacemaker adatai fogja forgalmazni).
Nyissuk meg a fájlt:
sudo nano /etc/corosync/corosync.conf file
Keressük meg és módosítsuk a következő szekciót:
interface { # The following values need to be set based on your environment ringnumber: 0 bindnetaddr: 192.168.0.0 #<-- Ezt akarjuk az alhálózat címére beállítani mcastaddr: 226.94.1.1 mcastport: 5405 }
2.3.4.2.1 A Corosync működésének engedélyezése
Alaptelepítésben a Corosync működése le van tiltva a /etc/default/corosync konfigurációs fájljában. Az ebben a fájlban található no értéket kell yes-re módosítnai.
Nyissuk meg a fájlt:
sudo nano /etc/default/corosync
és engedélyezzük a Corosync működését. A módosított fájl:
# start corosync at boot [yes|no] START=yes
2.3.4.3 Multicast adatforgalom engedélyezése
Amenyniben a multicast adatforgalom tiltva van a tűzfalban, azt engedélyezni kell, hogy a Corosnyc működhessen.
2.3.4.4 A Corosync elindítása
Ha mindent beállítottunk, akkor elindíthatjuk a szolgáltatást:
sudo /etc/init.d/coroync start
Megint kiemelném, hogy az idáig leírtakat minden csomóponton el kell végezni.
Ha minden csomóponton megy a Corosync, akkor teszetlhetjük a crm_mon programmal. Az --one_shoot paraméter arra utasítja, hogy ne folyamatosan monitorozzon, csak egyszer nézzen rá a fürtre és írja ki az eredményt. A -V paraméter részletesebb lekérdezést eredményez.
sudo crm_mon --one-shot -V
Ha minden tükéletesen működik, akkor egy a következő hasonló kimenetet kell adjon a program:
rm_mon[2196]: 2009/12/23_21:08:18 ERROR: unpack_resources: No STONITH resources have been defined crm_mon[2196]: 2009/12/23_21:08:18 ERROR: unpack_resources: Either configure some or disable STONITH with the stonith-enabled option crm_mon[2196]: 2009/12/23_21:08:18 ERROR: unpack_resources: NOTE: Clusters with shared data need STONITH to ensure data integrity ============ Last updated: Wed Dec 23 21:08:18 2009 Stack: openais Current DC: alpha - partition with quorum Version: 1.0.5-3840e6b5a305ccb803d29b468556739e75532d56 2 Nodes configured, 2 expected votes 0 Resources configured. ============ Online: [ beta alpha ]
Ha nem szerepel minden csomópont az Online részben (az adott csomópont stanby státuszúként van megjelölve) akkor megpróbálhatjuk manuálisan online állapotba hozni a következő a standby csomóponton kiadott parancsokkal:
sudo crm crm(live)# node crm(live)node# online crm(live)node# bye
Amennyiben így sem sikerül a fenti állapothz jutni, akkor érdemes minden csomópontot újraindítani, mert lehetséges, hogy megoldja a a problémát.
A fenti részen látható, hogy a Corosync panaszkodik, mivel nem állítottunk be neki a STONITH (ugyanaz mint a STOMITH csak a Machine helyett Node van a rövidítésben) működéséhez szükséges paramétereket, ez normális ennél a résznél.
--Kishonti István 2009. december 24., 19:49 (UTC)