Cluster-Verwaltung¶
nmg unterstützt Active-Active-Cluster ohne Primary/Replica-Konzept. Jede Node ist gleichwertig und verarbeitet Mail selbstständig.
Cluster-Topologie¶
- Kein Failover, kein Quorum, kein Promote
- Konfiguration wird per App-Level Fan-Out repliziert
- rspamd-Daten (Bayes, Reputation) über KeyDB Active-Active
- Mail-Queue und Quarantäne: lokal pro Node, cluster-weit lesbar
Cluster-Status¶
Die Cluster-Übersicht zeigt für jede Node:
| Spalte | Beschreibung |
|---|---|
| Node-ID | Eindeutige UUID der Node |
| FQDN | Vollqualifizierter Hostname |
| Version | Installierte nmg-Version — abweichende Versionen werden rot markiert |
| Konfigurations-Hash | SHA256 des Konfigurations-Stands — Abweichungen vom lokalen Hash = Drift |
| Hash-Alter | Sekunden seit dem letzten Konfigurations-Update |
| Status | online / offline / version mismatch |
| Neustart nötig | Ob ein Paket-Update einen Neustart erfordert |
| Letzte Meldung | Zeitstempel des letzten Health-Check-Signals |
Konfigurations-Drift erkennen¶
Weicht der Konfigurations-Hash einer Node vom Hash der lokalen Node ab, ist ein Drift aufgetreten — die Nodes sind nicht mehr synchron. Ursachen:
- Node war offline während einer Konfigurationsänderung
- Netzwerkfehler unterbrach die Replikation
- Manuelle Konfigurationsänderung direkt auf einer Node
Drifts werden in der Tabelle mit einem roten Drift-Tag markiert.
Drift reparieren¶
Über die Aktionen in der Node-Zeile:
- Reparatur (Push) — Lokale Konfiguration wird an die Ziel-Node gepusht (überschreibt dortigen Stand)
- Von Peer übernehmen (Pull) — Konfiguration der Ziel-Node wird auf die lokale Node übertragen
Push vs. Pull
Push überschreibt die Remote-Node. Pull überschreibt die lokale Node. Vor einer Pull-Aktion sicherstellen, dass die Remote-Node den korrekten Stand hat.
Cluster-CA (Certificate Authority)¶
nmg betreibt eine eigene interne CA für mTLS zwischen den Cluster-Nodes. Die CA-Informationen werden im Cluster-Status angezeigt:
| Feld | Beschreibung |
|---|---|
| CA-Pfad | Pfad zum CA-Zertifikat auf dieser Node |
| CA-Fingerprint | SHA256-Fingerprint des CA-Zertifikats (sollte auf allen Nodes identisch sein) |
| CA-Ablauf | Gültigkeitsdatum des CA-Zertifikats |
Node hinzufügen¶
Auf der neuen Node¶
curl -s https://get.netcell-mailguard.de | sudo bash
# Setup-Wizard: Schritt "Cluster" → "Dieser Node tritt einem bestehenden Cluster bei"
# Cluster-IP: IP der ersten Node
# Join-Token: Einmaliger Token aus dem Management-UI
Im Management-UI¶
- Cluster → Node hinzufügen
- Join-Token generieren — kopieren und auf der neuen Node im Setup-Wizard einfügen
- Nach erfolgreichem Join erscheint die neue Node in der Cluster-Übersicht
Was beim Join passiert: - mTLS-Zertifikate werden automatisch von der Cluster-CA ausgestellt - Konfiguration (Domains, Mail-Config, Filter) wird repliziert - KeyDB Replication Link wird eingerichtet
Node entfernen¶
- Cluster → Node auswählen → Entfernen
- Bestätigung eingeben
- nmg entzieht der Node ihr mTLS-Zertifikat (Revoke)
- Node wird aus der Peer-Liste aller anderen Nodes entfernt
Ghost-Node-Erkennung
Wenn eine Node mit gleicher Machine-ID neu installiert wird (z. B. nach einem OS-Rebuild), wird sie als "Ghost Node" erkannt und muss explizit aus dem Cluster entfernt werden.
Konfigurationsreplikation¶
Alle Konfigurationsänderungen werden sofort an alle erreichbaren Peers repliziert. Offline-Nodes werden bei nächster Gelegenheit synchronisiert.
Replizierte Objekte: Domains, Mail-Config, Sender-Filter, DKIM-Schlüssel, RBL-Einstellungen, Composites, Phishing-Feeds/Keywords/TLDs/URL-Shortener, Firewall-Regeln, Benutzer, API-Schlüssel
Nicht repliziert (lokal pro Node): Lizenzschlüssel, Mail-Queue, Quarantäne-Inhalte, Mail-Logs