亚马逊 ECS 新增自动修复故障 GPU 和实例功能

在生产环境中运行应用程序，意味着要在各种干扰中维持“始终在线”的状态。基础设施会故障，依赖会变慢，网络会分区——这些不是罕见的例外，而是大规模运行时的常态。承受并从这些干扰中恢复，是一项核心要求，而非事后才考虑的事情。

在实践中，这一要求体现为你可能已经熟悉的一系列时刻。客户发现了服务中断，或者收到了告警，而根本原因可能多种多样：GPU 抛出硬件故障导致某个实例上的任务失败，某个可用区发生了网络事件，或者你依赖的日志后端变慢，悄悄地把你的应用程序也拖垮了。这些都不稀奇，而且它们不会等你方便的时候才发生。真正重要的是接下来会发生什么，以及其中有多少要落到你头上。

“基础设施会故障，依赖会变慢，网络会分区——这些不是罕见的例外，而是大规模运行时的常态。”

在 Amazon ECS 上，我们的目标是替你处理其中大部分工作。故障恢复是我们设计和构建 ECS 功能时的核心考量。这意味着，对于 ECS 自身能够处理的故障，你不应该需要自己构建检测循环和修复手册。对于更模糊的情况——正确的响应取决于你的工作负载——我们开放同样的控制能力，让你自己做决定。

这建立在 ECS 背后的弹性原则之上，我们在《深入剖析 Amazon ECS 的弹性与可用性》中已经介绍过：跨可用区的静态稳定性、预扩容容量，以及工作负载隔离。这里我们聚焦于建立在这些原则之上的恢复机制，以及你对每一项的控制能力。

在 AWS 责任共担模型下，AWS 负责“云本身”的弹性——即你的工作负载所运行的基础设施，而你负责“云中”的弹性——即你的应用程序如何设计以承受故障并从中恢复。我们在这里描述的很多工作，是 ECS 从“云本身”一侧汲取的经验和模式——在那里我们依靠它们来保持自身系统的健康——并将它们应用到“云中”一侧，通常以合理的内置默认值的形式提供，从而简化你系统的运维姿态。

ECS Managed Instances 就是一个例子：ECS 接管了你的任务所运行的实例基础设施的弹性责任。它会在不影响应用程序可用性的前提下，应用操作系统、内核和 GPU 驱动补丁：它会逐步分批推送更新，在过程中持续监测故障，并在检测到问题时回滚。

AWS Fargate 遵循类似的模式：在那里你同样不需要运维实例，因此坏掉的实例、糟糕的操作系统更新或驱动回归，都由我们来检测和恢复，而不是你需要围绕它设计的故障模式。接下来，我们来看看 ECS 如何检测和恢复特定故障：不健康的实例、可用区事件、容器或任务失败，以及依赖降级。

当你的任务底下的实例出问题时

一些最具破坏性的故障始于你的任务之下——即它们所运行的实例。当实例退化时，调度在它上面的每个任务都面临风险，而且它在服务中的时间越长，故障扩散得越广。因此，你需要尽快检测到受损实例并将其移出轮换，以控制爆炸半径。

例如，设想一个运行在一组加速实例上的 GPU 推理工作负载。如果其中一个实例上的 GPU 开始抛出可纠正的 ECC 错误，并升级为故障，那么该实例上的任务就会变慢或失败。或者，如果实例因为网络分区、热事件、Amazon EBS 卷降级等原因而受损，那么它的任务会在没有编排支撑的情况下原地继续运行，最终自身也会受损。自己处理这类损伤，意味着你需要构建额外的自动化来检测受损实例、排空其工作负载、最终轮换它们，然后在大规模下可靠地维护和运营这套自动化。ECS 现在会自动为你完成这些。

“为了直接检测这些故障，ECS 集成了 NVIDIA 的 Data Center GPU Manager（DCGM）……并监测那些表明真实硬件故障的错误类别。”

在 Managed Instances 上，GPU 健康监控和 Auto Repair 填补了一个容易被忽视的缺口。由于 GPU 是直通到实例的，其中发生的大多数 GPU 故障对 Amazon EC2 实例状态检查不可见——那些检查能捕获普通硬件问题——因此它们只能以无法解释的任务失败或延迟的形式浮现。为了直接检测这些故障，ECS 在实例上集成了 NVIDIA 的 Data Center GPU Manager（DCGM），并监测那些表明真实硬件故障而非瞬态或非关键问题的错误类别。

ECS 还会监控数据面实例更广泛的健康状况。这包括 EC2 状态检查以及实例上的数据面组件，如 ECS agent 和容器运行时。ECS agent 管理实例上的任务，并保持它们与 ECS 控制平面连接。当 agent 无法到达控制平面时，任务的本地状态可能会与控制平面中的期望状态发生漂移，而这种漂移会以容易被忽视的方式影响这些任务。agent 无法再发布指标、日志或健康信息，实例变成了一个黑盒。ECS 也无法再可靠地停止或替换其上的任务，因此对于一个服务来说，被困在断开连接实例上的任务会占用其限额，并阻碍健康的替换任务。在 Fargate 和 Managed Instances 上，ECS 都会自动检测 agent 连接的持续中断，并将该实例视为受损；短暂的抖动若自行恢复，则不会触发回收。

在这两种情况下，ECS 都运行同样的持续监控与修复循环，如图 1 所示。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）