Apache failover

Linux-haladó

Sziasztok!

Egy apache failover párt kellene megvalósítanom, de failovert még nem csináltam, szeretnék egy kis segítséget kérni.
Ki milyen programot, módszert ajánlana ehhez?
Eddig a heartbeatet találtam erre a célra, de ha tudtok jobb megoldást azt is szívesen veszem.

  • 2541 megtekintés

( janoszen v | 2009. 08. 15., szo – 15:01 )

Heartbeattel lehet próbálkozni, de ajánlom figyelmedbe a STONITH fogalmát (avagy node fencing). Ismerkedj az alapokkal, majd válassz lehetőségeid szerint a következő technológiákból szimpatikusakat. Lehet Pacemaker-Heartbeat/OpenAIS kombóval játszani és/vagy esetleg LVSt tenni elé ha vannak plusz gépeid.

biztos?

ha a dns feloldásnál használatos round robinra gondolsz, az nem garantálja azt, hogy kiesés esetén csak a másik szerver címére oldana fel.

Saját tapasztalatom, hogy az offline (nem jól működő) gép címére feloldáskor egy frissítést kell nyomnom a böngészőben, hogy a másik címre váltson. (win alatt)

Ha másra gondolsz, akkor elnézést.

off

ha saját dns szerver oldaná fel kicsit ttl-lel, akkor lehetne még érdekes dolgokat alkotni :)

próbáltam egy primitív megoldást egyik hobbi weblapomnál, ott egy teljes böngészőablakos iframe-be tölti bele az aldomainen lévő gépemen futó weblapot, ha online van (jscript teszt)... ha nem, akkor pedig egy statikus tartalmat tölt oda. Persze ez csak egy kis játék. Több, adatbázist is használó szerver esetén tudom, hogy nem megoldás.

/off

Winen sosem teszteltem még ilyet, a többi dolgot, amit írsz, én is így tudom.
Sok adatbázisos weblapra ez nem jó, mert vagy meg tudod oldani, hogy állapotmentes legyen a webes cucc, vagy bajok lehetnek. Két gép esetén adatbázisszerverből is illik kettő, de akkor szinkronizálási kérdések merülnek fel...
Statikus weblapra nekem eddig jó volt a roundrobin.

Én is statikus lapomnál használom :) Még mindig jobb, ha egy frissítést kell nyomni (vagy a látogatók fele éri el kapásból), mintha teljesen elérhetetlen lenne.

Igazából az a kellemetlen, ha a szerver elérhető, csak nem azt mutatja amit kell... mert akkor a látógatók egy része mást (pl egy hibalapot) lát, mint a tartalom és akkor nem is vált át.

meg is van, itt is olvastam, hogy hiba esetén problémás
http://en.wikipedia.org/wiki/Round_robin_DNS
"Round robin DNS should not solely be relied upon for service availability. If a service at one of the addresses in the list fails, the DNS will continue to hand out that address and clients will still attempt to reach the inoperable service."

ja igen, az adatbázis szerverek többszörözésével kapcsolatban:
mysql esetén úgy tudom van olyan lehetőség, hogy a tartalék szerverre is továbbítsa a kéréseket, így kiesés esetén is megvan az-az állapot, ahol tartott.

Persze, hogy hiba esetén kiadja a döglött szerver ip címét is, a kérdés az, hogy ha a böngésződ nem tud konnektálni, akkor hibaoldalt dob-e vagy megint megpróbál rezolválni és konnektálni. Ez, szerintem, böngészőfüggő.

Postgresre is van clusterezési lehetőség, bár eléggé szottyossak :)

hibaoldat dobott (timeout) offline szerver esetén, és frissítés után váltott másikra.

emlékeim szerint win alatt többféle böngészővel is próbáltam, hogy mit reagál... arra nem emlékszem, hogy linux alól másképp viselkedtek -e a böngészők)

Linux kliens alól biztos, hogy másabb a round robin, mert sima pinget többször egymás után kiadva látni a váltogatást.
Win alatt csak egy ipconfig /flushdns kiadása után vált át a következő címre a ping. Gondolom sikeres kapcsolódás után bekesseli egy időre rendszer szinten. Bár ahogy nézem inkább a ping alkalmazás okosabb... és linux alatt mindig feloldást kér.

mysql esetén azt hiszem nem clusterezésre gondoltam, hanem erre:
http://dev.mysql.com/doc/refman/5.0/en/replication.html
ha jól értem ez inkább backupra való... de látom, hogy clusterezésre is linkelnek innen is :)

Nem jól értetted, a MySQL replikáció NEM backupra való. A replikáció egy kvázi-cluster dolog, amelyben egy vagy több master beszélget. A multimasterrel változóak a tapasztalatok, nekem van működőm, másoknak összeszarta magát. Az NDBvel meg az a baj, hogy ott a programozóknak nagyon kell figyelni arra, hogy ne csináljanak marhaságokat. (Ez igaz a replikációra is, csak kisebb mértékben.) Ha a programozók fele transzparens működés kell, akkor DRBD.

bocsi, de ahogy a weblapjukat olvasom éppen hogy nem.

Maser-Slave egyirányú kapcsolat, ahol minden írás (módosítás) a Masteren kell lefusson, a sima lekérdezések (terheléselosztás céljából) mehetnek slave-kre is. Abban igazad van, hogy nem kifejezetten a backup a célja, viszont leállás nélkül lehet róla backupot készíteni (mivel asszinkron a kapcsolata a masterrel).

Kisebb rendszerné viszont mégiscsak (szolgáltatás kiesés / hw hiba elleni) backup haszna is van (teljesen ugyanúgy felkonfigurált két rendszer), a master szerver kipusztulásakor pillanatok alatt átveheti a szerepét az addig slave gép :)

http://dev.mysql.com/doc/refman/5.0/en/replication.html

amiről te beszélsz az inkább ennek tűnik:
http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster.html

Gondolom lehet vegyesn is használni őket, pl több master clusterezve és mindegyiknek több slaveje.. hmm egész komoly teherbírású rendszer összehozható ezek szerint.

Őőőő a slavet nem tudod automatikusan masterré varázsolni. Illetve egészen pontosan ezt még meg tudod csinálni, azt nem tudod megcsinálni, hogy a régi master amikor visszajön, szinkronizálja vissza az adatokat.

Backupra egyébként LVM snapshot, ahhoz sem kell leállítani a szervert.

Az NDBvel kapcsolatban pedig nekem az volt az érzésem, hogy még erőteljesen experimental, azért tették bele a community editionbe, hogy jöjjenek ki a hibái.

Amit javaslok, ha nagy rendszert akarsz építeni: MySQL multimaster vagy DRBDvel failover, majd abból slavek.

A STONITH/node fenceing egy módszer, amit a heartbeatben vezettek be, de attól még mint elv fontos bármiféle HA megoldásban. Anyway, a CRM módú HB eléggé háklis és tele van bugokkal. Nekem sikerült az én feladataimhoz egy működőképes megoldást összerakni. A kolléga kipróbálta az OpenAIS-t is, azt mondja, fényévekkel jobb, de lehetne azért rajta mit reszelni.

( bambano | 2009. 08. 15., szo – 16:47 )

Kipróbálhatod a drbd-t is. Az ugyan diszkek tükrözésére való, de ha már a drbd eldöntötte helyetted, hogy melyik az aktív node, akkor azon el is lehet indítani a szükséges szerver programokat.

( golgota | 2009. 08. 15., szo – 18:54 )

Az egyetlen probléma a heartbeat és egyéb dolgokkal a session kezeléssel van. Ha session közben terhelődik át a szerver, akkor az adott felhasználó session-je megszakad.
Ez kiküszöbölhető, ha tomcat-et használsz és az ő cluster megoldását. Ebben az esetben nem kell bohóckodni a heartneat-tel és semmi mással, csak a tomcat-et kell megfelelően paraméterezni. Ami a doksijával nem nehéz.

Akkor addj el fizetős webes szolgáltatásokat, majd mond az ügyfeleknek, hogy sajnos előfordulhat, hogy a munkájukat "elölről" kell kezdeni.
(persze nem kell elölről kezdeni, de a lehgtöbb ügyfél még azért is haragszik, ha a "next" vagy "submit" gombra a bejelentkezés jön elő. Persze lehet a programot is szétpipmelni, hogy a lehető legkevesebb veszteség érje az ügyfelet, de ettől ő még nagyon nem fog örülni neki és majd kéri vissza a pénze egy részét, stb, stb)

( eax | 2009. 08. 15., szo – 21:48 )

Mi lesz rajta? Ha csak statikus cucc, akkor nem (feltetlenul) kell STONITH-al, meg hasonlokkal bohockodni, hanem csinalsz 2 ugyanolyan apache-t, kozejuk meg vrrp/carp-t, esetleg heartbeat ip failover moddal, es kesz.

Ha dinamikus a tartalom, akkor kell egy kozos adatbazisszerver (ennek HA-zasa az adatbaziskezelo tipusatol fugg), kozos session store (kornyezetfuggo, pl. php alatt siman lehet a session dir-t kozos fs-re rakni), kozos file store (pl. iscsi-n ext3, amit failoverkor atmountolsz, de akkor keszulni kell ra, hogy ha az aktiv node csunya halalt hal, akkor alaposan osszekuszalhatja a filerendszert; vagy valami cluster-aware fs ugyanigy (GFS, OCFS); vagy kulon file szerver, amit pl. nfs-en (glusterfs-en, lustre-n, akarmin) ersz el).
A STONITH akkor erdekes elsosorban, ha valami olyan eroforrasod van, amit semmikepp nem szabad egyszerre ket helyrol hasznalni (pl. a fent emlitett iscsi+ext3).

Erre jo pl. a heartbeat, a redhat cluster suite, etc.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

vrrp/carp-t,

Mivel a topik elejen "csak" "apache failover" volt, arra ez siman jo. Egy radius szerver levlistajan (mar sok eve volt) azt a tanacsot adtak (mivel sql-t HA-zni azert nem trivialis), hogy az sql szervered nagyon megbizhato legyen. Na most szolj hozza....

SPAMtelenul - POP3 spamszuro szolgaltatas

( cydrk | 2009. 08. 16., v – 00:57 )

Olvastam itt tobb megoldast is. Reszemrol nem javaslom ilyesmikhez nginx vagy akar varnish vagy hasonlo dolog beepiteset. Talan a legegyszerubb LVS -el megoldani. Semmi macera csak tisztan TCP alapu balance (ugye ha mar failover, akkor miert ne szolgaljon ki a tartalek gep is).

Mysql-re pedig a replikacio a jo. A multimaster replikacio egy remek, de experimental dolog nem javasolt oylanoknak akik nem ertik mi az es hogy mukodik. Mysqlhez inkabb drbd-t javasolnam neked. Egyszeru, hasznos es tonna szamra vannak leirasok.

drk

MySQL-t nem gáz fs szinten replikálni? Tudtommal futás közben nem mindent ír le azonnal a memóriából diskre. Clustering nem jobb? Igaz, ahhoz kell egy 3. control gép is.
Én most ilyesmit próbálok összerakni 2 vason, VM-eken. MySQL clusterezve, storage aktív-aktív DRBD-n, Apache-ból 2db. Az egész felett egy nat + apache proxy, ami a terheléselosztást csinálja (persze a 2 vason 1-1 példány HA IP takeover-el)
Szerintetek? (mert attól, hogy kiagyaltam, még nem biztos, hogy jó is)

Fizikailag csak 2 gép adott, így azon kell megoldani a redundanciát. Gondoltam, minden lényegesebb szolgáltatáshoz külön VM-t dedikálok, pontosabban mindenhez 2-t, egyiket egyik vason, másikat a másikon. Így később, szükség esetén bármikor beállítható +1 gép, amire át lehet terhelni 1-2 szolgáltatást.
- Storage-nak OpenFiler-t raktam fel DRBD+Heartbeat-el - ez tárol minden közös adatot, configot, htdocs-t, de szerintem még a kérdéses session file-okat is közös tárterületre lehet hozni és akkor még a session is átvehető.
- MySQL NDB Cluster - bár ebben kicsit csalódtam, lehet hogy sima replica lesz helyette
- Apache-ok loadbalance+failover
- "Gateway" - az egész cluster kijárata a netre, nem Apache proxy lesz, hanem LVS, Heartbeat, + ezekre kerültek a MySQL cluster management node-jai

- kérdéses még a mail és a DNS, de talán ezeknél a legegyszerűbb a redundancia

Lehet, hogy kicsit túlbonyolított, őrült ötlet, ezesetben szívesen fogadok alátámasztott ellenérveket, valamint javaslatokat egyéb megoldásra is (egyelőre) összesen 2 gépen.

Szia,

Sajat tapasztalatbol, 1 xen hoston mondjuk tobb virtual server rajtuk apache-al nem jelenti azt hogy anyival tobbet is fog birni :) Sot ezzel a mindenhez vm igazabol rabolod a memoriat bar ha okosan takarekosan configolsz, teljesen jo megoldas. Akar poor-man's cluster is lehetne ;)

- Storage-nak OpenFiler-t raktam fel DRBD+Heartbeat-el - ez tárol minden közös adatot, configot, htdocs-t, de szerintem még a kérdéses session file-okat is közös tárterületre lehet hozni és akkor még a session is átvehető.

OpenFiler -t nem ismerem. Reszemrol csync2-ot javaslom. Drbd active-passive es ugye mindig csak az aktiv-hoz fersz hozza (legalisan).

Ndb szerintem masra van mint ami neked kell. Az egy nagyobb cluster. Csak a failover miatt 2 gephez .. egy regi poen: "hazasodni az konyu sexert olyan mint megvenni egy 747 -est az ingyen mogyoroert". NDB sok penz, sok ido, sok tapasztalat kell hozza es sok szivas lehet.

APache loadbalance es failover igazan egyszeru. Ha csak 2 gep akkor meg mindig ott az apache proxy balance -al. LVS-el is sima ha csync2-ot hasznalsz. De persze az ilyen kornyezetekben altalaban szoktak valami svn szeru verzio kovetot hasznalni es maris megoldodik a modositasok problemaja.

A gateway teljesen esszerunek hangzik.
DNS, hat azert van 2 altalaban. Mail hibaturo, majdnem csak felesleges ossze sz*pni egy redundans clustert ezert.

Persze minden itt leirt SZVSZ es nem flamelesbol vagy azert irom mert melysegesen hiszem hogy ez a legjobb, csak remelem hatha adhatok otletet. :)

drk

Természetesen 2 fizikai gépen futó 1-1 Apache VM között akarok loadbalance-olni.

DRBD cluster aktív-passzív. Így ugyan a VM-ek storage elérése is terheli a 2 gép közti direkt linket, de mai viszonyok között az szükség esetén viszonylag olcsón megduplázható.

Az NDB cluster valóban kicsit ágyúval verébre, a többi MySQL redundancia megoldás viszont inkább _csak_ redundanciára való, nekem viszont - a gépeken futó alkalmazás miatt - pont az SQL-nél lenne szükségem az optimális esetben 2 vasból kihozható nagyobb teljesítményre (is).

ui.: ugyan szinte minden részlet összebogarászható netről, de mivel úgyis dokumentálnom kell a rendszert, összedobok az egészről egy publikus komplex leírást