Einleitung
Hochverfügbarkeit ist ein zentrales Thema beim Betrieb von SIEM- und Security-Monitoring-Plattformen. In Wazuh-Umgebungen wird dieses Ziel häufig über den Einsatz eines Clusters aus Master- und Worker-Nodes verfolgt. Dabei taucht regelmäßig die Frage auf, ob sich die Master-Rolle nachträglich oder im Fehlerfall dynamisch auf einen Worker verschieben lässt. Die kurze Antwort lautet: nein. Die längere Antwort – und vor allem die korrekten betrieblichen Konsequenzen – sind Thema dieses Artikels.
Ausgangslage / Problemstellung
In einer bestehenden Wazuh-Cluster-Installation stellte sich die Frage, ob sich der Master-Knoten nachträglich durch eine einfache Änderung der ossec.conf auf einen anderen Node verschieben lässt. Hintergrund war ein potenzielles Ausfallszenario: Was passiert, wenn der Master nicht mehr erreichbar ist, und wie kann der Betrieb möglichst schnell wiederhergestellt werden? Insbesondere wurde geklärt, ob Worker-Nodes automatisch oder manuell zum Master „befördert“ werden können.
Technische Analyse
Die Rolle eines Wazuh-Cluster-Nodes (Master oder Worker) wird bei der initialen Cluster-Erstellung fest definiert. Diese Entscheidung ist tief in der Cluster-Architektur verankert und geht weit über eine einzelne Konfigurationsoption hinaus.
Der Master übernimmt zentrale Aufgaben wie:
- Agent-Registrierung und -Deregistrierung
- Verteilung und Synchronisation von Regeln, Decodern und Shared-Konfigurationen
- Zentrale Koordination der Cluster-Metadaten
Worker-Nodes hingegen sind für die Event-Verarbeitung zuständig und können Agent-Events weiterhin entgegennehmen und analysieren, solange sie laufen. Was sie nicht können: Master-spezifische Aufgaben übernehmen.
Ein automatisches Failover oder eine dynamische Rollenumschaltung ist in der aktuellen Wazuh-Architektur nicht vorgesehen. Ein Wechsel der Rolle durch einfache Anpassung der ossec.conf ist weder unterstützt noch technisch ausreichend.
Ein manueller Umbau eines bestehenden Workers zum Master ist theoretisch möglich, entspricht jedoch faktisch einer Neuinstallation bzw. vollständigen Re-Konfiguration des Clusters. Dieser Vorgang ist nicht „live“-fähig, führt zwangsläufig zu Downtime und wird von Wazuh nicht als regulärer Betriebsablauf unterstützt.
Lösung / Best Practices
Da ein Role-Switch nicht möglich ist, ergeben sich klare empfohlene Vorgehensweisen für den Betrieb:
1. Master-Ausfall nicht durch Promotion lösen
Fällt der Master aus, sollten Worker nicht als Ersatz betrachtet werden. Stattdessen ist der Fokus auf Wiederherstellung oder Ersatz des Masters zu legen.
2. Master gezielt neu aufsetzen
Bei einem irreparablen Ausfall ist der empfohlene Weg:
- Einen neuen Master-Node bereitstellen (idealerweise mit identischem Hostnamen und IP)
- Zentrale Wazuh-Daten und Konfigurationen aus Backups wiederherstellen
- Den Cluster anschließend neu verbinden
Dieser Ansatz ist stabiler und konsistenter als der Versuch, bestehende Worker umzuwidmen.
3. Backups als Pflichtbestandteil der Architektur
Regelmäßige Backups der zentralen Wazuh-Komponenten (Manager-Daten, Konfigurationen, Schlüsseldateien) sind essenziell. Nur so lässt sich ein Master schnell und sauber wiederherstellen.
4. Komponenten sinnvoll trennen
In produktiven Umgebungen sollte der Wazuh Manager (Master), der Indexer und das Dashboard getrennt betrieben werden. Das reduziert den Impact eines einzelnen Knotenausfalls erheblich.
Lessons Learned / Best Practices
- Die Master-Rolle ist statisch und wird beim Cluster-Setup festgelegt.
- Worker-Nodes können den Master weder automatisch noch manuell „on the fly“ ersetzen.
- Ein Master-Ausfall bedeutet Einschränkungen bei Verwaltung und Konfigurationsverteilung, nicht zwingend beim Event-Processing.
- Backup- und Recovery-Konzepte sind wichtiger als vermeintliche Failover-Mechanismen.
- Planung der Cluster-Architektur entscheidet maßgeblich über die Ausfalltoleranz.
Fazit
Wazuh-Cluster sind bewusst einfach und deterministisch aufgebaut: ein Master, mehrere Worker, klar getrennte Verantwortlichkeiten. Diese Klarheit verhindert komplexe Split-Brain- oder Failover-Szenarien, bedeutet aber auch, dass ein Master-Ausfall nicht durch schnelle Rollenwechsel abgefangen werden kann. Wer Wazuh hochverfügbar betreiben möchte, muss daher auf saubere Backups, reproduzierbare Deployments und eine durchdachte Architektur setzen – nicht auf dynamische Master-Promotion.
Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program
Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program
https://wazuh.slack.com/archives/C0A933R8E/p1767796407544079