Windows Server Blog

Deutscher Windows Server Blog mit Beiträgen von Microsoft-Mitarbeitern; Tipps &Tricks für Administratoren zu aktuellen Windows Server-Versionen, allen Server-Rollen und Features.

Hochverfügbarkeit für DHCP: Optionen für Windows Server

Hochverfügbarkeit für DHCP: Optionen für Windows Server

  • Comments 1
  • Likes

Die Vergabe von gültigen IP-Adressen ist eine Grundvoraussetzung für jede Kommunikation in einem Netzwerk und damit eine kritische Komponente jedes IT-Service. In fast allen IT-Infrastrukturen kommt dabei DHCP zum Einsatz. Ob und in welchen Fällen DHCP die beste Lösung ist, bespreche ich in einem eigenen Blog-Artikel; für diesen Artikel gehen wir davon aus, daß ein DHCP-Server verwendet wird. Der wird somit potentiell zu einem ‘Single Point of Failure’ in der IT-Architektur, und eine gut durchdachte Hochverfügbarkeits-Lösung ist unverzichtbarer Bestandteil einer jeden Verfügbarkeits- und Desaster Recovery-Planung.

Bezüglich der Auswirkungen eines Ausfalls des DHCP-Servers auf die Verfügbarkeit der IT-Services muß man zum einen die Funktionsweise des DHCP-Protokolls berücksichtigen und zum anderen zwischen IPv6 und IPv4 unterscheiden.

Funktionsweise des DHCP-Protokolls

Ein DHCP-Client fragt prinzipiell immer bei der Initialisierung des Netzwerk-Protokolls einen DHCP-Server an. Die Initialisierung findet statt im Rahmen eines Neustarts des DHCP-Client und beim Erkennen einer neuen Verbindung (also z.B. beim einstecken des Netzwerkkabels). Die Protokoll-Sequenz ist ziemlich einfach:

DHCP

‘DHCPDiscover’ wird vom Client per Broadcast gesendet (geht ja auch nicht anders – eine IP-Konfiguration ist ja noch nicht verfügbar …) und ggf. von einem Router weitergeleitet. Auf einen Broadcast antworten alle DHCP-Server im Subnet, die eine passende Adresse anzubieten haben, mit ‘DHCPOffer’. Wird die Client-Anfrage dagegen von einem Router weitergeleitet, so geschieht das in der Regel unter Verwendung einer statischen IP-Adresse des DHCP-Servers, und es antwortet dann natürlich auch nur dieser eine DHCP-Server.

Neben der Initialisierung des Netzwerk-Protokolls ist die Reservierungs-Dauer der IP-Konfiguration wichtig. Der DHCP-Server gibt diese als Attribut der IP-Konfiguration dem Client mit; festgelegt wird sie vom DHCP-Administrator. Jeder DHCP-Client fängt mit Ablauf der Hälfte der Reservierungs-Dauer an, einen DHCP-Server zu kontaktieren, um die Reservierung zu verlängern. Gelingt das nicht, verfällt die IP-Konfiguration nach Ablauf der Reservierungsdauer.

Ist ein DHCP-Server nicht verfügbar, dann wird ein DHCP-Client in folgenden Fällen keine gültige IP-Konfiguration erhalten:

  • Neustart des Client-Computers
  • Neue Verbindung zum Netzwerk (z.B. Netzwerk-Kabel abgezogen und wieder eingesteckt, Notebook ab- und wieder angedockt, aufwachen aus dem Stand-By)
  • Reservierungs-Dauer der IP-Konfiguration abgelaufen

Das bedeutet: wenn der DHCP-Service ausfällt, bricht die Kommunikation im Netzwerk nicht gleich zusammen, man muß jedoch damit rechnen, daß sich die Supportanfragen um so mehr häufen, je länger der Dienst nicht verfügbar ist.

Hochverfügbarkeits-Optionen: Sicherung der DHCP-Konfiguration (Cold Stand-By)

Eine der am wenigsten aufwändigen Methoden, um die Verfügbarkeit des DHCP-Dienstes sicherzustellen, ist ein ‘Cold Stand-By’. Nach ITIL heißt das: es ist zwar ein Server verfügbar, der den DHCP-Dienst jederzeit übernehmen könnte, dieser ist jedoch in keiner Weise dafür konfiguriert. Man sichert lediglich die DHCP-Konfiguration in regelmäßigen Abständen und testet die Wiederherstellung dieser Konfiguration auf einem anderen Server. Randbemerkung: Ist überhaupt kein anderer Server im Netzwerk verfügbar, dann ist der Ausfall des DHCP-Dienstes ohnehin ihr geringstes Problem … ;-)

Die Sicherung der DHCP-Konfiguration kann manuell erfolgen (in der DHCP-Konsole gibt es eine Backup-Funktion im Kontext-Menü des DHCP-Servers), oder automatisiert per Skript. Dafür bietet sich ‘netsh’ an: ‘netsh dhcp server backup ?’ zeigt die gültige Syntax an.

Für die Wiederherstellung des Dienstes muß dann jeweils entschieden werden, ob man den ursprünglichen DHCP-Server benutzt und z.B. neu installiert, oder ob man irgendeinen anderen Server verwendet. Auf diesem kann dann die statische IP-Adresse des ursprünglichen Servers zusätzlich gebunden werden, die DHCP-Rolle ist zu installieren und die DHCP-Konfiguration ist wiederherzustellen. Alles in allem sollte das in 15-30 Minuten erledigt sein.

Kritisch ist hier eher die Frage, woran man merkt, daß der DHCP-Dienst ausgefallen ist. Wird der nicht überwacht (z.B. mit dem System Center Operations Manager), dann ist der erste Hinweis ein Anruf eines Benutzers beim Helpdesk … und dann können 15-30 Minuten schon wieder zu viel sein.

Hochverfügbarkeits-Optionen: Warm Stand-By

Geht man davon aus, daß ein Ausfall des DHCP-Servers die häufigste Ursache für einen Ausfall des DHCP-Dienstes ist, dann ist es naheliegend, sich mit Hilfe einer alternativen Server-Instanz dagegen abzusichern. Server gibt es in den meisten Infrastrukturen mehr als genug, und da DHCP als Dienst nicht allzuviel Last erzeugt, kann man die Rolle theoretisch jedem beliebigen Server als ständig laufende Komponente hinzufügen. Allerdings dürfen aktive DHCP-Scopes sich nicht überlappen! Ein guter Kompromiss ist ein ‘Warm Stand-By’: komplett konfiguriert, aber passiv, und mit sehr wenig Aufwand jederzeit aktivierbar. Das bedeutet: wir konfigurieren auf einem alternativen DHCP-Server Kopien aller DHCP-Scopes und lassen diese deaktiviert. Um Fehler zu vermeiden, sollten die Konfiguration und der periodische Abgleich automatisiert per Skript erfolgen (siehe dazu den Abschnitt ‘Cold Stand-By’). Die Aktivierung kann dann manuell erfolgen, oder man integriert diesen Vorgang in die Systemüberwachung (z.B. mit dem System Center Operations Manager) und triggert die Aktivierung per Skript.

Zu bedenken sind die folgenden Punkte:

  • IP-Adresskonflikte: Ein DHCP-Client wird immer versuchen, seine bestehende Konfiguration zu erneuern. Der alternative DHCP-Server kennt die bereits vergebenen Adressen jedoch nicht vollständig, da seit der letzten Sicherung und Wiederherstellung ggf. einige Zeit vergangen ist, und wird daher evtl. eine bereits aktive Adresse erneut vergeben. Um dies zu vermeiden, sollte man die Prüfung der Adressen aktivieren. Das macht man in der DHCP-Konsole in den IPv4-Optionen (dort ‘Eigenschaften’ - ‘Erweitert’). Der DHCP-Server prüft dann pro Anfrage bis zu fünf Adressen per Ping und markiert diese ggf. als belegt.
  • Statische Adresse des DHCP-Servers: Werden DHCP-Anfragen aus anderen Subnets über die Router weitergeleitet, dann zeigen die Router-Konfigurationen auf eine statische IP-Adresse, nämlich die des primären DHCP-Servers. Bei einem Failover muß dann entweder die Router-Konfiguration geändert werden, oder (wesentlich einfacher) die statische IP-Adresse an den sekundären Server gebunden werden.

Hochverfügbarkeits-Optionen: Failover Clustering

DHCP ist eine der bereits vordefinierten Rollen des Windows Failover Clusters. Die administrativ einfachste Art, sich gegen einen Ausfall des DHCP-Servers zu sichern, ist daher die Integration in einen Cluster – es sei denn, man hat in seiner Infrastruktur noch keinerlei Cluster zur Verfügung. Einzig und allein für DHCP einen Cluster aufzusetzen ist zwar relativ einfach (Shared Storage ist dafür nicht nötig!), bedingt jedoch ein Training der Administratoren für den Failover Cluster. Aber vielleicht möchten Sie ja bei dieser Gelegenheit die Hochverfügbarkeit weiterer Dienste konfigurieren und dafür den Failover Cluster ebenfalls benutzen … ;-)

Diese Option ist eine Kreuzung aus Warm Stand-By und Hot Stand-By: Einerseits ist die DHCP-Konfiguration und auch die Liste der aktiven Adressen auf jedem Cluster-Knoten stets verfügbar und aktuell und mit sehr geringer zeitlicher Verzögerung aktivierbar (also fast Hot Stand-By), andererseits ist eben auch nur eine Instanz der DHCP-Konfiguration vorhanden. Wird die DHCP-Konfiguration korrumpiert, dann bietet der Cluster keine Möglichkeit mehr, diese wieder zu korrigieren. Zusätzlich zum Einsatz des Clusters sollte daher auf jeden Fall eine regelmäßige Sicherung (siehe ‘Cold Stand-By’) vorgenommen werden.

Hochverfügbarkeits-Optionen: Split Scope (Hot Stand-By)

Neu in Windows Server 2008 R2 ist die Option ‘Split Scope’. Damit teilt man einen DHCP-Scope auf zwei DHCP-Server auf. Einer der Server antwortet optional verzögert auf DHCP-Anfragen, so daß zunächst die verfügbaren IP-Adressen des anderen Servers vergeben werden. Dann würde man z.B. 80% der Adressen des Scopes auf den Server legen, der ohne Verzögerung antwortet. Man kann aber auch problemlos je die Hälfte der Adressen auf einen der Server legen und die Verzögerung der Antwort deaktivieren. Dann antworten beide Server gleichzeitig, aber der DHCP-Client reagiert nur auf eine der Antworten, so daß auch nur eine Adresse von einem der DHCP-Server vergeben wird. Meine Empfehlung ist, auf jeden Fall die Verzögerung der Server-Antwort zu konfigurieren, denn aufgrund der physikalischen Netzwerkkonfiguration werden die beiden DHCP-Server ohnehin fast nie wirklich gleichzeitig antworten. Einer (immer der gleich) wird meist früher reagieren, und die gleichmäßig aufgeteilten Scopes werden eben nicht gleichmäßig verwendet werden. Da macht es dann mehr Sinn, das Verhalten der Server mit Hilfe der Antwort-Verzögerung bewußt zu steuern.

Mit freundlichen Grüßen!

Ralf M. Schnell

Comments
  • Hallo Herr Schnell,

    wie funktioniert denn der DHCP Failover Cluster ohne Shared Storage? Das müsste ja ähnlich dem von Exchange 2007 bekannten CCR funktionieren. Gibt es dazu irgendwo eine Beschreibung?

    Beste Grüße

    Oliver

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment