实现 AWS Outposts 服务器上 Amazon EC2 实例的高可用性

(第一部分)

by Macey Neff 于 2024 年 8 月 8 日发布在 、、、 和 上。

本文由 Brianna Rosentrater（混合边缘专家 SA）和 Jessica Win（软件开发工程师）撰写。

关键要点

• 本文是两部分系列的第一部分，介绍如何在 AWS Outposts 服务器上实现 Amazon EC2 实例的高可用性。
• 本文提供了代码示例和实施自定义逻辑以自动重新启动 Amazon EC2 的建议，主要针对无状态应用程序。
• 文章讨论了如何利用 Outposts 服务器，通过使用两个或多个服务器实现 N+1 故障容忍，来提供高可用性。

本篇文章是一系列的第一部分，主要讨论如何为在 服务器上运行的 Amazon EC2实例提供高可用性。我们提供了代码示例及实施自定义逻辑以自动在 Outposts 服务器上重新启动 Amazon Elastic Compute Cloud (EC2) 的建议。本文专注于无状态应用程序的指导，而 则聚焦于有状态应用程序，在那里需要维持 EC2实例存储的状态。

Outposts 服务器提供的计算和网络服务非常适合在零售店、分支办事处、医疗服务地点或空间有限的环境中低延迟本地数据处理的需求。Outposts服务器使用 EC2实例存储存储为运行无状态工作负载的实例提供非持久的块级存储，尽管无状态工作负载不需要弹性存储，许多应用程序所有者仍有这类工作负载的正常运行时间要求。本文将帮助您学习如何实现自定义逻辑，通过使用两个或以上的服务器来提供高可用性(HA)，从而为运行在 Outposts 服务器上的应用程序提供更好的可靠性。提供的代码旨在帮助您入门，并可以根据您的独特工作负载需求进行进一步修改。

概述

本文提供了一个 init.py 脚本，该脚本接受您的输入参数并创建一个自定义的 模板，部署在指定的账户中。用户可以运行 “./init.py –-help” 或 “./init.py -h” 来查看参数描述。以下是需要的输入参数：

在收集上述参数后，脚本会生成一个 CloudFormation 模板。您需要查看该模板并确认其符合您的期望。一旦选择 yes ，CloudFormation 模板将部署到您的账户中，您可以通过 查看堆栈。您还会收到一封确认邮件，确认您已订阅 SNS 主题。此 SNS 主题是通过 CloudFormation 堆栈创建的，用于在您的源 Outposts 服务器发生硬件或服务链接故障时进行报警。

init.py 脚本和 AutoRestartTemplate.yaml CloudFormation 模板被提供用于实施自定义逻辑，以便在源 Outposts 服务器出现故障时将 EC2 实例重新启动到指定的目标 Outposts 服务器，以改善应用程序可用性。该逻辑本质上通过创建源和目标 Outpost 之间的映射来工作，仅支持两个 Outposts 服务器之间的实现。这里的代码可以进一步定制以满足您的应用程序需求，旨在帮助您入门，实现您 Outposts 服务器环境的自定义逻辑。在我们讨论 init.py 的参数、意图用例、范围和提供的代码限制后，继续阅读以获取该解决方案的架构信息。

架构图

该解决方案只能在设定为高可用性的两个 Outposts 服务器上运行。对于在同一数据中心运行的超过两个服务器，每个服务器都需要映射到一个辅助服务器进行 HA。一个服务器可以是多个其他服务器的重新启动目标，前提是满足 Amazon EC2 的容量需求。如果源和目标 Outposts服务器同时不可用或发生故障，则需要额外的用户操作。此时，会向通知邮箱参数中指定的地址发送邮件，告知您尝试重启 EC2 实例失败。

函数，根据您提供的启动模板，重新启动源 Outposts 服务器的 EC2 实例到目标 Outposts 服务器。

6. 一个 监控源 Outpost 服务器的 ConnectedStatus 指标，以检测硬件或服务链接故障。
7. 如果 ConnectedStatus 指标显示源 Outposts 服务器的服务链接断开，则 Lambda 函数将协调在目标 Outposts 服务器上根据您提供的启动模板重新启动 EC2 实例。
8. 在源 Outposts 服务器发生硬件或服务链接故障并进行 Amazon EC2 重新启动时，Amazon SNS 会向您在 init.py 脚本中提供的通知邮箱发送通知。您将在 CloudWatch 警报触发时收到通知，并在自动化执行结束时获得包含执行状态的通知。
9. 根据您的启动模板的描述，EC2 实例将在目标 Outposts 服务器上自动启动，无需手动操作。

现在我们已经简要讨论了此解决方案的架构和工作流程，接下来是有关如何在您的 AWS 账户上实现此代码的逐步说明。

前提条件

进行本次演练需要以下先决条件：

• 用于运行动态创建 CloudFormation 堆栈的 init.py 脚本，该堆栈的账户由输入参数指定。
• 两台可以作为 的可恢复对的 Outposts 服务器，具体取决于工作负载的大小。
• 为您想要保护的应用程序创建启动模板——确保为目标 Outposts 服务器选择可用的实例类型。
• 确保您拥有在 AWS 账户中以编程方式部署 CloudFormation 堆栈所需的凭证。
• 如果您是从 中设置的，则需要配置 以查看 Outposts 指标。
• 下载 仓库。

部署 AutoRestart CloudFormation 堆栈

为了本篇文章的目的，已创建一个名为“Production-Application-A”的虚拟私有云 (VPC)，以及用于本次讨论的两台 Outposts服务器的子网，分别命名为“source-outpost-a”和“destination-outpost-b”。用于本次演练的启动模板提供了 destination-outpost-b 子网。

删除)

1. 确保您在包含 init.py 和 AutoRestartTemplate.yaml 文件的目录中。接下来，运行以下命令以执行 init.py 文件。请注意，您可能需要更改文件权限。如果是这样，请运行 “chmod a+x init.py” 以授予所有用户对该文件的执行权限：./init.py --launch-template-id <value> --source-outpost-id <value> --template-file AutoRestartTemplate.yaml --stack-name <value> --region <value> --notification-email <value>。

删除)

删除)

删除)

5. 您将收到一封确认电子邮件，其内容如上所示，询问您确认订阅为您的 CloudWatch 警报创建的 SNS 主题。此警报监控您的 Outposts 服务器的 ConnectedStatus 指标。这是一个关键步骤，如果不确认 SNS 主题的订阅，则您无法在源 Outposts 服务器发生硬件或服务链接故障以及启用此重启逻辑时收到通知。确认您的电子邮件地址后，Amazon EC2 自动重启逻辑的实施就完成了，您在 Event of a service link or source Outposts 服务器故障时，EC2 实例现在会自动重新启动到您在启动模板中提供的目标 Outposts 服务器子网。您还将收到一封通知您源 Outpost 服务器已断电和发生重启事件的电子邮件。

为本次文章的目的，模拟在 source-outpost-a 服务器上的服务链接故障。在 CloudWatch 警报被触发大约一分钟后，您将收到来自之前订阅的 SNS 主题的邮件提醒。邮件提醒的示例如下图所示：

删除)

收到此提醒后，您可以导航到 EC2删除)

现在，您的 EC2 实例已经在健康的目标 Outposts 服务器上重新启动，您可以开始追查源 Outposts服务器发生故障的原因，而不必担心将您的应用程序恢复到运行状态。

清理

由于此自定义逻辑是通过 CloudFormation 实现的，因此唯一需要清理的操作是从您的 AWS 账户中删除 CloudFormation堆栈。这样做将删除通过 CloudFormation 堆栈部署的所有资源。

结论

通过 AWS 工具，如 CloudFormation、CloudWatch 和 Lambda 使用自定义逻辑，可以为 Outposts服务器上的无状态工作负载实现高可用性。通过实施本篇文章中的自定义逻辑，您可以自动将运行在源 Outposts 服务器上的 EC2 实例重新启动到次要的目标 Outposts 服务器，从而在发生硬件或服务链接故障时减少应用程序的停机时间。文章中提供的代码也可以进一步扩展，以满足