Redundáns Postfix + DRBD + XFS (Cluster FS helyett)

UNIX haladó

http://www.kutukupret.com/2011/06/19/postfix-realtime-maildir-replicati…

Ebben a cikkben leírt megoldás működőképesnek tűnik, a lényeg:

Így néz ki: http://www.kutukupret.com/wp-content/uploads/2011/06/Postfix-drbd-ocfs2…

- Lesz 2 elsődleges cluster fs (OCFS2) + DRBD, így mindkét szerverről írható a fájl rendszer. A fájlok így megoldva.
- Lesz aktív/passzív DRBD + XFS. A fájlok így megoldva.

Szolgáltatás: mindkettőn megy a Postfix. Erre én is gondoltam eddig, csak nem tudtam, a DNS MX rekordok hogy lesznek lekezelve, hát így:
Szolgáltatás: az aktívon megy a Postfix majd:

DNS szerveren:

example.com. MX 10 postfix1.example.com.
example.com. MX 10 postfix2.example.com.
postfix1 IN A 202.xxx.xxx.1
postfix1 IN A 202.xxx.xxx.2

Én még nem láttam azonos MX 10 MX 10 beállítást, általában 1 MX van, vagy ha kettő, akkor MX 10 és a backup-nak MX 20, ami tárolja a leveleket, amíg nem elérhető az elsődleges.

Ebben a cikkben közös MySQL szerver javasolnak, azonban ha lenne 3 node-os MariaDB Galera Cluster, akkor jól gondolom, hogy meg lenne oldva az adatbázis redundancia is?

Tehát a 3 szerverből kettőn lenne postfix, közöttük DRBD + OCFS2 (primary-primary) köztük DRBD+XFS aktív/passzív üzemmódban, de a postfix csak az aktívon futna, és a 3 node-os Galera Cluster-t használom, akkor ha az egyik postfix-es gép kiesik, akkor 100%-ban működik a levelezés tovább. Ha visszajön a kiesett gép, akkor szinkronizálódik a Cluster FS DRBD+XFS és a Galera adatbázis is.

Így működhet? Csinált valaki ilyet? Milyen elvi hibát vétettem?
CentOS 6 7 alapon akarom ezt összerakni.

Köszönöm előre is.

UPDATE 1:

- Lesz aktív/passzív DRBD + XFS. Tényleg nem akarom magamat szívatni, csak ha tényleg indokolt... :-)
- CentOS 7

  • 7500 megtekintés

( elod v | 2014. 08. 30., szo – 12:04 )

A 2 postfix 2 külön queue-val (antivírussal, spamassassin-nal) kéne működjön. A többi szolgáltatást hogy oldod meg?

Úgy terveztem, hogy a lokális queue és helyi fájlok nem a cluster fs-en lenne, hanem a sima EXT4-en, és csak a maildir, a levelek lennének a Cluster fs-en, amikor már bedobja oda a már átszűrt levelet.
A leírás szerint amit linkeltem, működnie kellene.
De ha kipróbáltam, írni fogok ha érdekel valakit, hogy mi lett.

Sakk-matt,
KaTT :)

( KaTT v | 2014. 08. 31., v – 15:10 )

Ha a DNS rekordban van 2 darab MX 10, akkor véletlenszerű, hogy hova érkezik az adat, vagy ABC vagy egyéb sorrend?

Ugyanígy, ha van 2 A rekord azonos névre, mitől függ, hogy melyik IP-re megy? Random vagy ABC vagy egyéb?

A bind értelemszerűen kezeli?

Sakk-matt,
KaTT :)

Ezek köszönet, az új infó volt.
Hogy tudok rrset-order-t beállítani a bind-nek, ha a szerveren ISPCONFIG van? (az a tippem, hogy sehogy)

Ezeket lehet felvenni a domain névhez a rekord fülön:
A AAAA ALIAS CNAME HINFO MX NS PTR RP SRV TXT

Ezek a domain zóna opciók, amik nem alap (zone, ns, email, Refresh, Retry, Expire, Minimum, TTL) dolgok:

Allow zone transfers to these IPs (comma separated list)
Also Notify
Update ACL

Ennyi.

Sakk-matt,
KaTT :)

( dap | 2014. 09. 16., k – 23:38 )

Egy aktív-passzív felállás lokális fájlrendszerrel gyorsabb lenne. Ugyan ez is működhet, de bonyolultabb, ami sose jó. Én a MySQL InnoDB-t szintén aktív-passzív felállásban futtatnám, a DRBD storage-on.

Sőt, az egészet betenném egy LXC-be, majd az LXC-t a DRBD fölött futtatnám és failovernél az LXC-t migrálnám el (a pacemaker-hez van LXC resource agent script). Egyszerű az absztrakció miatt, hiszen a cluster dolga csak annyi, hogy migrálja az LXC-t ha kell, az LXC-nek (és a benne lévő szolgáltatásoknak) pedig nem kell törődni azzal, hogy létezik a cluster. Robusztus, mert a konfigok és az egész környezet replikált, nem eshet meg az, hogy failovernél derül ki, hogy a konfigok nincsenek szinkronban a gépeken.

- Lesz aktív/passzív DRBD + XFS. Tényleg nem akarom magamat szívatni, csak ha tényleg indokolt... :-)
Most itt tartok.
Én is szemezek az LXC-vel, csak én Galera Cluster-ben gondolkozom, ami megoldja a szinkronizálást DRBD-n kívül természetesen.
Kérdés, hogy kell-e a Galera, vagy jobban járok egy DRBD-re rakott MariaDB (MySQL) adatbázissal, amikor ha elszáll az aktív, akkor a passzívon elindul a MySQL, aztán szép napot...
Mit javasolsz? Az a cél alapvetően, ha kiesik az aktív szerver, a passzív szerver automatikusan és lehetőleg fél percen belül, de minél gyorsabban átvegye a helyét, adatvesztés nélkül.

Én LXC-be a PHP-CGI-ket gondoltam, amit az nginx hívna meg szépen, különböző portokra rakva. Sőt, akár haproxy-val szétosztani a php cgi-k között a terhelést...
Aztán ott a varnish, memcached... mind hasznos lenne...
Felmerült a Xen is az LXC előtt, de ha csak a php-cgi-nek kell a szétválasztás, LXC is jónak tűnik a célnak.

Sakk-matt,
KaTT :)

A Galera Cluster itt fölösleges, hiszen a DRBD ígyis-úgyis kell, márpedig az meg tudja oldani a MySQL failovert is, így egy második cluster üzemeltetése csak a komplexitást növeli. Mivel az adatbázisod kevés adatot tartalmaz, így a DRBD alapú MySQL failover is elég gyors lesz (csak nehogy MyISAM táblát használj).

Alapszabály, hogy mindig a lehető legegyszerűbb megoldásra kell törekedni. Egy komplex setup csökkenteni fogja a rendelkezésre állást, nem pedig növelni.

Ha megépítessz egy olyan clustert, ahol az LXC DRBD fölött fut és a Pacemaker képes azt automatikusan migrálni, akkor rengeteg HA-t igénylő feladatra lesz egy frappáns válaszod, hiszen lesz egy oprendszered, amin az összes szolgáltatás eredendően HA lesz. Én ebbe az irányba mennék; szép, tiszta, újrafelhasználható megoldás. (Az LXC behelyettesíthető KVM-mel vagy Xen-nel is.)

De lesznek MyISAM táblák is, de erre is van a MariaDB-ben az Aria, ami crash safe MyISAM elvileg.
Mi a bajod a MyISAM táblákkal? Sok egyszerű select és főként olvasásra elég jó.

Igen, én is azért próbálom csökkenteni a különböző megoldásokat, hogy ne bonyolítsam az egészet.

"cluster, ahol az LXC DRBD fölött fut és a Pacemaker képes azt automatikusan migrálni, akkor rengeteg HA-t igénylő feladatra lesz egy frappáns válaszod"

Ebbe az irányba akarok elmenni, csak még nem tiszta az LXC, KVM vagy XEN út.

Van aki szerint érdemes a MySQL-t is XEN-be rakni, valamint a webszervereket is, adni neki 1-1 magot, és haproxy-val szétdobni a terhelést. Ebben az tetszik, hogy ha feltörik esetleg bármelyik webszervert, akkor a virtuális gépen belül vannak, valamint az, hogy jobban beosztható a memória és a cpu. Hátránya a virtualizáció okozta sebességcsökkenés, az extra tárterület és az extra memóriahasználat, mármint ha túl sok memóriát kap egy webszerver, nem használja ki, vagy épp ha túl keveset, akkor meg azért.

LXC-nél ha jól értem, ott jobban lehet a memóriát beosztani, limitálom a process-eket de ott nem lehet dedikálni a processzor magot, ami nem feltétlen baj.
KVM-ről keveset tudok.

Én abba az irányba mennék inkább el, hogy az alap CentOS 7-en futna az adatbázis szerver, lxc-ben a php cgi-k, simán az nginx web szerver, de előtte a varnish + haproxy (még nem dőlt el, hogy ebben a sorrendben, vagy előbb a haproxy majd varnish, mindkettőnek van előnye, hátránya), postfix + valami safe smtp megoldás, openvpn, samba (csak vpn-ről lenne használva, ezt is jól lekorlátoznám), memcached a php-nak, maximum ezek kellenek, amikre szükség lehet valaha is.
Még nem tudom, mit lehet érdemes LXC-be rakni a php cgi-n kívül.

Sakk-matt,
KaTT :)

> Mi a bajod a MyISAM táblákkal?
Ebben a felállásban gond, hogy nem naplóz. Failovernél lesérülhet, javítani kell, ami adatvesztés és idő. Az Aria-t nem ismerem, az lehet jó, mert pont a "crash safe" feature kell ide. A InnoDB tuti "crash safe".

A virtualizáció előnyeit/hátrányait jól látod. Fontos az, hogy LXC-nél gyakorlatilag nincs overhead. BTW az LXC bekorlátozható 1-1 magra is (cgroup cpuset).

Huh, jó sok feladatot bízol a host-ra. Mire mindegyik HA lesz -az adatokat, a konfigokat, a környezetet szinkronban tartod-, addigra le fog esni, hogy egyszerűbb lett volna ha a szolgáltatások konténerben vannak és a konténer maga failover. De erről már írtam.
Mindenesetre te tudod, ez is egy módszer, de a mai trendnek ellene megy. A trend most az, hogy konténerekben fusson minden az absztrakció miatt. A Docker is terjed mint a nátha.

" egyszerűbb lett volna ha a szolgáltatások konténerben vannak és a konténer maga failover"

Az Aria pont a crash safe-re megoldás a sima MySQL ISAM táblákhoz képest, de még nem teszteltem a gyakorlatban ezt, hogy működik-e.

Próbálom tökéletesen érteni, amit írsz, de nem biztos, hogy jól fogtam fel, ezért összefoglalom:

Tehát lesz 2 CentOS 7, azokon egy aktív/passzív DRBD. A DRBD XFS tárhelyre kerülnek az LXC összes állománya, a konténerek. Minden szolgáltatás külön konténerben lesz: postfix, nginx, php-cgi, mysql, varnish, haproxy, samba, memcached.

Failover esetén a passzív gép aktívra áll át (pacemaker + corosync) és elindítja az LXC-t, az LXC pedig a szolgáltatásokat, a konténerekben.

A konténerek pedig be lennének állítva, le lennének korlátozva ha szükséges, stb.

Így értetted? Ez így nagyon logikusan hangzik. Tetszik a logikus felépítése és alapvető egyszerűsége.

Azt nem tudom jelenleg, hogy az LXC-t hogy kell majd használni, de ígéretesnek tűnik.

Tehát a host gépen frissítem a kernelt, a DRBD-t, LXC-t, meg az alap CentOS 7 dolgokat, de mást nem, hiszen más nem is lesz rajta?

Az LXC-s konténeren belül a MySQL konténerben a MySQL-t frissítem yum update-tel, az nginx konténeren belül az nginx-et frissítem yum update-tel, stb... mintha külön szerver lenne. Jól értem?

Az sem tiszta, hogy fogja elérni a haproxy, varnish, nginx és az nginx cgi-k egymást, mármint hogy miket kell beállítani, hogy lássák egymást.
Az egyértelműnek tűnik, hogy a DRBD-n belül szétosztom könyvtárakra a szolgáltatásokat, lesz adatbázis, web és samba mappa, stb és ezeket használják az LXC-k, amit látniuk kell.

Sakk-matt,
KaTT :)

Igen, mindent jól értessz. A konténereknek lesz saját privát IP címük, azon tudják elérni egymást, IP-n. Az IP tartomány lehet ugyanaz a privát mint amit a szerverek és a leendő iLo-k is használnak. Port forward-dal el tudod érni, hogy a host-ra felhúzott publikus IP egyes portjaira bizonyos konténer válaszoljon (pl smtp-n, imap-en).

Nem egy egyszerű feladat, nem tudom mi a célod vele, de ha produktív környezet, akkor érdemes megfontolni azt, hogy bizonyos VPS szolgáltatók (pl. DigitalOcean) fillérekért adják a konténereket 99.99%-os SLA-val. Persze más kérdés, hogy leállás esetén csak a havidíj egyenesen arányos tört részét írják neked jóvá, ami magyarul azt jelenti, hogy semmi garancia nincs arra, hogy teljesítik is.

Köszönöm dap, hogy segítesz, és persze másoknak is itt és most megköszönöm... :)

Tehát lesz mondjuk egy postfix LXC-ben, ami a 110-es porton keresztül lesz publikusan elérhető, de a host átirányítja a 110-es portot például a 201 végű privát IP cím 110-es portjára? Jól értem, hogy a 110-es port használható, mert konténerenként, azaz IP címenként az összes port használható, függetlenül a host használt portjaitól?
Valamint azt is jól értem, ha a host gépre jövök be VPN-nel, akkor a leveleket a 201 végű gépről is lehívhatom, a 110-es portról, de a host gép 110-es portjáról is, mert az csak átirányítás a 201-es IP 110-es portjára, ami a postfix konténer?

Valamint a MySQL lesz a 220-as IP, akkor a postfix LXC konténernek SQL kapcsolat esetén a 220-as IP-re kell kapcsolódni, és a 220-as MySQL LXC-ben be kell állítanom, hogy fogadjon külső IP kapcsolatokat is, stb?

Tehát úgy kell felépítenem, mintha minden LXC egy külön fizikai szerver lenne, azonos, privát IP tartományban (mert ebben vannak) és úgy kapcsolódnak egymáshoz a szolgáltatások, IP-n, a host gép portjain elérve, átirányítással.

Nem zavar, hogy nem egyszerű feladat, szépen lépésről lépésre felépítem ezt... :) Jó játék lesz... :)

Az már csak hab a tortán, hogy a CentOS 7 network manager új számomra, gondolkozom, hogy kikapcsoljam-e, vagy hasznos lehet.

Sakk-matt,
KaTT :)

otkilences?

Mármint 99.999% rendelkezésre állás? :)
Igen, azt akarok csinálni, tesztből, játékból, kihívásból.
Hogy értsem, hogy működik, teszt környezetben. Mi ezzel a baj?
Megígértem magamnak, hogy megcsinálom. Meg akarom csinálni. Meg fogom. Csak kérdés, hogy milyen szinten.

Nagyon szerencsés vagyok, hogy itt van sok igaz ember, aki segít.
Én is segítek az élet sok területén sok embernek, de most oda jutottam,
hogy kénytelen vagyok segítséget kérni, mert elértem a tudásom határát és iránymutatás kell.
Aztán majd küzdök napokat, heteket az LXC-vel, meg a DRBD-vel, meg mindennel... és elégedett leszek, ha kész.

Sakk-matt,
KaTT :)

Jó ha tudod, hogy lehet... hogy tényleg éles üzemebe megy ez majd ez az egész. Akár más is hozzáférhet.

Kirakom az otthoni netemre, majd mobilnetről laptoppal kipróbálom a levelezést, szambát, weboldalt, rakok rá próbának létező php-s rendszert, majd kihúzom a konnektorból az aktív szervert, és izgulok, hogy átveszi-e a helyét a passzív. Majd küldök megint pár teszt levelet és letöltöm. Stb... :)

Bárcsak ott tartanék, hogy rutinból felépítek egy ilyet, elsőre...

Btw... LXC-nél érdemes, ajánlott vagy kötelező template-eket használni?
Centos 7-hez ezt találtam:

template script for generating centos container for LXC

https://github.com/lxc/lxc/blob/master/templates/lxc-centos.in

Sakk-matt,
KaTT :)

Igen, így működik.

> a MySQL lesz a 220-as IP, akkor a postfix LXC konténernek SQL kapcsolat esetén a 220-as IP-re kell kapcsolódni, és a 220-as MySQL LXC-ben be kell állítanom, hogy fogadjon külső IP kapcsolatokat is, stb?
Használd a konténerek privát címét amikor csak lehet, a publikus IP-re tekints úgy mint szükséges rossz. Lehetne fordítva is, de ez a triviálisabb módszer.

A NetworkManager-t kapcsold ki, csak be fog kavarni, semmi haszna itt.

(amúgy szívesen, ha ráérek)