针对AWS上电子邮件服务器的最佳故障切换策略，以确保高可用性

我们有我们的电子邮件服务器托pipe在AWS上。上个星期，亚马逊在东海岸地区出现故障，导致我们的服务器和其他许多服务器一起中断。

我们现在要实施故障转移策略，以便如果邮件服务器再次变得不可用，那么我们可以简单地切换到另一个区域中的另一个邮件服务器，并且用户可以继续发送和接收邮件以及仍然可以访问他们现有的邮件项目。

显然，定期备份邮件并不是一个足够好的解决scheme，因为有一个连续不断的传入和传出电子邮件被写入磁盘。

我们正在使用Windows 2008 Server并运行Mailenable Enterprise。 MailEnable的configuration（例如，用户帐户，密码等）存储在邮件服务器上的SQL Server数据库中。

我们正在考虑以下解决scheme：

使用像tntdrive这样的工具将S3存储装载为Windows驱动器来存储消息。与EBS存储（仅限于单个可用区域）不同，S3存储在可用区域间可用，即使单个区域发生故障，我们的存储也可用。
我们每天拍摄邮件服务器的快照并将其复制到S3。
在邮件服务器发生故障的情况下，我们从快照创build邮件服务器的一个新实例（这意味着configuration更改（如更改密码或创build快照后创build的新用户帐户）将不会包含在内，但我们可以接受那风险）
我们将包含消息的S3存储作为驱动器安装在新服务器上。
我们将邮件服务器的弹性ip切换到新的服务器，并且我们有一个邮件服务器可以再次使用！

这个解决scheme能工作吗与EBS相比，我有点担心S3的延迟和成本（请参阅http://jimliddle.sys-con.com/node/1103438/mobile ）。我们应该考虑一个不同的方法吗？你会推荐不同的亚马逊工具来解决这个问题吗？

您可以克隆另一个EC2实例中的当前邮件服务器，并将其作为备份MX服务器运行。这两个服务器数据库应该与数据库级复制同步，并且磁盘应该与rsync / deltacopy同步。当主服务器发生故障时，发送电子邮件服务器将自动尝试使用辅助MX服务器，用户仍然可以访问新旧电子邮件。当主服务器回来时，备份服务器将再次与主服务器同步最新的电子邮件。