单实例Amazon EC2

Question

我们在单个EC2服务器实例上运行一个轻量级的Web应用程序，这对我们的需求很好，但我们想知道如果它发生故障就会监视并重新启动它。

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

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

感谢。

Answer 1

您应该查看puppet及其对AWS的支持。我还会查看RightScale AWS library以及有关starting a server with the RightScale scripts的帖子。您也可以在web serving with EC2上找到这篇文章。我做了类似的事情，但是没有外部监控，节点会自动监控并在不再需要时关闭，然后当有更多工作要做时，新的节点会启动。

Answer 2

几点：

您必须必须备份您的Amazon EBS卷。

他们声称“更好”的可靠性，但不是100％，而且它比S3的“12 9”耐用性高出几个数量级。 S3耐久性＆gt;＆gt; EBS耐用性。这是事实。 EBS支持“快照”功能，可以高效地将存储备份到S3。此外，使用EBS快照，您只需支付压缩的增量，这通常远远小于分配的卷大小。在另一个生活中，我向那些“认为”EBS“持久”的小客户发送了丢失量的电子邮件，并且用一个关键任务数据库的唯一副本来信任它......这令人心碎。

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

你提到的设计路径相对来说不合适;这就是为什么......许多公司运行冗余的“热备用”实例，其中第二个实例被启动并运行。这允许在“故障”（可能是硬件或软件）的情况下快速故障转移（秒）。 “冷备用”的问题在于，让机器保持最新状态并准备好在旧机箱停止的位置进行拾取是比较困难的。更重要的是，验证备件是否能够成功恢复您的生产服务是非常棘手的。硬件比未经测试的软件系统更可靠。测试测试。如果您尚未测试故障转移，则无效。

启动新EBS实例的简单自动化很容易，接近于微不足道。它只是一个调用the EC2 command-line tools的单行bash脚本。什么是棘手的是最重要的是一切。这样的解决方案几乎意味着完全100％自动化的部署过程。这些都是您的应用程序特有的。你的应用程序可以下载它需要运行的所有数据（也许它存储在S3中？）。您今天可以杀死您的实例并使用0.000手动设置/安装步骤启动新实例吗？

或者，您可能正在谈论我将称之为 “重新实施EBS卷”的方案 ：

1. EC2盒死（根卷为EBS）
2. 强制分离EBS卷
3. 使用EBS卷启动新的EC2实例

... 主要是 有效。陷阱：

• 无法防止EBS故障，无论是总体积丢失还是可用性丢失
• 假设一切正常
，恢复时间为O（分钟）
• 您的服务需要配置为自动重启。如果Nginx没有运行，那么将盒子带回来是没有用的。
• 您的DNS路由或其他服务或其他任何需要改变IP地址的服务。这可以通过ElasticIP解决。
• 您的主机SSH密钥是如何处理的？同名，新的主机密钥可以在主机密钥更改发出强烈警告时破坏基于SSH的自动化。
• 我没有这方面的证据（除了看到它发生一次），但我相信EC2 / EBS _already_does_this_会自动启动来自EBS实例

同样，这里的难点在于你的盘子。您今天可以停止生产服务并在新实例上提供可靠的服务吗？如果是这样，故事的EC2部分是really really easy。

Answer 3

作为一个侧面点：

  

我们所有的用户数据都在弹性存储上，因此我们不会担心丢失任何内容。

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

Answer 4

您可以使用最小/最大/所需数量为1的自动缩放组。将实例放在ELB后面，并使ELB健康节点计数触发自动缩放组。这允许您通过cloudwatch和ELB运行状况检查进行内置监控。任何时候出现问题，实例都会被自动缩放服务替换。

Answer 5

1. 如果您没有选中“防止意外终止”，您可能需要这样做。
2. 即使您已为您的实例禁用了“详细监控”，您仍应看到可以配置警报的实例的“StatusCheckFailed”指标（在CloudWatch控制台中）
3. 您的应用程序（托管在其他服务器中）应接收警报并使用AWS API（或CLI）启动实例

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