Newsgroup: it.comp.os.linux.sys
Titolo: Dovecot in HA

Avete mai messo dovecot in HA ?
Stavo facendo alcune supposizioni (e per definizione, le mie supposizioni sono roba da psicopatico :D )
 
Supponendo di avere uno storage condiviso (ad esempio GlusterFS di cui si parla nell'alto thread), usando Maildir o DBox come formato e facendo in modo che una determinata casella sia gestita solo da un server per volta, non ci sarebbero problemi di locking. Dico bene?
 
Usando utenti virtuali magari salvati su db è possibile splittare le caselle su due o più server associandole magari all'ip del nodo dovecot. 
Nel caso un server morisse, basterebbe cambiare il puntamento di tale ip sul database per spostare il traffico sulle macchine rimaste in piedi.
 
Ancora meglio usando (magari sempre dovecot) dei proxy imap davanti ai vari server. I server reali autenticano potenzialmente tutte le caselle, mentre i proxy smistano le richieste "un po qui", "un po li" assicurandosi che la casella 
pi...@pluto.it
 sia gestita solo dal server1 e mai dal server2.
 
Se il server1 muore, il proxy gira 
pi...@pluto.it
 su server2
 
Mi sembra relativamente semplice, non implica un filesystem, ha dei costi di implementazione quasi nulli (con delle VM per i proxy ed i vari dovecot i costi si abbattono) ed una scalabilità orizzontale. Servono più risorse? Si aggiunge un server e si ribilanciano le caselle dai proxy magari con un brutale algoritmo di questo tipo (la butto li):
 
5000 caselle, 3 server:
5000/3 = 1667 caselle per server. Gli ID da 1-1667 van sul primo, quelli da 1668 a 3335 van sul secondo e così via.
Si aggiunge un server e si ricalcola dividendo per 4.
 
Così a naso sono poche righe di script per riconfigurare automaticamente i proxy in base al numero di server operativi.

 Se il server1 muore, il proxy gira 
pi...@pluto.it
 su server2
 
Che ne dici di Linux Virtual Server (
http://www.linuxvirtualserver.org/
)?
L'ho usato per anni dal Provider dove ho lavorato e funziona che e' una
meraviglia...
 
Hai X Server (non serve neanche che abbiano IP "pubblici") e un Server di
controllo (meglio due con HA attivo/passivo) che smista le richieste ai
vari Servers interni.
Se si schianta un Server, LVS se ne accorge subito e manda le richieste
agli altri.
 
Ovvio, devi avere un qualche supporto per il FS "resistente agli schianti".
Un FS distribuito e' un'opzione. Al tempo usai una NAS della NetApp
(FANTASTICA! Anche se un po' costosa).
 
Ciao
Luca Bertoncello
(
luca...@lucabert.de
)
 
-- 
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it
 
 
 

 Avete mai messo dovecot in HA ?
 
No, ma io farei così:
Configuro una o più macchine dovecot che possono accedere a tutto il
datastore delle mailbox.
 
Poi stabilisco N indirizzi IP differenti (io ne prevederei 12) e associo
ciascun dominio dei clienti ad un IP specifico.
 
Quindi avrò 
p.es
.
imap.cliente1.it
	IP1
imap.cliente2.it
	IP2
imap.cliente3.it
	IP1
imap.cliente4.it
	IP3
imap.cliente5.it
	IP1
 
ecc.ecc. in modo da bilanciare + o - il numero di caselle tra i vari IP.
Se vuoi puoi anche ospitare ciascun datastore dei domini su una risorsa
glusterfs separata fino ad avere una risorsa storage per IP.
 
Quindi configuro i vari nodi in cluster con corosync che gestisce le
sole risorse IP tra i vari nodi.
 
Supponendo di avere 12 IP puoi avere 1 nodo con tutti gli IP, 2 nodi con
6 IP ciascuno, 3 nodi con 4 IP, 4 nodi con 3 ip, 6 nodi con 2 IP o anche
12 nodi con un IP ciascuno.
 
In questo modo:
- sei certo di non avere sovrapposizioni col locking perché ciascun
dominio è associato ad un solo IP che può essere presente su un solo
nodo in ciascun istante.
- aggiungere nuovi nodi comporta solo installare una nuova macchina e
farla partecipare al cluster assegnandole una parte degli IP e
replicandovi i corrispondenti datastore
- bilanciare in modo diverso le risorse è solo questione di spostare un
indirizzo IP
- spostare la gestione delle risorse da un nodo all'altro è praticamente
istantaneo (meno di un secondo)
- Il controllo della disponibilità dei servizi è possibile direttamente
con corosync il che consente controlli molto più efficaci di quelli
possibile da un balancer o da un proxy esterno.
- consente di aggiornare il software un nodo per volta senza impattare
quindi su tutti i clienti in un colpo solo permettendoti un passaggio
graduale.
- Puoi facilmente sbilanciare i cluster in funzione delle risorse.
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

 istantaneo (meno di un secondo)
 
IMHO, un takeover di meno di un secondo in ambito mail, sopratutto imap, non ha senso.
La connessione del client verrebbe comunque interrotta e 9 volte su 10 l'utente riceverebbe un errore.
Eventuali client pop3 riceverebbero errore fino alla rimappatura del cluster, gestibile con un: "No caro cliente, nessun problema, è probabile che abbia avuto problemi di adsl"
 
IMHO, una bella mappatura statica su file <email><server> aggiornata da un qualche demone che monitora lo stato del cluster, sarebbe perfetto. Cron ogni minuto o 30 secondi e via andare.

 indirizzo IP
 
e' esattamente ciò che ho detto/pensato io.
L'unica differenza è che te usi corosync, io pensavo di usare dei proxy ma il concetto è il medesimo: i vari dovecot devono potenzialmente essere in grado di accedere a tutto il datastore.
 
Sarà compito di una risorsa esterna (nel mio caso un proxy banale, nel tuo corosync) fare in modo che non ci siano due dovecot per lo stesso dominio.
 
Io pensavo di lavorare per email anzichè su dominio. bilanci molto meglio (un dominio da 10.000 caselle pesa di più rispetto a 100 domini da 1 casella) ed in caso di catastrofe globale (vuoi mai che non funzioni il failover) alcune mail dello stesso dominio continuerebbero a funzionare senza isolare una intera azienda.
 
Mi sembra qualcosa di attivabile in 1-2 giorni con gluster+XFS e senza troppe complicazioni.

 Mi sembra qualcosa di attivabile in 1-2 giorni con gluster+XFS e senza troppe complicazioni.
 
Sì.


 fatto i dovuti test.
 
Beh, no.
Ovviamente se non ha funzionato il failover, un problema c'è stato, ma almeno l'azienda cliente in qualche modo lavora. Nessuna rivalità, se devono ricevere una mail possono dire telefonicamente: mandatela a 
x...@azienda.it
 invece di 
y...@azienda.it
 
 
Il tempo di reazione del fornitore deve essere il medesimo sia in caso di azienda ko che azienda solo mutilata, ma almeno l'azienda lavora

 
x...@azienda.it
 invece di 
y...@azienda.it
 
 
Abbiamo clienti diversi... alcuni miei clienti si scannerebbero se ad
uno funzionasse la mail e all'altro no. :D


 uno funzionasse la mail e all'altro no. :D
 
Con questa frase ho capito che non mi hai capito.
Non parlo di un cliente funzionante e ad un altro no.
Parlo dello stesso cliente, dove ad un dipendente funziona la mail e l'altro dipendente, nella scrivania davanti, no.

 e l'altro dipendente, nella scrivania davanti, no.
 
Appunto... tra i miei clienti ve ne sono alcuni in cui se ad una
segretaria non funziona la mail mentre alla sua vicina va tutto bene,
rischi la vita....


 rischi la vita....
 
Oibho!

 di clienti > 50 sono certo che puoi bilanciare perfettamente.
 
Quindi te useresti il DNS per bilanciare (un dominio sul nodo1, un dominio sul nodo2, ...) e corosync lo useresti per spostare gli IP da un nodo all'altro in caso di guasto, senza dover alterare il dns, giusto?
 
In sostanza, faresti gestire tutti gli ip a corosync, che normalmente rispecchiano la configurazione dns, in caso di contingency, corosync sposta le risorse...

 contingency, corosync sposta le risorse...
 
Esattamente.


 per garantire maggiori performance o per qualsiasi altro motivo.
 
Vabbe', son scelte...
Io ritengo che, sopratutto adesso come adesso, con gli IPv4 esauriti e la
maggior parte dei Provider che non sa cosa voglia dire IPv6, che far fare
questi lavori al DNS usando cosi' tanti IP e' uno spreco...
 
Ognuno faccia quel che vuole, ma io ricordo bene che, con LVS e *UN* IP,
gestivamo *TUTTI* i Servers di posta (SMTP ingresso, SMTP uscita e
POP/IMAP).
Personalmente mi sembra un vantaggio non indifferente...


 Personalmente mi sembra un vantaggio non indifferente...
 
Quella di gestire con un solo IP tutto è una pratica che va bene per la
singola azienda, non per un provider di servizi come in questo caso.
 
Poi sono concorde che non si dedica un IP esclusivamente al server
IMAP/POP3 e che si debba valutare in funzione del numero di clienti che
si hanno, ma non sono 6 IP quelli che fanno la differenza. Senza contare
che con LVS non puoi entrare nel merito del protocollo per effettuare le
scelte di redirezione.


 si hanno, ma non sono 6 IP quelli che fanno la differenza.
 
Non sono certamente gli IP il mio problema.
Piuttosto sto valutando l'uso di eventuali proxy. Il lato negativo e che si complica l'infrastruttura (bisogna aggiungere macchine), il lato positivo è che i server dovecot possono essere su subnet non ruotate e protette.

 scelte di redirezione.
 
Occhestaiaddi? Certo che decido un merito al protocollo che Server usare!
Al tempo configurai il sistema per usare, sullo stesso IP, SMTP e
POP3/IMAP. E i Server SMTP erano ben diversi da quelli con POP3/IMAP
(addirittura in armadi diversi)!
E la differenza la facevo usando proprio il numero della porta (OK, son
d'accordo che tu puoi spedire FTP sulla porta SMTP e LVS inoltra in base
alla porta specificata senza analizzare il protocollo, ma in quel caso
gia' l'MTA ti rifiuta la comunicazione, no?).
E ovviamente potevo scegliere in che modo smistare i pacchetti ai vari
nodi (Round-Robin, Balanced Round-Robin, etc.). Altrettanto ovviamente una
comunicazione TCP aperta su un certo nodo continuava su quel nodo finche'
non la si chiedeva.
 
Mi pare per giunta di ricordare che, a partire da una certa versione, sia
anche possibile inoltrare una comunicazione HTTP (con sessione) sempre
allo stesso Server. Ma qui non sono piu' sicuro al 100%...


 allo stesso Server. Ma qui non sono piu' sicuro al 100%...
 
Quando l'ho usato io l'ultima volta si poteva solo fare stiking per IP o
IP/porta.


 allo stesso Server. Ma qui non sono piu' sicuro al 100%...
 
Per quanto ne so, lo ha sempre fatto.
Anche perchè altrimenti sarebbe del tutto impossibile usarlo con
protocolli multi-porta come FTP.
 
Parametro -p di ipvsadm.
 
Ma non ha nulla a che fare con quello cui si riferiva Zip (ma lo ha già
detto lui...)

 IP/porta.
 
Sinceramente, essendomi solo occupato dei Servers di posta, non ho mai
avuto l'occasione di provare con HTTP. Ma mi sembra proprio di ricordare
(nel 2007, ma non chiedermi che versione si usava!) che fosse possibile.
Almeno, cosi' mi disse al tempo il collega che se ne occupava...


 fare! E questo lavoro deve ben essere pagato...
 
Penso tu non abbia compreso quanto proposto, perché il lavoro è
certamente minore. L'unico "problema" effettivamente è quello degli IP
pubblici, ma IMHO in questo caso è secondario (considerando che ha una
/21 a disposizione e che se non ricordo male non è ancora tanto grosso
da usarli tutti).


 successivi di quella connessione verranno mandati allo stesso Server.
 
E chi l'ha detto?
Lato client, il server sarà sempre e solo il bilanciatore, pertanto il client inoltrerà i pacchetti solo verso di lui.
Spetta al bilanciatore usare sempre lo stesso server in caso di richieste multiple, e non è detto che lo faccia, se non tiene traccia delle sessioni in essere. Anzi, se hai un banale round-robin, quasi sicuramente non becchi lo stesso server di fila. (si potrebbe anche togliere il quasi)

 Spetta al bilanciatore usare sempre lo stesso server in caso di richieste
multiple, e non è detto che lo faccia, se non tiene traccia delle sessioni in
essere. Anzi, se hai un banale round-robin, quasi sicuramente non becchi lo
stesso server di fila. (si potrebbe anche togliere il quasi)
 
Credimi, LVS lo fa. Lo ha sempre fatto e sempre lo fara' (anche perche'
altro non avrebbe senso).


 acquista i servizi da te.... come lo risolvi subito?
 
Gli IP per l'uscita delle E-Mail non sono (necessariamente) quelli per
l'entrata... :)
 
Quanto al bloccare un cliente che spedisce Spam, e' una cosa banale e non
serve assolutamente avere X IP e tanti programmi a disposizione...


 serve assolutamente avere X IP e tanti programmi a disposizione...
 
FUSSP! FUSSP!
Spiega, spiega!
 

Spiega, spiega!
 
Non conoscevo l'acronimo, ma questo merita:
 
http://www.rhyolite.com/anti-spam/you-might-be.html
 
 
http://www.dmuth.org/fussp.html
 
 
Leonardo scendente ora dal pero
 
-- 
Tell us whether you spy, in the light of the morn,
what saluted was fiercely at the fall of the past day:
whose pips and whose bands in the very heart of the fray
bravely floated from the bulwarks to which we were sworn?

 IMAP/POP3
 
Perchè no?!? O:-)
 
 
 
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/
 

 altro non avrebbe senso).
 
Allora LVS lo fa (quindi il bilanciatore, come ho detto io), non il TCP/IP.

 Perchè no?!? O:-)
 
Era da intendersi se si è in scarsità di IP, come nel mio caso privato
in cui su 1 IP (il quarto è lì fermo per Leo se si da una mossa :D ) ci
faccio girare tutto: smtp, imap, webmail.
Su infrastrutture da ISP o meglio da ESP la separazione è cosa buona e
giusta, anche nel caso in cui alla fine, per scarsità di risorse
necessarie o disponibili, fosse una stessa singola macchina a gestire il
tutto (
p.es
. sempre sul mio caso privato per gli IPv6 dedico un IP a
ciascuno dei 3 domini che ho anche se sono tutti nella medesima network
/64).
dig +short -x 2001:1418:107:102::2
dig +short -x 2001:1418:107:102::3
dig +short -x 2001:1418:107:102::4


 loro", con nodi del tutto stupidi.
 
E poi, almeno un tempo (non uso più LVS da una vita), LVS e netfilter facevano
a cazzottoni, con risultati talvolta buffi. Meglio i reverse proxy, tutta la vita.

 Meglio i reverse proxy, tutta la vita.
 
Dipende.
Il proxy è certamente più flessibile, ma se i servizi che devi
bilanciare/clusterizzare sono diversi rischi di dover seguire N
approcci/proxy diversi in funzione del servizio, e potresti ritrovarti a
gestire dei grossi mal di testa per questo...
 
LVS e il suo essere del tutto agnostico al protocollo è anche un
vantaggio, di tanto in tanto O:-)
 
Poi LVS scala su numeri molto più alti, dato che il limite è dato la
capacità dell'HW di routare pacchetti e dalla dimensione della tabella
delle connessioni a sua disposizione, e non da cose come numero di
socket, consumo di CPU o memoria disponibile al proxy.
 
L'approccio a prova di bomba è bilanciare a livello network un cluster
di proxy applicativi. O:-)
 
Non a caso è il tipo di approccio che si segue per implementare
soluzioni anti-DDoS per sistemi web:
 
http://www.blyon.com/using-squid-proxy-to-fight-ddos/
 
 
 
Ma andiamo un po' tanto OT ;-)


 Ma andiamo un po' tanto OT ;-)
 
Siamo OT già da un bel po.
Io volevo parlare dello storage da mettere sotto un dovecot in HA, non tanto di come mettere in HA dovecot. :)
 
A proposito, hai ancora quella VPS di test?

 di proxy applicativi. O:-)
 
Cellò, senza usare LVS. :)
pacemaker/corosync che gestiscono un ip condiviso (*attivo* su tutti i nodi
con ClusterIP) e stunnel+haproxy. Un mostriciattolo che dà discrete soddisfazioni. :)

 A proposito, hai ancora quella VPS di test?
 
No :-P


 avanti e indietro...)
 
Qui mi sa che il problema è la latenza :-)
 
-- 
ValeRyo 
 
 

 banale...
 
Esatto.
 
L'unica accortezza, FONDAMENTALE, come il manuale di dovecot recita, è 
che l'accesso alla stessa mailbox avvenga sempre dallo stesso server nel 
caso il filesystem sottostante non supporti il locking dei files (vedasi 
NFS nella stragrande maggioranza delle implementazioni).
 
Traducendo: fai sempre in modo che ogni singola utenza atterri sempre sul 
medesimo backend e vivi felice, qualunque filesystem si utilizzi.

 Qui mi sa che il problema è la latenza :-)
 
Steroidi nanici?


 active/active è del tutto banale...
 
Ma perchè i nani? Sono più performanti? Preferirei degli gnomi, ne
ho giusto alcuni qui.

 lento probabilmente per le concorrenze. Ho sbagliato io qualcosa?
 
Gluster ed NFS hanno prestazioni analoghe, anzi, in lettura ed in
concorrenza gluster è più veloce, visto che può accedere simultaneamente
a tutto un pool di server.
 
Solitamente i webserver sono più invasivi in termini di risorse, i client
pop3 scaricano tutta la mail quindi non accedono alla maildir, i client
imap scaricano gli header e poi gestiscono in locale il resto, leggendo la
mail alla bisogna. Un webserver accede sempre e comunque.
 
O mi sfugge qualcosa oppure mi risulta difficile credere che un mailstore
sia più lento di un webstore.

 ho giusto alcuni qui.
 
Nani vs Gnomi? 15 anni fa avrei potuto mettere su un flame infinito al
riguardo.
 
Non ho più l'età.... :-(


 ho giusto alcuni qui.
 
Il nano è più incazzoso quando c'è traffico.
Se dedichi la connettività alla replica vanno bene anche gli gnomi.
 
-- 
ValeRyo 
 
 

 mailstore mantengano gli indici separatamente, su una partizione locale.
 
Ecco uno spunto di cui parlare.
Mettendo gli indici in locale, magari su dischi SAS da 146GB o addirittura
SSD, o RAM, l'accesso agli stessi sarà fulmineo, ma in caso di guasto al
nodo, gli indici dovranno essere ricreati su un nodo differente, dico bene?
In tal caso, il primo accesso dopo un crash risulterebbe lento.
 
E' da valutare. Per alcuni potrebbe non andare bene, magari se hai, come me,
una maildir da 120GB (centoventi giga)

 riguardo.
 
Sono Gandalf mica per niente, anche io potrei mettere su un flame infinito su questo argomento.

 Se dedichi la connettività alla replica vanno bene anche gli gnomi.
 
Questo l'ho dato per scontato. Connettività gigabit e jumbo attivi.
Ho solo paura che il jumbo frame sia più grosso dello gnomo, dopo ci
vuole una cariola per trasportarlo.

 medesimo backend e vivi felice, qualunque filesystem si utilizzi.
 
si, infatti sia con il mio metodo, sia con quello di Zippo, una casella
sarà attiva solo su un singolo nodo. anche se poi il nodo stesso è in grado
di leggere potenzialmente tutto il filesystem.

 Steroidi nanici?
 
Sale troppo il costo :D
 
-- 
ValeRyo 
 
 

 mailstore sia piů lento di un webstore.
 
Ecchettedevodě: webserver che condividono store nfs ne ho e vanno bene.
 
Dopo qualche prova con NFS su un mailserver ho abbandonato causa
risultati penosi. Ciň non toglie che possa aver sbagliato io qualcosa.
 
-- 
ValeRyo 
 
 

 risultati penosi. Ciò non toglie che possa aver sbagliato io qualcosa.
 
La seconda che hai detto.
Tendenzialmente, entrambe le cose funzionano ed entrambe hanno un 
decadimento di performance (ovvio) rispetto all'utilizzo di un FS locale.
 
Ma mentre con un mailserver l'utente di solito nemmeno se ne accorge, con 
un webserver ti posso garantire che, sebbene funzionando (e pure bene), 
tutto diventa MOLTO più lento (e non scala per nulla). 

 tutto diventa MOLTO più lento (e non scala per nulla).
 
Appunto, è ciò che dico anche io (per quel che conta)

 bene), tutto diventa MOLTO piů lento (e non scala per nulla).
 
Boh... che fo, riprovo?
E' possibile che i webserver vadano bene grazie alla tanta ram che di
solito alloco?
Con il mailserver avevo praticamente tutti i processi in io-wait.
 
-- 
ValeRyo 
 
 

 Puoi darmi qualche riferimento al riguardo?
 
mail_location = maildir:/var/spool/maildir/%u:INDEX=/var/indexes/%u
 
http://wiki.dovecot.org/MailLocation
 


 mail_location = maildir:/var/spool/maildir/%u:INDEX=/var/indexes/%u
 
Ovvio, grazie e scusa per la domanda scema... credevo a chissà
quale macumba ti riferissi.
 
In definitiva tu cosa mi consiglieresti per lo scenario di alcune (2-3)
macchine che devono accedere allo stesso mailstore per pop3 e
imap? NFS che è 'vecchio e conosciuto' però mi costringe ad usare
un altro sistema per la replica dei dati (drbd non è un problema),
OCFS2 che potrei usare su un volume iSCSI montato da più
macchine, o GlusterFS che mi da' il vantaggio di una replica geografica
che al momento non mi serve, ma tra un po' chissà?
 
-- 
ValeRyo 
 
 

 che al momento non mi serve, ma tra un po' chissà?
 
No, non te lo da. Provalo su scala geografica, guarda le performance e poi ne riparliamo.
 
Se per te è lento NFS in LAN prova GlusterFS tramite WAN e poi vediamo.

 
http://wiki.dovecot.org/MailLocation
 
 
Però non quadra una cosa, mettendo gli indici in locale come hai suggerito.
Ad ogni guasto, gli indici saranno ricreati su un nodo differente.
Appena il nodo guasto torna online, eventuali aggiornamenti agli indici fatti sul nodo "temporaneo" saranno nuovamente persi.
 
Questo poi pregiudica un eventuale bilanciamento dinamico del traffico e ti obbliga a mantenere il più costante possibile l'associazione nodo<>mailbox.
Se ad esempio in caso di carico estremo ad un nodo spostassi le mailbox, perderesti gli indici.

 Se ad esempio in caso di carico estremo ad un nodo spostassi le mailbox, perderesti gli indici.
 
E quindi?
Non č che sposti in giro le mailbox tra i nodi per il gusto di: il
cambio di nodo č una circostanza di degrado, non il passatempo dello
staff...
 

 staff...
 
hai perso una riga.
in caso di guasto ci può anche stare (devo vedere cosa "succede" cancellando gli indici, la webmail sarà sicuramente lenta ma un client forse non noterà differenze sostanziali), ma così facendo perdi la possibilità di distribuire
dinamicamente il carico di lavoro perchè in questo caso un dotato dominio
potrebbe essere trasferito più volte al giorno.
 

 staff...
 
e comunque secondo il tuo ragionamento, tanto vale mettere gli indici
in ram, tanto non è che stai a riavviare il nodo tutto il giorno no?


In tutta sincerità la "distribuzione dinamica del carico di lavoro" è
una feature abbastanza inutile per dei server IMAP, salvo forse in
contesti del tutto peculiari...
 
 
Diversamente da quel che accade con SMTP -in cui hai grosse variazioni
dei carichi dovuti ad eventi esterni- con IMAP il carico lo danno i tuoi
utenti, e dipende in maniera del tutto lineare dal loro numero e dalla
dimensione delle loro mailbox.
E' del tutto stabile nel tempo, almeno nella mia esperienza: spostare
gli utenti a destra e a manca lo fai al più per redistribuire il crico
quando aggiungi un nuovo sistema al pool e vuoi scaricare il resto dei
nodi in quanto vicino ai limiti.
 
Ma farlo per bilanciare uno sfasamento del 3% nel carico di oggi dovuto
al fatto che il cliente X oggi non si collega perchè c'ha il santo
patrono, son solo pippe mentali, IMHO ;-)
 
Tanto, a meno che non inizi ad avere le macchine in sofferenza (e non è
che ci vanno dall'oggi al domani, eh) la qualità del servizio per un
server IMAP è dato dal tempo di accesso allo storage (che nel caso di un
cluster è sempre nello stesso posto): quanti altri processi IMAP sono in
esecuzione sul server è sostanzialmente irrilevante...
 
 
 
Poi se proprio insisti l'alternativa c'è: appoggi sia mailstore che
indici su un filesystem clustered e fai active/active finchè ti pare. Ma
nel caso medio l'overhead causato da dover gestire locking distribuito
tra i nodi fa sì che peggiori sensibilmente il best-case, a vantaggio di
un miglioramento del worst-case.
 
Poi sta a te e a quanto spesso ti ritrovi nel worst-case decidere se
vale la pena o no...
 


Assolutamante, e infatti non lo sconsiglio affatto, se la quantità di
ram a disposizione e la stabilità della tua infrastruttura (ovvero non
fai reboot del server IMAP se non una volta l'anno o già di lì) te lo
consentono.
 
Ma avere una quarantina di GB di RAM a disposizione degli indici (questo
quel che occupano gli indici di ~10K utenti nella mia esperienza, con un
minimo di margine volto a evitare che lo spazio a disposizione degli
indici possa saturare)  non è poi così frequente, e posso immaginare
utilizzi migliori per quella risorsa...
 
 

 contesti del tutto peculiari...
 
Si, in effetti è una feature abbastanza inutile.

 utilizzi migliori per quella risorsa...
 
40GB di indici su un solo nodo. Qui si parlava di HA, quindi se i nodi son 2 e ben ripartiti, diventano 20GB. 4 nodi = 10GB
 
Il costo di 16GB di ram (quindi con un 60% di margine extra) è inferiore a quello di qualunque disco SAS/SSD e le performance non sono nemmeno lontanamente paragonabili.
 
Ma sti indici velocizzano così tanto l'accesso se messi in SSD/RAM rispetto ai dischi SAS locali? Un conto è avere un accesso sensibilmente più rapido, un altro è avere praticamente le stesse performance ma una infrastruttura più complessa data dai ramdisk e cose simili.
 
Ne vale la pena?

 utilizzi migliori per quella risorsa...
 
Vedo che sempre più spesso si sceglie di mettere un paio di dischi SSD
da 128GB o più su cui schiaffare gli indici, che siano quelli IMAP o di
Oracle o di qualsiasi altro sistema che richiede velocità di accesso a
piccoli insiemi di dati.
 
Due dischi SSD da 128GB oggigiorno costano molto poco, e per scarsi che
siano sono sempre meglio degli storage classici iSCSI
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

 Ne vale la pena?
 
Se non lo sai tu :)
Noi non sappiamo di che numeri parli.


 Noi non sappiamo di che numeri parli.
 
Nessun numero, è un discorso generale.
Se fossero 10k? 100k?
I miei numeri attuali non fan statistica, sarebbe interessante valutare la differenza di performance da chi ha numeri elevati.

 Nessun numero, è un discorso generale.
 
Se è un discorso generale allora non metterei glusterfs. :)


 Se è un discorso generale allora non metterei glusterfs. :)
 
In che senso? Non lo metteresti nel discorso o non lo metteresti in una ipotetica struttura?
 
Perchè? Cosa non ti piace? Cosa useresti?

 Perchè? Cosa non ti piace? Cosa useresti?
 
Userei uno storage FC condiviso e un cluster classico. Le repliche le
farei a livello di storage con il suo sistema nativo o al limite con
qualcosa tipo Site Recovery Manager se fosse tutto sopra VMware.


 qualcosa tipo Site Recovery Manager se fosse tutto sopra VMware.
 
Sono due architetture completamente differenti e con scalabilità differenti.
Gluster ed affini ti permettono di scalare su petabyte di spazio a costi irrisori e senza alcun tipo di rete o hardware dedicata. 
Più nodi metti, maggiori saranno le performance.
 
con uno storage in FC, oltre a costi di startup decisamente più elevati, non riusciresti ad avere le stesse features e la stessa scalabilità se non andando, forse, su fascia altissima. se vuoi aggiungere spazio devi aggiungere chassis alla san, mettendolo in cascata, con conseguente collo di bottiglia (prima o poi arriva, a meno che non si prendano in considerazione SAN del tipo equallogic o lefthand)
Nel caso di gluster, aggiungi un nodo, estendi il volume ed i dati di quel nodo saranno letti direttamente da quel nodo, senza fare ring o daisy-chain particolari.
 
A meno che uno non debba gestire centinaia di migliaia di caselle da oggi a domani, dubito che uno storage FC tradizionale sia più conveniente e più consigliabile rispetto ad una soluzione gluster, in merito all'oggetto di questo thread.