![负载平衡邮件网关](https://linux22.com/image/583735/%E8%B4%9F%E8%BD%BD%E5%B9%B3%E8%A1%A1%E9%82%AE%E4%BB%B6%E7%BD%91%E5%85%B3.png)
我目前正在尝试找到一种方法来平衡我们的 4 个邮件网关(运行邮件清理器)。我能够启动 HAProxy 并使用 tcp 模式进行负载平衡,没有任何问题。唯一真正的问题是我的源 IP 始终是 HAProxy 服务器,所以我的一些邮件过滤器检查现在毫无用处,因为我无法检查邮件是否来自已知的坏中继。
有没有 FLOSS 软件可以用来处理这种情况?我知道如果我让邮件网关将其用作默认网关,并编译一些附加模块并配置 iptables,HAProxy 就有这种能力。如果我缺少一个更简单的解决方案,我就不想走这条路。
答案1
我们只需使用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 竞争条件,您应该在设计时避免这种情况:
- 您的“真实服务器”要么位于单独的 LAN 中的负载均衡器后面
- 或者你将真实服务器配置为不回复虚拟地址的 ARP
- 或者,你将虚拟 IP 直接路由到负载均衡器,这样就不会被 ARP 攻击
也许-m- 伪装模式的设置更加容易一些。
还有另一个提示:你可能想使用保持活跃它设置 ipvsadm,监控您的邮件服务器的可达性,并可能使用 VRRP 为负载均衡器本身提供冗余。
我们正在使用 ipvs 来处理 15k CPS DNS 负载平衡。
(*)至少在 debian 中是这样称呼的,但搜索 ipvs 应该很容易
答案2
SMTP 内置了使用 DNS 的负载平衡功能,采用循环方式。这对于大多数用途来说都相当有效。如果这对您来说还不够,您将不得不创建自己的自定义设置,这不是一件容易的事。所以除非您真的需要它,否则我会坚持使用可用且广泛使用的方法。
我假设您的电子邮件服务器 (MTA) 位于同一个域中(例如 example.org),在这种情况下,为每个单独的 MTA 创建一个具有相同优先级的 MX 记录。使用相同的优先级可确保以循环方式尝试每个服务器,否则始终会首先尝试具有最高优先级(较低数字)的服务器(在 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 可能不是一个糟糕的解决方案。