Yan*_*ang 13 failover heartbeat amazon-ec2 scalr amazon-elastic-ip
在管理自己集群的人中（即不使用/支付 Amazon Autoscale、Rightscale、Scalr 等），您如何管理 EC2 上的实例并处理（例如）故障转移？我想知道是否大多数人最终会像我怀疑的那样针对 EC2 API 编写自己的大量脚本。
这当然是我们的方法：启动我们自己的基于 Python Boto 的监控/重启守护进程，该守护进程在异地运行，从我们的实例中监听 UDP 保持活动。失败时，我们对卷进行快照、注册映像、启动新实例、删除旧卷等。
每隔一段时间，当对我们的脚本进行黑客攻击时，我认为必须有一些开源工具已经可以处理这些问题，并且没有（比如）Scalr 的限制，但我总是从谷歌回来空手而归。（像 Scalr 这样的东西在支持的软件集/版本/配置方面非常有限，并且有专门的和 IMO 繁琐的方法来操纵这些设置。）
此外，Linux-HA/Pacemaker 生态系统（Heartbeat、ldirectord 等）听起来并不适合 EC2。（但后来我发现了这一点——尽管我不确定这是否真的是一个高质量的解决方案）。
好吧，我并不是要说显而易见的事情，但总体思路是将这种复杂性推入由 Amazon 管理的服务中。
因此，在前端，您将使用 Amazon Elastic Load Balancing (ELB) 来提供高度可用的负载平衡。在后端，您使用 Amazon Relational Database Service（托管 MySQL）、SimpleDB 和 S3 进行存储。所有这些都由亚马逊管理，并包含某种高可用性/故障转移处理。
这通常会留下您的 Web 应用程序服务器以及您可能使用的任何不太常见的服务器类型（渲染服务器、自行安装的 NoSQL 数据存储等）。
Webapp 服务器通常可以通过 ELB 内置的健康检查得到很好的处理。当一个 webapp 服务器关闭时，你可以接受一个小的性能下降，或者始终比你需要的多供应 +1 个服务器。或者，如果您的配置很简单，那么当 webapp 服务器出现故障时，ELB 和 Cloudwatch 可以自动为您生成一个新的 webapp 服务器。
您自己的自定义服务器是另一回事。对于这些，确实如此，您必须靠自己，并且需要使用应用程序内置方法，或者将某些东西与自定义脚本/开源 HA 工具结合在一起。
购买 Rightscale 的解决方案可能太贵了。但是，如果您需要高可用性，那么价格较低的 Amazon 工具（例如 ELB、基本 CloudWatch 警报（现在可免费提供 5 分钟分辨率）或 AutoScale 等）非常值得。