Cluster aufbauen¶
NetCell MailGuard ist ab Tag 1 Cluster-fähig. Active-Active-Architektur — jeder Node ist gleichberechtigter Peer, kein Master, kein Failover. Diese Anleitung führt Sie durch ein 3-Node-HA-Setup.
Lizenz-Hinweis
Cluster-Setup setzt eine Standard-Lizenz voraus (29 €/Server/Monat, jeder Node = 1 Lizenz). Free-Tier ist auf einen einzelnen Server begrenzt.
Architektur-Überblick¶
┌──────────────┐ verschlüsselte ┌──────────────┐
│ Node 1 │ ◀────Sync─────▶ │ Node 2 │
│ Detection- │ │ Detection- │
│ Stack │ ◀──────────────▶│ Stack │
│ + Sandbox │ │ + Sandbox │
└──────┬───────┘ └──────┬───────┘
│ │
│ ┌──────────────┐ │
◀──── │ Node 3 │ ◀─────────┤
│ │ ... │ │
│ └──────────────┘ │
│ │
└──────── MX Round-Robin ────────┘
Eingehende Mails kommen über MX-DNS-Round-Robin auf einem der Nodes an. Jeder Node verarbeitet die Mail komplett lokal — Detection-Stack, Sandbox, Quarantäne.
Schritt 1 — Seed-Node initialisieren¶
Auf dem ersten Node (nach abgeschlossenem Setup-Wizard, siehe Installation):
Was passiert:
- Es wird eine Cluster-CA erstellt (
/etc/nmg/secret/cluster-ca.crt) - Der Seed-Node erhält ein eigenes mTLS-Peer-Zertifikat
- Der Cluster-State wird in PostgreSQL initialisiert
Schritt 2 — Join-Token erzeugen¶
Auf dem Seed-Node:
Output:
Der Join-Token ist 24 Stunden gültig und einmal verwendbar.
Schritt 3 — Zweiten Node hinzufügen¶
Auf dem zweiten frischen Server:
-
Installer ausführen wie bei Node 1:
-
Cluster-Join statt Setup-Wizard:
Der neue Node:
- Authentifiziert sich beim Seed mit dem Join-Token
- Lädt einen Konfigurations-Snapshot
- Wird beim Seed im
ha_nodes-Register eingetragen - Ist sofort produktiv
Das Web-UI auf dem Seed zeigt den neuen Node unter System → Cluster als „connected".
Schritt 4 — Dritten Node hinzufügen¶
Identisch zu Schritt 3 — neuen Token erzeugen, neuen Server installieren, joinen.
Schritt 5 — MX-Records auf alle Nodes setzen¶
Damit eingehende Mails über alle Nodes verteilt werden:
example.com. IN MX 10 mailguard-1.example.com.
example.com. IN MX 10 mailguard-2.example.com.
example.com. IN MX 10 mailguard-3.example.com.
mailguard-1.example.com. IN A 198.51.100.41
mailguard-2.example.com. IN A 198.51.100.42
mailguard-3.example.com. IN A 198.51.100.43
Sendende Mailserver wählen den MX-Eintrag mit gleicher Priorität randomisiert — automatisches Round-Robin. Fällt ein Node aus, wechselt der Sender beim Retry auf einen anderen MX.
Operations im Cluster¶
- Hardware-Defekt an einem Node → keine Aktion nötig. Die anderen Nodes verarbeiten weiter, MX-Round-Robin überspringt den ausgefallenen Node automatisch nach SMTP-Timeout.
- Wartungs-Reboot → Nehmen Sie den Node aus dem MX-Round-Robin (DNS-Eintrag temporär entfernen oder Priorität senken), rebooten, wieder reinhängen.
- Knoten endgültig entfernen →
sudo nmg-ctl cluster-remove --node-id <id>auf einem anderen Node. - Cluster-State prüfen →
sudo nmg-ctl cluster-statuszeigt alle Nodes mit letzter Sync-Zeit.
Best Practices¶
- Geographisch verteilen: bei kritischen Setups verteilen Sie Nodes auf mehrere Rechenzentren oder mindestens mehrere Verfügbarkeitszonen.
- Monitoring: Prometheus-Metrik-Endpoint pro Node (
/metricsauf Port 9090) — Load-Balancing-Indikatoren wie Mail-Volumen, Detection-Score-Verteilung, Quarantäne-Anzahl. - Backup: PostgreSQL-Backup auf jedem Node identisch — bei Cluster-State-Korruption hilft Wiederherstellung von einem einzelnen Node, weil die anderen identisch sind.
Was als Nächstes?¶
- Erste Domain anlegen — eine geschützte Domain konfigurieren
- Cluster-Verwaltung — laufender Cluster-Betrieb