Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Größere Fehlermodi
Um HA-Architekturen so zu entwickeln, dass größere Ausfallmodi wie Rack-, Rechenzentrums-, Availability Zone- (AZ) oder Regionsausfälle vermieden werden, sollten Sie mehrere Outposts mit ausreichender Infrastrukturkapazität in separaten Rechenzentren mit unabhängiger Stromversorgung und WAN-Konnektivität bereitstellen. Sie verankern die Outposts in verschiedenen Availability Zones (AZs) innerhalb einer AWS-Region oder mehrerer Regionen. Sie sollten außerdem eine stabile und ausreichende site-to-site Konnektivität zwischen den Standorten bereitstellen, um die synchrone oder asynchrone Datenreplikation und die Umleitung des Workload-Datenverkehrs zu unterstützen. Abhängig von Ihrer Anwendungsarchitektur können Sie weltweit verfügbares [Amazon Route 53 DNS und Amazon Route 53](https://aws.amazon.com/route53/) [on Outposts](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/outpost-resolver.html) verwenden, um den Verkehr an den gewünschten Standort zu leiten und die Umleitung des Datenverkehrs an überlebende Standorte bei großen Ausfällen zu automatisieren.
# Outposts Rack Intra-VPC-Routing
AWS Outposts Das Rack unterstützt die [Intra-VPC-Kommunikation über mehrere Outposts hinweg](https://aws.amazon.com/blogs/compute/introducing-intra-vpc-communication-across-multiple-outposts-with-direct-vpc-routing/). Ressourcen auf zwei separaten logischen Outposts können miteinander kommunizieren, indem sie den Datenverkehr zwischen Subnetzen innerhalb derselben VPC, die sich über sie erstrecken, mithilfe der Outpost Local Gateways (LGW) weiterleiten. Bei der Intra-VPC-Kommunikation über mehrere Outposts hinweg können Sie die lokale Route in der mit dem Outposts-Subnetz verknüpften Routentabelle überschreiben, indem Sie dem anderen Outposts-Subnetz eine spezifischere Route hinzufügen und dabei das lokale LGW als nächsten Hop verwenden. Dies kann Vorteile bei der Architektur von Anwendungen bieten, die eine VPC zwischen zwei logischen Outposts als [Amazon ECS über zwei Outposts-Racks oder [Amazon](https://aws.amazon.com/blogs/containers/deploy-an-amazon-eks-cluster-across-aws-outposts-with-intra-vpc-communication/) EKS-Cluster](https://community.aws/content/2k5wK9P1oSC9I4ZzuSLWynsiJaa/extend-amazon-ecs-across-two-outposts-racks) erfordern. AWS Outposts
![\[Diagramm mit Netzwerkpfaden für eine einzelne VPC mit mehreren logischen Outposts\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/aws-outposts-high-availability-design/images/page-49-single-vpc-multiple-outposts.png)
Outposts-to-Outposts Die Weiterleitung des Datenverkehrs durch die Region ist blockiert, da es sich dabei um ein Anti-Pattern handelt. Bei einem solchen Verkehr würden Gebühren für ausgehenden Verkehr in beide Richtungen und eine deutlich höhere Latenz anfallen als bei der Weiterleitung des Datenverkehrs über das Kunden-WAN.
# Outposts Rack-Inter-VPC-Routing
Ressourcen auf zwei separaten Outposts, die an unterschiedlichen Standorten eingesetzt werden, VPCs können über das Kundennetzwerk miteinander kommunizieren. Outposts-to-OutpostsDurch die Bereitstellung dieser Architektur können Sie den Datenverkehr über Ihre lokalen lokalen Netzwerke und WAN-Netzwerke weiterleiten und Routen zu den entsprechenden Außenposten/VPC-Subnetzen hinzufügen.
![\[Diagramm mit Netzwerkpfaden für mehrere VPC mit mehreren logischen Outposts\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/aws-outposts-high-availability-design/images/page-50-multiple-vpc-multiple-outposts-networking-path.png)
Empfohlene Vorgehensweisen zum Schutz vor größeren Ausfallarten:
+ Setze mehrere Outposts ein, die in mehreren AZs Regionen verankert sind.
+ Verwenden Sie bei einer Bereitstellung mit mehreren Außenposten VPCs für jeden Außenposten separat.
# Lokaler Route-53-Resolver auf Outposts
Wenn die AWS Outposts Dienstverbindung durch eine vorübergehende Unterbrechung beeinträchtigt wird, schlägt die lokale DNS-Auflösung fehl, was es für Anwendungen und Dienste schwierig macht, andere Dienste zu erkennen, selbst wenn sie im selben Outposts-Rack ausgeführt werden. Wenn Route 53 Resolver aktiviert ist AWS Outposts, profitieren Anwendungen und Dienste jedoch weiterhin von der lokalen DNS-Auflösung, um andere Dienste zu erkennen — selbst wenn die Konnektivität zum übergeordneten AWS-Region Server unterbrochen wird. Gleichzeitig trägt der Route 53 Resolver on Outposts bei der DNS-Auflösung für lokale Hostnamen dazu bei, die Latenz zu reduzieren, da die Abfrageergebnisse zwischengespeichert und lokal bereitgestellt werden und gleichzeitig vollständig in die Route 53 Resolver-Endpunkte integriert sind.
Route 53 53-Resolver Eingehende Endpunkte leiten DNS-Anfragen, die sie von außerhalb der VPC erhalten, an den Resolver weiter, der in Outposts ausgeführt wird. Im Gegensatz dazu ermöglichen Route 53 Resolver Outbound Route 53 53-Resolvern, DNS-Abfragen an DNS-Resolver weiterzuleiten, die Sie in Ihrem lokalen Netzwerk verwalten, wie in der folgenden Abbildung dargestellt.
![\[Diagramm, das den Route 53-Resolver auf Outposts zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/aws-outposts-high-availability-design/images/page-51-route53-resolver-outposts.png)
## Überlegungen zu Route 53 Resolver on Outposts
Berücksichtigen Sie dabei Folgendes:
+ Sie müssen den Route 53 Resolver auf Outposts aktivieren, und er gilt für die gesamte Outposts-Bereitstellung, auch wenn diese mehrere Compute-Racks unter einer einzigen Outposts-ID umfasst.
+ Um diese Funktion zu aktivieren, müssen Ihre Outposts über genügend Rechenkapazität verfügen, um den lokalen Resolver in Form von mindestens 4 EC2 Instanzen von c5.xlarge, m5.large oder m5.xlarge bereitzustellen.
+ Wenn Sie privates DNS verwenden, müssen Sie die Private Hosted Zone mit den erforderlichen Outposts VPCs 'teilen, um die Datensätze lokal im Route 53 Resolver on Outposts zwischenzuspeichern.
+ Um die Integration mit lokalem DNS mit eingehenden und ausgehenden Endpunkten zu ermöglichen, müssen Ihre Outposts über genügend Rechenkapazität verfügen, um zwei EC2 Instanzen pro Route53-Endpunkt bereitzustellen.
# Lokaler EKS-Cluster auf Outposts
Wenn es zu Verbindungsabbrüchen zwischen Outposts und der übergeordneten Region kommt, kann es zu Problemen mit Diensten wie EKS Extended Cluster kommen, bei denen sich die Kontrollebene in der Region befindet. Zu den Herausforderungen gehört der Verlust der Kommunikation zwischen der EKS-Steuerebene und den Worker-Knoten und. PODs Obwohl beide Worker-Nodes weiterhin Anwendungen betreiben und warten PODs können, die sich lokal auf Outposts befinden, kann es sein, dass die Kubernetes-Kontrollebene sie als fehlerhaft einstuft und ihren Austausch einplant, wenn die Verbindung zur Kontrollebene wiederhergestellt ist. Dies kann zu Anwendungsausfällen führen, wenn die Konnektivität wiederhergestellt ist.
Um dies zu vereinfachen, besteht die Möglichkeit, Ihren gesamten EKS-Cluster auf Outposts zu hosten. In dieser Konfiguration werden sowohl die Kubernetes-Steuerebene als auch Ihre Worker-Knoten lokal vor Ort auf der Rechenkapazität Ihrer Outposts ausgeführt. Auf diese Weise funktioniert Ihr Cluster auch bei einem vorübergehenden Ausfall Ihrer Service Link-Verbindung und nach deren Wiederherstellung weiter.
![\[Lokaler Amazon EKS-Cluster auf Outposts\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/aws-outposts-high-availability-design/images/page-52-eks-local-cluster-outposts.png)
## Überlegungen zum lokalen EKS-Cluster auf Outposts
Es gibt einige Überlegungen, wenn ein lokaler EKS-Cluster in Outposts bereitgestellt wird:
+ Während einer Verbindungsunterbrechung gibt es keine Optionen, um Änderungen am Cluster selbst vorzunehmen, die das Hinzufügen neuer Worker-Knoten oder die automatische Skalierung einer Knotengruppe erfordern, solange dies von der übergeordneten Region abhängt EC2 und die AWS ASG-API-Aufrufe an sie richten.
+ [• In der eksctl-Unterstützung sind eine Reihe von Funktionen auf lokalen Clustern aufgeführt, die nicht unterstützt werden. AWS Outposts](https://eksctl.io/usage/outposts/) .