Cluster-Verwaltung¶

Die zentrale Übersicht über alle Cluster-Nodes. Hier sehen Sie pro Node Health-Status, Konfigurations-Konsistenz, Lizenz-Validität, Outbox-Backlog und können neue Nodes joinen oder bestehende entfernen.

Node-Liste¶

Pro Cluster-Node zeigt die Tabelle:

Feld	Bedeutung
Health	`online` (grün) / `stale` (gelb, letzter Heartbeat > 60 s) / `offline` (rot, > 5 min)
Node-ID	Eindeutige ID, generiert beim ersten Start
FQDN	Hostname des Nodes
API-URL	URL über die der Node erreichbar ist (intern für mTLS-Sync)
Last-Seen	Zeitstempel der letzten erfolgreichen Verbindung
Config-Hash	Hash der aktuellen Konfiguration. Identisch zwischen allen Nodes = synchron.
Config-Hash-Age	wie lange schon dieser Hash gilt — frisch geänderte Configs zeigen niedriges Alter
Outbox-Backlog	Anzahl an Replikations-Events die für diesen Node ausstehen (sollte 0 sein)
License	Lizenz-Status des Nodes (valid / type / expires_at / grace_period)

Ein lokaler Node ist mit einem Stern markiert.

Aktionen¶

Neuen Node einladen (Plus-Button)¶

Öffnet Modal mit Token-Generierung:

Operator klickt „Token erzeugen"
UI ruft nmg-ctl cluster-join-token auf, zeigt den 64-Hex-Token + Ablauf-Zeit
Token kopieren, auf dem neuen Server nmg-ctl cluster-join --from <seed-url> --token <hex> ausführen
Innerhalb von ~30 Sekunden erscheint der neue Node in der Liste

Token sind 24 Stunden gültig und einmal verwendbar.

Node entfernen (Mülltonne)¶

Der ausgewählte Node wird aus dem ha_nodes-Register entfernt. Die anderen Nodes hören auf, ihm Replikations-Events zu schicken. Nach dem Remove sollte der entfernte Server entweder neu gejoined oder physisch abgeschaltet werden — sonst läuft er als Zombie weiter mit veraltetem State.

Sync erzwingen (Refresh-Icon)¶

Triggert manuell einen Konfigurations-Snapshot vom lokalen Node zum ausgewählten Peer. Wird gebraucht wenn Drift festgestellt wurde (Config-Hashes weichen ab).

Peer-Cert neu ausstellen (Schild-Icon)¶

Erzeugt ein neues mTLS-Zertifikat für den ausgewählten Peer. Sinnvoll wenn die Cluster-CA rotiert wurde oder der Peer-Cert nahezu abgelaufen ist.

Drift-Erkennung¶

Wenn die Config-Hashes zwischen Nodes abweichen, zeigt die UI eine Drift-Warnung mit einem „Repair"-Button. Der Repair triggert eine vollständige Konfigurations-Synchronisation vom Node mit dem neuesten Stand zu allen anderen.

Drift kommt fast nie vor (Replikation ist async aber zuverlässig). Häufigste Ursachen wenn doch:

Netzwerk-Partition während eines Konfig-Schreibvorgangs
Manuelle Datenbank-Manipulation auf einem Node
Bug in einem alten Release der inzwischen behoben ist

Outbox-Backlog¶

Wenn ein Node offline geht und während dessen Konfigurations-Änderungen anfallen, sammelt jeder andere Node die nicht-bestätigten Events in seiner lokalen Outbox. Sobald der Offline-Node zurückkommt, werden die Events nachgespielt. Wenn der Backlog-Zähler dauerhaft hoch ist (>1000), prüfen Sie ob der Offline-Node wirklich erreichbar ist.

Single-Node-Cluster¶

Bei Single-Node-Setup zeigt die Liste nur einen Eintrag (lokal). Aktionen wie „Sync" oder „Token erzeugen" sind dort funktionslos aber nicht versteckt — sobald Sie den zweiten Node joinen, werden sie relevant.