Anker-Konnektivität

Ein Outpost-Servicelink stellt eine Verbindung zu öffentlichen oder privaten Ankern (nicht zu beiden) in einer bestimmten Availability Zone (AZ) in der übergeordneten Region des Outposts her. Outpost-Server initiieren ausgehende Service VPN Link-Verbindungen von ihren Service Link-IP-Adressen zu den Ankerpunkten im Anker-AZ. Diese Verbindungen verwenden den TCP Port UDP 443. AWS ist verantwortlich für die Verfügbarkeit der Ankerpunkte in der Region.

Sie müssen sicherstellen, dass die IP-Adressen der Outpost-Servicelinks über Ihr Netzwerk eine Verbindung zu den Ankerpunkten im Anker-AZ herstellen können. Die Service Link-IP-Adressen müssen nicht mit anderen Hosts in Ihrem lokalen Netzwerk kommunizieren.

Öffentliche Ankerpunkte befinden sich in den öffentlichen IP-Bereichen der Region (in den EC2 CIDR Serviceblöcken) und können über das Internet oder AWS Direct Connect(DX) öffentliche virtuelle Schnittstellen (VIFs). Die Verwendung öffentlicher Ankerpunkte ermöglicht eine flexiblere Pfadauswahl, da der Service Link-Verkehr über jeden verfügbaren Pfad geleitet werden kann, der die Ankerpunkte im öffentlichen Internet erfolgreich erreichen kann.

Private Ankerpunkte ermöglichen es Ihnen, Ihre IP-Adressbereiche für die Ankerkonnektivität zu verwenden. Private Ankerpunkte werden in einem privaten Subnetz innerhalb eines dedizierten Subnetzes VPC mithilfe von vom Kunden zugewiesenen IP-Adressen erstellt. Das VPC wird erstellt in der AWS-Konto dem die Outpost-Ressource gehört und Sie sind dafür verantwortlich, dass sie verfügbar und richtig konfiguriert VPC ist (löschen Sie sie nicht!). Auf private Ankerpunkte muss über Direct Connect private zugegriffen werdenVIFs.

Sie sollten redundante Netzwerkpfade zwischen dem Outpost und den Ankerpunkten in der Region bereitstellen, wobei die Verbindungen auf separaten Geräten an mehr als einem Standort enden. Dynamisches Routing sollte so konfiguriert werden, dass der Verkehr automatisch auf alternative Pfade umgeleitet wird, wenn Verbindungen oder Netzwerkgeräte ausfallen. Sie sollten ausreichend Netzwerkkapazität bereitstellen, um sicherzustellen, dass der Ausfall eines WAN Pfads nicht die übrigen Pfade überlastet.

Das folgende Diagramm zeigt drei Outposts mit redundanten Netzwerkpfaden zu ihrem Anker AZs unter Verwendung von AWS Direct Connect sowie öffentliche Internetkonnektivität. Outpost A und Outpost B sind in verschiedenen Availability Zones in derselben Region verankert. Außenposten A ist mit privaten Ankerpunkten in AZ 1 der Region 1 verbunden. Außenposten B ist mit öffentlichen Ankerpunkten in AZ 2 der Region 1 verbunden. Außenposten C ist mit öffentlichen Ankern in AZ 1 der Region 2 verbunden.

Hochverfügbare Ankerkonnektivität mit AWS Direct Connect und öffentlicher Internetzugang

Outpost A verfügt über drei redundante Netzwerkpfade, um seinen privaten Ankerpunkt zu erreichen. Zwei Pfade sind über redundante Direct Connect-Schaltungen an einem einzigen Direct Connect-Standort verfügbar. Der dritte Pfad ist über einen Direct Connect-Stromkreis an einem zweiten Direct Connect-Standort verfügbar. Dieses Design hält den Service Link-Verkehr von Outpost A in privaten Netzwerken aufrecht und bietet Pfadredundanz, die den Ausfall einer der Direct Connect-Leitungen oder den Ausfall eines gesamten Direct Connect-Standorts ermöglicht.

Outpost B verfügt über vier redundante Netzwerkpfade, um seinen öffentlichen Ankerpunkt zu erreichen. Drei Wege sind über öffentlich VIFs bereitgestellte Direct Connect-Leitungen und Standorte von Outpost A verfügbar. Der vierte Pfad ist über den Kunden WAN und das öffentliche Internet verfügbar. Der Service Link-Verkehr von Outpost B kann über jeden verfügbaren Pfad geleitet werden, der die Ankerpunkte im öffentlichen Internet erfolgreich erreichen kann. Die Verwendung der Direct Connect-Pfade kann für eine konsistentere Latenz und eine höhere Bandbreitenverfügbarkeit sorgen, während der öffentliche Internetpfad für Disaster Recovery (DR) oder Bandbreitenerweiterungen verwendet werden kann.

Outpost C verfügt über zwei redundante Netzwerkpfade, um seinen öffentlichen Ankerpunkt zu erreichen. Outpost C wird in einem anderen Rechenzentrum als Outpost A und B eingesetzt. Das Rechenzentrum von Outpost C verfügt nicht über spezielle Leitungen, die mit dem Kunden verbunden sind. WAN Stattdessen verfügt das Rechenzentrum über redundante Internetverbindungen, die von zwei verschiedenen Internetdienstanbietern () bereitgestellt werden. ISPs Der Service Link-Verkehr von Outpost C kann über eines der ISP Netzwerke geleitet werden, um die Ankerpunkte im öffentlichen Internet zu erreichen. Dieses Design bietet Flexibilität bei der Weiterleitung des Service Link-Verkehrs über jede verfügbare öffentliche Internetverbindung. Der end-to-end Pfad hängt jedoch von öffentlichen Netzwerken von Drittanbietern ab, in denen Bandbreitenverfügbarkeit und Netzwerklatenz schwanken.

Der Netzwerkpfad zwischen einem Outpost und seinen Service Link-Ankerpunkten muss der folgenden Bandbreitenspezifikation entsprechen:

• 500 Mbit/s — 1 Gbit/s verfügbare Bandbreite pro Outpost-Rack (z. B. 3 Racks: 1,5 — 3 Gbit/s verfügbare Bandbreite)

Empfohlene Vorgehensweisen für hochverfügbare Anker-Konnektivität:

• Stellen Sie redundante Netzwerkpfade zwischen jedem Außenposten und seinen Ankerpunkten in der Region bereit.

• Verwenden Sie Direct Connect (DX) -Pfade, um Latenz und Bandbreitenverfügbarkeit zu kontrollieren.

• Stellen Sie sicher, dass TCP UDP Port 443 von den Outpost Service CIDR Link-Blöcken zu den EC2IP-Adressbereichen in der übergeordneten Region geöffnet ist (ausgehend). Stellen Sie sicher, dass die Ports auf allen Netzwerkpfaden geöffnet sind.

• Stellen Sie sicher, dass jeder Pfad die Anforderungen an Bandbreitenverfügbarkeit und Latenz erfüllt.

• Verwenden Sie dynamisches Routing, um die Verkehrsumleitung bei Netzwerkausfällen zu automatisieren.

• Testen Sie das Routing des Service Link-Datenverkehrs über jeden geplanten Netzwerkpfad, um sicherzustellen, dass der Pfad erwartungsgemäß funktioniert.