Inhaltsverzeichnis
Szenario
DHCP-Server findet man in nahezu jeder Infrastruktur. Sie sind ein wichtiger Baustein, der uns Administratoren das Leben vereinfacht. Manchmal müssen wir den Service auf eine modernere Plattform migrieren. Mit einer passenden Downtime ist das eigentlich kein Problem. Aber wie gelingt die Migration, wenn es keine Unterbrechungen geben darf?
In meinem LAB werden Clients mit IPv4-Adressen über zwei DHCP-Server versorgt. Die Adressen der einzelnen Subnetze sind in zwei gleich große Adressräume aufgeteilt, von denen jeder jeweils einem DHCP-Server zugewiesen wurde (Split-Scope). So können Clients Adressen für jedes Subnetz erhalten – auch wenn mal ein Server ausfallen sollte.
Beide Server laufen mit Windows Server. Das Szenario wäre für alle Versionen ab Windows Server 2008 R2 denkbar.
Die Clients fragen die IPv4-Adressen nicht direkt an. Das übernehmen DHCP-Relayagents (iphelper) auf den Routern.
Die beiden alten Server sollen durch neue Server ersetzt werden. Unterbrechungen in der Adressvergabe sind zu vermeiden. Die neue Lösung soll ebenfalls höher verfügbar sein.
Die IP-Adressen der DHCP-Server können nicht wiederverwendet werden. (Das könnte z.B. durch andere Services verursacht werden, die auf den gleichen, alten Servern laufen, aber die jetzt noch nicht portiert werden können).
Die neuen Server werden das Feature DHCP-Failover für die Verfügbarkeit verwenden. Dies steht seit Windows Server 2012 zur Verfügung.
Da die Altsysteme weiter als Nicht-DHCP-Server in Betrieb bleiben und die IP-Adresse der Server nicht mitgenommen werden kann, sind die Verfahren „Inplace-Upgrade“ (Aktualisierung des alten Betriebssystems) und „Wipe-and-Load“ (Austausch des Altsystems durch ein gleichkonfiguriertes mit gleichem Namen und gleicher IP-Adresse) nicht möglich. Es bleibt also nur eine Migration im „Side-by-Side“-Verfahren.
Die Migration teile ich in 6 Phasen. Diese können auf einzelne Scopes heruntergebrochen werden. Es muss also keine „Big-Bang“-Migration sein: man kann ein Netzwerksegment nach dem nächsten umziehen.
Bei der Migration werden je Scope mehrere Arbeitsschritte erforderlich:
- Der Scope auf dem alten DHCP-Server wird deaktiviert. So können keine weiteren IPv4-Adressen ausgestellt werden.
- Alle aktiven Leases werden aus dem Scope des alten DHCP-Servers in den vorbereiteten Scope auf dem neuen DHCP-Server importiert.
- Der Scope auf dem neuen Server wird aktiviert.
- Optional müssen jetzt noch DHCP-RelayAgents auf den neuen DHCP-Server verweisen
Ablauf der Migration aus der Sicht der DHCP-Server
In diesem Abschnitt erläutere ich die 6 Migrationsphasen mit den dazugehörigen Arbeitsschritten
Schema:
In dieser Phase werden parallel zu den beiden alten Servern zwei neue DHCP-Server aufgesetzt. Diese haben noch keine Scopes und sie verwenden andere IPv4-Adressen als die alten Server. Die DHCP-Relayagents (iphelper) auf den Switches zeigen auf die beiden alten Systeme.
Im Bestand ist der Adressraum je Subnetz geteilt (Split-Scope), damit der Ausfall eines DHCP kompensiert werden kann. Beide Server haben Leases vergeben.
In dieser Phase wird es keine Service-Unterbrechung geben.
Schema:
Auf dem ersten neuen Server werden die Scopes neu erstellt. Sie bleiben deaktiviert, damit eine Mehrfachvergabe ausgeschlossen werden kann. Die IP-Adressräume der beiden alten Server werden dabei zusammengefasst:
- DHCP1 (alt) vergibt aktuell von 10.32.10.1 bis 10.32.10.127
- DHCP2 (alt) vergibt aktuell von 10.32.10.128 bis 10.32.10.253
- der neue DHCP vergibt nach der Migration die IP-Adressen 10.32.10.1 bis 10.32.10.253
Der andere neue DHCP-Server bleibt von Scope-frei. Auch hier gibt es keine Service-Unterbrechung.
Schema:
Jetzt wird die Vergabe der IP-Adressen auf den alten Servern ausgesetzt. Dies kann je Scope vorgenommen werden, indem man diese deaktiviert. Die bereits ausgeliehenen IPv4-Adressen bleiben dabei innerhalb ihrer Leasetime gültig. Clients ohne IPv4-Adresse werden aber nicht mehr bedient. Daher sollte diese Phase in einer aus DHCP-Sicht ruhigen Zeit stattfinden.
Das ist die Anweisung in der PowerShell. Sie führt die Phasen 3 bis 5 je Scope in einem Arbeitsschritt durch.
Zeitlich ist diese Phase sehr kurz (weniger als eine Minute), wenn die Portierung zur nächsten Phase gescriptet vorgenommen wird.
Schema:
Durch 2 PowerShell-Befehle werden nun die aktiven Leases und Reservierungen der beiden alten Server in den neuen Server integriert. Dieser kennt nun alle vergebenen Adressen. Der Vorgang dauert nur wenige Sekunden.
Schema:
Jetzt werden die neuen Scopes auf dem neuen Server aktiviert. Zusätzlich können jetzt die DHCP-Relayagents (iphelper) auf den Routern auf die neuen DHCP-Server angepasst werden. Ab diesem Moment werden Clients wieder mit IPv4-Adressen versorgt. Der neue Server wird dabei nur nicht-verwendete Adressen vergeben, da er ja die aktiven Leases der beiden alten Server kennt.
Nach der Aktivierung des ersten neuen Servers steht der Service DHCP eingeschränkt zur Verfügung: Es fehlt die Verfügbarkeit – der Ausfall des neuen Servers unterbricht die Versorgung mit IPv4-Adressen.
Schema:
Damit der Service DHCP wieder höher verfügbar wird, kann jetzt der fertige Scope durch die Einrichtung eines DHCP-Failovers auf den zweiten neuen DHCP-Server gespiegelt werden.
Die beiden alten Server werden nach dem Umzug aller alten Scopes nicht länger benötigt und können zurückgebaut werden.
Ablauf der Migration aus der Sicht eines Clients
Serverseitig ist der Migrationsprozess recht einfach. Dennoch wird es auf der Seite der Clients eine kurze Unterbrechung der Netzwerk-Konnektivität geben. Um diesem Umstand zu verstehen, möchte ich das Verhalten der Clients in 3 Schritten aufzeigen.
Ein Client hat auf dem alten DHCP-Server eine IPv4-Adresse angefragt. Das Verfahren beruht auf den 4 DORA-Paketen (Discover, Offer, Request, Ack), die er via Broadcast mit dem DHCP-Server übermittelt.
Ihm wurde die 10.32.2.102 zugewiesen:
Die IPv4-Adresse wurde in der Datenbank des alten DHCP-Servers eingetragen:
Damit ist der Vorgang abgeschlossen und der Client kann die Adresse innerhalb der Leasetime verwenden.
Nach Ablauf der halben Lease-Time wird der Client ein Unicast-Packet zum DHCP-Server senden, von dem er die Adresse erhalten hat. Dieser bestätigt die Lease-Erneuerung ebenfalls mit einem Unicast:
Und hier liegt das Problem: Der Client kennt die IPv4-Adresse des DHCP-Servers, von dem er seine eigene Adresse erhalten hat. Daher spricht er ihn direkt an. Sollte der Server zu diesem Zeitpunkt (Ablauf halbe Leasetime) nicht erreichbar sein, dann wird er es nach Ablauf von 87,5% der Leasetime erneut mit einem Unicast versuchen. Schlägt auch dieser fehl, dann wird der Client nach Ablauf von 100% Leasetime die IPv4-Adresse aufgeben und via Broadcast eine neue im Netzwerk anfragen. Dabei werden bestehende Netzwerkverbindungen unterbrochen.
Der Scope mit der IPv4-Adresse des Clients wurde jetzt vom alten DHCP-Server auf den neuen Server umgezogen.
Der Client versucht wieder nach Ablauf der halben Lease-Time, den ursprünglichen DHCP-Server via Unicast zu kontaktieren, um eine Verlängerung zu beantragen:
Aber durch die Deaktivierung des Scopes auf dem alten Server lehnt dieser die Lease-Verlängerung ab:
Danach muss der Client die IPv4-Adresse direkt aufgeben und eine neue Adresse via Broadcast anfragen:
Jetzt antwortet der neue DHCP-Server. Dieser kennt dank der importierten und immer noch gültigen Lease (diese ist ja erst zu 50% abgelaufen) die MAC-Adresse des Clients und bietet ihm daher seine „alte“ IPv4-Adresse wieder an:
Der Client wird dieses Angebot akzeptieren. Seine IPv4-Adresse wird also durch die Migration nicht verändert. Er wird aber für einen kurzen Zeitraum keine Netzwerkverbindung haben. In dem Beispiel betrug die Unterbrechung 0,015443 Sekunden.
Dies ist eine Möglichkeit für ein Side-By-Side-Szenario. Ich hoffe, dass euch die Erläuterungen zu den technischen Hintergründen bei euren Projekten helfen werden. Den Beitrag gibt es hier als PDF-Datei zum Download.
Stay tuned!