实现 AWS Outposts 服务器上的 Amazon EC2 实例高可用性 (第2部分)

关键要点

在此博文中，我们将为您提供用于在 AWS Outposts 服务器上实现 Amazon EC2实例高可用性的代码示例和注意事项。此部分重点关注需在重启时保持状态的状态应用程序，涉及如何利用 AWS 工具自动化 EC2实例的重新启动，确保应用程序在故障情况下能保持高可用性。

本博文是两部分系列“在 AWS Outposts 服务器上实现 Amazon EC2 实例高可用性”的第二部分。本文提供了代码示例以及实现自定义逻辑以自动化 Amazon Elastic Compute Cloud (Amazon EC2) 在

上的重启的考虑因素。文章主要关注那些在重启时需要维护 状态的状态类应用程序。

概述

提供计算和网络服务，非常适合低延迟、本地数据处理需求，如零售店、分支机构、医疗服务提供位置或空间受限的环境。Outposts 服务器利用 EC2实例存储提供非持久的块存储，许多应用程序使用实例存储来保存必须在灾难恢复（DR）事件中保留的状态信息。本文将教您如何实现自定义逻辑，以使用两个或更多服务器提供应用程序在 Outposts 服务器上运行时的高可用性（HA），从而实现 N+1容错。提供的代码旨在帮助您开始创建自定义重启逻辑，您可以根据自己的工作负载需求进一步修改。

架构

此解决方案适用于设置为强韧配对的两个 Outposts 服务器。若在同一数据中心运行三个或更多服务器，每个服务器需要映射到一个备用服务器以确保 HA。如果源和目标 Outposts 服务器同时不可用或发生故障，则需额外用户操作进行解决。在这种情况下，将向您在执行 init.py 脚本时提供的通知邮箱参数所指定的地址发送通知邮件，告知您 EC2 实例重启的尝试失败。

![图1：Outposts 服务器上 Amazon EC2删除)

有关步骤 1-6 的详细信息，请参见本系列的 ，讨论 Amazon EC2 重启自动化如何工作。如需针对状态应用程序扩展此逻辑以捕获 EC2 实例存储状态，需要使用 AWS Systems Manager自动化创建一个 Amazon Elastic Block Store (Amazon EBS) 支持的 Amazon Machine Image (AMI)，该数据在源 Outposts 服务器上运行的 EC2 实例的区域中。然后，在源服务器的硬件或服务链接故障时，此 AMI 可在另一台 Outposts 服务器上重启。与该 AMI 关联的 EBS 卷在重启时会自动转换为实例存储根卷。

先决条件

完成此操作步骤所需的先决条件如下：

• 受保护的 EC2 实例必须是 Linux 实例。
• 被保护的 EC2 实例必须能够访问 中的 Internet Gateway (IGW) 或 NAT 网关，以下载和安装所需的 Linux 包和未来更新。
• 在您 Outposts 服务器的 中创建一个 Amazon Simple Storage Service (Amazon S3) 存储桶，以存放 自动化文档。
• 如果您是从 设置此项，则需要配置 Amazon 以在您的消费账户中查看 Outposts 监控指标。
• 下载 仓库。
• 注意 GitHub 仓库 README 文件中的先决条件和限制说明。

此博文基于 中实现的 Amazon EC2自动重启逻辑。在第1部分中，我们讨论了为无状态应用程序实现 HA 的逻辑。第2部分则将实施扩展到状态应用程序，确保在实例重启时保留 EC2 实例存储数据。

部署 Outposts 服务器 Linux 实例备份解决方案

本博文假设已创建一个名为“Production-Application-A”的虚拟私有云 (VPC)，以及每个 Outposts服务器上均已创建的“source-outpost-a”和“destination-outpost-b”子网。目标 Outposts B的子网已在进行此操作时所用的启动模板中提供。已在本系列的 中实现了讨论的 Amazon EC2自动重启逻辑，本文的重点是将该自动重启功能扩展至状态应用程序的后续步骤。

按照 GitHub 仓库 README 文件中提供的安装说明，您首先需要在具有访问 Outposts 服务器的账户中打开 终端。接下来，克隆 GitHub 仓库并进入 “backup-outposts-servers-linux-instance” 目录：

![图2：在 CloudShell删除)

在这里，您可以使用 make documents 命令构建 Systems Manager 自动化文档及其附件。成功执行后，输出应类似如下：

删除)

最后，将您刚创建的 Systems Manager 自动化文档上传到您为此目的创建的 Outposts 服务器父区域中的 S3存储桶。以本文为例，创建了一个名为 “ssm-bucket07082024” 的 S3 存储桶。按照 GitHub 安装说明中的第4步，命令如下：

bash BUCKET_NAME="ssm-bucket07082024" DOC_NAME="BackupOutpostsServerLinuxInstanceToEBS" OUTPOST_REGION="us-east-1" aws s3 cp Output/Attachments/attachment.zip s3://${BUCKET_NAME} aws ssmcreate-document --contentfile://Output/BackupOutpostsServerLinuxInstanceToEBS.json --name ${DOC_NAME} --document-type "Automation" --document-format JSON --attachmentsKey=S3FileUrl,Values=s3://${BUCKET_NAME}/attachment.zip,Name=attachment.zip --region ${OUTPOST_REGION}

成功创建 Systems Manager 自动化文档后，命令的输出会显示您新创建文件的内容。检查完毕后，您可以退出终端，确认您指定的 S3存储桶中是否有新的 “attachments.zip” 文件。

现在可以准备实施此自动化逻辑。根据 GitHub 指导在具有访问 Outposts 服务器的账户中进入 SystemsManager，然后执行自动化。本文中使用的默认文档名称为 “BackupOutpostsServerLinuxInstanceToEBS”，所以选择该文档。

删除)

在执行此自动化后，系统将要求您配置此自动化的运行手册。保持默认的 简单执行 选项：

删除)

在输入参数部分，查看 GitHub 仓库 README 文件中给出的参数定义。为了说明，本文使用如下内容：

删除)

请注意，您可能需要为 Systems Manager 创建服务角色，以便其代表您执行此自动化。为了本博文的目的，您可以使用 中提供的信息完成此步骤。其他设置可以保持默认。通过选择页面底部的 执行 完成设置。执行所有必要步骤可能需要长达 30分钟的时间。请注意，自动化文档显示为32步，但执行的步骤数量会根据您的基础 Linux AMI类型有所不同。只要自动化的整体状态显示为成功，您就已经完成了实施。以下是一个示例输出：

删除)

您可以在 Amazon EC2 控制台的 镜像 部分找到此自动化生成的 AMI：

![图8：查看生成的 删除)

最后一步是为刚创建的 AMI 创建 。这会防止您在每次创建新 AMI ID 时手动更新应用程序的启动模板。由于此 AMI实际上是应用程序及其当前实例存储状态的备份，因此预期 AMI ID 将在每次备份或新的 AMI 创建时变化，因此请确定与您的应用程序 [恢复点目标 (RPO)](https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for- cloud-applications/) 一致的 AMI 创建频率。

要为 AMI 创建 Systems Manager 参数，首先导航到您的 Systems Manager 控制台。在 应用程序管理 中选择 参数存储 和 创建参数 。您可以根据需要选择标准或高级层次。后文中 AMI ID 为 ami-038c878d31d9d0bfb，以下是用于此次操作的参数详细信息示例：

删除)

现在您可以修改在第1部分创建的应用程序启动模板，并指定刚刚创建的 Systems Manager 参数。为此，导航到您的 Amazon EC2 控制台，在 实例 中选择 启动模板 选项。创建该启动模板的新版本，选择 浏览更多 AMIs 选项，并选择搜索框右侧的箭头按钮。选择 指定自定义值/Systems Manager 参数 。

![图10：指定 Systems Manager删除)

然后在列出格式中输入参数名称，最后选择 保存 。

删除)

您应会在启动模板摘要的 软件镜像 (AMI) 部分看到您的参数：

删除)

确保您的启动模板设置为最新版本。现在您的安装完成了；在源 Outposts 服务器发生故障时，您的应用程序将自动在目标 Outposts 服务器上的新 EC2 实例上重新启动。您还将收到一封发送到您在 init.py 脚本中指定的通知邮箱参数的通知邮件。这意味着您可以在第一时间处理源 Outposts服务器发生故障的原因，而无需担心应用程序的恢复。这有助于确保您的应用程序高可用并减少您的 [恢复时间目标 (RTO)](https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for- cloud-applications/) 。

清理

自定义的 Amazon EC2 重启逻辑通过 实现，因此唯一需要清理的就是删除您 AWS账户中的 CloudFormation 堆栈。这样将删除通过 CloudFormation 堆栈部署的所有资源。要删除 Systems Manager自动化，从主机管理中取消注册您的 EC2 实例并删除该区域中的 Amazon EBS 支持的 AMI。

结论

通过 AWS 工具（如 CloudFormation、、SystemsManager 和 ）使用自定义逻辑可以帮助您面向 Outposts服务器上的状态工作负载架构实现高可用性。实现本文中介绍的自定义逻辑，您可以自动将运行在源 Outposts 服务器上的 EC2 实例重启到备用 Outposts服务器，同时保持应用程序的状态数据。这减少了硬件或服务链接故障导致您的应用程序停机的时间。本文中提供的代码也可以进一步扩展以满足您的具体工作负载需求。

请注意，虽然使用 基础设施即代码 (IaC) 可以提高应用程序的可用性并在多个 Outposts 服务器间标准化部署，但定期进行故障演练至关重要，以测试现有的自定义逻辑，确保您了解应用程序在故障重启时的预期行为。有关 Outposts服务器的更多信息，请访问 。