Cluster-Bereitstellungsarchitektur

Dieser Leitfaden behandelt Architekturüberlegungen für die Bereitstellung von Hydden Discovery in einer geclusterten On-Premises-Konfiguration. Geclusterte Bereitstellungen bieten Hochverfügbarkeit, Fehlertoleranz und Disaster-Recovery-Funktionen für Unternehmensumgebungen.

Was ist eine Cluster-Bereitstellung?

Was es ist: Eine Cluster-Bereitstellung betreibt mehrere Hydden-Server-Knoten, die als einheitliches System zusammenarbeiten. Wenn ein Knoten ausfällt, bedienen die verbleibenden Knoten weiterhin Anfragen. Daten werden über Knoten hinweg repliziert, um Datenverlust zu verhindern.

Warum es wichtig ist: Einzelserver-Bereitstellungen schaffen einen Single Point of Failure. Für Organisationen mit strengen Verfügbarkeitsanforderungen, Compliance-Vorgaben oder umfangreichen Identitätsdaten gewährleistet eine Cluster-Bereitstellung kontinuierliche Verfügbarkeit und Datenschutz.

Diagrammbeschreibung: Ein Top-Down-Flussdiagramm, das eine Cluster-Bereitstellungsarchitektur zeigt. Ein Load Balancer (HAProxy, F5 oder AWS ALB) verteilt den Datenverkehr an einen Hydden Server Cluster mit Node 1 (Primary), Node 2 (Secondary) und Node 3 (Secondary). Alle Serverknoten kommunizieren mit einem NATS-Cluster aus drei Brokern und sind mit dem gemeinsamen Speicher verbunden, der die Identity Graph-Datenbank und den Key-Value Store enthält.

Schlüsselbegriffe:

• Knoten — Eine einzelne Hydden-Serverinstanz im Cluster.
• Quorum — Die Mindestanzahl von Knoten, die für den Clusterbetrieb erforderlich sind (typischerweise N/2 + 1).
• Failover — Automatische Übertragung von Operationen von einem ausgefallenen Knoten zu einem funktionsfähigen Knoten.
• Replikation — Kopieren von Daten zwischen Knoten zur Sicherstellung der Redundanz.

Bereitstellungstopologien

Wählen Sie eine Bereitstellungstopologie basierend auf Ihren Verfügbarkeits- und Disaster-Recovery-Anforderungen.

Active-Active-Cluster

Alle Knoten bedienen aktiv Anfragen. Ein Load Balancer verteilt den Datenverkehr über die Knoten.

Aspekt	Konfiguration
Minimale Knoten	3 (für Quorum)
Lastverteilung	Erforderlich
Failover-Zeit	Sekunden (automatisch)
Anwendungsfall	Hochverfügbarkeit innerhalb eines einzelnen Rechenzentrums

Vorteile:

• Vollständige Ressourcennutzung über alle Knoten
• Automatische Lastverteilung
• Kein manuelles Eingreifen während des Failovers

Überlegungen:

• Alle Knoten müssen identische Konfiguration haben
• Netzwerklatenz zwischen Knoten sollte für optimale Leistung unter 10ms liegen
• RPC-Verbindungen müssen innerhalb von 10 Sekunden hergestellt werden (konfigurierbar über RpcConnectTimeout)
• Erfordert gemeinsam genutzten oder replizierten Speicher

Active-Passive-Cluster

Ein Knoten verarbeitet den gesamten Datenverkehr, während Standby-Knoten inaktiv bleiben. Standby-Knoten werden nur während des Failovers aktiviert.

Aspekt	Konfiguration
Minimale Knoten	2
Lastverteilung	Optional (für Health Checks)
Failover-Zeit	30–60 Sekunden
Anwendungsfall	Kosteneffiziente Bereitstellungen mit moderaten Verfügbarkeitsanforderungen

Vorteile:

• Geringere Ressourcennutzung
• Einfachere Konfiguration
• Standby-Knoten kann als Warm-Backup dienen

Überlegungen:

• Aktiver Knoten ist ein Single Point of Failure bis Failover abgeschlossen ist
• Manuelles oder skriptgesteuertes Failover kann erforderlich sein
• Standby-Knoten erfordern regelmäßige Tests

Multi-Site (Disaster Recovery)

Knoten sind über geografisch getrennte Rechenzentren für Disaster Recovery verteilt. Hydden verwendet eine Leaf-Node-Architektur, bei der jeder Standort als Leaf-Cluster arbeitet, der mit einem zentralen Hub verbunden ist.

Aspekt	Konfiguration
Minimale Knoten	5 insgesamt (2 pro Standort + 1 Witness-Knoten)
Standorte	Primär + DR-Standort(e)
Replikation	Asynchron (standortübergreifend) über NATS-Leaf-Verbindungen
Failover-Zeit	60–90 Sekunden (automatische Erkennung + Promotion)
Anwendungsfall	Geschäftskontinuität und regulatorische Compliance

Vorteile:

• Schutz vor standortweiten Ausfällen
• Geografische Redundanz
• Compliance mit Datenresidenzanforderungen
• Jeder Standort kann während Netzwerkpartitionen unabhängig arbeiten

Überlegungen:

• Netzwerk-Timeout zwischen Standorten beträgt 300 Sekunden (konfigurierbar über NetworkTimeout)
• Asynchrone Replikation kann zu Datenverzögerung während Partitionen führen
• DNS oder globaler Load Balancer erforderlich für Standort-Failover
• Witness-Knoten stellt Quorum während Standortausfällen sicher

Warum 5 Knoten für Multi-Site?

Für Multi-Site-Bereitstellungen setzen Sie mindestens 5 Knoten ein (2 pro Standort plus ein Witness):

Konfiguration	Fehlertoleranz	Quorum erhalten wenn...
3 Knoten (einzelner Standort)	1 Knotenausfall	2 von 3 Knoten verfügbar
4 Knoten (2 pro Standort)	1 Knotenausfall	3 von 4 Knoten verfügbar (verliert Quorum wenn gesamter Standort ausfällt)
5 Knoten (2+2+1)	2 Knotenausfälle ODER 1 Standortausfall	3 von 5 Knoten verfügbar

Die Quorum-Formel ist (n/2) + 1, was bedeutet, dass ein 5-Knoten-Cluster 3 Knoten für das Quorum benötigt. Dies ermöglicht den Ausfall eines gesamten 2-Knoten-Standorts bei Aufrechterhaltung des Betriebs.

Witness-Knoten-Platzierung: Setzen Sie den Witness-Knoten an einem dritten Standort ein (Cloud-Region, separates Rechenzentrum oder Colocation-Einrichtung), um Entscheidungen während Standortpartitionen zu ermöglichen.

Leaf-Node-Architektur

Multi-Site-Bereitstellungen verwenden NATS-Leaf-Node-Verbindungen:

Diagrammbeschreibung: Ein Top-Down-Flussdiagramm, das die Multi-Site-Leaf-Node-Architektur zeigt. Site A (Primary) hat Node 1 und Node 2, die miteinander kommunizieren. Site B (DR) hat Node 3 und Node 4, die miteinander kommunizieren. Site C hat einen Witness-Knoten (Node 5). Beide Standorte sind über Leaf-Verbindungen mit dem Witness verbunden, und Site A und Site B sind über standortübergreifende Replikation verknüpft.

Innerhalb jedes Standorts kommunizieren Knoten direkt mit niedriger Latenz. Zwischen Standorten übernehmen Leaf-Verbindungen die Replikation und Cluster-Koordination.

Einzelne Region mit mehreren Rechenzentren

Eine Bereitstellung mit einer einzelnen Region und mehreren Rechenzentren funktioniert gut, wenn:

• Netzwerklatenz zwischen Rechenzentren unter 50ms liegt (Round-Trip)
• Netzwerkoperationen innerhalb der 300-Sekunden-Timeout-Schwelle abgeschlossen werden
• Dedizierte Netzwerkverbindungen zwischen Rechenzentren existieren

Für Same-Region-Bereitstellungen ist synchrone Replikation möglich, wenn die Latenz es erlaubt, wodurch RPO auf nahezu Null reduziert wird.

Server-Knoten-Anforderungen

Hardware-Spezifikationen

Komponente	Minimum (pro Knoten)	Empfohlen (pro Knoten)
CPU	4 Kerne	8+ Kerne
Arbeitsspeicher	16 GB RAM	32 GB RAM
Speicher	100 GB SSD	500 GB NVMe SSD
Netzwerk	1 Gbps	10 Gbps

Betriebssystem

Hydden Server unterstützt:

• Windows Server 2019, 2022
• Linux Ubuntu 20.04+, RHEL 8+, Rocky Linux 8+

Alle Knoten in einem Cluster sollten das gleiche Betriebssystem und die gleiche Version ausführen.

Netzwerkkonfiguration

Port	Protokoll	Zweck
TCP 22100	NATS	Stream-Broker (Knoten-zu-Knoten)
TCP 22101	HTTP	Bootstrap (nur Ersteinrichtung)
TCP 22103	NATS	SMB-Client-Verbindungen
TCP 22104	NATS	Message-Broker-Gateway
TCP 443	HTTPS	Weboberfläche und API

Firewall-Regeln:

• Alle Knoten müssen eingehenden/ausgehenden Datenverkehr auf Ports 22100, 22103 und 22104 zwischen Cluster-Mitgliedern zulassen
• Load Balancer muss TCP 443 auf allen Knoten erreichen
• Clients müssen die Load-Balancer-VIP auf TCP 443 erreichen

NATS-Cluster-Konfiguration

Hydden verwendet NATS als Message Broker. In einer Cluster-Bereitstellung läuft NATS im Cluster-Modus für Hochverfügbarkeit.

Cluster-Dimensionierung

Cluster-Größe	Fehlertoleranz	Empfohlen für
3 Knoten	1 Knotenausfall	Standard-HA
5 Knoten	2 Knotenausfälle	Hohe Fehlertoleranz
7 Knoten	3 Knotenausfälle	Maximale Fehlertoleranz

IMPORTANT

Verwenden Sie immer eine ungerade Anzahl von Knoten, um sicherzustellen, dass ein Quorum während Netzwerkpartitionen hergestellt werden kann.

NATS-Konfiguration

Die NATS-Konfiguration jedes Knotens enthält Cluster-Peer-Definitionen:

# Example NATS cluster configuration
cluster:
  name: hydden-cluster
  listen: 0.0.0.0:6222
  routes:
    - nats://node1.internal:6222
    - nats://node2.internal:6222
    - nats://node3.internal:6222

Der Hydden-Installer konfiguriert NATS automatisch. Für manuelle Cluster-Einrichtung kontaktieren Sie den Hydden-Support.

Timeout- und Health-Check-Einstellungen

Hydden verwendet die folgenden Standard-Timeouts für Cluster-Operationen:

Einstellung	Standardwert	Beschreibung
StartupTimeout	10 Sekunden	Maximale Zeit für einen Knoten zum Starten und Beitreten zum Cluster
ShutdownTimeout	30 Sekunden	Graceful-Shutdown-Zeitraum vor erzwungener Beendigung
RpcConnectTimeout	10 Sekunden	Timeout für die Herstellung von RPC-Verbindungen zwischen Knoten
NetworkTimeout	300 Sekunden	Maximale Zeit für Netzwerkoperationen (standortübergreifende Replikation)
ProbeInterval	15 Sekunden	Health-Check-Intervall zwischen Knoten (mit Jittering)
OfflineThreshold	60 Sekunden	Zeit ohne Antwort bevor ein Knoten als offline markiert wird

Fehlererkennungs-Timing: Wenn ein Knoten ausfällt, erkennt der Cluster den Ausfall innerhalb von 60 Sekunden (4 verpasste Probe-Intervalle). Automatisches Failover beginnt sofort nach der Erkennung.

TIP

Für Umgebungen mit höherer Latenz passen Sie NetworkTimeout entsprechend an. Standortübergreifende Bereitstellungen erfordern möglicherweise Werte bis zu 600 Sekunden.

JetStream-Persistenz

NATS JetStream übernimmt die Nachrichtenpersistenz und Replikation über den Cluster. JetStream bietet:

• Stream-Replikation: Nachrichten werden vor der Bestätigung auf mehrere Knoten repliziert
• Merkle-Baum-Verifizierung: Datenintegrität wird mittels Merkle-Baum-Hashes verifiziert
• Automatische Wiederherstellung: Knoten synchronisieren verpasste Nachrichten automatisch nach Wiederverbindung

Load-Balancer-Konfiguration

Ein Load Balancer verteilt eingehende Anfragen über Cluster-Knoten und bietet Health Checking.

Health-Check-Endpunkt

Konfigurieren Sie Ihren Load Balancer zur Prüfung:

Prüfung	Endpunkt	Erwartete Antwort
HTTP Health	GET /health	HTTP 200
Readiness	GET /ready	HTTP 200

Beispiel HAProxy-Konfiguration

frontend hydden_https
    bind *:443 ssl crt /etc/ssl/hydden.pem
    default_backend hydden_servers

backend hydden_servers
    balance roundrobin
    option httpchk GET /health
    http-check expect status 200
    server node1 192.168.1.10:443 check ssl verify none
    server node2 192.168.1.11:443 check ssl verify none
    server node3 192.168.1.12:443 check ssl verify none

Sitzungspersistenz

Hydden verwendet JWT-Tokens für die Authentifizierung. Sitzungspersistenz (Sticky Sessions) ist nicht erforderlich, da Tokens von jedem Cluster-Knoten validiert werden.

Datenspeicherung und Replikation

Identity Graph-Datenbank

Der Identity Graph speichert alle entdeckten Identitätsdaten. In Cluster-Bereitstellungen:

Speicheroption	Replikation	Empfohlen für
Gemeinsamer Speicher (SAN/NAS)	Speicherebene	Active-Passive-Cluster
Replizierter Speicher	Anwendungsebene	Active-Active-Cluster
Externe Datenbank	Datenbank-Clustering	Großskalige Bereitstellungen

Key-Value-Store

Der KV-Store verwaltet Konfigurations- und Sitzungsdaten. Optionen umfassen:

• Eingebettet (Standard): Repliziert über NATS JetStream
• Externes Redis: Redis Cluster oder Redis Sentinel für HA

Backup-Strategie

Datentyp	Backup-Methode	Häufigkeit
Identity Graph	Datenbank-Dump oder Snapshot	Täglich
Konfiguration	Datei-Backup oder Export	Nach Änderungen
Credentials Vault	Verschlüsseltes Backup	Täglich

NOTE

Hydden bietet integrierte Backup-APIs. Siehe Backup & Restore API für Automatisierungsoptionen.

Hochverfügbarkeits-Verfahren

Hinzufügen eines Knotens zum Cluster

Zweck: Cluster-Kapazität erweitern oder einen ausgefallenen Knoten ersetzen.

Voraussetzungen:

• Neuer Server erfüllt Hardware-Anforderungen
• Netzwerkverbindung zu bestehenden Knoten
• Hydden-Installationspaket

Schritte:

1. Hydden auf dem neuen Server installieren. Führen Sie den Installer wie in Linux Server oder Windows Server beschrieben aus.

2. Wählen Sie Join existing cluster während des Bootstrap. Der Bootstrap-Assistent erkennt den Cluster-Modus.

3. Cluster-Join-Token eingeben. Erhalten Sie das Token von der Admin-Oberfläche eines bestehenden Knotens unter Settings > Cluster.

4. Auf Synchronisierung warten. Der neue Knoten synchronisiert Daten von bestehenden Knoten. Dies kann je nach Datengröße mehrere Minuten dauern.

5. Knotenzustand verifizieren. Überprüfen Sie die Cluster-Statusseite, um zu bestätigen, dass der neue Knoten Healthy anzeigt.

Ergebnis: Der neue Knoten tritt dem Cluster bei und beginnt nach Abschluss der Synchronisierung Anfragen zu bedienen.

Entfernen eines Knotens aus dem Cluster

Zweck: Einen Knoten für Wartung oder Austausch außer Betrieb nehmen.

Schritte:

1. Knoten drainieren. Navigieren Sie zu Settings > Cluster > [Knotenname] und klicken Sie auf Drain. Der Knoten akzeptiert keine neuen Anfragen mehr.

2. Auf Abschluss aktiver Verbindungen warten. Überwachen Sie die Verbindungsanzahl, bis sie Null erreicht.

3. Knoten entfernen. Klicken Sie auf Remove from Cluster. Der Knoten trennt sich vom NATS-Cluster.

4. Load-Balancer-Konfiguration aktualisieren. Entfernen Sie den Knoten aus dem Backend-Server-Pool.

Ergebnis: Der Knoten wird sicher ohne Serviceunterbrechung entfernt.

Failover-Tests

Testen Sie Failover-Verfahren regelmäßig, um sicherzustellen, dass sie bei tatsächlichen Ausfällen korrekt funktionieren.

Erwartetes Timing: Knotenausfallserkennung dauert bis zu 60 Sekunden (OfflineThreshold). Load-Balancer-Failover hängt von Ihrer Health-Check-Konfiguration ab (typischerweise 15–30 Sekunden zusätzlich).

1. Wartungsfenster planen. Planen Sie mindestens 15 Minuten für den vollständigen Testzyklus ein.

2. Knotenausfall simulieren.

   • Option A: Hydden-Dienst auf einem Knoten stoppen (systemctl stop hydden oder Stop-Service Hydden)
   • Option B: Netzwerkports mit Firewall-Regeln blockieren (blockiert Ports 22100, 22103, 22104)

3. Timing starten und überwachen.

   • Notieren Sie die genaue Zeit des simulierten Ausfalls
   • Beobachten Sie die Cluster-Statusseite auf Knotenzustandsänderungen
   • Erwartet: Knoten innerhalb von 60 Sekunden als "Unhealthy" markiert

4. Automatisches Failover verifizieren.

   • Bestätigen Sie, dass verbleibende Knoten weiterhin Anfragen bedienen (API-Aufrufe testen)
   • Prüfen Sie, dass der Load Balancer den ausgefallenen Knoten als unhealthy markiert
   • Verifizieren Sie, dass Client-Verbindungen zu gesunden Knoten umgeleitet werden
   • Überwachen Sie Cluster-Logs auf Fehlermeldungen: journalctl -u hydden -f (Linux) oder Ereignisanzeige (Windows)

5. Knoten wiederherstellen.

   • Hydden-Dienst neu starten oder Firewall-Regeln entfernen
   • Verifizieren Sie, dass der Knoten automatisch dem Cluster wieder beitritt
   • Erwartet: Knoten innerhalb von 30 Sekunden nach Neustart als "Healthy" markiert

6. Ergebnisse dokumentieren. Tatsächliche Failover-Zeit aufzeichnen und mit erwarteten Schwellenwerten vergleichen:

   Metrik	Erwartet	Tatsächlich
   Ausfallserkennung	≤ 60 Sekunden
   Load-Balancer-Failover	≤ 30 Sekunden
   Gesamte Client-Beeinträchtigung	≤ 90 Sekunden
   Knoten-Wiederbeitrittszeit	≤ 30 Sekunden

Disaster Recovery

Recovery Point Objective (RPO)

Replikationstyp	Typischer RPO
Synchron (gleicher Standort)	0 (kein Datenverlust)
Asynchron (standortübergreifend)	1–5 Minuten
Backup-basiert	Letztes Backup-Intervall

Recovery Time Objective (RTO)

Szenario	Typischer RTO
Einzelner Knotenausfall (HA-Cluster)	Sekunden
Standortausfall (DR-Standort verfügbar)	5–30 Minuten
Vollständige Wiederherstellung aus Backup	1–4 Stunden

DR-Failover-Verfahren

Zweck: Den Disaster-Recovery-Standort aktivieren, wenn der primäre Standort nicht verfügbar ist.

Voraussetzungen:

• DR-Standort ist betriebsbereit und synchronisiert
• DNS- oder globaler Load-Balancer-Zugriff

Schritte:

1. Bestätigen, dass der primäre Standort nicht verfügbar ist. Überprüfen Sie, dass der Ausfall kein Netzwerkproblem ist, bevor Sie das DR-Failover initiieren.

2. DNS oder globalen Load Balancer aktualisieren. Leiten Sie den Datenverkehr zum DR-Standort. Beispiel:

   • Aktualisieren Sie hydden.yourcompany.com zur Auflösung auf DR-Standort-IPs
   • Oder aktualisieren Sie den globalen Load Balancer zur Bevorzugung des DR-Backends

3. Verifizieren, dass der DR-Standort Anfragen bedient. Greifen Sie auf das Hydden-Portal zu und bestätigen Sie die Funktionalität.

4. Stakeholder benachrichtigen. Informieren Sie Benutzer, dass das System vom DR-Standort aus betrieben wird.

5. Failback planen. Sobald der primäre Standort wiederhergestellt ist, planen Sie das Failback während eines Wartungsfensters.

Ergebnis: Der Betrieb wird vom DR-Standort mit minimalem Datenverlust fortgesetzt (basierend auf Replikationsverzögerung).

Überwachung und Alerting

Schlüsselmetriken

Metrik	Warnungs-Schwellenwert	Kritischer Schwellenwert
Knotenzustand	Jeder Knoten unhealthy	Quorum verloren
CPU-Auslastung	> 70%	> 90%
Arbeitsspeicher-Auslastung	> 75%	> 90%
Festplatten-Auslastung	> 70%	> 85%
Replikationsverzögerung	> 30 Sekunden	> 5 Minuten
API-Antwortzeit	> 500ms	> 2000ms

Integration mit Überwachungstools

Hydden stellt Metriken im Prometheus-Format unter /metrics bereit. Konfigurieren Sie Ihren Monitoring-Stack zum Scrapen dieses Endpunkts:

# Example Prometheus scrape config
scrape_configs:
  - job_name: 'hydden'
    static_configs:
      - targets:
        - 'node1.internal:443'
        - 'node2.internal:443'
        - 'node3.internal:443'
    scheme: https
    tls_config:
      insecure_skip_verify: true  # Use proper CA in production

Fehlerbehebung

Problem	Mögliche Ursache	Lösung
Knoten kann dem Cluster nicht beitreten	Firewall blockiert NATS-Ports	TCP 22100, 22103, 22104 zwischen Knoten öffnen
Knoten-Beitritt läuft ab	StartupTimeout (10s) überschritten	Netzwerkverbindung prüfen; StartupTimeout bei Bedarf erhöhen
Split-Brain-Zustand	Netzwerkpartition	Netzwerkverbindung wiederherstellen; Cluster heilt automatisch nach 60s
Langsame Replikation (gleicher Standort)	Hohe Netzwerklatenz	Sicherstellen < 10ms Latenz zwischen Knoten; Netzwerkauslastung prüfen
Langsame Replikation (standortübergreifend)	NetworkTimeout-Schwellenwert	NetworkTimeout über 300s für Verbindungen mit hoher Latenz erhöhen
RPC-Verbindungsfehler	RpcConnectTimeout (10s) überschritten	Inter-Knoten-Verbindung prüfen; keinen Paketverlust verifizieren
Load Balancer markiert alle Knoten als unhealthy	Health Check falsch konfiguriert	Verifizieren, dass /health-Endpunkt HTTP 200 zurückgibt
Knoten unerwartet als offline markiert	4 aufeinanderfolgende Probes verpasst (60s)	Knotenzustand prüfen; Netzwerkstabilität verifizieren
Dateninkonsistenz nach Failover	Asynchrone Replikationsverzögerung	Daten vom aktuellsten Knoten akzeptieren; bei Bedarf manuell abgleichen
Quorum in Multi-Site verloren	Weniger als (n/2)+1 Knoten verfügbar	Verbindung zu zusätzlichen Knoten wiederherstellen; Witness-Knoten prüfen

Verwandte Themen

• On-Prem-Bereitstellungsübersicht — Einzelknoten-Bereitstellungsanweisungen
• Linux-Server-Installation — Linux-Server-Einrichtung
• Windows-Server-Installation — Windows-Server-Einrichtung
• Architektur — Hydden Discovery Architekturübersicht
• Backup & Restore API — Automatisierte Backup-Endpunkte