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 in 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 in AWS Outposts funktionieren wie Multi-AZ-Bereitstellungen in AWS-Regionen, jedoch mit 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 in AWS Outposts ist für alle unterstützten Versionen von MySQL und PostgreSQL in 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
Obwohl AWS wirtschaftlich angemessene Anstrengungen unternimmt, um DB-Instances bereitzustellen, die für hohe Verfügbarkeit konfiguriert sind, wird für die Verfügbarkeit ein Modell der geteilten 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 Ausfallsicherheit 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 Amazon-CloudWatch-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.
Angenommen, Ihre VPC enthält Subnet-A in Outpost-A und Subnet-B in Outpost-B. Outpost-A verwendet LocalGateway-A (LGW-A) und Outpost-B verwendet LocalGateway-B (LGW-B). LGW-A verfügt über RouteTable-A und LGW-B über RouteTable-B. Sie sollten sowohl RouteTable-A als auch RouteTable-B für den Replikationsdatenverkehr verwenden. Verknüpfen Sie dazu Ihre VPC sowohl mit RouteTable-A als auch mit RouteTable-B.
Weitere Informationen zum Erstellen einer Verknüpfung finden Sie im AWS CLI-Befehl create-local-gateway-route-table-vpc-association von Amazon-EC2.
-
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 das AWS-Konto, das die RDS-DB-Instances besitzt, Eigentümer der lokalen Gateway-Routing-Tabellen 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 verwendet es User Datagram Protocol (UDP) Port 500 und IP Security (IPSec) Network Address Translation Traversal (NAT-T) und den UDP-Port 4500.
Weitere Informationen zu CoIPs finden Sie unter Kundeneigene IP-Adressen für Amazon RDS on AWS Outposts in diesem Leitfaden und unter Kundeneigene IP-Adressen im AWS Outposts-Benutzerhandbuch.
Arbeiten mit API-Operationen für Amazon-EC2-Berechtigungen
Unabhängig davon, ob Sie CoIPs für Ihre DB-Instance in AWS Outposts verwenden, benötigt RDS Zugriff auf Ihre CoIP-Pool-Ressourcen. RDS kann die folgenden EC2-Berechtigungs-API-Operationen für COIPs in Ihrem Namen für Multi-AZ-Bereitstellungen 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 CoIPs finden Sie unter Kundeneigene IP-Adressen für Amazon RDS on AWS Outposts und unter Kundeneigene IP-Adressen im AWS Outposts-Benutzerhandbuch.
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, Ihren lokalen Gateway-Routing-Tabellen interne RDS-VPCs zuzuordnen, oder heben diese Berechtigung auf. Sie können diese Zuordnungen zwischen Routing-Tabelle und VPC mit den API-Operationen DescribeLocalGatewayRouteTableVpcAssociations anzeigen.
