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.
Konzepte und Terminologie zu RDS-Proxy
Sie können die Verbindungsverwaltung für Ihre Amazon-RDS-DB-Instances vereinfachen, indem Sie RDS-Proxy verwenden.
RDS-Proxy verarbeitet den Netzwerkverkehr zwischen der Clientanwendung und der Datenbank. Es tut dies auf aktive Weise, indem es das Datenbankprotokoll erfasst Anschließend passt er sein Verhalten basierend auf den SQL-Operationen aus Ihrer Anwendung und den Ergebnismengen aus der Datenbank an.
RDS-Proxy reduziert den Arbeitsspeicher- und CPU-Overhead für die Verbindungsverwaltung in Ihrer Datenbank. Die Datenbank benötigt weniger Arbeitsspeicher und CPU-Ressourcen, wenn Anwendungen viele gleichzeitige Verbindungen öffnen. Es erfordert auch keine Logik in Ihren Anwendungen, um Verbindungen zu schließen und wieder zu öffnen, die für eine lange Zeit inaktiv bleiben. Ebenso erfordert es weniger Anwendungslogik, um Verbindungen im Falle eines Datenbankproblems wiederherzustellen.
Die Infrastruktur für RDS Proxy ist hochverfügbar und wird über mehrere Availability Zones (AZs) bereitgestellt. Berechnung, Arbeitsspeicher und Speicher für RDS-Proxy sind unabhängig von Ihrer RDS-DB-Instance. Diese Trennung hilft, den Overhead auf Ihren Datenbankservern zu senken, sodass sie ihre Ressourcen für die Bereitstellung von Datenbank-Workloads einsetzen können. Die RDS-Proxy-Rechenressourcen sind serverless und werden automatisch basierend auf der Datenbank-Workload skaliert.
Überblick über RDS-Proxy-Konzepte
RDS-Proxy verbreitet die Infrastruktur zum Ausführen des Verbindungspoolings und die anderen Funktionen, die in den folgenden Abschnitten beschrieben werden. Die in der RDS-Konsole dargestellten Proxys werden auf der Seite Proxys angezeigt.
Jeder Proxy verarbeitet Verbindungen zu einer einzelnen RDS-DB-Instance. Bei Multi-AZ-RDS-DB-Instances oder -Clustern bestimmt der Proxy die aktuelle Writer-Instance automatisch.
Die Verbindungen, die ein Proxy offen hält und für Ihre Datenbankanwendung verfügbar macht, bilden den Verbindungspool.
Standardmäßig kann RDS-Proxy eine Verbindung nach jeder Transaktion in Ihrer Sitzung wiederverwenden. Diese Wiederverwendung auf Transaktionsebene wird als Multiplexing bezeichnet. Wenn RDS-Proxy vorübergehend eine Verbindung aus dem Verbindungspool entfernt wird, um sie wiederzuverwenden, wird dieser Vorgang als Ausleihen der Verbindung bezeichnet. Wenn dies sicher ist, wird diese Verbindung an den Verbindungspool RDS-Proxy zurückgegeben.
In einigen Fällen kann RDS-Proxy nicht gewährleisten, dass eine Datenbankverbindung außerhalb der aktuellen Sitzung sicher wiederzuverwenden ist. In diesen Fällen bleibt die Sitzung auf derselben Verbindung erhalten, bis die Sitzung beendet ist. Dieses Fallback-Verhalten wird als Fixierung (Pinning) bezeichnet.
Ein Proxy hat einen Standard-Endpunkt. Sie stellen eine Verbindung mit diesem Endpunkt her, wenn Sie mit einer Amazon-RDS-DB-Instance arbeiten. Sie tun dies, anstatt eine Verbindung zu dem read/write Endpunkt herzustellen, der direkt mit dem verbunden ist. Für RDS-DB-Cluster können Sie auch zusätzliche read/write und schreibgeschützte Endpunkte erstellen. Weitere Informationen finden Sie unter Überblick über Proxy-Endpunkte.
Beispielsweise können Sie für read/write Verbindungen ohne Verbindungspooling weiterhin eine Verbindung zum Cluster-Endpunkt herstellen. Sie können weiterhin eine Verbindung zum Leser-Endpunkt für schreibgeschützte Verbindungen mit Lastenausgleich herstellen. Sie können weiterhin eine Verbindung zu den Instance-Endpunkten für die Diagnose und Behebung von Fehlern in bestimmten DB-Instances innerhalb eines Clusters herstellen. Wenn Sie andere AWS Dienste verwenden, z. B. AWS Lambda um eine Verbindung zu RDS-Datenbanken herzustellen, ändern Sie deren Verbindungseinstellungen, sodass der Proxy-Endpunkt verwendet wird. Beispielsweise geben Sie den Proxy-Endpunkt an, damit Lambda-Funktionen auf Ihre Datenbank zugreifen und gleichzeitig die RDS-Proxy-Funktionalität nutzen können.
Jeder Proxy enthält eine Zielgruppe. Diese Zielgruppe verkörpert die RDS-DB-Instance, mit dem der Proxy eine Verbindung herstellen kann. Die RDS-DB-Instance, die/der mit einem Proxy verknüpft ist, wird als Ziel dieses Proxys bezeichnet. Wenn Sie einen Proxy über die Konsole erstellen, erstellt RDS-Proxy auch die entsprechende Zielgruppe und registriert die zugeordneten Ziele automatisch.
Eine Engine-Familie ist eine verwandte Gruppe von Datenbank-Engines, die dasselbe DB-Protokoll verwenden. Sie wählen die Engine-Familie für jeden Proxy, den Sie erstellen.
Verbindungspooling
Jeder Proxy führt ein Verbindungspooling für die Writer- und Reader-Instance der zugehörigen RDS-Datenbank aus. Das Verbindungspooling ist eine Optimierung, die den Overhead reduziert, der mit dem Öffnen und Beenden von Verbindungen und dem Vorhandensein vieler aktiver Verbindungen gleichzeitig verbunden ist. Dieser Overhead umfasst den Arbeitsspeicher, der für die Verarbeitung jeder neuen Verbindung erforderlich ist. Es ist außerdem CPU-Overhead erforderlich, um jede Verbindung zu schließen und eine neue zu öffnen. Beispiele hierfür sind Transport Layer Security/Secure Sockets Layer (TLS/SSL), Handshaking, Authentifizierung, Verhandlungsmöglichkeiten usw. Das Verbindungspooling vereinfacht Ihre Anwendungslogik. Sie müssen keinen Anwendungscode schreiben, um die Anzahl gleichzeitig geöffneter Verbindungen zu minimieren.
Jeder Proxy führt darüber hinaus Multiplexing von Verbindungen aus, auch bekannt als Wiederverwendung von Verbindungen. Beim Multiplexing führt RDS-Proxy alle Operationen für eine Transaktion mit einer zugrunde liegenden Datenbankverbindung aus. RDS kann dann eine andere Verbindung für die nächste Transaktion verwenden. Sie können viele gleichzeitige Verbindungen zum Proxy öffnen und der Proxy hält eine geringere Anzahl von Verbindungen zur DB-Instance oder zum Cluster offen. Dadurch wird der Speicher-Overhead für Verbindungen auf dem Datenbankserver weiter minimiert. Diese Technik reduziert auch die Wahrscheinlichkeit des Fehlers "zu viele Verbindungen".
RDS-Proxy-Sicherheit
RDS Proxy verwendet die vorhandenen RDS-Sicherheitsmechanismen wie TLS/SSL und AWS Identity and Access Management (IAM). Allgemeine Informationen zu diesen Sicherheitsfunktionen finden Sie unter Sicherheit in Amazon RDS. Sie sollten sich außerdem unbedingt damit vertraut machen, wie RDS mit Authentifizierung, Autorisierung und anderen Sicherheitsbereichen arbeitet.
RDS-Proxy kann als zusätzliche Sicherheitsebene zwischen Clientanwendungen und der zugrunde liegenden Datenbank fungieren. Sie können beispielsweise über TLS 1.3 eine Verbindung zum Proxy herstellen, selbst wenn die zugrunde liegende DB-Instance eine ältere Version von TLS unterstützt. Sie können mithilfe einer IAM-Rolle eine Verbindung zum Proxy herstellen, auch wenn der Proxy mithilfe der Authentifizierungsmethode Datenbankbenutzer und Kennwort eine Verbindung zur Datenbank herstellt. Mit dieser Technik können Sie hohe Authentifizierungsanforderungen für Datenbankanwendungen ohne einen kostspieligen Migrationsaufwand für die DB-Instances selbst erzwingen.
Mit RDS Proxy können Sie die folgenden Authentifizierungsmethoden verwenden:
-
Anmeldeinformationen für die Datenbank
-
Standard-IAM-Authentifizierung
-
End-to-end IAM-Authentifizierung
Verwenden von IAM mit RDS-Proxy
RDS Proxy bietet zwei Methoden der IAM-Authentifizierung:
-
Standard-IAM-Authentifizierung: Erzwingen Sie die IAM-Authentifizierung für Verbindungen zu Ihrem Proxy, während der Proxy mithilfe der in Secrets Manager gespeicherten Anmeldeinformationen eine Verbindung zur Datenbank herstellt. Dadurch wird die IAM-Authentifizierung für den Datenbankzugriff erzwungen, auch wenn die Datenbanken die native Passwortauthentifizierung verwenden. Der Proxy ruft die Datenbankanmeldedaten von Secrets Manager ab und wickelt die Authentifizierung gegenüber der Datenbank im Namen Ihrer Anwendung ab.
-
End-to-end IAM-Authentifizierung: Erzwingt die IAM-Authentifizierung für Verbindungen direkt von Ihren Anwendungen zu Ihrer Datenbank über den Proxy. End-to-end Die IAM-Authentifizierung vereinfacht Ihre Sicherheitskonfiguration und vermeidet die Verwaltung von Datenbankanmeldedaten in Secrets Manager. Diese zusätzliche Sicherheitsebene erzwingt eine IAM-basierte Zugriffskontrolle von der Client-Anwendung zur Datenbank.
Um die Standard-IAM-Authentifizierung zu verwenden, konfigurieren Sie Ihren Proxy so, dass Secrets Manager Manager-Geheimnisse für die Authentifizierung verwendet werden, und aktivieren Sie die IAM-Authentifizierung für Client-Verbindungen. Ihre Anwendungen authentifizieren sich beim Proxy mithilfe von IAM, während sich der Proxy mit den von Secrets Manager abgerufenen Anmeldeinformationen gegenüber der Datenbank authentifiziert.
Um die end-to-end IAM-Authentifizierung zu verwenden, konfigurieren Sie Ihren Proxy so, dass er die IAM-Authentifizierung verwendet, wenn Sie das Standardauthentifizierungsschema bei der Erstellung oder Änderung Ihres Proxys festlegen.
Für die end-to-end IAM-Authentifizierung müssen Sie die dem Proxy zugeordnete IAM-Rolle aktualisieren, um die Berechtigung zu erteilen. rds-db:connect Mit der end-to-end IAM-Authentifizierung entfällt die Notwendigkeit, einzelne Datenbankbenutzer über Secrets Manager Secrets beim Proxy zu registrieren.
Verwendung TLS/SSL mit RDS Proxy
Sie können mithilfe des TLS/SSL Protokolls eine Verbindung zum RDS-Proxy herstellen.
Anmerkung
RDS Proxy verwendet Zertifikate von AWS Certificate Manager (ACM). Wenn Sie RDS-Proxy verwenden, müssen Sie keine Amazon-RDS-Zertifikate herunterladen oder Anwendungen aktualisieren, die RDS-Proxy-Verbindungen verwenden.
Um TLS für alle Verbindungen zwischen dem Proxy und der Datenbank zu erzwingen, können Sie beim Erstellen eines Proxys die Einstellung Transport Layer Security erforderlich angeben, wenn Sie einen Proxy in der AWS-Managementkonsole erstellen oder ändern.
RDS Proxy kann auch sicherstellen, dass Ihre Sitzung TLS/SSL zwischen Ihrem Client und dem RDS-Proxy-Endpunkt verwendet wird. Damit RDS-Proxy so verfährt, müssen Sie die clientseitige Anforderung festlegen. Für SSL-Verbindungen mit einer Datenbank unter Verwendung von RDS-Proxy werden keine SSL-Sitzungsvariablen festgelegt.
-
Geben Sie für RDS für MySQL die clientseitige Anforderung mit dem Parameter
--ssl-modean, wenn Sie den Befehlmysqlausführen. -
Geben Sie für Amazon RDS PostgreSQL
sslmode=requireals Teil derconninfo-Zeichenfolge an, wenn Sie den Befehlpsqlausführen.
RDS-Proxy unterstützt die TLS-Protokollversionen 1.0, 1.1 und 1.2. Sie können eine Verbindung mit dem Proxy herstellen, indem Sie eine höhere TLS-Version verwenden, als Sie in der zugrunde liegenden Datenbank verwenden.
Standardmäßig richten Client-Programme eine verschlüsselte Verbindung mit RDS-Proxy ein, wobei weitere Kontrolle über die Option --ssl-mode verfügbar ist. Clientseitig unterstützt RDS-Proxy alle SSL-Modi.
Für den Client sind die SSL-Modi die folgenden:
- PREFERRED
-
SSL ist die erste Wahl, aber nicht erforderlich.
- DISABLED
-
SSL ist nicht zulässig.
- REQUIRED
-
SSL erzwingen.
- VERIFY_CA
-
SSL erzwingen und die Zertifizierungsstelle (CA) überprüfen.
- VERIFY_IDENTITY
-
SSL erzwingen und die CA sowie den CA-Hostname überprüfen.
Bei Verwendung eines Clients mit --ssl-mode VERIFY_CA oder VERIFY_IDENTITY, geben Sie die Option --ssl-ca an, die auf eine CA im .pem-Format verweist. Laden Sie für die zu verwendende .pem Datei alle Root-CA PEMs von Amazon Trust Services.pem Datei.
RDS-Proxy verwendet Platzhalterzertifikate, die sowohl für eine Domain als auch für deren Unterdomains gelten. Wenn Sie den mysql-Client für die Verbindung mit dem SSL-Modus VERIFY_IDENTITY verwenden, müssen Sie derzeit den MySQL 8.0-kompatiblen Befehl mysql verwenden.
Failover
Failover ist eine Funktion mit hoher Verfügbarkeit, die eine Datenbank-Instance durch eine andere ersetzt, wenn die ursprüngliche Instance nicht verfügbar ist. Ein Failover kann aufgrund eines Problems mit einer Datenbank-Instance auftreten. Er kann aber auch Teil normaler Wartungsverfahren sein, z. B. während eines Datenbank-Upgrades. Failover gilt für RDS-DB-Instances in einer Multi-AZ-Konfiguration.
Die Verbindung über einen Proxy macht Ihre Anwendungen widerstandsfähiger gegenüber einem Datenbank-Failover. Wenn die ursprüngliche DB-Instance nicht verfügbar ist, stellt RDS-Proxy eine Verbindung mit der Standby-Datenbank her, ohne dass die inaktiven Anwendungsverbindungen verworfen werden. Dadurch wird der Failover-Prozess beschleunigt und vereinfacht. Dies ist mit weniger Störungen für Ihre Anwendung verbunden als ein typisches Neustart- oder Datenbankproblem.
Ohne RDS-Proxy ist ein Failover mit einem kurzen Ausfall verbunden. Während des Ausfalls können Sie keine Schreibvorgänge für diese Datenbank ausführen. Alle vorhandenen Datenbankverbindungen werden unterbrochen und Ihre Anwendung muss sie erneut öffnen. Die Datenbank wird für neue Verbindungen und Schreiboperationen verfügbar, wenn eine schreibgeschützte DB-Instance anstelle einer nicht verfügbaren Instance hochgestuft wird.
Während DB-Failovers akzeptiert RDS-Proxy weiterhin Verbindungen mit derselben IP-Adresse und leitet Verbindungen automatisch an die neue primäre DB-Instance weiter. Clients, die eine Verbindung über RDS-Proxy herstellen, sind nicht anfällig für Folgendes:
-
DNS (Domain Name System)-Ausbreitungsverzögerungen beim Failover.
-
Lokale DNS-Zwischenspeicherung.
-
Verbindungszeitüberschreitungen.
-
Unsicherheit darüber, welche DB-Instance der aktuelle Writer ist.
-
Warten auf eine Abfrageantwort eines früheren Writers, die nicht verfügbar wurde, ohne Verbindungen zu schließen.
Bei Anwendungen, die über eigene Verbindungspools verfügen, sorgt RDS-Proxy dafür, dass die meisten Verbindungen bei Failovers oder anderen Unterbrechungen aktiv bleiben. Nur Verbindungen, die sich mitten in einer Transaktion oder SQL-Anweisung befinden, werden unterbrochen. RDS-Proxy akzeptiert sofort neue Verbindungen. Wenn der Datenbank-Schreiber nicht verfügbar ist, werden eingehende Anfragen in RDS-Proxy in die Warteschlange gesetzt.
Für Anwendungen, die nicht über eigene Verbindungspools verfügen, bietet RDS-Proxy schnellere Verbindungsraten und mehr offene Verbindungen. Es reduziert den teuren Overhead, der mit dem häufigen Herstellen neuer Verbindungen über die Datenbank verbunden ist. Hierfür werden Datenbankverbindungen wiederverwendet, die im RDS-Proxy-Verbindungspool verwaltet werden. Dieser Ansatz ist besonders wichtig für TLS-Verbindungen, die mit erheblichen Setupkosten verbunden sind.
Transaktionen
Alle Anweisungen innerhalb einer einzelnen Transaktion verwenden immer dieselbe zugrunde liegende Datenbankverbindung. Die Verbindung wird für eine andere Sitzung verfügbar, wenn die Transaktion beendet wird. Die Verwendung der Transaktion als Granularitätseinheit hat folgende Auswirkungen:
-
Die Wiederverwendung von Verbindungen kann nach jeder einzelnen Anweisung erfolgen, wenn die Einstellung
autocommitvon RDS für MySQL aktiviert ist. -
Ist die Einstellung
autocommitdeaktiviert, beginnt im Gegensatz dazu die erste Anweisung, die Sie in einer Sitzung ausgeben, eine neue Transaktion. Angenommen, Sie geben die SequenzSELECT,INSERT,UPDATEund andere Data Manipulation Language (DML)-Anweisungen ein. In diesem Fall wird die Wiederverwendung von Verbindungen erst vorgenommen, wenn Sie einenCOMMIT,ROLLBACKausgeben oder die Transaktion anderweitig beenden. -
Die Eingabe einer DDL-Anweisung (Data Definition Language) bewirkt, dass die Transaktion beendet wird, nachdem diese Anweisung abgeschlossen wurde.
RDS-Proxy erkennt über das Netzwerkprotokoll, das von der Datenbank-Clientanwendung verwendet wird, wenn eine Transaktion beendet wird. Die Transaktionserkennung beruht nicht auf Schlüsselwörtern wie beispielsweise COMMIT oder ROLLBACK, die im Text der SQL-Anweisung angezeigt werden.
In einigen Fällen kann RDS-Proxy eine Datenbankanforderung erkennen, die es unpraktisch macht, Ihre Sitzung auf eine andere Verbindung zu verschieben. In diesen Fällen wird das Multiplexing für diese Verbindung während der verbleibenden Sitzung deaktiviert. Die gleiche Regel gilt, wenn RDS-Proxy nicht sicher sein kann, dass das Multiplexing für die Sitzung praktikabel ist. Diese Operation wird als Fixierung (Pinning) bezeichnet. Hinweise zum Erkennen und Minimieren von Fixierungen finden Sie unter Vermeiden von Pinning beim RDS-Proxy.