Comment construire un système Postfix haute disponibilité?

Je dois 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 descend à un moment donné, le serveur miroir prend sa place, gère les nouveaux courriers entrants et, lorsque le serveur de messagerie revient, il le mettra à jour avec les nouveaux e-mails et le retour C'est le contrôle de gérer les nouveaux courriers entrants.

Les serveurs de messagerie seront hébergés dans différents endroits (c.-à-d. Maindomain.com, themirrorsite.com).

L'obtention d'un serveur de sauvegarde simple ne semble pas trop difficile:

  • Http://beginlinux.com/blog/2010/03/backup-mx-with-postfix/
  • Http://www.postfix.org/STANDARD_CONFIGURATION_README.html#backup
  • Http://www.linuxmail.info/postfix-backup-mx/

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 tiendra que les e-mails reçus pendant que le serveur principal est en panne).

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

    4 Solutions collect form web for “Comment construire un système Postfix haute disponibilité?”

    Le résultat que vous voulez atteindre et la façon dont vous avez décidé de le faire sont des choses très différentes. Pour être franc, ce que vous voulez implémenter est une mauvaise idée, et si vous parvenez à 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 sur la mise en œuvre et que vous n'avez pas décrit l'utilité de votre environnement ni ce que vous essayez de réaliser réellement. Ne faites pas cela, vous obtiendrez de meilleurs résultats ici si vous "montrez votre travail".

    Permettez-moi de proposer quelques scénarios, cependant, pour vous donner un aperçu de ce qui est possible, pratique et utile:

    • S'assurer qu'aucun courrier ne se perde : (je ne pense pas que c'est ce dont vous avez besoin, car la documentation dont vous vous référez couvre adéquatement). Tout ce que vous voulez avoir ici, c'est l'assurance que, peu importe la durée de téléchargement de votre courrier et de votre infrastructure de gestion , Vous ne renverrez aucun courrier, et vous pouvez contrôler quand la livraison est effectuée. Pour cela, une sauvegarde hors-site simple "simple" fonctionnera de manière adéquate. Je dis "simple" parce que vous devez reproduire beaucoup de données sur la sauvegarde (toutes les logiques anti-spam, informations d'utilisateur / alias valides afin que vous puissiez renvoyer correctement le courrier non valide au moment du SMTP, ce genre de chose), mais tout est scriptable , Automatisable, et relativement peu applicable avec un peu de soin. Tant que vous disposez d'un disque suffisant pour mettre en file d'attente tout le courrier, vous pouvez faire une file d'attente pendant des semaines ou des mois jusqu'à ce que votre site principal revienne et que vous piquez le MX de sauvegarde et qu'il décharge une charge métrique de courrier dans votre infrastructure de messagerie et vos utilisateurs Allez "aaaaaaahhh!"
    • Assurer la disponibilité complète du système de messagerie : Cela ressemble à ce que vous voulez, mais ce n'est pas simple ou joli. Fondamentalement, vous voulez pouvoir fournir un service de messagerie "complet" à votre base d'utilisateurs en cas d'échec complet du site. En principe, cela est réellement impossible, car la réplication n'est pas instantanée, mais vous pouvez atteindre au moins un niveau de fiabilité raisonnable. Cependant, le bit difficile n'est pas le MTA; C'est le magasin de messagerie lui-même. Vous devrez trouver une manière de reproduire toutes les opérations de stockage de courrier (nouvelle livraison de courrier, modifications d'état de message, effacement) dans le deuxième site en temps quasi réel – et faites-le dans les deux sens, en fonction du site en direct . Vous pouvez prendre l'option à bas prix, d'un rsync périodique (avec le risque que tout ce qui a été fait depuis le dernier rsync soit disparu pour toujours si vous avez besoin de basculement), ou utilisez différentes techniques de réplication au niveau du fichier ou du bloc pour essayer de garder les choses en place -sync en temps quasi-réel (réduisant la quantité de perte de données en échange d'une configuration et d'un fonctionnement beaucoup plus complexes). Certains systèmes de messagerie ont un support pour une sorte de réplication intégrée, ce qui peut faciliter la vie. Ensuite, il y a toute la question de l'échec, et comment faites-vous cela, puis échouez, 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 fait un peu plus tard Casser quoi que ce soit …

    Fondamentalement, cette dernière option est pénible et ennuyeuse. Ma préférence personnelle, si vous pouvez vous en sortir (et vous seriez surpris de voir combien de temps vous pouvez) est de mettre tous vos oeufs dans un panier, après vous assurer que vous avez un panier très bon et robuste (ingénierie de systèmes appropriée ), En gardant un stock de patchs et d'outils de panier en main (en mettant l'accent sur la récupération élevée ), et en veillant à ce que les gens sachent que de temps en temps, quelques œufs pourraient se briser et vous êtes vraiment désolé, mais la vie n'est pas parfaite (Ne pas faire des garanties SLA qui ne sont pas raisonnables).

    Il y a des moments où vous avez besoin d'une disponibilité ultra haute, et j'ai construit des systèmes qui l'assurent, mais ils ne sont pas simples et, dans de nombreux cas, ils ne sont pas rentables, c'est ce que nous recherchons. Oui, HA est cool et sexy, et vous obtenez geek cred pour construire une monstruosité de complexité imposante, mais nous ne sommes pas là pour abattre nos egos. Nous sommes là pour offrir de la valeur commerciale et je suis désolé, mais un cluster de courrier multi-site hautement disponible de Rube Goldberg est susceptible de fournir autant de valeur qu'un service de messagerie simple et robuste et les "nous" occasionnels Je suis désolé pour la panne du courrier, nous aurons les systèmes en une heure, n'hésitez pas à nous faire un café et un muffin sur nous ".

    Vous pouvez le faire par un basculement DNS MX + un système de réplication de données.

    Pour le basculement MX: deux serveurs de messagerie, besoin d'aide pour la configuration dns pour la sauvegarde

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

    – $

    J'ai utilisé dbmail pour obtenir une solution similaire. Dbmail stocke tout le courrier électronique 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.

    Ce que vous voulez, c'est la réplication Postfix, que je ne pense pas que Postfix supporte en natif. La solution que j'ai utilisée d'autres personnes consiste à répliquer les fichiers de données Postfix entre les serveurs utilisant un système de fichiers distribué.

    Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de réseau.