使 AWS Spot 实例“持久化”的技巧？答案

【问题标题】：Tricks to make an AWS spot instance "persistent"?使 AWS Spot 实例“持久化”的技巧？
【发布时间】：2013-10-24 19:55:02
【问题描述】：

我的客户将 AWS 用于他的 VPS。他遇到的一件事是，如果现场实例的出价高于他的出价，那么他的实例就会被终止。看起来没什么大不了的，只是 Spot 实例不是持久的，所以每次发生这种情况时我们都必须从图像中恢复。

他希望我做的是编写一些东西，每隔 X 时间检查一次终止的实例，然后自动重新启动它们。更重要的是，他想要某种方式来假装“坚持”。我最好的想法是每隔 Y 时间从每个服务器创建一个映像，然后从该映像启动（如果/当该实例终止时）。

很高兴听到任何其他想法。我想我的问题是，我是否走在正确的轨道上，你们知道任何可能已经存在的解决方案吗？

更新：差不多一年后，我回到这里，发现所有这些精彩的回复，并且对这个话题的关注比我预期的要多得多。以下许多答案虽然内容丰富且很有帮助，但对我的推理提出了质疑。我想说的是，即使在那个时候，我也 100% 同意这不是一个明智的想法，但这是我的客户所要求的，尽管我做了任何尝试，以使事情朝着更好的方向发展。

非常感谢大家的帮助。我确实最终弄清楚了如何做我想要的，并且能够编写一些自动重新启动终止实例的代码。这从来都不是一件容易的事，但当我转向新客户时，它运作良好。

祝你们遇到同样问题的任何人好运，你们正在（可能是通过武力，就像我的情况一样）做一些不容易的事情。 Spot 请求更便宜，正如这里的一些人在他们的回复中提到的那样，特别是因为不提供持久性。否则，我想“现货请求”市场的定价会大不相同。

同样，这是可能的，我做到了，这是一次很棒的经历。当没有办法时，你必须伪造它！如果你不这样做，其他人会。

更新二：我只想提醒大家，这是我的主要任务。虽然当时很多人都忽略了整个概念，但我最终得到了一个或多或少的功能 SaaS，它允许一个人轻松管理和监控所有的现场实例，包括启用/禁用自动持久重新启动的能力实例，为各个实例安排时间（应该或不应该启动它们）等。

虽然我完全同意，从开发人员的角度来看，这是一个不雅的要求，而且当时我确实不想想要这样做，但我仍然会说这是在某种程度上很好，被要求去工作，因为我不仅学到了很多东西，不仅对自己的能力和代码充满了信心，而且我制作了一个非常有用，据我所知，对我的客户来说非常有价值的软件（即使他们因为不了解而要求错误的东西）。

我试图说服他不要这样做，但他坚持，因为他是付钱的人，所以我把注意力集中在那里，不仅完成了这里许多人认为很愚蠢的事情，而且使它有利可图为某人。

如果它是那么愚蠢，它不会为任何人省钱。

看，我现在读了这篇文章，有点畏缩。那我就天真多了。我更了解 AWS 很多，现在，我现在编写代码很多，等等。自然而然。

但我仍然为解决这个问题感到自豪，特别是因为是这些同胞、年纪较大、经验丰富得多、无疑是伟大的程序员告诉我不能或不应该这样做'完成不了。是你们给我带来了挑战，所以谢谢你们！

如果可以盈利怎么办？你确定不应该吗？

【问题讨论】：

标签： amazon-web-services

【解决方案1】：

我们最终找到了解决方案，这就是我们必须做的。我将逐步列出这一点，以便那些可能正在寻找类似解决方案的人更容易重新创建它......

创建一个新的现场请求实例。确保取消选中根设备的“终止时删除”，以便卷在下一步中保留。请务必记下您的实例使用的架构（我们始终使用 x86_64）和内核 ID（非常重要！）
现在，通过 SSH 连接到您的新实例并创建一个文件或其他内容，这样您就可以直接看到持久化的效果。对文件系统进行一些更改后，继续注销 SSH 连接并终止实例。
太棒了。现在，转到您的 EC2 Web 控制台并找到用于我们刚刚终止的实例的新卷。右键单击该卷并选择“创建映像”。按照向导进行操作，确保选择我们之前提到的相同架构和内核 ID。
现在，使用您的新图像启动 Spot 请求向导。按照向导，再次确保取消选中“终止时删除”。此外，这是一个容易错过的步骤，请确保展开标题为“高级选项”的折叠部分并再次设置正确的内核 ID。

如果您按照上述步骤操作到 T，您将在旧实例终止时所在的同一点拥有一个新实例。因此，我们实现了某种形式的持久性。

【讨论】：

Ethan，这个方法效果很好，但是每次需要重启服务器时都要经历一个漫长的过程。您是否偶然发现了一种无需将其复制到映像即可直接从卷启动的方法？
@trex005 很抱歉，我无法就此回复您。最简洁的答案是不”。长答案是你也可以解决这个问题。与我联系，我可能有一些代码可供您使用。
我最终选择了不同的路线。我有一个持久的 ebs，我会在初始化的早期自动挂载，我需要生存的任何东西都放在那里。然后，我只需要在进行系统更新时创建根的快照。
这是一种合理的方法并且效果很好。请注意，附加可能是异步的，因此请测试设备或睡眠 5 左右。观看权限和 UID。很快，如果性能不是问题，我们也许可以挂载 EFS 目录。这些可以小到 1G。 AWS doco 提到要调整大小的映像快照，但对于 linux，我们可以将文件复制到新的更大的磁盘。多个挂载也可以用作快速备份目的地。
嗨。 AWS 已停止将内核 ID 分配给 Spot 实例。我在实例启动后检查了同样的内容，它是“-”。

【解决方案2】：

（感谢 Ethan Barron 的一些原创想法。这是一个包含一些更正和澄清的版本。）

[1]。创建一个新的 Spot 实例。停用根设备的“终止时删除”。记下架构 (x86_64) 和内核 ID。

[2]。通过 SSH 连接到您的新实例并创建一些文件，这些文件应该在重启后仍然存在。不要终止实例。

[3]。在实例仍在运行时创建实例的快照（这在极少数情况下会导致文件系统不一致，因此限制对引导卷的写入）。记下该快照的名称。

[4]。现在退出 SSH 连接并终止实例。

[5]。从步骤 3 中创建的快照创建 AMI（AWS 不支持从卷创建 AMIS；它必须是快照。如果您使用的是剩余卷，则还有一个额外步骤：创建该快照）。

[6]。根据第 1 步中的架构、第 1 步中的内核 ID 和第 5 步中创建的 AMI 请求新的 Spot 实例。

这应该可行。

【讨论】：

不知道在终止之前创建快照的重要性。谢谢，夜骑士。
如果实例由 EBS 支持，并且启动时未选中“终止时删除”，则可以在实例终止后创建快照，没有任何问题。
你确定可以关机拍照吗？ - 您的初始图像不必来自现场实例，是吗。
@thomie 和 mckenzm 是正确的，我刚刚检查了我的旧代码。我想我肯定只是回答了 NightKnight，甚至没有验证他声称的内容是否属实。我可能只是认为 AWS 已经改变了这种方法不再适用的地方。从某种意义上说，它是hacky。您正在将现场实例用于它们不打算用于的东西。因此，如果您可以处理某些服务器在各处停机几分钟，但希望它保持持久性，并且如果这种方法今天仍然有效，那么就去做吧。在此过程中，您可能会赚到一大笔钱。

【解决方案3】：

更新：时代变了

EC2 Spot 实例请求现在可以配置为 stop 而不是 terminate 出价的 Spot 实例或任何其他导致 Spot 实例中断的容量相关事件。

请参阅 EC2 开发人员指南中的 Interruption Behavior。安装了适当的代理后，某些类的实例也可以休眠。

请注意，此新功能并不能保证实例将继续运行，而只是保证它们将在其以前的 EBS 卷、私有 IP、弹性 IP 和实例 ID 都完好无损的情况下重新启动。

之前的回答如下：

Spot instances 不能持久化，但 Spot requests 可以。

持久性 Spot 请求：当您将 Spot 出价请求指定为“持久性”时，您确保它会在其实例被您或 Amazon EC2 终止后自动重新提交，直到您取消出价请求。这使您能够在 Spot 价格低于您的最高价格时自动启动 Spot 实例。

http://aws.amazon.com/ec2/spot-instances/#4

这可以让机器在价格范围内随时运行，但至于其余部分，请考虑您的 Spot 实例正在做什么，这会让您认为磁盘的持久性是要走的路。想想“云”。想想“短暂的”。 Spot 实例旨在成为启动、获取工作、执行工作、提交工作的临时机器，如果它们消失，工作仍在等待下一个实例再次获取它、完成它并提交它。您“可以”将它们与 EBS 一起使用并保留卷，但如果这样做，这些实例将无法重新启动（如您所见）。

如果您的 AMI 使用实例存储，并存储需要在外部持久保存的所有内容（例如，在 S3 中），那么您无需破解 AWS 架构，您可以坐下来看着您的机器启动当价格合适时，做他们的工作，当价格超出范围时再次关闭。而且，一点也不烂，因为每次启动都是一个闪亮的干净系统。

或者，您的实例可以装载由始终开启的机器导出的 NFS 共享。

或者这个：https://serverfault.com/questions/448043/auto-attach-ebs-volume-to-a-new-spot-instance

【讨论】：

不完全是我正在寻找的答案，但仍然非常有用且很有帮助。我肯定会调查你在说什么，但我不太确定这会是一个解决方案。不管怎样，感谢您的时间和兴趣！
@EthanBarron Michael 说得对，您需要分配工作并使工作人员并行化。如果这对您没有任何意义，那么您最好使用该任务的常规实例。
确实，我们必须将工作单元设计为可重新启动。这可能意味着持久（因此不是静态的）存储，或打电话回家到控制点。这些都是简单的事情。 EFS 可能会有所帮助。通常，主要问题是将缓冲区刷新到磁盘并重新调整文件写入以匹配回滚的数据库工作（如果需要匹配），无头 FAH 客户端多年来一直是一个非常好的示例。

【解决方案4】：

如果您使用的是 ubuntu，我找到了一个方便的解决方案。它使用包含在 ubuntu 发行版中的称为“overlayroot”的功能。这个想法是保持根文件系统只读并将所有更改写入 EBS 支持的覆盖文件系统。因为根是只读的，它可以在终止时被删除，并且所有更改都将保留在覆盖文件系统中。

首先创建一个启用覆盖根的自定义 AMI。使用 AWS 控制台启动您最喜欢的 AMI。登录并将以下行添加到 /etc/overlayroot.local.conf

overlayroot=device:dev=/dev/xvdf,timeout=180,recurse=0

使用 AWS 从您的实例“Instances->Actions->Image->Create Image”创建自定义 AMI

现在创建一个 EBS 卷并将其附加到实例。 “Volumes->Actions->Attach Volume”，然后初始化卷。

mkfs.ext4 /dev/xvdf

第一个实例仅用于创建自定义 AMI 和初始化卷，因此可以终止它。在创建自定义映像之前不要附加 EBS 卷，以免它包含在映像中。

每次启动 Spot 实例时都应遵循以下步骤。

启动自定义实例。请务必设置现货价格。
实例启动后，将覆盖卷附加到 /dev/sdf 上的实例。
重启您的实例。 “实例->操作->实例状态->重启”。登录后，您应该会看到类似这样的内容

ubuntu@ip-10-178-74-83:~$ mount overlayroot on / type overlayfs (rw,discard) ... /dev/xvda1 on /media/root-ro type ext4 (ro,relatime,data=ordered) /dev/xvdf on /media/root-rw type ext4 (rw,relatime,data=ordered)

【讨论】：

超级好用！我最终用这个完全自动化了现场复活。谢谢！

【解决方案5】：

现场实例的性质是它们是瞬态的，因此您不能使实例“持久”。但是，您可以使用 EBS 使 data 持久化。

你的想法是一个关于图像的好想法，老实说，我不确定是否还有其他方法可以做到这一点。

您可以随时查看spot instances 上的文档或跳至forums，看看那里的任何 AWS 工程师是否有任何想法。

--编辑--

不确定这是否可行 - 因为它会产生额外费用，但您始终可以在生成映像后立即从生成的映像启动实例并终止现有实例。它会产生持久性的错觉，特别是如果您不依赖 EBS 卷来保留数据。

【讨论】：

您的回答让我找到了正确的方向。谢谢。
没问题，希望对你有帮助。如果您觉得这回答了您的问题，请接受答案。祝你好运

【解决方案6】：

AWS 最近推出了一个新的 Spot 实例控制面板，让您的实例保持在持久状态变得更加容易。这还包括自动定价和区域支持，因此您不必担心以理想的价格出价。启动实例后，创建实例的 AMI，仅此而已。下次您请求 Spot 实例时，只需从 Saved Instance 列表中选择该实例。内核和 EBS 恢复原样。

【讨论】：

这是最好最简单的答案
这不会保留 AMI 创建后发生的更改。
不，不会。您需要在删除您的 Spot 实例之前创建 AMI。

【解决方案7】：

EC2 Spot 支持自动恢复 EBS 设备https://aws.amazon.com/about-aws/whats-new/2020/01/amazon-ec2-spot-instances-stopped-started-similar-to-on-demand-instances/

【讨论】：

欢迎提供解决方案链接，但请确保您的答案在没有它的情况下有用：add context around the link 这样您的其他用户就会知道它是什么以及为什么会出现，然后引用最相关的您链接到的页面的一部分，以防目标页面不可用。 Answers that are little more than a link may be deleted.