IP "átkapcsolás" - Debian

Sziasztok!

Adott két Linux-os "szerver" melyek Master-Master replikációt használnak a mysql adatbázis "szinkronizálásához".

Egyik pl.:192.168.1.100 (szerver-1)
Másik pl.:192.168.1.101 (szerver-2)

Ha az egyik kiesne/tönkremenne/stb,akkor a másiknak kéne átvenni a helyét.
Tegyük fel,hogy SZERVER-1-hez kapcsolodnak a userek egy 3.gépen keresztül,ami az alábbi lenne:

Gondoltam,hogy a ket szerver elé beteszek egy kisgépet ami útvonalkapcsolókent funkcionálna (Debian alapon)

Tehát legyen ez a gép pl.:192.168.1.200

Hogy tudok olyat csinálni, hogy a userek a 192.168.1.200 géppel álljanak kapcsolatban,ami alapesetben átirányítódik a 192.168.1.100 (SZERVER-1)-re és, ha az nem elérhető,akkor mutasson a 192.168.1.101 (SZERVER-2) -re.

Akár x másodpercenként figyelgethetné a gépeket (szerver-1 és szerver-2-t) és ha szerver-1 kiesik,akkor átváltana szerver-2 -re és jelezné, ha kiesett illetve azt is,ha a másik esik ki.

Nagyon várom az ötleteket..
Köszi!
Bayao

Hozzászólások

A kisgéped fog legelőszőr besz@rni...
Ha már van szerver, meg backupszerver, akkor ne teremtsünk single point of failure-t, mert nem okos dolog.

vrrp +1

Hagyd az "útvonalkapcsoló"-t (z0mg), es hasznalj heartbeat-et.

Szerk: a mysql replikacio ugye nem a binlog-kuldos fajta? Azzal is lehet gyonyorueket szivni, master-masterben kulonosen.

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

Igen először én is megörültem,hogy megpróbálom heartbeat-tel, de a konzulensem kérése volt,hogy máshogy tegyem :(

Replikáció eddig szépen muzsikál :D

Köszönöm az eddigi ötleteket.Igyekszem sokminednt elolvasni a témában.Addig is bárkinek bármilyen ötlete van szívesen tágítom vele a fejemet! :D

Parancsot meghágni... :-)

A megoldás ordít heartbeat-ért. Ha más kell, "programozd le" a funkcionalitást, neked csak az ip tologatás kell némi életbenlévőség figyeléssel.

Vagy a kliensnek kell tudni, hogy több szerver van (és timeout után ő vált), vagy a szerverfarmnak kell önmagában "ha"-nak lennie.

Üdv,
Zsolt

A két adatbázis-szerver elé beraksz egy aktív/passzív HA-clustert, így akartad írni, nem?

Bocs, biztos naiv dolgot írok, de ha van két szervered, mindkettőn fut jól bekonfolva egy szolgáltatás, ráadásul master-masterbe tükrözve - azaz bármelyiken is történik változás, az továbbküldi a másiknak -, akkor miért nem oldod meg DNS-ből a dolgot? Vedd fel mindkét IP-t ugyanarra a névre. Így round-rubin hol az egyikre, hol a másikra csatlakoznak a userek, kiesés esetén meg úgyis újrapróbálkozik a kliens, és akkor előbb-utóbb a másik IP-jét kapja (feltéve, ha nem cache-lte be, mert akkor nem műx. Egy próbát megér).

Szerintem pont az a feladat, hogy a megoldási lehetőségeket számba véve, azokat összehasonlítsa, majd kiválassza az adott feladathoz optimálisat. Kapott némi iránymutatást, ülepedik egy kicsit, némi utánaolvasás, a hivatalos konzulenssel megveszélés, és utána kiderül, hogy melyik irány kifejtése javasolt.

Én ehhez hasonló elgondolásból írtam egy Netfilter/Iptables match-et.
A neve iface. Végtelenül egyszerű, de pl. ha cross-link kábelt alkalmazol gépek között, akkor meg tudod mondani, hogy az adott interfészbe be van-e dugva a háló....
Ha nem, akkor lehet átirányítgatni...

http://www.glsys.eu/iface
--
Debian Linux rulez... :D

Amire Neked szükség lesz, azok a Heartbeat, DRBD kulcsszavak. MySQL replikációval is meg tudod csinálni, de tengernyi szívásnak nézel elébe, ha ezt az utat választod. Konkrétan akkor fogod ezt érezni, amikor lerohad az egyik szervered és utána vissza kell szinkronizálni az adatokat.

A DRBD/Linux HA megoldással filerendszer szinten szinkronizálod a dolgokat, ráadásul ez egy olyan technológia ami erre lett kitalálva. Arra figyelj, hogy a MySQL táblaellenőrzés sokáig tud tartani egy átkapcsolásnál, tehát a timeoutot tekerd megfelelően magasra.

ilyenkor nemhulyul meg a mysql ha alatt megvaltozik a db fajl: egyik server beleir valami adatot a DB-be, drdb-vel atkerul a modositas a masik mysql "ala", az tuni fogja hogy valami megvaltozott?

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Sziasztok!

Működik a replikáció és az átkapcsolás is pound/keepalived párossal, de valamire nem gondoltam..
Szóval,userek,webmail beállítások (roundcubemail),címjegyzékek stb szépen szinkronizálódnak.De az üzenetek nem!

Cyrus tárolja őket.Olvasgatok a Cyrus replication-ról...de hátha alakinek van jobb ötlete.

Nem tudom az üzeneteket is valahogy mysql-ben tárolni?(Lehet,hogy butaság?!)

Hogyan lehetséges megoldani azt,hogy az üzenetek is replikálódjanak?
(Helyileg megvannak:/var/spool/cyrus/mail)

Köszi! :(

Szia!
Mindket gepen /var/spool/cyrus helyen vannak a levelek.

Mi lenne ha csak x masodpercenkent rsync-el masolnek valtozast?

Vagy ha a szerver-1 /var/spool/cyrus-t mountolnam a szerver-2 /var/spool/cyrus helyre és mindket gep a szerver-1-en levoket hasznalna,aztan,ha szerver 1 kiasne,akkor a szerver-2 belinkelne egy masik konyvtarat ahol egy rsync-es masolat lenne.Majdha szerver-1 folall,akkor visszacserelodne?

Ezek hulye otletek?
Már csak ezt kene megoldanom..A leveleket :(

Olvasgattam a DRDB-ről.Nagyon tetszik.
Eljátszottam a gondolattal,hogy kipróbálom és ezzel valósítom meg, hogy a /var/spool/cyrus konyvtarak tartalma azonos legyen.

De azon gondolkozom,hogy ha a master szerverem leall,visszaérkezésekor pl rsync-el szinkronizálhatom a konyvtarakat?
Akar egy tobb napos leallas utan,hogyan synkronizaljam a konyvtarakat

Keepalived-nel van lehetosegem arra,ha egyik vagy masik gép master ill. slave allapotba kerul,akkor egy script lefusson? Jelenleg csak egy BEEP "script" fut és visít,ha állapotváltozás történik (gép lehal,stb) illetve e-mailt-küld,de ez nem tartozik ide.

Várom a hozzászólásokat!

Köszönöm!Bayao

Most csináltam drbd-vel egy cluster-t. A "közös" diszken van a /var/www és a mysql "data" is. Ha a master node lepusztul, a mysql szolgáltatás a heartbeat-tel átvándorol a másik hostra, a ugyanazt a diszket használja tovább. Semmit sem kell szinkronizálni.

Ha a master node visszatér, a failback megtörénik automatikusan.

--
trey @ gépház

Automatikusan szinkronizálja magát. Ez egy - parasztosan fogalmazva - RAID1 a hálózati kártyán keresztül. Teljesen olyan mintha két lemezt megtükröznél. Amikor az egy node kiesik, a másik node-ra kerül mount-olásra a közös "diszk" (pl. /dev/drbd0) és ott a heartbeat elindítja a megfelelő szolgáltatásokat.

Ígértem már, hogy ha van rá igény, csinálok egy lépésről lépésre howto-t mondjuk egy egyszerűbb MySQL, Apache, PHP, postfix, Horde, ftpd, ntpd, freeradius, lopikula cluster megoldásról. Ezek szerint lenne rá igény.

--
trey @ gépház

Nálam van mysql replikáció a két mail szerveren ami a feladatom része volt (szakdolgzat)
De az uzeneteket is szinkronban kene tartanom,emiatt erdeklodok most a drdb utan.

OK-Postfix,Cyrus,Mysql,OpenMailAdmin,saslauthd,Apache2,RoundCubeMail
OK-Pound/Keepalived átkapcsoláshoz
??-/var/spool/cyrus -ben levo uzenetek is azonosak legyenek a gepeken.

A drbd elvileg jó _lehet_ azt kell megnézni pl. hogy a performanciája elegendő-e? A hibatűrése milyen (lehet-e raid-tömböt alárakni)? Mi van, amikor a fele kihal, majd visszajön, mekkora a szinkronizálás idő- és teljesítményigénye? A kialakított rendszerben hogyan lehet a spof lehetőségét minimalizálni?

Célszerű lehet a fenti problémákat összevetni egy iSCSI tárolótömb (pl. AX-150i) lehetőségeivel (duál vezérlő, multipath/failover kapcsolat).

A "hol kezdődik" ott kezdődik, hogy mit szeretne az ügyfél -- neked dupla vezérlős, dupla tápos megoldást kéne nézni, tárkapacitás, illetve diszkek száma, RAID-level igénytől függően... Erre árat max. kereskedő tudna mondani, mert én elsősorban műszaki oldalról foglalkoztam ilyesmivel.

Értem!
Azért kérdeztem csak,mert kisvállalkozásokhoz kapcsolódik a szakdolgozatom és ha 40-50 ezertől akkor megemlítem mint alternatíva de ha sok 100ezer akkor inkább nem,de örülök,hogy most legalább ennek is utánaolvastam.:)
Köszönöm..Még kezdő vagyok,de nagyon érdekel :D:D

40-50E??? Egy diszk, esetleg :-)) Azt kell megnézni, hogy a teljes IT-infrastruktúra mekkora háttértár-igénnyel lép fel, és ezt mivel (DAS, NAS, SAN) lehet ésszerűen és költséghatékony módon kielégíteni -- hozzávéve azt is, hogy a tárolómegoldásnak az üzletileg kritikus HA-klasztert is messzmenőkig ki kell tudnia szolgálni.