Compose betreiben: Installation, Wartung und Sicherung

Installation und Updates per Ansible#

Das Playbook unter deploy/ansible bereitet eine Debian/Ubuntu-VM mit SSH-Zugang vor: Docker installieren, einen festgelegten Release holen, fehlende Geheimnisse erzeugen, Images einzeln bauen und den Compose-Stapel starten. Es wartet auf einen gesunden Agenten und eine vorhandene Sicherung. Tragen Sie Zielhost und SSH-Nutzer in Ihr Inventar ein und setzen Sie lavalake_version auf den gewünschten Release-Tag.

cd deploy/ansible
cp inventar.beispiel.ini inventar.ini
# Zielhost, SSH-Nutzer und lavalake_version in inventar.ini festlegen
ansible-playbook -i inventar.ini install.yml

Für ein Update ändern Sie den Release-Tag und führen dasselbe Playbook aus. Vorhandene Schlüssel bleiben erhalten; Datenbank-Migrationen laufen beim Start. Images werden nacheinander gebaut, um die Speicherspitze auf kleinen Maschinen zu begrenzen.

Regeltermine und Iceberg-Wartung#

Unter Regeltermine stehen Berichte, Schwellwert-Alerts und Wartung zur Verfügung. Sie wählen den Zeitplan, sehen die Laufhistorie und können einen Termin manuell ausführen. Hintergrundläufe verwenden die gespeicherte Offline-Berechtigung ihres Eigentümers und dessen Rechte.

Die Art „Wartung“ verdichtet kleine Dateien, verwirft alte Snapshots, entfernt verwaiste Dateien und erneuert zuletzt die Tabellenstatistiken (ANALYZE) — ohne sie plant Trinos kostenbasierter Optimizer Join-Reihenfolge und Verteilstrategie im Blindflug. Die Aufbewahrung ist von 7 bis 365 Tagen wählbar, Vorgabe 7 Tage. Ohne eingerichteten Wartungstermin läuft keine automatische Bereinigung. Ein Fehler bei einer Tabelle wird im Ergebnis festgehalten; die übrigen Tabellen werden weiter bearbeitet.

Was die tägliche Sicherung enthält#

Der eigene Backup-Dienst sichert beim Start und danach täglich. Standardmäßig werden Sicherungen 14 Tage aufbewahrt; die letzte Sicherung wird nie durch die Aufbewahrungsbereinigung entfernt. Unter Betrieb → Überwachung sehen Sie Alter und Größe der letzten Sicherung sowie eine Warnung, wenn sie fehlt oder überfällig ist.

Wiederherstellung vorbereiten#

Das Verfahren steht im Produkt-Repository unter docs/betrieb/WIEDERHERSTELLUNG.md. Für eine Wiederherstellung müssen Datenbank-Sicherung, Konfiguration und die Daten des Objektspeichers zusammenpassen. Die Datenbank-Sicherung allein stellt die Nutzdaten des Sees nicht wieder her. Eine automatische Site-Replikation des Objektspeichers ist noch nicht Teil des gelieferten Betriebsumfangs. Proben Sie den Ablauf auf einer getrennten Testinstallation.

Leistungsklassen für Abfragen#

Im Compose-Stapel ordnen Rollen Abfragen einer Trino-Ressourcengruppe zu. Die Grenzen gelten gemeinsam für die Abfragen einer Klasse, nicht als eigenes Kontingent je Nutzer. Die Speicherwerte sind weiche Grenzen für die Zulassung weiterer Abfragen, keine reservierten Speicheranteile.

Weisen Sie die gewünschte Rolle unter Verwaltung → Nutzer & Rollen zu. Bei mehreren Leistungsrollen greift L vor M vor S; Plattform-Administratoren verwenden die eigene Klasse. Die Auswahl wirkt über die Rollen-Gruppendatei. Zusätzliche Maschinen, Auto-Suspend und automatisch wachsende Cluster werden dadurch nicht eingerichtet.

Verbrauch und Grenzen#

Die Überwachung zeigt Rechenzeit und gelesene Daten je Nutzer und Zweck, dazu Tageskontingente. KI-Verbrauch, Modellpreise und Token-Tagesbudgets stehen im Abschnitt „KI-Kosten“. Eine detaillierte Anleitung zu Anbietern, Preis-Synchronisierung und Budgetgrenzen finden Sie unter KI-Anbindung einrichten.

Öffentlicher Zugang über HTTPS#

Seit v0.40.0 stellt eine einzige Variable (PUBLIC_BASE_URL) die gesamte Installation auf einen öffentlichen Hostnamen um: Token-Aussteller, die Prüfung durch Agent und Abfrage-Engine, die in der Konsole eingebackene Anmelde-Adresse und die erlaubten Anmelde-Rückleitungen laufen dann im Gleichschritt. Dazu gehört ein TLS-Overlay für das Gateway mit HSTS und Frame-Schutz; der lokale Zugang über 127.0.0.1 bleibt daneben bestehen, damit SSH-Tunnel und Betriebsskripte weiterlaufen. Anleitung im Produkt-Repository unter docs/betrieb/OEFFENTLICHER-ZUGANG.md.

Mit weiteren Rechenknoten skalieren#

Die Abfrage-Engine lässt sich seit v0.42.0 um Worker erweitern — lokal zum Ausprobieren über ein Compose-Profil, produktiv auf zusätzlichen Maschinen über eine eigene Compose-Datei. Jeder Worker bringt eigene Kerne und eigenen Speicher mit und meldet sich binnen Sekunden am Koordinator an; die Leistungsklassen gelten unverändert weiter. Details unter docs/betrieb/WORKER.md. Seit v0.195.0 zeigt die Konsole die verbundenen Rechenknoten unter Administration → Betrieb → Systemzustand und meldet einen fehlenden Knoten nach fünf Minuten. Was ein Worker auf einer zweiten Maschine bringt, ist unter Dimensionierung gemessen.

Was die Konsole für den Betrieb zeigt#

Betrieb → Analytik bündelt Abfragen samt Fehlern, verarbeitete Daten, Rechenzeit, KI-Kosten in Euro sowie Sicherungs- und Lizenzstand, umschaltbar für 7, 14 oder 30 Tage. Betrieb → Auslastung zeigt den Zustand für Menschen: Gesamtstatus und vier Ampeln (laufende Abfragen, Warteschlange, Fehlerquote, p90-Antwortzeit der letzten 15 Minuten), kalibriert an einem Überlasttest. Das Analytik-Board weist zusätzlich Tabellen ohne physische Anordnung aus und wendet die Empfehlung auf Wunsch für alle Tabellen nacheinander an.