Назад | Перейти на главную страницу

Почтовые шлюзы с балансировкой нагрузки

В настоящее время я пытаюсь найти способ балансировки нагрузки на наших 4 почтовых шлюзах (запущенная программа очистки почты). Мне удалось запустить HAProxy и использовать режим tcp для балансировки нагрузки без проблем. Единственная реальная проблема заключается в том, что мой исходный IP-адрес - это всегда сервер HAProxy, поэтому некоторые из моих проверок почтового фильтра сейчас бесполезны, потому что я не могу проверить, приходит ли почта от известного плохого ретранслятора.

Есть ли у них какое-либо программное обеспечение FLOSS, которое можно было бы использовать для решения этого типа ситуаций? Я знаю, что HAProxy имеет такую ​​возможность, если у меня есть почтовые шлюзы, которые используют его в качестве шлюза по умолчанию, компилируют некоторые дополнительные модули и настраивают iptables. Я просто не хочу идти по этому пути, если мне просто не хватает более простого решения.

SMTP имеет встроенную балансировку нагрузки с использованием DNS в циклическом режиме. Это хорошо работает для большинства целей. Если вам этого недостаточно, вам придется создать свою собственную настройку, что является непростой задачей. Поэтому, если вам это действительно не нужно, я буду придерживаться того, что доступно и широко используется.

Я предполагаю, что ваши почтовые серверы (MTA) находятся в одном домене (например, example.org), в этом случае создайте запись MX для каждого отдельного MTA с тем же приоритетом. Использование одного и того же приоритета гарантирует, что каждый сервер проверяется циклически, в противном случае первым всегда проверяется сервер с наивысшим приоритетом (меньшее число) (в случае MTA, которые не сломаны, спамеры любят попадать на сервер с самым низким приоритетом. думая, что это может быть резервный сервер с более низкой спецификацией):

example.org.    IN  MX  10  mx1.example.org.
example.org.    IN  MX  10  mx2.example.org.
example.org.    IN  MX  10  mx3.example.org.
example.org.    IN  MX  10  mx4.example.org.

Конечно, убедитесь, что каждый mx * может быть разрешен:

example.org.    IN      A       192.168.2.1
mx1     IN      A       192.168.2.2
mx2     IN      A       192.168.2.3
mx3     IN      A       192.168.2.4
mx4     IN      A       192.168.2.5

Если вы хотите также использовать DNS для «балансировки нагрузки» MTA, чтобы ваши пользователи могли отправлять электронную почту, вы можете настроить DNS таким образом. Давайте назовем ваш исходящий сервер smtp.example.org и попросим ваших пользователей отправлять на него электронную почту. Я заключил «балансировку нагрузки» в кавычки, потому что это не предотвратит подключения к серверу, который не работает в MTA, используя записи MX. В этом случае пользователь должен повторить попытку один или несколько раз, чтобы попасть на рабочий сервер.

smtp    IN      A       192.168.2.2
smtp    IN      A       192.168.2.3
smtp    IN      A       192.168.2.4
smtp    IN      A       192.168.2.5

Это грубое решение, потому что в зависимости от системы и настроек пользователя они могут продолжать попытки поразить только один IP. Но, по крайней мере, это не «не для всех», и вы всегда можете направить их на рабочий сервер. Кроме того, если сервер постоянно не работает, вы можете удалить его из DNS и после кэширования, что должно предотвратить попадание на него ваших пользователей. В этом случае haproxy может оказаться не таким уж плохим решением.

Мы делаем это, просто используя Виртуальный сервер Linux, которое уже несколько лет является частью стандартного ядра Linux.

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

ipvsadm -A -t 192.168.0.3:25 -s wrr
ipvsadm -a -t 192.168.0.3:25 -r 192.168.0.8:25 -g -w 100
ipvsadm -a -t 192.168.0.3:25 -r 192.168.0.9:25 -g -w 100

(где 192.168.0.3 - ваш "служебный IP" или "виртуальный IP" а 192.168.0.8 и 192.168.0.9 - ваши "настоящие серверы")

Самое главное знать - способ работы. Эта установка использует "режим шлюза", в котором источник и место назначения пакетов не меняются. Но это имеет некоторые последствия. В виртуальный ip должен быть настроен на всех "реальных серверах". Но это может привести к условиям гонки ARP, которых следует избегать намеренно:

  • Либо ваши «настоящие серверы» находятся за балансировщиком нагрузки в отдельной локальной сети
  • ИЛИ вы настраиваете свои реальные серверы так, чтобы они не отвечали на ARP для виртуального адреса
  • ИЛИ вы маршрутизируете виртуальный IP-адрес непосредственно на балансировщик нагрузки, чтобы он не передавался по ARP для

Возможно - режим маскарадинга немного проще настроить.

И еще один намек: вы можете захотеть использовать оставайся живым который устанавливает ipvsadm, контролирует ваш почтовый сервер на предмет доступности и, возможно, обеспечивает резервирование для самого балансировщика нагрузки с помощью VRRP.

Мы используем ipvs для балансировки нагрузки DNS 15k CPS.

(*) по крайней мере, в debian это называется так, но поиск ipvs должен быть легким