DHCP-Server als Back-Up-Server laufen lassen

Wie schafft Ihr es denn, den Servern klar zu machen, welche IP's sie an welche PC's im jeweils zugehörigen Netz zu schicken?

Das "Lease" bedeutet, dass sich der DHCP-Client die IP über einen Zeitraum von 21 (einstellbar) Tagen merkt, auch bei Abwesenheit des DHCP-Servers behält der Client also "seine" IP auch nach dem Booten,

Gruß

Atti

Nope - solange die Lease noch gültig ist, wird keine neue angefordert. Erst wenn sie abläuft und der Client einen dhcprequest an den Server schicken will, gibt es Probleme.


Eigentlich nicht. Wenn Ihr mehr Ausfallsicherheit haben wollt, habt ihr folgende Möglichkeiten:

-ein Server mit den gleichen DHCP-Scopes wie der aktive als reine ColdStandby-Lösung, der bei Bedarf angeschaltet wird (die beiden Server dürfen nicht gleichzeitig laufen)

-eine 50:50 - Aufteilung der Scopes auf die beiden Server, die in diesem Fall gleichzeitig laufen können. Diese dürfen sich nicht überschneiden. Allerdings könnte es sein, daß diese Lösung zu Problemen führt, da der schnellere der beiden antwortet und wenn dieser die entsprechenden Scopes nicht hält, gibt er wahrscheinlich erst einmal blind ein dhcpnack aus. Wenn man allerdings die Netze physikalisch trennt und die dhcp-pakete nicht über das Gate gehen, sollte es theoretisch funktionieren

-eine Clusterlösung. Mit W2K und W2K3 kann man DHCP als Anwendungscluster betreiben. Das machen wir auch. Mittlerweile, nach etlichen Problemen, viel MS-Support und Generierung von zwei KB-Artikeln zum Thema DHCP unter W2K3 funktioniert es sauber *grins* Ist etwas aufwendig und mit Vorsicht zu genießen, aber wenn es läuft, läuft es gut. Wir haben auch schon testweise einen kompletten ASR-Restore mit Wiederherstellung beider Nodes, des Clusters und des DHCP-Dienstes durchgeführt (natürlich in einer Testumgebung).

Grüße,
fritzo

Ähm. Das mit dem Merken der IP-Adresse ist aber stark betriebssystemabhängig, wage ich mal hier zu behaupten!

Meine Rechner in meinem PC-Arbeitsraum fragen bei jedem Hochfahren den DHCP-Server nach ihrer IP-Adresse... das ganze kommt daher, weil ich via PXE-Bootrom von der Karte boote, bzw. über die Karte vom Netz *g*.

Das später nach dem PXE-Geschraddel gestartete Windows 2000 fragt ebenfalls beim Hochfahren nach einer IP-Adresse und nimmt sich, wenn kein DHCP-Server antwortet, eine APIPA-Adresse...

Die Leasedauer bei mir liegt bei 4h, was damit zu tun hat, dass ich im gleichen Netzsegment hin und wieder sehr dynamische Adressen habe und mir den Kram mit einem individuellen Lease für die IP-Adressbereiche sparen wollte.

Also würd ich sagen: es ist stark konfigurationsabhänig und sehr stark von der jeweiligen Situation gefärbt, wie sich die Systeme beim Hochfahren und beim Fehlen eines DHCP-Servers verhalten.

So hatte ich z.B. letzte Woche durch einen defekten Switch das Phänomen, dass ein Rechner beim Hochfahren eine IP-Adresse per DHCP bekam, dann im Laufe des Tages beim Renew der Adresse (beim Ablauf des Lease) die Antwort des DHCP nicht hörte (defekter Switch) und deswegen ab in den APIPA-Bereich sprang... Anderer Switch und das Problem war gegessen.

Gruß, Mupfel

Nach längerem Überlegen habe ich dann auch festgestellt, daß das evtl. eine Nullaussage sein könnte - da brauchst Du Clients, die nie rebooten. *g* es ist spät und der tag war lang; ich bin ein alter Mann, meine Augen sind gebeugt und mein Rücken halbblind (c) Brian (c) was soviel bedeutet wie Brian.

Grüße,
fritzo

Armes Tuktuk ich werde dich mit auf die Liste mit meinen Rentenbeiträgen zu finanzierender Personen setzen lassen Da kannst du mal noch gut und gerne 35 Jahre von Leben Naja, Leben ist übertrieben, aber zumindest ist eine tägliche Tasse Kaffee und ein Stück Kuchen drin

Gruß, Mupfel

PS: so alt bist doch noch garnicht, oder???

So spüre die Macht meiner Krücke, Elender!


natürlich nicht *grins* und wer was anderes behauptet - s.o. (Krücke)

Grüße,
fritzo

In "Ich habe keine Ahnung und ich lüge immer!" ist ein Paradoxon enthalten - wers findet darfs behalten. *gg

Hehe... herzlichen Glückwunsch: bist der erste, der das bisher zugegeben hat, dass er gemerkt hat, dass der Satz sowas geniales enthält

Darfst dir für den nächsten Sysadminday (www.sysadminday.com/) in diesem Jahr was wünschen, evtl. bekommst es ja *g*

Gruß, Mupfel

Zum Thema zurück:

du kannst unter Umständen (bei MS-Servern weiss ich das nicht) die Antwortzeit des "Backup-DHCP"-Servers verlängern, so dass der erstmal abwartet, bis er antwortet. Ist, wie die Kollegen schon sagten, eine sehr gewagte Sache, funktioniert aber durchaus. Lief in meinem Umfeld über einige Jahre stabil...

Setzt jedoch voraus, dass identische Scopes vergeben sind, damit keine Adresssprünge (schönes Wort mit 3 s) stattfinden... Also massiver Wartungsaufwand unter Umständen.

Besser wäre es, per Script z.B. den primären DHCP-Server zu überwachen (ob dieser voll funktionsfähig ist) und bei Ausfallerscheinungen den zweiten Server zu aktivieren... auch hier gilt die sache mit den gleichen Scopes ...

Es ist also wie oben schonmal erwähnt, eine Sache, die man besser nicht tun sollte oder aber wen man sie tut, muss man höllisch aufpassen, was man tut.

Gruß, Mupfel

Hi Mupfel,

ich meinte folgendes: Der Teilsatz "Ich lüge immer" ist für sich ein Paradoxon, weil es nicht beweisbar ist, ob die Aussage wahr oder falsch ist. Wunsch für den Sysadmin-Day: einen Tag außerhalb des Serverraums in the big blue ;)

Viele Grüße und Nightynight,
fritzo

Das war mir klar, dass du den Nachsatz meintest Ich habe den ja ganz bewusst reingeschrieben im Vollbesitz des Wissens darüber, dass diese Aussage eben nicht beweisbar ist! Das sind noch überbleibsel meiner Vergangenheit als ich mal noch als Student an einer Uni tätig war.

Wegen dem Tag ausserhalb deines Serverraumes: das sollte sich wohl einrichten lassen *grins* Ich kann ja mal einen Tag mit dir Tauschen und dich hier an die universitäre Front lassen

Da merkst du mal, wie "hart" aber auch wie amysant Benutzersupport und Fehlersuche vor Ort werden kann

Ich würde als Gegenleistung dann mit dem Staubsauger die Kabelschächte aussaugen *lach*, weil ich ja selbst weiss, wie das ist mit doppelten Böden und abgehangenen Decken

Gruß, Mupfel

Langes Gerede kurzer Sinn.

Auch ich würde auf einen Cluster setzen.
Du hast ja 2 Server - und warum nicht gleich clustern ???????

Du bräuchtest die DHCP Datenbank ja sowieso auf einer shared Disk.
Wie soll sonst der zweite wissen - was der erste bereits vergeben hat ???? geht nicht.

Also - Cluster.

So, Du degradierst unsere Überlegungen indirekt zu sogenanntem "langem Gerede". Na, ich werd mich direkt revanchieren *feistgrins


Weil Carrera911 != FiatPanda und Applikationscluster != Filecluster. Für ein Wolfpack braucht es nicht viel. Netzbasierte Applikationen hingegen sind eine ganz eigene Sache. Dachte auch mal, daß Applikationscluster kein Problem sind - 1/2 Jahr Gewurschtel mit falsch angezeigten Scopes, einer korrupten DB und mittlerweile zwei von uns generierten KB-Artikeln zum Thema Clustered DHCP lassen mich da etwas anders denken. Und bevor die Frage kommt - yes we read the fine manual.


Nack. Wenn er die Ranges bei einer gesplitteten Lösung trennt, dann ist es kein Problem. Bei ColdStandby brauchst Du auch keine shared disk. Du mußt lediglich sicherstellen, daß Du regelmäßig die Daten abziehst - dafür reicht ein sekundenschneller netshdump pro Tag vor der Sicherung (die ja auch nochmal verwendet werden kann) mal locker aus.

Grüße,
fritzo

NetzAdmin schrieb am 14.03.2005 Im Bezug auf DHCP-Applikationscluster unter W2K3:

Worauf man imho achten sollte - nehmt schnelle FC-Switches oder ähnliches statt Y-SCSI wegen der RPC-Latenzzeiten. Vergebt beim Clustering keine Prio, beide Knoten sollten gleichberechtigt sein. Setzt bei einem der Knoten eine etwas längere Bootzeit, damit nicht beide zum gleichen Zeitpunkt hochkommen, wenn sie durchstarten. Seht zu, daß Ihr eine ständig verfügbare gemeinsame Zeitquelle (domänenbasiert geht natürlich auch) für beide Nodes einrichtet und diese auf beiden Knoten konfiguriert - der Clusterdienst ist sehr abhängig von Timestamps.

Achtet auf Fehlermeldungen bzgl. des Zeitdienstes und beschäftigt Euch auch mit dem Clusterlog statt nur die Eventlogs zu checken. Snifft einmal pro Monat eine Zeit lang dhcp-pakete, wenn möglich, damit ihr wisst, ob irgendwas krumm läuft. Checkt testweise, mit ipconfig /release und /renew ob Clients in verschiedenen Subnetzen auch Leases ziehen. Prüft, ob Eure Router dhcp durchlassen.

Beschäftigt Euch auch mit dem Zusammenhang DNS <> DHCP unter 2003, wenn Ihr DHCP für die Registrierung von IPs in DNS benutzt. Checkt regelmäßig mit einem Offlinesystem, ob Ihr aus Euer DHCP-Sicherung den Server wiederherstellen könnt. Benutzt die Originalpfade für die DB und möglichst keine Spaces in den Namen. Verändert möglichst nicht die gesetzten Standardberechtigungen des Systems bzgl. der DB-Pfade.

Prüft mit eventcomb und Scripts regelmäßig die Logs. Wenn Ihr entfernte Systeme über iSCSI oder ähnliches benutzt, dann checkt ob die Latenzzeiten für RPC eingehalten werden. Switcht regelmäßig (1x / Monat) und prüft die Funktion der Nodes.

Benutzt auf jeden Fall eine shared disk für den Cluster - es gibt zwar auch die Möglichkeit, daß jeder Node seine eigene DB hält und die Daten dann ähnlich wie unter Unix mit rsync abgeglichen werden, das ist aber soweit ich weiß noch nicht ganz ausgereift.

Grüße,
fritzo

Kurzer Zwischenstatus von mir.

Unser DHCP Cluster läuft bereits.
Windows 2003 Enterprise.

Das "aufwendigste" an der Umstellung war eigentlich das exportieren am alten (W2k) DHCP und importieren am neuen
Aber auch dazu gibt's einen "HOW TO" von unseren MS Freunden......

Also, das erste TestScope am neuen macht mir zur Zeit keine Probleme............


nur mal als zwischenStatus - fritzo - und ich poste wieder.