目标是尽可能多地提供冗余，以便我们能够快速从实例故障或任何其他问题中恢复。我们当前运行的 Rails WebApp 的 AWS 设置如下：
- EC2 实例，其中我们有一个初始设置的 AMI。每次更改实例配置时，我们也会创建新的 AMI。
- 代码库、实例用户目录和一些配置文件位于由 EC2 实例挂载的 EBS 卷上（文件每晚进行 rsynced 或符号链接）
- 每周将 EBS 卷完整备份到 S3 存储桶并每晚进行增量备份
- WebApp 使用设置为 10 天可恢复性的 RDS 托管数据库
有人有什么建议可以让这个变得更加强大吗？（我们差点就被抓住了，不想再发生这种事了......）
答案1
您还可以运行多个 EC2 实例并在它们之间进行负载平衡。如果正常运行时间尚未达到 99.99%，那么这应该会使您的正常运行时间超过 99.99%。据我所知，单个 EC2 实例的正常运行时间约为 99.95% 或 99.5% 以上，对它们进行负载平衡，其正常运行时间将飙升至 99.99% 或更高，通常会达到 99.999% 以上的范围。无论哪种方式，这也可能有帮助...
...另一个想法是让 EC2 保持可热插拔。也可能让 RDS 存储库也保持可热插拔，以防生产副本损坏或出现类似问题。
...还有另一个想法，保留一个使用 mySQL 启动的 EC2 实例，如果 RDS 副本出现问题，则作为最后的紧急副本。
...最后一个想法是，在二级云（例如 Rackspace 或其他 RoR 友好型云主机）中运行热插拔或负载平衡 - 或热插拔和负载平衡的云托管服务。
希望有所帮助。:)
答案2
我赞同你的观点，Adron。如果你需要更高的可用性，那么负载平衡就是最佳选择。
建议设置
- 获取托管 DNS 服务，例如域名系统或者动态网络。[我们的想法是获得一个允许以极低的 TTL 进行循环负载平衡的全球服务。API 是顺利集成的加分项。)
- 两个弹性负载均衡器 (ELB) 用于故障转移。
- 它们背后是一系列应用服务器。
当然，ELB 需要对配置的应用服务器进行健康检查。
如果 ELB 不适合你（例如吞吐量有限或最终一致性太高 ;-)），那么请查看哈普罗西。这是一款很棒的软件。您必须在两个单独的实例上运行它——我会选择c1.medium或m1.small类型的实例。
监控与警报
监控所有组件的设置也很重要。不仅是为了警报，也是为了容量规划。
我建议你看看AWS 云监控或者类似的服务服务器密度。这取决于您想在内部构建多少，例如，进入 ServerDensity 并设置监控和警报更容易，而 CloudWatch 需要另一种解决方案来提取数据并进行分析，然后将其输入警报中。