Wazuh Migration von All-in-One zu verteilter Architektur: Manager-Cluster, Agent-Anbindung und saubere Datenübernahme
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
Quelle
Dieser Artikel stammt aus dem Wazuh-Blog von m.a.x. it (veröffentlicht am 12. März 2026).
Unterstützung von m.a.x. it
Bei Einführung, Betrieb und Feintuning von Wazuh (SIEM) unterstützt Sie m.a.x. it mit SIEM-Services auf Open-Source-Basis.
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
