Bewährte Methoden für Hochverfügbarkeit und Notfallwiederherstellung

Azure Managed Instance for Apache Cassandra ist ein vollständig verwalteter Service für reine Open-Source Apache Cassandra-Cluster. Der Dienst ermöglicht auch das Überschreiben von Konfigurationen, je nach den spezifischen Anforderungen der einzelnen Workloads, und bietet so ein Höchstmaß an Flexibilität und Kontrolle, wo dies erforderlich ist.

Apache Cassandra eignet sich aufgrund seiner verteilten Struktur und seiner masterlosen Architektur hervorragend für die Entwicklung hochresilienter Anwendungen. Jeder Knoten in der Datenbank kann genau dieselbe Funktionalität wie jeder andere Knoten bereitstellen, was zur Stabilität und Resilienz von Cassandra beiträgt. Dieser Artikel enthält Tipps zum Optimieren der Hochverfügbarkeit und zum Ansatz für die Notfallwiederherstellung.

RPO und RTO

RPO (Recovery Point Objective) und RTO (Recovery Time Objective), werden beide in der Regel niedrig (nahe null) für Apache Cassandra sein, solange Sie:

• Eine Bereitstellung mit mehreren Regionen mit regionsübergreifender Replikation und einem Replikationsfaktor von 3 haben.
• Aktivierte Verfügbarkeitszonen (Auswahloption beim Erstellen eines Clusters im Portal oder über Azure CLI) haben.
• Failover auf Anwendungsebene mithilfe der Lastenausgleichsrichtlinie im Clienttreiber und/oder Lastenausgleichsfailover mithilfe von Traffic Manager/Azure Front Door konfiguriert haben.

RTO („wie lange man bei einem Ausfall ausfällt“) wird gering sein, da der Cluster sowohl zonen- als auch regionenübergreifend resilient sein wird und Apache Cassandra selbst standardmäßig ein hochgradig fehlertolerantes, masterloses System ist (alle Knoten können schreiben). RPO („wie viele Daten bei einem Ausfall verloren gehen können“) wird niedrig sein, da die Daten zwischen allen Knoten und Rechenzentren synchronisiert werden, sodass der Datenverlust bei einem Ausfall minimal wäre.

Hinweis

Es ist theoretisch nicht möglich, sowohl RTO=0 als auch RPO=0 gemäß dem Cap-Theorem zu erreichen. Sie müssen den Kompromiss zwischen Konsistenz und Verfügbarkeit bzw. optimaler Leistung abwägen – dieser sieht für jede Anwendung anders aus. Wenn Ihre Anwendung zum Beispiel sehr leseintensiv ist, kann es besser sein, eine höhere Wartezeit bei regionsübergreifenden Schreibvorgängen in Kauf zu nehmen, um Datenverluste zu vermeiden (zugunsten der Konsistenz). Ist die Anwendung schreibintensiv und hat ein knappes Wartezeitbudget, kann das Risiko, bei einem größeren regionalen Ausfall einige der letzten Schreibvorgänge zu verlieren, akzeptabel sein (zugunsten der Verfügbarkeit).

Verfügbarkeitszonen

Die masterlose Architektur von Cassandra bringt Fehlertoleranz von Grund auf mit sich. Azure Managed Instance for Apache Cassandra bietet Unterstützung für Verfügbarkeitszonen in ausgewählten Regionen, um die Resilienz auf Infrastrukturebene zu erhöhen. Bei einem Replikationsfaktor von 3 stellt die Unterstützung von Verfügbarkeitszonen sicher, dass sich jede Replikation in einer anderen Verfügbarkeitszone befindet, wodurch verhindert wird, dass sich ein Zonenausfall auf Ihre Datenbank/Anwendung auswirkt. Wir empfehlen, Verfügbarkeitszonen zu aktivieren, wo immer dies möglich ist.

Redundanz für mehrere Regionen

Die Architektur von Cassandra in Verbindung mit der Unterstützung von Azure-Verfügbarkeitszonen bietet Ihnen ein gewisses Maß an Fehlertoleranz und Resilienz. Es ist jedoch wichtig, die Auswirkungen regionaler Ausfälle auf Ihre Anwendungen zu berücksichtigen. Die Bereitstellung von Clustern mit mehreren Regionen wird dringend empfohlen, um sich gegen Ausfälle auf Regionsebene abzusichern. Sie sind zwar selten, aber die möglichen Auswirkungen sind gravierend.

Für Geschäftskontinuität reicht es nicht aus, nur die Datenbank auf mehrere Regionen zu verteilen. Auch andere Teile Ihrer Anwendung müssen auf die gleiche Art und Weise bereitgestellt werden, indem sie entweder verteilt werden oder über geeignete Failovermechanismen verfügen. Wenn Ihre Benutzer über viele geografische Standorte verteilt sind, hat die Bereitstellung der Datenbank in mehreren Rechenzentren den zusätzlichen Vorteil, dass die Wartezeit verringert wird, da alle Knoten in allen Rechenzentren des Clusters sowohl Lese- als auch Schreibvorgänge in der Region bereitstellen können, die ihnen am nächsten ist. Wenn die Anwendung jedoch als „aktiv-aktiv“ konfiguriert ist, ist es wichtig zu bedenken, wie sich das CAP-Theorem auf die Konsistenz Ihrer Daten zwischen den Replikaten (Knoten) auswirkt und welche Kompromisse für die Bereitstellung von Hochverfügbarkeit erforderlich sind.

Im Sinne des CAP-Theorems ist Cassandra standardmäßig ein AP-Datenbanksystem (Available Partition-tolerant) mit hochgradig einstellbarer Konsistenz. Für die meisten Anwendungsfälle wird die Verwendung von „local_quorum“ für Lesevorgänge empfohlen.

• Bei aktiv-passiven Schreibvorgängen gibt es einen Kompromiss zwischen Zuverlässigkeit und Leistung: Für Zuverlässigkeit empfehlen wir QUORUM_EACH, aber für die meisten Benutzer ist LOCAL_QUORUM oder QUORUM ein guter Kompromiss. Beachten Sie jedoch, dass bei einem regionalen Ausfall einige Schreibvorgänge in LOCAL_QUORUM verloren gehen könnten.
• Bei paralleler Ausführung einer Anwendung werden in den meisten Fällen QUORUM_EACH-Schreibvorgänge bevorzugt, um die Konsistenz zwischen den beiden Rechenzentren zu gewährleisten.
• Wenn Ihr Ziel darin besteht, die Konsistenz (niedrigeres RPO) der Wartezeit oder Verfügbarkeit (niedrigeres RTO) vorzuziehen, sollte sich dies in Ihren Konsistenzeinstellungen und dem Replikationsfaktor widerspiegeln. Als Faustregel gilt, dass die Anzahl der für einen Lesevorgang erforderlichen Quorumknoten plus die Anzahl der für einen Schreibvorgang erforderlichen Quorumknoten größer sein muss als der Replikationsfaktor. Wenn Sie beispielsweise einen Replikationsfaktor von 3 und „quorum_one“ für Lesevorgänge (ein Knoten) haben, sollten Sie „quorum_all“ für Schreibvorgänge (drei Knoten) verwenden, sodass die Gesamtzahl von 4 größer ist als der Replikationsfaktor von 3.

Hinweis

Der Steuerungsebenenoperator für Azure Managed Instance für Apache Cassandra wird nur in einer einzigen Region bereitgestellt (die Region, die bei der ersten Bereitstellung des ersten Rechenzentrums ausgewählt wurde). Im unwahrscheinlichen Fall eines Gesamtausfalls einer Region verpflichten wir uns zu einer 3-stündigen Wiederherstellungszeit für ein Failover der Kontrollebene in eine andere Region. Dies wirkt sich nicht auf die Verfügbarkeit SLA für den Dienst aus, da Rechenzentren weiterhin funktionieren sollten. In diesem Zeitraum ist es jedoch möglicherweise nicht möglich, Änderungen an der Datenbankkonfiguration über das Portal oder die Tools des Ressourcenanbieters vorzunehmen.

Replikation

Es wird empfohlen, keyspaces und ihre Replikationseinstellungen von Zeit zu Zeit zu überprüfen, um sicherzustellen, dass die erforderliche Replikation zwischen Rechenzentren konfiguriert wurde. In der Anfangsphase der Entwicklung empfehlen wir, mit einfachen Tests unter Verwendung von cqlsh zu prüfen, ob alles wie erwartet funktioniert. Fügen Sie zum Beispiel einen Wert ein, während Sie mit einem Rechenzentrum verbunden sind, und lesen Sie ihn aus dem anderen.

Insbesondere bei der Einrichtung eines zweiten Rechenzentrums, in dem bereits Daten vorhanden sind, ist es wichtig festzustellen, ob alle Daten repliziert wurden und das System bereit ist. Wir empfehlen, den Replikationsfortschritt über unsere DBA-Befehle mit nodetool netstats zu überwachen. Ein alternativer Ansatz wäre, die Zeilen in jeder Tabelle zu zählen, aber bedenken Sie, dass dies bei großen Datenmengen aufgrund der verteilten Natur von Cassandra nur eine grobe Schätzung sein kann.

Ausgleich der Kosten für die Notfallwiederherstellung

Auch wenn Ihre Anwendung „aktiv-passiv“ ist, empfiehlt es sich im Allgemeinen, in jeder Region die gleiche Kapazität bereitzustellen, damit für Ihre Anwendung sofort ein Failover auf ein unmittelbar betriebsbereites Standby-Rechenzentrum in einer sekundären Region erfolgen kann. Dadurch wird sichergestellt, dass bei einem regionalen Ausfall keine Leistungsbeeinträchtigung auftritt. Die meisten Cassandra-Clienttreiber bieten Optionen, um Failover auf Anwendungsebene zu initiieren. Standardmäßig wird davon ausgegangen, dass ein regionaler Ausfall bedeutet, dass auch die Anwendung ausgefallen ist. In diesem Fall sollte ein Failover auf Lastenausgleichsebene erfolgen.

Um jedoch die Kosten für die Bereitstellung eines zweiten Rechenzentrums zu reduzieren, sollten Sie eine kleinere SKU und weniger Knoten in Ihrer sekundären Region bereitstellen. Bei einem Ausfall wird das Hochskalieren in Azure Managed Instance for Apache Cassandra durch schlüsselfertige vertikale und horizontale Skalierung erleichtert. Während für Ihre Anwendungen ein Failover auf Ihre sekundäre Region erfolgt, können Sie die Knoten in Ihrem sekundären Rechenzentrum manuell auf- und hochskalieren. In diesem Fall fungiert Ihr sekundäres Rechenzentrum als kostengünstige Betriebsbereitschaft. Dieser Ansatz muss gegen die Zeit abgewogen werden, die erforderlich ist, um Ihr System bei einem Ausfall in vollem Umfang wiederherzustellen. Es ist wichtig, zu testen und zu üben, was passiert, wenn eine Region ausfällt.

Hinweis

Das Hochskalieren von Knoten geht viel schneller als das Aufskalieren. Berücksichtigen Sie dies bei der Abwägung zwischen vertikaler und horizontaler Skalierung und der Anzahl der Knoten, die Sie in Ihrem Cluster bereitstellen möchten.

Sicherungszeitpläne

Sicherungen erfolgen in Azure Managed Instance for Apache Cassandra automatisch, aber Sie können Ihren eigenen Zeitplan für die täglichen Sicherungen festlegen. Es wird empfohlen, Zeiten mit geringerer Last zu wählen. Obwohl Sicherungen so konfiguriert sind, dass sie nur im Leerlauf CPU verbrauchen, können sie unter bestimmten Umständen Verdichtungen in Cassandra auslösen, was zu einem Anstieg des CPU-Verbrauchs führen kann. Verdichtungen können bei Cassandra jederzeit auftreten und hängen von der Arbeitsauslastung und der gewählten Verdichtungsstrategie ab.

Wichtig

Sicherungen dienen lediglich dazu, versehentliche Datenverluste oder Datenbeschädigungen zu vermeiden. Wir empfehlen Sicherungen nicht als Notfallwiederherstellungsstrategie. Sicherungen sind nicht georedundant, und selbst wenn sie es wären, kann es sehr lange dauern, eine Datenbank aus Sicherungen wiederherzustellen. Daher empfehlen wir dringend eine Bereitstellung in mehreren Regionen in Verbindung mit der Einrichtung von Verfügbarkeitszonen, wo immer dies möglich ist, um Notfallszenarien abzumildern und eine effektive Wiederherstellung zu ermöglichen. Dies ist besonders wichtig in den seltenen Fällen, in denen die ausgefallene Region nicht abgedeckt werden kann und ohne die Replikation in mehreren Regionen alle Daten verloren gehen können.

Nächste Schritte

In diesem Artikel wurden einige bewährte Methoden zum Erstellen resilienter Anwendungen mit Cassandra erläutert.

Erstellen eines Clusters im Azure-Portal