Verwaltungsvorgänge in Azure Managed Instance for Apache Cassandra

Artikel
10/26/2023

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. In diesem Artikel werden die vom Dienst gebotenen Verwaltungsvorgänge und -features vorgestellt. Außerdem wird die Trennung von Zuständigkeiten zwischen dem Azure-Supportteam und der Kundschaft bei der Verwaltung von hybriden Clustern erläutert.

Komprimierung

Es gibt verschiedene Arten von Komprimierungen. Wir führen derzeit eine kleinere Komprimierung über Reparatur durch (siehe Wartung). Die Reparatur führt die Merkle-Strukturkomprimierung durch, eine besondere Art der Komprimierung.
Abhängig von der Komprimierungsstrategie, die für die Tabelle mit CQL festgelegt wurde (z. B WITH compaction = { 'class' : 'LeveledCompactionStrategy' }), wird Cassandra automatisch komprimiert, wenn die Tabelle eine bestimmte Größe erreicht. Sie sollten sorgfältig eine Komprimierungsstrategie für Ihre Workload auswählen und außerhalb der Strategie keine manuellen Komprimierungen durchführen.

Patching

Patches auf Betriebssystemebene erfolgen automatisch in einem Rhythmus von etwa zwei Wochen.
Patches auf Apache Cassandra-Softwareebene erfolgen, sobald Sicherheitsrisiken erkannt werden. Der Rhythmus des Patchens kann variieren.
Während des Patchens werden Computer rackweise neu gestartet. Sie sollten keine Beeinträchtigung auf Anwendungsseite bemerken, solange die Quorumeinstellung ALL nicht verwendet wird, und der Replikationsfaktor 3 oder höher ist.
Die Version in Apache Cassandra hat das Format X.Y.Z. Sie können mithilfe von Diensttools die Bereitstellung von Hauptversionen (X) und Nebenversionen (Y) manuell steuern. Die Cassandra-Patches (Z), die für diese Kombination von Haupt- und Nebenversion erforderlich sein können, erfolgen jedoch automatisch.

Hinweis

Der Dienst unterstützt derzeit die Cassandra-Versionen 3.11 und 4.0. Beide Versionen sind allgemein verfügbar. Informationen zur Angabe der Cassandra-Version während der Clusterbereitstellung finden Sie in unserem Azure CLI-Schnellstart (Schritt 5).

Wartung

Die Nodetool-Reparatur wird vom Dienst mithilfe reaper automatisch durchgeführt. Dieses Tool wird einmal pro Woche ausgeführt. Sie können es deaktivieren, wenn Sie für eine Hybridbereitstellung Ihren eigenen Dienst verwenden.
Die Überwachung der Knotenintegrität umfasst Folgendes:
- Aktive Überwachung der Mitgliedschaft jedes Knotens im Cassandra-Ring
- Automatische Erkennung und automatisches Auslagern von Infrastrukturproblemen wie virtueller Computer, Netzwerk, Speicher, Linux und Support-Softwarefehler.
- Aktive Überwachung von CPU-, Datenträger-, Quorumverlusten und anderen Ressourcenproblemen.
- Automatisches Aufrufen fehlerhafter Knoten, wenn möglich, und manuelles Aufrufen von Knoten als Reaktion auf automatisch generierte Warnungen.

Support

Azure Managed Instance for Apache Cassandra bietet eine SLA für die Verfügbarkeit von Rechenzentren in einem verwalteten Cluster. Wenn bei der Verwendung des Diensts Probleme auftreten, stellen Sie eine Supportanfrage im Azure-Portal.

Zu unseren Supportvorteilen gehören:

Eine einzige Kontaktperson für Probleme mit der Cassandra-Infrastruktur – es ist nicht erforderlich, Supportanfragen an die IaaS-Teams (Festplatten, Rechner, Netzwerke) separat zu stellen.
Proaktive Beratung per E-Mail zu Leistungsengpässen, Größenanpassungen und anderen Ressourceneinschränkungen.
24x7-Support, einschließlich automatisch generierter Vorfälle für schwerwiegende Ausfälle.
Von der Community genehmigte Patchunterstützung (siehe Patchen).
Support durch das interne Java JDK/JVM-Entwicklungsteams.
Linux-Betriebssystemsupport mit Sicherheit der Softwarelieferkette.

Wichtig

Wir untersuchen und diagnostizieren Probleme, die im Supportfall gemeldet werden, und beheben oder lösen sie nach Möglichkeit. Sie sind jedoch letztendlich für jede Nutzung auf Apache Cassandra-Konfigurationsebene verantwortlich, die CPU-, Datenträger- oder Netzwerkprobleme verursacht.

Beispiele für solche Probleme sind u. a.:

Ineffiziente Abfragevorgänge
Die Kapazität überschreitender Durchsatz
Die Speicherkapazität überschreitende Datenerfassung
Falsche Konfigurationseinstellungen für Keyspace
Schlechte Datenmodell- oder Partitionsschlüsselstrategie

Für den Fall, dass wir einen Supportfall untersuchen und feststellen, dass die Ursache des Problems auf der Apache Cassandra-Konfigurationsebene liegt (und nicht auf der Ebene der von uns gewarteten Plattform), geben wir weiterhin Empfehlungen und Anleitungen zur Behebung oder Entschärfung (sofern möglich), bevor der Fall geschlossen wird.

Es wird empfohlen, Metriken zu aktivieren und/oder sich mit unserer Azure Monitor-Integration vertraut zu machen, um häufige Probleme auf Anwendung/Konfigurationsebene in Apache Cassandra zu vermeiden, z. B. die oben genannten.

Warnung

Mit Azure Managed Instance for Apache Cassandra können Sie außerdem die Befehle nodetool und sstable für die routinemäßige DBA-Verwaltung ausführen. Weitere Informationen finden Sie in diesem Artikel. Einige dieser Befehle können den Cassandra-Cluster destabilisieren und sollten in Nicht-Produktionsumgebungen nur mit Sorgfalt und nach dem Testen ausgeführt werden. Nach Möglichkeit sollte zuerst eine Option vom Typ --dry-run bereitgestellt werden. Microsoft kann keine SLA oder Unterstützung bei Problemen mit der Ausführung von Befehlen anbieten, die die Standardkonfiguration der Datenbank und/oder Tabellen ändern.

Sichern und Wiederherstellen

Momentaufnahmensicherungen sind standardmäßig aktiviert und werden alle 24 Stunden erstellt. Sicherungen werden in einem internen Azure Blob Storage-Konto gespeichert und bis zu 2 Tage (48 Stunden) aufbewahrt. Die ersten 2 Sicherungen sind kostenfrei. Zusätzliche Sicherungen werden in Rechnung gestellt, siehe Preise. Um das Sicherungsintervall oder den Aufbewahrungszeitraum zu ändern, können Sie die Richtlinie im Portal bearbeiten:

Um aus einer vorhandenen Sicherung wiederherzustellen, speichern Sie eine Supportanfrage im Azure-Portal. Wenn Sie den Supportfall einreichen, müssen Sie:

Stellen Sie die Sicherungs-ID aus dem Portal für die Sicherung bereit, die Sie wiederherstellen möchten. Dieser ist im Portal zu finden:
Wenn die Wiederherstellung des gesamten Clusters nicht erforderlich ist, stellen Sie die Schlüsseltasten und die Tabelle (falls zutreffend) bereit, die wiederhergestellt werden muss.
Empfehlen Sie, ob die Sicherung im vorhandenen Cluster oder in einem neuen Cluster wiederhergestellt werden soll.
Wenn Sie einen neuen Cluster wiederherstellen möchten, müssen Sie zuerst den neuen Cluster erstellen. Stellen Sie sicher, dass der Zielcluster dem Quellcluster in Bezug auf die Anzahl der Rechenzentren entspricht und dass das entsprechende Rechenzentrum dieselbe Anzahl von Knoten aufweist. Sie können auch entscheiden, ob die Anmeldeinformationen (Benutzername/Kennwort) im neuen Zielcluster beibehalten werden sollen, oder ob die Wiederherstellung das Außerkraftsetzen des Benutzernamens/Kennworts mit dem ursprünglich erstellten Zielcluster zulassen soll.
Sie können auch entscheiden, ob system_auth Keyspace im neuen Zielcluster beibehalten werden soll, oder ob die Wiederherstellung sie mit Daten aus der Sicherung überschreiben soll. Der system_auth Keyspace in Cassandra enthält Autorisierungs- und interne Authentifizierungsdaten, einschließlich Rollen, Rollenberechtigungen und Kennwörtern. Beachten Sie, dass unser Standardwiederherstellungsprozess die system_auth Keyspace überschreibt.

Hinweis

Die Zeit, die erforderlich ist, um auf eine Anforderung zur Wiederherstellung aus der Sicherung zu reagieren, hängt sowohl vom Schweregrad des Supportfalls ab, den Sie auslösen (und die entsprechende SLA für die Antwortzeit) als auch die Datenmenge, die wiederhergestellt werden soll. Wir stellen jedoch keine SLA für den Abschluss der Wiederherstellung bereit, da dies sehr von dem Datenvolumen abhängig ist, das wiederhergestellt wird.

Warnung

Sicherungen sind für Szenarien mit versehentlichem Löschen vorgesehen und nicht georedundant. Sie werden daher nicht für die Verwendung als Notfallwiederherstellungsstrategie im Falle eines gesamten regionalen Ausfalls empfohlen. Zum Schutz vor regionsweiten Ausfällen empfehlen wir eine Bereitstellung in mehreren Regionen. Informieren Sie sich über unseren Schnellstart für Bereitstellungen in mehreren Regionen.

Sicherheit

Azure Managed Instance for Apache Cassandra bietet viele integrierte explizite Sicherheitskontrollen und -features:

Gehärtete Linux-VM-Images mit kontrollierter Lieferkette
CVE-Überwachung (Common Vulnerability & Exposure) auf Betriebssystemebene
Rotation von Zertifikaten für Apache Cassandra- und Prometheus-Software, die auf den verwalteten VMs gehostet wird
Aktive Überprüfung auf Sicherheitsrisiken
Aktive Überprüfung auf Viren
Methoden zum Schreiben von sicherem Code

Weitere Informationen zu Sicherheitsfeatures finden Sie in unserem Artikel hier.

Unterstützung für Hybridlösungen

Wenn ein Hybridcluster konfiguriert ist, profitieren der gesamte Cluster von automatisierten Reaper-Vorgängen, die im Dienst ausgeführt werden. Dies schließt Rechenzentren ein, die nicht vom Dienst bereitgestellt werden. Ansonsten liegt die Betreuung Ihres lokalen oder extern gehosteten Rechenzentrums in Ihrer Verantwortung.

Nächste Schritte

Verwenden Sie eine unserer Schnellstartanleitungen: