Bents Blog

 

Ein IT Blog mit Themen aus dem Windows Server Umfeld.

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:

Manuelle Replikation der DHCP-Konfiguration

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:

Funktionsweise der Replikation

Erklärung der im Bild dargestellten Prozesse:

  1. Aktion 1: DHCP-Konfigurationsänderung am DHCP-Server 1
  2. Aktion 2: Eintrag im Ereignisprotokoll des DHCP-Server 1
  3. Aktion 3: Auslösung der Aufgabe zur Konfigurationsreplikation
  4. 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:

DHCP-Dienstkonto

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:

Recht: Anmeldung als Stapelverarbeitungsauftrag

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.

Neue Aufgabe und Trigger erstellen

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.

XML-Konfiguration des Ereignisfilters

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:

Neue Aufgabenaktion

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:

Allgemeine Aufgabeneinstellungen

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.

Einstellungen der Aufgabe

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:

Löschen einer Reservierung auf DHCP-Server 1

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:

Replikation auf dem DHCP-Server 2

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.

6 Kommentare für “DHCP Failover Cluster: Automatische Replikation von Konfigurationsänderungen”

  • Toni Dantzer

    Hallo Bent, ich hatte hier auch schon einmal was Ähnliches vom Microsoft Windows DNS, DHCP and IPAM Team Blog:

    http://bit.ly/2k45ecC

    VG
    Toni

  • Bent Schrader

    Hallo Toni,

    das ist genau das Skript, auf das ich (im Abschnitt Problem) verlinkt habe (Lösung von teamdhcp).
    Das Konstrukt ist nicht schlecht, erfodert aber einen ungleich höheren Aufwand: PowerShell-Skript-Ausführungspolicy, XML-Konfiguration, Pflege dieser Konfigurationen auf mehreren Servern. Daher der hier beschriebene, etwas einfachere Weg.

    Gruß,
    Bent

  • Stefan

    Hallo Bent,
    eigentlich super erklärt. Aber irgendetwas mache ich wohl noch falsch.
    Änderungen von DHCP1 auf DHCP2 werden sauber repliziert. Allerdings hatte ich es so verstanden, dass auch Änderungen am DHCP2 zu DHCP1 repliziert werden müssten. Und das funktioniert noch nicht bei mir. Ich erhalte dann immer einen Fehler 101.
    Hast Du einen Tipp, woran es haken könnte?
    DHCP1 ist bei mir ein Member-Server, DHCP2 ein Domänencontroller.

    Viele Grüße
    Stefan

  • Bent Schrader

    Hallo Stefan,

    bitte versuche doch einmal das Kommando [Invoke-DhcpServerv4FailoverReplication -Force] in einer PowerShell auf dem DHCP2 auszuführen. Erhälst Du dort ebenfalls einen Fehler? Das Recht zur Anmeldung als Stapelverarbeitungsauftrag hast Du auf dem Member-Server in der lokalen Sicherheitsrichtlinie durchgeführt?

    Gruß,
    Bent

  • Sabine A.

    Hallo Bent, ich glaube ich habe das gleiche Problem. Änderungen von DHCP2 auf DHCP1 kommen nach der Einrichtung als Task nicht an. Per Aufruf aus PowerShell geht es. Die Einträge im Event-Log sehen bei beiden Wegen gleich aus. Und kein angezeigter Fehler. Auch die Konfiguration des Tasks ist exakt gleich. Die Berechtigung zur Anmeldung als Stapelverarbeitungsauftrag habe ich beiden Servern als lokale Sicherheitsrichtlinie mitgegeben.
    Und nebennei: Ein Replizieren des DHCP-Filters geht so nicht, oder?

    Gruß
    Sabine

  • Hardy 69

    Hallo Bent,

    vielen DANK für die excellent geschriebene Anleitung funzt alles super!!!
    Hat auf Anhieb sehr gut geklappt.

    Gruß, Hardy

Einen Kommentar hinterlassen:

Antispam Bee hat Bent's Blog vor 481.464 Spam-Kommentaren bewahrt.