Active-Active. Kein Master, kein Failover.

Wie funktioniert das?

Jeder Knoten im Cluster ist gleichberechtigt. Konfigurations-Änderungen und Detection-State werden im Hintergrund verschlüsselt zwischen allen Knoten synchronisiert — der Operator macht eine Änderung im Web-UI, alle Knoten ziehen automatisch nach. Eingehende Mails verteilt der MX-Eintrag im DNS auf die Knoten, fällt einer aus, übernehmen die anderen ohne Eingriff.

Warum nicht Master/Replica?

Klassische Master/Replica-Architekturen haben drei strukturelle Probleme:

• Promote-Komplexität. Wenn der Master ausfällt, muss aktiv ein Replica zum Master gemacht werden — und alle Konfigurations-Punkte nachgezogen. Das funktioniert nicht immer reibungslos.
• Split-Brain-Risiko. Bei Netzwerk-Partition glauben beide Master, sie wären der einzige aktive Knoten — beide nehmen Mails an, danach ist Reparatur Handarbeit.
• Quorum-Aufwand. Die Vermeidung von Split-Brain braucht typischerweise eine ungerade Knoten-Zahl — der zusätzliche Knoten kostet, ohne zusätzlichen Durchsatz zu bringen.

MailGuard löst das durch radikale Symmetrie: jeder Knoten ist Master, es gibt keinen „korrekten" Knoten den man verlieren könnte.

Was bedeutet das im Betrieb?

• Hardware-Defekt → keine Aktion nötig. Die anderen Knoten bedienen weiter, das Routing überspringt den ausgefallenen automatisch.
• Knoten hinzufügen → ein Befehl. Der neue Knoten zieht beim ersten Start den Konfig-Stand vom bestehenden Cluster und ist innerhalb einer Minute produktiv.
• Wartungs-Reboot → kein Failover-Plan. Knoten aus dem Routing nehmen, rebooten, wieder reinnehmen. Die anderen Knoten verarbeiten in der Zwischenzeit weiter.
• Cluster-weite Quarantäne-Sicht. Das Web-UI zeigt alle Quarantäne-Mails zentral — der Admin sieht die gesamte Quarantäne an einem Ort, egal auf welchem Knoten sie physisch liegen.

   ┌──────────────┐  verschlüsselte ┌──────────────┐
   │  Node 1      │ ◀────Sync─────▶ │  Node 2      │
   │  Detection-  │                 │  Detection-  │
   │  Stack       │ ◀──────────────▶│  Stack       │
   │  + Sandbox   │                 │  + Sandbox   │
   └──────┬───────┘                 └──────┬───────┘
          │                                │
          │     ┌──────────────┐           │
          ◀──── │  Node 3      │ ◀─────────┤
          │     │  ...         │           │
          │     └──────────────┘           │
          │                                │
          └──────── MX Round-Robin ────────┘
                       │
              MX 10 mx1.example.com
              MX 10 mx2.example.com
              MX 10 mx3.example.com
                       │
                       ▼
              Bestehender Mailserver

Limit?

Keines. Praktisch betreiben Kunden Cluster mit 2 bis 10 Knoten. Die Replikations-Last skaliert linear mit der Knotenzahl, bei einer typischen Konfigurations-Änderungs-Frequenz von wenigen Updates pro Stunde ist das vernachlässigbar. Bei sehr großen Setups segmentieren wir geographisch — sprechen Sie uns auf Enterprise-Ebene an.

Cluster ausprobieren?

Zwei VMs, zwei One-Liner, Cluster steht. Kein Quorum, kein Promote-Skript, keine Magie.

Test starten