本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 更大规模的故障模式
要设计 HA 架构以缓解更大规模的故障模式 [例如机架、数据中心、可用区（AZ）或区域故障]，您应该在配备独立电源和 WAN 连接的单独数据中心中部署具有充足基础设施容量的多个 Outpost。您可以将 Outposts 锚定到一个 AWS 区域 或多个区域内的不同可用区 (AZs)。您还应在位置之间配置弹性和足够的 site-to-site连接，以支持同步或异步数据复制以及工作负载流量重定向。根据您的应用程序架构，您可以在 Outpo [sts 上使用全球可用的 [Amazon R](https://aws.amazon.com/route53/) oute 53 DNS 和 Amazon Rout](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/outpost-resolver.html) e 53 将流量引导到所需位置，并在发生大规模故障时自动将流量重定向到幸存的地点。
# Outposts 机架 VPC 内部路由
AWS Outposts rack 支持[跨多个 Outposts 的 VPC 内部通信](https://aws.amazon.com/blogs/compute/introducing-intra-vpc-communication-across-multiple-outposts-with-direct-vpc-routing/)。两个独立的逻辑 Outposts 上的资源可以使用 Outpost 本地网关 (LGW) 在同一 VPC 内的子网之间路由流量，从而相互通信。通过跨多个 Outposts 的 VPC 内部通信，您可以使用本地 LGW 作为下一跳向其他 Outposts 子网添加更具体的路由，从而覆盖与 Outposts 子网关联的路由表中的本地路由。它可以为架构需要在两个逻辑前哨之间跨一个 VPC 的应用程序提供优势，比如跨越两个 Outposts 机架的 [Amazon ECS 或者跨越两个 Out](https://community.aws/content/2k5wK9P1oSC9I4ZzuSLWynsiJaa/extend-amazon-ecs-across-two-outposts-racks) [posts 机架的 Amazon](https://aws.amazon.com/blogs/containers/deploy-an-amazon-eks-cluster-across-aws-outposts-with-intra-vpc-communication/) EKS 集群。 AWS Outposts
![\[该图显示了具有多个逻辑 Outposts 的单个 VPC 的网络路径\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/aws-outposts-high-availability-design/images/page-49-single-vpc-multiple-outposts.png)
Outposts-to-Outposts 通过该区域的流量路由被阻止，因为这是一种反模式。与通过客户 WAN 路由流量相比，此类流量会产生双向出站费，并且延迟要高得多。
# Outposts 机架 VPC 间路由
部署在不同位置的两个独立的 Outposts 上的资源 VPCs 可以在客户网络中相互通信。部署此架构使您能够 Outposts-to-Outposts通过本地本地和广域网路由流量，从而添加通往对应前哨/VPC 子网的路由。
![\[该图显示了具有多个逻辑 Outposts 的多个 VPC 的网络路径\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/aws-outposts-high-availability-design/images/page-50-multiple-vpc-multiple-outposts-networking-path.png)
针对防范更大规模的故障模式的建议实操：
+ 部署多个锚定在多个区域的 Outposts。 AZs
+ 在多前哨基地部署中， VPCs 对每个前哨基地分别使用。
# Outposts 上的 Route 53 本地解析器
当 AWS Outposts 服务链接受到暂时断开连接的影响时，本地 DNS 解析就会失败，这使得应用程序和服务很难发现其他服务，即使它们在同一 Outposts 机架上运行也是如此。但是，在 Route 53 Resolver 开启后 AWS Outposts，应用程序和服务将继续受益于本地 DNS 解析以发现其他服务，即使在与父 AWS 区域服务器的连接中断的情况下也是如此。同时，对于本地主机名的 DNS 解析，Outposts 上的 Route 53 解析器有助于减少延迟，因为查询结果在本地缓存和提供，同时与 Route 53 解析器端点完全集成。
Route 53 解析器入站终端节点将他们从 VPC 外部收到的 DNS 查询转发给在 Outposts 中运行的解析器。相比之下，Route 53 Resolver Outbound 允许 Route 53 解析器将 DNS 查询转发给您在本地网络上管理的 DNS 解析器，如下图所示。
![\[该图显示了 Outposts 上的 53 号公路解析器\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/aws-outposts-high-availability-design/images/page-51-route53-resolver-outposts.png)
## Outposts 上的 Route 53 Resolver 注意事项
请考虑以下事项：
+ 你必须在 Outposts 上启用 Route 53 Resolver，它适用于整个 Outposts 部署，即使这涉及单个 Outposts ID 下的多个计算机架。
+ 要启用此功能，您的 Outposts 必须有足够的计算容量来部署本地解析器，其形式为任何 c5.xlarge、m5.large 或 m5.xlarge 的至少 4 个 EC2 实例。
+ 如果您使用私有 DNS，则必须与所需的 Outposts 共享私有托管区域，以便将记录缓存在本地 VPCs的 Outposts 上的 Route 53 解析器中。
+ 为了通过入站和出站终端节点与本地 DNS 集成，您的 Outposts 必须具有足够的计算容量，以便每个 Route53 终端节点部署两个 EC2 实例。
# Outposts 上的 EKS 本地集群
当 Outposts 服务链路与父区域断开连接时，控制平面位于该区域的 EKS Extended Cluster 等服务可能会遇到挑战。挑战之一是EKS控制平面和工作节点之间的通信中断，以及 PODs. 尽管工作节点和工作节点 PODs 都可以继续在本地运行，也可以为驻留在 Outposts 上的应用程序提供服务，但 Kubernetes 控制平面可能会认为它们不健康，并计划在与控制平面的连接恢复时更换它们。恢复连接后，这可能会导致应用程序停机。
为了简化这一点，可以选择在 Outposts 上托管整个 EKS 集群。在这种配置中，Kubernetes 控制平面和你的工作节点都使用你的 Outposts 计算容量在本地运行。这样，即使您的服务链接连接暂时中断以及恢复后，您的集群仍能继续运行。
![\[Outposts 上的 Amazon EKS 本地集群\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/aws-outposts-high-availability-design/images/page-52-eks-local-cluster-outposts.png)
## Outposts 上的 EKS 本地集群注意事项
在 Outposts 中部署 EKS 本地集群时，有一些注意事项：
+ 在断开连接期间，没有选项可以对集群本身执行任何需要添加新工作节点或自动扩展节点组的更改，前提是它依赖于父区域 EC2 和 ASG API 调用。 AWS
+ • e [ksc AWS Outposts](https://eksctl.io/usage/outposts/) tl 支持中列出了本地集群上的一组不支持的功能。 。