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

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

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

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

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

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

Бывают случаи, когда вам нужна сверхвысокая доступность, и я создал системы, которые это обеспечивают, но они непростые и во многих случаях нерентабельны, и именно для этого мы здесь. Да, HA - это круто и сексуально, и вы получаете кредит компьютерных фанатов за то, что построили какое-то чудовищное чудовище сложности, но мы здесь не для того, чтобы задеть наше эго. Мы здесь, чтобы приносить пользу для бизнеса, и мне очень жаль, но высокодоступный многосайтовый почтовый кластер Руба Голдберга вряд ли будет иметь такую ​​же ценность, как простая и надежная почтовая служба и случайные «мы» Извините за перерыв в работе почты, мы вернем системы через час, пожалуйста, не стесняйтесь выпить нам кофе и выпить кекс ».

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

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

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

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

- $

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

Я не знаю об обычном подходе к кластеризации, который был бы здесь применим.

Для входящей почты решением будет несколько серверов (активный-активный с одинаковым приоритетом MX).

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

Остается только проблема с помещением почты в очередь на сервере.