Il risultato che vuoi ottenere e il modo in cui hai deciso di farlo, sono cose molto diverse. Ad essere sinceri, quello che vuoi implementare è una cattiva idea, e se riesci in qualche modo a farlo funzionare, non funzionerà per molto tempo (o molto bene).
Ciò che rende difficile rispondere a questa domanda è che sei passato direttamente all'implementazione e non hai descritto nulla di utile sul tuo ambiente o su ciò che stai cercando di ottenere. Per favore, non farlo, otterrai risultati molto migliori qui se "mostri il tuo lavoro".
Permettimi di ipotizzare un paio di scenari, per darti un assaggio di ciò che è possibile, pratico e utile:
- Garantire che la posta non vada persa: (Non penso che questo sia ciò di cui hai bisogno, poiché la documentazione a cui ti riferisci lo copre adeguatamente) Tutto ciò che vuoi avere qui è la certezza che, indipendentemente da quanto tempo la tua infrastruttura di consegna e gestione della posta è inattiva, non lo farai rimbalza qualsiasi posta e puoi controllare quando viene effettuata la consegna. Per questo, un "semplice" MX off-site di backup funzionerà adeguatamente. Dico "semplice" perché è necessario replicare molti dati nel backup (tutta la logica anti-spam, informazioni valide su utente / alias in modo da poter far rimbalzare correttamente la posta non valida al momento SMTP, quel genere di cose), ma è tutto programmabile , automatizzabile e piuttosto banalmente implementabile con un po 'di attenzione. Finché hai abbastanza disco per mettere in coda tutta la posta,
- Garantire la piena disponibilità del sistema di posta : sembra che questo sia quello che vuoi, ma non è semplice o carino. Fondamentalmente, si desidera essere in grado di fornire un servizio di posta "completo" alla base utenti in caso di un errore del sito completo. In linea di principio, questo è in realtà impossibile, poiché la replica non è istantanea, ma è possibile raggiungere almeno un ragionevole livello di affidabilità. La parte difficile non è l'MTA, però; è lo stesso negozio di posta. Dovrai trovare un modo per replicare tutte le operazioni di archiviazione della posta (consegna della nuova posta, modifiche allo stato del messaggio, cancellazione) sul secondo sito in tempo quasi reale - e farlo in entrambi i modi, a seconda di quale sito è attivo . Puoi prendere l'opzione economica di un periodico rsync (con il rischio che tutto ciò che è stato fatto dall'ultimo rsync sia andato per semprese è necessario eseguire il failover) o utilizzare varie tecniche di replica a livello di file o di blocco per provare a mantenere le cose sincronizzate quasi in tempo reale (riducendo la quantità di perdita di dati in cambio di operazioni e configurazioni significativamente più complicate) . Alcuni sistemi di posta elettronica supportano una sorta di replica integrata, che può semplificare la vita. Poi c'è tutta la questione di failover, e come si fa a farlo, e quindi in mancanza di nuovo , che è più duro ancora una volta, e, infine, hai avuto modo di testare periodicamente, al fine di garantire che l'aggiornamento del sistema operativo che hai fatto un po 'indietro no rompere qualsiasi cosa ...
Fondamentalmente, quest'ultima opzione è dolorosa e fastidiosa. La mia preferenza personale, se riesci a cavartela (e rimarrai sorpreso quanto spesso puoi) è di mettere tutte le uova in un cestino, dopo esserti assicurato di avere un cestino davvero buono e robusto (corretta ingegneria dei sistemi ), tenendo a portata di mano una scorta di toppe e strumenti per il basket (concentrandosi sull'alta recuperabilità ) e assicurando che le persone sappiano che ogni tanto alcune uova potrebbero rompersi e ti dispiace davvero ma la vita non è perfetta (non fare garanzie SLA che non siano ragionevoli).
Ci sono momenti in cui hai bisogno di una disponibilità ultra elevata e ho creato sistemi che lo garantiscono, ma non sono semplici e in molti casi non sono convenienti, ed è per questo che siamo qui. Sì, l'HA è bello e sexy, e ottieni credito geek per aver costruito una mostruosa mostruosità di complessità, ma non siamo qui per accarezzare il nostro ego. Siamo qui per offrire valore al business, e mi dispiace, ma un cluster di posta multi-sito ad alta disponibilità di Rube Goldberg non è in grado di fornire lo stesso valore di un servizio di posta semplice e robusto e il "noi" occasionale ci scusiamo per l'interruzione della posta, avremo i sistemi tra un'ora, non esitate a prendere un caffè e un muffin su di noi "annuncio.