Ausfallsicherheit für DHCP-Server unter Windows
Kein Anschluss unter dieser Nummer?
Die Vergabe von IP-Adressen in Unternehmen erfolgt meist per DHCP. Allerdings machen sich die wenigsten Systemverwalter über die Ausfallsicherheit Gedanken. Dabei hat der Ausfall eines DHCP-Servers für ein Unternehmen oft erhebliche Auswirkungen. Erhalten Arbeitsstationen oder gar Serverrechner keine IP-Adresse mehr, ist der Netzbetrieb schnell lahmgelegt. Der Beitrag zeigt, welche Wege es gibt, DHCP-Server ausfallsicher zu konfigurieren. Obwohl der Fokus auf Windows-Servern liegt, gelten zahlreiche Aspekte auch für DHCP-Server unter Linux.
Die DHCP-Funktionalität (Dynamic Host Configuration Protocol) ist seit Windows 2000 Server Cluster-fähig. Dies gilt natürlich auch für Windows Server 2003/2008. Durch die Einführung eines Clusters erhält jedes Unternehmen einen hervorragenden Ausfallschutz der DHCP-Server. Allerdings besteht der große Nachteil dieser Lösung in den erheblichen Kosten und der recht komplizierten Verwaltung. Aus diesem Grund setzen nur sehr wenige Unternehmen einen Cluster ausschließlich für DHCP ein. Meistens halten andere Lösungen in Unternehmen Einzug, um die Ausfallsicherheit von DHCP-Servern zu gewährleisten.
Diese Aufgabe gestaltet sich leider etwas schwieriger als zum Beispiel bei DNS (Domain Name System) oder bei Domänen-Controllern. Während sich DNS- und Active-Directory-Daten problemlos zwischen Servern replizieren lassen, ist eine solche Technik in DHCP nicht integriert. Aufgrund der laufenden und schnellen Änderungen in der DHCP-Datenbank ist eine Replikation zwischen zwei DHCP-Servern nicht möglich, da während eines Replikationsvorgangs bereits ein weiterer Client eine IP-Adresse anfordern könnte, die der andere DHCP-Server soeben vergeben hat. Die Folge wäre ein IP-Adresskonflikt.
Der häufigste Weg, um eine Ausfallsicherheit herzustellen, besteht darin, dass Systemverwalter den verfügbaren IP-Adress-Pool im Unternehmen auf verschiedene Server aufteilen. Jeder DHCP-Server erhält in diesem Fall einen eigenen Bereich von IP-Adressen, der sich nicht mit dem anderer DHCP-Server überlappen darf. Den kompletten Adress-Pool aufzuteilen, ist aber nur dann sinnvoll, wenn im Ernstfall ein Server allein alle Computer mit IP-Adressen versorgen könnte. Eine weitere Möglichkeit ist, auf allen Servern einen Bereich zu konfigurieren, der den gesamten Adress-Pool enthält. Auf jedem Server hinterlegt dann der Systemverwalter in der DHCP-Konfiguration als "Ausnahmen" diejenigen IP-Adressen, die die anderen DHCP-Server im Unternehmen verteilen sollen. Fällt ein DHCP-Server aus, lassen sich diese Ausnahmen problemlos entfernen und die noch laufenden Server übernehmen die Aufgaben des ausgefallenen Servers.
Allerdings müssen bei dieser Lösung auch die so genannten Reservierungen auf den Servern ihre Berücksichtigung finden. Diese lassen sich für jeden DHCP-Bereich getrennt auf dem Server festlegen. Benötigt zum Beispiel eine bestimmte Arbeitsstation immer dieselbe IP-Adresse und erhält sie diese per DHCP, spielen Reservierungen eine wichtige Rolle. Aus diesem Grund müssen auf allen DHCP-Servern, die als DHCP-Bereiche identische Adress-Pools haben, auch alle nötigen Reservierungen hinterlegt sein. Dadurch ist sichergestellt, dass jeder beteiligte DHCP-Server alle Reservierungen kennt und an die entsprechenden Clients zuweisen kann.
Erhalten diese Clients nicht die IP-Adresse, die als Reservierung vorgesehen ist, sondern durch den Ausfall eines DHCP-Servers eine andere Adresse, kann dies zu Problemen führen - etwa beim Netzwerkzugriff direkt über die IP-Adresse. Aber auch dann, wenn der Zugriff nicht über die IP-Adresse sondern über den DNS- oder NetBIOS-Name erfolgt, kann es durchaus einige Zeit dauern, bis alle WINS- und DNS-Server oder lokale Konfigurationen wie HOST- und LMHOST-Dateien und vor allem die verschiedenen Zwischenspeicher auf den Servern und Arbeitsstationen mit der neuen IP-Adresse aktualisiert sind. Daher ist es beim Einsatz von Reservierungen sehr wichtig, diese Komponente bei der Ausfallplanung zu berücksichtigen und bereits rechtzeitig festzulegen, was passieren soll, wenn der DHCP-Client nicht seine vorgesehene IP-Adresse erhält. Eine Alternative ist in diesem Fall natürlich auch die Vergabe von statischen IP-Adressen, anstatt mit Reservierungen zu arbeiten.
Standbyserver mit manueller Umschaltung
Ein weiterer Weg zur Herstellung der Ausfallsicherheit besteht darin, einen Standbyserver für den produktiven DHCP-Server zu konfigurieren. Dieser Weg funktioniert aber erst ab Windows Server 2003/2008. Windows 2000 Server enthält noch nicht die dazu notwendigen Funktionen. Die Umschaltung kann bei diesem Weg jedoch nur manuell erfolgen, ein Automatismus ist nicht möglich. Der Vorteil dieser Lösung ist jedoch der relativ günstige Preis im Vergleich zur gewonnenen hohen Ausfallsicherheit. Grundlage für einen Standby-DHCP-Server ist die Möglichkeit, DHCP unter Windows Server 2003/2008 mit dem Befehl "netsh" zu konfigurieren. Dadurch lassen sich alle notwendigen Maßnahmen in einer Batch-Datei zusammenfassen. Die Ausführung erfolgt manuell oder per geplanten Task. Mit der Batch-Datei ist es möglich, die Sicherung des aktiven Servers auf den Standby-DHCP-Server zu übertragen - und dies regelmäßig. Die Batch-Datei verwendet dazu die Option "export" von "netsh". So lassen sich alle aktuellen Konfigurationen und DHCP-Leases erfassen und auf den Backup-DHCP-Server kopieren.
Der zweite DHCP-Server ist im Active Directory nicht autorisiert, vergibt also keine IP-Adressen an die Clients, bis der Systemverwalter dies will. Fällt der primäre Server aus, muss seine Autorisierung nur noch aufgehoben und der Datenaustausch deaktiviert werden. Im Gegenzug autorisiert der Systemverwalter den Backupserver, der mit der aktuellsten Konfiguration seine Arbeit beginnt und IP-Adressen verteilt. Eine umfangreiche Anleitung sowie Beispielskripte für diese Vorgehensweise sind auf der Internetseite "
www.faq-o-matic.net/2004/10/26/wie-kann-man-einen-dhcp-server-unter-windows-ausfallsicher-gestalten" zu finden.
Ausfallsicherheit durch Konflikterkennung
Als praktisch hat sich die Funktion der Konflikterkennung erwiesen, bei der ein DHCP-Server zunächst versucht, einen Verbindungsaufbau mit der IP-Adresse zu bewerkstelligen, die er als nächste vergeben will. Erhält er darauf keine Antwort, ist die Adresse unbenutzt und steht für den nächsten Client zur Verfügung. Existiert bereits ein Client mit dieser IP-Adresse, verwendet der Server einfach die nächste Adresse aus seinem IP-Bereich. Sind im Unternehmen mehrere DHCP-Server im Einsatz, so empfiehlt es sich bei dieser Methode, alle mit den exakt gleichen Bereichen aus einem identischen Adress-Pool zu konfigurieren. Die Konflikterkennung stellen Systemverwalter in den Eigenschaften des Servers auf der Registerkarte "Erweitert" ein. Standardmäßig ist diese auf "0" gesetzt und damit nicht aktiv. Durch das Abändern dieses Werts auf "1" oder "2" aktivieren die Server die Konflikterkennung, und die Gefahr der Vergabe gleicher IP-Adressen besteht nicht mehr.
Der einzige Nachteil dieser Methode ist, dass sich die Dauer der Adressvergabe etwas erhöht. Dies stellt aber normalerweise kein Problem dar, vor allem angesichts der Tatsache, dass sich dadurch die Ausfallsicherheit deutlich verbessern lässt. Zu beachten ist dabei aber auch, dass alle eingesetzten DHCP-Server von der Hardware her so ausgestattet sind, dass sie den Ausfall eines Servers abfangen können. Dazu zählen neben CPU- und Speicherausstattung auch eine entsprechend leistungsfähige Netzwerkanbindung. Am besten sind in einem DHCP-Server mehrere Netzwerkkarten integriert, die sich die Last teilen. Für jeden zusätzlichen Konflikterkennungsversuch des DHCP-Dienstes, verzögert sich die Adressvergabe um einige Sekunden. Aus diesem Grund sollte die Anzahl der Konflikterkennungsversuche zwei Versuche nicht übersteigen.
Ausfallsicherheit mit der 80/20-Regel
Eine weitere Strategie der Ausfallsicherheit für DHCP-Server ist die 80/20-Regel. Sie ähnelt der Variante, den verfügbaren Adress-Pool auf mehrere Bereiche aufzuteilen. Hier verwaltet ein DHCP-Server 80 Prozent der Adressen des Adress-Pools, und ein zweiter Server die restlichen 20 Prozent. Die IP-Adressen dürfen sich in diesem Fall nicht überlappen. Fällt ein Server aus, kann der zweite Server zumindest teilweise übernehmen. Idealerweise ist der zweite Server so ausgestattet, dass er im Notfall alle Clients mit IP-Adressen versorgen kann. Diese Variante ist zum Beispiel auch beim Einsatz mehrerer Subnetze denkbar. Auch hier lassen sich die Adressen aus den verschiedenen Subnetzen im Verhältins 80 zu 20 auf verschiedene Server aufteilen. Allerdings muss bei der Methode der primäre Server so schnell wie möglich wieder funktionieren, damit dem Backupserver nicht die IP-Adressen ausgehen.
Wenn ein DHCP-Server als Versorgungssystem ausfällt, muss nicht immer das Betriebssystem oder die Hardware schuld sein. Es besteht auch die Möglichkeit, dass der Server keine IP-Adressen mehr zur Verfügung hat, weil die IP-Adressen des jeweiligen Bereichs erschöpft sind. Automatisch bedient sich ein DHCP-Server nämlich nicht mit den freien IP-Adressen aus weiteren Bereichen, die eventuell auf dem Server konfiguriert sind. Um diesem Problem vorzubeugen, helfen die Bereichsgruppierungen (Superscopes), die mehrere Bereiche auf einem Server unter einem Dach zusammenfassen. Unter Windows Server 2003/2008 lassen sich mehrere Bereiche eines DHCP-Servers zu einer solchen Bereichsgruppierung verbinden. Clients die IP-Adressen anfragen, erhalten IP-Adressen aus allen Bereichen des Superscopes. Sind die IP-Adressen eines Bereichs erschöpft, erhalten Clients IP-Adressen aus einem anderen Bereich auf dem Server, der noch über freie Adressen verfügt. Dadurch besteht keine Gefahr, dass der DHCP-Server die Anfragen von Clients ablehnt, nur weil ein Bereich für IP-Adressen erschöpft ist.
Natürlich muss in diesem Fall auch sichergestellt sein, dass das Routing im Unternehmen so konfiguriert ist, dass die Clients mit den neuen IP-Adressen alle notwendigen Server erreichen. Mehrere IP-Bereiche auf DHCP-Servern sind hauptsächlich dann sinnvoll, wenn sich diese in verschiedenen Subnetzen befinden. Da der DHCP-Server bei der Adressvergabe aber nicht überprüft, ob das Routing funktioniert, empfiehlt es sich, vor der Erstellung von Bereichsgruppierungen zunächst den Routing-Weg im Unternehmen zu überprüfen und anzupassen, sofern dies notwendig ist. Schließlich muss sichergestellt sein, dass DHCP-Clients alle benötigten Netzwerkverbindungen aufbauen können, unabhängig davon, welche IP-Adresse der DHCP-Server aus dem Superscope zuweist.
Ebenfalls wichtig: Sofern die Anfragen an DHCP-Server über Router erfolgen, ist es erforderlich, dass die Router keine DHCP-Request-Pakete blockieren, sondern diese passieren lassen. Da nicht alle Router diese Option unterstützen, beziehungsweise nicht in jedem Unternehmen die Router wegen der DHCP-Konfiguration angepasst werden können, besteht auch die Möglichkeit ein DHCP-Relay zu verwenden. Diese Funktion ist in Windows Server 2003/2008 enthalten und ermöglicht die Verbindung zwischen Clients und DHCP-Servern in verschiedenen Netzwerken. Dazu fordern die Clients vom DHCP-Relay eine IP-Adresse an. Das Relay ist im selben Subnetz positioniert wie die Clients. Anschließend fordert das DHCP-Relay vom eigentlichen DHCP-Server eine IP-Adresse an und teilt diese dem Client zu. Der Vorgang dauert insgesamt auch nicht wesentlich länger als etwa bei der Konflikterkennung.
Konsistenz der DHCP-Datenbank überprüfen
Zur Sicherstellung der Ausfallsicherheit ist es auch notwendig, die Datenbank der DHCP-Server auf Konsistenz zu überprüfen. Während dieses Vorgangs prüft der Server, ob die Inhalte der einzelnen Bereiche auf dem DHCP-Server und in der Datenbank konsistent sind und ob eventuell Überschneidungen von IP-Adressen auftreten. Am schnellsten aktivieren Systemverwalter diesen Vorgang über das Kontextmenü des Protokolls in der DHCP-Verwaltungskonsole: Durch Auswahl von "Alle Bereiche abstimmen" startet die Überprüfung. Taucht ein Fehler auf, meldet dies der Server.
Grundsätzlich besteht bei Windows-Servern die Möglichkeit, die DHCP-Datenbank auf einen anderen - zum Beispiel neueren oder leistungsfähigeren - Server zu verschieben. Vorteilhaft dabei ist, dass die DHCP-Leases erhalten bleiben und der neue Server dadurch als vollwertiger Ersatz des ursprünglichen DHCP-Servers einspringt. Die Grundlage für das Verschieben stellt die Datensicherung der DHCP-Datenbank dar. Diese erstellt der Server in gewissen Abständen automatisch und speichert die Daten im Verzeichnis "Windows\System32\Dhcp\Backup". Auch manuell lässt sich bei Bedarf eine Sicherung anfertigen. Die entsprechende Funktion "Sichern" steht im Kontextmenü des Servers in der Verwaltungskonsole zur Verfügung. Nach der Sicherung und kurz vor dem Verschieben muss der DHCP-Dienst auf dem Quellserver beendet werden, damit dieser keine neuen Adressen vergibt. Die Daten aus dem Backup-Verzeichnis kopiert der Systemverwalter auf den Zielserver. Über den Befehl "Wiederherstellen" aus dem Kontextmenü des Servers in der DHCP-Verwaltungskonsole lässt sich diese Sicherung in den neuen Server integrieren.
Auch die Lease-Dauer, also der Zeitraum in dem eine IP-Adresse einem Clients zugewiesen ist, will bei der Planung einer Ausfallsicherung berücksichtigt sein. Die Lease-Dauer beträgt in der Standardeinstellung sechs Tage. Windows Server 2008 unterscheidet an dieser Stelle zwischen stationären (verkabelten) Computern, die erfahrungsgemäß länger mit dem Netzwerk verbunden sind, und mobilen (drahtlosen) Computern, die oft nur sporadisch Verbindung mit dem Netzwerk haben. Je länger die Lease-Dauer, umso länger ist eine IP-Adresse für einen Client reserviert. Abhängig von dieser Zeit durchläuft der DHCP-Client drei Phasen:
Nachdem die Lease-Dauer zur Hälfte abgelaufen ist, wendet sich der Client an den Server, um die erhaltene IP-Adresse erneut zu bestätigen. Ist der DHCP-Server betriebsbereit, setzt er die Lease-Dauer wieder auf ihren ursprünglichen Wert zurück. Antwortet der Server nicht, versucht der Client in regelmäßigen Abständen den Server zu erreichen.
Steht der ursprüngliche DHCP-Server nicht mehr zur Verlängerung zur Verfügung, versucht der DHCP-Client nach sieben Achtel der Lease-Dauer, irgendeinen DHCP-Server zu erreichen, der ihm eine neue IP-Adresse zuweisen kann. Auch diesen Versuch wiederholt er in regelmäßigen Abständen.
Nach Ablauf der Lease-Dauer muss der Client seine IP-Adresse freigeben und versucht nun weiter, einen DHCP-Server zu erreichen, der ihm eine neue IP-Adresse zuweist.
Bei ausreichend verfügbaren IP-Adressen sollte die Lease-Dauer möglichst hoch sein, damit die Clients keine unnötige Netzwerklast mit DHCP-Anfragen erzeugen. Nur wenn die Anzahl der verfügbaren Adressen kleiner als die Gesamtzahl der Computer ist, sollte der Wert so niedrig gesetzt werden (unter Umständen sogar im Stundenbereich), dass der DHCP-Server nicht mehr benötigte Adressen schnell wieder aus der Datenbank löschen und anderen Clients zuweisen kann.
Lesen Sie mehr zum Thema
