本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
更新中的计算环境 AWS Batch
AWS Batch 提供了多种更新计算环境的策略,每种策略都针对特定的更新场景和要求而设计。这些方法使用相同的底层更新 API,但代表了用于有效管理更新的不同规范方法。您可以使用 AWS Batch 控制台或管理这些更新 AWS CLI。了解这些策略有助您选择最适合自己需求的方法,同时尽可能减少工作负载中断。
本主题概述了可用的更新策略,并提供了有关每种方法的使用场景的指导。有关详细操作过程,请参阅每种更新策略的相应部分。
重要
AWS Batch 代表您并在您的账户中创建和管理多个 AWS 资源,包括亚马逊 EC2 启动模板、亚马逊 EC2 Auto Scaling 群组、亚马逊 EC2 竞价队列和亚马逊 ECS 集群。这些托管式资源均经过专门配置,以确保 AWS Batch
的最优运行状态。除非在 AWS Batch 文档中明确说明,否则手动修改这些 AWS Batch托管资源可能会导致意外行为,包括INVALID计算环境、实例扩展行为不佳、工作负载处理延迟或意外成本。不能确定 AWS Batch 服务一定能够支持这些手动修改。请务必使用支持的控制台 AWS Batch APIs 或 AWS Batch 控制台来管理您的计算环境。
不支持的手动修改包括在托管的 Amazon ECS 集群上运行您自己的 AWS Batch Amazon ECS 任务或服务,或者直接在托管实例上 AWS Batch启动其他进程、守护程序或服务。 AWS Batch 完全控制托管计算环境中的计算资源,并且可以随时终止实例、停止任务或扩展集群。您在这些托管资源上提交 AWS Batch 任务之外运行的任何工作负载都可以在没有警告的情况下中断。在 AWS Batch托管集群和实例上运行非AWS Batch 工作负载也会干扰 AWS Batch 作业调度和实例扩展。
计算环境更新策略
使用扩缩更新或基础设施更新策略时,您的计算环境将就地更新。对于 blue/green 更新策略,您可以创建一个新的计算环境(绿色),然后将工作负载从旧计算环境(蓝色)迁移到新的计算环境(绿色)。
AWS Batch 为计算环境更新提供了三种不同的策略:
- 扩缩更新
-
扩缩更新通过增加或移除实例来调整计算环境的容量,但不会替换现有实例。这是最快的更新场景,不需要停机时间。需要更改容量设置时使用扩展更新 (vCPUs)。此类更新通常会在几分钟内完成。
Fargate 更新的执行过程与扩缩更新相同。有关更多信息,请参阅 执行扩缩更新。
- 基础架构更新
-
基础设施更新会将计算环境中的实例替换为具有更新后设置的新实例。此类更新需要特定的服务角色和分配策略配置,但停机时间极少,正在运行的作业可能会出现中断。需要修改实例类型、AMI 配置、联网设置、服务角色、环境状态或其他基础设施组件时,应使用基础设施更新。根据作业完成情况,此类更新通常会在 10-30 分钟内完成。
有关更多信息,请参阅 执行基础设施更新。
- 蓝绿更新
-
Blue/green updates create a new compute environment alongside your existing environment, allowing gradual workload transition with zero downtime. This approach provides the safest update path but requires running two environments temporarily. Use blue/green在需要零停机时间、想要在完全部署之前测试更改、需要快速回滚功能或使用不支持的配置进行基础架构更新时进行更新。完成更新所需的时间因情况而异,并且由您控制。
有关更多信息,请参阅 为计算环境执行 blue/green 更新。
选择合适的更新策略
使用以下决策指南来选择最适合您需求的更新策略:
选择扩缩更新的场景
当你只需要调整计算容量 (vCPUs) 时,选择扩展更新策略。需要在无停机时间的情况下快速更新且无需更改基础设施配置时,扩缩更新是理想的选择。
有关详细步骤,请参阅 执行扩缩更新。
选择基础设施更新的场景
需要修改实例类型、AMI 设置、服务角色、环境状态或联网配置时,应选择基础设施更新策略。您的环境必须使用AWSServiceRoleForBatch服务相关角色和BEST_FIT_PROGRESSIVESPOT_CAPACITY_OPTIMIZED、或SPOT_PRICE_CAPACITY_OPTIMIZED的分配策略。如果更新期间可以接受某些作业中断,并且您希望自动更新到最新版本的 Amazon ECS 优化型 AMI,则非常适合选择基础设施更新。
有关详细步骤,请参阅 执行基础设施更新。
在何时选择 blue/green 更新
如果您的工作负载需要零停机时间,或者您需要在过渡生产工作负载之前测试更改,请选择 blue/green 更新策略。当快速回滚功能很重要、您的环境使用BEST_FIT分配策略或者您的环境不使用AWSServiceRoleForBatch服务相关角色时,这种方法是必不可少的。 Blue/green 当您使用需要手动更新或需要进行重大配置更改 AMIs 的自定义版本时,更新也是最佳选择。
有关详细步骤,请参阅 为计算环境执行 blue/green 更新。
AMI 更新注意事项
更新方法 AMIs 取决于您的计算环境配置。
将 AWS Batch 提供的默认 AMI 更新为最新
AWS Batch 当满足所有这些条件时,可以在基础设施更新期间更新到最新 Amazon ECS 优化的 AMI:
注意
基础设施更新完成后,updateToLatestImageVersion 将设置为 false。要启动其他更新,必须将 updateToLatestImageVersion 设置为 true。
-
计算环境使用AWSServiceRoleForBatch服务相关角色
-
分配策略设置为
BEST_FIT_PROGRESSIVE、SPOT_CAPACITY_OPTIMIZED或SPOT_PRICE_CAPACITY_OPTIMIZED -
未在
imageId、imageIdOverride或启动模板中显式指定 AMI ID -
updateToLatestImageVersion设置为true
AMI 使用 blue/green 部署进行更新
AMIs 在以下情况下,必须使用 blue/green 部署进行更新:
-
使用
BEST_FIT分配策略时(不支持基础设施更新) -
不使用AWSServiceRoleForBatch服务相关角色时
自定义 AMI 的 AMI 更新
如果您在计算环境的启动模板中指定自定义 AMI,则 EC2 配置中的imageIdimageIdOverride参数或参数 AWS Batch 不会在基础设施更新期间自动更新您的自定义 AMI。您可以通过在创建计算环境时最初使用的参数中指定新 ID 来更新自定义 AMI ID。如果您想切换到使用 AWS Batch提供的 AMI,则可以通过在计算环境更新中删除自定义 AMI ID 来实现。