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.
Arbeiten mit Multi-AZ-Bereitstellungen für Amazon RDS auf AWS Outposts
Für Multi-AZ-Bereitstellungen erstellt Amazon RDS eine primäre DB-Instance auf einem AWS Outpost. RDS repliziert die Daten synchron auf eine Standby-DB-Instance auf einem anderen Outpost.
Multi-AZ-Bereitstellungen AWS Outposts funktionieren wie Multi-AZ-Bereitstellungen in AWS-Regionen, jedoch mit den folgenden Unterschieden:
-
Sie benötigen eine lokale Verbindung zwischen zwei oder mehr Outposts.
-
Sie benötigen Customer-owned IP Pools (CoIP, kundeneigene IP-Pools). Weitere Informationen finden Sie unter Kundeneigene IP-Adressen für Amazon RDS on AWS Outposts.
-
Die Replikation läuft in Ihrem lokalen Netzwerk.
Multi-AZ on AWS Outposts ist für alle unterstützten Versionen von MySQL und PostgreSQL auf RDS on Outposts verfügbar. Lokale Backups werden für Multi-AZ-Bereitstellungen nicht unterstützt. Weitere Informationen finden Sie unter Erstellen von DB-Instances für Amazon RDS in AWS Outposts.
Arbeiten mit dem Modell der geteilten Verantwortung
Es werden zwar AWS wirtschaftlich vertretbare Anstrengungen unternommen, um DB-Instances bereitzustellen, die für hohe Verfügbarkeit konfiguriert sind, für die Verfügbarkeit wird jedoch ein Modell der gemeinsamen Verantwortung verwendet. Die Fähigkeit von RDS on Outposts zum Failover und Reparieren von DB-Instances erfordert, dass jeder Ihrer Outposts mit seiner AWS-Region verbunden ist.
RDS on Outposts erfordert auch Konnektivität zwischen dem Outpost, der die primäre DB-Instance hostet, und dem Outpost, der die Standby-DB-Instance für die synchrone Replikation hostet. Jede Auswirkung auf diese Verbindung kann verhindern, dass RDS on Outposts ein Failover durchführt.
Aufgrund der synchronen Datenreplikation kann es zu erhöhten Latenzen für eine standardmäßige Bereitstellung einer DB-Instance kommen. Die Bandbreite und Latenz der Verbindung zwischen dem Outpost, der die primäre DB-Instance hostet, und dem Outpost, der die Standby-DB-Instance hostet, wirken sich direkt auf Latenzen aus. Weitere Informationen finden Sie unter Voraussetzungen.
Verbessern der Verfügbarkeit
Wir empfehlen die folgenden Maßnahmen zur Verbesserung der Verfügbarkeit:
-
Weisen Sie Ihren unternehmenskritischen Anwendungen genügend zusätzliche Kapazität zu, um Wiederherstellung und Failover zu ermöglichen, wenn ein zugrunde liegendes Hostproblem vorliegt. Dies gilt für alle Outposts, die Subnetze in Ihrer DB-Subnetzgruppe enthalten. Weitere Informationen finden Sie unter Resilienz in AWS Outposts.
-
Stellen Sie redundante Netzwerkkonnektivität für Ihre Outposts bereit.
-
Verwenden Sie mehr als zwei Outposts. Mit mehr als zwei Outposts kann Amazon RDS eine DB-Instance wiederherstellen. RDS führt diese Wiederherstellung durch, indem es die DB-Instance auf einen anderen Outpost verschiebt, wenn der aktuelle Outpost ausfällt.
-
Stellen Sie zwei Stromquellen und redundante Netzwerkkonnektivität für Ihren Outpost bereit.
Wir empfehlen Folgendes für Ihre lokalen Netzwerke:
-
Die Latenz der Round Trip Time (RTT, Umlaufzeit) zwischen dem Outpost, der Ihre primäre DB-Instance hostet, und dem Outpost, der Ihre Standby-DB-Instance hostet, wirkt sich direkt auf die Schreiblatenz aus. Halten Sie die RTT-Latenz zwischen den AWS Outposts im niedrigen einstelligen Millisekundenbereich. Wir empfehlen nicht mehr als 5 Millisekunden, Ihre Anforderungen können jedoch variieren.
Die Nettoauswirkung auf die Netzwerklatenz finden Sie in den CloudWatch Amazon-Metriken für
WriteLatency. Weitere Informationen finden Sie unter CloudWatch Amazon-Metriken für Amazon RDS. -
Die Verfügbarkeit der Verbindung zwischen den Outposts beeinflusst die Gesamtverfügbarkeit Ihrer DB-Instances. Sorgen Sie für redundante Netzwerkkonnektivität zwischen den Outposts.
Voraussetzungen
Für Multi-AZ-Bereitstellungen in RDS on Outposts gelten folgende Voraussetzungen:
-
Richten Sie mindestens zwei Outposts ein, die über lokale Verbindungen verbunden und verschiedenen Availability Zones in einer AWS-Region angefügt sind.
-
Stellen Sie sicher, dass Ihre DB-Subnetzgruppen Folgendes enthalten:
-
Mindestens zwei Subnetze in mindestens zwei Availability Zones in einer bestimmten AWS-Region.
-
Subnetze nur in Outposts.
-
Mindestens zwei Subnetze in mindestens zwei Outposts innerhalb derselben Virtual Private Cloud (VPC).
-
-
Verknüpfen Sie die VPC Ihrer DB-Instance mit allen Ihren lokalen Gateway-Routing-Tabellen. Diese Verknüpfung ist notwendig, da die Replikation über Ihr lokales Netzwerk unter Verwendung der lokalen Gateways Ihrer Outposts läuft.
Nehmen wir beispielsweise an, dass Ihre VPC Subnetz-A in Outpost-A und Subnetz-B in Outpost-B enthält. Outpost-A verwendet -A ( LocalGatewayLGW-A) und Outpost-B verwendet -B (LGW-B). LocalGateway LGW-A hat -A und LGW-B hat -B. RouteTable RouteTable Sie möchten sowohl RouteTable -A als auch -B für den Replikationsverkehr verwenden. RouteTable Ordnen Sie dazu Ihre VPC sowohl RouteTable -A als auch -B zu RouteTable.
Weitere Informationen zum Erstellen einer Assoziation finden Sie im Amazon EC2 create-local-gateway-routetable-vpc-association AWS CLI EC2-Befehl.
-
Stellen Sie sicher, dass Ihre Outposts das kundeneigene IP (CoIP)-Routing verwenden. Jede Routing-Tabelle muss außerdem jeweils mindestens einen Adresspool haben. Amazon RDS weist jeweils eine zusätzliche IP-Adresse für die primäre und die Standby-DB-Instance für die Datensynchronisation zu.
-
Stellen Sie sicher, dass derjenige AWS-Konto , dem die RDS-DB-Instances gehören, auch Eigentümer der lokalen Gateway-Routentabellen und CoIP-Pools ist. Oder stellen Sie sicher, dass es Teil einer Resource-Access-Manager-Freigabe mit Zugriff auf die lokalen Gateway-Routing-Tabellen und CoIP-Pools ist.
-
Stellen Sie sicher, dass die IP-Adressen in Ihren CoIP-Pools von einem lokalen Outpost-Gateway an die anderen weitergeleitet werden können.
-
Vergewissern Sie sich, dass die CIDR-Blöcke der VPC (z. B. 10.0.0.0/4) und die CIDR-Blöcke Ihres CoIP-Pools keine IP-Adressen der Klasse E enthalten (240.0.0.0/4). RDS verwendet diese IP-Adressen intern.
-
Stellen Sie sicher, dass Sie ausgehenden und damit verbundenen eingehenden Datenverkehr korrekt eingerichtet haben.
RDS on Outposts stellt eine Virtual Private Network (VPN)-Verbindung zwischen der primären und der Standby-DB-Instance her. Damit dies ordnungsgemäß funktioniert, muss Ihr lokales Netzwerk ausgehenden und damit verbundenen eingehenden Datenverkehr für Internet Security Association and Key Management Protocol (ISAKMP) zulassen. Dazu werden UDP-Port 500 (User Datagram Protocol) und NAT-T (IP SecurityIPsec) Network Address Translation Traversal (NAT-T) über UDP-Port 4500 verwendet.
Weitere Informationen zu Co IPs finden Sie Kundeneigene IP-Adressen für Amazon RDS on AWS Outposts in diesem Handbuch und zu kundeneigenen IP-Adressen im Benutzerhandbuch.AWS Outposts
Arbeiten mit API-Operationen für Amazon-EC2-Berechtigungen
Unabhängig davon, ob Sie Co IPs für Ihre DB-Instance verwenden AWS Outposts, benötigt RDS Zugriff auf Ihre CoIP-Pool-Ressourcen. RDS kann in Ihrem Namen für Multi-AZ-Bereitstellungen die folgenden EC2-Berechtigungs-API-Operationen für Co IPs aufrufen:
-
CreateCoipPoolPermission– Wenn Sie eine Multi-AZ-DB-Instance in RDS on Outposts erstellen -
DeleteCoipPoolPermission– Wenn Sie eine Multi-AZ-DB-Instance in RDS on Outposts löschen
Diese API-Operationen gewähren internen RDS-Konten die Berechtigung oder heben die Berechtigung auf, Elastic-IP-Adressen aus dem in der Berechtigung angegebenen CoIP-Pool zuzuweisen. Sie können diese IP-Adressen mit der API-Operation DescribeCoipPoolUsage anzeigen. Weitere Informationen zu Co IPs finden Sie unter Kundeneigene IP-Adressen für Amazon RDS on AWS Outposts und IP-Adressen im Besitz von Kunden im Benutzerhandbuch.AWS Outposts
RDS kann die folgenden EC2-Berechtigungs-API-Operationen für lokale Gateway-Routing-Tabellen in Ihrem Namen für Multi-AZ-Bereitstellungen aufrufen:
-
CreateLocalGatewayRouteTablePermission– Wenn Sie eine Multi-AZ-DB-Instance in RDS on Outposts erstellen -
DeleteLocalGatewayRouteTablePermission– Wenn Sie eine Multi-AZ-DB-Instance in RDS on Outposts löschen
Diese API-Operationen gewähren internen RDS-Konten die Berechtigung, interne RDS Ihren lokalen Gateway-Routentabellen zuzuordnen, oder entfernen diesen die Berechtigung. VPCs Sie können diese Zuordnungen zwischen Routing-Tabelle und VPC mit den API-Operationen DescribeLocalGatewayRouteTableVpcAssociations anzeigen.
