Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Azure Managed Instance for Apache Cassandra ist ein vollständig verwalteter Service für reine Open-Source Apache Cassandra-Cluster. Der Dienst ermöglicht die Außerkraftsetzung von Konfigurationen, abhängig von den Anforderungen jeder Workload, die maximale Flexibilität und Kontrolle bei Bedarf ermöglicht.
Apache Cassandra ist eine großartige Wahl für die Erstellung von hochresilienten Anwendungen aufgrund ihrer verteilten Natur und Peer-to-Peer-Architektur. Jeder Knoten in der Datenbank kann die gleiche Funktionalität wie jeder andere Knoten bereitstellen. Dieses Design trägt zur Stabilität und Resilienz von Cassandra bei. Dieser Artikel enthält Tipps zum Optimieren der Hochverfügbarkeit und zum Ansatz für die Notfallwiederherstellung.
Ziel des Wiederherstellungspunkts und Ziel der Wiederherstellungszeit
Solange Sie die folgenden Elemente haben, sind Wiederherstellungspunktziel (RPO) und Wiederherstellungszeitziel (RTO) in der Regel niedrig, nahe Null:
- Eine Bereitstellung mit mehreren Regionen mit regionsübergreifender Replikation und einem Replikationsfaktor von 3.
- Aktivierte Verfügbarkeitszonen. Konfigurieren Sie diese Option, wenn Sie einen Cluster im Azure-Portal oder mithilfe der Azure CLI erstellen.
- Failover auf Anwendungsebene mithilfe der Lastenausgleichsrichtlinie im Clienttreiber oder Lastenausgleichsfailover mithilfe von Azure Traffic Manager oder Azure Front Door konfiguriert haben.
RTO ist, wie lange ein Ausfall andauert. Dies ist niedrig, da der Cluster sowohl in Zonen als auch in Regionen stabil ist. Außerdem ist Apache Cassandra selbst ein sehr fehlertolerantes Peer-to-Peer-System, in dem alle Knoten standardmäßig schreiben können.
RPO ist die Menge an Daten, die Sie bei einem Ausfall verlieren können. Es ist niedrig, da Daten zwischen allen Knoten und Rechenzentren synchronisiert werden. Datenverlust in einem Ausfall wäre minimal.
Hinweis
Es ist nicht möglich, sowohl RTO=0 als auch RPO=0 pro CAP-Theorem zu erreichen. Bewerten Sie den Kompromiss zwischen Konsistenz und Verfügbarkeit oder optimaler Leistung.
Dieses Gleichgewicht sieht für jede Anwendung anders aus. Wenn Ihre Anwendung beispielsweise schwer gelesen wird, ist es möglicherweise besser, mit einer erhöhten Latenz von regionsübergreifenden Schreibvorgängen zu umgehen, um Datenverluste zu vermeiden, was die Konsistenz begünstigt. Wenn die Anwendung bei engen Latenzanforderungen schreiblastig ist, könnte das Risiko akzeptabel sein, einige der aktuellsten Schreibvorgänge in einem großen regionalen Ausfall zu verlieren, was zugunsten der Verfügbarkeit wäre.
Verfügbarkeitszonen
Cassandras Peer-to-Peer-Architektur bringt Fehlertoleranz von Anfang an. Azure Managed Instance für Apache Cassandra bietet Unterstützung für Verfügbarkeitszonen in ausgewählten Regionen. Diese Unterstützung verbessert die Resilienz auf Infrastrukturebene. Für einen Replikationsfaktor von 3 stellt die Verfügbarkeitszonenunterstützung sicher, dass sich jedes Replikat in einer anderen Verfügbarkeitszone befindet. Durch diesen Ansatz wird verhindert, dass sich ein zonaler Ausfall auf Ihre Datenbank oder Anwendung auswirkt. Wir empfehlen, Verfügbarkeitszonen zu aktivieren, wo immer dies möglich ist.
Redundanz für mehrere Regionen
Die Architektur von Cassandra, gepaart mit der Unterstützung von Azure-Verfügbarkeitszonen, bietet Ihnen ein Maß an Fehlertoleranz und Ausfallsicherheit. Berücksichtigen Sie auch die Auswirkungen regionaler Ausfälle für Ihre Anwendungen. Um vor Ausfallen auf Regionsebene zu schützen, wird dringend empfohlen, mehrere Regionscluster bereitzustellen. Sie sind zwar selten, aber die möglichen Auswirkungen sind gravierend.
Für geschäftskontinuität reicht es nicht aus, eine Datenbank mit mehreren Regionen zu verwenden. Andere Teile Ihrer Anwendung müssen ebenfalls verteilt oder mit angemessenen Mechanismen ausgestattet werden, um ein Failover ausführen zu können. Wenn Ihre Benutzer über viele geografische Standorte verteilt sind, hat eine Bereitstellung des Rechenzentrums für mehrere Regionen für Ihre Datenbank den zusätzlichen Vorteil, die Latenz zu reduzieren. Alle Knoten in allen Rechenzentren im gesamten Cluster können sowohl Lese- als auch Schreibvorgänge aus der Region bereitstellen, die ihnen am nächsten kommt.
Wenn die Anwendung so konfiguriert ist, dass sie active-active ist, überlegen Sie, wie das CAP-Theorem auf die Konsistenz Ihrer Daten zwischen Replikaten (Knoten) zur Anwendung kommt und welche Kompromisse zur Gewährleistung hoher Verfügbarkeit erforderlich sind.
Im Kontext des CAP-Theorems ist Cassandra standardmäßig ein verfügbares, partitionstolerantes (AP) Datenbanksystem mit hoch anpassbarer 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 Kompromisse bei Zuverlässigkeit und Leistung. Zur Zuverlässigkeit empfehlen wir QUORUM_EACH, aber für die meisten Benutzer LOCAL_QUORUM oder QUORUM ist ein guter Kompromiss. Wenn ein regionaler Ausfall vorhanden ist, gehen einige Schreibvorgänge möglicherweise in „LOCAL_QUORUM“ verloren.
Wenn eine Anwendung parallel ausgeführt wird, bevorzugen Sie „QUORUM_EACH“-Schreibvorgänge für die meisten Fälle, um die Konsistenz zwischen den beiden Rechenzentren sicherzustellen.
Wenn Ihr Ziel darin besteht, Konsistenz oder niedrigere RPO anstelle von Latenz oder Verfügbarkeit oder niedrigerer RTO zu bevorzugen, sollten Die Konsistenzeinstellungen und der Replikationsfaktor dieses Ziel widerspiegeln.
Im Allgemeinen sollte die Anzahl der für einen Lesevorgang erforderlichen Quorumknoten plus die Anzahl der für einen Schreibvorgang erforderlichen Quorumknoten größer sein 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 ist die Region, die beim Bereitstellen des ersten Rechenzentrums ausgewählt ist. 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.
Da Rechenzentren weiterhin funktionieren sollten, wirkt sich dieses Problem nicht auf die Verfügbarkeits-SLA für den Dienst aus. In diesem Zeitraum ist es möglicherweise nicht möglich, Änderungen an der Datenbankkonfiguration aus dem Azure-Portal oder den Tools für Ressourcenanbieter vorzunehmen.
Replikation
Wir empfehlen, von Zeit zu Zeit keyspaces und dessen Replikationseinstellungen zu überprüfen, um sicherzustellen, dass die erforderliche Replikation zwischen Rechenzentren konfiguriert ist. In den frühen Entwicklungsphasen empfehlen wir, einfache Tests mithilfe von cqlsh durchzuführen. Fügen Sie beispielsweise einen Wert ein, während sie mit einem Rechenzentrum verbunden ist, und lesen Sie ihn aus dem anderen.
Wenn Sie ein zweites Rechenzentrum einrichten, in dem bereits Daten vorhanden sind, bestimmen Sie insbesondere, dass Sie alle Daten repliziert haben und dass das System bereit ist. Wir empfehlen, den Replikationsfortschritt über unsere DBA-Befehle mit nodetool netstats zu überwachen. Ein alternativer Ansatz wäre das Zählen der Zeilen in jeder Tabelle. Beachten Sie, dass dieser Ansatz aufgrund der verteilten Natur von Cassandra bei großen Datenmengen nur eine grobe Schätzung liefern kann.
Ausgleich der Kosten für die Notfallwiederherstellung
Wenn Ihre Anwendung aktiv-passiv ist, wird in der Regel empfohlen, die gleiche Kapazität in den einzelnen Regionen bereitzustellen. Dieser Ansatz hilft Ihrer Anwendung, sofort zu einem Hot-Standby-Rechenzentrum in einer sekundären Region zu übergehen. Wenn ein regionaler Ausfall auftritt, stellt dieser Ansatz keine Leistungsbeeinträchtigung sicher. Die meisten Cassandra-Clienttreiber bieten Optionen, um Failover auf Anwendungsebene zu initiieren. Standardmäßig geht man davon aus, dass ein regionaler Ausfall bedeutet, dass auch die Anwendung betroffen ist, sodass ein Failover auf der Ebene des Lastenausgleichs erfolgen sollte.
Um 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. Wenn ein Ausfall auftritt, erleichtert die schlüsselfertige vertikale und horizontale Skalierung das Hochskalieren in Azure Managed Instance für Apache Cassandra. Wenn Ihre Anwendungen auf Ihre sekundäre Region umschalten, können Sie die Knoten im sekundären Rechenzentrum manuell erweitern und hochskalieren. Ihr sekundäres Rechenzentrum fungiert als kostengünstiges Warm-Standby-Zentrum. Diese Vorgehensweise muss mit der Zeit ausgeglichen werden, die erforderlich ist, um Ihr System in vollem Umfang wiederherzustellen, wenn ein Ausfall auftritt. Es ist wichtig, zu testen und zu üben, was passiert, wenn eine Region ausfällt.
Hinweis
Das Hochskalieren von Knoten ist viel schneller als das Herauswachsen. Beachten Sie diese Tatsache, wenn Sie das Gleichgewicht zwischen vertikaler und horizontaler Skalierung und der Anzahl der Knoten berücksichtigen, die für Ihren Cluster bereitgestellt werden sollen.
Sicherungszeitpläne
Sicherungen werden in azure Managed Instance für Apache Cassandra automatisch ausgeführt. Sie können Ihren eigenen Zeitplan für die täglichen Sicherungen auswählen. 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. Komprimierungen können jederzeit mit Cassandra passieren. Sie hängen von der Arbeitsauslastung und der gewählten Komprimierungsstrategie ab.
Wichtig
Die Absicht von Sicherungen besteht lediglich darin, versehentlichen Datenverlust oder Datenbeschädigungen zu mindern. Wir empfehlen Sicherungen nicht als Notfallwiederherstellungsstrategie.
Sicherungen sind nicht georedundant. Selbst wenn ja, kann es lange dauern, eine Datenbank aus Sicherungen wiederherzustellen. Daher empfehlen wir dringend, Bereitstellungen über mehrere Regionen zu verwenden und, wenn möglich, Verfügbarkeitszonen zu aktivieren, um Notfallszenarien abzuschwächen und sich effektiv von diesen zu erholen. Dieser Ansatz ist besonders wichtig in den seltenen Szenarien, in denen die fehlgeschlagene Region nicht wiederhergestellt werden kann. Ohne Replikation mit mehreren Regionen können alle Daten verloren gegangen sein.
