DHCP-Failover einrichten: zwei Windows-Server als Paar statt geteilter Bereiche
Was Lastausgleich vom Bereitschaftsmodus unterscheidet, was die maximale Vorlaufzeit für Clients tatsächlich bewirkt und woran die Einrichtung in der Praxis scheitert.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der zweite DHCP-Server steht da und weiß nichts
Die verbreitete Aufteilung sieht so aus: Der erste Server vergibt 80 Prozent des Bereichs, der zweite die restlichen 20 Prozent, meist mit einer Verzögerung, damit er im Normalbetrieb nicht antwortet. Das funktioniert, solange nichts passiert. Fällt der erste Server aus, bedient der zweite die Clients aus seinem kleinen Anteil, und der reicht bei einer üblichen Netzgröße nur für wenige Stunden. Danach bekommen neue Geräte keine Adresse mehr, obwohl im Bereich eigentlich reichlich Platz wäre.
Schwerer wiegt, dass die beiden Server nichts voneinander wissen. Jeder führt seine eigene Lease-Datenbank. Wenn ein Gerät seine Adresse vom ersten Server hat und beim Verlängern beim zweiten landet, kennt der diesen Vorgang nicht und vergibt eine andere Adresse aus seinem Anteil. Für den Client ist das ein Adresswechsel mitten im Betrieb, und alles, was auf der alten Adresse aufsetzt, von Firewall-Regeln bis zu Protokollauswertungen, geht daneben.
Die dritte Schwierigkeit ist die Pflege. Jede Änderung an Optionen, Ausschlüssen oder Reservierungen muss an zwei Stellen von Hand nachgezogen werden, und die beiden Stände laufen mit der Zeit auseinander. Das fällt nicht auf, solange nur der erste Server antwortet. Es fällt genau in dem Moment auf, in dem der zweite einspringt, also im ungünstigsten Augenblick. Eine Failover-Beziehung nimmt euch diese drei Probleme ab, verlangt dafür aber ein paar Festlegungen, die vorher getroffen sein wollen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Ein Befehl, der die ganze Beziehung beschreibt
Der folgende Aufruf legt eine Failover-Beziehung im Lastausgleich an und setzt dabei jeden Wert ausdrücklich, statt sich auf Voreinstellungen zu verlassen. Jeder Bestandteil beantwortet eine eigene Frage, und genau diese Fragen sind es, die in der Konsole schnell überklickt werden.
Der Aufbau
Add-DhcpServerv4Failover -ComputerName dhcp01.contoso.local -PartnerServer dhcp02.contoso.local -Name Standort-Nord -ScopeId 10.10.10.0 -LoadBalancePercent 50 -MaxClientLeadTime 1:00:00 -AutoStateTransition $true -StateSwitchInterval 2:00:00 -SharedSecret <Passphrase> - 01 Das Kommando legt ein eigenes Objekt an, nicht eine Einstellung am Bereich
Add-DhcpServerv4FailoverDer Aufruf erzeugt die Beziehung auf beiden beteiligten DHCP-Diensten gleichzeitig. Die Bereiche, die du angibst, werden dabei vom Quellserver auf den Partner übertragen und dort angelegt, falls sie noch nicht existieren. Du musst also nicht vorher auf beiden Servern denselben Bereich einrichten. Eine Beziehung besteht immer zwischen genau zwei Servern, aber ein Server kann in mehreren Beziehungen stehen.
- 02 Genau ein Partner, und im Cluster der Clustername
-PartnerServer dhcp02.contoso.localMehr als zwei Server lassen sich in einer Beziehung nicht zusammenfassen. Beide müssen mindestens Windows Server 2016 sein. Steht auf einer Seite ein Failovercluster, gibst du hier den Namen oder die Adresse des Clusters an und nicht die eines Knotens. Trägst du einen Knoten ein, geht die Beziehung in den Zustand Kommunikation unterbrochen, sobald der DHCP-Dienst auf einen anderen Knoten wechselt.
- 03 Nur IPv4, und Änderungen wandern nicht von allein mit
-ScopeId 10.10.10.0Failover gibt es ausschließlich für DHCPv4-Bereiche. DHCPv6-Bereiche lassen sich nicht aufnehmen. Der wichtigste Punkt im Alltag steht in der Dokumentation als Warnung: Änderst du später Parameter eines Bereichs, musst du sie von Hand zum Partner replizieren. Die Replikation überschreibt dabei die Einstellungen auf der Gegenseite, du startest sie also immer von dem Server aus, dessen Stand gelten soll.
- 04 Die Aufteilung im Lastausgleich
-LoadBalancePercent 50Der Wert gibt an, welcher Anteil der Anfragen vom lokalen Server bedient wird, der Rest geht an den Partner. Voreingestellt sind 50 Prozent, und jeder Wert von 0 bis 100 ist möglich. Die Zuordnung ist nicht zufällig, sondern folgt einem Hashwert aus der MAC-Adresse der Anfrage nach RFC 3074. Dasselbe Gerät landet dadurch reproduzierbar beim selben Server, solange die Aufteilung unverändert bleibt.
- 05 Die Sicherheitsspanne gegen doppelt vergebene Adressen
-MaxClientLeadTime 1:00:00Voreingestellt ist eine Stunde. Verliert ein Server den Kontakt zum Partner und erneuert er eine Lease, für die eigentlich der Partner zuständig wäre, vergibt er sie nur für diese Zeitspanne und nicht für die volle Lease-Dauer. Erst nachdem die Spanne im Zustand Partner nicht verfügbar abgelaufen ist, übernimmt er den gesamten Adresspool. Sie bestimmt damit, wie schnell ein Ausfall vollständig aufgefangen wird.
- 06 Der Wechsel in den Zustand Partner nicht verfügbar
-AutoStateTransition $true -StateSwitchInterval 2:00:00Von Haus aus steht AutoStateTransition auf $false, der Übergang bleibt also eine bewusste Handlung. Setzt du das Zeitintervall, wird der automatische Wechsel dadurch ohnehin eingeschaltet. Zwei Stunden sind ein brauchbarer Ausgangswert. Zu kurz gewählt reagiert die Beziehung auf jede kurze Störung, zu lang gewählt bleibt der überlebende Server länger als nötig auf seinem Anteil sitzen.
- 07 Nachrichtenauthentifizierung zwischen den Servern
-SharedSecret <Passphrase>Wird das gemeinsame Geheimnis gesetzt, schaltet sich die Authentifizierung der Nachrichten automatisch ein. Ohne den Parameter bleibt sie aus. Weil der Wert bei einer Verwaltung aus der Ferne im Klartext übertragen werden kann, fragt das Kommando standardmäßig nach, was sich mit -Force unterdrücken lässt. In einem Cluster muss das Geheimnis auf allen Knoten hinterlegt werden, dafür gibt es Set-DhcpServerv4Failover.
Wenn es nicht funktioniert
Das siehst du
Der Assistent oder das Kommando bricht mit einem schweren Fehler ab und verlangt, dass die Uhrzeit auf beiden Servern synchronisiert wird.
Warum
Beim Einrichten vergleicht der Vorgang die aktuelle Zeit beider Server. Weicht sie um mehr als eine Minute ab, bricht der Aufbau ab. Der Grund ist nicht Pedanterie: Jede Failover-Nachricht trägt einen Zeitstempel in koordinierter Weltzeit, und die Zustandslogik der Beziehung rechnet mit diesen Zeitstempeln. Ohne gleiche Zeit lassen sich Lease-Zeiten zwischen den Servern nicht sinnvoll abgleichen.
Was hilft
Das siehst du
Die Beziehung steht dauerhaft oder immer wieder im Zustand Kommunikation unterbrochen, obwohl beide Server laufen und sich gegenseitig anpingen lassen.
Warum
Zwei Ursachen sind häufig. Entweder ist die dauerhafte TCP-Verbindung auf Port 647 unterwegs blockiert, etwa durch eine Firewall zwischen zwei Standorten oder weil die beim Installieren der DHCP-Rolle angelegten Regeln nachträglich verändert wurden. Oder auf einer Seite steht ein Failovercluster, und als Partner wurde ein einzelner Knoten eingetragen statt des Clusters. Sobald der DHCP-Dienst auf einen anderen Knoten wechselt, ist der eingetragene Partner nicht mehr erreichbar.
Was hilft
Das siehst du
Ein neuer Ausschlussbereich, eine geänderte Option oder eine neue Reservierung wirkt nur auf einem der beiden Server. Auffallen tut es erst, als der Partner tatsächlich einspringt.
Warum
Die Beziehung gleicht Leases ab, aber nicht laufend die Bereichseinstellungen. Die Bereichsdaten werden beim Anlegen der Beziehung einmal übertragen, und danach nur, wenn ihr eine Replikation ausdrücklich anstoßt. Microsoft weist ausdrücklich darauf hin, dass geänderte Parameter von Hand repliziert werden müssen und dass die Replikation die Einstellungen auf dem Partner überschreibt.
Was hilft
Das siehst du
Beim Versuch, einen DHCPv6-Bereich in die Beziehung aufzunehmen, taucht er in der Auswahl gar nicht erst auf.
Warum
Failover ist ausschließlich für DHCPv4-Bereiche vorgesehen. Für IPv6 ist es nicht umgesetzt, und das hat einen sachlichen Grund: Adapter mit IPv6 bestimmen ihre Adresse meist selbst über die zustandslose Autokonfiguration. Der Server liefert dann nur noch die Optionen und führt gar keinen Lease-Zustand, den man abgleichen müsste.
Was hilft
Das siehst du
Der aktive Server fällt aus, der Partner läuft weiter, trotzdem bekommen die Clients in den Außennetzen keine Adresse mehr. Im Netz der Server funktioniert alles.
Warum
Clients senden ihre erste Anfrage als Broadcast, und Router leiten Broadcasts nicht weiter. In anderen Netzen übernimmt deshalb ein Relay-Agent die Weiterleitung, üblicherweise auf dem Router konfiguriert. Ist dort nur die Adresse des ersten DHCP-Servers eingetragen, erreichen die Clients den Partner überhaupt nicht. Die Beziehung selbst ist dabei völlig in Ordnung, sie hat nur niemanden, der sie fragt.
Was hilft
Das siehst du
Nach einem Wechsel auf den Partner werden die DNS-Einträge der Clients nicht mehr aktualisiert. Die Adressvergabe funktioniert, aber die Namensauflösung zeigt weiter die alten Adressen.
Warum
Wenn der DHCP-Server die dynamische Aktualisierung im Namen der Clients übernimmt, wird er zum Besitzer des jeweiligen DNS-Namens. Ab diesem Moment darf nur noch er selbst diesen Datensatz ändern. Springt der Partner ein und benutzt andere Anmeldeinformationen, scheitert die Aktualisierung an genau diesem Besitzrecht, ohne dass die Adressvergabe darunter leidet.
Was hilft
Fünf Entscheidungen vor der ersten Failover-Beziehung
- 01 Stehen beide Server am selben Standort? Dann Lastausgleich, sonst Bereitschaftsmodus.
- 02 Wie lang ist eure Lease-Dauer? Die maximale Vorlaufzeit muss deutlich darunter liegen.
- 03 Soll der Wechsel in den Zustand Partner nicht verfügbar automatisch erfolgen oder von Hand?
- 04 Erreichen die Clients beide Server, auch über die Relay-Agenten in den anderen Netzen?
- 05 Laufen beide Server auf derselben Zeit, und ist Port 647 zwischen ihnen offen?
Was du vor dem ersten Befehl entscheidest
Die Einrichtung selbst dauert wenige Minuten. Die Entscheidungen darin sind schwer nachträglich zu ändern, deshalb lohnt es sich, sie einmal bewusst zu treffen.
Beziehung statt Bereich denken
Die Failover-Beziehung ist ein eigenes Objekt zwischen genau zwei DHCP-Servern. Ihr ordnet ihr Bereiche zu, nicht umgekehrt. Ein Server kann in mehreren Beziehungen stehen, jede davon mit einem anderen Partner und in einem anderen Modus. Das ist der Hebel für verteilte Standorte: eine Beziehung im Lastausgleich für den Hauptstandort, eine im Bereitschaftsmodus für die Außenstelle.
Lastausgleich oder Bereitschaftsmodus wählen
Im Lastausgleich antworten beide Server gleichzeitig, verteilt über einen Hashwert aus der MAC-Adresse der Anfrage nach RFC 3074. Voreingestellt ist eine Aufteilung von 50 zu 50. Im Bereitschaftsmodus bedient ein Server alle Anfragen, der Partner hält einen Anteil frei und springt erst ein, wenn der aktive Server ausfällt. Lastausgleich passt für zwei Server am selben Standort, der Bereitschaftsmodus für einen Server im Rechenzentrum, der eine Außenstelle absichert.
Die maximale Vorlaufzeit für Clients festlegen
Die Maximum Client Lead Time bestimmt, wie lange ein Server eine Adresse im Alleingang verlängern darf, wenn er seinen Partner nicht erreicht. Voreingestellt ist eine Stunde. Sie ist keine Wartezeit für euch, sondern die Sicherheitsspanne, die verhindert, dass zwei Server dieselbe Adresse zweimal vergeben. Sie sollte deutlich kürzer sein als eure Lease-Dauer.
Entscheiden, ob der Zustandswechsel automatisch laufen soll
Verliert ein Server den Kontakt zum Partner, geht er zunächst in den Zustand Kommunikation unterbrochen. Erst im Zustand Partner nicht verfügbar übernimmt er nach Ablauf der Vorlaufzeit den gesamten Adressraum. Dieser Wechsel ist von Haus aus nicht automatisch. Wenn ihr ihn automatisieren wollt, setzt ihr ein Zeitintervall, nach dessen Ablauf der Wechsel von selbst erfolgt. Das ist bequem und in einem instabilen Netz gefährlich.
Die Verbindung zwischen den Servern absichern
Die beiden Server halten eine dauerhafte TCP-Verbindung auf Port 647. Mit einem gemeinsamen Geheimnis wird die Nachrichtenauthentifizierung eingeschaltet, ohne bleibt sie aus. Nehmt sie mit, denn die Beziehung überträgt vollständige Lease-Informationen. In einem Cluster muss dieses Geheimnis auf allen Knoten von Hand hinterlegt werden.
Die Zeitsynchronisierung vorher prüfen
Die beiden Server müssen auf dieselbe Zeit laufen. Weicht die Uhrzeit beim Einrichten um mehr als eine Minute ab, bricht der Assistent mit einem schweren Fehler ab und verlangt zuerst die Synchronisierung. Im laufenden Betrieb trägt jede Failover-Nachricht einen Zeitstempel, und bei einer Abweichung von mehr als einer Minute protokolliert der empfangende Server ein kritisches Ereignis.
Die Relay-Konfiguration mitziehen
Clients müssen beide Server erreichen können, nicht nur einen. Wenn eure Clients in anderen Netzen sitzen als die DHCP-Server, reicht ein einzelner Relay-Eintrag nicht mehr aus. Es braucht einen Eintrag je Server. Wird das vergessen, funktioniert die Beziehung im Test einwandfrei und versagt genau dann, wenn sie gebraucht wird.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Warum geteilte Bereiche keine gute Antwort mehr sind
Die Aufteilung eines Bereichs auf zwei Server war lange die einzige Möglichkeit, DHCP unter Windows redundant zu betreiben, und sie hat ihre Aufgabe erfüllt. Ihre Schwäche ist nicht die Technik, sondern die fehlende gemeinsame Sicht. Jeder Server führt seine eigene Lease-Datenbank und erfährt nichts über die Vergaben des anderen. Ein Client, der beim Verlängern beim zweiten Server landet, bekommt deshalb eine neue Adresse statt seiner alten, mit allen Folgen für Regeln und Auswertungen, die auf dieser Adresse aufbauen.
Dazu kommt die Rechnung mit dem Adressraum. Wer 80 zu 20 aufteilt, hält auf dem zweiten Server dauerhaft ein Fünftel des Bereichs vor, das im Normalbetrieb ungenutzt bleibt, und im Ausfall trotzdem nicht lange reicht. In Netzen, die ohnehin knapp an Adressen sind, ist das der schmerzhafte Teil. Eine Failover-Beziehung braucht diese Reserve nicht, weil der überlebende Server nach Ablauf der Vorlaufzeit den vollständigen Adressraum übernimmt.
Der dritte Punkt ist die Pflege. Bei geteilten Bereichen existiert derselbe Bereich zweimal, und jede Änderung muss zweimal gemacht werden. Bei einer Failover-Beziehung existiert er ebenfalls auf beiden Servern, aber es gibt einen vorgesehenen Weg, ihn abzugleichen. Dass dieser Abgleich nicht von selbst passiert, ist der wichtigste Merksatz beim Umstieg, und er ist der Grund dafür, dass Failover-Beziehungen im Betrieb trotzdem auseinanderlaufen können.
Lastausgleich oder Bereitschaftsmodus: was wann passt
Der Lastausgleich ist der voreingestellte Modus. Beide Server bedienen dasselbe Netz gleichzeitig, und welcher Server auf eine Anfrage antwortet, entscheidet ein Hashwert aus der MAC-Adresse im Client-Paket. Das Verfahren stammt aus RFC 3074. Aus den eingestellten Prozentwerten ergibt sich für jeden Server ein Bereich von Hashwerten, und jeder Server prüft anhand seines Bereichs, ob er zuständig ist. Weil derselbe Client immer denselben Hashwert erzeugt, ist die Zuordnung stabil.
Der Bereitschaftsmodus ist für die andere Topologie gedacht. Ein Server bedient alle Anfragen, der Partner hält sich zurück und springt nur ein, wenn der aktive Server nicht mehr antwortet. Dafür wird ein Anteil des Adressraums für den Bereitschaftsserver reserviert, voreingestellt sind fünf Prozent. Dieser Anteil ist ausdrücklich für neue Vergaben gedacht. Verlängerungen bestehender Leases beantwortet der Bereitschaftsserver mit derselben Adresse wie zuvor, allerdings zunächst nur für die Dauer der maximalen Vorlaufzeit.
Für die Auswahl gilt eine einfache Faustregel. Stehen beide Server am selben Standort, ist der Lastausgleich die richtige Wahl, weil beide ohnehin gleich gut erreichbar sind. Sitzt ein Server im Rechenzentrum und soll er einen Server in einer Außenstelle absichern, ist der Bereitschaftsmodus passender: Im Normalbetrieb bleibt der Verkehr lokal, und die Leitung zwischen den Standorten wird nur für den Abgleich benutzt. Weil ein Server in mehreren Beziehungen stehen kann, lassen sich beide Muster nebeneinander betreiben, und ein Server kann in einer Beziehung aktiv und in einer anderen Bereitschaftsserver sein.
Was im Ausfall tatsächlich passiert
Verliert ein Server den Kontakt zu seinem Partner, wechselt er in den Zustand Kommunikation unterbrochen. In diesem Zustand beginnt er im Lastausgleich damit, allen Clients Leases zu erteilen, auch denen, die eigentlich dem Partner zugeordnet sind. Kommt eine Verlängerungsanfrage für eine Lease des Partners, verlängert er dieselbe Adresse, aber nur für die Dauer der maximalen Vorlaufzeit. Kommt eine Anfrage von einem Client ohne vorherige Lease, vergibt er aus seinem freien Anteil und greift erst danach auf den Anteil des Partners zu.
Erst der Zustand Partner nicht verfügbar hebt diese Zurückhaltung auf. Der Server wartet dann noch die maximale Vorlaufzeit ab und übernimmt anschließend die Verantwortung für den gesamten Adressraum. Der Sinn dieser Wartezeit ist, dass eine Lease, die der ausgefallene Partner kurz vor dem Ausfall noch vergeben hat und die nicht mehr übertragen wurde, garantiert abgelaufen ist, bevor die Adresse neu vergeben werden kann. Genau davor schützt die Vorlaufzeit, und deshalb ist sie keine Bequemlichkeitseinstellung.
Der Übergang zwischen beiden Zuständen ist die Stelle, an der ihr eine bewusste Entscheidung treffen müsst. Ohne den automatischen Zustandswechsel bleibt der Server im Zustand Kommunikation unterbrochen, bis jemand eingreift. Das ist die sichere Variante, verlangt aber, dass jemand den Zustand überwacht und im Ernstfall verfügbar ist. Mit gesetztem Zeitintervall erfolgt der Wechsel selbsttätig, was in einem stabilen Netz die richtige Wahl ist und in einem Netz mit häufigen kurzen Aussetzern zu unnötigen Übernahmen führt.
Was die Beziehung nicht abdeckt
Failover ersetzt die Absicherung des DHCP-Dienstes über einen Cluster nicht, sondern ergänzt sie. Beide Verfahren lassen sich kombinieren: Ein einzelner Server kann eine Beziehung zu einem Cluster unterhalten, und zwei Cluster können untereinander eine Beziehung bilden. Entscheidend ist dabei, dass immer der Cluster als Partner eingetragen wird und nie ein Knoten, denn sonst bricht die Beziehung bei jedem Wechsel des aktiven Knotens ab.
Ebenfalls nicht abgedeckt ist die richtlinienbasierte Adressvergabe in ihrer vollen Freiheit. Diese Funktion erlaubt es, Clients anhand von Merkmalen wie Herstellerklasse, Benutzerklasse oder MAC-Adresse zu gruppieren und ihnen eigene Adressbereiche und Optionen zuzuweisen. Dadurch entstehen mehrere Adressbereiche innerhalb eines Bereichs. Failover kommt damit zurecht, verteilt die Adressen im Lastausgleich dann aber je Adressbereich, was bei sehr kleinen Bereichen zu unerwarteten Aufteilungen führen kann.
Und schließlich deckt die Beziehung nicht ab, was außerhalb von DHCP passiert. Das betrifft vor allem die dynamische DNS-Aktualisierung, bei der beide Server dieselben Anmeldeinformationen benutzen müssen, und die Erreichbarkeit über Relay-Agenten. Beides sind Konfigurationen an anderer Stelle, beides fällt im Normalbetrieb nicht auf, und beides ist genau im Ausfall entscheidend. Ein Testlauf, bei dem ihr den DHCP-Dienst auf dem aktiven Server bewusst anhaltet und danach in jedem Netzsegment eine Adressvergabe prüft, deckt diese beiden Lücken zuverlässig auf.
Dazu passende Kurse
Wenn ihr die Adressvergabe im Zuge eines Versionswechsels ohnehin anfasst, nehmen Windows-Server-2022-Kurse mit DHCP und DNS im Programm beide Themen im selben Aufbau mit.
Wer die Relay-Konfiguration auf den Routern mitverantwortet, findet in Kurse zu Adressvergabe und Netzdiensten im Rechenzentrum die Grundlagen dazu.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Danke an Trainer Sven, welcher ein sehr detailliertes und fachliches KnowHow besitzt.
Ich beziehe mich hier nur auf die Nachschlung durch Herrn Marco Jachmann. Herr Jachmann ist überaus kompetent und hat alle Inhalte professionell vermittelt.
Sehr sehr gut aufbereitete Nachschulung mit genau dem notwendigen Engagement und der erforderlichen Vorbereitung innerhalb von 48 Stunden.
Häufige Fragen
Können mehr als zwei DHCP-Server in einer Beziehung stehen?
Werden Reservierungen und Optionen automatisch abgeglichen?
Funktioniert DHCP-Failover auch für IPv6?
Wie kurz darf ich die maximale Vorlaufzeit setzen?
Muss ich die Beziehung nach einer Änderung neu starten?
Woran erkenne ich im laufenden Betrieb, dass etwas nicht stimmt?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Windows Server-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Netzdienste einmal von Grund auf sauber aufsetzen
In den Netzwerk- und Windows-Server-Kursen bei cmt richtest du DHCP, DNS und die Zusammenhänge dazwischen selbst ein, und du lässt sie auch einmal absichtlich ausfallen, um zu sehen, was dann tatsächlich passiert.