Какова идеальная схема серого списка с несколькими MX в разных местах?
В настоящее время у нас есть два сервера MX в одной физической стойке, они совместно используют одну и ту же базу данных серого списка, и все, кажется, работает хорошо. Два MX имеют разные приоритеты и находятся на двух разных физических серверах, поэтому мы получаем избыточность в случае сбоя одного из двух.
(К сведению, база данных находится на виртуальной машине в избыточном аппаратном кластере: хотя система БД в целом представляет собой единую точку отказа, аппаратное обеспечение, на котором она работает, нет, устраняя большинство возможных режимов сбоев)
Мы хотели бы представить новый (или пару) MX в другом центре данных, чтобы обеспечить полную избыточность систем входящей почты (наши DNS-серверы уже распределены по разным DC), но мы не можем подключить его к тот же самый сервер MySQL, так как это в первую очередь победило бы избыточность.
Как правильно внедрить грейлистинг в такой настройке?
Могу ли я просто позволить каждой локации / группе MX иметь свою собственную базу данных серых списков, или это создаст какие-либо проблемы или неэффективность? Есть ли причина настраивать MX на одном и том же сайте с одинаковым / другим приоритетом или это не имеет значения? (конечно разные сайты всегда будут иметь разные приоритеты)
РЕДАКТИРОВАНИЕ / РАЗЪЯСНЕНИЕ: первые ответы, кажется, предлагают настроить репликацию MySQL (либо ведущую / подчиненную, либо двустороннюю) или объяснить, как это сделать: были там, сделали это. Я могу установить двухстороннюю репликацию MySQL между центрами обработки данных, если мне нужно / нужно.
Мой вопрос был сосредоточен на том, нужно ли мне реплицировать / передавать базу данных серых списков или я могу обойтись без обмена знаниями между различными MX-списками серых списков, а не на том, как реализовать совместное знание.
3 ответа
В худшем случае, если ваш первичный центр обработки данных переходит в автономный режим после начальной попытки доставки, вторичный центр обработки данных вступает во владение, и у него нет записи о первой попытке доставки. Он будет рассматривать последующую попытку доставки как начальную попытку доставки и сообщит ретрансляционному серверу повторить попытку позже.
Поскольку время задержки часто составляет всего 5 минут, это означает, что максимально возможная задержка составляет около 10 минут. Первоначальная доставка за 0 минут, вторая доставка на другой почтовый сервер за 5 минут, а затем окончательная доставка через 10 минут.
Учитывая, что возможны периоды задержки, отличные от 5 минут, наихудший случай - это фактически удвоенная задержка по сравнению с обычной задержкой доставки в случае отказа центра обработки данных.
Если это приемлемо для вас в случае сбоя центра обработки данных, вам не нужно совместно использовать базу данных серых списков. Если это не так, то репликация будет путь.
Я предполагаю, что серый список не слишком смешен и не активен... почему бы не выполнить репликацию главного / подчиненного в базе данных MySQL на удаленный центр данных?
Я бы посоветовал вам использовать репликацию для синхронизации базы данных mysql между обоими местоположениями.
В зависимости от структуры ваших баз данных существует много возможностей, но общая настройка состоит в том, чтобы настроить каждый кластер для создания независимых последовательных ключей и заставить их реплицировать друг друга. Например, в my.cnf:
auto-increment-increment = 5
auto-increment-offset = 1 ( and 2, 3, 4 , 5 on your other clusters )
В случае сбоя каждый кластер локально ведет журнал еще не реплицированных транзакций, так что когда приходит другая сторона, транзакции доставляются.
Редактировать: Хорошо, вам нужно синхронизировать ваши кластеры, иначе вы будете независимо отображать один и тот же IP-адрес на каждом из ваших кластеров, что может на практике умножить время на серый список на количество настроенных вами кластеров. Кстати, почему бы вам не установить одинаковый приоритет MX для всех ваших записей MX?