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
- 2555 megtekintés
Hozzászólások
én natolással oldanám meg
- A hozzászóláshoz be kell jelentkezni
egyetertek...:) egyszeru bash script crontabba ami megfeleloen allitgatja a -to-destination mezot es kesz...
Ha szamit a kulalak akkor biztos van valami kevesbe garazs hack megoldas (load ballancer megfeleloen beconfigolva) bar ilyen teruleten meg nem neztem szet.
- A hozzászóláshoz be kell jelentkezni
vrrp esetleg?!
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
A kliens-oldalt szerintem nem illik bántani, vagy a szerver-oldalon kell a HA-t megcsinálni, vagy pedig valami tport jellegű megoldást (tport gateway) kell hegeszteni. ( http://www.freepatentsonline.com/6785741.html )
- A hozzászóláshoz be kell jelentkezni
Okos, ügyes konzulensed van. Miért ne lehetne már meglévő, jó eszközt erre használni?
Ez esetleg? http://pwet.fr/man/linux/administration_systeme/ucarp
Egy minta rá:
http://www.wiredfool.com/2008/09/03/ip-address-failover-on-debian-etch/
- A hozzászóláshoz be kell jelentkezni
Szia!
Közben kipróbáltam a Pound/Keepalived párost.Szépen működik is (végre)
Csak még a témavezetőm nem válaszolt az utóbbi 3 levelemre...:(
De a te javaslatodat is áttanulmányoztam az imént.Vannak ötletek,megoldások...ez tetszik :D
Köszönöm (Mindekinek)!
- A hozzászóláshoz be kell jelentkezni
A két adatbázis-szerver elé beraksz egy aktív/passzív HA-clustert, így akartad írni, nem?
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
É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
- A hozzászóláshoz be kell jelentkezni
Nem jó, legalábbis legtöbb esetben ugyanaz a kliens ugyanazt a rossz címet kapja. Terheléselosztásra a legegyszerűbb és jól működő megoldás, de ha-ra nem az igazi. A dns timeout baromi hosszú, ha rossz a kliens alkalmazás, belerokkan.
Üdv,
BaZso
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
Alapbol de, viszont rabeszelheto external locking-ra is, bar kompromisszumokkal (pl. a cache-eket ritkitani kell olyankor).
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
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! :(
- A hozzászóláshoz be kell jelentkezni
Shared storage vagy
http://www.drbd.org/
- A hozzászóláshoz be kell jelentkezni
olvasom máris..köszönöm!!!
- A hozzászóláshoz be kell jelentkezni
Érdemes a DRBD-t figyelemmel kísérni, mert egész szépen fejlődik.
- A hozzászóláshoz be kell jelentkezni
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 :(
- A hozzászóláshoz be kell jelentkezni
Találtam ilyet: Cyrus replication
http://cyrusimap.web.cmu.edu/imapd/install-replication.html
Nem lehet ez olyan rossz nekem nem? :)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Most olvastam ezt:
http://www.drbd.org/home/recovery/
Jól értem,hogy valóban nem kell szinkronizálni?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Érdemes berakni +1 hálókártyát cross kábellel a két gépbe csak drdb-nek?
- A hozzászóláshoz be kell jelentkezni
Én egy gigabit kártyás crosslink kábelre tettem a két gép közti "heartbeat"-et és a drdb syncer-t. 400GB-nyi adatot kellett első alkalommal szinkronizálni, amihez azért kell ez.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Én mindenképp dedikált gigás linken lógatnám össze a két vasat, plusz egy másik dróton a HA-t -- viszont az oda/vissza döntése a clusternek ellenjavalt :-P
- A hozzászóláshoz be kell jelentkezni
Ja. Ha kicsi a bugdet, akkor a heartbeat elmegy a drbd-vel közös kanócon, max kicsit lejjebb kell venni a syncer-t a biztonság kedvéért.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
A drbd egy activ / passziv megoldás a legtöbb esetben. Ha neked MySQL szinkronizáció kell, akkor nem a drbd a barátod.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Szia!
MYSQL replikáció is kell persze, de azzal nem tudom a messages mappát is "szinkronizalni",csak ugye azt amit aban tarolok.
Tehát arra keresek megoldást.Vélemény?:)
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Köszönöm!
Kipróbálom drdb-t.Figyelgetem.
Árban hol kezdődnek ezek (pl.:AX-150i)?
Lehet,hogy megemlítem ezt a megoldást alternatívaként.Köszi még1x!
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
É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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni