加速 AMI 和 ASG 创建

Posted 2023-03-04

【中文标题】加速 AMI 和 ASG 创建

【英文标题】：Speed up AMI and ASG Creation

【发布时间】：2016-05-19 17:47:11

【问题描述】：

我使用 Ansible 创建了一个 ubuntu 实例的 AMI，然后使用此 AMI 创建一个 Launch 配置，然后更新和自动扩展组，是否有任何快捷方式可以加快 ASG 和 AMI 步骤，需要 10 分钟+

【参考方案1】：

使用 EBS 支持的 AMI 而不是 Instance Store 支持的 AMI。来自AWS docs：

           Amazon EBS-Backed             Amazon Instance Store-Backed
Boot time  Usually less than 1 minute    Usually less than 5 minutes

--http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ComponentsAMIs.html#storage-for-the-root-device

【讨论】：

好的，我会试一试，是否有特定的实例大小可以加快速度？

当我查看列表云图像时 - cloud-images.ubuntu.com/locator/ec2 hvm:ebs hvm:ebs-io1 hvm:ebs-ssd

我认为实例大小没有那么重要。我相信速度提升来自于从 EBS 卷获取 OS 映像与从 S3 下载整个 OS 映像之间的差异。

我会购买文档中的 5 分钟时间，但我一生中还没有看到任何 EC2 实例在不到 1 分钟的时间内启动。我想这取决于你如何定义引导。现在在 Google Compute Engine 上，我可以在大约 23 秒内“启动”一个虚拟机并通过 ssh 进入。

【参考方案2】：

我通过 AWS Support 工单问了一个类似的问题，这里有回复：

启动新 EC2 实例时的主要耗时过程 是实例内操作系统的启动过程：或多或少 安全组/网络 ACL，不同数量的 SSH 密钥对，以及 与实例关联的角色在 它启动所需的时间。大部分时间都需要 启动实例由操作系统本身使用。

考虑到这一点，请允许我回顾一下 实例启动时可能会消耗最多的时间 - 对于所有 下面的几点我将从 EC2 的角度专门关注 Linux 观点：

本地文件系统挂载：如果您的实例需要挂载大量文件系统，这会为您的启动增加一点时间 过程。根据您使用的文件系统类型，您可能需要 每固定天数定期运行检查 - 例如，在 Linux 您可能需要每 90 天在 ext4 文件系统上运行一次 fsck （此时间段可能会根据您的设置而变化）和操作系统 挂载文件系统时自动触发此检查 如果检测到已超过期限，则启动。一种策略 防止这种情况可以在创建之前执行这些检查 您将用于启动新实例的 AMI，以便任何实例 从此 AMI 启动的文件系统最近会被检查 并且您在启动时不会遇到意外的 fsck 执行 第一次实例。根据您的文件系统类型 使用，可以完全禁用这些定期检查， 但我不推荐它，因为它们是维护 文件系统随时间的完整性。

远程文件系统挂载：如果您的实例需要挂载任何远程文件系统（例如，EFS 共享或任何常规 NFS 共享）， 您的启动过程可能会延迟，具体取决于网络连接 到共享此远程文件系统的服务器。在最坏的情况下 场景，如果共享文件系统的服务器离线，你的启动 进程将被中断，直到此连接超时并失败。 如果您在启动时默认挂载任何远程文件系统 您的实例，确保共享它们的服务器可用 在启动您的实例之前。

常规操作系统初始化脚本：启动过程消耗的大部分时间将用于启动操作系统 服务。 Linux 中有两种类型的模型： 传统的 SystemV init（以串行方式启动服务，一个 另一个之后），以及相对较新的 systemd（能够 并行启动服务，从而减少某些启动时间 情况）。您使用哪一个将取决于 Linux 您在实例中运行的发行版。例如，如果您需要 启动数据库服务器，每次启动时可能需要很长时间 例如，可能值得考虑 systemd，因为它允许 其余不相关的服务将并行启动，如 只要他们没有这个数据库服务器作为先决条件。

用户数据和云初始化脚本：这些在常规操作系统初始化脚本结束后执行。就像前面的项目一样，你 可能想要检查您执行的任何这些自定义脚本是否 优化，以便他们可以花费最少的时间；它是 建议单独测试任何自定义用户数据脚本以 在将它们添加到新实例启动之前测量它们的时间，以便您 可以更好地了解它们在整个过程中的影响 实例启动。如果您的脚本正在检索外部的任何文件 实例（如果您从 S3 存储桶下载内容，请运行 自动更新已安装的软件包等），相同 我提到的“远程文件系统挂载”项的注意事项 上述适用 - 确保没有网络问题 可能会减慢或阻止此连接，因为这会增加更多 您的实例的整个启动过程的时间。

实例类型：实例类型确实会影响操作系统完成启动所需的时间。同样情况下，一个 t2.large 实例将比 t2.nano 启动得更快，因为它有更多 RAM、vCPU 和更多的 CPU 积分 - 所有这些都允许 操作系统以更快地执行启动过程。另外，如果你需要 在实例启动过程中检索大量数据， 您可能想要使用增强的网络模式和 EBS 优化 实例以确保您拥有可用于您的最佳带宽 需要；有关更多详细信息，请参阅此消息末尾的链接 这个。

EBS 卷类型：与实例类型一样，EBS 卷的性能也是影响总时间的一个因素 实例启动时间。如果您的实例需要读取大 引导过程中从 sc1 卷（HDD 为不经常访问的数据设计的低性能卷）， 启动过程将比您的实例读取相同的速度慢 来自具有更高性能的 PIOPS 卷的数据 - 如果您使用 案例包含您受此影响的场景，您可能 想要测试不同的卷类型以选择更好的卷类型 适合您的需求。同样，您的实例的根卷的类型 也会影响启动性能，因为在所有情况下，您都会 必须从中读取信息。在大多数情况下，默认的“常规 用途 SSD” a.k.a. gp2 EBS 卷对于实例 root 来说已经足够好了 卷。

最终，将确定启动新实例所需的时间 通过为您的特定用例运行基准测试；一般 我上面提到的注意事项可以帮助您减少这个时间，但是 确定哪些设置最适合您的环境 需要测试和微调每个参数，直到达到一个点 启动时间适合您的需求。

我在此回复的末尾附加了几个链接，其中包含更多 我在此回复中提到的项目的详细信息。

我希望这些信息对您有用。请让我知道是否 你有任何问题。

谢谢，

相关链接： - EC2 实例类型：https://aws.amazon.com/ec2/instance-types/ - EBS 卷类型：http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html - EBS 优化实例：http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html - EBS 卷的性能提示：http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html - 增强 EC2 Linux 实例上的网络模式：http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html