Wazuh High Availability ohne Load-Balancing: Was wirklich möglich ist bei Indexer, Manager und Dashboard

von

Einleitung

High Availability (HA) in SIEM- und XDR-Umgebungen wird oft mit “mehr Knoten” gleichgesetzt. In der Praxis unterscheiden sich jedoch Datenebene, Kontroll-/Konfigurationsebene und UI-Schicht deutlich darin, wie (und ob) sie sich hochverfügbar betreiben lassen. In Wazuh ist das besonders relevant, weil der Wazuh Manager (Server) neben Event-Ingestion auch zentrale Steuerfunktionen übernimmt, während der Wazuh Indexer (OpenSearch-basierend) die eigentliche Datenpersistenz und -replikation liefert. Das Wazuh Dashboard wiederum ist eine UI-Schicht mit eigenem Betriebsmodell.

Dieser Artikel ordnet ein, welche HA- und DR-Muster in einem Wazuh-Setup (v4.10.1) realistisch sind – mit Fokus auf Failover, Datenreplikation und dem Umstieg von einem bestehenden Single-Node-Deployment.

Ausgangslage / Problemstellung

Umgebung: 3 getrennte Nodes: 1× Indexer, 1× Wazuh Server/Manager, 1× Dashboard. Bereits länger in Betrieb, produktive Daten vorhanden.
Anforderung: HA/DR je Komponente mit “Backup-Node” und zeitnaher Replikation von Daten und Konfiguration – ausdrücklich kein Load-Balancing.
Kernfragen:

  • Was passiert, wenn der Master (Manager oder Indexer) ausfällt?
  • Können Worker/Secondary-Knoten automatisch übernehmen?
  • Wie repliziert man Daten und Konfiguration nachträglich, wenn man von Single Node auf Cluster erweitert?
  • Gibt es HA für das Dashboard?

Technische Analyse

1) Wazuh Manager Cluster: HA ja – aber Failover ist nicht “magisch”

Der Wazuh Manager-Cluster arbeitet typischerweise mit Master und Worker:

  • Worker nehmen Agent-Events weiterhin an, dekodieren, korrelieren, führen Regeln aus und schreiben Alerts.
  • Master übernimmt cluster-zentrierte Aufgaben, z. B. Synchronisation “shared” (Regeln/Decoders/Listen/SCA/Agent-Gruppen-Assets je nach Setup), bestimmte API-Operationen, Agent-Enrollment/Registrierung (je nach Enrollment-Design), sowie die Koordination der Cluster-Synchronisation.

Wichtig: Fällt der Master aus, laufen Worker weiter – aber bestimmte zentrale Funktionen sind eingeschränkt oder nicht verfügbar, bis ein Master wieder vorhanden ist.
DR-Szenario “Master irreparabel verloren”: Ein Worker wird nicht automatisch Master. Eine Übernahme ist möglich, aber nur, wenn sie explizit per Konfiguration/Prozess vorgesehen ist (Promotion/Neudefinition der Cluster-Rolle plus Sicherstellung, dass der neue Master die maßgeblichen Konfigurationsstände besitzt).

Konsequenz: Wazuh Manager-HA ist “weiterverarbeiten trotz Masterausfall” plus “geplante Wiederherstellung/Promotion”, nicht zwingend “automatischer Master-Failover ohne Betriebsprozess”.

2) Agent-Failover ohne Load-Balancer: nur mit Client-seitiger Redundanz oder Netzwerk-VIP

Wenn du ausdrücklich kein Load-Balancing willst, bleiben für Agent-Failover im Wesentlichen zwei Wege:

  1. Mehrere Manager-Adressen im Agent (Client-seitiges Failover)
    Agents können so konfiguriert werden, dass sie bei Nichterreichbarkeit auf eine zweite Manager-Adresse ausweichen (je nach Agent/OS/Policy-Stand). Das ist der sauberste “ohne LB”-Ansatz – allerdings muss er flächig ausgerollt werden (GPO/MDM/Config-Management).
  2. Virtuelle IP / DNS-Failover (Active/Passive auf Netzwerkebene)
    Das ist streng genommen kein Load-Balancing, sondern ein VIP-Failover: eine feste Adresse “zeigt” im Fehlerfall auf den Secondary Manager. Das kann sehr gut funktionieren, ist aber Infrastruktur-Thema (Keepalived/VRRP, Cloud-LB im Failover-Modus, DNS mit kurzen TTLs etc.).

Ohne eine dieser beiden Maßnahmen “shiftet” ein Agent nicht automatisch zu einem anderen Knoten – der Agent kennt sonst schlicht kein alternatives Ziel.

3) Wazuh Indexer Cluster: Replikation ist OpenSearch-Mechanik (Shards/Replicas)

Der Wazuh Indexer ist die Datenebene. HA/DR wird hier primär über:

  • Cluster mit mehreren Knoten
  • Shard-Replikate (replica shards)
  • optional Snapshots (für echtes DR/Restore in anderen Umgebungen)

realisiert.

Typischer Effekt:

  • Fällt ein Knoten aus, bleiben Indizes verfügbar, wenn genügend Replikate existieren und die Cluster-Health nicht in kritische Zustände rutscht.
  • Datenreplikation ist “live” im Sinne der Index-Replication: neue Daten werden gemäß Shard/Replica-Strategie verteilt.

Rolle “Master” im Indexer: In OpenSearch gibt es Cluster-Manager (früher “Master”) zur Clusterkoordination. Viele Installationen betreiben mehrere master-eligible Nodes. Damit ist der Cluster koordiniert hochverfügbar, solange Quorum/Mehrheit gewährleistet ist. Das ist keine Wazuh-Speziallogik, sondern OpenSearch-Clusterprinzip.

4) Dashboard: offiziell praktisch Single-Node im Wazuh-Sinn

Das Dashboard ist UI und API-Consumer. In der Praxis kann man Infrastruktur-HA um das Dashboard herum bauen (VM-HA, Container-Restart, gespiegelte Konfig, Reverse Proxy), aber “Wazuh Dashboard als vollwertiger HA-Cluster mit State-Replikation” ist im Standardbetrieb nicht das gleiche wie beim Indexer. Der produktive Mehrwert liegt meist darin, Indexer und Manager hochverfügbar zu machen; das Dashboard kann dann bei Ausfall schnell ersetzt/neu gestartet werden, ohne Datenverlust (weil Daten im Indexer liegen).

Lösung / Best Practices

A) Zielbild für HA/DR (minimal sinnvoll, produktionsnah)

Indexer:

  • Mindestens 3 Knoten (Quorum-fähig), mit Replica-Shards (z. B. number_of_replicas: 1 oder höher je nach SLA).
  • Optional: Snapshots in Object Storage/NFS als DR-Absicherung.

Manager:

  • 1× Master + ≥1× Worker.
  • Agents erhalten zwei Manager-Ziele (Client-Failover) oder es gibt eine VIP/DNS-Failover-Adresse.

Dashboard:

  • Single-Node betreiben, aber Konfigurationssicherung und schnelles Reprovisioning einplanen (Infrastructure-as-Code, Backups der opensearch_dashboards.yml/Wazuh-App-Konfiguration, Zertifikate).

B) Bestehendes Single-Node-Setup zu Indexer-Cluster erweitern (Daten bleiben erhalten)

  1. Neue Indexer-Nodes bereitstellen (gleiches Major/Minor, gleiche Security-Policy/Zertifikatsstrategie).
  2. Cluster Discovery konfigurieren (Seed Hosts / Initial Cluster-Manager Nodes, Zertifikate, Clustername).
  3. Node beitreten lassen, Cluster-Status prüfen.
  4. Replikation aktiv nutzbar machen:
    • Bestehende Indizes haben häufig number_of_replicas: 0 im Single Node.
    • Setze für relevante Indizes Replikate auf 1 (oder mehr) und verifiziere, dass Replica-Shards auf andere Nodes verteilt werden.
  5. Shard-Strategie prüfen:
    • Zu viele Shards auf kleinen Clustern erzeugen Overhead.
    • Plane Shard-Anzahl anhand Datenvolumen und Retention, nicht “Standardwerte”.

Side-Effects: Beim Erhöhen von Replikaten und beim Rebalancing steigen IO/CPU/Netzwerk-Last temporär. Das sollte bewusst in einem Wartungsfenster oder mit Kapazitätspuffer passieren.

C) Manager-Cluster nachrüsten (Konfig-Sync, aber DR braucht Prozess)

  1. Worker-Node installieren (gleiche Version), Zertifikate/Cluster-Key sauber setzen.
  2. Cluster-Konfiguration definieren (Node-Name, Node-Type, Cluster-Name, Shared Sync).
  3. Cluster-Sync verifizieren:
    • Prüfe, dass “shared” Inhalte (Regeln, Decoders, Listen, ggf. Agent-Gruppenartefakte je nach Deployment) konsistent sind.
  4. Agent-Failover umsetzen:
    • Entweder zweite Manager-Adresse in Agent-Konfig ausrollen
    • oder VIP/DNS-Failover einrichten.
  5. DR-Promotion planen (Worst Case “Master weg”):
    • Definiere ein Runbook, wie ein Worker zum neuen Master wird: Rollenänderung, Neustart/Service-Reihenfolge, Prüfung der Konfig-Vollständigkeit, API/Enrollment-Services testen.
    • Stelle sicher, dass kritische Konfigurationen nicht nur auf dem Master liegen (saubere Sync- und Backup-Strategie).

Side-Effects: Bei Master-Ausfall sind zentrale Operationen eingeschränkt. Mit sauberem Runbook ist der Impact beherrschbar, aber nicht “unsichtbar”.

D) Dashboard betrieblich absichern (ohne “Cluster-Illusion”)

  • Halte Dashboard stateless: Konfiguration per IaC/Config-Management ausrollen.
  • Backups der Dashboard-Konfig, Zertifikate und (falls genutzt) benutzerdefinierter Einstellungen/Objekte einplanen.
  • Reverse Proxy davor ist okay – aber er ersetzt kein echtes State-Failover; er erhöht nur Erreichbarkeit.

Lessons Learned / Best Practices

  1. HA ohne Load-Balancing braucht trotzdem eine Failover-Mechanik.
    Entweder Agents kennen mehrere Manager-Ziele, oder du nutzt VIP/DNS-Failover. Ohne das gibt es keinen automatischen “Shift”.
  2. Indexer-HA ist dein Daten-Sicherheitsnetz.
    Replica-Shards und ein quorumfähiger Cluster sind entscheidend. Für DR zusätzlich Snapshots einplanen.
  3. Manager-Cluster = Weiterbetrieb + koordinierter Restore/Promotion.
    Worker können weiter korrelieren und Alerts erzeugen, aber Master-zentrierte Funktionen brauchen Wiederherstellung oder gezielte Promotion.
  4. Nachträgliches Clustering ist möglich, aber nicht “kostenlos”.
    Rebalancing/Replica-Aufbau erzeugt Last. Plane Kapazität und Timing.
  5. Dashboard nicht überbewerten.
    Datenverlust entsteht dort nicht – der kritische Pfad ist Indexer + Manager. Dashboard muss “schnell ersetzbar” sein.

Fazit

Wazuh lässt sich für HA/DR sinnvoll ausbauen: Indexer-Cluster liefert echte Datenreplikation (Shards/Replicas) und robuste Verfügbarkeit, Manager-Cluster ermöglicht Weiterverarbeitung bei Master-Ausfall, erfordert aber für vollständige Übernahme einen geplanten Promotion-/Restore-Prozess. Ein automatisches Agent-Failover ohne Load-Balancer gelingt nur über mehrere Manager-Ziele im Agent oder über VIP/DNS-Failover. Das Dashboard bleibt im Kern eine Single-Node-Komponente, sollte aber betrieblich so aufgestellt sein, dass es im Fehlerfall schnell neu bereitgestellt werden kann.

https://wazuh.slack.com/archives/C07CCCCGHHP/p1765780935226779

Mehr zu Wazuh …

Mehr zum Wazuh Ambassador Program …