Facebook Instagram Envelope Phone User
Termine vereinbaren
Home
Termin vereinbaren

Protokoll: Wir bauen einen redundanten Failover-Server in unter 4 Stunden

Übersicht

Inhaltsverzeichnis

Einleitung: Warum Redundanz heute entscheidend ist und was uns die 4-Stunden-Challenge lehrt

1. Definition von Hochverfügbarkeit (HA) und Failover im Kontext der IT

Die aktuelle Geschäftserwartung setzt Verfügbarkeitsziele von mindestens 99,9 % („drei Neunen“) an kritische IT-Systeme voraus, was einer maximalen Ausfallzeit von unter neun Stunden pro Jahr entspricht. Hochverfügbarkeit (HA) ist die Architektur, die diese Betriebszeit durch redundante Systeme sicherstellt. Ein Failover bezeichnet dabei den sofortigen, automatischen Wechsel von einem primären, ausgefallenen System auf eine passive Einheit. Es handelt sich um eine ungeplante, reaktive Serviceübergabe, die sich fundamental von einem geplanten Switchover unterscheidet.

2. Die ‚4-Stunden‘-Prämisse: Wie wir durch Fokus und den richtigen Technologie-Stack Zeit sparen

Die Zeitvorgabe von unter vier Stunden ist die ultimative Metrik für diesen Guide, da sie die Notwendigkeit einer schnellen Risikominderung unterstreicht und die Dringlichkeit der Implementierung belegt. Um diesen technischen Sprint zu gewährleisten, wird der Fokus rigoros auf die Kernfunktionalität der automatisierten Wiederherstellung des Dienstes gelegt. Komplexe Überwachungssysteme (Monitoring), umfangreiche Skalierungslösungen oder aufwändige, globale Storage-Lösungen, die die Implementierungszeit typischerweise verlängern, werden bewusst ausgelassen. Der Schwerpunkt liegt auf der Etablierung einer schnell realisierbaren, minimal funktionsfähigen HA-Lösung (Minimum Viable Cluster).

3. Vorgestellter Technologie-Stack: Eine kurze Übersicht

Das Erreichen des 4-Stunden-Ziels erfordert den Einsatz schlanker, bewährter Open-Source-Tools auf einer stabilen Linux-Basis. Diese Komponenten sind für ihre Effizienz und schnelle Konfigurierbarkeit bekannt. Die zentrale Steuerung des Sprint-Protokolls basiert auf den folgenden Kernkomponenten:

  1. Linux-Betriebssystem: Die stabilste und ressourceneffizienteste Basis für die spezialisierte HA-Software.
  2. DRBD (Distributed Replicated Block Device): Wird zur synchronen Block-Level-Replikation von Daten zwischen den Cluster-Knoten eingesetzt.
  3. Keepalived oder Pacemaker: Dient zur Überwachung der Knoten und zum Management der Ressourcen, insbesondere zur Zuweisung einer virtuellen IP-Adresse (VIP) zur Steuerung des automatischen Failover-Prozesses.

Die Vorbereitung: Systemanforderungen und die ersten 30 Minuten

Der 30-Minuten-Sprint beginnt: Die unmittelbare Betriebsbereitschaft ist jetzt zwingend herzustellen. Jede Abweichung von den folgenden Vorgaben führt zur Verzögerung des Hochverfügbarkeits-Setups.

Hardware- und Software-Mindestanforderungen für das Duplikat-Setup

Zwingend erforderlich sind zwei identisch konfigurierte Linux-Server (Knoten).

  • Minimalanforderungen (pro Knoten): Die Knoten müssen mindestens über eine 64-Bit-CPU-Architektur verfügen. Die RAM-Anforderung für DRBD skaliert mit der Speicherkapazität und liegt bei etwa 32 MiB pro 1 TiB repliziertem Speicher.
  • Betriebssystem (OS): Wählen Sie eine Enterprise-fähige Linux-Distribution wie Ubuntu Server LTS oder CentOS/RHEL.
  • Dedizierte Partition: Eine unformatierte, dedizierte Block-Partition von gleicher Größe auf beiden Knoten ist zwingend erforderlich. DRBD spiegelt dieses Block-Device als Netzwerk-RAID-1-Äquivalent, weshalb die Partition als primäre Datenspeicherung dient und auf dem passiven Knoten nicht gemountet werden darf.

Netzwerk-Topologie und IP-Schema (Master, Slave und Virtuelle IP)

Eine klare Trennung des Netzwerkverkehrs muss eingerichtet werden, um Heartbeat/VIP-Verkehr vom DRBD-Replikationsverkehr zu isolieren. Dies erfordert mindestens zwei getrennte Netzwerkschnittstellen.

Knoten Feste IP Funktion
Knoten 1 (Master) 192.168.1.101 Feste Management-/Produktions-IP (Primär)
Knoten 2 (Slave) 192.168.1.102 Feste Management-/Produktions-IP (Sekundär)
Virtuelle IP (VIP) 192.168.1.100 Floating Service-IP (wird bei Failover verschoben)

Die Virtuelle IP (VIP) wird vom Keepalived-Protokoll (VRRP) verwaltet und ist die Adresse, über die Clients auf den Dienst zugreifen. Im Falle eines Master-Ausfalls weist Keepalived die VIP automatisch dem Slave-Knoten zu, um einen nahtlosen Failover zu gewährleisten.

Bereitstellung der Betriebssystem-Basis (OS-Installation oder Template-Deployment)

Führen Sie die Basisinstallation auf beiden Knoten durch und eliminieren Sie sofort unnötige Dienste, um die Angriffsfläche zu reduzieren.

  1. System-Update: Alle Pakete auf den neuesten Stand bringen (apt update && apt upgrade oder dnf update).
  2. Unnötige Dienste: Deaktivieren Sie nicht benötigte Dienste wie cups, postfix oder avahi-daemon.
    • Befehl: sudo systemctl stop <dienst>; sudo systemctl disable <dienst>
  3. Hostnamen-Auflösung: Stellen Sie die Auflösung der Hostnamen beider Knoten sicher, indem Sie die Hostnamen und ihre festen IPs in der Datei /etc/hosts auf beiden Systemen eintragen.
  4. Zeitsynchronisation: Installieren Sie einen NTP-Dienst, um die Systemzeiten zu synchronisieren, was für den Clusterbetrieb kritisch ist.

Notwendige Vorinstallationen und Firewall-Konfiguration

1. Zwingend zu installierende Pakete: Installieren Sie die folgenden Pakete auf beiden Knoten:

  1. drbd-utils (für die Replikation des Block-Devices)
  2. keepalived (für das VRRP-basierte IP-Failover)

2. Firewall-Konfiguration: Die lokale Firewall (firewalld oder ufw) muss so konfiguriert werden, dass die Kommunikation zwischen den Knoten möglich ist.

  • DRBD-Daten-Sync: DRBD verwendet TCP-Port 7788 (oder höher, pro Ressource).
    • Firewalld-Beispiel: sudo firewall-cmd --permanent --add-port=7788/tcp; sudo firewall-cmd --reload
  • Keepalived-Heartbeat (VRRP): Keepalived verwendet IP-Protokoll 112 (kein TCP/UDP-Port), oft Multicast-Adresse 224.0.0.18.
    • UFW-Beispiel: sudo ufw allow proto vrrp

Schritt-für-Schritt-Protokoll: Aufbau und Konfiguration des Failover-Clusters

Mit funktionierender Basis-Kommunikation starten wir nun die HA-Kernkonfiguration.

Installation und Grundkonfiguration der HA-Software auf Master und Slave

Installieren Sie die notwendigen DRBD-Pakete (drbd-utils und Kernel-Module) auf beiden Knoten (Master und Slave).

  1. Aktualisieren Sie das Paket-Repository:
    bash
    sudo apt update
  2. Installieren Sie die DRBD-Kernpakete:
    bash
    sudo apt install drbd-utils drbd-dkms

    oder
    bash
    sudo yum install drbd kmod-drbd
  3. Laden Sie das DRBD-Kernel-Modul:
    bash
    sudo modprobe drbd
  4. Überprüfen Sie die erfolgreiche Modul-Installation:
    bash
    drbdadm status
  5. Erstellen Sie auf beiden Hosts die Konfigurationsdatei für die erste Ressource, beispielsweise /etc/drbd.d/r0.res.

Einrichtung der Datenreplikation (z.B. mit DRBD)

Definieren Sie in der Ressourcendatei (/etc/drbd.d/r0.res) die minimalen Parameter zur Verbindung der Replikations-IPs und der zugrundeliegenden Blockgeräte (/dev/sdb1).

Parameter Wert/Beschreibung
resource r0 Definiert die Ressource.
protocol C Synchrones Replikationsprotokoll (beste Performance/Konsistenz).
device /dev/drbd0 Das virtuelle DRBD-Blockgerät.
disk /dev/sdb1 Das physische Blockgerät auf dem jeweiligen Host.
address IP:Port Replikations-IP und Port (z.B. 10.0.0.1:7788).
meta-disk internal Speichert Metadaten auf der replizierten Partition.

Fügen Sie der Datei r0.res die entsprechende Konfiguration hinzu:

drbd
resource r0 {
protocol C;
on host-master {
device /dev/drbd0;
disk /dev/sdb1;
address 10.0.0.1:7788;
meta-disk internal;
}
on host-slave {
device /dev/drbd0;
disk /dev/sdb1;
address 10.0.0.2:7788;
meta-disk internal;
}
}

Führen Sie auf beiden Knoten nacheinander folgende Initialisierungsbefehle aus:

  1. Erstellen Sie den Metadaten-Header der DRBD-Ressource:
    bash
    sudo drbdadm create-md r0
  2. Aktivieren Sie die Ressource und stellen Sie die Verbindung zum Peer her:
    bash
    sudo drbdadm up r0
  3. Setzen Sie den Master-Knoten initial auf den Primär-Status (nur auf dem Master ausführen):
    bash
    sudo drbdadm primary --force r0

    Warten Sie die erste vollständige Synchronisation ab.

Definition der Cluster-Ressourcen und Dienste (Services)

Erstellen Sie ein robustes Start/Stopp-Skript, das den primären Applikationsdienst steuert, da Keepalived dieses Skript zur Dienstintegritätsprüfung verwenden wird. Speichern Sie das Skript beispielsweise unter /usr/local/bin/check_service.sh und machen Sie es ausführbar.

„`bash

!/bin/bash

SERVICENAME=“ihrdienst“ # Ersetzen Sie dies durch Ihren tatsächlichen Dienstnamen (z.B. apache2, mariadb)

case „$1“ in
start)
systemctl start $SERVICENAME
;;
stop)
systemctl stop $SERVICENAME
;;
status)
systemctl status $SERVICE_NAME > /dev/null 2>&1
;;
*)
echo „Usage: $0 {start|stop|status}“
exit 1
esac

exit $?
„`

Stellen Sie sicher, dass das Skript auf beiden Knoten ausführbar ist:

bash
sudo chmod +x /usr/local/bin/check_service.sh

Zuweisung der Virtuellen IP (VIP) und Konfiguration der Umschaltregeln

Konfigurieren Sie Keepalived auf dem Master-Knoten (/etc/keepalived/keepalived.conf), um die Virtuelle IP (192.168.1.100) zu binden und die Master-Rolle mit hoher Priorität zu definieren.

keepalived
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 101 # Höhere Priorität als Slave (z.B. 100)
advert_int 1
authentication {
auth_type PASS
auth_pass geheim
}
virtual_ipaddress {
192.168.1.100/24 dev eth0 # Die Virtuelle IP
}
track_script {
chk_service_health # Referenz auf das Health-Check-Skript (H3-5)
}
}

Setzen Sie auf dem Slave-Knoten die state auf BACKUP und die priority auf einen niedrigeren Wert (z.B. 100).

Implementierung von Health-Checks und automatischen Failover-Triggern

Fügen Sie der Keepalived-Konfigurationsdatei (/etc/keepalived/keepalived.conf) einen vrrp_script-Block hinzu, der den Status des Anwendungsdienstes (über das in H3-3 erstellte Skript) prüft.

keepalived
vrrp_script chk_service_health {
script "/usr/local/bin/check_service.sh status"
interval 2 # Führt den Check alle 2 Sekunden aus
weight -20 # Senkt die Priorität bei Fehler um 20 (Failover)
fall 2 # Wie oft fehlschlagen, bevor Priorität gesenkt wird
rise 1 # Wie oft erfolgreich sein, bevor Priorität wieder erhöht wird
}

Durch weight -20 wird bei einem Fehler im Service-Check die Priorität des Knotens so dynamisch gesenkt, dass der Backup-Knoten (mit Priorität 100, falls Master bei 101) die VIP übernimmt.

Starten Sie Keepalived auf beiden Knoten, um das Protokoll zu aktivieren:

bash
sudo systemctl start keepalived
sudo systemctl enable keepalived

Die Stunde der Wahrheit: Testing und Verifizierung des Failover

Der Test- und Verifizierungsprozess der Hochverfügbarkeits-Konfiguration erfolgt in vier sequenziellen Schritten, um die Wiederherstellungsziele (RTO und RPO) aktiv zu messen.

1. Überprüfung des Cluster-Status und der Ressourcenzuordnung

Vor der Failover-Simulation muss der stabile Betriebszustand des Clusters verifiziert werden.

  1. DRBD-Status prüfen: Auf dem Primärserver den Status des replizierten Block-Devices überprüfen.
    cat /proc/drbd
    Erwartet: Der Status muss cs:Connected, die Rolle st:Primary/Secondary und die Synchronisierung ds:UpToDate/UpToDate melden.
  2. VIP-Zuweisung verifizieren: Die Zuweisung der Virtual IP (VIP) zum aktiven (Master-)Knoten prüfen.
    ip a show <Schnittstelle>
    Erwartet: Die VIP muss direkt der Netzwerkschnittstelle des Master-Knotens zugewiesen sein.

2. Manuelle Failover-Simulation durch Abschalten des Primärservers

Der realistischste manuelle Test simuliert einen unerwarteten Dienst- oder Knotenausfall des primären Systems.

  1. Downtime-Messung starten: Auf einem separaten Client einen kontinuierlichen Ping zur VIP starten, um die Umschaltzeit (RTO) zu messen: ping <VIP>
  2. Primärserver abschalten: Auf dem Primärserver den Keepalived-Dienst unsanft beenden, um einen Ausfall zu simulieren:
    systemctl stop keepalived
  3. VIP-Übernahme prüfen: Sofort auf dem Sekundärserver die Schnittstellen prüfen.
    ip a show <Schnittstelle>
    Erwartet: Der Sekundärserver muss in den Status MASTER wechseln und die VIP innerhalb von Sekunden übernehmen. Die Ping-Ausgabe zeigt die exakte RTO.

3. Analyse der Umschaltzeit und des Datenverlusts

Die Wiederherstellungsziele (RTO/RPO) werden anhand der Messungen aus Schritt 2 validiert.

Test-Metrik Erwarteter Wert (Ziel) Gemessener Wert
RTO (Umschaltzeit) < 5 Sekunden [Gemessene Ping-Ausfallzeit eintragen]
RPO (Datenverlust) Null (0) Kein Datenverlust

Begründung RPO: Da DRBD synchron (Protocol C) konfiguriert ist, werden Schreibvorgänge erst dann als abgeschlossen bestätigt, wenn sie auf beiden Knoten auf die Festplatte geschrieben wurden, wodurch Datenverlust ausgeschlossen ist.

4. Belastungstest: Stabilität des Sekundärservers unter Last

Nach erfolgreicher Umschaltung muss die Funktionsfähigkeit des nun aktiven Sekundärservers unter minimaler Last bestätigt werden.

  1. Service-Integrität prüfen: Führen Sie auf dem Client einen kurzen Lasttest auf die VIP durch, um die Stabilität des Services zu prüfen und zu bestätigen, dass der Webserver auf dem neuen Master korrekt antwortet.
    for i in {1..100}; do curl -s -o /dev/null http://<VIP>/; done
  2. Verifizierung: Die Schleife muss 100 erfolgreiche, fehlerfreie HTTP-Anfragen liefern.
  3. Abschluss: Der DRBD-Status des aktiven Servers muss weiterhin Primary/Secondary melden, die VIP muss zugewiesen bleiben.

Fazit, Härtung und Ausblick

Zusammenfassung des Zeitprotokolls: Wurde das 4-Stunden-Ziel erreicht?

Die Implementierung des Basis-Failover-Clusters konnte innerhalb des 4-Stunden-Sprints erfolgreich abgeschlossen werden, einschließlich der Installation, Konfiguration und Validierung eines funktionierenden Test-Failovers. Der Proof-of-Concept ist somit erfolgreich.

Tipps zur Härtung und Skalierung des Failover-Clusters

Für den Produktionsbetrieb sind sofortige Härtungsmaßnahmen notwendig, da der 4-Stunden-Sprint nur das funktionale Minimum umfasste. Die wichtigsten nächsten Schritte sind:

  1. Implementierung von STONITH (Fencing): Dies ist der kritischste Schritt zur Verhinderung von Split-Brain-Szenarien und zur Sicherstellung der Datenintegrität. Ohne STONITH kann der Cluster nicht garantieren, dass ein ausgefallener Knoten tatsächlich gestoppt ist, bevor Ressourcen auf einem gesunden Knoten übernommen werden.
  2. Skalierung durch Load Balancing: Für eine horizontale Skalierung muss ein dedizierter Load Balancer (z.B. HAProxy oder LVS) vor der Virtual IP (VIP) eingerichtet werden. Dies ermöglicht eine aktive Verteilung des Datenverkehrs auf mehrere aktive Dienstknoten und verbessert die Performance.

Überlegungen zu Monitoring und proaktiver Wartung

Für eine proaktive Überwachung des Hochverfügbarkeits-Setups sind minimale, aber essenzielle Metriken sofort einzurichten:

  • DRBD-Sync-Status: Die kontinuierliche Überwachung des Replikationsstatus ist unerlässlich, um Datenverlust bei einem Ausfall zu vermeiden und zeitnahe Alerts zu ermöglichen.
  • Pacemaker-Ressourcenstatus: Der Zustand aller Cluster-Ressourcen (z.B. die Virtual IP, VRRP-State) muss überwacht werden, um sicherzustellen, dass das automatische Failover bei Bedarf auch tatsächlich funktioniert.

Häufig gestellte Fragen (FAQ)

Ist dieses schnelle Setup auch für kritische Produktivsysteme geeignet?

Das hier vorgestellte schnelle Setup dient primär als Prototyp oder als Disaster Recovery (DR)-Testumgebung, jedoch nicht als vollwertige, gehärtete HA-Lösung für kritische Produktivsysteme. Es fehlen essentielle Mechanismen wie STONITH (Shoot The Other Node In The Head) oder Fencing, deren Konfiguration im Ernstfall das gefürchtete Split-Brain-Szenario verhindert und von Herstellern für unterstützte Cluster vorausgesetzt wird.

Wie unterscheidet sich ein aktiver/passiver Failover von Active/Active-Clustern?

Ein Aktiv/Passiv-Cluster nutzt nur einen Knoten für die Dienstbereitstellung, während der zweite Knoten im Standby wartet, was eine einfache Implementierung ermöglicht. Im Gegensatz dazu verteilt ein Aktiv/Aktiv-Cluster die Last gleichzeitig auf alle verfügbaren Knoten, was zu einer besseren Ressourcennutzung und höherem Durchsatz führt. Aktiv/Aktiv-Konfigurationen erfordern jedoch eine komplexe Anwendungsintegration, lastverteilungsfähigen Speicher sowie anspruchsvollere Cluster-Manager.

Welche Alternativen zu dem hier verwendeten Technologie-Stack gibt es?

Für komplexere Anforderungen und höhere Ansprüche existieren Open-Source-Alternativen wie der Cluster-Resource-Manager Pacemaker, welcher die Verwaltung anspruchsvoller Dienst-Abhängigkeiten ermöglicht und oft anstelle von Keepalived eingesetzt wird. Im Storage-Bereich kann DRBD durch skalierbare, verteilte Dateisysteme wie Ceph ersetzt werden. Kommerzielle Alternativen umfassen proprietäre Lösungen wie VMware HA für virtualisierte Umgebungen oder Microsoft Failover Clustering.

Termine vereinbaren
Instagram