Verwaltungsvorgänge in Azure Managed Instance for Apache Cassandra

2025-06-10

Azure Managed Instance for Apache Cassandra ist ein vollständig verwalteter Service für reine Open-Source Apache Cassandra-Cluster. Der Dienst ermöglicht es auch, Konfigurationen zu überschreiben, je nach den spezifischen Anforderungen jeder Workload, die maximale Flexibilität und Kontrolle bei Bedarf ermöglicht.

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. Dieser Dienst führt derzeit eine kleinere Komprimierung mithilfe der Reparatur durch, weitere Informationen finden Sie unter "Wartung". Dieser Vorgang führt eine Merkle-Baumkomprimierung aus, die eine besondere Art von Komprimierung ist.
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 eine Komprimierungsstrategie für Ihre Workload sorgfältig auszuwählen. Führen Sie keine manuellen Komprimierungen außerhalb der Strategie durch.

Patchen

Patches auf Betriebssystemebene werden automatisch in zwei Wochen durchgeführt.
Patches auf Apache Cassandra-Softwareebene erfolgen, sobald Sicherheitsrisiken erkannt werden. Die Patchfrequenz kann variieren.
Während des Patchens werden Computer rackweise neu gestartet. Sie sollten keine Beeinträchtigung auf der Anwendungsseite erleben, solange die Quorum-ALL-Einstellung nicht verwendet wird, und der Replikationsfaktor 3 oder höher ist.
Die Version in Apache Cassandra hat das Format X.Y.Z. Mithilfe von Diensttools können Sie die Bereitstellung von Hauptversionen (X) und Nebenversionen (Y) manuell steuern. Die Cassandra-Patches (Z), die für diese Haupt-/Nebenversionskombination möglicherweise erforderlich sind, werden automatisch durchgeführt.

Hinweis

Der Dienst unterstützt derzeit die Cassandra-Versionen 3.11 und 4.0. Beide Versionen sind allgemein verfügbar. Informationen zum Angeben einer Cassandra-Version beim Bereitstellen eines Clusters finden Sie in der Azure CLI-Schnellstartanleitung.

Wartung

Der Dienst führt nodetool repair mithilfe von reaper aus. Dieses Tool wird einmal pro Woche ausgeführt. Wenn Sie Ihren eigenen Dienst für eine Hybridbereitstellung verwenden, sollten Sie die Reaper deaktivieren.
Die Überwachung der Knotenintegrität umfasst Folgendes:
- Aktive Überwachung der Mitgliedschaft jedes Knotens im Cassandra-Ring
- Automatische Erkennung und Minderung von Infrastrukturproblemen wie bei virtuellen Maschinen, Netzwerken, Speichern, Linux und unterstützender Software.
- 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.

Unterstützung

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:

Einzelner Ansprechpartner für Cassandra-Infrastrukturprobleme. Es ist nicht erforderlich, Supportfälle bei IaaS-Teams wie Datenträger, Compute und Netzwerk separat einzureichen.
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 Patching.
Unterstützung durch das interne Java JDK/JVM-Engineering-Team.
Linux-Betriebssystemsupport mit Sicherheit der Softwarelieferkette.

Wichtig

Microsoft untersucht und diagnostiziert alle Probleme, die über einen Supportfall gemeldet werden. Der Support löst oder entschärft Probleme da, wo es möglich ist. Sie tragen letztendlich die Verantwortung für jeglichen Einsatz von Apache Cassandra-Konfigurationsebenen, der zu CPU-, Datenträger- oder Netzwerkproblemen führt.

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

Microsoft kann einen Supportfall untersuchen und feststellen, dass die Ursache des Problems auf Apache Cassandra-Konfigurationsebene liegt. Ein solches Problem stammt nicht aus allen zugrunde liegenden Aspekten auf Plattformebene, die Azure verwaltet. Der Support bietet weiterhin Empfehlungen und Anleitungen zur Behebung oder Entschärfung, bevor er den Fall schließt.

Wir empfehlen, Metriken zu aktivieren und sich mit unserer Azure Monitor-Integration vertraut zu machen, um häufige Probleme auf Anwendungs-/Konfigurationsebene in Apache Cassandra zu verhindern, z. B. zuvor beschrieben.

Warnung

Azure Managed Instance für Apache Cassandra ermöglicht es Ihnen auch, nodetool und sstable Befehle zur routinemäßigen Verwaltung von DBA-Aufgaben auszuführen. Weitere Informationen finden Sie unter DBA-Befehle für azure Managed Instance für Apache Cassandra.

Einige dieser Befehle können den Cassandra-Cluster destabilisieren. Sie sollten diese Befehle nach dem Testen in Nichtproduktionsumgebungen sorgfältig ausführen. Verwenden Sie nach Möglichkeit zuerst eine --dry-run Option. Microsoft bietet keine SLA oder Unterstützung für Probleme mit ausgeführten Befehlen, die die Standarddatenbankkonfiguration 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 für bis zu zwei Tage (48 Stunden) aufbewahrt. Es gibt keine Kosten für die ersten beiden Sicherungen. Zusätzliche Sicherungen werden in Rechnung gestellt. Siehe Preise. Um das Sicherungsintervall oder den Aufbewahrungszeitraum zu ändern, können Sie die Richtlinie im Azure-Portal bearbeiten:

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

Stellen Sie die Sicherungs-ID aus dem Portal für die Sicherung bereit, die Sie wiederherstellen möchten. Sie finden diese ID im Azure-Portal:
Lassen Sie uns wissen, ob das Quellrechenzentrum gelöscht wurde. Diese Tatsache ist wichtig, um das richtige Sicherungskonto zu identifizieren, aus dem wiederhergestellt werden soll.
Wenn Sie nicht den gesamten Cluster wiederherstellen müssen, geben Sie, falls zutreffend, den Keyspace und die Tabelle an, die wiederhergestellt werden müssen.
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. Stellen Sie sicher, dass das entsprechende Rechenzentrum dieselbe Anzahl von Knoten aufweist. Sie können auch entscheiden, ob Sie die Anmeldeinformationen im neuen Zielcluster beibehalten. Alternativ können Sie erlauben, dass die Wiederherstellung den Benutzernamen und das Kennwort mit dem ursprünglich Erstellten außer Kraft setzt.
Sie können auch entscheiden, ob system_auth-Keyspace im neuen Zielcluster beibehalten werden soll, oder ob die Wiederherstellung ihn 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. Der Standardwiederherstellungsprozess überschreibt den system_auth Schlüsselbereich.

Hinweis

Die Zeit, die erforderlich ist, um auf eine Anforderung zur Wiederherstellung aus der Sicherung zu reagieren, hängt vom Schweregrad des supportfalls ab, den Sie auslösen, der SLA für die Antwortzeit und der Menge der wiederherzustellenden Daten. Wir bieten keine SLA für die Dauer der Wiederherstellung an. Dieser Wert ist zeitabhängig vom Datenvolumen, das wiederhergestellt wird.

Warnung

Sicherungen sind für versehentliche Löschszenarien vorgesehen und sind nicht georedundant. Es wird nicht empfohlen, Sicherungen für die Verwendung als Notfallwiederherstellungsstrategie (DR) für regionale Ausfalle zu verwenden. Um gegen umfassende Ausfälle in Regionen zu schützen, empfehlen wir eine Bereitstellung über mehrere Regionen hinweg. Weitere Informationen finden Sie in der Schnellstartanleitung für Bereitstellungen mit mehreren Regionen.

Sicherheit

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

Gehärtete Linux-VM-Images mit einer kontrollierten 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 unter Sicherheit in Azure Managed Instance für Apache Cassandra.

Unterstützung für Hybridlösungen

Wenn ein Hybridcluster konfiguriert ist, profitieren automatisierte Reapervorgänge, die im Dienst ausgeführt werden, vom gesamten Cluster. Dieser Aspekt umfasst Rechenzentren, die nicht vom Dienst bereitgestellt werden. Es liegt in Ihrer Verantwortung, Ihr lokales oder extern gehostetes Rechenzentrum zu verwalten.

Freigeben über