Comment construire un système Postfix haute disponibilité?

12

J'ai besoin de configurer un miroir distant pour un serveur postfix (où le contenu des deux serveurs de messagerie devrait être le même à tout moment).

L'idée est que si le serveur principal tombe en panne à un moment donné, le serveur miroir prendra sa place, gérera les nouveaux e-mails entrants, et lorsque le serveur de messagerie réapparaîtra, il le mettra à jour avec les nouveaux e-mails et reviendra c'est le contrôle pour gérer les nouveaux mails entrants.

Les serveurs de messagerie seront hébergés à différents endroits (par exemple maindomain.com, themirrorsite.com).

Obtenir un simple serveur de sauvegarde ne semble pas trop difficile:

Mais le problème est que cette configuration ne ferait pas du site de sauvegarde un miroir complet du serveur de messagerie principal (il ne conservera que les e-mails reçus pendant que le serveur principal est en panne).

Existe-t-il un moyen d'obtenir la configuration requise?

VanHackman
la source

Réponses:

22

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 ".

womble
la source
2
Je n'aurais pas dit mieux moi même.
voretaq7
4
Désolé de ne pouvoir offrir qu'un seul +1
mailq
Je pense qu'un NAS résout essentiellement le problème du stockage et de la synchronisation du courrier, n'est-ce pas? Surtout si votre boutique de messagerie devient volumineuse et que vous hébergez du courrier pour de nombreux domaines.
Ernie
Non, un NAS représente environ 5% de l'ensemble du problème et il nuit à vos performances et à votre évolutivité.
womble
1

Vous pouvez y parvenir par un basculement DNS DNS + un système de réplication de données.

Pour le basculement MX: Deux serveurs de messagerie, ont besoin d'aide pour la configuration DNS pour le serveur de sauvegarde

Pour la réplication des données: http://www.drbd.org/docs/install/

- $

SparX
la source
Est-ce que drbd fonctionnerait avec des serveurs qui ne sont pas dans le même LAN? Le serveur principal et le serveur de basculement ne devraient communiquer que sur Internet, donc je ne sais pas si cela fonctionnera dans ce cas.
VanHackman
DRBD possède un produit proxy propriétaire qui améliore considérablement la réplication WAN; ce n'est pas bon marché et il n'est pas garanti de tout garder à jour partout.
womble
1

J'ai utilisé dbmail pour réaliser une solution similaire. dbmail stocke tous les e-mails dans une base de données. Vous pouvez configurer la réplication de la base de données pour vous assurer que vos e-mails sont également stockés dans l'emplacement distant. Cela rend la gestion du système de messagerie plus compliquée car vous devez gérer la base de données ainsi que le courrier électronique.

Yavor Shahpasov
la source
0

Ce que vous voulez, c'est la réplication de Postfix, que je ne pense pas que Postfix supporte nativement. La solution que j'ai vu d'autres personnes utiliser est la réplication des fichiers de données Postfix entre les serveurs à l'aide d'un système de fichiers distribué.

Klox
la source
3
La mise en miroir de Postfix est la plus simple. Mais ce n'est pas ça le problème. La difficulté est de savoir comment synchroniser le stockage du courrier (mbox ou Maildir). Le stockage de mails sur NFS pour IMAP est presque impossible et conduit à avoir à nouveau un point de défaillance unique.
mailq