我正在做一些研究，以确定如何最低成本地创build高可用性解决scheme来部署rails / mysql web应用程序。
我已经提出了一个可能性，并且正在寻找关于它的反馈和其他想法或可能性。
我希望我的主要生产实例是位于同一地点的服务器。 这大大增加了我可以获得每美元的托pipe功率量，同时仍然有一个非常安全和可靠的托pipe环境。 我find了几个适合这个账单的当地公司。 我并不完全擅长，但是我可以build立和架设服务器，而且我是一个有能力的pipe理员，所以我可以在没有更多更好的pipe理服务的情况下生活。
我不希望购买完整的具有相同规格的灾难恢复/故障转移实例 – 对于一件事情，它应该在不同的地区，这意味着它必须是专用的或虚拟的，因为我无法进入数据中心; 并且因此比我的同位置实例贵得多，并且很可能不会被使用。
所以我的想法是使用EC2进行故障转移，并将实例保持在离线状态，直到需要时为止。 所以，故障切换不会是瞬间的，但新的服务器将在几分钟内上线。 尽pipe如此，我仍然需要一些在线的实例来充当MySQL复制从属目标。
但是我不确定pipe理故障切换的最佳方式。 我有两个想法：一个是使用TZO-HA ，它可以用于端口testing和故障切换，当然，它只是在DNS级别，这意味着直到人们的DNScaching过期才会出现中断。
所以我的想法是把一个低端的EC2实例，可以运行HAProxy。 默认的configuration是弹性的IP到这个实例代理我的co-located服务器。 有几种不同的方式来自动执行实际的故障切换，如果它几乎是瞬间发生在同位应用程序服务器或HAProxy中。
当然缺点是这会为每个请求创build一个额外的跳跃。 而且，我最终会通过EC2投入大量带宽，这就引出了为什么不直接使用它们的问题，因为带宽占我估计的托pipe成本的很大一部分。
我的计划有什么问题？ 任何其他的想法？
我认为AWS允许您设置自己的负载平衡器（ELB），这也将允许您设置自动规则，以根据负载需求启动更多AMI实例（并在之后再次closures）。
我自己并没有实现，虽然我一直在寻找它。 我确实find了设置负载平衡LAMP堆栈的绝佳指南： http : //www.lindstromconsulting.com/node/7 （自从写入这个版面之后，AWS布局有所改变，但仍然非常有用）。
（编辑：链接已经移动，现在我看： http : //bit.ly/aaasX2 ）