DHCP Failover Cluster: Automatische Replikation von Konfigurationsänderungen
Mit dem Windows Server 2012 (R2) unterstützt Microsoft nun die hochverfügbare Konfiguration des DHCP Dienstes. Das bedeutet, dass zwei Server gleichzeitig die Rolle des DHCP Servers besitzen und über ein und dieselbe Konfiguration verfügen. In aktuellen, oftmals virtualisierten IT-Umgebungen können so hochverfügbare DHCP-Konfigurationen umgesetzt werden, bei denen ein DHCP-Server virtualisiert und ein zweiter auf einem physischen System betrieben wird.
Ein sogenannter DHCP Failover Cluster unterstützt zwei Modi: Load Balancing und Hot-Standby. Gleich welcher Modus verwendet wird, die DHCP-Datenbank für die ausgestellten Leases wird immer synchron gehalten, um im Fehlerfall eines (oder des aktiven) Servers, ohne Unterbrechung durch den Partnerserver weiterhin zur Verfügung zu stehen.
Problem
Obwohl bei der Einrichtung eines DHCP Failover Clusters die gesamte Konfiguration des ersten DHCP-Servers durch den Assistenten auf den Partnerserver übertragen wird, so gilt das im Betrieb nicht für Änderungen an der Konfiguration. Wird beispielsweise eine Reservierung innherhalb eines Failover-replizierten Bereiches hinzugefügt, geändert oder gelöscht, so wird diese Änderung nicht automatisch auf den Partnerserver repliziert. Diese Aktion muss manuell im Kontextmenü in der DHCP-Konsole erfolgen:
Alternativ kann diese Replikation auch über den folgenden PowerShell erfolgen, im diesem Beispiel würde die gesamte Konfiguration (also alle Failover-replizierten Bereiche) auf den Partnerserver übertragen werden:
Invoke-DhcpServerv4FailoverReplication -Force
Leider ist dieses Verhalten kein Fehler, sondern per Design so. Es lässt sich aber durchaus automatisieren, wie auch die Lösung von teamdhcp im Microsoft Technet. Allerdings war mir die Lösung zu kompliziert und erfordert die Ausführung eines PowerShell-Skriptes mit zusätzlicher XML-Konfigurationsdatei. Außerdem erfolgt die Synchronisation zeitgesteuert zyklisch.
Lösung
Mit der folgenden Anpassung lässt sich die DHCP-Konfiguration ereignisgesteuert replizieren. Dazu sind einige, im Folgenden beschriebene, Schritte notwendig, ohne das ein gesondertes PowerShell-Skript ausgeführt werden muss. Das folgende Schaubild skizziert die Funktionsweise der hier vorgestellten Lösung:
Erklärung der im Bild dargestellten Prozesse:
- Aktion 1: DHCP-Konfigurationsänderung am DHCP-Server 1
- Aktion 2: Eintrag im Ereignisprotokoll des DHCP-Server 1
- Aktion 3: Auslösung der Aufgabe zur Konfigurationsreplikation
- Aktion 4: Replikation der Konfiguration auf Basis von Powershell als spezieller Replikationsbenutzer
Natürlich soll die Replikation (im Load-Balancing-Modus) auch bidirektional funktionieren. Damit nach der Aktion 4, welcher der Aktion 1 auf dem DHCP-Server 2 entspricht, keine Endlos-Replikationsschleife ausgelöst wird, reagiert der Trigger der Aufgabe bei Aktion 3 nur, wenn das Ereignis nicht durch den Replikationsbenutzer erzeugt wurde.
Voraussetzung
Eine bereits eingerichtete DHCP-Failover-Konfiguration ist für die anschließenden Tests der hier beschriebenen Anpassung sinnvoll. Dabei ist zu beachten, dass immer alle Failover-konfigurierten Bereiche (Scopes) in der Replikation enthalten sind.
Schritt 1: Neues Dienstkonto erstellen
Das Dienstkonto (Domänenmitglied) wird zur Ausführung der Replikation benötigt und muss Mitglied der Gruppe DHCP-Administratoren auf den DHCP-Servern sein. Wird der DHCP-Server auf Domänencontrollern ausgeführt, ist diese Gruppe eine Domänen-lokale Sicherheitsgruppe. Als Mitglied dieser Gruppe darf der Benutzer Änderungen (und auch Replikationen) an den DHCP-Servern vornehmen:
Außerdem muss das Dienstkonto auf den DHCP-Servern das Recht Anmelden als Stapelverarbeitungsauftrag erhalten. Dies kann über eine Gruppenrichtlinie (oder bei einem Mitgliedsserver über die lokale Sicherheitsrichtlinie) erreicht werden:
Dieses Benutzerrecht wird benötigt, um später eine Aufgabe in der Aufgabenplanung auf den betroffenen Systemen auszuführen.
Schritt 2: Neue Aufgabe erstellen
Auf dem ersten DHCP-Server wird in der Aufgabenplanung eine neue Aufgabe erstellt. Im Reiter Trigger wird im Anschluss ein neuer Trigger erstellt. Unter Aufgabe starten muss Bei einem Ereignis und danach unter den Einstellungen Benutzerdefiniert ausgewählt werden.
Im Anschluss kann ein neuer Ereignisfilter erstellt werden. Als Protokoll ist das Microsoft-Windows-DHCP Server Events/Betriebsbereit auszuwählen, da bei einem hier auftretenden Ereignis der Trigger und damit die Aufgabe ausgeführt werden soll. Allerdings soll verhindert werden, dass der Trigger für ein Ereignis welches remote durch den in Schritt 1 definierten Benutzer erzeugt wurde, ausgelöst wurde. Dazu muss dieser Benutzer im Feld Benutzer eingetragen werden:
Danach ist der Reiter XML auszuwählen und im unteren Fensterbereich Manuell bearbeiten zu aktivieren. Dadurch wird das XML-Feld editierbar. Hier muss nach der Zeichenkette @UserID und vor dem = ein ! eingefügt werden. Damit gilt der neue Ereignisfilter für alle Eregnisse im ausgewählten Protokoll – außer diejenigen, die vom Benutzer aus Schritt 1 erzeugt worden.
Nun können die offenen Fenster des Ereignisfilters mit OK bestätigt werden. Im Aufgabendialog kann nun der Reiter Aktionen gewählt werden und mit der Schaltfläche Neu eine neue Aktion erstellt werden. Dazu wird der oben aufgeführte PowerShell-Befehl verwendet:
Dabei ist als Programm/Skript powershell zu verwenden und als Argument die Zeile
-command „Invoke-DhcpServerv4FailoverReplication -Force“
hinzuzufügen. Danach kann der Dialog mit OK bestätigt werden und der Aufgabenreiter Allgemein ausgewählt werden. Hier ist ein Name für die Aufgabe einzugeben und der Benutzer aus Schritt 1 für die Ausführung auszuwählen. Zudem soll die Aufgabe unabhängig von der Benutzeranmeldung und mit höchsten Privilegien ausgeführt werden:
Im Anschluss kann im Reiter Einstellungen die letzten Anpassungen vorgenommen werden. Wird die Aufgabe bereits ausgeführt, soll eine neue Instanz in die Warteschlange gestellt werden. Bei einer Ausführung von mehr als einer Minute ist die Aufgabe zu beenden – diese dauert erfahrungsgemäß wenige Sekunden.
Mit diesen Einstellungen kann die Aufgabe mit OK erstellt werden. Das Kennwort für den Benutzer wird abgefragt und der Hinweis für das notwendige Recht zur Anmeldung als Stapelverarbeitungsauftrag erscheint.
Zu diesem Zeitpunkt existiert bereits die unidirektionale Replikation vom aktuellen DHCP-Server (auf dem die Aufgabe erzeugt wurde) zum Partnerserver.
Schritt 3: Einrichtung der bidirektionalen Funktionalität
Auf dem zweiten DHCP-Server (Partnerserver) sind nun der Schritte 1 und 2 analog zum ersten Server durchzuführen. Dabei muss das Servicekonto (bei Mitgliedschaft in der Domäne) nicht neu angelegt werden
Schritt 4: Testen der Funktionalität
In meiner Testumgebung habe ich auf dem DHCP-Server 1 (hier lab-dc1.test.lab) auf dem die Aufgabe erstellt wurde, eine vorhandene Reservierung in einem Failover-konfigurierten (und synchronen) Bereich gelöscht. Diese Aktion wurde als Administrator durchgeführt. Im Ereignisprotokoll findet man dazu folgenden Eintrag:
Nach der Ausführung dauerte es (in meiner virtuellen Umgebung) einige Sekunden und im Ereignisprotokoll des DHCP-Server 2 (hier lab-dc2.test.lab) wurden folgende drei Ereignisse des Benutzers DHCP-Replication angezeigt:
Auf Grund der Tatsache das der Ereignisfilter aber den Benutzer DHCP-Replication explizit ausschließt, findet keine Rückreplikation statt – also so wie gewollt. Der Blick in die DHCP-Konsole bestätigte: die Reservierung wurde auf beiden DHCP-Servern erfolgreich gelöscht.
Auch weitere Tests bestätigen – die beschriebene Lösung funktioniert wie erwartet und hilft, die vermisste automatische Replikation der Konfigurationsänderungen in DHCP-Failover-Clustern zu verwenden.
Fazit
Warum Microsoft die automatische Replikation im DHCP-Failover-Cluster nur auf ausgestellte Leases beschränkt, ist für mich schwer nachvollziehbar. Gibt es in größeren Netzwerken (in denen ein hochverfügbarer Cluster-Betrieb erst sinnvoll erscheint) genügend Aufgaben, die eine Konfigurationsänderung im DHCP-Server nach sich ziehen. Die hier beschriebene Lösung ist recht praiktikabel und ohne größeren Aufwand umsetzbar. Wer Ergänzungen oder Verbesserungsvorschläge hat, kann diese gern hier als Kommentar posten.
Wie bei allen meinen Beiträgen gilt: Bei Tipps, Vorschlägen sowie Fragen oder Kritiken hinterlasst bitte einen Kommentar.
Einen Blog am Leben zu erhalten kostet Zeit und Geld. Da ich auf meiner Seite weder Werbung einbinde, noch andersweitige Zuwendungen erhalte, freue ich mich über jede kleine Spende. Einfach und unkompliziert geht das über PayPalMe. Du unterstützt damit diesen Blog. Vielen Dank.
Auf Grund der am 25. Mai 2018 in Kraft tretenden europäischen Datenschutz-Grundverordnung wurden alle Kommentare abgeschaltet und gelöscht. Damit wird die Erhebung personenbezogener Daten vermieden. Das DSGVO wurde von Professor Thomas Hoeren zu "einem der schlechtesten Gesetze des 21. Jahrhunderts" gekürt, mit der Bemerkung, dass überbordene Werk sei "hirnlos". Ich bedaure sehr, das damit die Möglichkeit zum Austausch von Informationen von Gleichgesinnten verhindert wird.