Compose für den Referenzbetrieb, Ansible für die Installation

Observability vs. Monitoring im Datenbetrieb

Monitoring verfolgt bekannte Zustände, etwa die Erreichbarkeit eines Dienstes oder eine überschrittene Schwelle. Observability unterstützt die Untersuchung, warum ein System ein bestimmtes Verhalten zeigt. lavalake stellt dafür Systemzustand, Alarme und Protokolle in der Konsole bereit; der Metrik-Endpunkt lässt sich in eine eigene Überwachung einbinden.

Cloud-Arten und Betriebsort wählen

Public Cloud, Private Cloud und eigenes Rechenzentrum beschreiben unterschiedliche Betriebsumgebungen. Für lavalake wählen Sie die Infrastruktur und legen fest, wer Installation, Sicherung und Updates übernimmt. Prüfen Sie dabei Netzwerkzugriff, Speicher, Identitätsanbieter und Wiederherstellung. Ein gemieteter Server kann genauso Teil der Planung sein wie vorhandene Hardware.

Erst einmal auf einer Maschine

Ein Skript im Compose-Ordner erzeugt beim ersten Start die Geheimnisse, baut Konsole und Agent, fährt den Stapel hoch und richtet den Keycloak-Realm ein. Danach ist die Plattform unter einer Adresse erreichbar. Kein Kubernetes nötig, um zu sehen, ob das Ding taugt.

gateway     nginx, die einzige Tür nach außen
console     die Oberfläche
agent       Backend, Rechte und Werkzeuge
keycloak    Anmeldung, Rollen
trino       die Query-Engine
nessie      versionierter Iceberg-Katalog
minio       S3-kompatibler Speicher
postgres    Plattformzustand und Vektorindex
ollama      lokales Einbettungsmodell (CPU)
backup      tägliche Datenbank- und Konfigurationssicherung

Das lokale Einbettungsmodell läuft mit und wird bei Untätigkeit entladen, damit es keinen Arbeitsspeicher hält. Für die semantische Suche braucht es damit keinen Cloud-Schlüssel. Für den KI-Assistenten dagegen schon eine Anbindung Ihrer Wahl – mit der Plattform wird kein Modellschlüssel ausgeliefert.

Genau eine Tür nach außen

Alles läuft hinter einem Reverse-Proxy, und der kennt drei Routen: die Konsole, die Agent-Schnittstelle und Keycloak. Trino, der Objektspeicher und die Plattform-Datenbank sind von außen nicht erreichbar – nicht durch Konfiguration abgeschaltet, sondern gar nicht veröffentlicht.

Was nicht erreichbar ist, muss nicht abgesichert werden. Die kürzeste Absicherung ist eine fehlende Route.

Das hat eine Folge, die man kennen sollte: BI-Werkzeuge können sich nicht direkt an Trino hängen. Der Weg dorthin führt über einen eigenen, lesenden Feed der Plattform – nicht über einen offenen Datenbankport.

Kundeninstallation per Ansible

Die Referenzinstallation läuft als Compose-Stapel auf einer Maschine. Das mitgelieferte Ansible-Playbook bereitet eine Debian/Ubuntu-VM vor, installiert Docker, holt einen festgelegten Release, baut die Images nacheinander und startet die Plattform. Derselbe Ablauf dient dem Update. Vorhandene Schlüssel bleiben erhalten. Ein vollständiger Erstlauf auf einer frischen VM steht als Abnahme noch aus.

Sichern, warten und Verbrauch zuordnen

Ein eigener Dienst sichert im Compose-Stapel täglich alle PostgreSQL-Datenbanken einschließlich Keycloak und Nessie sowie die Konfiguration mit dem Verschlüsselungsschlüssel. Die Aufbewahrung beträgt standardmäßig 14 Tage; die letzte Sicherung bleibt erhalten. Die Überwachung zeigt Alter und Größe und meldet fehlende oder überfällige Sicherungen.

Regeltermine führen Berichte, Schwellwert-Alerts und Iceberg-Wartung aus. Die Überwachung ordnet Rechenzeit, gelesene Daten und KI-Verbrauch den Nutzern zu. Tageskontingente begrenzen die Abfragen und Tokens; KI-Kosten werden aus gepflegten Preisen berechnet. Listenpreise lassen sich auf Knopfdruck synchronisieren, ohne Vertragspreise zu überschreiben.

Leistungsklassen S, M und L steuern im Compose-Stapel Parallelität und weiche Speichergrenzen je Nutzerrolle. Sie ersetzen noch keine elastischen Compute-Cluster.

Was eine Maschine trägt

Die naheliegende Frage vor jeder Installation ist, wie groß die Maschine sein muss. Dafür gibt es seit dem 6. September 2026 eine Messung statt einer Schätzung: eine Referenzanlage wurde einen Tag lang unter steigender Last gefahren, bis sie abwies. Alle Zahlen unten stammen aus diesem Lauf.

Über alle Läufe dieses Tages hinweg gab es keinen Absturz. Dreißig Sekunden nach der härtesten Laststufe beantwortete dieselbe Anlage eine normale Abfrage in 76 Millisekunden, ohne Eingriff. Der Massenimport der 60 Millionen Zeilen lief in 73 Sekunden durch, also über 800.000 Zeilen je Sekunde.

Für die Größenwahl heißt das: Eine Maschine dieser Klasse trägt rund 50 gleichzeitige Analysten auf 60 Millionen Zeilen. Wer mehr braucht, reizt zuerst die eine Maschine aus – mehr Arbeitsspeicher für die Engine, ein Server mit mehr Kernen – und nimmt dann weitere Maschinen mit eigenen Kernen dazu.

Ein zweiter Knoten auf derselben Maschine brachte nichts: er teilt sich dieselben sechs Kerne. Mehr Arbeitsspeicher für die eine Engine brachte dagegen deutlich mehr — von 8 auf 16 GB stiegen die fertigen Analysen unter Höchstlast um 70 Prozent. Jenseits davon braucht es mehr Kerne: in einem größeren Server oder auf einer zweiten Maschine.

Nur die erste Zeile ist gemessen; die übrigen sind hochgerechnet, Kerne und Speicher gemeinsam skaliert. Für eine erste Planung brauchbar, kein Ersatz für eine Messung auf Ihrer Hardware.

Mit einer zweiten Maschine

Am 26. September 2026 haben wir die Maschine um einen Worker auf einem zweiten Server derselben Größe ergänzt und mit TPC-H gemessen, dem Standard-Test für Auswertungen: 60 Millionen Bestellpositionen, acht Standard-Abfragen, bewusst ohne Cache. Der Worker bringt eigene Kerne und eigenen Arbeitsspeicher mit und holt sich die Daten über ein verschlüsseltes Netz.

Unter Spitzenlast bringt die zweite Maschine 77 Prozent mehr Durchsatz und halbiert die Wartezeit. Sie lohnt sich, sobald mehrere große Auswertungen gleichzeitig laufen – etwa zum Monatsabschluss.

Die Konsole zeigt jeden Rechenknoten mit Auslastung und laufenden Aufgaben und meldet, wenn einer wegfällt. Die vollständigen Messwerte und die Reihenfolge beim Ausbau stehen in der Dokumentation zur Dimensionierung.

Der Kubernetes-Weg

Für Kubernetes gibt es ein Chart, das die Plattform samt Abhängigkeiten ausrollt: drei getrennte PostgreSQL-Instanzen für Nessie, Keycloak und den Plattformzustand, SeaweedFS als Speicher, Keycloak, Nessie, Trino, ein nginx-Ingress als die eine öffentliche Tür und optional cert-manager für die Zertifikate.

Dass Keycloak über das Chart von codecentric kommt und nicht über das von Bitnami, ist kein Geschmack: die Bitnami-Abbilder sind hinter eine Bezahlschranke gewandert und halten keine ziehbaren versionierten Marken mehr vor. Solche Entscheidungen stehen im Chart als Kommentar – wer den Stapel betreibt, muss wissen, woher die Abbilder kommen.

Der Objektspeicher und PostgreSQL sind Abhängigkeiten mit Schalter. Wenn in Ihrem Rechenzentrum schon ein S3-kompatibler Speicher und eine betreute Datenbank stehen, zeigen Sie darauf, statt zwei weitere zu betreiben.

Betriebsbausteine nach Bedarf

Der Sicherheitskern steht: delegierte Identität, Richtlinien in der Engine, WORM-Audit, Egress-Schutz, verschlüsselte Geheimnisse, prozessisoliertes Parsen. Weitere Betriebsbausteine lassen sich gezielt zuschalten. Das HA-Profil für Kubernetes wartet noch auf die Cluster- und Ausfallabnahme.

• HA-Profil für Kubernetes; Cluster- und Ausfallabnahme offen
• Systemzustand, Alarme und Protokolle in der Konsole
• Secret-Dateien für Compose; Vault/External Secrets für Kubernetes
• Zuschaltbare interne TLS-Ebene für die dokumentierten Dienstverbindungen
• Offline-Betrieb per Compose mit lokalen Modellen
• Wiederherstellung auf einen Zeitpunkt, mit Sicherung an einen zweiten Ort

Die Betriebsdokumentation beschreibt Einrichtung, Voraussetzungen und Prüfung jeder Ebene. Compose und Kubernetes unterscheiden sich im Umfang.