Két node-os load balancing HA cluster

Linux-haladó

Hello,

A $subj.-et próbálnám megvalósítani, bár lehet hogy minden nem fog menni egy config-ban. Olvastam manual-t rendesen :), egyelőre a koncepcióval van nagyobb bajom mintsem az eszközökkel. A következőt szeretném:

Két node. Egyik izmosabb (node0), disk i/o miatt alkalmasabb adatbázist futtatni, mint a másik. Szeretnék egy haproxy-t rakni rá, hogy a slave ne csak unatkozzon, hanem a két node elosztva kapja a terhelés közös adatbázist használva. Ha az egyik kihalna, akkor a heartbeat felhúzná a publikus ip-t a másikra és működne szépen tovább minden. Problémáim, kérdéseim:

1. DRBD-t felhúztam két kísérleti vmware alatt futó lenny-re.
Pri/Sec módban megy szépen. Nekem viszont a session kezelés miatt szükséges lenne írnom _mindkét_ node-on a /ha/data/sites könyvárba.

2. A mysql lehetséges HA megoldásait már többször átrágtam, de nem találtam meg az igazit. A kiszolgált oldalak 95%-a PHP alapú mysql-t használó dinamikus oldal. A terhelést nézve egyelőre elég, ha az egyik node-on futó mysql példányra csatlakozik mindkét node illetve nem is tud nagyon mást tenni, mivel írni is kell tudni mindkettőnek. Lehetne master-master replikáció is, de kicsit félek tőle.

[node1] .............heartbeat.............. [node0] haproxy (80.x.x.x eth0)
apache2-----------------------------------apache2
---------------------------------------------proftpd
[ vhost-ok DRBD-vel /ha/data/sites ]
mysql 5.x slave <-----------------------> mysql 5.x master

Előre is köszönöm a javaslatokat.

  • 4875 megtekintés

( tompos v | 2010. 03. 16., k – 22:41 )

Semmi kerdest nem raktal fel.

tompos

1. Elmeletileg igen. Viszont az ocfs2-t sokan kopkodik szerte a neten, javasolt inkabb a gfs (nem gfs2) hasznalata. Tudtommal. Bevallom, en csak primary/slave drbd-t hasznaltam, es kicsit mas koncepcioban, de ennek igazabol nem szabad szamitania.

2. Nekem a mysql replikaciot keveset tesztelve, kicsit nyuzva, kicsit konfigolva nem mukodott, allanoan szetesett. Lehet (valoszinu), hogy be lehet rendesen konfigolni, de az app oldalarol akkor is meg kell tamogatnod rendesen. Viszont ha drbd-re rakod, akkor 100%, hogy lesz vmennyi elmeleti adatvesztesed.
Tehat ha rendesen ki tudod tesztelni, akkor a replikacio javasolt, szerintem.

3. Egy rovid pillantas alapjan: igen.

A haproxy-t miert kevered bele, miert nem round robin leosztas es kesz?

1.
Ok, próbálom akkor a gfs-t.
2.
Szóval ne reménykedjek :). Master-slave kőbalta lesz szerintem, ebből kihagyom a drbd-t
3.
Tetszett a haproxy. A sima round-robin-nál minden második kérést szolgálja csak ki az egyik node kiesésekor, de ez majdnem részletkérdés.

Köszi.

( egeresz | 2010. 03. 17., sze – 00:38 )

Szia,

altalaban a HA es a load balancing nem szokott egyszerre menni. Altalaban azert, mert a geprendszernek 1 geppel is mukodokepesnek kell lennie, tehat az igenyelt szolgaltatasnak be kell fernie a (kisebbik) gepbe.

Mondjuk lehet azt mondani, hogyha el mind a 2 gep, akkor jobb valaszidokkel nyujtjuk a szolgaltatast, ha failover van, akkor rosszabb valaszidokkel. Oks, csak tudjad.

Diszk IO igenyes adatbaziskezeles terheleselosztasa 2 gepre
amennyiben jol el tudod vagni, hogy pl ket adatbazisod van, 20 tabla az egyikben, 20 tabla a masikban, es a kliens mindkettohoz konnektal (es az alkalmazas nem igenyli soha a ket fele osszefesuleset). vagy a userek fele az egyik gephez, a masik fele a masik gepre konnektal.
Amennyiben nem tudod jol elvagni, magyaran mindenkeppen 1 adatbazis kell, akkor hm, azt mondanam, hogy nem lehet egyszeruen 2 gepre bontani.
A kozos diszket (draga) external storagevel, vagy mastar/master DRBD -vel meg lehet oldani. Azonban erre cluster enabled FS kell, (ocfs, gfs) amik jellegzetessegei, hogy halozaton osztjak meg a lockot. Ha erre teszel egy adatbaziskezelot, mindenfele szornyu teljesitmenyproblemaba (IO) utkozol, hiszen a cluster filesystemen minden lockot igenylo muvelet lassabb. (sokkal). Arrol nem is szolva, hogy az adott adatbaziskezelo kepes-e ilyen mukodesre (hiszen az adatbaziskezelonek is meg kell osztania a sajat lockjait az egesz clusterben)

CPU igenyes adatbaziskezeles elosztasa tobb gepre
Itt mar lehet valamirevalo eredmenyt elerni, ha nem a disk io a szuk, es meg a clustered FS iraslassito hatasa is belefer. Megis, a clustered FS helyett talan erdemesebb egy gepen local FS-sel megfogni, es NFS-en adni a masik gepnek a diszket, az adatbaziskezelonek ugy is el kell inteznie a sajat lockjait (a mysql-t nem ismerem).

Nem latok konnyu, jo megoldast erre a problemara, ugy tippelem, hogy most 2010-ben linuxszal es mysql-lel failoveres loadbalancingot 2 geppel nem fogsz csinalni. Ellentetben peldaul OpenVMS-sel es RDB-vel, ahol ez mar 1996-ban is priman ment.

altalaban a HA es a load balancing nem szokott egyszerre menni. Altalaban azert, mert a geprendszernek 1 geppel is mukodokepesnek kell lennie, tehat az igenyelt szolgaltatasnak be kell fernie a (kisebbik) gepbe.

- Ez menni fog.

Mondjuk lehet azt mondani, hogyha el mind a 2 gep, akkor jobb valaszidokkel nyujtjuk a szolgaltatast, ha failover van, akkor rosszabb valaszidokkel. Oks, csak tudjad.

- Pontosan ezt szeretném elérni.

Diszk IO igenyes adatbaziskezeles terheleselosztasa 2 gepre

- Jelenleg a mysql a szűk keresztmetszet a mostani konfigban. Gyorsabb diszk alrendszerre költözik hamarosan illetve másik gépre. De valami módon szükség lenne arra is, hogy ha az egyik elhasal, akkor a másik _még elfogadható szinten_ nyújtsa a szolgáltatás.

Valószínűleg a mysql az izmosabb gépre kerül, master-slave replikációval és nem lesz rá load balancing.

es mi volt a regi diszk alrendszer (ami lassu) es mi lesz a gyorsabb diszk alrendszer?
Szakmai kivancsisag csak.

Ha kiadod a 


sar -d 3 0

parancsot, akkor abban a tps valamint a avgqu-sz ertekek jellemzoen mik?
Nagyon megkoszonnem, ha egy fomusoridoben jellemzo tps + avgqu-sz erteket most, es az uj diszkalrendszer beuzemelese utan megirnal ide/nekem.
Csak gyujtom a tapasztalatot, semmi egyeb.

meg van mar veve az uj hw?
Az uj, az 1 buszon 2 darab (15k RPM) scsi diszkkel?

hany kotetes most a raid5? a raid5 jol viselkedik random read eseten, csak a random write teljesitmenye szar, de az nagyon.

ha csinalsz egy scsi buszt, rajta 2 darab 15k RPM diszkkel raid1 -ben, akkor a kinyerheto (random) teljesitmeny 540 IO/sec random read; 190 IO/sec random write.

Ha csinalsz egy 4 diszkes SATA linux sw raid10 tombot, es nagyon cselesen es ugyesen a SATA diszkeknek csak az elso 20%-25% -at hasznalod a RAID10 -be, a tobbit egyaltalan nem hasznalod, akkor kapsz egy 700 IO/sec random read; 280 IO/sec random write teljesitmenyu tombot.

1 szalra (1 kliensre) merve a 2 diszkes scsi megoldas gyorsabb (2-szer), mint a 4 diszkes alulparticionalt sata, viszont 20 szalra mar az utobbi a gyorsabb. Ugy nagyjabol 40 szalnal jon elo az az elmeleti hatarertek, amit fentebb irtam.

( Tyra3l | 2010. 03. 17., sze – 01:06 )

ha mindkettot irod, akkor nem tudsz replikalni koztuk (alapbol master-master felallasnal is passziv az egyik node-od, csak majdnem hot spare), ilyenkor inkabb sharding van (ilyenkor eloszthatod az irast), viszont akkor ket gepbol ha az egyik kiesik, akkor felborul a rendszered.
ha ezt azzal probalod kikuszobolni, hogy keresztbe szinkronizalsz drbd-vel akkor ha elo mysql alatt modositasz adatot, az garantalt adatvesztes, ha csak cold spare-ben csinalod (drbd aktiv passziv, halal eseten aktiv elengedi, drbd passziv aktivva valik, heartbeat athuzza az ipt majd elindul rajta a mysql) akkor meg gyakorlatilag minden irast megcsinalsz mindket gepen, szoval nem nyersz teljesitmenyt a sima mmm-hez(multi master mysql) vagy drbd-hez kepest.
mmm: majdnem hot spare, magas uptime, viszont nem feltetlen konzisztens (crashnel lehetnek nem kireplikalt rekordok, amik majd utkozni fognak merge-nel)
drbd aktiv-passziv felallas: nagyon konzisztens, viszont a failover(mysql recovery) nagy db-nel(sok tabla, vagy keves nagy) sokaig eltarthat, es addig ha nincs mondjuk egy read only mukodest kiszolgalni kepes slave-ed, akkor all az oldal.

ps: anno nezegettem haproxy-t, spockproxy-t, de nagy volt az overheadje, joint vagy nem tud, vagy tetu lassu, ha alkalmazasbol kell joinolni, akkor mar inkabb valami nosql megoldast hasznalnek, mert az megiscsak jobban skalazodik, mint egy kiherelt rdbms.

Tyrael

( lrbuzgan | 2010. 03. 17., sze – 21:57 )

Hello!

Amit tudok ajánlani klaszter megoldás az az, hogy legyen két fizijai vasad, amin virtualizálsz két gépet: db-master, db-slave. Ezek egymás között replikáljanak.
A virtuális gépeket építsd fel drbd-re, ami majd a virtuális gépeket szinkeli a másik node-ra. A HA pedig kapcsolgassa a virtuális gépekete és a drbd diszkeket.
A db-t pedig úgy kialakítani, hogy a masterre írsz és a slave-ről pedig lekérdezel.
Ez egy jól bevált összeállítás és nem kell load balancing, nagyobb forgalomnál sem. Ha meg sok a slow query akkor meg a lekérdezéseket kellene optimalizálni.

De ha viszont feltétlen kell a load balncing, akkor mysql-claser, amit ajánlani tudok. Csinálsz egy n darab node-os mysql-clastert, a managert fel lehet rakni a load balancerre, és a HA vezérelje a két load baancert. Most raktam össze egy, ilyen felállást és meg vagyok vele elégedve, de ennek is azért alap követelménye az optimalizált lekérdezések.

( sfeher v | 2010. 03. 29., h – 15:55 )

Továbbgondoltam.
(ami eddig kész: drbd primary/primary módban rajta gfs2.)

Heartbeat konfigolása jönne, szeretném szétosztani a szolgáltatásokat, amik _szükség esetén_ beférnek az egyik gép alá is.
Ez így festene:
------------
+ node0 +
------------

apache
mysql master

------------
+ node1 +
------------

apache
postfix
proftpd
mysql slave

Ha mindkettő megy akkor load balancing van a két apache között.
Ha node0 meghal, akkor a node1 a slave mysql-t fogja használni.
Ha node1 meghal, akkor ftp, postfix átköltözik a node0-ra.
Erre lenne jó valami ötlet, howto stb.
Köszi.

drbd primary/primary mysql ala?
ugye nem akarod egyszerre ket mysql instance-bol irni az adatokat?
azzal nagyon gyorsan korrupta tudod tenni.
gondolom elolvastad ezt:
http://dev.mysql.com/doc/refman/5.0/en/drbd-architecture.html#qandaitem…
meg ezt:
http://sources.redhat.com/cluster/wiki/FAQ/GFS#gfs_mysql
meg ezt:
http://www.mysqlperformanceblog.com/2007/03/15/mysql-myisam-active-acti…

szoval szerintem 2 aktiv mysql-lel jatszani csak replikacioval(vagy MMM vagy master slave) lehet biztonsagosan.

ne felejtsd el megtervezni a recovery-t sem.
ha a node0 meghal, a node1 kapja a kereseket, elkezdi irni az addigi slave-et, de mit csinalsz amikor visszajon a node0?
visszafailoverelsz ra?
vagy atallitod a node1-et masternek, ami ala belokod a node0-t slave-nek?

szemely szerint azt javaslom, hogy ha nem drbd-vel szinkronizalod a 2 egyenrangu mysql nodeot, hanem replikalni akarsz, akkor hasznalj mmm-et (multi master mysql), annak vannak eszkozei, ami (fel)automatikusan tudjak kezelni a hibakat, es a recovery-t.

apache loadbalance-ra ldirectord, failoverelni heartbeat, illetve ezen alkalmazasok adatainak szinkronban tartasara jo a drbd.

Tyrael

drbd primary/primary mysql ala?
ugye nem akarod egyszerre ket mysql instance-bol irni az adatokat?
azzal nagyon gyorsan korrupta tudod tenni.

Nem. drbd a vhost dir-nek kell. mysql master, slave lesz vagy meglátjuk majd, de semmiképp nem lesz drbd-n.

ne felejtsd el megtervezni a recovery-t sem.
ha a node0 meghal, a node1 kapja a kereseket, elkezdi irni az addigi slave-et, de mit csinalsz amikor visszajon a node0?
visszafailoverelsz ra?
vagy atallitod a node1-et masternek, ami ala belokod a node0-t slave-nek?

Kézzel kidump-olom és berakom a node0 alá. Ez még át kell gondolnom.

apache loadbalance-ra ldirectord, failoverelni heartbeat, illetve ezen alkalmazasok adatainak szinkronban tartasara jo a drbd.

A failover esetében hogy tudom rávenni a heartbeat-et, hogy a két node egymás szolgáltatásait átvegye ? (Nem fut minden mindegyiken, illetve egyik egyiken a másik a másikon normál üzemben.)

Load balancing-ra szerintem jo a ClusterIP, heartbeat helyett pedig inkabb a pacemaker.

En OpenVZ es DRBD hasznalok (nalam egyelore a MySQL is csak egy OpenVZ kontenerben van), hogy elszigeteljuk az ugyfeleket egymastol, load balance nelkul. Quagga hasznalok a routinghoz ha netan menetkozben migralok egy VPS (http://wiki.openvz.org/VPS_Migration_with_OSPF). Ez az oldal nagyon sokat segitett: http://forum.openvz.org/index.php?t=msg&goto=32740&l Az oldalon levo "mbhave" scriptet atreszeltem pacemaker ala.
Az alap otlet innen jott: http://www.fridu.org/hosting/52-openvz-virtualization csak o egy gepen csinalta.

"Since up to release 2.1.4 the messaging layer (Heartbeat proper), the Local Resource Manager, "plumbing" infrastructure and STONITH (now known as Cluster Glue), the Resource Agents, and the Cluster Resource Manager (now Pacemaker) were all part of a single package named heartbeat, the name was often applied to the Linux-HA project as a whole. "

heartbeat figyeli azt hogy elnek-e a gepek, Pacemaker pedig kezeli a failover esemenyeket, amiket a heartbeat jelez neki.

Tyrael

( sfeher v | 2010. 04. 01., cs – 21:23 )

Szépen haladtam. Egészen a mai napig. Kezdem érteni mi mire való.
Van két apache-om, ami a két node-on fut egyidőben. Van egy proftpd-m, ami csak az egyiken. Megy a load balancing is (haproxy).
Most következett volna a drbd kezelés beépítése.
Ez alapján tök jól meg lehet csinálni. https://wiki.ubuntu.com/ClusterStack/LucidTesting#Overview Ubuntura van, de gondoltam majd jó lesz lenny-re is. Hát nem.

primitive resGFSD ocf:pacemaker:controld \
params daemon="gfs_controld.pcmk" args="" \
op monitor interval="120s"

Erre azt mondja, hogy nincs daemon paramétere a resource-nak.
Aztán nem találom sehol a gfs_controld-t.
Peding kerestem rendesen. Testingből is próbálkoztam, hátha.
_Nagyon_ szeretném végigvinni _ezt_ a vonalat, de nem szeretnék ilyen hackelésekbe belemenni, mint ez itt: http://gcharriere.com/blog/?tag=gfs
WTF ? Lehet, hogy futok egy kört az Ubuntu házatáján (Debian-al dolgoztam eddig). Szóval gfs2+drbd+debian=suxx. Szerintem.

A konfig így néz ki egyébként:

node0:~# crm configure show
node node0
node node1 \
attributes standby="off"
primitive ClusterIP ocf:heartbeat:IPaddr2 \
params ip="192.168.1.40" cidr_netmask="32" \
op monitor interval="30s"
primitive FTP lsb:proftpd \
op monitor interval="1min" \
meta target-role="Started"
primitive WebSite ocf:heartbeat:apache \
params configfile="/etc/apache2/apache2.conf" statusurl="http://localhos
t:8080/server-status" port="8080" httpd="/usr/sbin/apache2" \
op monitor interval="1min"
clone web_clone WebSite \
meta clone-node-max="1" globally-unique="false" target-role="Started"
location ftp_pref_location FTP 100: node1
location web_pref_location web_clone 100: node1
property $id="cib-bootstrap-options" \
dc-version="1.0.8-2c98138c2f070fcb6ddeab1084154cffbf44ba75" \
cluster-infrastructure="openais" \
no-quorum-policy="ignore" \
stonith-enabled="false" \
expected-quorum-votes="2"

node0:~# crm_mon -1
============
Last updated: Thu Apr 1 20:57:01 2010
Stack: openais
Current DC: node1 - partition with quorum
Version: 1.0.8-2c98138c2f070fcb6ddeab1084154cffbf44ba75
2 Nodes configured, 2 expected votes
3 Resources configured.
============

Online: [ node0 node1 ]

ClusterIP (ocf::heartbeat:IPaddr2): Started node0
FTP (lsb:proftpd): Started node1
Clone Set: web_clone
Started: [ node0 node1 ]

A leírt virtualizációs megoldások jónak tűnnek, de most nem mennék el ebbe az irányba.

( sfeher v | 2010. 04. 09., p – 13:31 )

Kikristályosodott mit is akarok és mivel oldom meg.
Úgy döntöttem nem sz**** tovább a gfs-el illetve az active/active drbd-t is pri/sec-re cserélem, majd az éppen aktív primary-t kiajánlom a másik node-nak nfs-el. Ha cserélnek, akkor az nfs mount-ot eldobom, váltom a drbd-t akvtívra, majd felcsatolom. A mysql-t lehet, hogy kipróbálom ebben a felállásban drbd-n. Összerakom a hétvégén remélhetőleg.

http://dev.mysql.com/doc/refman/5.1/en/multiple-servers.html 


The warning against sharing a data directory among servers also applies in an NFS environment. Allowing multiple MySQL servers to access a common data directory over NFS is a very bad idea.

    *

      The primary problem is that NFS is the speed bottleneck. It is not meant for such use.
    *

      Another risk with NFS is that you must devise a way to ensure that two or more servers do not interfere with each other. Usually NFS file locking is handled by the lockd daemon, but at the moment there is no platform that performs locking 100% reliably in every situation.

Make it easy for yourself: Forget about sharing a data directory among servers over NFS. A better solution is to have one computer that contains several CPUs and use an operating system that handles threads efficiently.

szoval lassan belathadnad, hogy storage nelkul halozaton keresztul szinkronizalt fajlrendszeren nem jo otlet aktiv-aktiv felallasban adatbazisszervert uzemeltetni.
ha mindenkepp kell hogy mindket szerver dolgozzon, akkor replikacioval master-master vagy master slave, vagy csinalhatsz shard-olast is keresztbe drbd aktiv-passziv failover felallassal...

Tyrael

Idézem magam :)

A mysql-t lehet, hogy kipróbálom ebben a felállásban drbd-n

Tyrael-t

szoval lassan belathadnad, hogy storage nelkul halozaton keresztul szinkronizalt fajlrendszeren nem jo otlet aktiv-aktiv felallasban adatbazisszervert uzemeltetni.

Ezt már rég beláttam. Félreérthetően fogalmaztam. Nem aktív/aktív lesz, ezt is írtam. A mysql-en már túl vagyok régen, nem fogom drbd-re rakni. Itt kizárólag a virtual hostok könyvtára a kérdés, ahova mindkét node-nak tudnia kell írni a session kezelés miatt.
Ennyi a problémám. Tudom, hogy az nfs lassú meg minden, de nem akarom túlbonyolítani a dolgot.

ha a sessionoket fajlrendszerre teszed es nem hasznalsz sticky session-t (nem ugy ballace-olod a forgalmat, hogy ugyanaz a session ugyanazt a www-t kapja) akkor eleg csunyan labon lovod az egesz cluster koncepciot.
ha lesz 10 www-d, akkor egyet kinevezel nfs masternek, a tobbi 9 meg felcsatolva irogatja a halozaton keresztul a fajlrendszert?
hasznalhatatlanul lassu lesz, ilyenkor inkabb azt szoktak csinalni, hogy ha nincs sok vagy erzekeny adat a session-be, akkor tedd ki sutibe oket, ha ez nem jarhato, akkor centralizald a session kezelest db-be, vagy valami key-value storage-be (ami lehet akar egy cassandra cluster is), vagy csinalj sticky sessiont (load ballancer ugyanazt a klienst mindig ugyanahhoz a www-hez parositja) es akkor nyugodtan lehet lokalis fajlrendszeren tarolni a session adatokat, viszont cserebe menedzselni lesz problemasabb a centralizalt megoldashoz kepest (keresni hogy eppen ki online, ki nezte az elmult x idoben az oldalt, kileptetni az osszes felhasznalot, vagy eppen torolni a sessionjuket mert csinaltak a fejlesztok egy visszafele nem kompatibilis valtozast a session formatuman, etc.)

Tyrael

Hmm. Minden vhost a saját chroot-olt könyvtárába lévő tmp-be rakja a sessionjeit, amik egy partíción vannak. Nincs lehetőségem a session kezelést máshogy csinálni (egy rakat különféle website, joomlák, egyedi app-ok stb.). De pl. a haproxy elvileg tudja ezt kezelni.
Addig még nem jutottam el, hogy a session kezelést tudjam tesztelni. Egyelőre a megoldásnak kéne összeállni csak nem szeretnék ellőni napokat azzal, hogy rossz irányba indulok el.

ha jól olvasom, akkor most azt szeretnéd, hogy nfs-en keresztül menjen a "közös fájlrendszer", amiben a session adatok lesznek.

man nfs, és olvasd végig a DATA AND METADATA COHERENCE szekciót, gyakorlatilag az üzembiztos működéshez nagyon durva performancia-korlátozó paraméterezést kell használni (minden írás szinkron, pl.), különben hasra fog esni a rendszered, ha egyazon session-höz tartozó két kérés nem ugyanarra a gépre érkezik.

1 gep kieseset tuleli, akartam is irni en is, de hogy oldod meg a recovery-t?
memcache-t nem lehet se lockolni, se dumpolni, se replikalni (alapbol legalabbis, de mintha a facebooknak lett volna anno valami patche ra), szoval ha visszajon a halott gep, akkor azon nem indithatsz memcache-t, kulonben inkonzisztens lesz a 2 node, es nem is tudod szinkronba hozni oket. :(

reszletek:
memcached faq idevonatkozo resze
miert ne hasznaljunk memcache-t sessionkezelesre

Tyrael

A 2 memcacheben ilyenkor nem ugyanaz lesz, lasd consistent hashing. Ha az egyik memcache meghal, akkor a userek felenek ujra e kell lepni, mert elvesztetted a session informacioit. A masik nodeon futo memcache miatt belepni viszont tovabbra is be lehet. Cserebe ez gyors lesz es skalazhato, a node kieses pedig ritka annyira, hogy a felhasznalok ilyenkor egy relogint elviselnek. Az adatbazis vagy nfs-en tarolt sessionok viszont lassuak, hamar bottleneckek lesznek. Nyilvan olyan helyen ezt nem szabad csinalni, ahol a session fontos, pl. fizetesi informaciokat tartalmazhat, de a legtobb esetben szerintem nincs vele gond.

ja, ha sessionpool-rol es nem arrol hogy minden sessiont 2 helyre irsz, akkor valoban.
de nem tudom hogy tudod-e, hogy mi a te megoldasoddal a baj:
1, ha ugy alitod be a pool-t, hogy a hibas nodeokat kidobja a pool-bol, akkor az elosztasi algoritmus mukodese miatt az egyik node kiesese miatt minden keres atmegy az egy darab megmaradt szerverre, ugye ez 2 gepes felallasnal normalis mukodes lenne, fele usered kileptetesre kerul, mert azok a sessionok nincsenek rajta a megmaradt node-on.
viszont mikor visszajon a halott gep, akkor visszakerul a pool-ba, es megint kileptetodik a fele usered, mert a consistent hashing miatt azokat az uj friss ures memcache node-on keresne.

meg nagyobb baj az, hogy ez nem jol skalazodik, ebben a felallasban ha hozzaadsz egy uj nodeot, akkor kb. minden key-t mas helyen fog keresni, mint ahol eddig volt tarolva, ergo mindenkit kileptet a rendszer.

a masik megoldas az lenne, hogy a hibas gepek nem esnek ki a pool-bol, de akkor az arra eso keresek mindig ures valaszt kapnak, ergo ha nincs valami perzisztens reteged fallbacknek a sessionre, akkor fele usered nemhogy kileptetodik, de nem is fog tudni belepni...

Szoval szemely szerint maradnek a perzisztens vagy perzisztens+memcache megoldasoknal.

Illetve memcache helyett ott a redis, az tud perzisztenciat, dump/restore-t es replikaciot, szoval disaster recovery-ben fenyevekkel jobb mint a memcached.

Tyrael

Jol latod a dolog limitacioit, es azt is, hogy a redis jobb megoldas. A kerdes, hogy milyen gyakori egy memcache node kieses, es megeri e a plusz koltseg, hogy perzisztensen taroljuk az adatokat. Ha a session adatbazisban van, gyakorlatilag minden dinamikus oldallekeres adatbazis irassal jar, tobbek kozott a replikaciot is eleg jol haza tudja vagni. Memcache node-ot viszonylag ritkan ad hozza/vesz el a rendszerbol az ember. A session cache-t pedig kezeletik kulon memcache instanceok, amiket esetleg nem olyan utemben bovitunk, mint a cache tobbi reszet. A kulombozo tipusu objektumokat amugy is megeri kulon memcache-ben tarolni, hogy elkeruld a fragmentaciot.

a memcache kieses ha nem is gyakori, de uzemszeru:
kernel/software frissites, halozati/hardver problema, kapacitas bovites (ujabb memcache node-ok hozzaadasa a poolhoz), etc.
es minel nagyobb pool-od van, annal nagyobb az eselye, hogy elszall 1 node, tehat ezert vallalhatatlan az, hogy a session csak memcacheben van.
mert ha nem veszed ki a pool-bol a halott gepet, akkor userek {100/memcache nodeok szama}%-a nem tud bejelentkezni (mert a halott node-ra esne az o sessionjuk), vagy ha kiveszed a pool-bol, akkor 1-1 node kiesese miatti atrendezodes majdnem a userek 100%-nak a sessionjenek az elvesztesevel jar (minnel nagyobb a gepszam, annal kissebb az eselye, hogy mind a regi mind az uj elosztas eseten ugyanarra a node-ra esik ugyanaz a session), raadasul a recover utan furcsa hibakat okozhat (ha csak a halozat szallt el az egyik node alol, akkor az o sessionjeit megkapja egy masik node, majd miutan visszajon a halozat, akkor visszakapja a user-t a regi node, akinek mar elavult-ta valt sessionadatok vannak a birtokaban)

ps: ahogy fentebb is irtam, nem kell hogy rdbms-ben legyen a session, csak annyi lenne a feltetel hogy olyan elosztott rendszerben, ami toleralja a hibakat (perzisztens) es ugy bovitheto, hogy nem kavar be az elosztasi algoritmusnak, es mellesleg a leheto leggyorsabb.
ha mindenkepp memcache, akkor en valami olyasmit csinalnek, hogy:
session handler figyeli, kezeli, hogy a lapletoltes soran lett-e modositva a session, ha nem, akkor nem ir sehova.
ha lett modositva, akkor kiirja mind memcache-be, mind valami perzisztens retegbe, pl. mysql.
session betoltese elso korben memcache-bol, ha ott nem elerheto, akkor perzisztens retegbol.
igy a readek majdnem egesze memcache-bol megy, ha nem tarolsz session-ben counter-t, vagy lastvisitet, ami minden lapletoltesnel valtozik, akkor az irasok joresze sem general irast a perzisztens retegre.
raadasul elsodleges kulcs alapu select mysql-ben is olcso, iras sem olyan veszes, ha csak az elsodleges kulcson van index.

igy a memcache tenyleg csak cache, elerhetetlenseg eseten csak a sebesseg degradalodik, az elerhetoseg/funkcionalitas nem.

Tyrael

Igy viszont mar alkalmazasoldalon kell beleszolasod legyen, ha jol ertem, akkor a topic nyito drupalt, joomlat, stb kesz alkalmazasokat akar futtatni, egyebkent igazad van. Ha viszont a sessionok kulon memcache instance-ban vannak, akkor a gyakori cache pool bovitest en nem latom akkora problemanak (hiszen ott csak a sessionok vannak). Ha mindent ugyanabban a memcacheben tarolsz, akkor ez egy sokkal gyakrotibb problema lehet.

skalazasrol beszeltunk.
ha egyre tobb sessionod van, akkor egyre tobb memcached node-ra lesz szukseged, akar azert mert tobb memoria kell, akar azert, mert tobb memcache connection-od lenne 1 idoben, mint amennyit elbir az adott pool.
ha pedig a bovitesnel fellepnek a fent nevezett problemak, akkor egy olyan megoldast valositottal meg, ami minnel latogatottabb, annal gyakrabban vannak problemak vele. :/

Tyrael

Eddig a topicban az volt, hogy db-ben vagy nfs-en legyenek a session adatok, teljesitmeny szempontjabol egyik sem jo. A memcache igen, kitargyaltuk, hogy mik annak a hatranyai, es mikor vagod ki a usereket, ebben is egyetertunk. Ha bele tudsz nyulni az alkalmazasba, akkor szerintem egyszerubb redist hasznalni, mint az altalad felvazolt memcache es db hasznalata egyutt, meg ugy altalaban sokkal jobb megoldasokat tudsz csinalni, mintha egy kesz szoftver (drupal, joomla a topicnyito eseteben) kell ala architekturat tenned.

ha nem tud/akar belenyulni az alkalmazasokba, akkor a db mar eleve szoba sem johet kozos session stoarge-nek.
a memcached is csak addig, amig az adott alkalmazas nem definialta felul a session_set_save_handler() vagy sajat session osztaly megvalositasaval a session kezelest az adott alkalmazas.
ha igen, es explicit lemezre dolgozik a website, akkor a loadbalance-olt 2 aktiv node-os www csak sticky session vagy elosztott filerendszer segitsegevel mukodhet, de annak meg nagy az overhead-je a lockolasok miatt, ami egy minden lapletoltesnel piszkalt fajlrendszer eseten mar gaz.
ott van meg a kepfeltoltesek kezelese, ha nincs elosztott fajlrendszer, vagy okos kod, akkor ott is csunyan meg tudnak lepodni az alkalmazasok, hogy a fajl feltoltese utan nincs ott, vagy nincs ott teljesen a fajl (vagy mert meg nem sult el az unison/rsync, vagy mert elsult, de meg nem syncelt at).
szoval ha nem csak session-rol van szo, akkor bonyolodik a helyzet.
marpedig egy shared hosting kornyezetben random alkalmazasokkal ez a helyzet, valahogy ez a hozzaszolas elkerulte a figyelmemet, valamiert abban a hitben voltam, hogy sajat alkalmazasok lesznek hostolva a 2 szerveren, amire kell magas rendelkezesreallas, de nem akarnak 1 szervert uresben jaratni csak arra az esetre, ha elszallna az elsodleges gep.
igy viszont, hogy sok kis latogatottsagu site van, nem nehany nagy, es nem lehet belenyulni a kodba, viszont nem akarnak szivni, akkor megiscsak azt javasolnam, hogy leszarni a performanciat rovid tavon, es gfs vagy nfs menjen ala nyugodtan, es majd ha lesz sok penz, akkor esetleg el lehet gondolkozni valami storage jellegu megoldason (akar hardveres, akar csak telebaszni raid10-ben egy nagy zsak vinyoval valami toronyhazat, es kinevezni nfs servernek normalisan beconfolva).

ps: kezdek faradni, ha hulyeseget irtam, bocs.

Tyrael

Nem írtál hülyeséget, szívemből szóltál :). _Jelen_ helyzetben számomra nem a performancia a releváns, hanem hogy stabilabb legyen a rendszerem, ne legyenek leállások akár egy nagyobb overhead miatt. A gfs-t lenny-vel és corosync-el nem nevezném letisztultnak, ezért gondoltam az nfs-re.
A hétvége megint elment, de legalább info-val gazdagodott a thread ;).

( akoscomp | 2010. 04. 10., szo – 18:48 )

Kb. erről a témáról volt egy nyílt nap az ITFactory-n. Az előadás videói letölthetőek innen: http://itfactory.hu/download/linux/
Ott, igaz röviden, el lettek mondva érvek a klasztermegoldások mellett illetve ellen. Bár a nyílt napon kevés konkrétum hangzott el, azért kiindulónak lehet érdemes megfontolni az ott javasolt megoldásokat, és azokra megpróbálni felépíteni egy működőképes rendszer.
Én személy szerint teszteltem két node-os klasztert. Egy osztott drbd-n (primary/slave), heartbeat-el oldottam meg a klaszter részt. A mysql adatbázisokat a drbd-re tettem, ext3 vagy ext4 fájlrendszerre, de csak nagyon minimális igénybevétel mellett teszteltem, úgy működött rendesen az egyik node lekapcsolása után is (stop és fizikai kikapcsolást is teszteltem). A mysql csak az aktív node-on futott mindig.
Ha a drbd-t úgy állítod be, hogy mindig kiírja az IO műveleteket, a node mindkét tagján, nem lenne szabad, hogy előforduljon adatvesztés, de ezt igazából nagy terheléssel lehet tesztelni.

Megnéztem én is megint a felvételt. A javaslatok a legvégén hangzottak el, és akkor már kikapcsolták a felvételt.
Jegyzetek alapján:
Klaszter megoldásnak az OpenAIS-t javasolják, mivel egy sokkal fejlettebb, standardokon alapuló klasztermegoldás, ami jobban skálázható és konfigurálható.
Heartbeat+drbd kombinációban nem javasolták a mysql tárolását, mivel adatvesztéssel járhat, arra konkrét megoldás nem hangzott el, hogy ezt, hogy lehet megoldani, ez csak a tanfolyam során fog kiderülni.
Azt hiszem közben is kiderült, hogy a javasolt klaszter fájlrendszer az ocfs2 mivel sokkal tágabb körben támogatott és jobban dokumentált mint a gfs. A gfs az egy erősen redhat-ra szabott és a redhat által használd fájlrendszer de más platformokon kevésbé támogatott.
Mysql esetén vannak saját megoldások is, de ahogy én néztem, azok egyrészt többgépesek, másrészt pedig forrásból kell telepíteni, amit én nem igazán szeretek, mivel problémás a frissítése.

Ha mysql-ben be van kapcsolva a binlog, es az innodb_flush_log_at_trx_commit 1-re van allitva, akkor nem tortenhet adatvesztes.
A Heartbeat+drbd kombo alatt valoszinuleg azt ertette, hogy aktiv-aktiv drbd + 2 mukodo query-ket fogado mysql-t futtatsz ugyanazon a data dir-en.
Ebben az esetben garantalt az adatvesztes! :)

Tyrael

igazabol binlog onmagaban nem lassit, viszont gyorsabb tole a recovery, a innodb_flush_log_at_trx_commit pedig default-bol 1-en van, szoval nem ez a performance penalty, hanem a innodb_flush_log_at_trx_commit magasabb ertekre allitasa a performance improvement, de egyebkent valoban, ilyenkor gyakorlatilag annyi write trans/sec-re kepes csak a rendszered, ahany random irast tud masodpercenkent a diszk alrendszer.

Tyrael

nem ezektől lesz lassú a rendszer, hanem ha ilyen beállítások mellett etherneten szinkron replikált diszken futtatod az adatbázist.

egyébként a mysql nem tud log írást batchelni?
azaz amíg vár a rendszer a log kiírására, addig akik jönnek új tranzakciók, azokat sorbarakja, majd a következő log kiíráskor egyben mindet kiírja (hiszen az 1k-s szinkron írás és a 100k-s írás kb. ugyanannyi ideig tart).

nyilván ez csak akkor működik, ha nem lockolják egymás elől az objektumokat.

"nem ezektől lesz lassú a rendszer, hanem ha ilyen beállítások mellett etherneten szinkron replikált diszken futtatod az adatbázist."

en erre a mondatodra valaszoltam:
"... de performancia sem történhet :)"

Amibol nekem nem jott at, hogy a drbd-re gondolsz mint szuk keresztmetszet.
Ha van a kotetek alatt alami battery-backed write cache, akkor azert csak a halozatra kell varnia a drbd-nek, a lemezre nem, szerintem, de valoban van teljesitmeny veszteseg.

"egyébként a mysql nem tud log írást batchelni?
azaz amíg vár a rendszer a log kiírására, addig akik jönnek új tranzakciók, azokat sorbarakja, majd a következő log kiíráskor egyben mindet kiírja (hiszen az 1k-s szinkron írás és a 100k-s írás kb. ugyanannyi ideig tart)."

innodb_flush_log_at_trx_commit 0, vagy 2 allapota lesz az, amire te gondolsz:
http://dev.mysql.com/doc/refman/4.1/en/innodb-parameters.html#sysvar_in…

Amugy drbd alternativakent meg szobajohet majd az 5.5-os mysql Semisynchronous Replication-ja is.
http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html
Ez azt tudja, hogy amig nem igazolta vissza legalabb 1 slave hogy megkapta a slave-logbol az adott query-t, addig blockol a hivas, ha nem jon idoben ilyen visszajelzes, akkor rollbackel a tranzakcio.
Ez is overhead, de ha sok query-d van, ami sok adatot modosit, akkor ez kevesebb adatmozgassal jar, mint a drbd szinkronizacio.
persze 5.5-bol meg nincs GA, csak gondoltam megemlitem.

Tyrael

sem a 0, sem a 2 nem garantálja a db által a user felé visszaigazolt dolgok diszkre kerülését, csak az 1 (az is csak akkor, ha nem beteg alatta az I/O alrendszer, és a sync művelet valóban jól elvégzi a dolgát). ezek tehát szemantikailag különböznek.

én pusztán arról beszélek, amit a 1-es tud, azzal a kiegészítéssel, hogy nem egyesével, tranzakciónként írjuk a logot (+ flush), hanem mindig annyi tranzakció adatát egyben, amennyi az előző logírás alatt összegyűlt. ez nem jelentene szemantikai különbséget a 1-esnél leírtakhoz képest, csak teljesítménybelit (ergó ha nem így van megírva most, akkor simán át is írhatnák, nem kéne hozzá új érték az innodb_flush_log_at_trx_commit-hoz).

néha tényleg az az érzésem, hogy egy pár hónap alatt ennél jobbat is össze lehetne dobni, mint amit a mysql-ben az utóbbi >tizenx év alatt összehoztak...

"sem a 0, sem a 2 nem garantálja a db által a user felé visszaigazolt dolgok diszkre kerülését, csak az 1 (az is csak akkor, ha nem beteg alatta az I/O alrendszer, és a sync művelet valóban jól elvégzi a dolgát). ezek tehát szemantikailag különböznek."

a 0 nem garantal semmit, ha elszall a mysql, akkor buk(hat)tad az uccso N tranzakciot.

viszont a 2 eseteben ha elszall a mysql, de az OS es a diszkrendszer allva maradt, akkor igenis kikerul lemezre az adat, mert:
"When the value is 2, the log buffer is written out to the file at each commit, but the flush to disk operation is not performed on it."

"én pusztán arról beszélek, amit a 1-es tud, azzal a kiegészítéssel, hogy nem egyesével, tranzakciónként írjuk a logot (+ flush), hanem mindig annyi tranzakció adatát egyben, amennyi az előző logírás alatt összegyűlt. ez nem jelentene szemantikai különbséget a 1-esnél leírtakhoz képest, csak teljesítménybelit (ergó ha nem így van megírva most, akkor simán át is írhatnák, nem kéne hozzá új érték az innodb_flush_log_at_trx_commit-hoz)."

akkor talan a group commitra gondolsz:
http://www.mysqlperformanceblog.com/2009/02/02/pretending-to-fix-broken…

De ha jol ertem amit szeretnel a te megoldasod eseteben ha elszall a mysql, akkor az uccso flush ota elvegzett osszes tranzakciot buknad te is.
miben kulonbozik ez attol, hogy masodpercenkent irod ki egyszerre a binlogot ahogy a innodb_flush_log_at_trx_commit=0 csinalja.

Tyrael

viszont a 2 eseteben ha elszall a mysql, de az OS es a diszkrendszer allva maradt, akkor igenis kikerul lemezre az adat, mert:

de engem nem érdekel, hogy csak bizonyos esetekben lesz adatvesztés, néha meg nem, mert az a szempont, hogy ELŐFORDULHAT adatvesztés.
tehát a '2' nem garantálja, hogy áramszünet (vagy pl. bármilyen kernel crash esetén) esetén a már általam adatbázisba írtnak hitt adataim nem mennek a levesbe.

De ha jol ertem amit szeretnel a te megoldasod eseteben ha elszall a mysql, akkor az uccso flush ota elvegzett osszes tranzakciot buknad te is.
miben kulonbozik ez attol, hogy masodpercenkent irod ki egyszerre a binlogot ahogy a innodb_flush_log_at_trx_commit=0 csinalja.

az én megoldásom esetén amire azt mondjuk, hogy kint van a diszken, az kint van a diszken.
a commit akkor van kész (akkor tér vissza a felhasználóhoz), ha kint van a diszken az adat.
a commit=0 szerintem nem ezt csinálja (a doksi szerint).

a lényeg, hogy a commit-okat nem sorbarendezzük, és szigorúan egymás után írjuk őket a logba, egyesével, hanem egy threadben, de batchelve.
azaz egyszerre mindig csak egy írás lehet aktív, ezalatt gyűlnek a commitok, de az írás befejeztével a közben összegyűlt összes többi commitot a következő írásban egyben írjuk ki (és várjuk meg ezt az írást az összes commit-tal, és ha az írás kész, akkor van kész az összes érintett commit).
így ha sok a tranzakció, de a lassú a diszkem, akkor legfeljebb nagyobb írások mennek majd a diszkre.

akkor talan a group commitra gondolsz:
http://www.mysqlperformanceblog.com/2009/02/02/pretending-to-fix-broken…

valami ilyesmiről van szó, de a szóhasználatuk alapján (group commit) alapján nem biztos, hogy pont ugyanarra gondolunk.

"tehát a '2' nem garantálja, hogy áramszünet (vagy pl. bármilyen kernel crash esetén) esetén a már általam adatbázisba írtnak hitt adataim nem mennek a levesbe."
ha van rad vezerlod es abban van cache az is(marmint a vezerlo) elszallhat.
"Caution

Many operating systems and some disk hardware fool the flush-to-disk operation. They may tell mysqld that the flush has taken place, even though it has not. Then the durability of transactions is not guaranteed even with the setting 1, and in the worst case a power outage can even corrupt the InnoDB database. Using a battery-backed disk cache in the SCSI disk controller or in the disk itself speeds up file flushes, and makes the operation safer. You can also try using the Unix command hdparm to disable the caching of disk writes in hardware caches, or use some other command specific to the hardware vendor.
"

"a lényeg, hogy a commit-okat nem sorbarendezzük, és szigorúan egymás után írjuk őket a logba, egyesével, hanem egy threadben, de batchelve.
azaz egyszerre mindig csak egy írás lehet aktív, ezalatt gyűlnek a commitok, de az írás befejeztével a közben összegyűlt összes többi commitot a következő írásban egyben írjuk ki (és várjuk meg ezt az írást az összes commit-tal, és ha az írás kész, akkor van kész az összes érintett commit).
így ha sok a tranzakció, de a lassú a diszkem, akkor legfeljebb nagyobb írások mennek majd a diszkre."
sasold meg a perconas IO patcheket:
http://www.percona.com/docs/wiki/patches:innodb_io_patches

Tyrael

ha van rad vezerlod es abban van cache az is(marmint a vezerlo) elszallhat.

ha annyira hülye vagyok, hogy nem redundáns raid vezérlő + cache kombót használok write-behind üzemmódban, akkor meg is érdemlem, "az ellen nem véd" :)

alapvetően azt gondolom, hogy vagy naked diszk, vagy redundáns külső intelligens tárolóeszköz.

sasold meg a perconas IO patcheket:
http://www.percona.com/docs/wiki/patches:innodb_io_patches

végigolvasom valamikor, amikor lesz energiám elmélyedni, róluk már régen hallottam, hogy milyen frankó patcheket csináltak (csak azt nem értem, hogy miért nem bírtak ezek bevándorolni a mainline-ba, ha tényleg jók).

( 3xtati | 2010. 04. 10., szo – 23:04 )

subscribe
____________________
Ha igen akkor miért nem...
Linux 2.6.30-gentoo-r4 i686 Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz GenuineIntel GNU/Linux

( sfeher v | 2010. 04. 14., sze – 23:15 )

Építeném fel a konfigot, de elakadtam egy ponton.

Ezt szeretném:

node0

a. drbd felhúzva, mint primary. [ok]
b. /dev/drbd0 felmountolva az /mnt alá. [ok]
c. nfs szerver indítása azon a gépen, amelyik éppen master [?]
d. Virtual_IP felhúzása azon a gépen, amelyik éppen master [?]

node1:

e. drbd Slave módban [ok]
f. virual_ip:/mnt felcsatolása /mnt könyvtárba, miután a node0-án elindult az nfs szerver

Ha cserélnek, akkor csere (pri/slave). Fontos, hogyha egyedül marad az egyik node, akkor ne induljon rajta nfs szerver (ekkor primary a drbd) hanem várja meg amíg a másik node visszajön, csak utána indítsa.
Fontos még, hogy a,b,c,d ugyanazon a node-on menjen illetve e,f a másikon.
Beleástam magam a pacemaker manuáljába, háát nem mondom, hogy vágom a megoldást a problémámra de közben ezt is megtaláltam.

crm configure show ( Ez egy alap lenne)

node node0 \
attributes standby="off"
node node1 \
attributes standby="off"
primitive drbd0 ocf:heartbeat:drbd \
params drbd_resource="r0" \
op monitor interval="59s" role="Master" timeout="30s" \
op monitor interval="60s" role="Slave" timeout="30s"
primitive fs0 ocf:heartbeat:Filesystem \
params fstype="ext3" directory="/mnt" device="/dev/drbd0"
primitive nfs_server ocf:heartbeat:nfsserver \
params nfs_init_script="/etc/init.d/nfs-kernel-server" nfs_shared_infodi r="/var/lib/nfs/" nfs_ip="192.168.1.40" nfs_notify_cmd="/sbin/rpc.statd"
primitive virtual-ip ocf:heartbeat:IPaddr2 \
params ip="192.168.1.40" broadcast="192.168.1.255" nic="eth0" cidr_netma sk="24" \
op monitor interval="21s" timeout="5s"
group apache-group fs0 virtual-ip nfs_server \
meta target-role="Started"
ms ms-drbd0 drbd0 \
meta clone-max="2" notify="true" globally-unique="false" target-role="St arted"
location cli-prefer-apache-group apache-group \
rule $id="cli-prefer-rule-apache-group" inf: #uname eq node0
colocation apache-group-on-ms-drbd0 inf: apache-group ms-drbd0:Master
order ms-drbd0-before-apache-group inf: ms-drbd0:promote apache-group:start
property $id="cib-bootstrap-options" \
dc-version="1.0.8-2c98138c2f070fcb6ddeab1084154cffbf44ba75" \
cluster-infrastructure="openais" \
stonith-enabled="false" \
no-quorum-policy="ignore" \
expected-quorum-votes="2"

Ebből egy dolog nem megy. A másik node-ra migrálása az apache-group-nak
Amiatt, hogy az nfsd nem hajlandó elengedni az /mnt/nfs könyvtárat, emiatt a drbd-s partíciót nem lehet lecsatolni és nem megy a váltás.

ps ax

357 ? S< 0:00 [kjournald]
3479 ? S< 0:00 [rpciod/0]
3495 ? S< 0:00 [lockd]
3496 ? S< 0:00 [nfsd4]
3497 ? S 0:00 [nfsd]
3498 ? S 0:00 [nfsd]
3499 ? S 0:00 [nfsd]
3500 ? S 0:00 [nfsd]
3501 ? S 0:00 [nfsd]
3502 ? S 0:00 [nfsd]
3503 ? S 0:00 [nfsd]
3504 ? S 0:00 [nfsd]
3630 ? S 0:00 [drbd0_asender]
4244 pts/0 R+ 0:00 ps ax
node0:~# mount
/dev/sda2 on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/drbd0 on /mnt type ext3 (rw)
/mnt/nfs on /mnt/nfs type none (rw,bind)
nfsd on /proc/fs/nfsd type nfsd (rw)

Köszi.

Ok, megvan.

node1:/etc/init.d# diff nfs-kernel-server~ nfs-kernel-server
154c154
< --name nfsd --user 0 --signal 2
---
> --name nfsd --user 0 --signal 9

Megy szépen a váltás. Eddig jó.

( sfeher v | 2010. 04. 16., p – 23:54 )

Itt a következő két problémám:

1. Ha migrálom az apache-group-ot, akkor előtt nem csatolja le az nfs mountot. Kellene erre valami constraint.

2. Ha lelövöm az egyik node-ot, akkor a másik szépen elindítja az apache-group-ot az nfs_client-et meg _helyesen_ nem, mivel az csak slave drbd-n futhat. Ha viszont visszajön a másik node, akkor az apache-group ész nélkül átmigrál(na) rá, csak elakad, mivel az nfs_client ott figyel és fel van mountolva az /mnt alá, amit egyébként a primary drbd-t futtató node is felhúz.

crm configure show

node node0 \
attributes standby="off"
node node1 \
attributes standby="off"
primitive drbd0 ocf:heartbeat:drbd \
params drbd_resource="r0" \
op monitor interval="59s" role="Master" timeout="30s" \
op monitor interval="60s" role="Slave" timeout="30s"

primitive fs0 ocf:heartbeat:Filesystem \
params fstype="ext3" directory="/mnt" device="/dev/drbd0" \
meta target-role="Started"

primitive nfs_client ocf:heartbeat:Filesystem \
params fstype="nfs" directory="/mnt/" device="192.168.1.40:/mnt/" options="hard,intr,noatime,rw,nolock,tcp,timeo=50" \
meta target-role="Stopped"

primitive nfs_server lsb:nfs-kernel-server \
op monitor interval="1min"

primitive virtual-ip ocf:heartbeat:IPaddr2 \
params ip="192.168.1.40" broadcast="192.168.1.255" nic="eth0" cidr_netmask="24" \
op monitor interval="21s" timeout="5s" target-role="Started"

group apache-group fs0 virtual-ip nfs_server \
meta target-role="Started"

ms ms-drbd0 drbd0 \
meta clone-max="2" notify="true" globally-unique="false" target-role="Started"

location cli-prefer-apache-group apache-group \
rule $id="cli-prefer-rule-apache-group" inf: #uname eq node0

colocation apache-group-on-ms-drbd0 inf: apache-group ms-drbd0:Master
colocation co_nfs_client inf: nfs_client ms-drbd0:Slave
order ms-drbd0-before-apache-group inf: ms-drbd0:promote apache-group:start
order ms-drbd0-before-nfs_client inf: ms-drbd0:promote nfs_client:start
property $id="cib-bootstrap-options" \
dc-version="1.0.8-2c98138c2f070fcb6ddeab1084154cffbf44ba75" \
cluster-infrastructure="openais" \
stonith-enabled="false" \
no-quorum-policy="ignore" \
expected-quorum-votes="2" \
last-lrm-refresh="1271453094"

node1:~# crm_mon -1
============
Last updated: Fri Apr 16 23:49:30 2010
Stack: openais
Current DC: node0 - partition with quorum
Version: 1.0.8-2c98138c2f070fcb6ddeab1084154cffbf44ba75
2 Nodes configured, 2 expected votes
3 Resources configured.
============

Online: [ node0 node1 ]

Resource Group: apache-group
fs0 (ocf::heartbeat:Filesystem): Started node1 (unmanaged) FAILED
virtual-ip (ocf::heartbeat:IPaddr2): Stopped
nfs_server (lsb:nfs-kernel-server): Stopped
Master/Slave Set: ms-drbd0
Masters: [ node0 ]
Slaves: [ node1 ]
nfs_client (ocf::heartbeat:Filesystem): Started node1 (unmanaged) FAILED

Failed actions:
nfs_client_start_0 (node=node0, call=98, rc=1, status=complete): unknown error
fs0_stop_0 (node=node1, call=9, rc=-2, status=Timed Out): unknown exec error
nfs_client_stop_0 (node=node1, call=7, rc=-2, status=Timed Out): unknown exec error
node1:~#