Nagy felhasználószámú levelező szerver tervezése, gyakorlati tapasztalatok

Linux-haladó

Üdv!

Az elmúlt pár napban rengeteg doksit olvastam el levelezőszerverekről, de sehol nem találtam semmi arra utalót, hogy kell megtervezni, és mit kell figyelembe venni több 10.000 vagy 100.000 felhasználós linux szervereknél. Egy szerver kb. hány felhasználót tud biztonságosan kiszolgálni, illetve milyen fájlrendszert ajánlott használni több millió vagy tízmillió fájl tárolására. Melyik az a felhasználószám, ahol már fürtözni kell a tárolószervert és ezt hogyan kell megvalósítani.
Amire jutottam, hogy postfixet vagy esetleg eximet ajánlott mtaként használni, és cyrust, dovecotot esetleg couriert kiszolgálóként. A felhasználókat pedig ldapban vagy adatbázisban tárolni. Én az ext3-at tartom a legalkalmasabbnak a feladatra, a támogatottsága és stabilitása miatt, vagy az xfs-t a sebessége miatt.

Elsősorban olyanok tapasztalatára lennék kíváncsi, akik jelenleg is üzemeltetnek 1000 felhasználó feletti szervereket, évi 1.000.000 levél feletti forgalommal.

Update:

Mivel a konkrét esetben a felhasználószám, ami miatt ilyesmin elgondolkodtam, és utánaolvastam, az itt feltüntetett felhasználószám töredéke, ezért nem írtam pontosabb adatokat.
Egy átlagos, céges környezetben használt rendszer 80%-ban imapot, 20%-ban (a tudatlan felhasználók miatt) pop3-at használ. 10.000 felhasználó esetén, évi kb. 10.000.000 levél forgalom a reális, ez napi 20.000-30.000 levél.
Anyagilag én kb. 1.000.000 ft. költséggel, simán kivitelezhetőnek tartom a hw-t.

  • 4560 megtekintés

( Jason v | 2009. 11. 15., v – 18:15 )

subscribe

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

( janoszen v | 2009. 11. 15., v – 18:21 )

Ami igazából sarkallatos pont, azok maguk a maildirek. Eleve nem valószínű, hogy valamennyi felhasználód valamennyi levele el fog férni egy gépen. Innentől kezdve csak az olyan megoldások játszanak, amik ezt meg tudják oldani (az NFSen keresztüli mailstore nem jó, az iSCSI/SAN esetleg). Ezek közül vagy Cyrus IMAP vagy Dovecot. Az utóbbi szabvány Maildir++ formában tárolja a leveleket és az 1.2-es verzió óta rendesen működik a kvóta kezelése olyan formában is, hogy adatbázisból olvassa, fájlba írja a kvótát. Ha MTA, akkor valószínűleg Eximmel jobban jársz, az jobban konfigurálható. Esetleg írhatsz magadnak, ha sok időd van.

A Postfixnál azért van egy-két dolog, amit nem tudsz triviálisan megcsinálni. Például hogy oldanád meg azt, hogy az egyik domainről érkező autentikált levelek egy másik relayre menjenek, mint a többi, mellette BCC-zve legyenek egy harmadik szerverre és mellette még fogadjon nem autentikált leveleket a szerver. Meg lehet oldani, de nem triviális. A legtöbb feladatra úgyis saját policy daemont kell írni vagy több SMTP daemont kell föllőni különböző konfiggal.

NFS-en Maildir sem jo megoldas?

Ugy remlik az a Maildir egyik elonye, hogy mukodik NFS-en is.

Szerintem van olyan IMAP proxy is van, ami felhasznalonev alapjan is tudja osztani a bejovo kapcsolatokat, mondjuk en valoszinuleg nem igy csinalnam, de hatha a kerdezonek jol jon az ottlet.

Komoly terhelessel nem hasznaltam NFS-t, nekem azert fura, hogy pl egy iSCSI szerinted jobb.

Arra ugye akkor mar vmi cluster fs kellene, ha tobb SMTP/IMAP/POP frontend van, az meg erzesre nem lesz gyorsabb mint egy NFS storage.

Persze az en erzeseim ellenere siman igazad lehet, sot.

NFS-en en valami redundans storage-et ertettem, annak azert nem illene beallni.

Mondjuk az eredeti kerdesben nem reszletezte a kerdezo, hogy milyen egyeb peremfeltetelek vannak (penz, rendelkezesre allas, stb.).

Nem tudom, mennyire jó az iSCSI, de az NFSnél rosszabb nem lehet. A cluster FS meg jó ha van, de még jobb, ha nincs. Csak úgy éri meg ezt csinálni, hogy ha van egy szép nagy gépet, ami sok-sok CPUval és RAMmal bír (x86 kizárva) és az kezeli az egész kócerájt.

Az NFS meg annyira király, hogy ha a mögötte levő disk csuklik egyet az egyik gépben, akkor beáll az egész cluster. Ha soft módban mountolod, akkor meg elcrashel az alkalmazás mert olyan pontokon fog hibákat kapni, ahol egy normál filerendszertől nem. Lehet választani.

NFS-nel latency van, mint mindennel ami networkon keresztul megy. Volt olyan, hogy NFS -en vagy CIFS -en keresztuli muveletet tobb szalon vegeztem, mert a latency per muveletre vonatkozik es tobb mehet parhuzamosan siman, ha nem utkozik fs lock -ba, de az van lokalisan is.
Ujabb Linux kerneleknel az NFS eleg szepen cachelheto.
iSCSI -nel megvan ugyan ez a latency, csak ott blokkokat tudsz cachelni. Egy blokk cachelesekor eselyes, hogy olyan infohoz is huzajutsz amit egy kesobbi keresed igenyelne FS szinten. En teljesen random hozzaferesnel az NFS -re fogadnek.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( bambano | 2009. 11. 15., v – 20:48 )

ez még egy kicsit nyitott kérdés, mert nem tudjuk, hogy lesz 100 ezer usered, akik este hazamennek, letöltik az emailjüket a városi kábeltv-s neten oszt csók anyu, vagy egy nagyvállalatban ülnek, akik folyamatosan pofozzák jobbról-balról a levelesládájukat, a naptárjukat meg a többit.

A mai vasakon meg moderált felhasználást elképzelve túl sok minden tervezni való nincs, nagyjából bármi elbír 10 ezer postafiókot.

Majd leteszteli jól élesben, és jön sírni, hogy hajjajj nem bírja a pista bt. core2duo server :)
Aztán ha valaki azt mondja h. figy, volt ez a topik, mondták h. SAN + clusterfs + több frontend, akkor mi leszünk a köcsögök :)

Viccet félretéve, a kollégának teljesen igaza van. A pop3 korszak már véget ért. Jobbára IMAP, MAPI korszak van, ami azért elég jelentős terhelést tud generálni. Szóval a topikindító által vázolt dolog jelentősen függ a felhasználóktól is. De mindannyian tudjuk, hogy a webmail is imap. Én mindenképpen a több frontendes shared storage-en csücsülős, cluster filerendszeres megoldást tudom ide elképzelni jó megoldásként, pláne ha még valami jóféle spamszűrést is akarunk bele.

Tudom, hogy sokan használnak, de azt gondolom, hogy a normálisabb webes cuccok is imappal csatlakoznak a local szerverhez (pop3-hoz ott az Iloha a roundcube anyja). Nálam 20 mail user van 1-4 gigabyte postafiókkal. Nem egy "gyorsvonat" a levelek közti turkálás nem helyi hálóról, hanem valahonnan mondjuk 3G, nem webesen, hanem kliensről.

RoundCube ebben jó fej, mert aktívan sql-ezik így amiket megnéztél azokat legközelebb sql-ből tolja eléd.

Nem a webes cuccal van a gond, hanem a juzerekkel sokszor. Teljes POP3 mánia van, mert anno ez volt a default mindenhol. Azóta "POP3 ugye van?" az első kérdés. Alig néhányukat sikerült rábeszélnem, hogy ha imapozik többszörösen jár jól, mert pl. a webmail is imapos, tehát teljesen szinkronja lesz a mindenféle kliensekkel. A fiókméret teljesen hektikusan a néhány kbájttól (pop3 ugye) a 2-3GB-ig simán megy itt. :)

mert nem fogja erteni, hogy ha cegnel belep, akkor fennmaradna ka levelei, de ha otthon, akkor meg csak ott lesznek.
mire elmagyarazod, hogy otthon pop3-azik, ami nem ugyanaz mint az imap, addigra ketszer megszulsz, meg ha fiu is vagy.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Ezt szerintem az ittlevők nagy százaléka tudja, de ha beszólsz a juzernek hogy akkor NE a pop3-mat válassza, hanem az imapot két dolog történik:

- Pánikba esik, de ez még elmúlik, de elég kis eséllyel lesz körülötte olyan, aki újra így fogja beállítani ha összefossa magát a windozere és itt jön a pánik, főleg ha folderei is voltak, hogy jajj eltűntek a levelei, a leveleit meg törölte a POP3 ahogy kell.

- A büdös életben nem fog egyetlen levelet sem törölni/archiválni ezért a világ összes diszkjét alá kell majd tenni és lassú is lesz a maildir elérése (ugye itt a körbeküldözgetett sokMB-os PPT-k és tsaikról van szó), ennek pedig azaz oka, hogy POP3 juzer volt és abban a hitben van hogy amit megnézett azt letöltötte.

A POP3 mániát valszin pont az indította el, hogy anno 10-20-50MB-os fiókot adtak az ISP-k és tényleg pop3-ommal kellett szedegetni a maileket hogy ne teljen meg.

"Nem egy "gyorsvonat" a levelek közti turkálás nem helyi hálóról, hanem valahonnan mondjuk 3G, nem webesen, hanem kliensről."
mégis, mitől lenne gyorsvonat? van 3g (vagy akármilyen) netelérés gigabit sebességgel? ilyen szempontból tökmindegy, hogy pop3 vagy imap, meg hogy sql vagy nemsql. a leveleket akkor is le kell töltened a kliens gépre, a lassú neten keresztül.
sőt, ilyen szempontból még jobb is lehet a pop3, amennyiben letöltöd _egyszer_ a leveleidet a gépre és ott már gyorsvonat. az imapnál meg n+1-szer töltöd le, ahányszor megnézed.
meg azért megnéznék egy statisztikát, hogy valóban leáldozott-e a pop3 kora, mert én pl. kétféle usert ismerek: az egyik pop3-at használ, a másik webmailt. olyat egyet sem, aki konkrétan mondjuk egy kliensen imapozik. még ha a webmailt imapnak számolom, akkor is én szerintem legalább 50% még a pop3 aránya. (szigorúan csak saját mintás adatból becsülve)

----------------------------------
feel the beat - it's everywhere!

A hálózati forgalommal nincs gond. Nem töltögeti le senki folyamatosan a teljes mailboxát, és elég sok konkurens user kell, hogy agyonverjenek akár egy 100Mbit-es linket.

A gond ott van, amikor sok kliens keresgél maildirben - esetleg a teljes levéltörzsben szöveget.
Ez rendesen oda tud tenni a diszkeknek (sok olvasás kis blokkmérettel).
Sokuseres Imap esetén nagyon ajánlott a sokdiszkes raid.

Hat, engedtessek meg a ketkedes joga. Nalunk nem kell keresgeles ahhoz, hogy megfekudjon a mail szerver. Van egy kozos postalada az ugyfelszolinak, amit 3-4 gep is cseszeget, es idonkent egyszeruen megfekszik a gep alatta, pedig semmi extra felhasznalas nincs, csak eppen bezudult 80-90 level, es azt 3-4 gep toltene lefele. Persze ez meg siman lehet a Courier hibaja is...
-- 


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

Szerintem a kulcs inkabb az lehet, hogy 1 postafiokhoz fernek hozza emberek random. Es gondolom nem az INBOX-ot bamuljak meredten hogy mikor jon mar level, hanem mappaznak, keresgelnek, olvasgatnak... Igy mar valszinuleg arnyaltabb a kep.
-- 


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

Nálunk is van közös fiók. Sok központi mail van ami ide jön különböző mail címnek, amit procmail válogat szét almappákba. (megjegyzem, hogy ezt javaslom minden cégnek, mert nagy multiknál is van az az extragáz, hogy szabin van az illető és nem olvassa a mail-t/rendelést).

Nem volt még belőle gond, mi 6-an nézzük pedig folyamatosan.

Igen, csak itt megint kepbe jon az, hogy alapvetoen r=1 userekrol beszelunk, ha a levkliensben 1-nel tobb opciot kell maskepp beallitani, mar kulon user manager embert kell felvenni, aki kimegy, es atboki.
-- 


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

( andrej_ v | 2009. 11. 15., v – 22:29 )

Egy 2 socketes mai quadcore xeon mondjuk RAID 1+0-val vagy egy hardware-es RAID5-el baromi mennyiségű fiókot és emailt tud elvinni. Persze ahogy már írták oltári módon függ a felhasználási módtól. A mindenki webmailezik és mp-enként 10 levelet küld/fogad vs. mindenki két hetente egyszer két levelet leszed POP3-al. :)

( mauzi v | 2009. 11. 15., v – 22:41 )

üzemeltetünk ilyet...

a frontend nem különösebben nagy történet. mi postfixet és courier-t használunk (LDAP illetőleg MySQL backenddel), a CPU igény a mai dualcore/quadcore világban gyakorlatilag semmiség, a konkurrens kapcsolatok számának megfelelően egyedül a memóriára kell odafigyelni, de a mai alaplapokba könnyedén lehet sok gigát pakolni, ha pedig minden kötél szakad, melléteszel mégegy frontendet, mégegyszer annyi RAM-mal.

backenden oprendszertől függően UFS (FFS) illetve ext3 szokott lenni. a diszk (főleg a sok seek-elés miatt) szokott szűk keresztmetszet lenni, RAID1+0 szinte kötelező.

mi nyúzzuk az NFSv3-at rendesen, nem szokott akadékoskodni. (újabb vasakon inkább iSCSI szokott játszani)

( 3xtati | 2009. 11. 16., h – 08:28 )

subscribe

____________________
Ha igen akkor miért nem...
Linux 2.6.30-gentoo-r4 i686 Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz GenuineIntel GNU/Linux

( elod v | 2009. 11. 16., h – 09:33 )

EXT3-at Maildirrel felejtsd el (fsck egy óra körül van jelenleg, resize után mintha megállna 5 percre minden). 100GB felett nekem már teljesen használhatatlan. Most migrálok XFS-re. Relatív kicsi szerver (1000 felhasználó körül).

Kicsit megkesve, de egyszeruen nincs idom mindent elolvasni: nalunk sok szopas volt vele. A kvotat kinlodas aran lehet csak beallitani (a sima quota undorodva loki el magatol, a xfs sajat quota rendszere pedig tobb leiras kovetesevel sem mukodott, maga a management util dobal rejtelyes hibakat). Raadasul a fajlbiztonsaga meg mindig messze nem olyan jo, mint a tobbi linuxos fajlrendszereknek.
-- 


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

Valamit biztos elrontok, hogy kb. 5 év alatt sehogy se sikerült összedöntenem xfs-t. Pedig mindent azon viszek.

1 dologtól áll meg (!= összedől)
ha megtelik. Olyankor azt mondja, van még 20k free. Majd elkezd 100%-on pörögni a CPU, és ameddig nem csinálok szabad helyet, addig pörög. Utána megy tovább.

Sőtt ~130-150 user, összesen ~70-80GB-nyi mailbox, cyrus, xfs nfs-en exportálva a cyrus alá, és atomstabil.

( maniac | 2009. 11. 16., h – 15:35 )

Szerintem postfix-szel nem lesz gond. Tarolni a leveleket mar kicsit erdekesebb, de miert nem ajanlotta meg senki azt, hogy maildir helyett sql-ben taroljuk a leveleket?

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

Amennyire tudom, a levelek adatbázisban való tárolásával azért hagytak fel, mivel a jelenlegi HDD-k elérési ideje, és a fájlrendszerek megbízhatósága illetve beépített indexelési szolgáltatása elég gyorssá tette őket, hogy elérjék az adatbázisok sebességét, amennyiben levelek tárolásáról van szó. Ezen kívül szerintem ha recovery-ra kerülne a sor, akkor mindenképp előnyösebb fájlrendszerről visszahozni az adatokat, mint egy adatbázisfájlból.

"Ezen kívül szerintem ha recovery-ra kerülne a sor, akkor mindenképp előnyösebb fájlrendszerről visszahozni az adatokat, mint egy adatbázisfájlból."

Pont fordítva. :)
Egy pár nagy fájlból álló adatbázist nagyságrendekkel gyorsabban vissza lehet tölteni, mint pár millió kis fájlt...

"mi van akkor, ha 20 kisebb file serul meg"

Nagyon beszoptad. Honnan tudod, hogy melyik 20 kisebb fájl sérül meg? Sehogy. Ha törlődik a fájlrendszerből, esélytelen vagy.

Adatbázisnál szól, hogy melyik az inkonzisztens fájl.

Egyébként meg sokkal gyorsabb mentésből visszahúzni egy pár gigás fájlt, mint 2 millió fájl közül 20 3k-sat.

Majdnem erre gondoltam. Amirol azonban en beszeltem az az, hogy worst case elveszett osszesen 20 level vs. elveszett az sql mentes ota az osszes leveled... Es akkor gavaller voltam, es azt is felteteleztuk, hogy az adatbazis nem all fejre, es nem kuszalodik ossze...

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

"elveszett az sql mentes ota az osszes leveled..."
vs. elveszett a fájlrendszer mentés óta az összes leveled.
Most akkor melyik is a jobb?
(Ki mondta, hogy adatbázist nem lehet inkrementálisan menteni? Még gyorsabb is mint 2-3 millió fájl inkrementális mentése.)

Egyébként a "worst case elveszett osszesen 20 level" -ben a legrosszabb az, hogy NEM tudhatod, hogy ténylegesen mennyi veszett el. Viszont ha az adatbázis konzisztens akkor biztos lehetsz benne, hogy minden levél megvan.

Egy apro dolgot nem vagok: ha az fs teljesen megadja magat [hogy lehet ujra formazni/mkfs.*/...] (gondolom, ezt jelenti az fs mentes utani osszes level elvesztese), akkor hogy marad meg rajta az sql par darab, de sok gigas file-ja? Mert olyat mar lattam, hogy az fsck par arva node-ot kinyirt (ok, teljesen igaz, hogy nem tudhatom, melyik level lesz erintett), de ha az sql recovery nem sikerul valamiert, akkor (imho) tobb level lesz erintve, es valoszinuleg szinten nem tudjuk, hogy melyek... (ok, a maillog-gal ossze lehet vetni, de a banatos kuncsaftot ez kevesse vigasztalja)

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

mindegy, asszem értem mire céloztál.
Arra, hogy ha korrupt a fájlrendszered, akkor max egy pár levél veszik el maildirből, és nem kell a teljes mentést visszatölteni, amíg adatbázis esetén ez az egy megoldás van.

Ezzel továbbra is az a baj, hogy valójában nem tudhatod, hogy mennyi leveled veszett el ténylegesen. (Mondjuk igazából adatbázis esetén sem tudod)

Igazából sok értelme nincs ilyen alapon összehasonlítani a két megoldást. Amiben egyértelmű a különbség, az az, hogy egy adatbázisnak gyorsabb a teljes mentése, és gyorsabb a teljes visszaállítása.
Ráadásul viszonylag egyszerűbb elosztott rendszerként üzemeltetni, valamint megfelelő indexeléssel gyorsabb egy teljes levéltörzs alapú keresés.

A fájlrendszer előnye az egyszerűbb adminisztrálhatóság, a kisebb erőforrás igény, valamint az , hogy minden lda (local delivery agent) támogat valamilyen file rendszer alapú tárolót (maildir, vagy mbox).
Ez utóbbi a legfontosabb, mert egy váltásnál nem kell sokat migrálni.

Nem volt ez verseny.

Személy szerint teljesen szubjektív okok miatt utálom nem szeretem az adatbázis backend mail szervereket. (Nem vagyok profi dba - egy file rendszer alapút jobban kézben tudok tartani.)
De ettől még teljesen jó egy adatbázis alapú mail szerver.

Az opensource világban de facto a file rendszer alapú mail-store megoldások terjedtek el.
Talán azért, mert a maildir és a mailbox fájlrendszertől független, rém egyszerű implementálni. Ezzel szemben egy adatbázis már erősen db motor függő, és kevésbé triviális jól összerakni.

A zárt forráskódban egyébként sok mailszerver használ adabázist (vagy ahoz hasonló képződményt)- pl. Exchange, oracle emailserver, stb.

Szolgáltatás szempontjából szerintem jóval többet tudnak az adatbázis alapúak.

Vegigolvastam nagyjabol a trhead-et es alapvetoen nem ertem, hogy jott a kepbe a db storage alapu mail szerver.

A topicnyito 100k userrol beszelt. Ekkora meretu adatbazist egyszeruen keptelenseg lenne uzemeltetni gyakorlati es anyagi szinten is. Lehet az xch, dbmail, vagy oraclemail(?) errol meg nem is hallottam.

Gyorsan megneztem, a Release overview 2005. A meretbeli korlatokrol nem lattam informaciot a Datasheetben es a Technical whitepaper-ben sem.

Mindenezeztul feltetelezhetoen nem olyan emberre akarjak bizni a 100K-s usert alkalmazo vallalat levelezeset, akinek ilyen alap dolgokban hup forumos informaciokra van szuksege.
Tehat maradt a free mail szolgaltatas........... Kozben megneztem a topicnyito hozzaszolasait, es nekem ugy tunik, az a 100k user max. 1k lehet vagy ilyesmi.

tompos

Igazad van, jelen konkrét esetben tényleg min. 1000 max. 5000 userről van szó, viszont a topikot sem csak azért indítottam, hogy egy ilyen kisebb szervert belőjek, hanem azért mert érdekel, hogy megy ez jelentős számú, akár 100000 vagy több felhasználó esetén. Magát az architektúrát el tudom képzelni, ami szerintem a legnagyobb probléma lehet ilyen nagy felhasználószámnál, a háttértároló megoldása. Arra vagyok még mindig kíváncsi, hogy ezt miként lehet megoldani, hogy elég gyors és biztonságos legyen.
Ami még felmerül ilyen esetben, a kiszolgálószerver terheléselosztása, mert feltételezem ennyi felhasználót egy szerver már elég nehezen szolgál ki.

"Vegigolvastam nagyjabol a trhead-et es alapvetoen nem ertem, hogy jott a kepbe a db storage alapu mail szerver."

A db alapú mail szerver támája átment elméleti síkra.
Az eszmefuttatás arról szólt, hogy miért jó/nemjó egy ilyen - a jelenlegi topictól kicsit elszakadva.

Egyébként oracle mail szerver létezik, csak az oracle baromira nem tudja sehova eladni. Egyébként felhasználóként nekem is volt hozzá szerencsém.

100k user esetén átlag 500Mb mailboxal 50T diszk. Ezt egy szerverrel nem tudod kiszolgálni akár db. akár maildir. Ha meg elosztott rendszer, akkor az adatbázis miért ne lehetne jó? Nem itt szokta mindenki orrba-szájba hangoztatni, hogy párhuzamos adatbázis rendszerek a jövő, és kukába minden nagy vassal? :)

Ismétlem, a db. alapú mailstore-ról csak elméleti társalgás folyt.

( _ventura_ v | 2009. 11. 16., h – 18:17 )

szia !

Nálunk kb 1500 domain és 8000 user van a levelezo szerveren. Amióta cseréltük a vasat semmi gond nincsen a terheléssel.
Napi kb 40e levél jövet menet. Természetesen használunk RBL listát is mert anélkül többszöröse lenne a forgalom és a vírusirtás is. Posftix üzemel + clamav,amavis,spamassassing,dcc,pyzor,razor stb, ext3 és maildir van. A gép dual quad core 6G ram 4x250G vincsi raid5 ben, fuji-siemens rx300s3 as vas, jelenleg debian 4.0 val. Szóval 1 milkából bőven lehet építeni :>

Core2Duo T7100, 4G, Ubuntu 9.10, 2.6.31

Ennemertekhozzakeremszepen. Tenyleg nem, csak felvetettem egy gondolatot, hogy mi a rak van, ha az az egy gep kihal. Mindenkeppen huzos ido ujra elinditani a szolgaltatast.. Meg backupbol is komoly ido visszaallni (najo, backup tipusatol fugg).

Akkor addig áll a levelezés míg másik vas be nem áll. Napi szintű backup, ráadásul az fs online megtalálható másik szerveren is :> Lehetne HA is de eddigi tapasztalataink a BRAND szerverekkel nagyon jók, tulajképpen az évek alatt vincsihaláltól eltekintve semmilyen gond nem volt velük. Így nem látjuk értelmét még 1 gép fölösleges müködtetésének éveken át, Inkább fél - 1 óra kiesés :>

Core2Duo T7100, 4G, Ubuntu 9.10, 2.6.31

Nálunk a cégnél pénteken ment ki egy Dell PowerEdge 2950 II-es szerver, úgy tűnik az alaplapja. Szinte 3 éve működik folyamatosan, vmware esxi volt rajta, nem volt örömteli pillanat, amikor mind a 10-15 rajta futó szolgáltatást át kellett tenni más vasakra. Evvel együtt én sem nagyon látom értelmét egy másik gép párhuzamos futtatásának, csak azért, hogy ha ez elromlik, akkor ne legyen nagy kiesés. Ha jól van megszervezve a backup, és esxi esetén van elég sűrű tükörmásolat, akkor 1-2 óra kiesés az esetek nagy részében belefér.

A teljes mondat: Általában az ésszel élő vezetők is belátják, hogy egy totálisan lehaló szerver az előfordulhat és nem napi probléma.

Tehát mivel elromlásra hajlamos eszközről van szó, ezért számolni kell azzal hogy előfordulhat ilyen. Ez cégfüggő, hogy belefér-e 1-2 óra állás mondjuk évente vagy pedig mindent 23982398x-esen bebiztosítanak és persze jó drágán.

( andrej_ v | 2009. 11. 16., h – 22:10 )

Picit gondolkodtam, meg a topikot olvasva én így csinálnám:

1. gép MTA frontend:
- minden bejövő SMTP forgalom ide érkezik alapértelmezésben
- rbl-ek és egyéb rule-ok nézegetése
- spam és vírus kergetés

2- gép IMAP/POP szerver
- az SMTP frontend a maradék emailt átpasszolja ide és ha vannak lokális peruser szabályok azok értelem szerűen itt kerülnek alkalmazásra
- meglepően IMAP és POP3 kiszolgálás
- szinten meglepően webmail (kimenő smtp az mta frontend felé)

Amiért két egyszerűbb és tökegyforma vasat vennék az az egyszerű ok, hogy lehetnek egymás backupjai is. Igaz hogy ha kidől az egyik akkor lassabban, de mégiscsak elérhető lenne a szolgáltatás. A hátránya, hogy emiatt egy picit felül kell méretezni a gépeket CPU és diszk IO téren. Ha postfix akkor always_bcc-vel az mta frontend helyi backupba is betenném, majd adott időnként rsyncelnék visszafelé az IMAP szerverről.

Természetesen a harmadik gépre menő backupot nem szabad kihagyni, de ekkora méretnél az jó eséllyel már rendelkezésre áll.

Kb. ilyesmi az amit jelenleg is használunk a cégnél, csak a topikban írtaknál jóval kisebb forgalmú, és hasonló struktúrára gondoltam a jövőben bevezetendő helyszínen is. Ott két egyenként 4 magos, 12-12 gb memóriás gépen vmware esxi alatt futna a szerver, az egyiken több szolgáltatás és az smtp szűrő, ami egyben backupja is a főszervernek, és a másikon a tároló és kiszolgálószerver. A HDD-k esetén mindkét szerveren raid5-öt gondoltam a legjobb megoldásnak. És természetesen a háttérben még egy külső backup is működne. A fentebb írtak alapján ez kb. 10000-20000 felhasználót jól ki tud szolgálni.

Akkor mi a kérdés? :) A RAID5-nél a RAID1+0 nem lesz feltétlen gyorsabb csak sok diszkkel, tehát mondjuk 3db RAID1-es kötsz RAID0-ba. A memóriát elég nehéz levelező kitölteni, a konkurrens feldolgozásra inkább költsetek szerintem. Ha kisebb órajellel is, de a 8 core igencsak jól jöhet.

Azert lehet ezen egy kicsit tuningolni. Evi 10M level az nudli. Az always_bcc is eleg nyers mentesre, foleg ha ebben a spamek is benne vannak (az 1. gep alapjan ugy latom, igen), ill. egy (=1) gep SMTP szervernek?

Akkor mar inkabb:

2 olcso gepen SMTP funkcio (tetszoleges* spam+antivirus) komboval

2 igenyesebb vas mail (=pop3/imap/...) szerver celra, az egyik standby modban figyel, es kozottuk szinkronizaljuk a leveleket. Ja, es igy az "aktualis" allapotrol mentesunk is van mar. Ja, es egy ugyes mentes a spamkent felismert leveleket nem teszi el sok napra visszamenoleg...

*: de ha lehet, akkor ne SA vagy feketelista

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

A mail mentes erdekes dolog. Lehet vitatkozni azon, hogy van-e ertelme menteni a fel evvel korabban letorolt leveleket... Van olyan vallalat, ahol evekre visszamenoleg archivaljak (figyeled, meg a szo is mas), de olyan kornyezet is van, ahol nem. A topiknyito ezt a reszet szemermesen elhallgatta.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Az always_bcc kiváló archiválni és menteni is, csak ügyesen kell csinálni. Egyébként van értelme menteni, mert úgyis töröl véletlenül a t. felhasználó és akkor jajjde ASAP, meg mindenhogy kell neki. Persze ettől kényelmesek is lesznek.

A céges mailek archiválása pedig relatív olcsón megoldható, de ha nincs és esetleg kell az roppant sokba tud kerülni.

Fölösleges a két smtp szerver, meg imho és fölösleges hw és sw buzerát nyersz vele. A topiknyitásban pedug a 1m hufos kiviteli bugdetbe próbáltam beférni saccra, amit viszont egy "igényesebb vas" is lazán átvihet, de minimum megközelíti annyira, hogy max kamilla teára maradjon a keretben.

De ha már több SMTP, akkor a travlanak van olyan 1U-s háza, ami két mini-ITX board megy. Noh innentől meg el lehet szabadulni bőszen. :) Tudom ez sufni meg jajj, de ha mondjuk 6 MX-ből kiesik egy és táphiba miatt meg kettő, az elég pici vagy legalábbis bőven elviselhető fejfájást okoz.

Az always_bcc a maradékot bcc-zi, ami átjut, legalábbis ez a tapasztalat.

Fölösleges a két smtp szerver

Te mekkora (level/nap ill. userek szama) levelezest uzemeltetsz (1 mx-szel)?

fölösleges hw és sw buzerát nyersz vele.

Ugy erted, n db kommersz klonozhato (konfiguracioju) pc-vel? Evi 10M levelet a desktop PC-men (mint MX) ki tudnek szolgalni (spam+virusszuressel egyutt), ugyhogy aligha ez vinne el a budzset...

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

1000-1200 köröli postafiókszám és 800 domain van. (Most pontos számot nem néztem, a juzerek tudják nyomkodni a fiókjaikat ideoda.) Naponta sokezer email megy, ha jól számoltam saccra 15-20e email jön-megy és spam+vírust is szűrünk.

Persze desktop PC-vel mindent lehet, csak nem biztos hogy akarnék olyat. :) Ha már igen, akkor lásd a travla házas dualminiITX-es ötletet.

( subchee | 2009. 11. 17., k – 12:33 )

subchee... (vö. Timiiii) izé, a szábszkrájpot úgysem tudom leírni helyesen :)

Én megmondtam, hogy megmondtam.. hát nem megmondtam, na? :)
Szóval izé, nem tudom hogyan rendeljek billentyűkombináció FF helyesírás-ellenőrzőjéhez, hogy gyorsan tudjak HU<->EN között váltani, ha valamiben nagyon vagyok biztos.

Amúgy meg ha beszédhibás vagyok és csak ,,p'' -vel tudom kiejteni ,,b'' helyett? Akkor fonetikusan leírva a beszédbéli feltételezett fogyatékosságomat kiröhögni nem szép dolog :P