DHCP Failover mit Windows Server 2012 24. Mai 2012

Der DHCP Serverdienst ist eine Kernkomponente eines jeden Netzwerkes. Deshalb ist gerade auf diesen Dienst ein besonderes Augenmerk zu legen. Um die Ausfallsicherheit des DHCP Dienstes zu gewährleisten, gab es bis Windows Server 2008 R2 mehrere Möglichkeiten:

  1. Aufsplitten der IP Bereiche auf mehrere Server (80/20 Regel)
  2. Einsatz von Failoverclustering

Beide Möglichkeiten hatten ihre Nachteile. Die 80/20 Regel war eher umständlich zu verwalten und das Failover Clustering verursachte hohe Kosten, da es erst ab der Enterprise Edition verfügbar war. Mit Windows Server 2008 führte Microsoft einen Assistenten ein, der es ermöglichte, einen Bereich zwischen zwei DHCP Servern aufzuteilen. Das machte zumindest die Verwaltung der 80/20 Regel schon etwas einfacher. Mit Windows Server 2012 bietet Microsoft jetzt eine neue Möglichkeit, mit welcher man den DHCP Serverdienst auch ohne größere Umstände hochverfügbar auslegen kann. Die Internet Engineering Task Force hat sich bereits im Jahr 2003 darüber Gedanken gemacht und die Möglichkeiten beschrieben, wie eine Lösung aus zwei unabhängigen Servern arbeiten muss, damit eine Ausfallsicherheit des DHCP Serverdienstes realisiert werden kann. Microsoft implementiert diese Vorschläge mit dem Feature DHCP Failover in Windows Server 2012. Die Installation bzw. die Konfiguration des Features ist fast selbsterklärend. Wichtig für den erfolgreichen Einsatz von DHCP Failover ist, dass beide Server über die gleiche Sytemzeit verfügen und sich beide Server über den Port 647/TCP erreichen können. Nachdem auf beiden zukünftigen DHCP Servern der Dienst installiert und autorisiert wurde, kann auf dem zukünftigen primären DHCP Server der IP Bereich eingerichtet werden. Nachdem der IP Bereich inklusive der Optionen eingerichtet wurde, kann über das Kontextmenü des Bereichs das Failover eingerichtet werden.

Im nächsten Dialogfenster hat man nun die Qual der Wahl. Microsoft bietet für das DHCP Failover zwei Modi an. Das DHCP Failover kann man als “Loadbalancing” oder auch als “Hot Standby” Lösung bereitstellen. Die Option “Hot Standby” ist für Umgebungen gedacht, in denen ein zweites Rechnenzentrum existiert und der zweite DHCP Server dort untergebracht wurde. Die Option “Hot Standby” lässt sich auch gut einsetzen, wenn Filialen existieren in denen nur ein einzelner Server installiert ist. Dort könnte man den DHCP Bereich der Filiale auf dem DHCP der Zentrale verfügbar auslegen. Die Option “Loadbalancing” wird eingesetzt, wenn sich beide DHCP Server im gleichen physischen Subnetz befinden. Als Erstes demonstriere ich die Konfiguration im “Hot Standby” Modus.

Die konfigurierbaren Werte bedeuten im Einzelnen:

Addresses reserved for standby Server: Dieser Prozentsatz an IP-Adressen wird für den sekundären DHCP Server reserviert. Wenn die Verbindung zwischen dem primären DHCP Server und dem sekundären DHCP Server unterbrochen wird, verteilt der sekundäre DHCP Server an DHCP Clients die IP-Adressen aus dem reservierten Bereich.

Maximum Client Lead Time: Bei einem Ausfall werden die DHCP Leases nur temporär ausgegeben. Die Leasedauer entspricht der “Maximum Client Lead Time”. Bei einem Ausfall (Status: Partner Down) wird dieser Zeitraum abgewartet, bis der Server die volle Kontrolle über den IP Bereich übernimmt.

Auto State Switchover Interval: Diesen konfigurierbaren Zeitraum wartet der sekundäre DHCP Server ab, bis es zum Failover kommt bzw. der sekundäre DHCP Server davon ausgeht, dass der primäre Server “Down” ist.

Enable Message Authentication: Der Datenaustausch zwischen den beiden DHCP Servern sollte authentifiziert erfolgen, damit kein Dritter den beiden DHCP Servern gefälschte Statusmeldungen unterschieben kann. Das “Shared Secret” kann frei gewählt werden und wird bei der Einrichtung vom primären DHCP Server auf den sekundären DHCP Server übertragen.

Nachdem das Failover eingerichtet wurde, kann man im Ereignisprotokoll der Server folgende Meldung sehen:


Eintrag auf dem primären Server


Eintrag auf dem sekundären Server

In den Eigenschaften des Bereichs wird eine neue Registerkarte verfügbar, in der man den Status einsehen kann.

Den Zustand des Bereichs kann man sich auch über die Powershell mit dem cmdlet “get-dhcpserverv4failover” anzeigen lassen.

Wenn es jetzt zu einem Ausfall des primären DHCP Servers kommt, wird das vom sekundären Server registriert. Das kann man sehr schön mit der Powershell beobachten.

Nach dem von mir konfigurierten “Auto State Switch Interval”, wechselt der Server in den Modus “PartnerDown”. Er übernimmt also jetzt die volle Kontrolle über den Bereich und geht nicht mehr davon aus, dass der Ausfall des primären Servers durch einen kurzzeitigen Netzwerkausfall hervorgerufen wurde.

Auf der Clientseite sieht man jetzt, dass die Leasedauer auf eine Stunde (Maximum Client Lead Time) begrenzt ist. Zusätzlich kann man in dem Screenshot erkennen, dass der sekundäre Server nur aus dem 5% Bereich, der reserviert wurde, die Adressen verteilt. Der Bereich fängt normalerweise bei 192.168.2.200 an. Wenn der primäre Server länger offline ist (“Auto State Switch Interval” + “Maximum Client Lead Time”), verteilt der sekundäre Server IP-Adressen aus dem gesamten Bereich. Als Leasedauer wird aber nur die “Maximum Client Lead Time” vergeben und nicht die konfigurierte Leasedauer des entsprechenden Bereichs.

Wenn der primäre Server wieder verfügbar ist, wechselt der sekundäre Server wieder in den Status “Normal” und gleicht die Datenbank mit dem primären Server ab. Wenn die Clients nach dem Ablauf der “Maximum Client Lead Time” versuchen die Lease zu erneuern, wird die Anfrage vom primären Server beantwortet. Dabei bekommen die Clients jetzt auch die Leasedauer des entsprechenden Bereichs mit übergeben.

DHCP Server Loadbalancing

Die Einrichtung des “Loadbalancing” ist ähnlich dem des “Hot Standby” Modus bis auf folgende Dialogseite:

Durch diese Einstellung werden die Clientanfragen auf beide DHCP Server verteilt. Der primäre Server vergibt bei der Einrichtung an seinen sekundären Server sogenannte “Hash Buckets”. Das sind Bereiche bzw. Hashs von möglichen MAC Adressen, die in einem DHCP Request auftreten können. Wenn jetzt ein DHCP Request bzw. DHCP Discover von einem DHCP Server empfangen wird, hasht er die MAC Adresse des anfragenden Clients. Wenn der generierte Hash in seinem “Hash Bucket” mit enthalten ist, antwortet er auf die Anfrage, andernfalls überlässt er die Arbeit seinem Partner. Die genaue Funktion ist in diesem Dokument beschrieben.

 

2 Comments
Sebastian Röhner Januar 11th, 2013

Vielen Dank für die sehr gute Erklärung!

Peter Weber April 30th, 2015

Hi,

gut erklärt.

Nur was passiert wenn der primäre DHCP nicht mehr wieder kommt und der sekundäre DHCP alleine weiter arbeiten muss.

Wie kann ich den primären DHCP als alleinigen DHCP umkonfigurieren.

Der primäre DHCP ist nicht mehr erreichbar.

Danke dir

LG Peter

Leave a Reply

*