none
Redundante auslegung von DC, DHCP und Userprofilen RRS feed

  • Frage

  • Hallo allerseits,

    da es das letzte mal so gut geklappt hat, jetzt noch eine kleine Steigerung.

    Wir sind hier dabei unsere Umgebung ausfallsicher zu gestallten. Wir haben einen Win2k8 R2 Server mit mehreren VM's, mitunter ein DC. Jetzt soll noch ein 2. Win2k8 R2 Server dazukommen, auf dem noch ein 2 VDC eingerichtet wird. Da wir jetzt 2 DC's haben, dürfte doch gar nichts mehr dagegen sprechen, die beiden festen Maschinen mit in die Domäne aufzunehmen und als Fileserver zu benutzen. Da einer von der Hosts aus welchen auch immer Grund ausfallen sollte, haben wir ja noch den zweiten mit einem VDC drauf, an dem sich alle (und auch der ausgefallene Host nach dem start) anmelden können. Oder mache ich da einen Denkfehler?

    Nächste Frage geht um den DHCP. Wie krieg ich den DHCP redundant ausgelegt? Bis jetzt haben wir das immer so gelöst, dass ein zweiter DHCP, mit einer etwas anderen Range, verzögert eingesprungen ist, falls der erste mal ausgefallen ist. Leider gibt die Anzahl der IP-Adressen und der Rechner das nicht mehr her. Gibt es eine Möglichkeit, einen DHCP-Server so ähnlich wie einen DC zu replizieren?
    Und was spricht eigentlich dagegen, den DHCP auf dem DC  zu haben? Habe auf der Suche nach einer Lösung für das DHCP Problem öfter gelesen, dass dies nicht das optimalste ist.

    Und nun zu meiner dritten und letzten Frage. Eigentlich haben wir geplant, die Userprofile in einem Namespace auf den beiden Fileservern zu speichern, und untereinander mit DFS-R zu replizieren. Jetzt musste ich aber feststellen, dass das keine von Microsoft supportete Lösung ist. Wenn der User auf ein nur zum Teil repliziertes Profil umgeschaltet wird, kann das Profil zerstört werden. Ich kenne das aber so, dass die User eh auf den lokal gespeicherten Profilen arbeiten. Diese werden bei der Anmeldung vom Server auf den lokalen Computer kopiert (soweit sich die beiden unterscheiden), und beim Ausloggen wieder zurück. Man arbeitet also nur lokal. Wieso dan die Einwände?

    Ich hoffe, Ihr könnt mir weiterhelfen und vielen Dank schon mal im Vorraus

    Gruß

    Sebastian

    Dienstag, 22. Januar 2013 15:09

Alle Antworten

  • Folgende Artikel seien Dir fürs Selbststudium an die Hand gegeben:

    Planning Considerations for Virtualized Domain Controllers
    http://technet.microsoft.com/nl-nl/library/dd348476.aspx

    Clustering DHCP Servers
    http://technet.microsoft.com/en-us/library/ee405263.aspx

    Information about Microsoft support policy for a DFS-R and DFS-N deployment scenario
    http://support.microsoft.com/kb/2533009
    -> Technical reasons that Microsoft does not support the scenario
    [..]

    We do not support the deployment scenario for the following reasons:
    • User home folders or user profiles that are replicated by using DFS-R between the branch office file servers and the central file server may not be up to date. The issue may occur for one of the following reasons:
      • Large replication backlogs
      • Heavy system load
      • Bandwidth throttling
      • Replication schedules
    • DFS-R does not perform transactional replication of user profile data. A transactional replication either replicates all changes to a user profile or replicates nothing at all. Therefore, some files of a user profile may have been replicated, whereas other files may not have been replicated before the user was failed over to the central file server.
    • The client computer may be failed over to the central file server by the DFS-N client in one of the following scenarios:
      • There are transient network glitches when the client computer accesses data over Server Message Block (SMB) from the branch office file server.
      • There are specific error codes when the client computer accesses data over SMB from the branch office file server.
      The redirection may occur even when the branch office file server is available. Therefore, a user may be redirected to the central file server even if you configure the target referral priority of the branch office file server at a higher level.

    [..]

    --

    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net

    Dienstag, 22. Januar 2013 15:23
  • Danke erstmal für deine Antwort. Aber lassen wir uns das Ganze einmal Schritt für Schritt durchgehen.

    Die Links habe ich mir natürlich angeschaut, verstanden nur teilweise.

    Uns sind natürlich die Unterschiede zwischen physischen DC's und VDC's bekannt, obwohl die Unterschiede bei der Verwendung von Hyper-V und VDC's zu physischen DC's nicht mehr so groß sind. Nachteile wie: unbefugter Zugriff auf VHD's (VHD's befinden sich in geschützter Umgebung auf die Niemand Zugriff hat), falsche Benutzung von VHD's (Stichwort Wiederherstellung sollte jedem klar sein, USN-Rollbacks, etc.)

    1. VDC's: Wir haben 2 physische Server zur Verfügung, beide in der Domäne, da Shares auf einer Direct Attached Storage für Domänenuser zur Verfügung gestellt werden müssen. Geht ein Host aus, übernimmt der 2. VDC auf dem 2. Host die Aufgabe für die Anmeldungen der User. Einziger Punkt wären die FSMO Rollen beim Ausfall des 1. Hosts und den damit nicht verfügbaren 1. DC. Gibt es Einwände gegen eine solche Konstellation? Man liest so viele verschiedene Dinge, sodass man nicht mehr weiß was wirklich Best Practice ist. Aber irgendwo hat man nun mal ein bestimmtes Budget und muss mit den vorhandenen Mitteln etwas anfangen. Mir wäre ein Cluster mit einer zentralen Speicherlösung und Hardwarevirtualiserung auch lieber :)

    2. Profildaten: Wir würden die Daten auf dem ersten Host auf einem Fileserver ablegen und über domäne.local\profildaten zur Verfügung stellen. Uns ist natürlich bewusst, dass wenn der Host ausfällt und sich die User am 2. DC, der sich auf dem 2. Host befindet anmelden, nicht an Ihre Profildaten kommen. Dazu eine Idee: Wir verwenden DFSN (Im Userprofil: \\domäne.local\dfsn) und deaktivieren im Namedspace das DFSR für die Replikation. Abends kopieren wir die Daten von A nach B. Im Fehlerfall ändern wir einfach das Target im DFSN auf das 2. Share. Wo wäre hier aber der Unterschied zu DFSR, wenn wir die Daten per Robocopy kopieren? Andernfalls könnte auch ein Fast Recovery Szenario zum Einsatz kommen, ist aber nicht so schön.

    3. DHCP: Gibt es eine Möglichkeit ohne Failover Cluster? Sollte der DHCP ausserhalb des DHCP liegen?

    Dienstag, 22. Januar 2013 16:41
  • Hallo Sebastian,

    zum Anfang: Du/ Ihr solltet euch wirklich erstmal Gedanken machen was ihr eigentlich wollt. Dein Plan klingt zwar auf den ersten Blick durchdacht, aber da gibts ein paar Fallstricke die es gerade in den Umgebungen die Ihr vorhabt zu bedenken gilt.

    Wenn ich das richtig verstanden habe ist euer Ziel Redundanz und Ausfallsicherheit - schön und gut, dann wollt ihr aber noch anfangen mit der Hand hin und her zu kopieren, was dann wieder vergessen wird, oder schiefgeht, oder oder oder und DFS ist dazu auch keine wirkliche Alternative.

    Lasst euch erstmal richtig von eurem IT Partner oder Systemhaus beraten. Bei der Virtualisierung kann ne Menge schiefgehen - gerade dann wenns das eigentlich nicht soll.

    Denkt erstmal über eure Server nach die ihr habt/ beschaffen wollt - geht das nicht günstiger? Brauch ich tastsächlich für 2 DCs, Fileserver und DHCP 2 vollausgestatte DL380 (nur als Beispiel) oder tuts auch was kleineres, das übrig gebliebene Geld kann man dann in ein Storage investieren und hat dann was richtiges. Was sich auszahlt. Mit einem richtigen (für eure Zwecke angemessenen) Array schlagt ihr viele Fliegen mit einer Klappe: Die Daten liegen auf einem zentralen Storage und können von beiden Servern angesprochen werden, die VHD´s (Schlussendlich die Daten und Betriebssysteme) sind für beide HyperV Server erreichbar, ohne lästiges kopieren etc.. Aber der Hauptvorteil ist eben das du in dem Storage Array nen einfaches RAID hast mit 1,2,3,4 redundanten Platten, da kann nicht soviel schiefgehen.

    Schlussendlich könnt ihr dann machen was ihr wollt, ein DC hier, ein DC da, Fileserver für die Profile dort, Datashare wieder woanders usw. Und fällt ein physischer Server aus - egal, der  andre kann den sofort hochfahren und weiter betreiben. Ohne händischen Eingriff.

    Das nur so am Rande, was mein Tipp ist, ansonsten funktioniert das alles so wie du das vorhast - ausser das mit dem DHCP, autonomen DHCP Failover gibts erst seit Server 2012 :)

    Dienstag, 22. Januar 2013 18:53
  • Am 22.01.2013 schrieb Sebastian Wilczek:
    Hi,

    3. DHCP: Gibt es eine Möglichkeit ohne Failover Cluster? Sollte der DHCP ausserhalb des DHCP liegen?

    Ja, mit WIndows Server 2012 gibts da was.
    http://blog.iteach-online.de/index.php/2012/05/dhcp-failover-mit-windows-server-2012/
    oder
    http://www.faq-o-matic.net/2011/12/12/dhcp-failover-in-windows-server-8/

    HTH
    Norbert


    Dilbert's words of wisdom #19:
    Am I getting smart with you? How would you know?

    Mittwoch, 23. Januar 2013 10:28
  • Hallo Sebastian,

    zum Anfang: Du/ Ihr solltet euch wirklich erstmal Gedanken machen was ihr eigentlich wollt. Dein Plan klingt zwar auf den ersten Blick durchdacht, aber da gibts ein paar Fallstricke die es gerade in den Umgebungen die Ihr vorhabt zu bedenken gilt.

    Wenn ich das richtig verstanden habe ist euer Ziel Redundanz und Ausfallsicherheit - schön und gut, dann wollt ihr aber noch anfangen mit der Hand hin und her zu kopieren, was dann wieder vergessen wird, oder schiefgeht, oder oder oder und DFS ist dazu auch keine wirkliche Alternative.

    Lasst euch erstmal richtig von eurem IT Partner oder Systemhaus beraten. Bei der Virtualisierung kann ne Menge schiefgehen - gerade dann wenns das eigentlich nicht soll.

    Denkt erstmal über eure Server nach die ihr habt/ beschaffen wollt - geht das nicht günstiger? Brauch ich tastsächlich für 2 DCs, Fileserver und DHCP 2 vollausgestatte DL380 (nur als Beispiel) oder tuts auch was kleineres, das übrig gebliebene Geld kann man dann in ein Storage investieren und hat dann was richtiges. Was sich auszahlt. Mit einem richtigen (für eure Zwecke angemessenen) Array schlagt ihr viele Fliegen mit einer Klappe: Die Daten liegen auf einem zentralen Storage und können von beiden Servern angesprochen werden, die VHD´s (Schlussendlich die Daten und Betriebssysteme) sind für beide HyperV Server erreichbar, ohne lästiges kopieren etc.. Aber der Hauptvorteil ist eben das du in dem Storage Array nen einfaches RAID hast mit 1,2,3,4 redundanten Platten, da kann nicht soviel schiefgehen.

    Schlussendlich könnt ihr dann machen was ihr wollt, ein DC hier, ein DC da, Fileserver für die Profile dort, Datashare wieder woanders usw. Und fällt ein physischer Server aus - egal, der  andre kann den sofort hochfahren und weiter betreiben. Ohne händischen Eingriff.

    Das nur so am Rande, was mein Tipp ist, ansonsten funktioniert das alles so wie du das vorhast - ausser das mit dem DHCP, autonomen DHCP Failover gibts erst seit Server 2012 :)

    Klinke mich mal ein, wenn ich darf, habe ja mal ein ähnliches Thema eröffnet an dem ich noch rumstricke.

    @th.proehl

    1. Du kennst ja erstmal nicht die Anforderung, die Sebastian hat. Laufen vlt. noch weitere Server auf den Hosts? Denke ja mal nicht, dass er s ich 2 Hosts anschafft und darauf drei Gastmaschinen laufen lässt, da wird schon mehr hinterstecken. Ferner denke ich wohl auch, dass Sebastian selbst ITler ist, da finde ich es schon fast erniedrigend für ih zu lesen, dass er einen IT Dienstleister fragen soll.. Ich gehe mal davon aus, dass du auch nicht als MCITP geboren wurdest.

    2. Wenn du jetzt meinst, dass du mit einer Storage redundanter bist, dann hast du dich getäuscht. Selbst ich würde dann lieber mit 2 Hosts arbeiten und mir ein Fast Recovery Szenario bauen.

    @Sebastian:

    Warum kein 2. DHCP inplace auf dem DC in unterschiedlichen Bereichen (Subnetting)? Darüber schon Gedanken gemacht? Martin hat mir in meinem Thema auch zu DFSN geraten und per Robocopy die Daten auf ein 2. Share zu kopieren (ich arbeite dran :) ). Ich gehe mal davon aus, dass er das nicht zum Spaß gemacht hat.

    Mittwoch, 23. Januar 2013 13:07
  •  
    > Martin hat mir in meinem Thema auch zu DFSN geraten und per Robocopy
    > die Daten auf ein 2. Share zu kopieren (ich arbeite dran :) ). Ich
    > gehe mal davon aus, dass er das nicht zum Spaß gemacht hat.
     
    Nein, hat er nicht - er kennt die MS-Empfehlungen zu Roaming Profiles,
    Homesets und DFS-N/R fast auswendig :-D
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Mittwoch, 23. Januar 2013 13:53
  • SADFR,

    da hast du recht, ohne Frage. Als Erniedrigung war das nicht gedacht. Nur ist es bei vielen Dingen besser, gerade was die Hardware betrifft, mal mit Leuten zu sprechen die täglich damit zu tun haben. Beim normalen Systemmanagement und Client PC Wartungen verliert man auch die ein oder andere Sache aus der Serverhardwarewelt aus den Augen bzw. kann sich gar nicht damit beschäftigen. Ein unverbindliches Gespräch mit einer "Hardwarebude" ist in jedem Fall eine gute Idee, da die nüchtern dein Problem betrachten und auch mal Tipps oder Ideen haben in denen man viel anfangen kann bzw. man gar nicht daran gedacht hätte.

    Mit dem Array bin ich allerdings nicht deiner Meinung, du willst mir doch nicht erzählen das 2 phsysikalische Maschinen mit internem Speicher besser sind als ein externen Storage was nur das macht? Über Sinn oder Unsinn will ich hier nicht debattieren. Nur muss man mal drüber nachdenken wenn einem mal beide Phys. Server abschmieren. Wie flexibel man ist wenn alles auf einen oder zwei Blechen liegt.

    Ich wollte auf keinen Fall anmaßend wirken, wirklich nicht, die Fragen die gestellt worden sind haben mir nur implziert das da an vielen Ecken noch Nachholbedarf auf die ajktuellen Technologien besteht. Nen kleines Projekt ist das nämlich nicht was der TS vor hat.

    Wie dem auch sei, das ist meine Meinung dazu, und ich kann guten Gewissens sagen das das nicht die schlechteste is, wir haben schon einige erlebt die mit so einer o.g. Virtualisierung richtig abgeraucht sind. Entweder man virtualisiert richtig, oder man bastelt, wenn man bastelt darf man sich aber keine Hochverfügbarkeit und Langlebigkeit wünschen.

    Mittwoch, 23. Januar 2013 16:09
  • Mit dem Array bin ich allerdings nicht deiner Meinung, du willst mir doch nicht erzählen das 2 phsysikalische Maschinen mit internem Speicher besser sind als ein externen Storage was nur das macht? Über Sinn oder Unsinn will ich hier nicht debattieren. Nur muss man mal drüber nachdenken wenn einem mal beide Phys. Server abschmieren. Wie flexibel man ist wenn alles auf einen oder zwei Blechen liegt.

    Was die Ausfallsicherheit angeht will ich dir das definitiv sagen. Was hast du davon, wenn du eine Storage hast auf der alle VMS liegen und diese kracht ab? Dann geht rein gar nichts mehr! Wie hoch ist denn die Wahrscheinlichkeit, dass 2 physische Server gleichzeitig abschmieren? Eine Storage kann auch kaputt gehen! Dann habe ich definitiv lieber 2 Server, und wenn diese sogar leistungstechnisch benötigt werden, was spricht dagegen? Und mit einem Fast Recovery Szenario ist doch alles schnell überspielt.. Verstehe ich nicht ganz!

    ##

    "Zitat: ... was nur das macht)"

    Was heißt hier besser? Wozu brauchst du denn Storages? Weil sie redundanter sind als Server? Quatsch...

    Eine Storage (je nach Storage, die Rede ist von einem SAN!!) ist performanter und skalierbarer als interne VDs oder Backplanes an denen HDDS angeschlossen werden, auf denen ich VDs konfiguriere. Wobei das auch nur die halbe Wahrheit ist.

    Wenn meine internen VDs an einem SAS Controller hängen und ich gegenwärtig eine Storage Expansion (Intelligenz liegt im Server am HBA, ist eigentlich nichts Anderes als ein Raid Controller mit einem externen SAS Anschluß) mit einem SAS HBA nutze, dann rate doch mal was von beidem schneller ist.. Das ist genau das gleiche wie meine internen VDs, halt nur extern.

    Nutze ich eine richtige SAN (Intelligenz ist in der Storage, nicht im Server) als Storage und verbinde diese über einen oder mehrere FC HBAs, dann habe ich deutliche Perfomance-Vorteile aber immer noch keine Redundanz. Die erreiche ich erst, wenn ich minimun 2 Storages betreib. Aber noch nicht einmal dann habe ich eine Redundanz, die erreiche ich erst, wenn ich beide Storages aktiv fahre und das geht bekanntlich nur hochverfügbar mit Hardwarevirtualisierung, dann bin ich redundant. 2 Server, 4 FC HBAs, 2 SAN Switche, 2 SVCs, 2 Storages mit jeweils 2 Controllern. ABER bei beiden Lösungen (Storage Expansion, SAN) haben wir eine bessere Skalierbarkeit in Hinsicht auf Festplattengröße.

    ##

    Wollt hier keines Wegs ein Battle starten. Die Anforderung von Sebastian war doch klar vorgegeben, wenn ich mich da nicht irre. 2 Server auf Blech, 2 VDCs, ein bissl DHCP, Redundanz mit dem was wohl verfügbar ist, usw. Da er es nicht weiß (ich gehöre übrigens auch zu denen, die in der MS Welt bei Weitem nicht alles wissen) wie es geht, hat er sich wohl an uns gewandt.  Und da ich das Thema interessant finde und ebenfalls eine Lösung brauche, passt mir das Thema ganz gut.

    ##

    BTT

    @Sebastian: Wie schauts aus mit meiner Idee? Damit schon Erfahrungen gesammelt? Punkto Subnetting... Ich meine das mal irgendwann, irgendwo gelesen zu haben.. Wenn du bereits eine Lösung für dein Problem hast, dann lass mal hören. Ich habe eine ähnliche Umgebung, nur noch mit dem Vorteil, dass ich Storages zur Verfügung habe..

    Edit: Kann denn jemand noch etwas dazu schreiben? Im Bereich DHCP. Kann ich den bedenkenlos auf ein DC aufspielen? Kann ich hier mit Subnetting 2 Adressbereiche vergeben und die Server zur Verfügung stellen? Bsp: 1. DHCP auf DC1 Bereich: 192.168.0.x - 192.168.0.x; der 2. DHCP auf dem 2. DC vergibt 192.168.1.x - 192.168.1.x? Und die Server arbeiten dann in einem Subnetz, um über beide Netzwerk IDs erreichbar zu sein? Habe auch ein W2K8 und ein Umstieg auf 2012 ist gerade nicht geplant..


    • Bearbeitet SADFR Mittwoch, 23. Januar 2013 18:11
    Mittwoch, 23. Januar 2013 17:54
  • > Martin hat mir in meinem Thema auch zu DFSN geraten und per Robocopy
    > die Daten auf ein 2. Share zu kopieren (ich arbeite dran :) ). Ich
    > gehe mal davon aus, dass er das nicht zum Spaß gemacht hat.
    Nein, hat er nicht - er kennt die MS-Empfehlungen zu Roaming Profiles,
    Homesets und DFS-N/R fast auswendig :-D

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!

    Davon bin ich ausgegangen, über ein paar Tipps würde ich mich dennoch freuen. So richtig komme ich nicht weiter.. Jeder schreibt was Anderes und ich bin kein Windows Profi.
    Mittwoch, 23. Januar 2013 18:05
  • Wem die Server schon mal abgesoffen sind und die Storage im anderen Gebäude gestanden hat wird anders über sowas denken. Aber egal nun. Zu deinem Prob mit den DHCPs:

    Ja kannst du auch, du kannst sogar beide Zonen auf einem DHCP laufen lassen, du brauchst nur einen DHCP Relay Agent im anderen Netz der sich dann mit deinem DHCP verbindet. Beispiel: DHCP 1 steht in Netz 1 und verteilt 192.168.0.x - er ist also physisch mit dem 1. Netz verbunden. Soweit so klar. DHCP 2 steht im selben Netz wie DHCP eins hat aber -keine- IP in Netz 2, sondern ist wie DHCP 1 sagen wir unter der 192.168.0.5 erreichbar. Dann musst du aus dem 192.168.2.x Netz mit deinem Router (wenn der DHCP Relay kann [auch die meisten billig Geräte für den Midmarket können das]) einfach eintragen das der übergeordnete DHCP der 192.168.0.5 ist.

    Wenn jetzt aus Netz 1 eine Anfrage kommt geht die direkt an DHCP 1, soweit so klar, er ist im gleichen Subnetz, und verteilt dem zufolge auch IPs. Wenn nun aber ein Client aus Netz 2 nach einer IP Fragt (muss natürlich physisch getrennt sein) stellt er die Anfrage, dein Router antwortet und schickt die Anfrage aus Netz 2 an den DHCP weiter. Er sagt aber "Hey, ich hab zwar ne 192.168.0.x IP die Anfrage kam aber über meine Schnittstelle rein die an Netz 192.168.2.x hängt. Also gib mir keine 192.168.0.x IP sonder eine 192.168.2.x IP." Der DHCP stellt die IP aus, teilt diese dem Router mit und der wiederum gibt sie dem Client.

    Mittwoch, 23. Januar 2013 18:24
  • Wem die Server schon mal abgesoffen sind und die Storage im anderen Gebäude gestanden hat wird anders über sowas denken.

    Versteh ich immer noch nicht. Meinst du mit abgesoffen tatsächlich abgesoffen (unter Wasser?? ganz blöd gefragt), dann empfehle ich 2 grundlegend getrennte Bereiche, falls möglich, zu wählen. Es ist doch ganz egal, ob deine Server oder die Storage stirbt. Hast du keine echte Redundanz und die hast du nunmal nicht mit einer Storage, mehr habe ich nicht geschrieben, dann kann kaputt gehen was will, du stehst im Regen. Wenn mir von 2 Servern einer kracht, dann kann ich immer noch arbeiten, wenn auch mit ein wenig Handarbeit. Kracht mir eine Storage und ich habe nur eine, dann geht nichts mehr.. Das können wir drehen wir wollen und dabei ist es auch egal was mir in welchen Gebäude oder Brandschnittbereich kracht. Würde mich freuen, wenn du mir das Szenario genau erklärst. Ich bin System Archtitect und zuständig für den Aufbau hochverfügbarer Lösungen (im Bereich der HW, SW machen andere Leute), da würde es mich schon interessieren wie das genau von dir gemeint ist bevor wir einander vorbei schreiben!

    ##

    Zu deinem Vorschlag mit dem DHCP:

    Klingt nach einer Lösung, die ich suche. Verstehen werde ich das erst, wenn ich es mit eine paar Kollegen mal durchgehe.. Wobei mir schon auffällt, dass ich sicher nicht 2 Zonen auf einem DHCP laufen lassen würde, wenn DHCP auf DC läuft. Lieber 2 auf jeweils einem DC. Das Subnetting würden wir nur benutzen, um einen 2. DHCP ins Netz zu stellen falls der Andere ausgeht. Router haben wir einen Midrange zur Verfügung, Bintec. Der sollte DHCP Relay können.


    EDIT: Ich glaube ich habe mich missverständlich ausgedrückt: Ich versuche es nochmal: Wir habe ein paar Server insgesamt 12 meine ich, alle liegen im Netz 192.168.2, nun habe wir ein DHCP im gleichen Netz, jetzt möchte ich einen 2. DHCP haben, der nur zum Einsatz kommt, falls DHCP1 aus. Nun habe ich gelesen, dass ich DHCP nicht replizieren kann. Meine Idee wa ralso folgende: DHCPs im gleichen Netz, die unterschiedliche IPs verteilen; DHCP1 (wenn erreichbar ist Primärer DHCP) 192.168.2 und der DHCP2 (antwortet mit Verzögerung) 192.168.3; die Server konfiguriere ich in der Netzmaske so, dass Rechner aus beiden Netzen mit den Servern kommunizieren können.
    • Bearbeitet SADFR Mittwoch, 23. Januar 2013 18:53
    Mittwoch, 23. Januar 2013 18:45
  • OK.
    Das ist aber dann wieder basteln auf einem prof. Level. 

    Klar, DHCP kannste mit 2k8(R2) nicht redundant aufstellen. Aber 2 DHCP Server hinzustellen, im gleichen Netz, und die dann je nach dem welcher an ist andere IPs verteilen ist doch bei näherer Betrachtung schon etwas waghalsig. Das ist nicht nur in MS Netzen so sondern überall, und das soll auch nicht anmaßend klingen, aber eine schlechte Idee ist das trotzdem.

    Gehen wir doch mal so ran, was macht schon ein DHCP? Dynamisch IPs verteilen, die im DNS reggen, paar andere Dinge wie Gateway und DNS Server Einstellungen verteilen. Mehr nicht. Und dann soll das ganze, in einem Netz 2x vorgehalten werden mit 2 unterschiedlichen Konfigs. Weisste was da passieren kann? Bis du die Probleme die daraus resultieren gelöst hast ist der kaputte Server schon wieder repariert aus der Werkstatt da.Käse.

    Die DHCP "Datenbank" vom Windows DHCP kann man kopieren, das ist nur eine normale Datei im Dateisystem, genauso wie die (nicht AD integrierten) DNS Zonen als Textdatei vorliegen. Wieso dann nicht einfach diese Datei nehmen und in Zeitabstand X sichern. Wenn dann mal wirklich der DHCP ausfällt, nimmt man die gesicherte Datei, spaziert an den 2 DHCP, kopiert diese dort in das richtige Verzeichnis und startet den DHCP Dienst - zack - ist der 2 DHCP online, weiss das Selbe wie der Erste und tut das Gleiche. Das Ganze könnte man sich jetzt noch mit einem Script automatisieren und alles ist gut.

    Mittwoch, 23. Januar 2013 20:52
  •  
    > Davon bin ich ausgegangen, über ein paar Tipps würde ich mich dennoch
    > freuen. So richtig komme ich nicht weiter.. Jeder schreibt was Anderes
    > und ich bin kein Windows Profi.
     
    Kein WIndows-Profi? Na, da können wir helfen ;-)
     
    Was brauchst denn für "Tipps"? Oder wo gibt's Probleme? Vielleicht wäre
    dafür ein neuer Thread angebracht - mit DHCP hat das ja nicht mehr viel
    zu tun...
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Mittwoch, 23. Januar 2013 22:09
  • @th.proehl

    Da hat SADFR schon Recht. Die Hardware, die wir hier stehen haben, hat schon ihre Berechtigung. Da laufen noch ein paar Sachen mehr drauf, als das, was ich hier erwähnt habe. Aber das nur so am Rande... ;-)

    @SADFR

    Ja, so ähnlich habe ich mir das auch schon gedacht. Da ich in meinem bisherigen Subnet (sagen wir mal 192.168.2.0/24) kein Platz mehr für 2 DHCP-Bereiche (80/20 Teilung) habe, wollte ich das Subnet auf 192.168.2.0/22 erweitern, und dem einem DHCP den Bereich 192.168.2.0/24 zuweisen, und dem zweiten 192.168.3.0/24. Der zweite DHCP wird dann noch etwas verzögert, so dass die Arbeit bei dem ersten bleibt, solange der funktioniert. Fällt er aus, springt automatisch der zweite für ihn ein. Wollte nur schauen, ob hier jemand vielleicht noch ne andere, und vielleicht bessere Lösung hat. ;-)

    Donnerstag, 24. Januar 2013 08:50
  • > Martin hat mir in meinem Thema auch zu DFSN geraten und per Robocopy
    > die Daten auf ein 2. Share zu kopieren (ich arbeite dran :) ). Ich
    > gehe mal davon aus, dass er das nicht zum Spaß gemacht hat.
    Nein, hat er nicht - er kennt die MS-Empfehlungen zu Roaming Profiles,
    Homesets und DFS-N/R fast auswendig :-D

    Habe den Thread jetzt auch gefunden, und hab da die folgendes von Martin Binder gelesen:

    > 3. Überlegung: Profildaten werden per DFSN unter \\domain.local\profile zur Verfügung gestellt. Und nachts kopiert ein Task den Inhalt des Shares auf einen anderen Server. Fällt Server1 aus, kannst Du ganz einfach im DFSN das Target ändern und für die User ändert sich nix. Das gleiche für umgeleitete Ordner. Aber bitte OHNE DFS Replikation!

    Wo liegt da der Unterschied, ob ich die Daten nachts per Script kopiere, oder das DFS-R das für micht automatisch erledigt? Die Einschränkung von Microsoft ist, dass DFS-R nicht transanktionell arbeitet, sprich es kann sein, dass beim Umswitchen von dem einem Target auf das andere vielleicht nur ein Teil der Daten kopiert wurde, und das Profil dadurch unbrauchbar wird. Das kann mir aber auch genauso beim kopieren passieren. Und für den Fall kann ich mir ja meine Profile trotzdem nochmal nachts irgendwo sichern.

    Nicht falsch verstehen, das sollte jetzt kein Vorwurf sein, nur ne dumme Frage in den Raum geworfen... ;-)

    Donnerstag, 24. Januar 2013 09:15
  •  
    > Wo liegt da der Unterschied, ob ich die Daten nachts per Script
    > kopiere, oder das DFS-R das für micht automatisch erledigt?
     
    Wen ich es manuell (Skript) mache, habe ich vollständige Kontrolle: Was,
    wann, von wo nach wo, Log, Fehlerbehandlung etc.
    Wenn ich es DFSR machen lasse, ist das etwas "versteckter" - aber
    natürlich einfacher einzurichten, das stimmt. Und wenn Ihr mehrere
    Admins habt: Wehe einer ändert das Schedule :-))
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Donnerstag, 24. Januar 2013 16:31
  • > Davon bin ich ausgegangen, über ein paar Tipps würde ich mich dennoch
    > freuen. So richtig komme ich nicht weiter.. Jeder schreibt was Anderes
    > und ich bin kein Windows Profi.
    Kein WIndows-Profi? Na, da können wir helfen ;-)
    Was brauchst denn für "Tipps"? Oder wo gibt's Probleme? Vielleicht wäre
    dafür ein neuer Thread angebracht - mit DHCP hat das ja nicht mehr viel
    zu tun...

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!

    Na darauf freue ich mich schon, habe z.Z. einfach sooo viele Baustellen, dass ich nicht weiß wo ich anfangen soll. Wir ersticken vor Arbeit.... Jetzt darf ich mich schon um Windows Dinge kümmern wo doch jeder hier weiß, dass ich das nicht beherrsche... Uns fehlen MA!! Und Gute MA bekommt mein Chef wohl ganz schlecht! Wir sollten ein neues Forum "Mitarbeiter gesucht" eröffnen! :)

    Ich möcht nicht wegen jeder Kleinigkeit hier irgendwelche Fragen stellen, darum wollt ich erst ein wenig testen, lernen und wenn dann konkrete Fragen bestehen, dann werd ich noch einmal ein Thread eröffnen, denn das Forum ist ja nicht da, damit du kostenlose Schulungen an uns bringst! ;) Aber vielen Dank, dein Angebot nehme ich dankend an!

    Donnerstag, 24. Januar 2013 18:07
  • OK.
    Das ist aber dann wieder basteln auf einem prof. Level. 

    Klar, DHCP kannste mit 2k8(R2) nicht redundant aufstellen. Aber 2 DHCP Server hinzustellen, im gleichen Netz, und die dann je nach dem welcher an ist andere IPs verteilen ist doch bei näherer Betrachtung schon etwas waghalsig. Das ist nicht nur in MS Netzen so sondern überall, und das soll auch nicht anmaßend klingen, aber eine schlechte Idee ist das trotzdem.

    Gehen wir doch mal so ran, was macht schon ein DHCP? Dynamisch IPs verteilen, die im DNS reggen, paar andere Dinge wie Gateway und DNS Server Einstellungen verteilen. Mehr nicht. Und dann soll das ganze, in einem Netz 2x vorgehalten werden mit 2 unterschiedlichen Konfigs. Weisste was da passieren kann? Bis du die Probleme die daraus resultieren gelöst hast ist der kaputte Server schon wieder repariert aus der Werkstatt da.Käse.

    Die DHCP "Datenbank" vom Windows DHCP kann man kopieren, das ist nur eine normale Datei im Dateisystem, genauso wie die (nicht AD integrierten) DNS Zonen als Textdatei vorliegen. Wieso dann nicht einfach diese Datei nehmen und in Zeitabstand X sichern. Wenn dann mal wirklich der DHCP ausfällt, nimmt man die gesicherte Datei, spaziert an den 2 DHCP, kopiert diese dort in das richtige Verzeichnis und startet den DHCP Dienst - zack - ist der 2 DHCP online, weiss das Selbe wie der Erste und tut das Gleiche. Das Ganze könnte man sich jetzt noch mit einem Script automatisieren und alles ist gut.


    Wäre eine Alternative! Wenn man das Ganze Scriptbasiert steuern kann, dann wäre ich damit glücklich. Wobei ich immer noch am Rätseln bin was mein Vorschlag für Probleme mit sich bringt! Subnetting ist doch in jeder mittelständischen Bude Alltag. Bin kein Freund davon zu lesen, dass es Probleme damit gibt, würde eher erfahren warum! Gibt es irgendwelche Konkreten Aussagen dafür?
    Donnerstag, 24. Januar 2013 18:10
  • Mach dafür doch bitte einen neuen Thread auf. Wir haben uns schon zu weit vom Thema des TS entfernt. Aber bitte red nicht hochtrabend und Heil bringend vom Subnetting. Du hast für beide Möglichkeiten eine Lösung geboten bekommen, 2 DHCP Server in 2 Subnetzen, und zwei DHCP Servern in einem Subnetz. Wenn du nichts von Problemen sondern nur von Lösungen hören willst biste bei mir zumindest leider falsch. Wir machen das hier nämlich freiwillig und aus Spass an der Sache und nicht um umsonst IT Consulting Dienste anzubieten. http://www.tech-faq.com/dhcp.html
    Donnerstag, 24. Januar 2013 21:39
  • > Wo liegt da der Unterschied, ob ich die Daten nachts per Script
    > kopiere, oder das DFS-R das für micht automatisch erledigt?
    Wen ich es manuell (Skript) mache, habe ich vollständige Kontrolle: Was,
    wann, von wo nach wo, Log, Fehlerbehandlung etc.
    Wenn ich es DFSR machen lasse, ist das etwas "versteckter" - aber
    natürlich einfacher einzurichten, das stimmt. Und wenn Ihr mehrere
    Admins habt: Wehe einer ändert das Schedule :-))

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!

    Ja, da stimme ich Dir zu 100% zu. Ich hab dir vollständige Kontrolle (die gebe ich eh sehr ungern ab :-D), und dass DFS-R einfacher einzurichten ist, ist für mich auch nur zweitrangig. Der Hauptgrund für mich wäre der automatische Failover, falls mal der Server mit den Userprofilen ausfallen sollte, und hier grad kein Admin greifbar ist, weil sie mit anderen Sachen beschäftigt sind.
    Freitag, 25. Januar 2013 08:27
  • @th.proehl und SADFR

    Ihr könnt ruhig weiter diskuttieren. Schließlich habe ich auch nach Tipps für DHCP gefragt, und vielleicht kommt man ja noch zu anderen Lösungesansätzen. ;-)

    Dein Vorschlag, th.proehl, mit dem Kopieren der DHCP Datenbank klingt zwar auch sehr gut, aber wie ich schon zu Martin gesagt habe, eine Lösung mit einem automatischen Failover wäre mir am liebsten. ;-) Ich glaube, ich bleibe bei meiner ursprünglichen Idee, das Subnetz zu erweitern und in zwei Bereiche aufzuteilen.

    Freitag, 25. Januar 2013 09:02
  •  
    > Der Hauptgrund für mich wäre der automatische Failover, falls mal der
    > Server mit den Userprofilen ausfallen sollte, und hier grad kein Admin
    > greifbar ist, weil sie mit anderen Sachen beschäftigt sind.
     
    Das mußt eh skripten - DFSN mit 2 Targets ist verboten, also müßtest Du
    im DFSN sowieso das Verweisziel ändern. Und wenn ein Server ausfällt,
    der zudem noch existentiell ist - naja, wenn dann kein Admin greifbar
    ist, dann ist was falsch organisiert :-)
     
    mfg Martin
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Freitag, 25. Januar 2013 12:33
  • Wir machen das hier nämlich freiwillig und aus Spass an der Sache und nicht um umsonst IT Consulting Dienste anzubieten. http://www.tech-faq.com/dhcp.html

    LOL!

    In einem Forum werden Probleme aber auch diskutiert und nicht einfach Behauptungen in den Raum geschmissen! Die Frage war, ob es konkrete Empfehlungen von MS zu diesem Thema gibt, und nicht, ob du mich kostenlos beraten kannst!
    • Bearbeitet SADFR Freitag, 25. Januar 2013 16:35
    Freitag, 25. Januar 2013 16:32
  • Ja, und die gab ich dir, das willst du aber nicht hören. Weil du es besser weißt.
    http://technet.microsoft.com/en-us/library/cc780311(v=ws.10).aspx
    Freitag, 25. Januar 2013 20:09
  • Ja, und die gab ich dir, das willst du aber nicht hören. Weil du es besser weißt.
    http://technet.microsoft.com/en-us/library/cc780311(v=ws.10).aspx

    Wenn ich es besser wüsste, dann würde ich nicht fragen.

    Mal davon ab gilt dein Link für Win2k3.

    Ich habe mich ein wenig missverständlich ausgedrückt, in dem ich schrieb, ob es Empfehlungen von MS zu diesem Thema gibt. Gemeint war warum es NICHT empfohlen wird mit 2 DHCP Servern zu arbeiten, die unterschiedliche Adressbereiche verteilen, denn genau das hast du kritisiert.

    Aber lassen wir das, ich werde es einfach in einer TEstumgebung probieren, mich im Technet schlaulesen und mich dann nochmal dazu melden. Denn gerade drehen wir uns im Kreis... Danke erstmal!

    Samstag, 26. Januar 2013 09:30
  • Hi,

    Am 26.01.2013 10:30, schrieb SADFR:

    Gemeint war warum es NICHT empfohlen wird mit 2 DHCP Servern zu
    arbeiten, die unterschiedliche Adressbereiche verteilen

    Sorry, ich habe nicht komplett mitgelesen, aber die 80/20 Regel ist seit Jahren der Klassiker für redundanz im DHCP Umfeld.
    Gibt es auch von MS als KB Artikel. Erst mit dem 2008 oder 2008 R2?
    ist der DHCP von MS Cluster tauglich und mit dem Moment präferieren sie natürlich diese Lösung anstelle der "alten".

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Samstag, 26. Januar 2013 11:13
  • In der Tat, aber: was für Server 2003 gilt, hat auch für 2008 und 2008 R2 noch Bestand. An dem 2008er DHCP hat sich ausser ein bisschen Optik und der IPv6 Unterstützung nichts geändert.
    Samstag, 26. Januar 2013 11:32
  • Hi,

    Am 26.01.2013 12:32, schrieb th.proehl:

    An dem 2008er DHCP hat sich ausser ein bisschen Optik und der IPv6
    Unterstützung nichts geändert.

    Das ist das Team anderer Meinung ;-)
    http://blogs.technet.com/b/teamdhcp/archive/2009/02/26/new-features-in-dhcp-for-windows-server-2008-r2-windows-7.aspx

    SCNR

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Samstag, 26. Januar 2013 19:55
  • Hi,

    Am 26.01.2013 10:30, schrieb SADFR:

    Gemeint war warum es NICHT empfohlen wird mit 2 DHCP Servern zu
    arbeiten, die unterschiedliche Adressbereiche verteilen

    Sorry, ich habe nicht komplett mitgelesen, aber die 80/20 Regel ist seit Jahren der Klassiker für redundanz im DHCP Umfeld.
    Gibt es auch von MS als KB Artikel. Erst mit dem 2008 oder 2008 R2?
    ist der DHCP von MS Cluster tauglich und mit dem Moment präferieren sie natürlich diese Lösung anstelle der "alten".

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Gemeint ist wohl dieses hier:

    http://blogs.technet.com/b/windowsservergermany/archive/2009/09/23/hochverf-gbarkeit-f-r-dhcp-optionen-f-r-windows-server.aspx

    Split Scope (Hot Stand-By)

    Das liest sich für mich sehr gut. Dann werde ich die Idee mit dem Subnetting wohl streichen wobei ich immer noch nichts wirklich Gegenwärtiges seitens MS gelesen habe. Denn was passiert, wenn Einem die Adressen ausgehen? Das Ganze Netz umzustellen ist hierbei sehr aufwändig.

    Sonntag, 27. Januar 2013 12:30
  • Hi,

    Am 27.01.2013 13:30, schrieb SADFR:

    Gemeint ist wohl dieses hier: [...] Split Scope (Hot Stand-By)

    genau. als 80/20 findest du aber "gegooglet" mehr dazu ;-)

    [...] Denn was passiert, wenn Einem die Adressen ausgehen? Das Ganze Netz
    umzustellen ist hierbei sehr aufwändig.

    Naja, das du eine Client "Explosion" erlebst ist doch wohl eher selten oder?
    Wenn dir jetzt schon 250 Adressen "zu wenig" sind dann ist das klassische Class C warhscheinlich sowieso nicht das richtige für dich.

    Es schadet ja nicht mit 512 oder mehr hosts von Anfang an zu planen, das einzig unbequeme ist ja eigentlich nur die Dezimaldarstellung der Adressen.

    Viele Firmen, die ich kenne sind da hemmungslos und verwenden von deswegen ein Class B, damit die Dezimalzahlen schön bleiben und die Summe immer ausreicht ... Du kannst ja den Verteilungs scope erst mal einschränken, man muss ja nicht gleich 65000 Adressen verteilen.

    Beim Class B kannst du wahrscheinlich auch locker mit der 80/20 Regel selbst bei 20% noch das ganze Netz betreiben, ohne daß Clients keine IP mehr kriegen könnten ;-)

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Sonntag, 27. Januar 2013 14:03
  • Hi,

    Am 27.01.2013 13:30, schrieb SADFR:

    Gemeint ist wohl dieses hier: [...] Split Scope (Hot Stand-By)

    genau. als 80/20 findest du aber "gegooglet" mehr dazu ;-)

    [...] Denn was passiert, wenn Einem die Adressen ausgehen? Das Ganze Netz
    umzustellen ist hierbei sehr aufwändig.

    Naja, das du eine Client "Explosion" erlebst ist doch wohl eher selten oder?
    Wenn dir jetzt schon 250 Adressen "zu wenig" sind dann ist das klassische Class C warhscheinlich sowieso nicht das richtige für dich.

    Es schadet ja nicht mit 512 oder mehr hosts von Anfang an zu planen, das einzig unbequeme ist ja eigentlich nur die Dezimaldarstellung der Adressen.

    Viele Firmen, die ich kenne sind da hemmungslos und verwenden von deswegen ein Class B, damit die Dezimalzahlen schön bleiben und die Summe immer ausreicht ... Du kannst ja den Verteilungs scope erst mal einschränken, man muss ja nicht gleich 65000 Adressen verteilen.

    Beim Class B kannst du wahrscheinlich auch locker mit der 80/20 Regel selbst bei 20% noch das ganze Netz betreiben, ohne daß Clients keine IP mehr kriegen könnten ;-)

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm


    Ja da hast du schon Recht! Wir sind aber mittlerweile schon bei ca. 10 Maschinen, mehreren Managed Switches für unsere Uplinks, einigen VOIP Geräten, TK Anlage, USVs, etc. Da sind 250 Adressen schon nicht mehr so viel.. Aber wenns halt nicht reicht, dann muss eben gewechselt werden. Es sind ja ca 150 Clients. Man kann ja auch 50/50 konfigurieren, stimmts?
    Wenn dann der 1. DHCP keine Adressen mehr frei hat, dan würde der 2. welche vergeben, richtig?
    • Bearbeitet SADFR Sonntag, 27. Januar 2013 15:57
    Sonntag, 27. Januar 2013 15:56
  • Hi,

    Am 27.01.2013 16:56, schrieb SADFR:

    Man kann ja auch 50/50 konfigurieren, stimmts?

    Logisch. Das Verhältnis suchst du dir selber aus anhand der notwendigen freien IPs und der Anzahl die er verteilen können soll im Ausfall.

    Aber mal anders betrachtet:
    Wenn der DHCP ausfällt ist der höchstens einen (halben?) Tag weg, die meisten deiner Clients haben ja noch eine IP und behalten diese, die "neuanfragen" sind idR sehr gering.
    Selbst wenn der Server ganz ausfällt, die DHCP Datenbank kriegst du idR ganz schnell auf einen anderen. DHCP ist zwar kritisch, aber sicherlich nicht im High-Availability Bereich, der dir zuviele Sorgen machen sollte.

    Wie lange brauchst du um im Fehlerfall einen nagelneuen hinzustellen?
    30 Minuten? 60 Minuten? Die ZEit muss der 2te DHCP überbrücken ... Don´t Panic!

    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Sonntag, 27. Januar 2013 16:04
  • Hi,

    Am 27.01.2013 16:56, schrieb SADFR:

    Man kann ja auch 50/50 konfigurieren, stimmts?

    Logisch. Das Verhältnis suchst du dir selber aus anhand der notwendigen freien IPs und der Anzahl die er verteilen können soll im Ausfall.

    Aber mal anders betrachtet:
    Wenn der DHCP ausfällt ist der höchstens einen (halben?) Tag weg, die meisten deiner Clients haben ja noch eine IP und behalten diese, die "neuanfragen" sind idR sehr gering.
    Selbst wenn der Server ganz ausfällt, die DHCP Datenbank kriegst du idR ganz schnell auf einen anderen. DHCP ist zwar kritisch, aber sicherlich nicht im High-Availability Bereich, der dir zuviele Sorgen machen sollte.

    Wie lange brauchst du um im Fehlerfall einen nagelneuen hinzustellen?
    30 Minuten? 60 Minuten? Die ZEit muss der 2te DHCP überbrücken ... Don´t Panic!

    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Auch da gebe ich dir Recht. Aber man weiß ja nie wann das passiert. Um noch das DHCP Problem aus dem Weg zu gehen, kann man doch auch die Leasetime relativ hoch setzen oder gibt es dabei Probleme?

    Folgendes Szenario:

    Client001 holt sich Montag morgens 07.00h von DHCP1 eine IP, Leasetime eine Woche.

    Dienstag morgen ist DHCP1 nicht verfügbar, DHCP2 kommt zum Einsatz, Client001 schaltet ein, und arbeitet noch mit der IP von Montag morgen vom DHCP1? Wird da nicht noch einmal etwas beim DHCP trotz gültigem Lease abgefragt?

    Sonntag, 27. Januar 2013 16:16
  • Folgendes Szenario:

    Client001 holt sich Montag morgens 07.00h von DHCP1 eine IP, Leasetime eine Woche.

    Dienstag morgen ist DHCP1 nicht verfügbar, DHCP2 kommt zum Einsatz, Client001 schaltet ein, und arbeitet noch mit der IP von Montag morgen vom DHCP1? Wird da nicht noch einmal etwas beim DHCP trotz gültigem Lease abgefragt?

    Der Client001 fragt nach Ablauf der halben Lease beim DHCP nochmal nach. Ist dieser erreichbar, behält er seine IP, und die Lease startet wieder neu. Sollte der DHCP nicht erreichbar sein, fragt er nochmal nach der Hälfte der verblienenen Zeit (also 3/4 der Lease) an. Ist der DHCP immernoch nicht erreichbar, versucht der Client001 einen anderen DHCP zu finden und holt sich eine neue IP.

    Auf der anderen Seite, fordert der DHCP am Ende der Lease die vergebene IP wieder zurück.

    Montag, 28. Januar 2013 08:54
  • @Mark

    Davon mal abgesehen ;). Man ist aber trotzdem in der Lage mit einer 2003er Anleitung den 2008R2 DHCP zu konfigurieren.

    Asche aufs Haupt, ich wollte das Team nicht beleidigen. ;)

    Montag, 28. Januar 2013 10:23
  • Hi,

    Am 28.01.2013 11:23, schrieb th.proehl:

    Asche aufs Haupt, ich wollte das Team nicht beleidigen. ;)

    Ich denke die können das haben ;-) heheeeheee

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Montag, 28. Januar 2013 14:10