postfix cluster

Linux-kezdő

Hi!

Van 7 darab mail szerver, ami nagyjabol napi 3- 4M level kezbesiteset es fogadasat bonyolitja le. A spamek aranya 50- 90% :- ). Ezek teljesen kulonalloak, ossze vissza van takolva, bar szerintem elegge ugyes modon.

A vezetes kitalalta, hogy csinaljunk egy nagy nagy postfix clustert, ahova mindent migralunk. Ezzel kapcsolatban erdekelne mindenkinek a velemenye.

A vezetes ugy szeretne, hogy kezdetben minden feladatnak egy kulon szerver, tehat egy a postfixnak, egy a spamfilternek, egy a viruskergetonek, 1- 2 a storage- nak, szoval szepen szetvalasztva.

Kerdesem leginkabb az lenne, hogy ennek ki mennyire latja ertelmet, illetve ha van, milyen jobb megoldas lehetne helyette. Szep es jo, hogy szetvalasztunk mindent, de mi van, ha pl. az egy szep spamfilter kiesik? Az eleg ciki.

Hogy erdemes Nekiallni egy ilyen rendszer tervezesenek is. Ez nyilvan nem 2 nap lesz. Masfel honapot szannak ra, bar itt minden lassan megy, szoval gondolom 2- 3 het elegendo kell, hogy legyen, de ez most nem szamit.

Van hozza esetleg egy jo kis howto tanacsokkal, buktatokkal? Sajna nem talaltam kifejezetten erre a celra valo howto- t.

Az is jo lenne, ha le tudnatok irni, hogy ki szerint miert hulyeseg / jo az egesz, elonyok / hatranyok, ill. hol lehetnek buktatok.

A jelszavaknak biztos lesznek, mert a mostani 7 szerveren 4 fajta titkositas van. Azokat nehez visszafejteni :- ). Pl. ha az ujon md5 lesz a jelszavaknak, akkor az md5- osekkel meg nem lesz gond, de a tobbivel. Nyilvan user oldalon kell megoldani, esetleg egy kis belepteto webes alkalmazas, vagy ra kell kenyszeriteni a usert, hogy 30 napon belul valtoztasson jelszot, kulonben irgumburgum, es az ujonnan valtoztatott jelszavakat mar egysegesen tarolni.

Koszi a valaszokat.

----------

Akinek van 3 perce, toltse ezt ki: http://256.hu/kerdoiv

  • 1723 megtekintés

( Esc | 2008. 11. 21., p – 15:02 )

Egyik vezetőt tedd meg smtp szervernek
egy másikat meg utána spamet szűrni,
a harmadik jó lesz a vírusok ellen,
a negyedik meg kezelje a storage-t.:)
Nagy isten állatkertje.. mit vezetnek? Kocsmát?:)

Hát.. én a helyedben kétszer is meggondolnám, hogy belevágok-e, ugyanis ha nincs rálátásod a
technológia buktatókra, ha nincs kellő tapasztalatod, alaposabb ismereted a megoldásokról, akkor
szívni fogsz.
A kezdő rovatba írtál.. ami elég elgondolkoztató.. szerintem.
A lenti hozzászólásokkal meg vigyázz.. elolvasva legalább annyi használható ötlet van bennük, mint
amennyi használhatatlan.

Fura, hogy ezt írod, mármint hogy elgondolkodtató, hogy a Linux- kezdőbe raktam. Egyszer raktam valamit még nagyon régen a haladóba, és le is szólt valaki érte, szóval ha nem találok kategóriát, akkor alapból ide rakom, pedig sokat gondolkoztam, hogy ez tutira mehetne a haladóba, de végülis így maradt.

Technológiailag van némi tapasztalatom, de nem ekkora méretben, és minden infót szeretnék begyűjteni, minden vélemény érdekel. Magam részéről tök hülyeségnek tartom az egészet, de nem én vagyok a főnök. Nyílván, ha visszamegyek, hangot adok ennek, de val. nem sok értelme lesz. Persze a cég anya helyzetét elnézve simán meglehet, hogy különbontunk minden szolgáltatást 1- 1 szerverre, és 2 hét múlva mindegyikből csinálunk még kettőt, és akkor lesz 21 szerver, és itt közel nem a leggagyibb szervereket használják, csak kérdés, hogy ennek is mennyire van értelme. Persze, mivel a mostani rendszer eléggé összetákolt, nehéz kibogozni, hogy melyik komponens mennyit erőforrást eszik.

----------

Akinek van 3 perce, toltse ezt ki: http://256.hu/kerdoiv

( djsmiley v | 2008. 11. 21., p – 20:09 )

Hali,

Én a helyedben load-balance-on gondolkodnék.
SAN hálózat, GFS v. GPFS v. OCFS (ez esetben term. mbox formátum) és minden szerver mindent csinál. + 2 ha-clusterben load balancer.

Kb. így lenne értelme.

Avagy, vegyetek 2 IBM x3950M2-t v. 3-at, dugdossátok össze Scalablity kábellel és lesz 16-32-48 CPU-d, azon már "elketyeg" :-D

Üdv,

Zoli

Tcp offload...

Ok h. 10Gb ethernet, de mi fogja neked kihajtani? P4 2.8, 512 RAM? Kétlem..."

Oh SAN. De mi fogja kihasználni? Pop3 és imap? Kétlem....

Egyébként az alsóbb kategóriás SAN-okban is általában Xeon-ok a vezérlőprocesszorok...

Tudni kell, hogy mikor milyen technológiát érdemes használni, és ide nem való SAN, hacsak nem több százezer (v. millió) mailboxról beszélünk.

Ha meg több szervert akarsz rákötni, akkor kell SAN switch is (jönnek az újabb milliók), meg valami konkurensen írható file rendszer...

bár szerintem jelen esetben mailbox szervernek bőven elég egy vas, amire a 6-7 smtp szerver forwardol. (Ezeknek meg nem kell szinte semmi diszkhely.)

A helyzetet látva gyanítom történelmileg, és politikailag alakult így, hogy több szerver van, nem pedig értelmes tervezés eredménye. A tények pontosabb ismerete nélkül még az us lehet, akár 1 szerver is elvihetné az egészet....

A fájlrendszer nem olyan nagy probléma szerintem ebben az esetben. Lehet akár OCFS2 is, az egész használható (igaz nem tud fcntl() lockingot, de nem is nagyon kell jelen esetben.
A SAN switch valóban drága mulatság és ami említettél tervezési hiba az tutira fennáll, ahogy leírta a rendszert a kérdező. Mindenesetre abban megegyezhetünk h. pontosabb adatok nélkül mind2 állítás megállja a helyét. (NFS vs. SAN)
Sőt, még azt is meg merem kockáztatni h. 1 combosabb gép simán elvinné az egészet és a jelenlegi sok szerver felesleges energia/idő/pénz kidobása. Go Green Computing, go! :)

Szerintem az első és legfontosabb kérdés ebben a projektben, amit még a tervezés előtt meg kell válaszolni, az az, hogy mennyi pénzt szánunk rá.

nettó 5M alatt (feltéve, hogy új szervert nem akarnak venni) nem érdemes SAN-ban gondolkodni.
Nettó 5-10M között már szóba jöhet a SAN -új gép vásárlás nélkül.

Totál új szerverek + SAN minimum kb. 20M HUF + áfa.

Egyébként, most látom, hogy adva van napi 3-4M levél, 50-90% spam aránnyal. Ebből már viszonylag jó becsléssel lehet méretezni, bár a pop3/imap/webmail aggregált terhelést érdemes előtte 2-3 hétig monitorozni.
Ekkora levélforgalom azért valóban sejtet annyi usert, hogy esélyes legyen a SAN.

És mi lenne ha ebben az esetben valami kompaktabb megoldást csinálnának. Pl. lehet manapság elég jó áron belépő szintű BladeCentert vásárolni. gondolok itt az 5-10M értékhatárra, sőt, szerencsés esetben (pl. most van vmi IBM akció Blade S-re) akár az 5 alatt is. Abban pedig minden megvan ami kellhet, nyilván teljesítményfűggő, hiszen ez nem SAN lenne, de az infrastruktúra dobozon belül adott lehet.
Egyéb esetben pedig mondjuk DS4XXX szériát megússzák mondjuk 5-8M-ból. ehhez a plusz FC kártyák mondjuk szerverenként 2K. Ha cserélik a gépeket is, akkor mondjuk gépenként 1-1.5M, de nem biztos h. kell belőle 7, jobb esetben 4 is elég lehet mondjuk 2x quad core xeon elég jól teljesíthet.
Nyilván a pontos terhelési adatok ismerete nélkül nehéz jól saccolni, de tételezzük fel h. a 3-4M levélből csak 2-3%>1M. Így az IO performancia nagyjából azért kiszámítható.
Alternatívaként tudom javasolni még akár azt is ha valóban ilyen sok a spam, hogy valami hatékony kereskedelmi megoldással (load-balanced cluster persze) szűrjék meg, akkor kisebb hw kell már a legitim levelek feldolgozásához. Talán ez lehet egy okosabb megoldás a "javak" elosztásához ;)

Én nem tom, de értelmes postfix rule-okkal már eleve nem lehetne a bejövő levelek 70%-a spam. És akkor még rbl-t sem kell ehhez használni. Rbl-el (bár én nem nagyon szeretem) meg szerintem még lejebb lehet szorítani. Lehet hogy a próbálkozások száma 70%-ban spam, de ezek többsége el sem jut a contentfilterig, mert már maga a postfix sem foglalkozik velük. A filteren meg a 80%-a fennakad a maradéknak.

Na mindegy. Tök egyetértek veled egy kereskedelmi mailgateway megvételével kapcsolatban. Egész jókat lehet már venni 3-5 milláért, amik a 95%-t megfogják a spam-nek, gyönyörűen managelhetők, a főnökség számára csili reportokat lehet velük gyártani, stb., stb. :)
Érdemes elgondolkodni rajta, ha nincs meg cégen belül a kellő szakértelem. Anélkül bajos lesz postfix hegyeket üzemeltetni.

Csak pusztan postgrey-jel meg jol megvalasztott postfix konfigbejegyzesekkel 20% ala szorithato a spam.
Es igen, jo lenne ide nemi szakertelem, mert ami jelenleg van, az bizony kevesnek tunik. Meg akkor is kell, ha egy mailgw-t vesznek, mert azt is szet lehet cseszni konfigokkal.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ez igaz, a greylisting nagyon sokat megfog. Nem tudok most pontos adatokat, de 20- 30%- ot biztosan.

Nemetország szakértelem szempontjából más. Ok, lehet, hogy én vagyok túl maradi, de ők a nagios- t is nagiosadmin- nal konfigolják (pár héttel ezelőttig nem is tudtam, hogy van webes adminja), ha configfájlt kell írni, akkor már sírnak, rínak, tehát ilyen szempontból is érdekes a probléma. Főleg úgy, hogy tudom, hogy csak december végéig leszek itt, és olyan rendszer kell, amit utána a titkárnő is elkattintgat (na jó, ez erős túlzás).

----------

Akinek van 3 perce, toltse ezt ki: http://256.hu/kerdoiv

Mivel a cégnek elég jól megy, és ez a levelezés nagyon meghozza az árát, nem jelentene gondot a mostani szervereken túl hozzácsapni 40- 50E Eurót, de ha nagyon megindokoljuk, nyílván többet is. Nem tudom pontosan ezek milyen szerverek, az se biztos, hogy maradnak. Annyit tudok róluk, hogy most estek át a leselejtezésen ezen a héten, és így nézegetve őket, egyikben sincs 8- nál kevesebb proci (nyílván nem fizikailag), és 3G- nél kevesebb RAM.

----------

Akinek van 3 perce, toltse ezt ki: http://256.hu/kerdoiv

Most egy nagyon vegyes rendszer van, de tényleg. Az egészben van egy db. windows is, bár az nem sokat csinál, de ott van :- ). Először nyílván nagyon jól meg kell tervezni az egészet elejétől a végéig, de mindent részletesen. Olyat is bele kell számolni, hogy idővel a levélforgalom ötszöröse lesz, vagy még nagyobb, tehát könnyen bővíthető legyen, de az sem baj, hogy ha most minden szerver csak 30%- osan van kihasználva.

----------

Akinek van 3 perce, toltse ezt ki: http://256.hu/kerdoiv

( golgota | 2008. 11. 21., p – 21:00 )

Többször el lett mondva, hogy az smtp protocol sajátja, hogy nem nagyon tud levél elveszni benne (csak jó hosszú idő után, miután a másik fél kiüríti a queue-t és nem próbálja meg megint elküldeni.). Ráadásul egy clusteres megoldásnál probléma a queue kezelése (közös queue????).
Smtp szervereket nem nagyon szoktak clusterezni. Van egy backup mx, ami addig fogadja a leveleket, amíg a másik nem áll helyre. Utána vagy átküldi őket a primary-ra, vagy ha közös a tárterület, azaz a felhasználók kézbesítési könyvtára, akkor ő is odateheti a leveleket. Na ebben az értelemben van cluster a mail serveren, mivel a terület valami SAN-on van, vagy NFS-en, stb, stb. De postfix-ből nem csinálunk cluster szervert.
Na már most az egy lehetséges út, hogy van a postfix primary, meg a postfix backup mx elöl. Mögöttük van egy clusterezett content filter (amavisd) két gépen. Itt aztán mehet az LVS és loadbalance. Ezek majd jól visszadobják a spam-et és csak a rendes leveleket küldik vissza a postfix-eknek. Ezek meg aztán csinálnak egy delivery-t a közös tárterületre, vagy valahova máshova. Na ha ez a közös tárterület NFS, akkor azt is lehet clusterezni, de én inkább a SAN híve vagyok. Hozzáteszem, hogy ehhez meg valami GFS vagy cluster filerendszer kell ugye. Na itt van neked a következő cluster. De a postfix még mindíg csak promary+backupmx.
További olvasásra ajánlom a postfix oldalát.
Ja! A felhasználók szempontjából nem az smtp, hanem az imap/pop szerver a legkritikusabb, mert ha azok nem működnek, akkor hiába jönnek a levelek a postfixre és hiába van delivery, attól még a szerencsétlenek nem tudják letölteni a leveleiket. Szóval itt egy újabb lehetőség apache-os webmail clusterre.

De ne legyek kishitű. Lehet azt csinálni, hogy van 7 postfix, de akkor előttük legyen egy hardware-s loadbalancer, valami cisco, vagy más termék. Akkor itt is van a loadbalance meg a cluster, de nem kell nagyon átalakítani a rendszereket. Mondjuk ettől még a közös terület kéne, ahova a 7 szerver a leveleket dobja, hogy ne a 7 szerverről kelljen összevadászni a leveleket a pop/imap szervernek.

"De ne legyek kishitű. Lehet azt csinálni, hogy van 7 postfix, de akkor előttük legyen egy hardware-s loadbalancer, valami cisco, vagy más termék. Akkor itt is van a loadbalance meg a cluster, de nem kell nagyon átalakítani a rendszereket."

Hardware-es load balancer szerintem jelen esetben drága, és felesleges.
DNS-round robin teljesen megfelelő, ráadásul ingyen van, és kb 10 perc konfigurálni.

"Mondjuk ettől még a közös terület kéne, ahova a 7 szerver a leveleket dobja, hogy ne a 7 szerverről kelljen összevadászni a leveleket a pop/imap szervernek."

A 7 szerver egy pop3/imap szervernek tolja tovább az összes bejövőt. Mondjuk úgy, hogy a pop3/imap szerveren figyel egy postfix, ami fogadja a többitől érkező leveleket, és nem csinál semmi extrát.
(Max pl. "vacation" jellegű funkciókat.)

( zwei | 2008. 11. 21., p – 21:02 )

A gond az, hogy szerintem a spam szűrőn, vírus szűrőn, ill smtp szerveren teljesen más terhelést generál a bejövő levélforgalom. Így, ha sorbakötöd őket, a "leggyengébb" láncszem lesz a szűk keresztmetszet.
Ráadásul, mint már korábban is mondták, nem túl hibatűrő a rendszer.

Ha én csinálnám akkor valami ilyen irányban gondolkodnék:

N darab azonosan konfigurált smtp+spamszűrő+vírusszűrő szerver, és mondjuk DNS round-robin módszerrel terheléselosztás.

A mailboxokat lehet külön szerverre rakni, esetleg többre, HA clusterbe, közös SAN/iSCSI/nfs storage-el.

( zwei | 2008. 11. 21., p – 21:32 )

A jelszavaknak biztos lesznek, mert a mostani 7 szerveren 4 fajta titkositas van. Azokat nehez visszafejteni :- ). Pl. ha az ujon md5 lesz a jelszavaknak, akkor az md5- osekkel meg nem lesz gond, de a tobbivel. Nyilvan user oldalon kell megoldani, esetleg egy kis belepteto webes alkalmazas, vagy ra kell kenyszeriteni a usert, hogy 30 napon belul valtoztasson jelszot, kulonben irgumburgum, es az ujonnan valtoztatott jelszavakat mar egysegesen tarolni.

Vagy ez, vagy ha a pop3/imap authentikáló megoldásotok tudja logolni a user jelszavát, akkor az.
Pl. a courier-authdaemon tud jelszót is logolni.

Ha van webmail, és a login scriptet tudod módosítani, akkor oda is beírhatsz egy jelszó eltárolást sikeres auth után.

Nem akarom megserteni a kerdezot, de ezzel a hozzaertessel?

En inkabb ravennem a IMAP/POP cuccot meg a postfixeket, hogy egy darab kozos SQL adatbazisbol authentikaljon. Erre van kismillio-negyszaz-nyolcvanezer howto a neten, egy titkarno be tudja allitani az ilyent.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( hrgy84 | 2008. 11. 22., szo – 07:19 )

Oke, biztos lesz ismetles, de az sosem art.

  • Cluster otletet most dobd ki a kukaba, rajtad ez nem igazan segit
  • Azt mondod, a Spam aranya 50-90%, ez 4M levelre vetitve azt jelenti, hogy max 2M hasznos leveletek van - jobb napokon. Mas napokon meg legfeljebb negyszazezer.
  • Azt kellene igazabol tudni, hogy egyszerre korulbelul mennyi level jon be. Elmondom miert: Ha nagyon sok, erdemes elgondolkodni a loadbalancer-en meg max 3-4 levszerveren mindenkepp, tobbon nem.
  • Ez a rengeteg spam nagyon leterhelo, nem is csodalom, hogy a szervereitek izzadnak. Mindenkepp olvass el jo sok postfix dokumentaciot, hogy megismerkedj a spammerek szivatasanak mikentjevel.
  • Azt hiszem, a feladat-szeparalt szerver a leendo uj felallasban hulyeseg, mivel egy postgrey es megfelelo postfix szabalyok eletbeleptetesevel a spam mennyisege a jelenleginek a toredeke lesz (mondjuk max 20-25%), es nagyjabol hasonlo arany lesz folyamatosan. Mellesleg egy spamfilter nem esik csak ugy ki, es ember nem uzemeltet eles rendszert hidegtartalek nelkul
  • Mindenkeppen alaposabb teljesitmenyfelmeres szukseges a tervezeshez, ennyi informaciora nem lehet ertelmes rendszert tervezni. Ismerni kellene a problemas levelek aranyat, a virusos levelek aranyat, meg ilyenek.
  • Szerintem a 7 SMTP szerverbol legalabb 3 de inkabb 4 biztosan felszabadul. Meg loadbalancing eseten sincs szereny meglatasom szerint szukseg ennel tobb szerverre.

Jelen adatok alapjan ketfele rendszert tudnek megalmodni, az egyikhez nagyon sok hozzaertes kell, a masikhoz kevesebb:

Hozzaertes-needed:
- hardveres load-balancer
- 3 postfix
- 1 filter szerver (postgrey, clamav, spamassassin, ...)
- 1 tartalek filter szerver
- 1 mailbox szerver postfix-szel, amely csak kezbesit (mivel a tobbiek mar akcioztak eleget a levelen)
- 1 SQL szerver authentikaciora.

Hozzaertes-unneeded:
- hardveres load-balancer
- 3 postfix
- 1 mailgw
- 1 tartalek filter szerver - ezt viszont raersz osszerakni
- 1 mailbox szerver postfix-szel, amely csak kezbesit (mivel a tobbiek mar akcioztak eleget a levelen)
- 1 SQL szerver authentikaciora.

A jelszavakkal valoszinu gond lesz, de itt jelenleg tul sokat nem tudsz tenni. En egy drasztikus modszert javaslok: mindenki kap egy automatan generalt jelszot az uj rendszerben, amit koteles megvaltoztatni. Igy az userek maguk fogjak a sajat regi jelszavukat beirni az uj rendszerbe. Ez azert jo, mert igy mindenki eldontheti, hogy akar-e uj jelszot, vagy megtartja a regit.
Amiert eroltetem az SQL authentikaciot, az a postfixadmin. Van user es admin oldali felulete is, sok nyelven elerheto, es a jelszovaltas benne 1 perc.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nekem szimpatikusabb az a fentebb emlitett verzio, hogy pl. 3-4 mx szerveren postfix + clamav + spamassassin (sic!) + okos rbl + a hatso lan-on postgrey egy gepen. Ha csak 1 gepre teszel sa-t, az lesz a szuk keresztmetszet, imho jobb a spam/virusszurest is szetdobni tobb mx-re. Az auth (akar) mehet ugyanazon a gepen is, mint a postgrey, es maradt is egy tartalek geped, amivel/amire menteni tudsz.

SPAMtelenul - POP3 spamszuro szolgaltatas

Azt hiszem, a feladat-szeparalt szerver a leendo uj felallasban hulyeseg, mivel egy postgrey es megfelelo postfix szabalyok eletbeleptetesevel a spam mennyisege a jelenleginek a toredeke lesz (mondjuk max 20-25%), es nagyjabol hasonlo arany lesz folyamatosan.

Kiváncsi vagyok azokra a "megfelelő postfix szabályokra" amikkel eldöntöd, hogy mi spam és nem spam