Routing von Anwendungen und Arbeitslasten - AWS Outposts Überlegungen zu Design und Architektur für hohe Verfügbarkeit
Empfohlene Verfahren für das Routing von Anwendungen/Workloads:

Dieses Dokument wird derzeit aktualisiert. In der Zwischenzeit sind einige Inhalte möglicherweise nicht korrekt.

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.

Routing von Anwendungen und Arbeitslasten

Für Anwendungs-Workloads gibt es zwei Wege aus dem Outpost heraus:

  • Der Service-Link-Pfad

  • Der lokale Gateway-Pfad (LGW)

Sie konfigurieren die Routing-Tabellen des Outpost-Subnetzes, um zu steuern, welcher Pfad zum Erreichen der Zielnetzwerke verwendet werden soll. Routen, die auf LGW die verweisen, leiten den Verkehr vom lokalen Gateway zum lokalen Netzwerk weiter. Routen, die auf die Dienste und Ressourcen in der Region verweisen, z. B. Internet Gateway, NAT Gateway, Virtual Private GatewayTGW, und verwenden Service Link, um diese Ziele zu erreichen. Wenn Sie eine VPC Peering-Verbindung mit mehreren Personen VPCs auf demselben Außenposten haben, VPCs verbleibt der Verkehr zwischen den Außenposten und verwendet nicht den Service-Link zurück zur Region. Informationen zum VPC Peering finden Sie unter Connect VPCs using VPC Peering im VPCAmazon-Benutzerhandbuch.

Diagramm, das eine Visualisierung des Outpost-Servicelinks und der Netzwerkpfade zeigt LGW

Visualisierung der Outpost-Serviceverbindung und LGW der Netzwerkpfade

Bei der Planung des Anwendungsroutings sollten Sie darauf achten, dass sowohl der normale Betrieb als auch die eingeschränkte Routing- und Serviceverfügbarkeit bei Netzwerkausfällen berücksichtigt werden. Der Service Link-Pfad ist nicht verfügbar, wenn ein Outpost von der Region getrennt wird.

Sie sollten verschiedene Pfade bereitstellen und dynamisches Routing zwischen dem Outpost LGW und Ihren kritischen lokalen Anwendungen, Systemen und Benutzern konfigurieren. Redundante Netzwerkpfade ermöglichen es dem Netzwerk, den Datenverkehr um Ausfälle herum weiterzuleiten und sicherzustellen, dass lokale Ressourcen bei teilweisen Netzwerkausfällen mit Workloads kommunizieren können, die auf dem Outpost ausgeführt werden.

VPCOutpost-Routenkonfigurationen sind statisch. Sie konfigurieren Subnetz-Routing-Tabellen über AWS Management Console, CLIAPIs, und andere Infrastructure as Code (IaC) -Tools. Sie können die Subnetz-Routingtabellen jedoch nicht ändern, wenn die Verbindung unterbrochen wird. Sie müssen die Konnektivität zwischen dem Outpost und der Region wiederherstellen, um die Routing-Tabellen zu aktualisieren. Verwenden Sie für den normalen Betrieb dieselben Routen, die Sie bei Verbindungsabbrüchen verwenden möchten.

Ressourcen auf dem Outpost können das Internet über den Service-Link und ein Internet Gateway (IGW) in der Region oder über den Local Gateway (LGW) -Pfad erreichen. Durch die Weiterleitung des Internetverkehrs über den LGW Pfad und das lokale Netzwerk können Sie vorhandene lokale Interneteingangs- und -ausgangspunkte verwenden. Dies kann zu einer geringeren, höheren und niedrigeren Latenz führen MTUs AWS Gebühren für ausgehenden Datenverkehr im Vergleich zur Nutzung des Service-Link-Pfads zu einem in der Region. IGW

Wenn Ihre Anwendung lokal ausgeführt werden muss und über das öffentliche Internet zugänglich sein muss, sollten Sie den Anwendungsdatenverkehr über Ihre lokalen Internetverbindungen an die weiterleiten, um die Ressourcen auf dem LGW Outpost zu erreichen.

Sie können zwar Subnetze in einem Outpost wie öffentliche Subnetze in der Region konfigurieren, dies kann jedoch in den meisten Anwendungsfällen unerwünscht sein. Eingehender Internetverkehr erfolgt über AWS-Region und werden über den Service-Link zu den Ressourcen weitergeleitet, die auf dem Outpost laufen.

Der Antwortverkehr wird wiederum über den Service Link und wieder zurück über den AWS-Region ist Internetverbindungen. Dieses Verkehrsmuster kann die Latenz erhöhen und es fallen Gebühren für ausgehende Daten an, wenn der Verkehr die Region auf dem Weg zum Außenposten verlässt und wenn der Rückverkehr durch die Region zurückkehrt und ins Internet gelangt. Wenn Ihre Anwendung in der Region ausgeführt werden kann, ist die Region der beste Ort, um sie auszuführen.

Der Verkehr zwischen VPC Ressourcen (innerhalb derselbenVPC) folgt immer der lokalen VPC CIDR Route und wird von den impliziten VPC Routern zwischen den Subnetzen weitergeleitet.

Beispielsweise wird der Verkehr zwischen einer EC2 Instance, die auf dem Outpost läuft, und einem VPC Endpunkt in der Region immer über die Service-Verbindung geleitet.

Diagramm, das das lokale VPC Routing über die impliziten Router zeigt

Lokales VPC Routing durch die impliziten Router

  • Verwenden Sie nach Möglichkeit den Local Gateway (LGW) -Pfad anstelle des Service-Link-Pfads.

  • Leiten Sie den Internetverkehr über den LGW Pfad weiter.

  • Konfigurieren Sie die Outpost-Subnetz-Routingtabellen mit einer Reihe von Standardrouten. Diese werden sowohl für den normalen Betrieb als auch bei Verbindungsabbrüchen verwendet.

  • Stellen Sie redundante Netzwerkpfade zwischen dem Outpost LGW und wichtigen lokalen Anwendungsressourcen bereit. Verwenden Sie dynamisches Routing, um die Verkehrsumleitung bei Netzwerkausfällen vor Ort zu automatisieren.