DHCP HA Standby

[BSChris 13]

Guten Abend,

 

wir haben mehrere Standorte und ich würde gerne einen zentralen Server für alle Standorte als Failover konfigurieren.

Meine Idee dabei ist, dass ich bei der Konfiguration der Standorte den zentralen Server als Failover nehme. Wenn ich den 2. Standort dann konfigurieren möchte und auch den Zentralen Server auswähle, kann ich mir vorstellen das dieser die Datenbank überschreibt. Meine Frage daher ist es überhaupt möglich so wie ich es mir vorstelle? Im Falle das er jedes mal die Datenbank überschreibt, wenn ich einen neuen Standort hinzufüge, könnte ich mir vorstellen, am ende mit Powershell die ganzen Scopes der Standorte separat hinzuzufügen!?

 

Gruß

Chris

[NilsK 2.785]

Moin,

 

Ich glaube nicht, dass dein Konstrukt mit DHCP funktioniert. Die Clients versuchen den Server per Broadcast zu erreichen, das wird über die Grenze des Standortes nicht klappen.

 

Gruß, Nils

 

Édit: hier lag ich falsch, siehe unten.

bearbeitet 22. Juni 2022 von NilsK
Falsche Annahme

[MurdocX 904]

Dazu ergänzend: Du könntest die Gateways der Standorte als DHCP-Server nutzen und den lokalen Windows-DHCP einen delay von einigen Sekunden geben. Dann hättest du einen Fallback, falls das Gateway nicht antwortet.

[NilsK 2.785]

Moin,

 

Ich würde allerdings auch noch mal nach dem Sinn des Ganzen fragen. Meiner Erfahrung nach wird HA für DHCP weitgehend überbewertet. Es gibt einzelne Umgebungen, die das brauchen mögen. Die meisten aber eher nicht.

 

Und wenn es denn benötigt wird, dann würde ich es auch richtig machen und kein Spar- und Bastelkonstrukt aufbauen.

 

Gruß, Nils

 

[BSChris 13]

vor 21 Minuten schrieb MurdocX:

Dazu ergänzend: Du könntest die Gateways der Standorte als DHCP-Server nutzen und den lokalen Windows-DHCP einen delay von einigen Sekunden geben. Dann hättest du einen Fallback, falls das Gateway nicht antwortet.

 

Hi, ja das wäre eine alternative, aber das werde ich dann noch einmal intern besprechen.

Danke für den Hinweis.

 

vor 8 Minuten schrieb NilsK:

Moin,

 

Ich würde allerdings auch noch mal nach dem Sinn des Ganzen fragen. Meiner Erfahrung nach wird HA für DHCP weitgehend überbewertet. Es gibt einzelne Umgebungen, die das brauchen mögen. Die meisten aber eher nicht.

 

Und wenn es denn benötigt wird, dann würde ich es auch richtig machen und kein Spar- und Bastelkonstrukt aufbauen.

 

Gruß, Nils

 

 

Ein Spar- und Bastelkonstrukt kann ich daraus nicht erkennen. Ich finde die Idee im Grundegenommen gut, da alle Standorte eine MPLS zu einen Zentralen Punkt haben.

Aber genau deswegen schreibe ich es ja hier noch einmal rein, um eventuelle alternativen zu erhalten.

 

Danke vorerst euch beiden.

Gruß

Chris

[NilsK 2.785]

Moin,

 

Was ich damit meine: so, wie du dir das ausgedacht hast, ist DHCP Failover nicht gedacht. Selbst wenn es keine Broadcast-Grenze in deinem Aufbau gäbe, wäre er jenseits der Spezifikation.* Damit könntest du dich nicht darauf verlassen, was dem HA-Ansatz grundsätzlich widerspricht.

 

Falls es wirklich so sein sollte, dass an mehr als einem Standort HA für DHCP erforderlich ist (was aus meiner Sicht schon ausgesprochen ungewöhnlich wäre), dann sollte es an den geringen Mehrkosten eines vollständigen Failover-Sets pro Standort nicht scheitern.

 

Gruß, Nils

 

* Édit: auch hier ist die Vermutung mit der Spezifikation falsch, siehe unten.

bearbeitet 22. Juni 2022 von NilsK
Auch nicht ganz richtig

[cj_berlin 1.137]

Moin,

vielleicht übersehe ich ja was, aber, sofern sich die Scopes zwischen den Standorten nicht überschneiden, ist es eine ganz normale Topologie??? 

 

 

[NilsK 2.785]

Moin,

 

Ich lerne ja gern dazu - wie erreichen die Clients im Failover-Fall den Server? Ist dann da an jedem Standort noch ein Relay im Spiel?

 

Kann auch sein, dass ich falsch lag, aber so ein Konstrukt erschiene mir eher unsinnig, weil ziemlich komplex und damit fehleranfällig.

 

Edith: okay, ich sehe, ich lag tatsächlich falsch mit meiner Vermutung. Sorry für den Fehler und die Verwirrung, die ich erzeugt habe. Wie Evgenij richtig sagt, ist das genau so vorgesehen:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn338979(v=ws.11)

 

(Ich würde es trotzdem nicht so bauen, weil ich es für zu komplex halte.)

 

Gruß, Nils

bearbeitet 22. Juni 2022 von NilsK

[BSChris 13]

vor 7 Stunden schrieb cj_berlin:

Moin,

vielleicht übersehe ich ja was, aber, sofern sich die Scopes zwischen den Standorten nicht überschneiden, ist es eine ganz normale Topologie??? 

 

 

 

Guten Morgen,

 

ja genau so dachte ich es mir, habe eben auch noch einmal versucht den Artikel zu suchen.
Wenn ich bei der Suche auf Bilder umschalte, finde ich den Artikel auch :)

Danke!

 

Gruß

Chris

[NorbertFe 1.800]

Ich stimme Nils da zu. Der DHCP Failover ist zwar "nett", aber eben leider wie bei MS typisch irgendwie anders als man es erwartet. Wer nicht die BEsonderheiten (änderungen werden nicht automatisch repliziert, Last Writer wins usw.) kennt und sie berücksichtigt, hat schneller als erwartet eher weniger als mehr Verfügbarkeit. (dafür aber mehr Aufwand). ;) (Danke an Nils für den Hinweis)

 

Bye

Norbert

bearbeitet 22. Juni 2022 von NorbertFe

[NilsK 2.785]

Moin,

 

Gerade eben schrieb NorbertFe:

hat schneller als erwartet eher mehr als weniger Verfügbarkeit.

jetzt noch mal 180 Grad drehen, oder? 

 

Gruß, Nils

 

[BSChris 13]

Mahlzeit,

 

ich werde es diese Woche noch mit 2 Standorten testen. Wie gesagt bin gespannt ob die Datenbank überschrieben wird oder nicht. Da bei einer Migration über netsh ja auch jedesmal die DB überschreibt. Werde hier berichten.

Vielen Dank für eure Beiträge.

 

Gruß
Chris

[NilsK 2.785]

Moin,

 

du machst ja keine Migration. Du richtest eine Failover-Beziehung ein. Das ist ganz was anderes. Schau dir die oben verlinkte Doku von MS an, von da aus solltest du weiterkommen.

 

Gruß, Nils

 

[BSChris 13]

Hallo,

 

sorry für die Verspätung. Also der Failover hat wunderbar funktioniert. Hatte zuvor beim testen vergessen den Zentralen DHCP Server noch im IP Helper einzutragen.

Danach hat es aber sehr gut und schnell funktioniert. Im Moment ist der Primäre DHCP Server noch im Status Recover wait, werde sehen wann dieser wieder in den Status Normal geht.

Edit: Nach genau 60 min. ist der Server wieder in den Status Normal gewechselt.

 

Gruß

Chris

bearbeitet 28. Juni 2022 von BSChris