Einleitung
Beim Umzug einer Wazuh All-in-One-Installation auf neue Server ist die häufigste und sinnvollste Designentscheidung: Rollen trennen (Indexer/Dashboard getrennt vom Manager) und – sobald Last oder Verfügbarkeit relevant werden – den Wazuh-Manager als Cluster betreiben. Das reduziert Ressourcenkonkurrenz, vereinfacht Skalierung und schafft eine Grundlage für stabile Agent-Konnektivität. Dieser Beitrag ordnet die typischen Fragen aus der Praxis ein: Was bringt ein zweiter Manager? Ist das automatisch ein Cluster? Welche Rollen haben Master/Worker? Was ändert sich bei den Agents (IP vs FQDN/VIP)? Und wie übernimmt man historische Daten korrekt, ohne „Index-Verzeichnisse zu kopieren“?
Ausgangslage / Problemstellung
Geplant ist eine Migration von einer All-in-One-Instanz auf ein neues Setup:
- VM A: Wazuh Indexer + Wazuh Dashboard
- VM B: Wazuh Manager (Master)
- VM C: Wazuh Manager (Worker)
Ziele:
- Last besser verteilen, insbesondere Agent-Verbindungen und Event-Ingestion
- später skalieren können (z. B. dritter Manager-Node)
- Agent-Konfiguration aktuell per IP, Frage nach VIP/Load-Balancer
- historische Indexer-Daten übernehmen (bisheriges Verzeichnis
/var/lib/wazuh-indexer/nodes/0/indices)
Technische Analyse
1) Zwei Manager-VMs = Cluster (wenn als Cluster konfiguriert)
Ein Wazuh-Server-Cluster ist ein Verbund aus mehreren Wazuh-Server-Nodes in einer verteilten Umgebung und dient explizit horizontaler Skalierung und Performance. Wazuh Dokumentation
Sobald du mehr als einen Wazuh-Server-Node betreibst und die Cluster-Funktionalität entsprechend konfigurierst, arbeitest du im Cluster-Modell.
2) Rolle der Nodes: Master und Worker
Wazuh unterscheidet im Server-Cluster zwei Node-Typen: master und worker. Diese Rollen definieren Aufgaben und Hierarchie für Synchronisationen. Wazuh Dokumentation+1
Wichtig für die Praxis: „Master“ bedeutet primär Cluster-Koordination und Synchronisation – nicht „hier gehen alle Agent-Daten durch“. Für Lastverteilung brauchst du eine Agent-Anbindung, die Worker aktiv nutzt (siehe Agent-Connections).
3) Agent-Konnektivität und Lastverteilung: Failover vs Load Balancer
Wazuh beschreibt zwei Wege, wie Agents an ein Cluster angebunden werden können:
- Failover-Modus: Agents kennen mehrere Ziele (wenn ein Node nicht erreichbar ist, wird umgeschaltet)
- Mit Load Balancer: empfohlen, damit Agents verteilt registrieren und berichten, und der Load Balancer zuweist, zu welchem Worker die Agenten-Verbindung geht Wazuh Dokumentation
Für „schwere Loglast über zwei Manager verteilen“ ist das entscheidend: Ohne Load Balancer/VIP landen Agenten typischerweise nicht automatisch gleichmäßig auf beiden Nodes.
4) „Ist das echte HA?“ – was ein Load Balancer wirklich leistet
Ein Load Balancer verteilt Agent-Traffic auf mehrere Worker-Nodes und kann bei Node-Ausfall Verbindungen auf verfügbare Nodes lenken. Das ist in der Wazuh-Cluster-Doku als empfohlener Ansatz beschrieben; Wazuh nennt als Beispiele u. a. NGINX und HAProxy. Wazuh Dokumentation+1
Damit erreichst du operative HA für Agent-Konnektivität (und gleichzeitig Load Distribution), vorausgesetzt der Load Balancer selbst ist hochverfügbar ausgelegt (z. B. redundant betrieben).
5) Historische Daten: kein Kopieren von nodes/0/indices, sondern Index-Migration per Snapshot
Das direkte Kopieren des Index-Verzeichnisses zwischen Maschinen ist in solchen Systemen typischerweise riskant (Versionen, Cluster-Metadaten, Shards, Locks). Wazuh dokumentiert für die Übernahme historischer Daten ausdrücklich die Migration von Wazuh-Indices per Snapshot/Restore. Wazuh Dokumentation+1
Zusätzlich beschreibt die Doku die relevanten Index-Patterns (z. B. wazuh-alerts-* für Alerts), was bei Planung/Retention und Migration hilft. Wazuh Dokumentation
Lösung / Best Practices
1) Architekturentscheidung: Rollen sauber trennen
Für produktive und skalierbare Umgebungen ist die Trennung der Rollen (Indexer/Dashboard separat vom Manager) der stabile Standardansatz. Der Manager-Cluster skaliert unabhängig vom Indexer-Layer, und Ressourcen konkurrieren weniger direkt (CPU/RAM vs I/O).
2) Manager-Cluster korrekt aufsetzen: 1 Master + 1..n Worker
Starte mit:
- 1 Master
- mindestens 1 Worker
Das ist der in der Dokumentation beschriebene Grundaufbau, inkl. Node-Typen und Konfigurationsvorgehen. Wazuh Dokumentation+1
Skalierung später: Einen weiteren Worker (z. B. dritten Node) kannst du später ergänzen – das Cluster-Modell ist explizit für horizontale Skalierung gedacht. Wazuh Dokumentation
3) Agent-Konfiguration: nicht nur Master-IP, sondern Cluster-fähige Anbindung
Wenn du Agents nur auf die Master-IP zeigst, erreichst du nicht automatisch eine sinnvolle Lastverteilung. Für verteilte Agent-Verbindungen empfiehlt Wazuh den Betrieb mit Load Balancer vor dem Cluster. Wazuh Dokumentation
Praktische Konsequenz:
- Agents zeigen auf VIP/Load-Balancer-Adresse
- Der Load Balancer verteilt Agent-Sessions auf die verfügbaren Cluster-Nodes (typischerweise Worker) Wazuh Dokumentation+1
Damit beantwortet sich auch die HA-Frage operativ:
- Fällt ein Node aus, können neue/neuaufbauende Agent-Verbindungen auf einen anderen Node gehen (abhängig von Load-Balancer-Healthchecks und deinem Balancing-Algorithmus).
4) IP vs FQDN: Minimierung von Agent-Änderungen
Wenn heute IP-Adressen im Agent-Manager-Eintrag verwendet werden, ist eine Migration auf VIP (IP) meist der geringste Eingriff. Ein späterer Wechsel auf FQDN ist möglich, aber betrieblich musst du sicherstellen, dass DNS/VIP-Failover sauber gemanagt wird. Entscheidend ist: Agents sollten auf eine stabile Frontdoor (VIP/LB) zeigen, nicht auf einzelne Nodes.
5) Historische Daten übernehmen: Snapshot/Restore nach Wazuh-Doku
Statt /var/lib/wazuh-indexer/nodes/0/indices zu kopieren, folge der dokumentierten Index-Migration:
- Snapshot Repository einrichten
- Snapshots erzeugen
- In neuer Umgebung restore (inkl. Optionen wie Prefix/Umbenennen, um Konflikte zu vermeiden) Wazuh Dokumentation
Das ist der offiziell vorgesehene Weg, um historische Alerts/States/Indices sauber in einen neuen Indexer-Cluster zu übernehmen.
6) Müssen beide Manager-VMs identisch dimensioniert sein?
Wazuh schreibt nicht vor, dass Master und Worker identische Ressourcen haben müssen. Praktisch hängt die Dimensionierung von:
- Anzahl Agents / EPS
- Regelwerk/Decoder-Last (analysisd)
- Größe/Anzahl integrierter Logquellen
Wenn du Last wirklich verteilen willst, ist es jedoch häufig sinnvoll, Worker nicht zu klein zu dimensionieren, damit Balancing auch effektiv hilft. Das Cluster-Konzept selbst zielt auf horizontale Skalierung und Performance. Wazuh Dokumentation+1
Lessons Learned / Best Practices
- Cluster = mehrere Server-Nodes, mit klaren Rollen (Master/Worker) und Synchronisationshierarchie. Wazuh Dokumentation+1
- Für Agent-Lastverteilung ist ein Load Balancer vor dem Cluster der empfohlene Weg. Wazuh Dokumentation+1
- „HA“ ist nicht nur Cluster: Auch der Load Balancer muss hochverfügbar geplant werden, sonst entsteht ein Single Point of Failure.
- Historische Daten nicht per Dateikopie migrieren, sondern per Snapshot/Restore gemäß Indexer-Migration. Wazuh Dokumentation+1
- Plane Index-Patterns und Datenklassen (z. B. Alerts) bewusst – hilft bei Retention, Migration und Kapazitätsplanung. Wazuh Dokumentation
Fazit
Zwei Wazuh-Manager-VMs lohnen sich dann, wenn du sie als Wazuh-Server-Cluster (Master + Worker) betreibst und die Agents nicht „nur auf den Master“, sondern auf eine Load-Balancer/VIP-Frontdoor konfigurierst. So erreichst du echte Lastverteilung und robuste Agent-Konnektivität. Für historische Daten ist das Kopieren des Index-Verzeichnisses der falsche Ansatz – die offiziell dokumentierte Methode ist die Migration per Snapshot/Restore. Mit diesem Design kannst du später problemlos um weitere Worker erweitern und die Plattform schrittweise skalieren.
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/p1767621494010259