我们正在单个 EC2 服务器实例上运行一个轻量级 Web 应用程序，这可以满足我们的需求，但我们想知道是否监控它并在它出现故障时重新启动它。
我们有一个单独的非亚马逊服务器，我们想用它来监控 EC2 并在必要时启动一个新实例并关闭旧实例。我们所有的用户数据都在 Elastic Storage 上，所以我们不太担心会丢失任何东西。
我想知道是否有人有以这种方式使用 EC2 的经验，尤其是自动化启动新实例的过程？我们从头开始创建东西没有问题，但似乎它应该是一个已解决的问题，所以我想知道是否有人有任何提示、链接、脚本、教程等要分享。
谢谢。
【问题讨论】：
标签： amazon-ec2 amazon-web-services
您应该看看puppet 及其对AWS 的支持。我还会查看RightScale AWS library 以及关于starting a server with the RightScale scripts 的这篇文章。您可能还会发现web serving with EC2 上的这篇文章很有用。我做了类似的事情，但没有外部监控，节点监控自己并在不再需要时关闭，然后当有更多工作要做时会启动一个新的。
【讨论】：
几点：
他们声称“更好”的可靠性，但不是 100%，而且它比 S3 的“12 个 9”的耐用性低了几个数量级。 S3 耐用性 >> EBS 耐用性。这是事实。 EBS 支持“快照”功能，该功能可以高效且增量地备份您的存储到 S3。此外，使用 EBS 快照，您只需为压缩增量付费，这通常远小于分配的卷大小。在另一种生活中，我曾向像您这样“认为”EBS 是“耐用”并信任它的唯一任务关键数据库副本的小型客户发送大量丢失的电子邮件……这令人心碎。
你提到的设计路径是相对未走过的；这就是为什么...许多公司运行冗余的“热备用”实例，其中第二个实例已启动并运行。这允许在“故障”（可能是硬件或软件）的情况下快速故障转移（秒）。 “冷备用”的问题在于，很难让机器保持最新状态并准备好从旧盒子停止的地方拿起。更重要的是，验证备件是否能够成功恢复您的生产服务是很棘手的。硬件比未经测试的软件系统更可靠。测试测试测试。如果您没有测试过故障转移，它就不起作用。
启动新 EBS 实例的简单自动化非常简单，几乎是微不足道的。这只是一个调用the EC2 command-line tools 的单行bash 脚本。棘手的是最重要的一切。这样的解决方案几乎意味着完全 100% 自动化的部署过程。这都是特定于您的应用程序的。您的应用程序能否拉取运行所需的所有数据（可能存储在 S3 中？）。您今天可以杀死您的实例并使用 0.000 个手动设置/安装步骤启动一个新实例吗？
或者，您可能正在谈论我称之为“重新实例化 EBS 卷”的场景：
...大部分都有效。问题：
同样，这里最难的部分在你的盘子里。您今天可以停止生产服务并在新实例上可靠地启动它吗？如果是这样，故事的 EC2 部分是 really really easy。
【讨论】：
顺便说一句：
我们所有的用户数据都在 Elastic Storage 上，所以我们不太担心丢失任何东西。
如果您还没有这样做，我强烈建议您定期将 EBS（弹性块存储）快照到 S3。
【讨论】：
您可以使用最小/最大/所需数量为 1 的自动缩放组。将实例放在 ELB 后面，并让自动缩放组由 ELB 健康节点计数触发。这允许您通过 cloudwatch 和 ELB 健康检查进行内置监控。每当出现问题时，实例都会被自动缩放服务替换。
【讨论】：
由于您已防止意外终止，因此您永远不需要生成新实例。
【讨论】：