On 15:58, Catalin Muresan wrote: > Salut, > > On 11/27/06, Marius Stan <[EMAIL PROTECTED]> wrote: > >Salut, > > > >Am nevoie sa construiesc un MX pt un numar destul de mare de useri, > >~150.000; normal ar fi sa mentionez traficul pe care ma astept sa-l > >faca, dar nu il stiu. Vad 2 solutii pina acum: > >1. Server standalone: nu stiu cit hardware trebuie pentru a suporta > >cerintele vagi de mai sus. nu scaleaza. > >2. (pe care o prefer) Un cluster facut cu servere entry-level (am la > >dispozitie pina la 8 masini) > > > >Si aici ma invirt in jurul cozii: nu gasesc deloc un paper cu HA/LB > >email server. > >Pentru partea de load balacing m-am oprit asupra lui Ultra Monkey [ > >http://www.ultramonkey.org/ ] > >Cu asta sper ca voi reusi sa distribui cererile SMTP/POP3 pe mai multe > > LVS, DNS LB, sunt solutii mai multe. > > >masini. Urmeaza partea specifica: > >Sa folosesc un filesystem shared (nfs/coda) pt stocare de emailuri ? > > eu personal nu am testat in ultima vreme asa ceva, singura problema > care o vad e ca serverul NFS o sa fie single-point-of-failure. Sunt si > solutii la asta, cluster NFS dar ajungi la shared storage care e ori > FC/SAN ori poor-man's GNBD care _iar_ e doar cu un server.
NFS+DRBD+HB (caps disclaimer - sunt acronime) scoate S-ul din SPOF IMHO La 150k clienti poti sa-ti permiti totusi un SAN care sa exporte o interfata bestioasa . Mai ales daca bishnitza se invarte la setupul asta de MX-uri. > > >In caz ca da, lucrurile devin oarecum triviale (cu ceva probleme totusi, > >de ex indecsi in dovecot). Voi fi penalizat la performanta prin > >folosirea nfs ? > > iti recomand un FS cu shared storage, costa mai mult hardware-ul dar e > cel mai performant. > Oricum nimeni nu-ti poate propune o solutie daca nu incepi de la un > buget. Poti sa pui 30kEUR stoage-ul FC (scalabil, > no-single-point-of-failure), 5k placile FC, 10k 2 sw FC. > > Orice ai face intre 0.33 si 1 EUR/client ajungi sa cheltuiesti. > > >Sau sa gasesc o solutie de a distribui userii pe mai multe masini (de ex > >A-Fpe o masina, G-L pe alta etc) ? Asta implica logica suplimentara, > >pentru a ma asigura ca fiecare aterizeaza pe serverul destinat lui. In > >acest caz nu mai am nevoie de Ultra Monkey, lucrurile se pot face cu > >reverse proxies. > > dovecot, perdition suporta asa ceva, dar te intorci la problema ca iar > ai single-point-of-failure. > daca pica masina cu G-L ce faci? > > > > >Ceva amendamente sau idei ? > > structura e simpla: > - 2-3 MX-uri care fac antivirus, antispam, trebuie disk-uri cit de cit > sau ramdisk ca sa tina fisierele temporare care le fac diferitele > scannere/antispam-uri. MX-urile trimit mailurile (postfix - transport, > etc) la storage-uri > - 2 storage-uri (pentru redundanta), CPU load e mic, IO wait poate sa > fie mare. pe storage-uri ai POP/IMAP servers. > - inca 2 outgoing mail servers, separat de storage/incoming, prin care > clientii trimit mailuri, cu antivirus, antispam optional. la fel ca > MX-urile, cu disk rapid sau ramdisk pentru queue. Astea 2 le poti > comasa cu MX-urile, dar e mai bine sa fie separate. > > http://sources.redhat.com/cluster/ > > > > > >Multumesc, > >Marius > > spor. Poate cel mai bine ar fi, dupa ce ai citit tot, sa revii de la > inceput si sa pui pe hartie ce anume vrei de la solutie: redundanta, > capacitate, extensibilitate, flexibilitate, cost, tot detaliat. De > acolo poti incepe, solutii sunt gramada, conteaza mult bugetul. > > > > > > >_______________________________________________ > >RLUG mailing list > >RLUG@lists.lug.ro > >http://lists.lug.ro/mailman/listinfo/rlug > > > > _______________________________________________ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug -- + Lorin + BOFH excuse #301: appears to be a Slow/Narrow SCSI-0 Interface problem _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
