Newsgroup: it.comp.os.linux.sys
Titolo: Re: mail server con record MX oppure NLB

 Quale è la soluzione migliore ?
Gli MX.
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGP2Z88THo01J+SBERAt65AJ9xKIXZ2XC4hQDJdBNCX2Mpvznr3ACgob0R
C2b4x7NfgBodUcJYzjfLAf0=
=BP2k
-----END PGP SIGNATURE-----

 Quale è la soluzione migliore ?
Dipende!
Se quello che interessa a te e' di spezzare il carico tra le due macchine,
l'UNICA soluzione e' un Cluster Load-Balancing (consiglio KeepAlived: e'
semplice da configurare e funziona senza dare problemi. SCONSIGLIO CON
TUTTE LE MIE FORZE di implementare soluzioni assurde [ma viste spessissimo
anche in ditte teoricamente esperte di reti] come un Load-Balancing
implementato con un DNS-Round-Robin).
Se invece ti basta che, quando un Server e' fuori uso l'altro prenda il
suo posto, allora basta configurare due MX (primario e secondario).
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

 implementato con un DNS-Round-Robin).
Mbah....
Vero per qualunque altro servizio, ma per MTA proprio no...
Avendo due mailserver e volendoli porre in bilanciamento 50-50, metti
due MX con la stessa priorità e vivi felice, senza incasinarti la vita,
e con una soluzione perfettamente ridondante.
Usare bilanciatori (indipendentemente dal tipo) nel caso di mailserver è
una buona idea se il numero di server inizia ad essere significativo (e
quindi la distribuzione del carico diventa meno banale), o se ci sono
ragioni particolari per farlo (ad esempio la necessità di bilanciare
sulla base del carico), ma per una situazione semplice come due MTA in
parallelo significa solo aggiungere un punto di complessità aggiuntiva
senza che ve ne sia alcuna ragione e alcun vantaggio...
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGQCIJ8THo01J+SBERAhD9AKC1jp0WAGxCGyYkBc4qc6fdIJw2NQCgynvG
ATKyNzxX6LIIm/GVhF2rm3w=
=JxVk
-----END PGP SIGNATURE-----

 senza che ve ne sia alcuna ragione e alcun vantaggio...
Questa e' la tua opinione...
La mia opinione e' che, se si vuole bilanciare un carico di lavoro o anche
semplicemente creare una ridondanza, e' SEMPRE meglio usare gli strumenti
preposti, in quanto... sono fatti apposta e non ti creano problemi.
Usare altri strumenti, pensati per tutt'altre cose, per fare un
load-balancing o un failover, crea SEMPRE un problema, perche' usi gli
strumenti nel modo sbagliato.
Poi, ripeto, ognuno faccia cio' che vuole! :)


 In altre parole: lavorare e' quasi impossibile...
scusa....
quali problemi stai incontrando?
Di solito, la configurazione proposta da skull funziona senza problemi

 preposti, in quanto... sono fatti apposta e non ti creano problemi.
Balle.
L'intero servizio SMTP (con le sue priorità MX e la possibilità di
usarle uguali per la distribuzione del carico) è stato *pensato* fin da
principio in funzione di scalabilità e ridondanza. I meccanismi di
distribuzione del carico tramite l'uso di più MX non sono affatto una
soluzione "sporca": sono la soluzione *nativa* del protocollo.
Poi, su strutture altamente scalate, sono soluzioni che hanno i loro
limiti (di fatto, bilanciamento dinamico, oltre ad alcune limitazioni
dei DNS stessi su numeri molto alti), ergo su tali strutture ha senso
ricorrere a bilanciatori di vario genere e sorta; nulla da ridire al
riguardo.
Di fatto, dal trend che ho visto in strutture di grosse dimensioni, vi è
la "necessità" di usare bilanciatori solamente al di sopra dei 10-15
MTA, per quanto abbia presente strutture che usano banchi di oltre 50
MTA, raggruppati in 4-5 record MX, senza difficoltà di sorta pur senza
l'uso di bilanciatori. E dove si rimane restii riguardo all'opportunità
del loro inserimento, in base, appunto, al fatto che aumentano la
complessità globale della soluzione.
E dato che una qualche complessità aggiuntiva certamente la introducono
(maggiore o minore a seconda del tipo di bilanciatore utilizzato),
quello che va fatto è un calcolo del tradeoff tra questa complessità e i
benefici ottenuti, per stabilire se e dove vale la pena di introdurla.
IMHO, nello scenario con due soli MTA, soprattutto se uguali, siamo
abbondantemente al di sotto della massa critica.
Poi, come giustamente dici, che ognuno faccia quel che gli pare, in
funzione della propria esperienza e del proprio credo personale...
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGQC2x8THo01J+SBERAvRUAJ96MVLCBLNkbWicw1G6jme71Zh3vgCdFUU1
P4WBm1S4fa4V45toBW9tDu8=
=HeIr
-----END PGP SIGNATURE-----

 preposti, in quanto... sono fatti apposta e non ti creano problemi.
I record MX sono gli strumenti nativamente preposti, nel caso di SMTP,
fino a prova contraria.

 **CREDO** di aver imparato qualcosa...
E io credo che tu mi ricordi un altro frequentatore di usenet, uno che
si e' preso sui denti un post cosi':
---cite---
Vedi, .... dovresti smetterla di cercare di insegnare alle persone il
loro mestiere.
---/cite---
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 ---/cite---
Ecco! Quello di gestire MailCluster **E'** il mio mestiere!
Quindi, se permetti, quello che pretende di insegnare alle persone il loro
mestierie NON sono io!
Io, il mio mestiere, lo conosco molto bene!
E, visto che si era chiesto un aiuto in un campo che, modestamente, per
motivi di lavoro e' la mia specializzazione, mi sono sentito di darlo.
Fine!


 complessità globale della soluzione.
Scusa ma 50 MTA a cosa servono ??? =)
Io presso un ISP (discretamente grosso) ho installato un cluster con 2 
server (4xOpteron DC 16GB su SAN) che è in grado tranquillamente di 
saturare i 155Mb a dispozione per il traffico SMTP/IMAP/POP.

 saturare i 155Mb a dispozione per il traffico SMTP/IMAP/POP.
Vero, se fai relay e basta[1].
Ma se sugli MX ti attendi di fare analisi AS/AV (in particolare in
pre-queue) molto aggressiva, non è la banda, il problema, ma le risorse
di memoria e CPU, che saturano molto più facilmente...
In queste condizioni, soprattutto, hai il problema che introduci una
latenza nelle comunicazioni (dovuta all'analisi), il che aumenta la
concorrenzialità delle richieste da soddisfare, il che aumenta il
carico, il che rallenta l'analisi, il che aumenta la latenza, ecc...
Quindi in queste condizioni è preferibile avere più macchine piccole che
non poche macchine grosse, dato che la scalabilità esterna (due mail?
una per macchina!) è lineare, mentre quella interna (due mail? una
macchina 2 volte più grossa!) non lo è mai...
Proprio per queste ragioni, poi, queste strutture hanno una resilienza
al flusso in ingresso piuttosto bassa: variazioni di 2x sul flusso
stesso possono portarti facilmente al 4x/6x del carico medio dei
sistemi. Per far fronte, ci si dimensiona su flussi molto più ampi di
quelli effettivamente gestiti (di un ordine di grandezza, circa).
Non che 50 MTA sian la norma, ma conosco almeno una manciata di
strutture che quel numero probabilmente lo superano pure...
[1] Leggevo qualche giorno fa un paper, che tra le altre cose riportava
le statistiche di inoltro verificate da Duchovni per postfix 2.4 e il
suo nuovo scheduer: 150 milioni di mail/giorno su un sistema Opteron
praticamente entry-level. Impressionante... O__o
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGQYIC8THo01J+SBERAsi0AJ9x9gDxg7dJWwZ5Xi4pHg0K7Ui5QwCfdKws
aN88d5cUX6HjrEtojSht9gc=
=+2ad
-----END PGP SIGNATURE-----

 praticamente entry-level. Impressionante... O__o
Lol, uguale a Exchange. :-D

 Lol, uguale a Exchange. :-D
Avrei da raccontarne, al riguardo... :-\
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGQYew8THo01J+SBERAhDtAKDMLqdqNqd8acqG3IKSuX8K+i5C8QCeLmqV
AUoN97crVEl4AlmJNejLiK8=
=lf4N
-----END PGP SIGNATURE-----

 
Racconta, racconta...
Io amo l'horror
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Don't cook tonight -- starve a rat today!

 Io amo l'horror
Off-list, che saremmo OT...
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGQYso8THo01J+SBERAn5dAKCWKaHGpMyzrSCuww/KV7axTbehXQCgoo70
gLNI044oVzd3IG6wZvbYGjE=
=UdDC
-----END PGP SIGNATURE-----

 Ecco! Quello di gestire MailCluster **E'** il mio mestiere!
Mi dispiace, ma se ignori l'uso degli MX come definito dalle RFC, non 
sai fare bene il tuo mestiere.
-- 
Luca Villani        NOC, OpenSailing.org
                     Remove "+settanta" in address for e-mail replies
http://www.opensailing.org
 , il primo Portolano collaborativo online

 quelli effettivamente gestiti (di un ordine di grandezza, circa).
o.O
Terminologia ineccepibile, contenuto interessante, ottima esposizione... 
insomma si puo' dire "... 'sta minchia !!!! " :)
(come risollevare l'attenzione di un topic ormai assurdo)
Rizio

 Ecco! Quello di gestire MailCluster **E'** il mio mestiere!
Direi che è anche quello di Skull, che per "curriculum" su Usenet (cerca su
Google Grups) ha dimostrato di avere le palle cubiche  sull'argomento MTA.
E non voglio nemmeno sapere il curriculum reale, perchè probabilmente il
numero di dimensioni delle palle aumenterebbe esponenzialmente ;D
Insomma, nessuno sta dicendo che tu sia un incompetente, ci mancherebbe,
però neanche tu lo devi dire agli altri (o dire, senza conoscere la
persona, "ne sò più di te perchè è il mio mestiere").
-- 
Vide

 sai fare bene il tuo mestiere.
Non volevo essere cosi' bastardo, ma hai tradotto abbastanza bene il mio
pensiero.


 sai fare bene il tuo mestiere.
Non lo ignoro assolutamente!
Semplicemente dico, per esperienza personale, che e' il modo sbagliato per
gestire un LoadBalancing.
Dico, ma se un LoadBalancing fosse cosi' semplice da implementare, secondo
voi, PERCHE' MAI sarebbero stati fatti questi programmi (KeepAlived,
implmentazioni di CARP, etc.)?
Proprio per dare una sicurezza di funzionamento.
Fine della prima parte, inizio della seconda... (libero sfogo)
Per motivi a me ignoti, pare che questo NG non mi reputi in grado di
gestire un MTA, sebbene abbia fatto solo quello per due anni e mezzo (e il
Provider dove lavoravo aveva un carico giornaliero di E-Mail tra il
TERABYTE e il TERABYTE E MEZZO, mica poco, quindi).
Ritengo di avere un certa esperienza in merito.
La stessa cosa (vedi Post di qualche tempo fa in cui consigliavo una
soluzione completa basata su Exim+Dovecot e tutti a spararmi addosso
perche', secondo voi, Postfix e' piu' semplice da gestire) quando
consiglio, basandomi sull'esperienza alcune programmi rispetto ad altri.
Bene, pare proprio che qui si stia prendendo l'abitudine di catalogare le
persone in base a concetti personali e poi sparare loro addosso
indipendentemente da quanto dicono, spesso con commenti che scadono nel
MOLTO volgare (vedi il post dove si dice che "voglio fare a gara a chi ce
l'ha piu' grosso").
Ora, se non vado troppo errato, l'autore del post ha chiesto un'opinione.
Io ho espresso la mia, forte della mia esperienza in materia.
Altri hanno idee differenti, non c'e' il minimo problema.
Non mi sembra, pero', di aver mai insultato nessuno perche' aveva idee
differenti, cosa che invece e' da tempo che si verifica nei miei confronti
quando esprimo un'opinione "non allineata con il vostro credo".
Signori, mi sono stufato!
Io continuero' a fare cio' che ho fatto finora, scegliendo soluzioni
Software robuste e ben configurabili (e il mio sistema di E-Mail tutt'ora
in funzione conferma che so fare il mio lavoro).
Voi fate quel che vi pare.
Per quanto mi riguarda, mi asterro' dall'offrire la mia opinione in questo
NG, anche quando richiesta.
Saluti


 gestire un MTA
A me non pare e *sicuramente* io non ho mai fatto una simile affermazione.
Io ti ho post dei semplici quesiti:
- rfc2821 dice cazzate quando afferma
"If there are multiple destinations with the same preference
and there is no clear reason to favor one (e.g., by recognition of an
easily-reached address), then the sender-SMTP MUST randomize them to
spread the load across multiple mail exchangers for a specific
organization."?
- Hai qualche case study sulla inaffidabilità di una soluzione con più
MX a pari priorità?
- Come puoi affarmare che introdurre un sistema di director per
bilanciare il carico non aumenta la complessità di un sistema?
Nulla di offensivo, a mio avviso.
(Per la cronaca, sono *anni* che uso keepalived in altri contesti.)

 l'ha piu' grosso").
Questo proprio no: tu hai detto una cosa sbagliata e io ti ho corretto.
Se non sei in grado di ragionare su quello che ti ho scritto, dimostri 
*veramente* di non saper fare il tuo lavoro.
P.S.: non ti dico dove lavoro e quale lavoro faccio, googlando un po' 
sui newsgroup dovresti trovarlo, se ti interessa.


 Fine della prima parte, dove hai imparato la lezione numero 1: non rompere i coglioni a Villo mentre sta bestemmiando con un DBMS server. 
Questo -mi pare di rammentare- capita di frequente... <g>
[1] Perlomeno, irrilevante per la trasmissione in sč, ma non sui tempi
di transito. Questi, a loro volta, creano coda dal lato del mittente,
mentre non fanno nulla dal lato del destinatario. Sugli MX, che devono
ricevere da altri, chissenefrega. Per relay interno, da un tier
all'altro, č altra cosa...
[2] Dirň di piů: alcuni *grossi* ISP ( >50.000.000 mailbox) inseriscono
*apposta* record MX che puntano a IP dove non risponde nulla, perchč dŕ
alcuni vantaggi nella gestione dello spam... Quindi figuriamoci quanto
sposta il problema avere balancing/HA sugli MX...
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGQcLa8THo01J+SBERAvAZAJ9k+iqJ2PkQlmvT34f78kM1Wq2LkgCfUX8Q
0C6vitr8Whmr+S7oEy0q1qY=
=7Po8
-----END PGP SIGNATURE-----

 Questo -mi pare di rammentare- capita di frequente... <g>
*TACI!!!* :-(


 Off-list, che saremmo OT...
Ho visto OT ben peggiori e meno istruttivi... :)
Enrico
P.S. se non si fosse capito, per me puoi postare qui

 NG, anche quando richiesta.
Non mi pare che lo sia mai stata né penso che lo sarà dati i presupposti
Aufwiederseen.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 E' la dura vita del sistemista.
Tre righe che condensano il nostro lavoro (purtroppo).
-- 
Vide

 Tre righe che condensano il nostro lavoro (purtroppo).
Vi capita mai che vi rompano le palle mentre cercate informazioni (IRC,
ng, web...) sul come configurare qualcosa?
Enrico

 ng, web...) sul come configurare qualcosa?
No, per fortuna no. Il mio responsabile diretto è sistemista pure lui e sa
come funziona :)
-- 
Vide

 quello che hai descritto?
E' tutto corretto quello che dici, però ci sono due osservazioni utili a
spaccare il capello in quattro :) :
1) il server SMTP mittente accoda la posta solo se la risoluzione del record
MX ha avuto successo, altrimenti la butta via. Questo non ha a che fare con
l'alta affidabilità del server di posta in sè, ma nella progettazione di una
soluzione complessiva devi occuparti quantomeno di un'altra alta
affidabilità, quella del server DNS. Quindi non è esattamente vero che il
servizio SMTP è stato pensato per essere intrinsecamente asincrono come tu
dici;
2) Se il server SMTP destinazione non risponde, il mittente ritenta l'invio,
ma lo ritenta non certo immediatamente, userà un qualche tipo di back-off.
Per cui il ripristino di un server di posta implica che passerà del tempo
prima che la posta in attesa sui mittenti venga consegnata;
Tutto questo ha delle implicazioni: anche se io e te sappiamo che la posta
in genere non va persa, i mittenti e sopratutto i destinatari cominciano ad
agitarsi se la mail non è arrivata, possibilmente prima che parte, e questo
richiede comunque di gestire la cosa. In base alla struttura che si ha, tra
ricevere n-mila ticket di disperati che vanno rassicurati uno per uno (e
almeno una frazione penserà di aver comunque perso la posta, e rimarrà
delusa dalla occasionale interruzione del servizio) e spendere soldi e
risorse per un'alta affidabilità, bhè non è detto quale sia il bilanciamento
(gioco di parole) migliore. Purtroppo della pila protocollare fanno parte
pure gli utenti :)
-- 
Per rispondermi, sostituisci a nomecognome il mio nome e cognome
To reply me, substitute nomecognome with my real name and surname

 uso di piu' MX per bilanciare il carico, usw.) danno SEMPRE problemi,
Però sono due soluzioni alquanto diverse: usare una tecnica round robin a
livello di DNS è utile solo per quella parte di richieste che provengono da
client di cui tu puoi controllare tutta la catena di cache dei DNS (quindi
per un mail server con una componente significativa di posta generata da
interni per interni), mentre usare più MX è già più plausibile (anche se poi
il problema di consolidare server distinti in un'unica casella di posta va
pure affrontato).
Certo che la cosa migliore è scomporre funzionalmente il server di posta in
più sotto server specializzati.


 prima che la posta in attesa sui mittenti venga consegnata;
Quale parte di "record MX multipli" ti è sfuggita?
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGSCwu8THo01J+SBERAmmwAJ446xuymb/nKbbdXkUIWbwzUiSfEACeLHs/
JmyaYxqWIGx4j82GcJ93F7I=
=s4tO
-----END PGP SIGNATURE-----

   distinti e quindi l'email risulterà non consegnabile.
Questo è vero, ma lo puoi mitigare tramite un adeguato feedback dai
singoli nodi al bilanciatore (non che sia sempre semplice farlo).
In ogni caso, anche qualora si usi un bilanciatore, è sempre
consigliabile avere più di un record MX, anche a costo di farli puntare
tutti sullo stesso pool.
In tale scenario, le probabilità che il mittente incorra nel problema
durante tutto il "run di consegna", in presenza di F macchine con
problemi, è data da
(F/N)^M
dove N è il numero di mailserver/nodi del pool su cui avviene il
bilanciamento, ed M il numero di record MX pubblicati.
Ancora una nota sulla pari priorità degli MX.
Molti mailserver (credo, e spero, tutti quelli di concezione più
recente) interpretano due MX di pari priorità come il fallback uno
dell'altro.
Ovvero, se ho due record MX con priorità 10, denominati A e B, il server
mittente si collega prima ad A, e se va in errore transiente passa da sè
su B.
Altri sistemi, più vecchi, invece, non lo fanno, e fanno un tentativo di
fallback solamente qualora esista un record MX con priorità maggiore.
Questo significa che una configurazione del DNS tipo
@	IN	MX	10 a
@	IN	MX	10 b
farà sì che, ammettendo che A non funzioni correttamente mentre B sì, i
primi sistemi riusciranno nella consegna mentre i secondi no
(rimetteranno in coda e ritenteranno, con nuovamente il 50% delle
possibilità di fallire).
Come detto per i record in bilanciamento, avere...
@	IN	MX	10 a
@	IN	MX	10 b
@	IN	MX	20 a
@	IN	MX	20 b
...riduce le probabilità di fallimento, secondo la formuletta
precedentemente indicata, al 25% (per non riuscire nella consegna
dovrebbe incorrere nel record "A" in entrambi i tentativi, quello
rivolto alla priorità 10 e quello per la 20).
Se si vuole avere la piena garanzia di consegna al primo run anche per
questi sistemi "scrausi", è evidentemente sufficiente avere...
@	IN	MX	10 a
@	IN	MX	10 b
@	IN	MX	20 a
@	IN	MX	21 b
...che ottiene lo scopo, pur mantenendo un bilanciamento di 50-50 dei
due mailserver (almeno per quanto concerne i mittenti "leciti": lo
spamware, come detto, si comporta diversamente, ed andrà in linea di
massima a caricare di più l'MX con priorità più alta).
Aloha.
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGSEOq8THo01J+SBERAjVsAJ9GbeU2wre17JDjhCwWdjd5bJ2uiQCglMzO
OUpvsoYLdasIAyTK7cFiS0g=
=fqxY
-----END PGP SIGNATURE-----

 agitarsi se la mail non è arrivata,
scusa la domanda: se la mail non arriva a causa di un /errore/ del server
di destinazione (tutto questo discorso verte su questo), perchè
l'agitazione del destinatario dovrebbe essere un *tuo* problema? Peraltro,
se il /loro/ server è down, probabilmente avranno problemi a contattarti.
se il problema ipotizzato è sul lato /tuo/, quale vantaggio porta avere
un sistema di HA invece di un dominio, due MX, due server?

 un sistema di HA invece di un dominio, due MX, due server?
Quale svantaggio porta?


 Quale parte di "record MX multipli" ti è sfuggita?
Continuo a non capire perchè l'uso di una soluzione ad alta affidabilità a
livello di server (perchè l'alta affidabilità a livello di storage immagino
sia sottintesa) ti sia così sgradevole. 


 livello di storage immagino sia sottintesa) ti sia così sgradevole. 
Sistemeresti cortesemente il tuo charset?
-- 
*** Hi! I'm a .signature Virus ! Copy me
    to your signature to help me spreading! ***
http://www.neodigital2k.com

 sia sottintesa) ti sia cos� sgradevole. 
Non ho mai detto che mi sia sgradevole...
Quello che dico (e che argomento) è che non è la manna, e che anzi, se
fatta "ciecamente" (ovvera come *unica* soluzione per la continuità
della ricezione) dà problemi peggiori della "pura" ridondanza nativa
attraverso l'uso di MX multipli.
Se poi si fa uso di MX multipli, che puntano a macchine che sono poste
in ridondanza tra loro, non ci vedo assolutamente nulla di male... Anzi,
ben venga.
Vedi altro post in stesso thread...
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGSXfA8THo01J+SBERAl9AAJ9aAQQp0rsktDeq42STxaDpI00C4ACeK7Sf
lBiMxoKI9/R514Z0w3fCuJ0=
=Sf/4
-----END PGP SIGNATURE-----

 Sistemeresti cortesemente il tuo charset?
Guarda, non è che io non ci provi, ma tra slrn, Fedora 6 e gnome terminal
non c'è dialogo.


 In altre parole: lavorare e' quasi impossibile...
ma che tipo di problemi hai avuto?
Io ne avevo solo 2 in DNS round-robin (piccolo ISP, diciamo circa 10.000 
caselle e-mail) ma non avevo nessun tipo di problema...
Ciao
Manuel

 Quale svantaggio porta?
Un aumento del costo.
A fronte di questo svantaggio - che non è piccolo - quale vantaggio offre
il tuo sistema?

 
Esiste , basta che definisci piu' IP per un solo record A.
Il problema e' che e' il client (quindi il browser) a non accorgersi
quando l'ip verso il quale viene "rediretto" attraverso la risoluzione
dns e' giu o meno .
Infatti ci sono alcune soluzioni di load balancing che si basano
sul round robin dns per bilanciare le connessioni HTTP.
Quando si verifica un fault semplicemente viene rimosso l'ip
"fallato" dal record DNS relativo .
Senza contare che basterebbe heartbeat per riassegnare quell'ip
ad un altra macchina del cluster, bypassando anche il problema
del time-to-live del record dns.
Ciao.

 Esiste , basta che definisci piu' IP per un solo record A.
Questa è una ridondanza fatta dal DNS, lavorando sui record forniti in
risposta alle interrogazioni, con quel che ne consegue (e che
giustamente noti).
La situazione SMTP (e quella ipotizzata) è completamente client-side,
invece, poichè il DNS -come il resto della struttura lato server- nulla
sa o è tenuta a sapere riguardo ad eventuali down di parti della
struttura: è chi si connette a gestire la cosa, in funzione dei dati che
gli vengono forniti.
E' cosa *molto* diversa...
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGSrkI8THo01J+SBERAi+5AJwPASDmxtzcZN4mQx0LQv6A4u5CQACfTINB
HHx1bgGDeHeCUCXCA5EvLG8=
=hRvd
-----END PGP SIGNATURE-----

 il tuo sistema?
Che usi il record MX per avere affidabilita' in senso geografico (se li hai,
ha senso che i due MX siano su reti diverse) e usi l'alta affidabilita' per
avere affidabilita' in ambito locale. 


 affidabilita' hai due server
Perchè, almeno un paio di director non li vogliamo mettere?
O intendi limitare il tutto ad un vrrp direttamente sui due server?
Perchè davvero vorrei che qualcuno mi dia una dimostrazione oeggettiva
del fatto che avere un'architettura del genere:
192.168.1.1---|
              |
              |MX1 VIP 192.168.1.3
              |
192.168.1.2---|
  10.10.1.1---|
              |
              |MX2 VIP 10.10.1.3
              |
  10.10.1.2---|
è più affidabile rispetto a
192.168.1.1 MX1
192.168.1.2 MX2
10.10.1.1 MX3
10.10.1.2 MX4

 10.10.1.2 MX4
Dipende da come si usano le priorità in un caso e nell'altro, ma la tua
osservazione è corretta, IMHO.
Se ad esempio nella prima configurazione si fa uso di...
@ 	IN	MX	10	MX1-VIP
@ 	IN	MX	10	MX2-VIP
...e nella seconda che disegni imposti invece priorità del tipo...
@ 	IN	MX	10	MX1
@ 	IN	MX	10	MX3
@ 	IN	MX	20	MX2
@ 	IN	MX	20	MX4
...hai anzi che la seconda soluzione è più ridondante della prima:
il failover tra gli MX viene fatto dal client, il quale lo esegue anche
nel caso di errori interni (temporanei o meno) dell'MX che ha cercato di
contattare, e anche *per la singola mail*.
Questo, nel primo caso, è vero solamente per quei server mittenti che
trattano le pari-priorità come mutui failover (già accennato in altro
ramo del thread), ma non per tutti gli altri, mentre nel secondo caso è
valido per qualunque server mittente, dato che tutte le implementazioni
sono tenute a trattare come fallback le priorità maggiori.
Questo si ha perchè VRRP (o quant'altro) effettua il failover solo nel
caso in cui ci sono problemi ben più "seri" del problema temporaneo (che
può essere ad es una temporanea saturazione
della_memoria/dei_processi/di_quello_che_ti_pare).
E anche qualora intervenisse, le mail che erano in fase di consegna
durante il failover vengono comunque reintrodotte in coda dal mittente,
e attendono un tempo non-noto prima di venire ri-consegnate...
Dal che si potrebbe desumere che la soluzione con gli MX garantisce una
continuità di servizio superiore...
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGTB1+8THo01J+SBERAvgjAJ9d6p1xbDnTsC6ucQm3j9zNztZKqACgiqUF
GsaqtAITFrAeFD17bb73br8=
=mWvc
-----END PGP SIGNATURE-----

 continuità di servizio superiore...
Si potrebbe, infatti.
Aspetto di ascoltare anche l'altra campana: magari ci è sfuggito qualcosa...