XPLN/Lernbereiche

E04 · Windows Server 2025 / Kea 3.0.2

Hochverfügbarkeit und Failover

Kapitel in dieser Lernstufe

Das lernst du

  • Split-Scope, Windows-Failover und Kea-HA unterscheiden.
  • Partition, Partnerausfall, Synchronisierung und Wiederaufnahme planen.

Voraussetzungen: F03 · Mehrere Server und AngeboteF05 · T1, T2 und Lease-AblaufF10 · Windows Server praktisch einrichtenF11 · Linux und Kea praktisch einrichten

Redundanz soll einen Dienstausfall begrenzen, ohne neue Doppelvergaben zu erzeugen. Zwei erreichbare Server allein erfüllen diese Anforderung nicht.

MCLT
Maximum Client Lead Time: Beim Windows-DHCP-Failover begrenzt sie die Verlängerung einer Lease gegenüber dem dem Partner bekannten Stand. Sie ist nicht mit der gewöhnlichen Lease-Dauer gleichzusetzen.

Zwei Arten von Übereinstimmung

Lease-Abgleich ≠ KonfigurationsabgleichDHCP01DHCP02LEASES · automatisch synchronisiert.120 → PC07.120 → PC07DNS-OPTION · separate Replikation erforderlich.20.10.20.11Gleiche Zuordnungen, trotzdem verschiedene Parameter.
Grafik vergrößern
Lease-Abgleich ≠ KonfigurationsabgleichDHCP01DHCP02LEASES · automatisch synchronisiert.120 → PC07.120 → PC07DNS-OPTION · separate Replikation erforderlich.20.10.20.11Gleiche Zuordnungen, trotzdem verschiedene Parameter.
Windows-DHCPv4-Failover synchronisiert Lease-Daten. Geänderte Scope-Einstellungen müssen gesondert repliziert werden. Identische Leases können deshalb neben unterschiedlichen DNS-Optionen existieren. Das Bild zeigt Konfigurationsdrift, keinen Ausfall des Lease-Abgleichs.

Drei unterschiedliche Ansätze

Split-Scope teilt Adressmengen disjunkt auf. Die Server kennen die Leases des anderen nicht automatisch. Windows-DHCP-Failover synchronisiert dagegen Leaseinformationen zwischen zwei Partnern eines DHCPv4-Bereichs. Load Balance verteilt Verantwortung; Hot Standby hält einen Partner vorwiegend als Reserve bereit.

Kea-HA verwendet die libdhcp_ha-Hookbibliothek mit eigener Konfiguration, Kommunikation und Zustandslogik. Load-balancing und hot-standby sind dort ebenfalls Begriffe, aber nicht dasselbe Produktprotokoll wie Windows-Failover. Die Hookunterstützung für DHCPv4 und DHCPv6 ist separat von Windows zu betrachten. Im Kea-Load-Balancing müssen Pools zwischen HA-Serverklassen aufgeteilt werden; identische unbeschränkte Pools auf beiden Partnern sind keine gültige Übertragung des Windows-Beispiels. Hot Standby hat einen primären Vergabepfad.

Zeit, Zustände und Konfigurationsdrift

Eine Kommunikationsunterbrechung zwischen Partnern beweist nicht, dass einer ausgefallen ist. Beide könnten noch Clients erreichen. Ein vorschnelles manuelles Umschalten auf volle Verantwortung kann daher gefährlich sein. Windows unterscheidet unter anderem NORMAL, COMMUNICATIONS INTERRUPTED und PARTNER DOWN; weitere Recoveryzustände begleiten die Wiederherstellung.

MCLT (Maximum Client Lead Time) begrenzt, wie weit ein Partner eine Lease über den dem anderen bekannten Stand hinaus verlängern darf. Sie ist weder die normale Lease-Dauer noch pauschal die Zeit bis jeder Client ausfällt. Übergänge und Übernahmefristen müssen im Zusammenhang mit Modus und Zustand geprüft werden.

Windows synchronisiert Leases im Betrieb, Scope-Konfigurationsänderungen müssen dagegen gezielt zum Partner repliziert werden. Bei unterschiedlichen Betriebssystemständen empfiehlt Microsoft, Änderungen von der neueren Version aus zu replizieren. Windows-DHCP-Failover gilt nur für DHCPv4-Scopes; Kea-HA und DHCPv6 müssen nach ihrer eigenen Dokumentation bewertet werden.

Wiederherstellung als Teil der Abnahme

Nach Rückkehr eines Partners erst Zustand und Lease-Abgleich beobachten. Nicht beide Server blind mit veralteten Sicherungen starten. Konfiguration, Partnerkommunikation, Clientpfad zu beiden Servern und Zeitbasis kontrollieren. Ein Ausfalltest endet erst, wenn auch die Rückkehr ohne Doppelvergabe belegt ist.

Dienstfehler und Netzpartition getrennt testen

Stoppt ein DHCP-Dienst, kann der Partner gegebenenfalls erkennen, dass keine Antworten mehr kommen. Bei einer Netzpartition ist die Lage schwieriger: Die Partner erreichen einander nicht, können aber jeweils noch Clients versorgen. Wenn beide vorschnell die vollständige Verantwortung übernehmen, wird aus Verfügbarkeit ein Konsistenzproblem. Ein HA-System benötigt deshalb Regeln darüber, welcher Bestand wann sicher verwendet werden darf.

Ein Testplan sollte mindestens vier Fälle enthalten: normaler Betrieb, einzelner Dienststillstand, unterbrochene Partnerkommunikation bei erhaltenem Clientpfad und Rückkehr eines Partners. Beobachte jeweils neue Vergaben und Erneuerungen getrennt. Ein Client mit einer acht Stunden gültigen Lease kann während des gesamten kurzen Tests funktionieren, ohne jemals die Übernahmefähigkeit des Partners zu beanspruchen.

Datenabgleich und Konfigurationsabgleich nachweisen

Lease-Daten beantworten, wer eine Adresse bis wann nutzen darf. Konfiguration beschreibt dagegen Pools, Optionen und Auswahlregeln. Ein Paar kann beim ersten Bestand übereinstimmen und beim zweiten auseinanderlaufen. Dann erhalten Clients je nach antwortendem Partner verschiedene DNS-Werte, obwohl keine doppelte Adresse vergeben wird. Die Prüfung muss beide Konsistenzarten erfassen.

Nach einer Wiederaufnahme vergleichst du Partnerzustände, Leasezuordnungen und effektive Scopewerte. Bei Windows gelten dessen MCLT- und Replikationsregeln; Kea verwendet die Zustandslogik seines HA-Hooks. Übertrage daher weder Zustandsnamen noch Wartefristen ungeprüft zwischen den Produkten. Erst der kontrollierte Übergang zurück zum vorgesehenen Normalbetrieb schließt den Ausfalltest ab.

DURCHGEARBEITETES BEISPIEL

Büro mit zwei Windows-Partnern

  1. DHCP01=.20.10 und DHCP02=.20.11. Beide müssen durch Relay und Firewall erreichbar sein; Partnerkommunikation benötigt zusätzlich TCP 647.
  2. Load Balance für Scope .10.0 einrichten. Neue Clients und Erneuerungen protokollieren; Scopeänderung kontrolliert replizieren.
  3. Nur im isolierten Labor Partnerdienst stoppen. Bestehende Leases, neue Clients, Partnerzustand und MCLT-bezogene Übergänge getrennt beobachten.
  4. Dienst wieder starten, Synchronisierung und Normalzustand abwarten. Danach beide Leaseansichten auf widersprüchliche Zuordnungen prüfen.

Ergebnis: Ein erfolgreiches Ping auf den zweiten Server ist kein HA-Test. Vergabe, Erneuerung, Zustandsübergänge und Wiederaufnahme müssen belegt werden.

Typische Fehler

  • Konfigurationsreplikation und Lease-Synchronisierung sind nicht identisch.
  • Eine Netzpartition ist nicht automatisch ein nachgewiesener Partnerausfall.
  • Windows-Failover nicht als DHCPv6-Funktion ausgeben.

Praktisch anwenden

Offizielle Quellen

Versionsbezüge geprüft am 14. Oktober 2026. Produktkonfigurationen werden im jeweiligen isolierten Labor validiert.