Newsgroup: it.comp.os.linux.sys
Titolo: Proxy IMAP

Nell'ottica di fare load-balancing IMAP, stavo pensando di utilizzare nginx 
come proxy... qualcuno ha esperienze? Altri suggerimenti? Come fate il load 
balancing e la alta disponibilità di caselle di posta?
-- 
Vide



perdition
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?


Perdition per la parte imap/pop over ssl
Ma da quando ho implementato un proxy smtps con delegate, ho deciso di
utilizzare sempre quello. su bsd però.
Attenzione però, delegate è letteralmente mostruoso, in tutto e per
tutto.
http://www.delegate.org

 
Non è proprio un load balancing, ma è molto semplice. Assegno più Ip 
allo stesso nome DNS e dissemino gli IP su più server, a coppie gestiti 
con heartbeat. Naturalmente il filesystem è condiviso tra le macchine.
Leandro

 perdition
Grazie per la dritta, me lo studio con attenzione (da una prima letta sembra 
effettivamente quello che cerco)
-- 
Vide

 con heartbeat. Naturalmente il filesystem è condiviso tra le macchine.
Ok però così hai bisogno di almeno 4 macchine per avere HA e LB, io devo 
sbrigarmela con due (sì, me ne frega che vada più lento se dovesse morire 
una macchina, è una perdita di prestazioni accettabile).
-- 
Vide

 sembra effettivamente quello che cerco)
Ok, ulteriore dubbio da sottoporre.
Premessa: vorrei evitare, se possibile, lo storage condiviso.
Se metto un proxy IMAP/SMTP con due server dietro e faccio:
- SMTP: manda una copia della mail a entrambi i server
- IMAP: in base all'utente invia a un server o a un altro.
ho HA e LB *a parte* i casi in cui un utente muove manualmente mail da una 
parte all'altra. però perdo anche la possibilità di cancellare la mail da 
una parte e che scompaia anche dall'altra... che potrei risolvere con un 
rsync, ma cominciamo ad entrare nel territorio delle soluzioni sporche.
La soluzione migliore è avere quindi lo storage condiviso a livello fisico 
(drbd o SAN, a seconda)?
Skull? :D
-- 
Vide

 Skull? :D
Muà?!?
Perchè muà?!?
Cmq, dipende dalle dimensioni e dalla scalabilità di ciò che devi gestire.
E dal tipo di ridondanza che vuoi ottenere.
Tipicamente perdition l'ho visto usato in architetture "tipo 1+0", per 
rifarsi al RAID:
N mailserver a fare local-delivery, ciascuno con un suo "gemello". 
Storage locale, allineato con il gemello via drbd. Questo ti dà la 
ridondanza. Ciascuno di questi N contiene solamente un TOT di mailbox e 
solo quelle, ed esegue un servizio POP/IMAP per esse. Un database di 
qualche tipo mantiene correlazione tra mailbox e server fisico dove sta. 
A saturazione delle risorse (I/O, banda, spazio disco, whatever) si 
aggiunge una nuova coppia di sistemi al pool.
I mailserver a tier 1 (MTA puri, niente mailbox) instradano sulla base 
della locazione fisica della mailbox al tier 2 dove la mailbox sta, 
guardando sul database suddetto. Questo consente alti flussi, 
soprattutto perchè lo store-and-forward che vieene eseguito dalle MTA è 
scalabile linearmente con minimo sforzo, e ci gestisci praticamente 
quante mail vuoi (o quasi).
I server POP/IMAP "di frontend" usano perdition, il quale, guardando in 
tale stesso database, fa da proxy verso il server dove la mailbox sta.
Anche i server di frontend, analogamente alle MTA, scalano linearmente 
(ma prima di saturare le risorse di perdition ce ne vuole, dato che lui 
fa solo I/O di rete e non tocca nemmeno i dischi...).
E' una architettura che scala dannatamente *tanto*, dato che non c'è 
nessun elemento singolo (foss'anche la SAN) che possa mai fare da collo 
di bottiglia, ma è anche esosa in termini di progettazione iniziale e 
richiede un numero minimo di ruoli tutt'altro che irrilevante...
Usare storage condiviso può risultare parecchio più semplice, ma anche 
lì occhio a non avere poi il collo di bottiglia proprio sul fatto di 
avere FS condiviso: ho già visto in diretta gente mettersi in piedi il 
cluster strafigo su SAN da 100K€ e poi attentare alla propria stessa 
virilità a causa delle prestazioni risibili che cavava fuori da GFS...
Quindi occhio al dimensionamento e agli strumenti che utilizzi.
Active/active fa un sacco figo, ma in alcune occasioni un sano 
active/passive + passive/active può rendere di più, prestazionalmente...
Io personalmente ho usato per anni un active/passive "normalissimo", per 
un FS esportato via NFS, poi usato dai mailserver. Funziona 
discretamente, IMHO, ma io non gestisco strutture enormi...
So anche di gente che ha cavato fuori prestazioni mirabolanti usando 
Lustre come filesystem per lo storage delle mailbox, ma solo a pensarci 
mi viene mal di testa...
-- 
http://bofhskull.wordpress.com/

 Quindi occhio al dimensionamento e agli strumenti che utilizzi.
Il punto è che non so a quale compromesso scendere. Storage condiviso (senza 
filesystem clusterizzato) significa attivo/passivo, ergo zero LB.
D'altro canto per avere attivo/attivo o rinuncio a parte dell'alta 
disponibilita (se uno dei due cade, si tira di backup per recuperare le 
caselle mancanti del server gemello) oppure faccio l'1+0 come dici tu... 
però mi sa che con la crisi 4 macchine non me le lasciano utilizzare.
Boh, grazie per le dritte... ormai sta a me la decisione dato che devo 
vedere cosa posso ottenere a livello hardware.
-- 
Vide

 (per il momento :P)
In tal caso, le prestazioni migliorerebbero già tanto anche solo 
mettendo lo storage della posta su uno storage un po' più prestante.
Puoi cavare buona roba anche con spesa dell'ordine dei 2500-3000€ su iSCSI.
Con servizi IMAP il collo di bottiglia è praticamente sempre lo storage...
-- 
http://bofhskull.wordpress.com/

 Con servizi IMAP il collo di bottiglia è praticamente sempre lo storage...
Già. Spiegaglielo a chi ha comprato il server... (io sono ormai 3 anni che 
ci provo)
-- 
Vide