在管理自己的集群（即不使用/支付 Amazon Autoscale、Rightscale、Scalr 等）的人们中，您如何管理 EC2 上的实例并处理（例如）故障转移？我想知道大多数人是否最终会根据 EC2 API 编写自己的大量脚本，正如我所怀疑的那样。
这当然是我们的方法：开发我们自己的基于 Python Boto 的监控/重启守护程序，该守护程序在异地运行，监听来自我们实例的 UDP 保持活动。发生故障时，我们会快照卷、注册映像、启动新实例、删除旧卷等。
时不时地，当我们破解我们的脚本时，我认为一定有一些开源工具已经可以处理这些问题，而且它们没有（比如）Scalr 的限制，但我总是从 Google 上空手而归。（像 Scalr 这样的东西在支持的软件集/版本/配置方面非常有限，并且有专门的、在我看来很麻烦的方法来操作这些设置。）
此外，Linux-HA/Pacemaker 生态系统（Heartbeat、ldirectord 等）听起来像不太适合 EC2（但后来我发现这- 尽管我不确定这是否真的是一个高质量的解决方案）。
答案1
好吧，我并不是想陈述显而易见的事实，但总体想法是将这种复杂性推入亚马逊管理的服务中。
因此，在前端，您可以使用 Amazon Elastic Load Balancing (ELB) 来提供高可用性负载平衡。在后端，您可以使用 Amazon Relational Database Service（托管 MySQL）、SimpleDB 和 S3 进行存储。所有这些都由 Amazon 管理，并包含某种高可用性/故障转移处理。
这通常会留下您的 Web 应用程序服务器以及您可能使用的任何不太常见的服务器类型（渲染服务器、自行安装的 NoSQL 数据存储等）。
通常，使用 ELB 内置的运行状况检查，Web 应用服务器就可以很好地处理。当一个 Web 应用服务器发生故障时，您可以接受性能略有下降，或者持续提供比您需要的 +1 台服务器。或者，如果您的配置很简单，那么当 Web 应用服务器发生故障时，ELB 和 Cloudwatch 可以自动为您生成一个新的 Web 应用服务器。
您自己的自定义服务器则是另一回事。对于这些服务器，您确实需要自己处理，并且需要使用应用程序内置方法，或者使用自定义脚本/开源 HA 工具将某些东西拼凑在一起。
购买 Rightscale 的解决方案可能太贵了。但如果您需要高可用性，那么价格较低的 Amazon 工具（如 ELB、基本 CloudWatch 警报（现在免费提供 5 分钟的分辨率）或 AutoScale）非常值得。
答案2
RightScale 有一些很棒的文章关于如何在 EC2 上自动执行故障转移。虽然其中大部分内容向您展示了如何使用 RightScale 本身执行此操作，但这些原则是通用的，可能对任何考虑如何在 EC2 上设置故障转移架构的人都有帮助。
答案3
您描述的问题（HA、监控自定义服务器、“管道胶带”服务）通常由 PaaS 提供商处理。Rightscale 和 Scalr 已在之前的回答中提及，还有其他不错的选择（请参阅此处了解一些 PaaS 选项：
https://stackoverflow.com/questions/9542784/looking-for-paas-providers-recommendations）
您应该考虑哪一个提供商最能满足您的需求。
备注：我在 cloudify 工作，一家开源 PaaS 提供商。
答案4
您在两台服务器上都安装了心跳，将弹性 IP 附加到“活动”服务器，您配置一个脚本来通过启动 API 请求来获取弹性 IP，从而执行故障转移，一旦“备用”服务器获得弹性 IP（大约需要 30-60 秒），它就可以成为主/活动服务器。
我没有具体信息可以在这里提供。