Eine der wichtigsten Aufgaben eines Datenbank-Administrators (DBA) ist die Überwachung der Datenbanken im laufenden Betrieb. Die neue Version der Open-Source-NoSQL-Datenbank Apache Cassandra liefert dafür sehr hilfreiche Auditing Tools. Dieser Blog-Beitrag gibt einen Überblick über die wichtigsten Neuerungen. 

What's new? 

Zu den wichtigsten Änderungen der neuen Version zählt das Audit-Logging. Wir zeigen Ihnen, wie Sie diese Funktion aktivieren und welchen Nutzen Sie daraus ziehen können. Als weitere Neuerung sind die virtuellen Tabellen (orig.: virtual tables) zu erwähnen. Mithilfe der virtuellen Tabellen bekommt der Benutzer schnell einen Überblick über die wichtigsten Informationen des Knotens. Außerdem zählen die neuen Features "full-query-logging" und "transient replication" zu den weiteren Verbesserungen von Cassandra. Anmerkend möchten wir erwähnen, dass Cassandra 4.0 die supporteten Versionen der notwendigen Pakete wie Java und Python unterstützt.

 Lohnt sich also das Upgrade auf die neue Version? Hier erfahren Sie es.

Audit-Logging 

Zur Aktivierung des Auditing werden die folgenden Schritte ausgeführt. Für unser Beispiel benutzen wir das folgende Setup für einen Cluster:

node1; 192.169.1.10

node2; 192.169.1.11

Alle Server sind bereits auf Netzwerk- und Betriebssystemebene auf einen Clusterbetrieb vorbereitet.

Weiterhin sind die Softwarepakete Apache Cassandra 4.0.4, Java 11.0.15 und Python 3.9.13 installiert, sowie grundlegende Einstellungen wie listen_address, endpoint_snitch, rpc_adress, authenticator, authorizer und seeds in der cassandra.yaml getätigt.

Damit wir das Verhalten beobachten können, erstellen wir darüber hinaus ein Keyspace "testdaten" und eine dazugehörige Tabelle "testtabelle1".

Audit-Logging aktivieren 

Um die Auditierung zu aktiveren, stellen wir die Einstellung „enabled“ in der cassandra.yaml auf true. Alternativ kann auch der Befehl nodetool enableauditlog verwendet werden.

Audit-Logging konfigurieren 

Bei der Art des Logging gibt es mit dem BinAuditLogger und dem FileAuditLogger zwei verschiedene Möglichkeiten. Diese unterscheiden sich hinsichtlich der Performance und des Dateityps der „save-files“. Der BinAuditLogger, welchen wir auch im Beispiel benutzen, speichert die Informationen in einem binären Dateiformat. Dadurch wird das Schreiben der Daten effizienter. Im Gegensatz dazu beschreibt der FileAuditLogger die Dateien im Klartextformat. So sind wir als Administratoren in der Lage, die Informationen aus der Datei direkt dem Klartext zu entnehmen. Beim binären Format verwenden wir für das Lesen der Audit-Daten das mitgelieferte Tool auditlogviewer. 

Im nächsten Schritt befüllen wir das Auditlog mit Daten, indem Anfragen von der CQL-Shell an die Datenbank gesendet werden. 

​Daraus ergeben sich die folgenden Audit-Einträge:

Anhand dieser Logs kann der Datenbank-Administrator viele Informationen ablesen. Dabei werden Details zu den Koordinator- und Quellknoten, CQL-Abfragen, sowie Ausführungszeiten angezeigt. Durch den Hinweis „category: ERROR“ erkennen wir direkt fehlerhafte Requests, auch bei der Authentifizierung. Anhand des letzten Beispiels ist erkennbar, dass Passwörter nicht im Klartext abgespeichert, sondern maskiert werden. 

Fazit Audit-Logging 

Audit-Logging ermöglicht dem Benutzer eine Echtzeitüberwachung und unterstützt ein Debugging. Je nach Cluster-Aufbau und Einsatz ist die Nutzung von Audit-Logging zu empfehlen. Bei einem Einsatz mit hoher Schreiblast empfehlen wir die Performance zu beobachten, da durch das Auditing mehr Overhead bei den Schreibvorgängen erzeugt wird.

Die erzeugten Logs enthalten viele Informationen. Bereits in der Standard-Einstellung sind diese gut filterbar, wodurch weiterführende Analysen vereinfacht werden. Im Vergleich zu den meisten anderen Datenbank-Management-Systemen (z.B. PostgreSQL, MySQL, MongoDB) bietet das Feature ähnliche Informationen in der Ausgabe.

Virtual tables 

Virtuelle Tabellen unterscheiden sich von herkömmlichen. Im Gegensatz zu den „normalen“ Tabellen sind die virtuellen Pendants nicht anpassbar. Das heißt, der Benutzer kann keine DDL- oder DML-Kommandos anwenden. Cassandra übernimmt deswegen die Administration der virtuellen Tabellen. Diese werden für jeden Knoten erstellt und beinhalten Informationen über ebendiesen Knoten. Die virtuellen Tabellen gehören zu den Keyspaces „system_virtual_schema“ oder „system_views“.

Cassandra bietet diverse Statistiken und folgende Tabellen:

• caches (system_views): System Caches
• clients (system_views): Aktuell verbundene Clients
• settings (system_views): Aktuelle Einstellungen aus der cassandra.yaml
• sstable_tasks (system_views): Aktuelle sstable tasks
• system_properties (system_views) Systemeinstellungen
• columns (system_virtual_schema): Spaltendefinitionen der virtuellen Tabellen
• keyspaces (system_virtual_schema): Keyspace-Definitionen der virtuellen Tabellen
• tables (system_virtual_schema): Liste aller virtuellen Tabellen

Weitere Neuerungen 

Audit-Logging und virtuelle Tabellen sind nicht die einzigen Neuerungen. Direkt bei den Voraussetzungen für die Installation bzw. das Update auf Apache Cassandra 4.0 sind zwei Veränderungen zu erwähnen. Neben Java 8 gilt nun auch Java 11 zu den unterstützten Versionen der Datenbank. Apache möchte zukünftig alle weiteren Java-Versionen mit Langzeit-Support in Cassandra aufnehmen. Die Kommandozeilen-Schnittstelle, über welche der Nutzer mit der Datenbank Cassandra interagiert (die CQL-Shell), ist auch von dem Versionssprung betroffen. Die CQL-Shell läuft jetzt über die Python-Version 3.6 und höher.

Des Weiteren implementierten die Entwickler das „full query logging“. Ähnlich zum Audit-Logging schreibt das „full query logging“ CQL-Befehle in eine Datei. Mit dem Unterschied, dass nur die erfolgreichen Ausführungen gespeichert werden. Durch das Einspielen der Logs ergeben sich unterschiedliche Möglichkeiten. Die Loginformationen können z. B. zur Vereinfachung von Migrationen genutzt werden, da mithilfe der aufgezeichneten CQL-Befehle im Vorfeld neue Systeme aufgebaut und nach und nach mit den laufenden Veränderungen des "Alt"-Systems synchronisiert werden können. Dadurch ist es möglich, Umschaltzeiten im Rahmen einer Migration zu verkürzen. Zusätzlich kann der Administrator diese Daten des Logs zum Benchmarken benutzen. Die aufgezeichnete Last kann gegen Cassandra-Versionen immer wieder getestet werden. Laufzeit-Unterschiede (Performance) können so identifiziert werden.

Unter anderem kann das neue experimentelle Feature ‚transient replication' genutzt werden, um Speicher einzusparen. Durch diese Neuerung besteht die Möglichkeit, die Anzahl der Repliken zu verringern, ohne dass der Replikationsfaktor und damit verbunden die Ausfallsicherheit der Daten verringert werden muss.

Apache Cassandra 4 bietet auch im Bereich der Sicherheit Verbesserungen. Unter anderem mit dem „SSL Certificate Hot Reloading“. Bisher musste der Administrator bei Anpassung des Truststores (z. B. durch Hinzufügen eines neuen Knotens in den Cluster) jeden Knoten neu starten. Nun erkennt das Datenbankmanagementsystem automatisch nach einem definieren Zeitintervall oder manuell über ein Kommando die Änderung und wendet diese ohne Neustart an.

Lohnt sich das Upgrade? 

Ein Upgrade auf Apache Cassandra 4.0 wird generell jedem Nutzer empfohlen. Allein durch die Unterstützung der supporteten Java- und Python-Versionen ist das Upgrade ein Muss für jede produktive Umgebung. Die weiteren neuen Funktionen können bei Bedarf aktiviert werden: Auditing ist für jeden DBA eine große Hilfe und in vielen großen Unternehmen eine wichtige Voraussetzung, um Sicherheitsrichtlinien zu erfüllen. Nicht zuletzt sollte die bessere Performance letzte Zweifel aus dem Weg räumen. Die neue Cassandra-Version ist nach Angaben der Entwickler um ein Vielfaches effizienter. Das Aktivieren der Neuerungen sollte für geübte Administratoren kein großes Hindernis darstellen.

Für alle, die ihr Know-how bei der Administration von Apache Cassandra aufbauen wollen, empfehlen wir den Besuch von unseren Kurs Apache Cassandra Administration.