Konfiguration einer AWS RDS Multi-AZ-Bereitstellung für hohe Verfügbarkeit
Konfigurieren Sie AWS RDS Multi-AZ für automatisches Failover, sicherere Wartung und bessere Datenbankverfügbarkeit in der Produktion.
Konfiguration einer AWS RDS Multi-AZ-Bereitstellung für hohe Verfügbarkeit
Die Verfügbarkeit der Datenbank ist entscheidend, wenn Ihre Anwendung von einem einzelnen RDS-Endpunkt abhängt. AWS RDS Multi-AZ reduziert das Risiko eines Instanz- oder Availability-Zone-Ausfalls, indem es einen Standby in einer anderen AZ bereithält und automatisch ein Failover durchführt, wenn die primäre Instanz keinen Datenverkehr mehr bedienen kann.
Diese Anleitung zeigt, wie Sie eine AWS RDS Multi-AZ-Bereitstellung für eine neue oder bestehende DB-Instanz konfigurieren, was Sie nach der Änderung überwachen sollten und mit welchen Kompromissen Sie rechnen müssen.
Was ist AWS RDS Multi-AZ?
Eine AWS RDS Multi-AZ (Multiple Availability Zone)-Bereitstellung erstellt eine exakte Kopie Ihrer Datenbankinstanz in einer anderen, physisch isolierten Availability Zone (AZ) innerhalb derselben AWS-Region. Diese Standby-Instanz arbeitet in einer "Hot-Standby"-Konfiguration, was bedeutet, dass sie kontinuierlich mit Änderungen von der primären Instanz mittels synchroner Replikation aktualisiert wird.
Funktionsweise:
- Primäre Instanz: Ihre Anwendung verbindet sich mit der primären Datenbankinstanz und schreibt Daten in diese.
- Synchrone Replikation: Alle Datenschreibvorgänge auf die primäre Instanz werden synchron auf die Standby-Instanz repliziert. Dies stellt sicher, dass die Standby-Instanz immer auf dem neuesten Stand der primären Instanz ist und Datenverluste während eines Failovers minimiert werden.
- Automatisches Failover: Im Falle eines Infrastrukturfehlers, der die primäre Instanz betrifft (z. B. ein AZ-Ausfall, ein Hardwarefehler der Instanz, ein Netzwerkproblem oder ein Datenbank-Engine-Absturz), wechselt AWS RDS automatisch zum Standby-Replikat. Die Failover-Dauer variiert je nach Engine, Workload und DNS-Caching-Verhalten, daher sollte Ihre Anwendung eine Wiederverbindungslogik verwenden. Der Datenbankendpunkt bleibt derselbe, sodass Ihre Anwendungen keine neue Verbindungszeichenfolge benötigen.
- Einzelner Endpunkt: Sowohl die primäre als auch die Standby-Instanz teilen sich einen einzigen DNS-Endpunkt. Ihre Anwendungen verbinden sich mit diesem Endpunkt, und AWS verwaltet die Weiterleitung zur aktuell aktiven primären Instanz.
Vorteile von Multi-AZ-Bereitstellungen
Die Konfiguration von RDS mit Multi-AZ bietet mehrere entscheidende Vorteile für Produktionsworkloads:
- Hohe Verfügbarkeit: Automatisiertes Failover zu einem Standby-Replikat in einer anderen AZ stellt sicher, dass Ihre Datenbank auch dann betriebsbereit bleibt, wenn die primäre AZ einen Ausfall erleidet. Dies reduziert Ausfallzeiten erheblich.
- Datenhaltbarkeit: Synchrone Replikation garantiert, dass alle bestätigten Transaktionen sowohl auf der primären als auch auf der Standby-Instanz vorhanden sind. Dies minimiert das Risiko von Datenverlusten während eines Failovers.
- Notfallwiederherstellung: Durch die Verteilung über mehrere Availability Zones ist Ihre Datenbank vor AZ-Ausfällen geschützt und bildet einen kritischen Bestandteil Ihrer Notfallwiederherstellungsstrategie.
- Vereinfachter Betrieb: AWS übernimmt die Überwachung, Replikation und den Failover-Prozess automatisch. Sie müssen keine hostbasierte Replikation konfigurieren, Standby-Instanzen verwalten oder Failover manuell orchestrieren.
- Wartungsfenster: Während geplanter Wartungsarbeiten (z. B. Betriebssystem-Patches oder Datenbank-Engine-Upgrades) führt AWS automatisch ein Failover zur Standby-Instanz durch, führt Wartungsarbeiten an der alten primären Instanz durch und wechselt dann zurück. Dies minimiert Anwendungsausfallzeiten.
- Leistung (Schreiblatenz): Während die synchrone Replikation im Vergleich zu einer Single-AZ-Bereitstellung inhärent eine leichte Erhöhung der Schreiblatenz mit sich bringt (aufgrund der Bestätigung von Schreibvorgängen an zwei Standorten), ist dies für die meisten Anwendungen oft vernachlässigbar und ein lohnender Kompromiss für die verbesserte Verfügbarkeit.
Voraussetzungen
Bevor Sie beginnen, stellen Sie sicher, dass Sie Folgendes haben:
- Ein AWS-Konto mit entsprechenden Berechtigungen zum Erstellen und Verwalten von RDS-Instanzen.
- Ein grundlegendes Verständnis von AWS-Regionen, Availability Zones und Virtual Private Clouds (VPCs).
Schritt-für-Schritt-Konfigurationsanleitung
Option 1: Erstellen einer neuen RDS-Instanz mit Multi-AZ
Dies ist der empfohlene Ansatz für neue Bereitstellungen, der von Anfang an hohe Verfügbarkeit gewährleistet.
- Navigieren Sie zur RDS-Konsole: Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon RDS-Konsole.
- Datenbank erstellen: Wählen Sie im Navigationsbereich Datenbanken und klicken Sie dann auf Datenbank erstellen.
- Datenbank-Erstellungsmethode wählen: Wählen Sie Standard erstellen.
- Engine-Optionen wählen:
- Engine-Typ: Wählen Sie Ihre gewünschte Datenbank-Engine (z. B. MySQL, PostgreSQL, SQL Server, Oracle).
- Engine-Version: Wählen Sie die spezifische Version.
- Vorlagen: Wählen Sie die entsprechende Vorlage. Verwenden Sie für die Produktion eine produktionsorientierte Vorlage und überprüfen Sie dennoch die Multi-AZ-Einstellung, bevor Sie die Datenbank erstellen.
- Einstellungen:
- DB-Instanzkennung: Geben Sie einen eindeutigen Namen für Ihre Datenbankinstanz an.
- Master-Benutzername und Master-Passwort: Legen Sie Anmeldeinformationen für den primären Datenbankbenutzer fest.
- DB-Instanzgröße: Wählen Sie die Instanzklasse, die Ihren Leistungsanforderungen entspricht.
- Speicher: Konfigurieren Sie Speichertyp und zugewiesenen Speicher.
- Verfügbarkeit & Haltbarkeit: Dies ist der entscheidende Schritt für Multi-AZ:
- Wählen Sie unter Multi-AZ-Bereitstellung die Option Ja (Standby-Instanz erstellen).
- (Optional) Wenn Sie zuvor die Vorlage "Produktion" ausgewählt haben, ist diese Option vorausgewählt.
- Konnektivität:
- VPC: Wählen Sie die VPC aus, in der Ihre Datenbank residieren soll.
- Subnetzgruppe: Stellen Sie sicher, dass Sie eine DB-Subnetzgruppe haben, die sich über mehrere Availability Zones erstreckt. RDS verwendet diese, um die primäre und die Standby-Instanz in verschiedenen AZs zu platzieren.
- Öffentlicher Zugriff: Wählen Sie für Produktionsumgebungen aus Sicherheitsgründen Nein.
- VPC-Sicherheitsgruppen: Fügen Sie eine geeignete Sicherheitsgruppe hinzu, die eingehenden Datenverkehr zu Ihrem Datenbankport von Ihren Anwendungsservern zulässt.
- Datenbankauthentifizierung: Wählen Sie Ihre bevorzugte Authentifizierungsmethode.
- Überwachung, Performance Insights, Log-Exporte, Wartung: Konfigurieren Sie diese nach Ihren betrieblichen Anforderungen.
- Datenbank erstellen: Überprüfen Sie alle Ihre Einstellungen und klicken Sie auf Datenbank erstellen.
AWS wird Ihre primäre Instanz bereitstellen und dann das Standby-Replikat in einer anderen Availability Zone erstellen und synchronisieren. Dieser Prozess kann je nach Instanzgröße einige Zeit in Anspruch nehmen.
Option 2: Ändern einer vorhandenen RDS-Instanz auf Multi-AZ
Sie können Multi-AZ für eine vorhandene Single-AZ-RDS-Instanz ohne Ausfallzeiten aktivieren.
- Navigieren Sie zur RDS-Konsole: Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon RDS-Konsole.
- Datenbank auswählen: Wählen Sie im Navigationsbereich Datenbanken und dann die RDS-Instanz aus, die Sie ändern möchten.
- Instanz ändern: Klicken Sie auf die Schaltfläche Ändern.
- Verfügbarkeit & Haltbarkeit: Scrollen Sie nach unten zum Abschnitt Verfügbarkeit & Haltbarkeit.
- Wählen Sie unter Multi-AZ-Bereitstellung die Option Ja (Standby-Instanz erstellen).
- Weiter: Überprüfen Sie andere Einstellungen (Instanzklasse, Speicher usw.) und nehmen Sie alle anderen erforderlichen Änderungen vor, klicken Sie dann auf Weiter.
- Planung von Änderungen:
- Sofort anwenden: Wenn Sie diese Option wählen, wird die Änderung sofort gestartet. RDS erstellt den Standby im Hintergrund, während die primäre Instanz verfügbar bleibt, obwohl während der Synchronisierung eine höhere I/O-Latenz auftreten kann. AWS erfordert normalerweise keine geplante Ausfallzeit nur für die Aktivierung von Multi-AZ, aber spätere Failover oder Wartungsereignisse können dennoch Verbindungen unterbrechen.
- Während des nächsten geplanten Wartungsfensters anwenden: Diese Option wendet die Änderungen während Ihres definierten Wartungsfensters an und minimiert so Unterbrechungen während der Hauptgeschäftszeiten.
- DB-Instanz ändern: Klicken Sie auf DB-Instanz ändern.
AWS startet den Prozess der Erstellung des Standby-Replikats und der Synchronisierung mit Ihrer primären Instanz. Während dieser Zeit bleibt Ihre Datenbank online, aber Sie könnten ein kurzes Failover-Ereignis beobachten, wenn die Multi-AZ-Konfiguration abgeschlossen wird.
Überwachen Ihrer Multi-AZ-Bereitstellung
Nach der Einrichtung von Multi-AZ ist es wichtig, den Status zu überwachen:
- RDS-Konsole: Gehen Sie zur RDS-Konsole und wählen Sie Ihre Datenbankinstanz aus.
- Registerkarte Details: Im Abschnitt Konnektivität & Sicherheit sehen Sie Multi-AZ als
Jaaufgeführt. Unter Verfügbarkeit & Haltbarkeit sollte Ihre Instanz als in einer Multi-AZ-Bereitstellung befindlich angezeigt werden. - Ereignisse: Überprüfen Sie die Registerkarte Logs & Ereignisse auf Ereignisse im Zusammenhang mit Failovern, Instanzerstellung oder Wartungsaktivitäten. AWS protokolliert Ereignisse für Failover (z. B.
RDS-EVENT-0026 - DB-Instanz XXX wurde einem Failover unterzogen).
Testen des Failovers (Optional, aber empfohlen)
Obwohl AWS Failover automatisch verwaltet, ist es gute Praxis, den Failover-Mechanismus in einer Nicht-Produktionsumgebung zu verstehen und gelegentlich zu testen.
Auslösen eines Failovers:
- Neustart mit Failover: Wählen Sie Ihre Multi-AZ-Instanz in der RDS-Konsole aus. Wählen Sie im Menü Aktionen die Option Neustarten. Stellen Sie sicher, dass Sie die Option "Mit Failover neu starten?" auswählen.
- Diese Aktion zwingt RDS, die primäre Instanz auf das Standby-Replikat umzuschalten und simuliert so einen ungeplanten Ausfall. Ihre Anwendung sollte mit einer kurzen Trennung rechnen, während der Endpunkt beginnt, auf die neue primäre Instanz aufzulösen.
- Ereignisse beobachten: Überwachen Sie nach dem Initiieren eines Failovers die Registerkarte Logs & Ereignisse für Ihre Instanz. Sie sollten Ereignisse sehen, die darauf hinweisen, dass ein Failover stattgefunden hat und dass die neue primäre Instanz aktiv ist.
Überlegungen und Best Practices
- Kosten: Multi-AZ-Bereitstellungen verursachen höhere Kosten als Single-AZ-Bereitstellungen, da Sie effektiv zwei Datenbankinstanzen (primär und Standby) betreiben, obwohl zu einem bestimmten Zeitpunkt nur eine aktiv Datenverkehr bedient.
- Read Replicas vs. Multi-AZ: Verstehen Sie den Unterschied. Multi-AZ dient der hohen Verfügbarkeit und Haltbarkeit (Schreibvorgänge). Read Replicas dienen der Leseskalierung und Verbesserung der Leseleistung. Sie können zusammen verwendet werden; Sie können eine Multi-AZ-Primäre erstellen und dann Read Replicas zur Skalierung von leseintensiven Anwendungen haben.
- Leistungsauswirkungen: Während Multi-AZ die Verfügbarkeit verbessert, kann die synchrone Replikation im Vergleich zu Single-AZ eine leichte Erhöhung der Schreiblatenz mit sich bringen. Für die meisten Anwendungen ist dieser Overhead minimal.
- Subnetzgruppen: Stellen Sie sicher, dass Ihre DB-Subnetzgruppe Subnetze in mindestens zwei verschiedenen Availability Zones enthält. Dies ermöglicht RDS, Ihre primäre und Standby-Instanz in separaten AZs zu platzieren.
- Sicherheitsgruppen: Konfigurieren Sie Ihre VPC-Sicherheitsgruppen ordnungsgemäß, um Datenverkehr von Ihren Anwendungsservern zum RDS-Endpunkt zuzulassen.
- Datenbank-Engine-Unterstützung: Multi-AZ wird von den meisten gängigen Datenbank-Engines unterstützt, darunter MySQL, PostgreSQL, SQL Server, Oracle und MariaDB.
Fazit
Verwenden Sie AWS RDS Multi-AZ für Produktionsdatenbanken, bei denen automatisches Failover wichtiger ist als die zusätzlichen Kosten und die mögliche Schreiblatenz. Nach der Aktivierung bestätigen Sie, dass Ihre DB-Subnetzgruppe mindestens zwei AZs umfasst, testen Sie das Wiederverbindungsverhalten der Anwendung in einer Nicht-Produktionsumgebung und überwachen Sie RDS-Ereignisse, damit Failover Ihr Team nicht überraschen.