11
Domänencontroller virtualisieren - zusätzlichen physischen Server?
Guten Abend,
Ich stehe vor der Migration von Windows Server 2019 und frage mich momentan, wie ich am besten meine DCs aufstelle.
Meine Umgebung besteht aus momentan aus 5 Standorten, in der Zentrale stehen zwei physische DCs, einer noch auf Windows Server 2008 R2, der Zweite mit 2012 R2
Idee 1:
Ein physischer DC mit allen FSMO Rollen / PDC und ein Hyper-V-Host mit zusätzlichem DC
Idee 2:
Zwei Hyper-V Hosts mit je einem DC, einer davon trägt dann alle Rollen inne
Diverse Beiträge meinen nach wie vor, dass es zumindest einen physischen DC geben sollte, ist dies bei Win Server 2019 nach wie vor so?
Idee 2 gefällt mir natürlich besser aufgrund des zusätzlichen VM-Rechts und der Sicherungsmöglichkeit mit Veeam.
Wie seht ihr das?
Grüße,
Nomad
Ich stehe vor der Migration von Windows Server 2019 und frage mich momentan, wie ich am besten meine DCs aufstelle.
Meine Umgebung besteht aus momentan aus 5 Standorten, in der Zentrale stehen zwei physische DCs, einer noch auf Windows Server 2008 R2, der Zweite mit 2012 R2
Idee 1:
Ein physischer DC mit allen FSMO Rollen / PDC und ein Hyper-V-Host mit zusätzlichem DC
Idee 2:
Zwei Hyper-V Hosts mit je einem DC, einer davon trägt dann alle Rollen inne
Diverse Beiträge meinen nach wie vor, dass es zumindest einen physischen DC geben sollte, ist dies bei Win Server 2019 nach wie vor so?
Idee 2 gefällt mir natürlich besser aufgrund des zusätzlichen VM-Rechts und der Sicherungsmöglichkeit mit Veeam.
Wie seht ihr das?
Grüße,
Nomad
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 504543
Url: https://administrator.de/contentid/504543
Ausgedruckt am: 25.11.2024 um 18:11 Uhr
11 Kommentare
Neuester Kommentar
Hallo
wir haben Idee 2 am laufen. Rennt problemlos.
3 mal Blech mit div VMs - 2 davon sind reine DCs
so Long
Yumper
wir haben Idee 2 am laufen. Rennt problemlos.
3 mal Blech mit div VMs - 2 davon sind reine DCs
so Long
Yumper
Moin,
wir haben 2 DC's. Eine dedizierte Maschine, die auch die Datensicherungen durchführt und eine VM, die die FSMO Rollen innehat und DHCP spielt.
Das Ganze läuft einheitlich auf Win2016.
Gruß
Thomas
wir haben 2 DC's. Eine dedizierte Maschine, die auch die Datensicherungen durchführt und eine VM, die die FSMO Rollen innehat und DHCP spielt.
Das Ganze läuft einheitlich auf Win2016.
Gruß
Thomas
Moin,
wir setzen schon seit Jahren auf rein virtuelle DC.
Wichtig ist halt, das man mehrere DC hat, die voneinander unabhängig funktionieren! Ob die dann physisch oder virtuell laufen spielt dann gar keine Rolle.
Gruß
Dirk
wir setzen schon seit Jahren auf rein virtuelle DC.
Wichtig ist halt, das man mehrere DC hat, die voneinander unabhängig funktionieren! Ob die dann physisch oder virtuell laufen spielt dann gar keine Rolle.
Gruß
Dirk
Moin ,
wir haben je einen physischen DC an den Hauptstandorten. Dann jeweils einen virtuell an jedem Hauptstandort.
An den Nebenstandorten alles virtuell.
Gruss
wir haben je einen physischen DC an den Hauptstandorten. Dann jeweils einen virtuell an jedem Hauptstandort.
An den Nebenstandorten alles virtuell.
Gruss
Zitat von @Looser27:
wir haben 2 DC's. Eine dedizierte Maschine, die auch die Datensicherungen durchführt und eine VM, die die FSMO Rollen innehat und DHCP spielt.
Das Ganze läuft einheitlich auf Win2016.
wir haben 2 DC's. Eine dedizierte Maschine, die auch die Datensicherungen durchführt und eine VM, die die FSMO Rollen innehat und DHCP spielt.
Das Ganze läuft einheitlich auf Win2016.
Warum nicht DHCP Failover nutzen!?
Funktioniert seit W2012 wunderbar. Dann kann man auch wunderbar mal einen der DHCP-Server im laufenden Betrieb rebooten (z.B. Wartung).
Hallo,
das man DCs redundant aufbaut, ist sicher klar. Egal ob rein virtuell oder gemischt.
Das Problem ist das Management der VM-Umgebung! Ist das Management der VM-Umgebung in die Domäne integriert (in Windows-Umgebungen mit Hyper-V meist der Fall), muß man sich zur Administration der VMs an der Domäne autentifizieren. Wenn der DC und damit die Domäne nicht verfügbar ist, kann man im schlimmsten Fall den DC als VM nicht administrieren. Ein typisches "Henne - Ei" - Problem.
Man muss in einer solchen Konstellation also immer gewährleisten, dass man einen DC auch ohne die Möglichkeit der Domänen-Anmeldung managen kann. Dabei ist es unerheblich, ob der DC nun eine VM ist oder ein "Blech".
Ich arbeite mit VMware und da ist das möglich. Deshalb können bei mir die DCs alle als VM laufen.
Jürgen
das man DCs redundant aufbaut, ist sicher klar. Egal ob rein virtuell oder gemischt.
Das Problem ist das Management der VM-Umgebung! Ist das Management der VM-Umgebung in die Domäne integriert (in Windows-Umgebungen mit Hyper-V meist der Fall), muß man sich zur Administration der VMs an der Domäne autentifizieren. Wenn der DC und damit die Domäne nicht verfügbar ist, kann man im schlimmsten Fall den DC als VM nicht administrieren. Ein typisches "Henne - Ei" - Problem.
Man muss in einer solchen Konstellation also immer gewährleisten, dass man einen DC auch ohne die Möglichkeit der Domänen-Anmeldung managen kann. Dabei ist es unerheblich, ob der DC nun eine VM ist oder ein "Blech".
Ich arbeite mit VMware und da ist das möglich. Deshalb können bei mir die DCs alle als VM laufen.
Jürgen
Moin,
da hat wohl jeder sein eigenes "Best Practice". Imho:
Das kannst du beides so machen, wobei ich bei "Idee 1" die FSMO-Rollen auf die VM packen würde, zwecks schnellerer und einfacherer Wiederherstellung.
Spricht aber auch nichts gegen Idee 2.
Das ein physischer DC vorhanden sein muss, kommt imho noch aus Anfängen der Virtualisierung als man noch Sorgen hatte, dass hier irgendwas schief läuft und man vllt. auch nur einen VM-Host hatte. Da gab es dann auch noch das zusätliche Problem, dass der Host beim booten ja keinen DC findet, wenn dieser als VM auf ihn selbst lief.
Gruß
da hat wohl jeder sein eigenes "Best Practice". Imho:
Das kannst du beides so machen, wobei ich bei "Idee 1" die FSMO-Rollen auf die VM packen würde, zwecks schnellerer und einfacherer Wiederherstellung.
Spricht aber auch nichts gegen Idee 2.
Das ein physischer DC vorhanden sein muss, kommt imho noch aus Anfängen der Virtualisierung als man noch Sorgen hatte, dass hier irgendwas schief läuft und man vllt. auch nur einen VM-Host hatte. Da gab es dann auch noch das zusätliche Problem, dass der Host beim booten ja keinen DC findet, wenn dieser als VM auf ihn selbst lief.
Gruß
Vielen Dank für die zahlreichen Reaktionen, hilft mir sehr weiter und ich tendiere zu Idee 2, das würde mir jedenfalls schon mal ein Blech einsparen.
Speziell zum Thema Administrieren des Hosts, wenn er ein Mitglied der Domäne ist und der DC down ist:
Ist dafür nicht dann im Zweifel der zweite DC auf einem anderen Host da? Blöd ist dann nur wenn beide down gehen müssen wegen z.B einem längeren Stromausfall. Hilft da im Zweifel nicht die automatische Startaktion der VMs?
Speziell zum Thema Administrieren des Hosts, wenn er ein Mitglied der Domäne ist und der DC down ist:
Ist dafür nicht dann im Zweifel der zweite DC auf einem anderen Host da? Blöd ist dann nur wenn beide down gehen müssen wegen z.B einem längeren Stromausfall. Hilft da im Zweifel nicht die automatische Startaktion der VMs?
Zitat von @NomadD:
Speziell zum Thema Administrieren des Hosts, wenn er ein Mitglied der Domäne ist und der DC down ist:
Ist dafür nicht dann im Zweifel der zweite DC auf einem anderen Host da?
Speziell zum Thema Administrieren des Hosts, wenn er ein Mitglied der Domäne ist und der DC down ist:
Ist dafür nicht dann im Zweifel der zweite DC auf einem anderen Host da?
Ja, ist er. Daher kann man das auch so machen.
Blöd ist dann nur wenn beide down gehen müssen wegen z.B einem längeren Stromausfall. Hilft da im Zweifel nicht die automatische Startaktion der VMs?
Die Startaktion Hilft in diesem Falle nicht, da die VM ja erst startet, wenn der Host hochgefahren ist. Aber selbst das ist zumindest bei WinSrv2016/Hyper-V eigentlich kein Problem. Der Host braucht dann einfach nur länger zum Starten, weil er erstmal einen DC sucht, aber keinen findet. Gruppenrichtlinien werden dann natürlich nicht verarbeitet, aber da sollte es ja vermutlich eh keine Änderungen vor dem Stromausfall gegeben haben, die relevant wären.
Das einzige Problem, das ich in diesem Zusammenhang kenne ist, dass das Netzwerk ohne DNS nicht ordentlich erkannt und dadurch auf "Öffentlich" steht. Dadurch gelten dann andere Win-Firewallregeln und man kommt u.U. z.B. per RDP drauf (betrifft aber nur den Host, nicht die VMs, sofern diese später als der DC starten). Aber selbst dagegen kann man vorbeugen, falls das Problem überhaupt noch so auftriff (ist schon eine Weile her).
Meine Hosts sind alle in der Domäne, damit ich auch mal eine VM bequem verschieben kann oder ein VM Cluster fahren kann. Nachdem die Server alle IPMI haben, kann ich mich immer lokal darauf verbinden, auch, wenn alle DC VMs down wären. Außerdem habe ich noch eine DC VM in einer Niederlassung über WAN. Ich sehe kein Risiko/Problem/Gefahr.
Genau so habe ich es nun auch gelöst und jeweils einen virtuellen Host mit einem virtuelle DC, dazu einen DC auf Blech in einer weiteren Filiale. Vielen Dank, auch wenn die Antwort spät kommt! 
1
