从故障模式的角度进行思考

在设计高度可用的应用程序或系统时，必须考虑到哪些组件可能会出现故障，组件故障会对系统产生哪些影响，以及可以实施哪些机制来缓解或消除组件故障的影响。应用程序是在单台服务器上、单个机架中还是单个数据中心中运行？ 当服务器、机架或数据中心出现临时或永久故障时会发生什么？ 当网络等关键子系统或应用程序本身出现故障时会发生什么？ 这些就是故障模式。

在规划 Outpost 和应用程序部署时，应考虑本部分所述的故障模式。以下各部分将介绍如何缓解这些故障模式，从而为应用程序环境提供更高级别的可用性。

故障模式 1：网络

Outpost 部署的管理和监控依赖于与其父级区域的弹性连接。网络中断可能是由各种故障引起的，例如操作员错误、设备故障和服务提供商的服务中断。Outpost 可能包含在站点连接在一起的一个或多个机架，如果其无法通过服务链接与区域通信，则被视为已断开连接。

冗余网络路径可以帮助降低发生断开连接事件的风险。您应该映射应用程序依赖关系和网络流量，以了解断开连接事件对工作负载操作的影响。规划足够的网络冗余以满足应用程序可用性需求。

在断开连接事件期间，在 Outpost 上运行的实例将继续运行，并且可通过 Outpost 本地网关（LGW）从本地网络进行访问。如果本地工作负载和服务依赖于区域的服务，则可能会受损或出现故障。当 Outpost 与区域断开连接时，变更请求（例如启动或停止前哨基地上的实例）、控制平面操作和服务遥测（例如 CloudWatch 指标）将失败。

故障模式 2：实例

如果支持 EC2 实例运行的服务器出现问题，或者实例遇到操作系统或应用程序故障，则这些实例可能会受损或失败。应用程序处理这些类型故障的方式取决于应用程序架构。单体应用程序通常使用应用程序或系统功能进行恢复，而以服务为导向的模块化架构或微服务架构通常会替换出现故障的组件以保持服务可用性。

您可以使用 EC2 自动扩缩组等自动机制将失败的实例替换为新实例。实例自动恢复可以重启因服务器故障而失败的实例，前提是其余服务器上有足够的可用容量。

故障模式 3：计算

服务器可能会出现故障或受损，并且可能由于各种原因（例如组件故障和定期维护操作）而需要（临时或永久）停止运行。Outpost 机架上的服务处理服务器故障和受损问题的方式各不相同，可能取决于客户如何配置高可用性选项。

您应该订购充足的计算容量以支持 N+M 可用性模型，其中 N 是所需的容量，M 是为应对服务器故障而预置的备用容量。

作为完全托管 AWS Outposts 机架服务的一部分，提供故障服务器的硬件更换。 AWS 主动监控 Outpost 部署中所有服务器和网络设备的运行状况。如需进行物理维护， AWS 将安排时间前往您的站点以更换出现故障的组件。通过预置备用容量，您可以在出现故障的服务器停止使用和进行更换的同时保持工作负载运行。

故障模式 4：机架或数据中心

机架故障可能是由于机架完全断电或环境故障（例如冷却中断或数据中心因洪水或地震而受到物理损坏）所致。数据中心的配电架构存在缺陷或标准数据中心电源维护期间出现错误，都可能导致一个或多个机架甚至整个数据中心断电。

通过将基础设施部署到多个数据中心楼层或者同一园区或城区内相互独立的地点，可以缓解上述情况。

在 AWS Outposts 机架上采用这种方法需要仔细考虑应用程序的架构和分布方式，使其在多个独立的逻辑 Outposts 上运行，以保持应用程序的可用性。

故障模式 5： AWS 可用区或区域

每个 Outpost 都锚定到某个 AWS 区域内的特定可用区（AZ）。锚 AZ 或父级区域内的故障可能会导致 Outpost 失去管理和可变性，并可能中断 Outpost 与区域之间的网络通信。

与网络故障类似，AZ 或区域故障可能会导致 Outpost 与区域断开连接。如前所述，在 Outpost 上运行的实例将继续运行，并且可以通过 Outpost 本地网关（LGW）从本地网络进行访问，如果这些实例依赖于区域内的服务，则可能会受损或失败。

为了减轻 AWS 可用区和区域故障的影响，您可以部署多个 Outposts，每个Outpost都锚定到不同的可用区或区域。然后，您可以使用当今用于设计和部署的许多类似机制和架构模式来设计工作负载，使其在分布式多前哨部署模型中运行。 AWS