单实例 Amazon EC2

Question

我们正在单个EC2服务器实例上运行一个轻量级Web应用程序，这对我们的需求来说很好，但是如果它崩溃了，我们想知道如何监控并重新启动它。

我们有一个单独的非亚马逊服务器，我们希望用它来监视EC2，并在必要时启动新的实例并关闭旧的实例。我们所有的用户数据都存储在弹性存储中，因此我们不太担心数据丢失。

我想知道是否有人有使用EC2以这种方式的经验，特别是自动化启动新实例的过程？我们可以从头开始创建一些东西，但似乎这应该是一个解决的问题，所以我想知道是否有任何提示、链接、脚本、教程等可以分享。

谢谢。

- Graham

Answer 1

您应该看一下 puppet 及其支持的AWS。我还会看一下RightScale AWS library，以及这篇关于使用 RightScale 脚本启动服务器的文章。您可能还会发现这篇关于在 EC2 上进行 Web 托管的文章很有用。我已经做过类似的事情，但没有外部监控，节点自行监测并在不再需要时关闭，然后在稍后需要更多工作时重新启动新的。

- carson

Answer 2

一些要点：

您必须一定要备份您的Amazon EBS卷。

他们声称拥有更好的可靠性，但并非100％，并且与S3的“12 9”的耐用性相差几个数量级。 S3的耐用性>> EBS的耐用性。 这是事实。 EBS支持“快照”功能，可以有效地增量地将存储备份到S3。 此外，使用EBS快照，您只需支付压缩的增量，通常远远小于分配的卷大小。 在另一个生活中，我曾向像您这样的小客户发送过关于丢失卷的电子邮件，他们“认为”EBS是“耐用”的，信任它是使命关键数据库的唯一副本......这让人心碎。

您的问题：自动启动新实例

您提到的设计路径相对较少走过；以下是原因...许多公司运行冗余的“热备份”实例，第二个实例已经引导并正在运行。这样可以在“失败”（可能是硬件或软件故障）时快速切换（几秒钟）。使用“冷备份”的问题在于难以保持机器更新并准备好接替旧盒子的工作。更重要的是，验证备用机能够成功恢复生产服务非常棘手。硬件比未经测试的软件系统更可靠。测试测试测试。如果您没有测试过故障转移，它将无法正常工作。

简单的自动化启动新的EBS实例很容易，几乎可以说微不足道。只需一个调用EC2命令行工具的一行bash脚本即可。困难的是在此基础上完成所有其他内容。这种解决方案几乎意味着完全100％的自动化部署过程。而且这完全取决于您的应用程序。您的应用程序能否获取运行所需的所有数据（可能存储在S3中）？您今天可以杀死实例并启动一个新实例，而不需要0.000个手动设置/安装步骤吗？

或者，您可能正在谈论我称之为“重新实例化EBS卷”的场景：

1. EC2实例崩溃（根卷是EBS）。 2. 强制分离EBS卷。 3. 使用EBS卷启动新的EC2实例。

这在大多数情况下都可以工作。但需要注意以下几点：

- 不能保护EBS故障，无论是完全损失还是可用性损失。 - 恢复时间为O（分钟），假设一切正常。 - 您的服务需要配置自动重启。如果Nginx没有运行，将无济于事。 - 您的DNS路由或其他服务必须接受IP地址的更改。这可以使用弹性IP解决。 - 您的主机SSH密钥如何处理？同名，新主机密钥可能会在获取强烈警告的主机密钥更改时中断基于SSH的自动化。 - 我没有证据证明这一点（除了看到它发生过一次），但我相信EC2 / EBS已经自动为从EBS启动的实例执行此操作。

再次强调，这里最困难的部分在你的手头。你能否今天停止生产服务，并可靠地将其迁移到新实例上？如果可以的话，EC2 部分就非常容易。

- Dave Dopson

Answer 3

作为一个附带的观点：

我们所有的用户数据都存储在弹性存储器上，所以我们并不太担心会失去任何数据。

如果您还没有这样做，我强烈建议定期将您的弹性块存储（EBS）快照到S3。

- user55400

Answer 4

1. 如果您尚未勾选“防止意外终止”，建议您这样做。
2. 即使您已为实例禁用“详细监控”，您仍应该看到实例的“StatusCheckFailed”指标，您可以在其中配置警报（在CloudWatch仪表板中）。
3. 您的应用程序（托管在不同的服务器上）应接收警报并使用AWS API（或CLI）启动实例。

由于您已经防止了意外终止，因此您永远不需要生成新的实例。

- nitarshs

Answer 5

您可以使用1个最小/最大/期望数量的自动缩放组。将实例放在ELB后面，并通过ELB健康节点计数触发自动缩放组。这使您可以通过CloudWatch和ELB健康检查进行内置监视。每当出现问题时，实例将被自动缩放服务替换。

- chadneal