1 postfix mail szerver bővítése 2 szerverre.

Linux-haladó

Sziasztok,

Az lenne a feladat, hogy egy működő postfix szerver mellé beállítsunk mégeggyet, ami alapvetően nem probléma de pár dolgoban szeretném kikérni a véleményeteket, hogy a lehető legkisebb behatással és a legésszerübben csináljam.
Tehát egy postfix mail szerver, mysql-ből dolgozik,courier, pop, imap, webmail.
KB 350-400GB levél található rajta.
Egy ugyan olyan vasat beállítunk mellé postfix és többi szolgáltatás belő, ezzel nincs is probléma, ami érdekelne ,ki hogyan oldaná meg a két szerver szinkronba hozatalát.
A cél az ,hogy mind a két szerver folyamatosan dolgozza a leveleket, fogadjon, küldjön, pop-oljon imap-oljon stb...
Ehhez mind a két szervernek ugyan azon adatokkal (levelekkel) kell bírnia.
A jelenlegi szerveren a lehető legkisebb behatás mellett kell megoldani.

1; Az első ötlet ami beugrott bár tudom butaság nfs share-en megosztani és kész. De ez elég nagy kockázat, jön a baltás gyilkos lezuzza a gépet amiről sharelünk és ugrott a másik gépen is szolgáltatás, mert nem lesznek meg a levelek.

2; drdb: Ehez ujra kellene az első gépet is húzni és formázni a diszkeket. Ez nem megvalósítható jelenleg. És ha jól tudom csak 2 gépet lehet vele kezelni, és ha jön az ötlet kellene még 1 harmadik gép is akkor ez bukta.

3; gluterfs: jo-jo, de kicsi fájlokra borzalmasan lassú , ez tapasztalat. A használata egyszerű de még kell kicsit fejlődnie.

4; Egy storage gép beállítása, és arról dolgoznának a többiek. Ha lehet ezt is el szeretnénk kerülni, bár ha a baltás gyilkos az egyik mail szervert zuzza le akkor nincs para, de ha a storage-t akkor megint csak meg vagyunk lőve.
.....

Ki milyen megoldást választana, hogy a jelenlegi szervereket fájl szinten szinkronba hozza és ezt fenn is tartsa.

Végig olvastam több mailes topicot is elszórva találtam erről infokat de szeretném összefogni, de ha van már ezzel foglalkozó topic akkor írjátok meg és ez semmisnek tekinthető.

Köszi.

  • 2757 megtekintés

( _ventura_ v | 2009. 11. 17., k – 16:34 )

"De ez elég nagy kockázat, jön a baltás gyilkos lezuzza a gépet"

és ezt hogyan teheti meg ? Nem a szobában vagy a folyosón kell szervert üzemeltetni ahol bárki bármikor barmolhat :>
mert akkor semmi értelme, 2 szervernek mert mindkét szervert is lelőheti nem ?

Core2Duo T7100, 4G, Ubuntu 9.10, 2.6.31

( blajo | 2009. 11. 17., k – 16:41 )

Csak egy otlet:
Ha a storage szerver komolyabban felmerul, akkor erdemes azon is elgondolkodni, hogy a 2 uj gepen osszerakni nullarol normalis clusterbe a rendszert.

Mas kerdes, hogy ezt 2 gep eseten is meg lehet csinalni: megepited fellabu clusterkent, beallitod elesbe, aztan ha minden oke, az eddigi elesbol megcsinalod a masik labat. (Egy kis downtime azert biztosan lesz, meg ha elsore sikerul is. :)

( junior013 | 2009. 11. 17., k – 17:24 )

Failsafe, load balance vagy is-is?
Ha sok virtual domain és csak load balance, akkor szétpakolnám a domain-eket, aztán keresztben backup MX és pop/imap proxy.
Ha failsafe, akkor legegyszerűbben talán DRBD, felépítve az új gépre a fél clustert, átterhelni, majd a régi gépre felhúzni a másik felét és beszinkronizálni alá.
Aztán, ha később tovább kell skálázni, akkor ezt a DRBD HA storage-ot elérheted a 3., 4., x. mail szerverről nfs-en. Nagyon később meg a DRBD clusterről le lehet venni a mail feladatokat, marad csak storage-nak.

( janoszen v | 2009. 11. 17., k – 18:43 )

LBt szeretnél vagy HAt? Ha HA, akkor elvileg újrahúzás nélkül is tudsz DRBDt csinálni ha a metadatat máshova teszed, de levelezés alá csakis C protokollt használj!

Ha LBt akarsz, akkor Dovecot proxy belső hálóval.

ELMÉLETILEG úgy megy a dolog, hogy összerakod a DRBD confot kulcsra készen, hogy a metadata valahol máshol lakjon. Ez után unmountolod a partíciót és elindítod a DRBDt úgy, hogy ő legyen a primary, majd a DRBD devicet mountolod föl.

MINDENKÉPPEN PRÓBÁLD KI ELŐTTE! Azt meg remélhetőleg nem kell mondani, hogy legyen mentésed.

Köszi, az infót, mielött nekiállnák mindenképp egy jo kis tesztelés következne. Nem fogok éles rendszerrel játszadozni.
Mentés az van, de eszembe juttattál egy kérdést, 300-400G levelet (rengeteg pici fájl) mivel a legcélszerübb menteni?

A DRBD-t ezesetben szerintem a kovetkezokeppen lehetne megcsinalni:
Az uj szerveren kialakitod a rendszert, felepited a drbd-resource-t, de csak egy fellabu rendszert csinalsz (ugy remlik, mintha lehetne, es nem kellene hozza hogy "lassa" a masik gepet is). Atmigralod a regi geprol az ujra a levelezest, majd a regi szerveren is megcsinalod a DRBD disket (ehhez muszaj formazni). Ha kesz a disk, hozzaadod ezt is a resource-hoz es ha mindent jol csinaltal ossze fog szinkronizalni a 2 rendszer. Mindenkeppen kell hozza egy primary gep, tehat ezzel a megoldassal csak HA-t tudsz elerni, load balancingot nem (kerdes, hogy cel-e ez).
--
TH

A cél , hogy ha valamely gépen adatváltozás történik az megjelenjen a a másik gépen is.
Amit leírtál az is jó ötlet, én is gondolkodtam rajta, csak hogyan oldom meg, hogy a két gépen lévő adatok percre pontosan szinkronba legyenek. Ekkor nem lenne kiesés a szolgáltatásban minden más esetben igen. Tegyük fel át syncelem a leveleket ami ekkora mennyiségnél nem kis idő. Mire ez végez rengeteg változás történt már a disken, így ha kicserélem az új gépre akkor sok dolg hiányos lesz. Max ha ezután nyomok még egy syncet neki...

Ezt úgy szokták, hogy egy előzetes rsync-et csinálnak ami vmikor éjjelre végez és remélem hogy nincs komoly éjjeli használat. Szolgáltatás leállít. Utolsó és úgymond véglegesítő rsync ráereszt, ami szintén nem lesz túl gyors, de kell. Új gépen szolgáltatás indít. Amit szeretnél az a felvázoltakból kiesés nélkül nem oldható meg rendesen szerintem, csak ezzel a minimális leállással járó módszerrel.

A janoszen féle módszert egy teszt gépen próbáld ki, de teljes mentés nélkül semmiképp se állj neki az éles gépen, akármilyen jól is ment a teszt. Ezen kívül sajnos csodát nehéz tenni.

A két gép között az SMTP forgalmat simán két MX rekord megadással (mail01, mail02 stb.) meg tudod oldani, de az imap/pop kérdés neccesebb.

( cabal v | 2009. 11. 20., p – 12:23 )

subscribe

Szerelem reggel, szerelem délben szerelem este... most már működhetne az a k..va szerver!

( melak | 2009. 11. 20., p – 17:52 )

"3; gluterfs: jo-jo, de kicsi fájlokra borzalmasan lassú , ez tapasztalat. A használata egyszerű de még kell kicsit fejlődnie."

Pedig ezekszerint a GlusterFS-t pont neked találták ki :)

"A key advantage is the GlusterFS modular architecture that allows modules to be stacked to match user requirements. You can use GlusterFS to quickly configure a standalone server system and later expand the system as your needs grow."

Kis fileokról elvileg nincs szó ha minden mysqlben zajlik, vagy nem jól olvastam?

( szilard_ v | 2014. 09. 15., h – 12:11 )

Látom jó régi a téma, DRDB miatt keveredtem ide.
Mi lett a megoldás végül?