Как построить систему высокой доступности Postfix?

12

Мне нужно настроить удаленное зеркало для постфиксного сервера (где содержимое обоих почтовых серверов должно быть одинаковым в любое время).

Идея состоит в том, что если в какой-то момент основной сервер выйдет из строя, зеркальный сервер займет его место, будет управлять новыми входящими письмами, а когда почтовый сервер снова появится, он обновит его новыми письмами и вернет это контроль для управления новыми входящими письмами.

Почтовые серверы будут размещаться в разных местах (например, maindomain.com, themirrorsite.com).

Получение простого резервного сервера не кажется слишком сложным:

Но проблема в том, что эта конфигурация не сделает резервный сайт полным зеркалом основного почтового сервера (он будет хранить только электронные письма, полученные, когда основной сервер не работает).

Есть ли способ добиться требуемой конфигурации?

VanHackman
источник

Ответы:

22

Результат, которого вы хотите достичь, и способ, которым вы решили это сделать, - это очень разные вещи. Если говорить прямо, то, что вы хотите реализовать, - плохая идея, и если вам удастся каким-то образом заставить ее работать, она не будет работать очень долго (или очень хорошо).

Что затрудняет ответ на этот вопрос, так это то, что вы прыгнули прямо к реализации и не описали ничего полезного о вашей среде или о том, чего вы пытаетесь достичь на самом деле. Пожалуйста, не делайте этого, вы получите намного лучшие результаты, если «покажете свою работу».

Позвольте мне изложить несколько сценариев, чтобы дать вам представление о том, что возможно, практично и полезно:

  • Обеспечение того, чтобы почта не терялась: (Я не думаю, что это то, что вам нужно, так как документация, на которую вы ссылаетесь, охватывает это должным образом) Все, что вам нужно здесь, - это уверенность в том, что независимо от того, как долго работает ваша инфраструктура доставки и управления почтой, вы не будете отказаться от любой почты, и вы можете контролировать, когда доставка будет произведена. Для этого «простая» внешняя резервная копия MX будет работать адекватно. Я говорю «просто», потому что вам нужно реплицировать большое количество данных в резервную копию (вся логика защиты от спама, действительная информация о пользователе / ​​псевдониме, чтобы вы могли правильно отсылать недопустимую почту во время SMTP, такого рода вещи), но все это доступно для сценариев , автоматизируемый и довольно тривиально реализуемый с небольшой осторожностью. Пока у вас достаточно диска, чтобы поставить в очередь всю почту,
  • Обеспечение полной доступности почтовой системы . Звучит так, будто вы этого хотите, но это не просто и не красиво. По сути, вы хотите иметь возможность предоставлять «полный» почтовый сервис вашей базе пользователей в случае полного отказа сайта. В принципе, это на самом деле невозможно, потому что репликация не происходит мгновенно, но вы можете достичь как минимум разумного уровня надежности. Трудная часть не MTA, хотя; это сам почтовый магазин. Вам нужно будет найти способ репликации всех операций хранения почты (доставка новой почты, изменения состояния сообщения, удаление) на второй сайт практически в режиме реального времени - и сделать это обоими способами, в зависимости от того, какой сайт работает , Вы можете выбрать дешевый вариант периодической rsync (с риском, что все, что было сделано с момента последней rsync, пропало навсегдаесли вам нужно переключиться при отказе), или используйте различные методы репликации на уровне файлов или блоков, чтобы попытаться поддерживать синхронизацию практически в реальном времени (уменьшая потери данных в обмен на значительно более сложную конфигурацию и работу) , Некоторые почтовые системы поддерживают встроенную репликацию, которая может облегчить жизнь. Затем возникает проблема с переключением при сбое, и как вы это делаете, а затем с возвратом , что еще сложнее, и, наконец, вы должны периодически проверять его, чтобы убедиться, что обновление ОС, которое вы делали некоторое время назад, не было сломать что-нибудь ...

По сути, последний вариант является болезненным и раздражающим. Мое личное предпочтение, если вы можете сойти с рук (и вы будете удивлены, как часто вы можете), это положить все яйца в одну корзину, убедившись, что у вас действительно хорошая, крепкая корзина (правильное проектирование систем). ), имея под рукой запас корзин с патчами и инструментами (с акцентом на высокую восстанавливаемость ) и следя за тем, чтобы люди знали, что иногда могут разбиться несколько яиц, и вы действительно сожалеете, но жизнь не идеальна (не делайте SLA гарантии, которые не являются разумными).

Есть моменты, когда вам нужна сверхвысокая доступность, и я создавал системы, которые это обеспечивают, но они не простые, и во многих случаях они не являются экономически эффективными, для чего мы здесь. Да, ХА - это круто и сексуально, и вы получаете заслуженное уважение за то, что создали чудовищную сложность, но мы здесь не для того, чтобы погладить наше эго. Мы здесь для того, чтобы приносить пользу для бизнеса, и я извиняюсь, но высокодоступный многосайтовый почтовый кластер Rube Goldberg вряд ли будет обеспечивать такую ​​же ценность, как простой, надежный почтовый сервис и случайное «мы» Приносим извинения за перебои с почтой, мы вернем системы через час, пожалуйста, не стесняйтесь, чтобы выпить кофе и кекс на нас ".

ombble
источник
2
Не мог бы сказать это лучше сам.
voretaq7
4
Извините, что я могу предложить только один +1
mailq
Я думаю, что NAS в основном решает проблему хранения и синхронизации почты, не так ли? Особенно, если ваш почтовый магазин становится Большим, и вы размещаете почту для множества доменов.
Эрни
Нет, NAS составляет около 5% от всей проблемы, и это плохо влияет на производительность и масштабируемость.
Уомбл
1

Вы можете добиться этого с помощью восстановления DNS DNS + системы репликации данных.

Для восстановления после отказа MX: двум почтовым серверам нужна помощь с настройкой DNS для резервного

Для репликации данных: http://www.drbd.org/docs/install/

- $

Sparx
источник
Будет ли работать drbd с серверами, которые не находятся в одной локальной сети? Основной сервер и сервер отработки отказа должны взаимодействовать только через Интернет, поэтому я не уверен, будет ли это работать в этом случае.
VanHackman
DRBD имеет собственный прокси-продукт, который значительно улучшает репликацию WAN; это не дешево, и это не гарантирует, что все будет обновляться везде.
Уомбл
1

Я использовал dbmail для реализации аналогичного решения. dbmail хранит всю электронную почту в базе данных. Вы можете настроить репликацию базы данных, чтобы убедиться, что ваши электронные письма также хранятся в удаленном месте. Это усложняет управление почтовой системой, поскольку вам приходится управлять базой данных и электронной почтой.

Явор Шахпасов
источник
0

Вам нужна репликация Postfix, которую я не думаю, что Postfix изначально поддерживает. Решение, которое я видел у других людей, - это репликация файлов данных Postfix между серверами с использованием распределенной файловой системы.

Klox
источник
3
Зеркальное отражение Postfix является простым. Но это не проблема. Сложно то, как синхронизировать почтовое хранилище (mbox или Maildir). Хранение почты в NFS для IMAP практически невозможно и приводит к возникновению единой точки отказа.
mailq