tartalék email szerver

Linux-haladó

Szeretnék két email szervert üzemeltetni úgy, hogy a levelek szinkonban legyenek.
Azaz az első MX-en élő működne mint általában: postfix, dovecot..., postgresql, maildir, samba4, openchange, ( de egyelőre az adatbázis szinkonnal és az opencange-el nem kell foglalkozni, későbbi kérdés ).
A másodikra mutatna a második MX rekord, és relay az elsőre, de szeretném ha ezen is teljes lenne a userek maildirje.

Ha az első meghal, valamilyen HA-s, ip váltós megoldással már a második szerverre csatlakoznának a kliensek imap, és így is látnák a teljes maildirjüket (észe sem vennék hogy az első meghalt)

Aztán ha az első feléled újra, akkor a közben bejött, kiment leveleiket a másodlagos továbbítaná az elsődlegesre, és kliensek (HA ip), vissza az elsőre.

Tudtok valamilyen módszert ilyen relay-re, a levelek szinkonban tartására?
Nem filerendszer szinten szeretném..., azaz nem rsync, drbd, ilyesmik..., hanem önmagában a levelezőszerverekkel megoldható?

  • 4348 megtekintés

( pirate | 2015. 08. 03., h – 10:29 )

Imapsync vagy valami hasonlo (google segit).
De van ertelme? Ha hirtelen esik ki az egyik akkor ugysem lesz tokeletes a szinkron ha sok a mailbox.
Miert nem csak siman backup MX-et csinalsz?

-----
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

Nem. :)

Több kérdés van, amit szerintem még nem tettél fel magadnak és nem jártad körül. Az első, hogy pontosan mekkora rendelkezésre állásra van szükség és mi az, amihez nem elég egy redundáns tápos hotswap hdd-s vas? Mi lesz a legszűkebb keresztmetszet, gondolok itt példul a netkapcsolatra.

( Zsugabubus | 2015. 08. 03., h – 10:45 )

Cyrus 2.6-ra írják a multi-master replikáció támogatását, a master-slave most is benne van, de nekem a 2.4-es szériában voltak vele gondok, így már nem használom. DRBD pedig egy jó megoldás lenne, még ha ezt nem is szeretnéd.

Szerintem a drbd itt csak egy szükségmegoldás, ezt meg kell tudni oldani email szerver szinten is. Azaz úgy, hogy a két szervernek nincs közös része... drbd.
Cyrust olvasom, köszönöm..., de közben találtam ilyesmit is: http://wiki2.dovecot.org/Replication bár még nem teljesen világos számomra...

( sj | 2015. 08. 03., h – 12:17 )

recipient_bcc_maps a masik gepre? Btw. az email archivalas nem jatszik? Az pont azt (is) tudja, hogy minden level meg egy masik helyen is elerheto. Es abbol konnyebb 2 peldanyt csinalni, amelyek a vilag 2 ellentetes vegen is lehetnek akar.

--
"Egy fekete farmer szvsz [...] sokkal kenyelmesebb nagy melegben." (hrgy84)

( _Franko_ v | 2015. 08. 03., h – 12:28 )

OpenLDAP master-master meta-adat-bázis, GlusterFS replika a teljes maildir-re, egyenrangú MX az ördögtől való lenne? 2015-ben miért gondolkodtok még mindig master-slave és/vagy active-passive gépekben? :)

Ráadásul ez az architektúra skálázható horizontálisan és vertikálisan is, bármelyik komponense cserélhető (frissíthető!) menet közben, ésatöbbi.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Az a tapasztalat vele, hogy abszolut nem lehet tudni, hogy mi van replikálva, és mi nem. DRBD-nél pl. a C protokoll garantálja, ha az írás teljesül, akkor az megvan a másik oldalon is. Glusteren meg semmi ilyen garancia nincs. Simán lehet inkonzisztens a másik oldal, és még csak nem is tudsz róla. Videoszervert replikálni talán használnám.
A másik meg, hogy mmap és lock sem nagyon működik rajta, amiket a cyrus is, és a dovecot is szereti, ha van.

"Az a tapasztalat vele, hogy abszolut nem lehet tudni, hogy mi van replikálva, és mi nem."

Erről tud a RHEL support is? Emlékeim szerint pont azért lassú és körülményes az írás, mert megvárja a replikákat és distributed lock-ot használ. Ettől persze el lehet térni, hogy gyorsabb legyen, de akkor nem kell azért panaszkodni, hogy néhol nem konzisztens.

"A másik meg, hogy mmap és lock sem nagyon működik rajta, amiket a cyrus is, és a dovecot is szereti, ha van."

Dovecot esetén az mmap letiltható, a distributed lock pedig van GlusterFS-hez.

Én pár éve végeztem teszteket elosztott Postfix-Dovecot-OpenLDAP konfiggal GlusterFS alapokon, nem vettem észre különösebb problémákat, simán lábonlőhettem bármelyik node-ot terhelés alatt és ment tovább. De YMMV, ha nem, hát nem.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Dovecotnál megnéztem, nagyon nem ajánlják a glustert, amúgy ez a fájl szinten replikálunk elég rizikósnak tűnik, egy meglévő fájlba írás mikor jelenik meg a túloldalon? Ha lezárják a fájlt? A mailszerverek használnak adatbázisokat is (cyrus biztosan), ezekre megint nem egy életbiztosítás a Gluster.

Mint írtam volt, van distributed lock, tehát a replikált írás jól működik, persze vannak limitációk, például csak maildir a célszerű és nem mailbox a használható formátum, ki kell kapcsolni az index cache-t, és az adatbázis OpenLDAP-ban van (mostanában már lehet MongoDB-re vagy Cassandra-ra is tenni), ami szintén master-master replika volt.

Nyilván megszokásból bármit nem lehet megcsinálni elosztott környezetben, vannak limitációk, amiket át kell gondolni aztán le kell tesztelni, viszont nagyon sok előnye van a master-slave vagy active-passive megoldásokkal szemben, mert rugalmasan bővíthető akár napi szinten az igények szerint és minden gép ki van használva, nincs "túlméretezve" az üzemeltetési idő nagy részében.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Én elhiszem, hogy teszt szinten működik, de azért az, hogy fuse fájlrendszer, plusz a FAQ-ból ez (amit egyébként egy balfaszul tervezett rendszernél személyesen is tapasztaltam):


15. I am getting weird errors and inconsistencies from a database I am running in a Gluster volume

Unless your database does almost nothing, this is expected. Gluster does not support structured data (like databases) due to issues you will likely encounter when you have a high number of transactions being persisted, lots of concurrent connections, etc. Gluster *IS*, however, a perfect place to store your database backups.

nem győz meg arról, hogy mail szerver storagnek akarnám használni.

"nem győz meg arról, hogy mail szerver storagnek akarnám használni."

Azért a maildir az messze nem database... és pluszban nincs fájlon belüli random írás, minden fájl egyetlen egyszer szekvenciálisan íródik és ha egyszer létrejött, akkor a fájl neve és/vagy a könyvtár módosul csak, a tartalom nem.

Szerintem ez egy tipikus használati esete egy distributed fájlrendszernek.

"Én elhiszem, hogy teszt szinten működik"

Milyen szinten kellene még működnie? Én élesbe mentem volna a tesztek alapján, aztán nem volt rá szükség.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Mondjuk a cyrus adatbázisait"

Leírom mégegyszer és utoljára: "elosztott Postfix-Dovecot-OpenLDAP konfiggal GlusterFS alapokon [...] vannak limitációk, például csak maildir [...] ki kell kapcsolni az index cache-t, és az adatbázis OpenLDAP-ban van"

Nem Cyrus, nincs adatbázis replikálva, memóriában van a Dovecot indexe, én ezt raktam össze, ezt teszteltem, ez működött, minden más esetben YMMV... :)

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

> "Az a tapasztalat vele, hogy abszolut nem lehet tudni, hogy mi van replikálva, és mi nem."
> Erről tud a RHEL support is?

Igen, ez köztudott. Az outdated/split-brain replika detektálása csak full scan-nel lehetséges, nincs globális állapotjelző. A Self-Heal Daemon próbálja az inkonzisztencát egy bizonyos időablakon belül tartani, de ennek sikere erősen függ a környezettől (IOPS teljesítmény, fájlok száma, stb).

Glusterfs-nél sosem lehetsz biztos abban, hogy a fájlod valóban redundánsan van-e tárolva. Persze ettől rengeteg helyen nagyon jól használható.

"Glusterfs-nél sosem lehetsz biztos abban, hogy a fájlod valóban redundánsan van-e tárolva. Persze ettől rengeteg helyen nagyon jól használható."

Ahja, ez erősen use case függő. Az általam vázolt esetben a fájlok létrejönnek, úgy maradnak aztán törlődnek. A tartalmuk nem módosul soha többé.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Végig kell gondolni, hogy milyen igénybevételre kell a replikáció... mert a GlusterFS olvasásra nem marad el jelentősen a helyi fájlrendszertől (mert helyben van a teljes replika), írásnál pedig valóban van egy tranzakcióra jellemző overhead, ami kis fájloknál arányaiban nagyobb, de meg kell nézni, hogy mekkora az írás/olvasás arány és ki kell mérni, hogy a többi megoldáshoz képest mennyire lassabb vagy gyorsabb (mert lehet gyorsabb is...).

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Fájlok megnyitásánál bizony jelentősen elmarad az (replikálás esetén), a self-healing miatt. A kliens sosem lehet biztos abban, hogy a helyi példány up-to-date, emiatt a távoli szervert ugyanúgy meg kell szólítania, megnézni a fájlt és az összes parent állapotát a rootig. Ehhez képest az, hogy 200 bájtot helyből olvas ki és nem a hálózaton, már lófütty, ezért jelentős az overhead.

( wpeople v | 2015. 08. 03., h – 12:50 )

bennem felmerült egy olyan kérdés, hogy mi van, ha a küldő éppen nem tud csatlakozni
az MX1-re. Az MX2 fogadja a levelet, kirakja local-ba és az MX1-re is?

Mi van, ha MX1 és MX2 nem látja egymást - de az internet mindkettőt?

Ebből lehetnek a szép split-brain események :-)

( bra | 2015. 08. 04., k – 07:55 )

Jfyi, a sok alternatív megoldás helyett a dovecot tud tetszőleges store-t (maildir, dbox stb) szinkronizálni.
Dsync-et keress, be lehet állítani "fixen" is, ha változás van, szinkronizál.
Sajnos nem a világ leghatékonyabb megoldása, de hacsak nem nagy, szolgáltatói környezetben vagy, ebből valószínűleg semmit sem fogsz észrevenni.

Van tapasztalatod is vele ugye?
Megtaláltam már, köszönöm! ...ez eddig a legszimpatikusabb megoldás. A napokban csinálom, aztán teszt...

Amikor azt írtam hogy "meg kell tudni ezt oldani program szinten is", nem ilyesmi megoldást képzeltem el, de biztos megvan az oka hogy így valósították meg. (majd talán a konfig, teszt alatt rájövök hogy miért így)

Alapvetően egy kisebb irodához kell nekem, max ötven postafiók..., ami viszont fontos, merthogy olyan az ügymenet, hogy ha meghalna az elsődleges szerver, akkor is menjen a levelezés, és a régi maildir is elérhető legyen. Azaz ne kelljen megvárni, míg backupból vissza az elsődleges.