Le résultat que vous souhaitez atteindre et la manière dont vous avez décidé de le faire sont des choses très différentes. Pour être franc, ce que vous voulez mettre en œuvre est une mauvaise idée, et si vous pouvez en quelque sorte réussir à le faire fonctionner, cela ne fonctionnera pas très longtemps (ou très bien).
Ce qui rend cette question difficile à répondre, c'est que vous avez sauté directement à la mise en œuvre et que vous n'avez décrit rien d' utile à propos de votre environnement ou de ce que vous essayez réellement de réaliser. S'il vous plaît ne faites pas cela, vous obtiendrez de bien meilleurs résultats ici si vous "montrez votre travail".
Permettez-moi de poser quelques scénarios, cependant, pour vous donner un aperçu de ce qui est possible, pratique et utile:
- S'assurer qu'aucun courrier n'est perdu: (Je ne pense pas que c'est ce dont vous avez besoin, car la documentation à laquelle vous vous référez le couvre de manière adéquate) Tout ce que vous voulez avoir ici est l'assurance que quelle que soit la durée de votre infrastructure de distribution et de gestion du courrier, vous ne le ferez pas renvoyez n'importe quel courrier et vous pouvez contrôler le moment de la livraison. Pour cela, une «simple» sauvegarde hors site MX fonctionnera correctement. Je dis "simple" parce que vous devez répliquer beaucoup de données sur la sauvegarde (toute la logique anti-spam, les informations utilisateur / alias valides pour que vous puissiez correctement renvoyer les courriers invalides au moment SMTP, ce genre de chose), mais tout est scriptable , automatisable et assez trivialement implémentable avec un peu de soin. Tant que vous avez suffisamment de disque pour mettre en file d'attente tout le courrier,
- Assurer la disponibilité complète du système de messagerie : Il semble que c'est ce que vous voulez, mais ce n'est pas simple ou joli. Fondamentalement, vous souhaitez pouvoir fournir un service de messagerie "complet" à votre base d'utilisateurs en cas de défaillance complète du site. En principe, cela est en fait impossible, car la réplication n'est pas instantanée, mais vous pouvez au moins atteindre un niveau de fiabilité raisonnable. Mais le plus difficile n'est pas le MTA; c'est la boutique de courrier elle-même. Vous devrez trouver un moyen de répliquer toutes les opérations de stockage du courrier (nouvelle distribution du courrier, changements d'état des messages, suppression) vers le deuxième site en temps quasi réel - et le faire dans les deux sens, en fonction du site en ligne . Vous pouvez prendre l'option bon marché, d'une rsync périodique (avec le risque que tout ce qui a été fait depuis la dernière rsync soit parti pour toujourssi vous avez besoin d'un basculement), ou optez pour diverses techniques de réplication au niveau des fichiers ou des blocs pour essayer de garder les choses synchronisées en temps quasi réel (en réduisant la quantité de perte de données en échange d'une configuration et d'un fonctionnement beaucoup plus compliqués) . Certains systèmes de messagerie prennent en charge une sorte de réplication intégrée, ce qui peut vous faciliter la vie. Ensuite, il y a tout le problème du basculement, et comment faites-vous, puis le retour , ce qui est encore plus difficile, et enfin vous devez le tester périodiquement, pour vous assurer que la mise à niveau du système d'exploitation que vous avez effectuée il y a quelque temps n'a pas casser quoi que ce soit ...
Fondamentalement, cette dernière option est douloureuse et ennuyeuse. Ma préférence personnelle, si vous pouvez vous en tirer (et vous seriez surpris de voir combien de fois vous le pouvez) est de mettre tous vos œufs dans le même panier, après vous être assuré d'avoir un très bon panier solide (ingénierie des systèmes appropriée ), en gardant un stock de paniers et d'outils à portée de main (en se concentrant sur la haute récupérabilité ), et en s'assurant que les gens savent que de temps en temps, quelques œufs peuvent se casser et vous êtes vraiment désolé mais la vie n'est pas parfaite (ne faites pas de garanties SLA qui ne sont pas raisonnables).
Il y a des moments où vous avez besoin d'une ultra haute disponibilité, et j'ai construit des systèmes qui le garantissent, mais ils ne sont pas simples, et dans de nombreux cas, ils ne sont pas rentables, ce pour quoi nous sommes ici. Oui, HA est cool et sexy, et vous obtenez un crédit de geek pour construire une monstruosité imposante de complexité, mais nous ne sommes pas ici pour caresser nos ego. Nous sommes là pour offrir une valeur commerciale, et je suis désolé, mais un cluster de messagerie multisite hautement disponible de Rube Goldberg n'est pas susceptible de fournir autant de valeur qu'un service de messagerie simple et robuste et le «nous» occasionnel désolé pour la panne de courrier, nous aurons les systèmes de retour dans une heure, n'hésitez pas à prendre un café et un muffin sur nous ".