Hochverfügbarkeit und Disaster-Recovery für Databases for Redis
HochverfügbarkeitDie Fähigkeit eines Dienstes oder einer Arbeitslast, Ausfällen standzuhalten und die Verarbeitungsfähigkeit gemäß einem vordefinierten Servicelevel weiterhin bereitzustellen. (HA) ist die Fähigkeit eines Dienstes, auch bei unerwarteten Ausfällen betriebsbereit und zugänglich zu bleiben. Unter Disaster RecoveryDie Fähigkeit eines Dienstes oder einer Arbeitslast, sich von seltenen, schwerwiegenden Vorfällen und großflächigen Ausfällen, wie z. B. Dienstunterbrechungen, zu erholen. Dies umfasst eine Naturkatastrophe, die eine ganze Region betrifft, die Beschädigung einer Datenbank oder den Verlust eines Dienstes, der zu einer Arbeitsbelastung beiträgt. Die Auswirkungen übersteigen die Fähigkeit des Hochverfügbarkeitsdesigns, sie zu bewältigen. versteht man die Wiederherstellung eines funktionierenden Zustands der Service-Instanz.
Databases for Redis ist ein regionaler Dienst, der die mit dem Standardplan definierten Service Level Objectives(SLO ) erfüllt.
Weitere Informationen über die verfügbaren IBM Cloud Regionen und Rechenzentren für Databases for Redis finden Sie unter Service- und Infrastrukturverfügbarkeit nach Standort.
Architektur für hohe Verfügbarkeit
Databases for Redis bietet Replikations-, Failover- und Hochverfügbarkeitsfunktionen, um Ihre Datenbanken und Daten vor Infrastrukturwartung, Upgrades und einigen Ausfällen zu schützen. Bereitstellungen enthalten einen Cluster mit zwei Datenmitgliedern in einer Konfiguration aus Primär- und Replikatdaten. Das Replikat wird durch asynchrone Replikation auf dem neuesten Stand gehalten. Die Hochverfügbarkeit wird mit drei Redis Wächtern überwacht und verwaltet
Standardmäßig ist die Datenpersistenz bei allen Bereitstellungen aktiviert und Ihre Daten werden auf die Festplatte geschrieben. Databases for Redis verwendet eine Kombination aus RDB-Snapshots und AOF(Append Only File), um Daten auf der Festplatte zu halten. Das Intervall, in dem Databases for Redis auf die Festplatte schreibt (fsync), ist auf einmal pro Sekunde eingestellt, um Haltbarkeit und Leistung auszugleichen.
Sie können die Datenpersistenz inaktivieren, was für die Konfiguration von Redis als Cache nützlich ist.
Funktionen für hohe Verfügbarkeit
Databases for Redis unterstützt die folgenden Hochverfügbarkeitsfunktionen:
| Feature | Beschreibung | Hinweis |
|---|---|---|
| Automatische Ausfallsicherung | Standard bei allen Clustern und widerstandsfähig gegen den Ausfall einer Zone oder eines einzelnen Mitglieds | |
| Mitgliedsanzahl | Minimum - 2 Mitglieder. Standard ist ein Standard-Zweimember-Cluster in einer Primär- und Replikatkonfiguration. Ein Cluster mit zwei Mitgliedern stellt sich nach dem Ausfall einer einzelnen Instanz oder Zone automatisch wieder her (mit Datenverlusten bis zur Verzögerungsgrenze). | Drei Sentinel-Knoten, die den Zustand des Clusters überwachen und Failover koordinieren. |
| Asynchrone Replikation | Ermöglicht die Replikation vom Primärsystem zum Replikat, ohne den Schreibpfad zu blockieren, und sorgt so für hohe Verfügbarkeit bei geringer Latenz. Siehe Asynchrone Replikation. | Kann bei einem Failover zu Datenverlusten aufgrund von Replikationsverzögerungen führen (RPO > 0). Nicht geeignet, wenn eine strenge Haltbarkeit der Daten erforderlich ist. |
Asynchrone Replikation für Databases for Redis
Standardmäßig verwendet Databases for Redis eine asynchrone Replikation, bei der der primäre Knoten nicht auf die Bestätigung von Schreibvorgängen durch das Replikat wartet. Dies gewährleistet niedrige Latenzzeiten und einen hohen Durchsatz, wodurch Databases for Redis ideal für Caching und leistungsempfindliche Arbeitslasten ist. Im Falle eines Ausfalls der Primärdaten kann die Verzögerung bei der Replikation jedoch zu Datenverlusten führen, da die Replikate möglicherweise nicht die neuesten Schreibvorgänge erhalten haben.
Databases for Redis die Replikation ist auf hohe Verfügbarkeit ausgelegt, nicht auf strikte Haltbarkeit. Ein Failover wird automatisch ausgelöst, wenn das primäre System nicht mehr erreichbar ist, wodurch das Replikat zum Leader wird. Da die Replikation asynchron erfolgt, können bei diesem Vorgang einige bestätigte Schreibvorgänge verloren gehen. Diese Replikationsverzögerung definiert das Wiederherstellungspunktziel (Recovery Point Objective, RPO) von Databases for Redis Bereitstellungen.
Um das Risiko von Datenverlusten zu verringern, unterstützt Databases for Redis Persistenzmechanismen wie RDB-Snapshots und AOF(Append Only File), die Daten unabhängig vom Replikationsprozess auf die Festplatte schreiben. Diese sollten auf der Grundlage der Arbeitslastanforderungen sorgfältig konfiguriert werden.
Die asynchrone Replikation in Databases for Redis gewährleistet eine schnelle Leistung, schließt aber die Möglichkeit eines Datenverlusts bei Failover-Ereignissen nicht aus. Sie wird für Workloads empfohlen, bei denen Geschwindigkeit und Verfügbarkeit wichtiger sind als strikte Datenkonsistenz.
Architektur zur Wiederherstellung im Katastrophenfall
Die allgemeine Strategie für die Wiederherstellung im Katastrophenfall besteht darin, eine neue Datenbank zu erstellen, wie die nachstehende Datenbank Restore. Der Inhalt der neuen Datenbank kann eine Sicherung der Quelldatenbank
sein, die vor der Katastrophe erstellt wurde.
Funktionen zur Wiederherstellung im Katastrophenfall
Databases for Redis unterstützt die folgenden Disaster-Recovery-Funktionen:
| Feature | Beschreibung | Hinweis |
|---|---|---|
| Sicherung wiederherstellen | Erstellen einer Datenbank aus einer zuvor erstellten Sicherung; siehe Verwaltung von Cloud Databases Sicherungen. | Neue Verbindungszeichenfolgen für die wiederhergestellte Datenbank müssen während des gesamten Workloads referenziert werden. |
Disaster-Recovery planen
Die Wiederherstellungsmaßnahmen müssen regelmäßig geübt werden. Berücksichtigen Sie bei der Erstellung Ihres Plans die folgenden Fehlerszenarien und Lösungen.
| Fehler | Lösung |
|---|---|
| Hardware-Ausfall (einzelner Punkt) | (Beispiel) IBM bietet eine Datenbank, die gegen einen einzelnen Hardwareausfall innerhalb einer Zone resistent ist. Keine kundenseitige Konfiguration erforderlich. |
| Zonenfehler | Automatische Ausfallsicherung. Die Mitglieder der Datenbank sind auf die Zonen verteilt. |
| Datenbeschädigung | Backup wiederherstellen. Verwenden Sie die wiederhergestellte Datenbank in der Produktion oder für Quelldaten, um die Beschädigung in der wiederhergestellten Datenbank zu korrigieren. |
Hochverfügbarkeit auf Anwendungsebene
Anwendungen, die über Netze und Cloud-Services kommunizieren, sind temporären Verbindungsfehlern ausgesetzt. Sie möchten Ihre Anwendungen so gestalten, dass sie den Aufbau von Verbindungen neu versuchen, wenn Fehler durch einen temporären Verlust der Verbindung zu Ihrer Bereitstellung oder zu IBM Cloud verursacht werden.
Da Databases for Redis ein verwalteter Dienst ist, gehören regelmäßige Aktualisierungen und die Wartung der Datenbank zum normalen Betrieb. Dies kann gelegentlich zu kurzen Intervallen führen, in denen Ihre Datenbank nicht verfügbar ist. Es kann auch dazu führen, dass die Datenbank ein geordnetes Failover, eine Wiederholung und Neuherstellung der Verbindung auslöst. Es dauert eine kurze Zeit, bis die Datenbank ermittelt hat, welches Member ein Replikat und welches der Leader ist, sodass möglicherweise auch eine kurze Verbindungsunterbrechung auftritt. Failover dauern in der Regel weniger als 30 Sekunden.
Ihre Anwendungen müssen so konzipiert sein, dass sie mit vorübergehenden Unterbrechungen der Datenbank umgehen können, eine Fehlerbehandlung für fehlgeschlagene Datenbankbefehle implementieren und eine Wiederholungslogik zur Wiederherstellung nach einer vorübergehenden interruption.Use IOREDIS, NODEREDIS oder ein anderes Paket Ihrer Wahl implementieren, um die Kontinuität Ihrer application.For zu gewährleisten. Weitere Informationen finden Sie im Blogbeitrag Fehlererkennung und -behandlung mit Redis.
Mit einer Nichtverfügbarkeit von Datenbanken oder einer Unterbrechung von Verbindungen für mehrere Minuten muss nicht gerechnet werden. Eröffnen Sie einen Support-Fall mit Details, wenn Sie länger als eine Minute keine Verbindung haben, damit wir dies untersuchen können.
Verbindungslimits
Databases for Redis legt eine Höchstzahl von 10.000 gleichzeitigen Verbindungen pro Einsatz fest. Dieser Grenzwert gewährleistet die Leistungsstabilität und das Ressourcenmanagement in Ihrer Redis Umgebung. Allerdings stehen nicht alle 10.000 Verbindungen den Kunden zur Verfügung - ein Teil ist intern für Vorgänge reserviert, die den Zustand und die Integrität der Bereitstellung aufrechterhalten. Nach Erreichen des Verbindungslimits führen alle Versuche, eine neue Verbindung aufzubauen, zu einem Fehler. Weitere Informationen finden Sie unter Verwalten von Redis Verbindungen.
Ihre Verantwortlichkeiten für HA und DR
Die folgenden Informationen können Ihnen dabei helfen, Ihren Plan für HA und DR zu erstellen und kontinuierlich zu üben.
Bei der Wiederherstellung einer Datenbank aus Sicherungskopien oder bei der Point-in-Time-Wiederherstellung wird eine neue Datenbank mit neuen Verbindungszeichenfolgen erstellt. Vorhandene Workloads und Prozesse müssen an die neuen Verbindungsstrings angepasst werden.
Eine wiederhergestellte Datenbank benötigt unter Umständen die gleichen vom Kunden erstellten Abhängigkeiten wie die Notfalldatenbank. Stellen Sie sicher, dass diese und andere Dienste in der zurückgewonnenen Region vorhanden sind:
- IBM® Key Protect for IBM Cloud®
Denken Sie daran, dass beim Löschen einer Datenbank auch die zugehörigen Sicherungen gelöscht werden. Gelöschte Datenbanken können jedoch innerhalb eines begrenzten Zeitrahmens wiederhergestellt werden. Weitere Informationen finden Sie unter Backups FAQ.
Es ist nicht möglich, Sicherungen von IBM Cloud zu kopieren, daher sollten Sie die datenbankspezifischen Tools für zusätzliche Sicherungen verwenden. Sie kann erforderlich sein, um eine böswillig gelöschte Datenbank wiederherzustellen, gefolgt von einer Reklamationslöschung einer Datenbank. Eine sorgfältige Verwaltung des IAM-Zugriffs auf Datenbanken kann dazu beitragen, die Anfälligkeit für dieses Problem zu verringern.
Die folgende Checkliste für jedes Merkmal kann Ihnen bei der Erstellung und Umsetzung Ihres Plans helfen.
- Sicherung wiederherstellen
- Überprüfen Sie, ob Backups in der gewünschten Häufigkeit verfügbar sind, um die RPO-Anforderungen zu erfüllen. Die Verwaltung von Cloud Databases Backups dokumentiert die Häufigkeit der Backups.
- Es gibt einige Einschränkungen für Datenbank-Wiederherstellungsregionen - vergewissern Sie sich, dass Ihre Wiederherstellungsziele erreicht werden können, indem Sie Cloud Databases Backups verwalten lesen.
- Vergewissern Sie sich, dass die Aufbewahrungsfrist der Backups Ihren Anforderungen entspricht.
- Planen Sie regelmäßig Testwiederherstellungen, um zu überprüfen, ob die tatsächlichen Wiederherstellungszeiten den definierten RTO einhalten. Denken Sie daran, dass die Größe der Datenbank die Wiederherstellungszeit erheblich beeinflusst. Ziehen Sie Strategien zur Minimierung der Wiederherstellungszeiten in Erwägung, z. B. die Aufteilung großer Datenbanken in kleinere, besser zu verwaltende Einheiten und die Bereinigung nicht verwendeter Daten.
- Überprüfen Sie den Dienst Key Protect.
Um mehr über die Verantwortung zwischen dem Kunden und IBM Cloud für die Nutzung von Databases for Redis zu erfahren, siehe Gemeinsame Verantwortung für Cloud Databases.
Bleiben Sie informiert: IBM Benachrichtigungen
Aktualisierungen, die sich auf die Arbeitslasten der Kunden auswirken, werden über IBM Cloud mitgeteilt. Um über geplante Wartungsarbeiten, Ankündigungen und Versionshinweise in Bezug auf diesen Dienst informiert zu bleiben, besuchen Sie die Seite Benachrichtigungen und Status der Überwachung. Prüfen Sie außerdem regelmäßig die Seite Versionsrichtlinien, um die neuesten Aktualisierungen zu den End-of-Life-Versionen und Terminen zu erhalten.