如何构建高可用性Postfix系统?

如何构建高可用性Postfix系统?

我需要为 Postfix 服务器设置远程镜像(其中两个邮件服务器的内容在任何时候都应该相同)。

这个想法是,如果主服务器在某个时候宕机,镜像服务器将取代它,管理新收到的邮件,当电子邮件服务器再次启动时,它将使用新电子邮件进行更新,并将管理新收到邮件的控制权返回给它。

邮件服务器将托管在不同的地方(即 maindomain.com、themirrorsite.com)。

获取一个简单的备份服务器看起来并不太难:

但问题是,这种配置不会使备份站点成为主邮件服务器的完整镜像(它只会保存主服务器关闭时收到的电子邮件)。

有没有办法实现所需的配置?

答案1

你想要实现的结果和你决定实现结果的方式是截然不同的两码事。坦率地说,你想要实现的是一个坏主意,即使你能设法让它奏效,它也不会持续很长时间(或效果不佳)。

这个问题很难回答,因为你直接跳到了实现,而没有描述任何事物对您的环境或您实际想要实现的目标很有用。请不要这样做,如果您“展示您的工作”,您将在这里获得更好的结果。

不过,让我假设几个场景,让您体验一下什么是可能的、实用的和有用的:

  • 确保邮件不丢失:(我不认为这是您所需要的,因为您引用的文档已经充分涵盖了这一点)您在这里想要的只是确保无论您的邮件传递和管理基础设施停机多长时间,您都不会退回任何邮件,并且您可以控制何时进行传递。为此,“简单”的异地备份 MX 就足够了。我说“简单”是因为您需要将大量数据复制到备份中(所有反垃圾邮件逻辑、有效的用户/别名信息,以便您可以在 SMTP 时正确退回无效邮件,诸如此类),但所有这些都是可编写脚本、可自动化的,并且只要稍加注意,就可以相当轻松地实现。只要您有足够的磁盘来排队所有邮件,您就可以排队数周或数月,直到您的主站点恢复,然后您戳一下备份 MX,它会将大量邮件转储到您的邮件基础设施中,您的用户就会“啊啊啊啊啊!”
  • 确保邮件系统全面可用:这听起来像是您想要的,但它并不简单也不美观。基本上,您希望能够在站点完全故障的情况下为您的用户群提供“完整”的邮件服务。原则上,这实际上是不可能的,因为复制不是即时的,但您至少可以达到合理的可靠性水平。不过,困难的部分不是 MTA;而是邮件存储本身。您需要想出一种方法,将所有邮件存储操作(新邮件传递、邮件状态更改、删除)近乎实时地复制到第二个站点——并且双向执行,具体取决于哪个站点处于活动状态。您可以选择便宜的选项,即定期 rsync(但存在自上次 rsync 以来所做的任何操作都丢失的风险)永远如果您需要故障转移,或者采用各种文件或块级复制技术,尝试近乎实时地保持同步(减少数据丢失量,但配置和操作要复杂得多)。一些邮件系统支持某种内置复制,这可以让生活更轻松。然后就是故障转移的问题,以及如何做到这一点,然后失败后退,这又变得更加困难,最后你必须定期进行测试,以确保你之前进行的操作系统升级没有破坏任何东西……

基本上,后一种选择既痛苦又烦人。我个人的偏好是,如果你能侥幸逃脱(你会惊讶于你经常能做到),把所有的鸡蛋都放在一个篮子里,确保你有一个真正好的、坚固的篮子(适当的系统工程),手头上备有篮子补丁和工具(专注于高恢复性),并确保人们知道偶尔会有几个鸡蛋被打破,你真的很抱歉,但生活并不完美(不要做出不合理的 SLA 保证)。

有时您需要超高可用性,我构建了可以确保这一点的系统,但它们并不简单,而且在很多情况下它们并不具有成本效益,而这正是我们存在的目的。是的,HA 很酷很性感,而且您可以因构建一些复杂的庞然大物而获得极客的赞誉,但我们不是来满足自我的。我们来这里是为了提供商业价值,很抱歉,但 Rube Goldberg 高可用性多站点邮件集群不太可能提供与简单、强大的邮件服务和偶尔的“我们对邮件中断感到抱歉,我们将在一小时内恢复系统,请随意享用我们的咖啡和松饼”公告一样多的价值。

答案2

您可以通过 MX DNS 故障转移 + 数据复制系统实现此目的。

对于 MX 故障转移:两台邮件服务器,需要帮助配置备份的 DNS

对于数据复制:http://www.drbd.org/docs/install/

-$

答案3

我用过数据库邮件实现类似的解决方案。dbmail 将所有电子邮件存储在数据库中。您可以设置数据库复制,以确保您的电子邮件也存储在远程位置。它使邮件系统的管理更加复杂,因为您必须管理数据库和电子邮件。

答案4

您需要的是 Postfix 复制,但我认为 Postfix 本身并不支持此功能。我看到其他人使用的解决方案是使用分布式文件系统在服务器之间复制 Postfix 数据文件。

相关内容