通过控制面板控制的撤离

第一种模式使用数据面板操作来阻止在受影响的可用区中执行工作，从而缓解事件的影响。但是，您使用的架构可能不使用负载均衡器，或者无法为每台主机配置运行状况检查。或者，您可能希望通过自动扩缩或正常工作计划阻止将新容量部署到受影响的可用区。

为了应对这两种情况，您需要执行控制面板操作来更新资源配置。该模式适合任意网络配置可以更新的服务，例如 EC2 Auto Scaling、Amazon ECS、Lambda 等。它需要针对每项服务编写代码，但业务逻辑遵循标准模式。代码应由响应事件的操作员在本地执行，以最大限度地减少所需的依赖项。脚本逻辑的基本流程如下图所示。

为撤离可用区而进行的控制面板更新

1. 该脚本列出了指定类型的所有资源（例如自动扩缩组、ECS 服务或 Lambda 函数）并从资源信息中检索其子网。支持的资源取决于脚本的配置。

2. 它通过将每个子网的可用区名称与映射的可用区 ID（作为输入参数提供）进行比较来确定应删除哪些子网。

3. 资源的网络配置已更新以移除已识别的子网。

4. 更新的详细信息记录在 DynamoDB 表中。可用区 ID 作为分区键进行存储，而资源 ARN 或名称则作为排序键进行存储。已删除的子网则作为字符串数组进行存储。最后，还会存储资源类型，并用作全局二级索引 (GSI) 的哈希键。

步骤 4 记录了所做的更新，因此当您准备好恢复时，这种方法还能够轻松恢复，如下图所示。

为恢复可用区撤离操作而进行的控制面板更新

恢复步骤：

1. 查询 GSI 以获取针对指定可用区（如果未指定，则为所有可用区）中指定类型的每种资源删除的子网。

2. 描述在 DynamoDB 查询中找到的每个资源以获取其当前网络配置。

3. 将当前网络配置中的子网与从 DynamoDB 查询中检索到的子网合并。

4. 使用新的子网集更新资源的网络配置。

5. 更新成功完成后，从 DynamoDB 表中删除该记录。

这种通用模式既可以阻止将工作路由到受影响的可用区，又可以阻止将新的容量部署到这些可用区。以下示例介绍如何针对不同服务实现该模式。

• Lambda — 更新函数的 VPC 配置以删除指定可用区中的子网。

• 自动扩缩组 — 从 ASG 配置中删除子网，这将替换剩余可用区中的该容量。

• Amazon ECS — 更新 ECS 服务 VPC 配置以删除子网。

• Amazon EKS — 对受影响的可用区中的节点应用污点，以驱逐现有容器组 (pod) 并防止在此安排其他容器组 (pod)。

各项服务对配置更新的反应都会有所不同。例如，Amazon ECS 将在更新后实施服务的部署配置，并触发新任务的滚动部署或蓝/绿部署。

对于某些工作负载来说，这些更新可能会过快地将工作转移到正常的可用区。尽管经过配置可在面临该故障时保持静态稳定（在剩余的可用区中预先配置足够的容量来处理受影响的可用区的工作），您可能仍希望逐步淘汰受影响可用区中的容量。

如果您计划更新已禁用跨区域负载均衡的负载均衡器的目标组（自动扩缩组）网络配置，请遵循此指南。

Auto Scaling 会使用其可用区重新平衡逻辑对这一变化做出反应。它将在其他可用区启动实例以满足您所需的容量，并终止您移除的可用区中的实例。但是，在实例终止的过程中，负载均衡器将继续在每个可用区（包括您从 ASG 中移除的可用区）之间平均分配流量。这可能会导致该可用区的剩余容量减少，直到所有实例都成功终止。这与可用区独立性中描述问题相同，涉及禁用跨区域负载均衡导致的可用区不平衡。为避免出现此类情况，您可以：

• 始终先撤离可用区，这样流量就只会在剩余的可用区之间进行分配

• 指定运行状况良好的目标最低计数进行 DNS 故障转移，以匹配该可用区所需的最低目标数量。

这将有助于确保在实例开始终止后不会将流量发送到您移除的可用区。