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.

Resilienz an der Peripherie

Die Säule Zuverlässigkeit umfasst die Fähigkeit eines Workloads, die vorgesehene Funktion korrekt und konsistent auszuführen, wenn dies erwartet wird. Dazu gehört auch die Fähigkeit, den Workload während seines gesamten Lebenszyklus zu bedienen und zu testen. In diesem Sinne müssen Sie beim Entwurf einer ausfallsicheren Architektur am Netzwerkrand zunächst überlegen, welche Infrastrukturen Sie für die Bereitstellung dieser Architektur verwenden werden. Es gibt drei mögliche Kombinationen, die mithilfe von AWS Lokale Zonen und implementiert werden können AWS Outposts: Outpost to Outpost, Outpost to Local Zone und Local Zone to Local Zone, wie in der folgenden Abbildung dargestellt. Zwar gibt es auch andere Möglichkeiten für ausfallsichere Architekturen, wie z. B. die Kombination von AWS Edge-Services mit herkömmlicher lokaler Infrastruktur oder AWS-Regionen, doch dieser Leitfaden konzentriert sich auf diese drei Kombinationen, die für das Design von Hybrid-Cloud-Diensten gelten

Überlegungen zur Infrastruktur

Eines der Kernprinzipien des Service Designs von At AWS besteht darin, einzelne Ausfallpunkte in der zugrunde liegenden physischen Infrastruktur zu vermeiden. Aufgrund dieses Prinzips verwenden AWS Software und Systeme mehrere Availability Zones und sind widerstandsfähig gegen den Ausfall einer einzelnen Zone. At the Edge AWS bietet Infrastrukturen, die auf Local Zones und Outposts basieren. Ein entscheidender Faktor für die Gewährleistung der Ausfallsicherheit beim Infrastrukturdesign ist daher die Definition, wo die Ressourcen einer Anwendung eingesetzt werden.

Lokale Zonen

Local Zones verhalten sich ähnlich wie Availability Zones innerhalb ihrer Zonen AWS-Region, da sie als Platzierungsort für zonale AWS Ressourcen wie Subnetze und EC2 Instances ausgewählt werden können. Sie befinden sich jedoch nicht in AWS-Region, sondern in der Nähe von großen Industrie- und IT-Zentren mit großer Bevölkerung, in denen es heute keine AWS-Region gibt. Trotzdem bieten sie weiterhin sichere Verbindungen mit hoher Bandbreite zwischen lokalen Workloads in der Local Zone und Workloads, die in der Local Zone ausgeführt werden. AWS-Region Daher sollten Sie Local Zones verwenden, um Workloads näher an Ihren Benutzern bereitzustellen, um Anforderungen mit geringer Latenz zu erfüllen.

Outposts

AWS Outposts ist ein vollständig verwalteter Service, der AWS Infrastruktur AWS-Services APIs, und Tools auf Ihr Rechenzentrum ausdehnt. Dieselbe Hardware-Infrastruktur, die in verwendet wird, AWS Cloud ist in Ihrem Rechenzentrum installiert. Outposts werden dann mit den nächstgelegenen AWS-Region verbunden. Sie können Outposts verwenden, um Ihre Workloads zu unterstützen, die eine geringe Latenz oder lokale Datenverarbeitungsanforderungen haben.

Availability Zones für Eltern

Jede lokale Zone oder jeder Außenposten hat eine übergeordnete Region (auch als Heimatregion bezeichnet). In der übergeordneten Region ist die Steuerungsebene der AWS Edge-Infrastruktur (Außenposten oder Lokale Zone) verankert. Im Fall von Local Zones ist die übergeordnete Region eine grundlegende architektonische Komponente einer Local Zone und kann von Kunden nicht geändert werden. AWS Outposts erweitert das AWS Cloud auf Ihre lokale Umgebung, sodass Sie während des Bestellvorgangs eine bestimmte Region und Availability Zone auswählen müssen. Diese Auswahl verankert die Kontrollebene Ihres Outposts-Einsatzes in der ausgewählten AWS Infrastruktur.

Wenn Sie Hochverfügbarkeitsarchitekturen am Edge entwickeln, muss die übergeordnete Region dieser Infrastrukturen, wie Outposts oder Local Zones, identisch sein, damit eine VPC zwischen ihnen erweitert werden kann. Diese erweiterte VPC ist die Grundlage für die Erstellung dieser Hochverfügbarkeitsarchitekturen. Wenn Sie eine hochbelastbare Architektur definieren, müssen Sie aus diesem Grund die übergeordnete Region und die Availability Zone der Region validieren, in der der Service verankert sein wird (oder ist). Wie in der folgenden Abbildung dargestellt, müssen Sie, wenn Sie eine Hochverfügbarkeitslösung zwischen zwei Außenstellen bereitstellen möchten, zwei verschiedene Availability Zones auswählen, um die Outposts zu verankern. Dies ermöglicht eine Multi-AZ-Architektur aus Sicht der Steuerungsebene. Wenn Sie eine hochverfügbare Lösung bereitstellen möchten, die eine oder mehrere Local Zones umfasst, müssen Sie zunächst die übergeordnete Availability Zone validieren, in der die Infrastruktur verankert ist. Verwenden Sie zu diesem Zweck den folgenden AWS CLI Befehl:

aws ec2 describe-availability-zones --zone-ids use1-mia1-az1

Ausgabe des vorherigen Befehls:

{     "AvailabilityZones": [         
          {
             "State": "available",
             "OptInStatus": "opted-in",
             "Messages": [],
             "RegionName": "us-east-1",
             "ZoneName": "us-east-1-mia-1a",
             "ZoneId": "use1-mia1-az1",
             "GroupName": "us-east-1-mia-1",
             "NetworkBorderGroup": "us-east-1-mia-1",
             "ZoneType": "local-zone",
             "ParentZoneName": "us-east-1d",
             "ParentZoneId": "use1-az2"
         }
     ]
 }

In diesem Beispiel ist die Miami Local Zone (us-east-1d-mia-1a1) in der us-east-1d-az2 Availability Zone verankert. Wenn Sie also eine robuste Architektur am Edge erstellen müssen, müssen Sie sicherstellen, dass die sekundäre Infrastruktur (entweder Outposts oder Local Zones) in einer anderen Availability Zone als verankert ist. us-east-1d-az2 us-east-1d-az1Wäre zum Beispiel gültig.

Das folgende Diagramm enthält Beispiele für hochverfügbare Edge-Infrastrukturen.

Überlegungen zum Netzwerk

In diesem Abschnitt werden erste Überlegungen zu Netzwerken am Netzwerkrand erörtert, hauptsächlich im Hinblick auf Verbindungen für den Zugriff auf die Edge-Infrastruktur. Es werden gültige Architekturen untersucht, die ein stabiles Netzwerk für den Service Link bereitstellen.

Resilienznetzwerke für Local Zones

Local Zones sind über mehrere redundante, sichere Hochgeschwindigkeitsverbindungen mit der übergeordneten Region verbunden, sodass Sie alle regionalen Dienste wie Amazon S3 und Amazon RDS problemlos nutzen können. Sie sind dafür verantwortlich, Konnektivität von Ihrer lokalen Umgebung oder Ihren Benutzern zur lokalen Zone bereitzustellen. Unabhängig von der gewählten Konnektivitätsarchitektur (z. B. VPN oder AWS Direct Connect) muss die Latenz, die über die Netzwerkverbindungen erreicht werden muss, gleichwertig sein, um jegliche Beeinträchtigung der Anwendungsleistung bei einem Ausfall einer Hauptverbindung zu vermeiden. Falls Sie diese verwenden AWS Direct Connect, entsprechen die entsprechenden Resilienzarchitekturen denen für den Zugriff auf AWS-Region, wie in den AWS Direct Connect Resilienz-Empfehlungen dokumentiert. Es gibt jedoch Szenarien, die hauptsächlich für internationale Local Zones gelten. In dem Land, in dem die Local Zone aktiviert ist, ist es mit nur einem einzigen AWS Direct Connect PoP unmöglich, die aus Gründen der AWS Direct Connect Resilienz empfohlenen Architekturen zu erstellen. Wenn Sie Zugriff auf nur einen einzigen AWS Direct Connect Standort haben oder Ausfallsicherheit benötigen, die über eine einzelne Verbindung hinausgeht, können Sie eine VPN-Appliance bei Amazon einrichten EC2 und AWS Direct Connect, wie im AWS Blogbeitrag Enabling high available connectivity from local to AWS Lokale Zonen dargestellt und besprochen.

Resilienznetzwerke für Outposts

Im Gegensatz zu Local Zones verfügen Outposts über redundante Konnektivität für den Zugriff auf Workloads, die in Outposts bereitgestellt werden, von Ihrem lokalen Netzwerk aus. Diese Redundanz wird durch zwei Outposts-Netzwerkgeräte () ONDs erreicht. Jedes OND benötigt mindestens zwei Glasfaserverbindungen mit 1 Gbit/s, 10 Gbit/s, 40 Gbit/s oder 100 Gbit/s zu Ihrem lokalen Netzwerk. Diese Verbindungen müssen als Link Aggregation Group (LAG) konfiguriert werden, um das skalierbare Hinzufügen weiterer Links zu ermöglichen.

Weitere Informationen zu dieser Konnektivität finden Sie in der AWS Outposts Dokumentation unter Lokale Netzwerkkonnektivität Outposts Outposts-Racks.

Für eine optimale Benutzererfahrung und Ausfallsicherheit AWS empfiehlt es sich, redundante Konnektivität mit mindestens 500 Mbit/s (1 Gbit/s ist besser) für die Service Link-Verbindung zum zu verwenden. AWS-Region Sie können AWS Direct Connect oder eine Internetverbindung für den Service Link verwenden. Mit diesem Minimum können Sie EC2 Instances starten, EBS-Volumes anhängen und auf Amazon EKS AWS-Services, Amazon EMR und CloudWatch Metriken zugreifen.

Das folgende Diagramm veranschaulicht diese Architektur für eine hochverfügbare private Verbindung.

Das folgende Diagramm veranschaulicht diese Architektur für eine hochverfügbare öffentliche Verbindung.

Skalierung Outposts Outposts-Rack-Bereitstellungen mit ACE-Racks

Das Aggregation, Core, Edge (ACE) -Rack dient als kritischer Aggregationspunkt für AWS Outposts Multi-Rack-Bereitstellungen und wird in erster Linie für Installationen mit mehr als drei Racks oder für die Planung future Erweiterungen empfohlen. Jedes ACE-Rack verfügt über vier Router, die Verbindungen mit 10 Gbit/s, 40 Gbit/s und 100 Gbit/s unterstützen (100 Gbit/s sind optimal). Jedes Rack kann für maximale Redundanz mit bis zu vier vorgelagerten Kundengeräten verbunden werden. ACE-Racks verbrauchen bis zu 10 kVA Strom und wiegen bis zu 705 Pfund. Zu den wichtigsten Vorteilen gehören geringere physische Netzwerkanforderungen, weniger Uplinks für Glasfaserkabel und weniger virtuelle VLAN-Schnittstellen. AWS überwacht diese Racks mithilfe von Telemetriedaten über VPN-Tunnel und arbeitet bei der Installation eng mit den Kunden zusammen, um die richtige Stromverfügbarkeit, Netzwerkkonfiguration und optimale Platzierung sicherzustellen. Die ACE-Rack-Architektur bietet im Zuge der Skalierung der Bereitstellungen einen immer größeren Nutzen. Sie vereinfacht effektiv die Konnektivität und reduziert gleichzeitig die Komplexität und die physischen Port-Anforderungen in größeren Installationen.  Weitere Informationen finden Sie im AWS Blogbeitrag Skalierung von Rack-Bereitstellungen mit ACE AWS Outposts Rack.

Verteilung von Instanzen auf Outposts und Local Zones

Outposts und Local Zones haben eine begrenzte Anzahl von Rechenservern. Wenn Ihre Anwendung mehrere verwandte Instanzen bereitstellt, werden diese Instanzen möglicherweise auf demselben Server oder auf Servern im selben Rack bereitgestellt, sofern sie nicht unterschiedlich konfiguriert sind. Zusätzlich zu den Standardoptionen können Sie Instances auf mehrere Server verteilen, um das Risiko zu minimieren, dass verwandte Instances auf derselben Infrastruktur ausgeführt werden. Sie können Instances auch mithilfe von Partitionsplatzierungsgruppen auf mehrere Racks verteilen. Dies wird als Spread-Rack-Verteilungsmodell bezeichnet. Verwenden Sie die automatische Verteilung, um Instanzen auf Partitionen in der Gruppe zu verteilen, oder stellen Sie Instanzen auf ausgewählten Zielpartitionen bereit. Durch die Bereitstellung von Instances auf Zielpartitionen können Sie ausgewählte Ressourcen im selben Rack bereitstellen und gleichzeitig andere Ressourcen auf mehrere Racks verteilen. Outposts bietet auch eine weitere Option namens Spread Host, mit der Sie Ihre Arbeitslast auf Host-Ebene verteilen können. Das folgende Diagramm zeigt die Verteilungsoptionen „Spread Rack“ und „Spread Host“.

Amazon RDS Multi-AZ im AWS Outposts

Wenn Sie Multi-AZ-Instance-Bereitstellungen auf Outposts verwenden, erstellt Amazon RDS zwei Datenbank-Instances in zwei Outposts. Jeder Outpost läuft auf seiner eigenen physischen Infrastruktur und stellt eine Verbindung zu verschiedenen Availability Zones in einer Region her, um eine hohe Verfügbarkeit zu gewährleisten. Wenn zwei Outposts über eine vom Kunden verwaltete lokale Verbindung verbunden sind, verwaltet Amazon RDS die synchrone Replikation zwischen der primären und der Standby-Datenbank-Instance. Im Falle eines Software- oder Infrastrukturausfalls stuft Amazon RDS die Standby-Instance automatisch in die primäre Rolle hoch und aktualisiert den DNS-Eintrag so, dass er auf die neue primäre Instance verweist. Für Multi-AZ-Bereitstellungen erstellt Amazon RDS eine primäre DB-Instance in einem -Outpost und repliziert die Daten synchron auf eine Standby-DB-Instance in einem anderen Outpost. Multi-AZ-Bereitstellungen auf Outposts funktionieren wie Multi-AZ-Bereitstellungen in AWS-Regionen, mit den folgenden Unterschieden:

Multi-AZ-Bereitstellungen sind für alle unterstützten Versionen von MySQL und PostgreSQL auf Amazon RDS on Outposts verfügbar. Lokale Backups werden für Multi-AZ-Bereitstellungen nicht unterstützt.

Das folgende Diagramm zeigt die Architektur für Multi-AZ-Konfigurationen von Amazon RDS on Outposts.

Failover-Mechanismen

Lastenausgleich und automatische Skalierung

Elastic Load Balancing (ELB) verteilt Ihren eingehenden Anwendungsdatenverkehr automatisch auf alle EC2 Instances, die Sie ausführen. ELB hilft bei der Verwaltung eingehender Anfragen, indem es den Datenverkehr optimal weiterleitet, sodass keine einzelne Instanz überlastet wird. Um ELB mit Ihrer Amazon EC2 Auto Scaling Scaling-Gruppe zu verwenden, fügen Sie den Load Balancer Ihrer Auto Scaling Scaling-Gruppe hinzu. Dadurch wird die Gruppe beim Load Balancer registriert, der als zentrale Anlaufstelle für den gesamten eingehenden Webverkehr zu Ihrer Gruppe fungiert. Wenn Sie ELB mit Ihrer Auto Scaling Scaling-Gruppe verwenden, ist es nicht erforderlich, einzelne EC2 Instances beim Load Balancer zu registrieren. Instances, die von Ihrer Auto-Scaling-Gruppe gestartet werden, werden automatisch beim Load Balancer registriert. Ebenso werden Instances, die von Ihrer Auto Scaling Scaling-Gruppe beendet wurden, automatisch vom Load Balancer abgemeldet. Nachdem Sie Ihrer Auto Scaling Scaling-Gruppe einen Load Balancer hinzugefügt haben, können Sie Ihre Gruppe so konfigurieren, dass ELB-Metriken (wie die Anzahl der Application Load Balancer Balancer-Anfragen pro Ziel) verwendet werden, um die Anzahl der Instances in der Gruppe bei schwankendem Bedarf zu skalieren. Optional können Sie ELB-Zustandsprüfungen zu Ihrer Auto Scaling-Gruppe hinzufügen, sodass Amazon EC2 Auto Scaling fehlerhafte Instances anhand dieser Zustandsprüfungen identifizieren und ersetzen kann. Sie können auch einen CloudWatch Amazon-Alarm erstellen, der Sie benachrichtigt, wenn die Anzahl gesunder Hosts der Zielgruppe niedriger als zulässig ist.

Das folgende Diagramm zeigt, wie ein Application Load Balancer Workloads auf Amazon EC2 in verwaltet. AWS Outposts

Das folgende Diagramm zeigt eine ähnliche Architektur für Amazon EC2 in Local Zones.

Amazon Route 53 für DNS-Failover

Wenn mehrere Ressourcen dieselbe Funktion ausführen, z. B. mehrere HTTP- oder Mail-Server, können Sie Amazon Route 53 so konfigurieren, dass der Zustand Ihrer Ressourcen überprüft und DNS-Abfragen beantwortet werden, indem nur die fehlerfreien Ressourcen verwendet werden. Nehmen wir zum Beispiel an, dass Ihre Website,example.com, auf zwei Servern gehostet wird. Ein Server befindet sich in einer lokalen Zone und der andere Server in einem Outpost. Sie können Route 53 so konfigurieren, dass der Zustand dieser Server überprüft und DNS-Anfragen beantwortet werden, example.com indem nur die Server verwendet werden, die derzeit fehlerfrei sind. Wenn Sie Aliaseinträge verwenden, um den Verkehr an ausgewählte AWS Ressourcen weiterzuleiten, z. B. an ELB-Loadbalancer, können Sie Route 53 so konfigurieren, dass der Zustand der Ressource bewertet wird und der Verkehr nur an fehlerfreie Ressourcen weitergeleitet wird. Wenn Sie einen Aliaseintrag konfigurieren, um den Zustand einer Ressource zu bewerten, müssen Sie keine Integritätsprüfung für diese Ressource erstellen.

Das folgende Diagramm veranschaulicht die Route 53-Failover-Mechanismen.

Amazon Route 53 Resolver auf AWS Outposts

Amazon Route 53 Resolverist in Outposts-Racks erhältlich. Es bietet Ihren lokalen Diensten und Anwendungen eine lokale DNS-Auflösung direkt von Outposts aus. Lokale Route 53 Resolver-Endpunkte ermöglichen auch die DNS-Auflösung zwischen Outposts und Ihrem lokalen DNS-Server. Route 53 Resolver on Outposts trägt dazu bei, die Verfügbarkeit und Leistung Ihrer lokalen Anwendungen zu verbessern.

Einer der typischen Anwendungsfälle für Outposts ist die Bereitstellung von Anwendungen, die einen Zugriff auf lokale Systeme mit geringer Latenz erfordern, wie z. B. Fabrikausrüstung, Hochfrequenz-Handelsanwendungen und medizinische Diagnosesysteme.

Wenn Sie sich für die Verwendung lokaler Route 53-Resolver auf Outposts entscheiden, profitieren Anwendungen und Dienste weiterhin von der lokalen DNS-Auflösung, um andere Dienste zu erkennen, auch wenn die Konnektivität zu einem übergeordneten Element unterbrochen AWS-Region wird. Lokale Resolver tragen auch dazu bei, die Latenz bei DNS-Auflösungen zu reduzieren, da die Abfrageergebnisse zwischengespeichert und lokal von den Outposts aus bereitgestellt werden, wodurch unnötige Roundtrips zum übergeordneten Objekt vermieden werden. AWS-Region Alle DNS-Auflösungen für Anwendungen in Outposts VPCs , die privates DNS verwenden, werden lokal bereitgestellt.

Dieser Start aktiviert nicht nur lokale Resolver, sondern auch lokale Resolver-Endpunkte. Mit ausgehenden Route 53 Resolver-Endpunkten können Route 53-Resolver DNS-Abfragen an von Ihnen verwaltete DNS-Resolver weiterleiten, z. B. in Ihrem lokalen Netzwerk. Im Gegensatz dazu leiten eingehende Route 53 Resolver-Endpunkte die DNS-Abfragen, die sie von außerhalb der VPC erhalten, an den Resolver weiter, der auf Outposts ausgeführt wird. Es ermöglicht Ihnen, DNS-Abfragen für Dienste, die auf einer privaten Outposts-VPC bereitgestellt werden, von außerhalb dieser VPC zu senden. Weitere Informationen zu eingehenden und ausgehenden Endpunkten finden Sie in der Route 53-Dokumentation unter Auflösen von DNS-Abfragen zwischen VPCs und Ihrem Netzwerk.