15
Domaincontroller physikalisch oder virtuell??
Hallo Leute,
ich weiß, dass das Thema bereits in einem anderen Zusammenhang bereits behandelt wurde. Hier meine Frage: Bei uns in der Firma läuft in ein paar Monaten der Support von einem physikalischen Server (auf dem ein Domain Controller) aus. 3 weitere Domain Controller laufen bereits virtuell. Die virtuellen Server laufen in einer sicheren VM Ware Umgebung (Redundanter Speicher etc.) Die Frage die sich mir stellt, ist ob wir diesen durch einen physikalischen Server ersetzen sollen oder auf die Virtualisierung setzen sollten und diese weiter virtuell zu betreiben. Der physikalische Server ist nur ein Member Server (kein PDC, RID etc.) mit einem Global Catalog.
Setzt Ihr weiter auf die komplett Virtualisierung der Domain Controller? Oder setzt Ihr in eurer Umgebung mind. noch einen physikalischen Domain Controller weiter ein?
Ich kann leider schwer abschätzen wo die Vor- und Nachteile bei beiden liegen.
Vielen Dank im vorraus für euer Feedback
Gruß
Klauser
ich weiß, dass das Thema bereits in einem anderen Zusammenhang bereits behandelt wurde. Hier meine Frage: Bei uns in der Firma läuft in ein paar Monaten der Support von einem physikalischen Server (auf dem ein Domain Controller) aus. 3 weitere Domain Controller laufen bereits virtuell. Die virtuellen Server laufen in einer sicheren VM Ware Umgebung (Redundanter Speicher etc.) Die Frage die sich mir stellt, ist ob wir diesen durch einen physikalischen Server ersetzen sollen oder auf die Virtualisierung setzen sollten und diese weiter virtuell zu betreiben. Der physikalische Server ist nur ein Member Server (kein PDC, RID etc.) mit einem Global Catalog.
Setzt Ihr weiter auf die komplett Virtualisierung der Domain Controller? Oder setzt Ihr in eurer Umgebung mind. noch einen physikalischen Domain Controller weiter ein?
Ich kann leider schwer abschätzen wo die Vor- und Nachteile bei beiden liegen.
Vielen Dank im vorraus für euer Feedback
Gruß
Klauser
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 242244
Url: https://administrator.de/contentid/242244
Printed on: April 19, 2024 at 01:04 o'clock
15 Comments
Latest comment
Zitat von @klauser77:
Hallo Leute,
ich weiß, dass das Thema bereits in einem anderen Zusammenhang bereits behandelt wurde. Hier meine Frage: Bei uns in der
Firma läuft in ein paar Monaten der Support von einem physikalischen Server (auf dem ein Domain Controller) aus. 3 weitere
Domain Controller laufen bereits virtuell. Die virtuellen Server laufen in einer sicheren VM Ware Umgebung (Redundanter Speicher
etc.) Die Frage die sich mir stellt, ist ob wir diesen durch einen physikalischen Server ersetzen sollen oder auf die
Virtualisierung setzen sollten und diese weiter virtuell zu betreiben. Der physikalische Server ist nur ein Member Server (kein
PDC, RID etc.) mit einem Global Catalog.
???Hallo Leute,
ich weiß, dass das Thema bereits in einem anderen Zusammenhang bereits behandelt wurde. Hier meine Frage: Bei uns in der
Firma läuft in ein paar Monaten der Support von einem physikalischen Server (auf dem ein Domain Controller) aus. 3 weitere
Domain Controller laufen bereits virtuell. Die virtuellen Server laufen in einer sicheren VM Ware Umgebung (Redundanter Speicher
etc.) Die Frage die sich mir stellt, ist ob wir diesen durch einen physikalischen Server ersetzen sollen oder auf die
Virtualisierung setzen sollten und diese weiter virtuell zu betreiben. Der physikalische Server ist nur ein Member Server (kein
PDC, RID etc.) mit einem Global Catalog.
Du meinst sicher nicht "Member Server", sondern er ist ein "einfacher" DC, ohne Rollen, mit Ausnahme des GC. Einer wichtigen Rollen ....
Setzt Ihr weiter auf die komplett Virtualisierung der Domain Controller? Oder setzt Ihr in eurer Umgebung mind. noch einen
physikalischen Domain Controller weiter ein?
Ich kann leider schwer abschätzen wo die Vor- und Nachteile bei beiden liegen.
Die ESX an sich sind auch redundant? Also mehrere ESX im Cluster mit lizensiertem HA?physikalischen Domain Controller weiter ein?
Ich kann leider schwer abschätzen wo die Vor- und Nachteile bei beiden liegen.
Wir haben bei uns ca. 30 DC's als VM und einen als Hardware. Der Grund für letzteren ist einfach die Tatsache, dass er auch DNS-Server ist und sich die Wartung der ganzen Infrastruktur (also auch der ESX) vereinfacht, wenn die Namensauflösung gegeben ist, auch wenn mal die komplette VM-Umgebung down ist.
Ein Gefahr besteht bei virtuakisierten DC's: Wenn mal jemand auf die doofe Idee, kommt, einen DC per Snapshot "auf die einfache Art zu sichern" und diesen dann auch tatsächlich mal "unkontrolliert" wiederherstellt. Das geht dann höchstwahrscheibnlich gegen den Baum.
Snapshot-Sicherung von DC's kann in bestimmten Szenarien möglich und sinnvoll sein, ist aber i.A. mit extremer Vorsicht zu genießen.
E.
Moin,
die Antwort darauf ist m.E. eher bei euren Leuten zu suchen... Habt ihr das Know-How im Haus um ne virtuelle Umgebung wirklich sauber laufen zu lassen? Habt ihr das Know-How im Haus das ganze in einer HA-Umgebung zu betreiben? Wenn ja spricht m.E. nichts gegen was virtuelles... Wenn es nur der Standard-HA ist ("hat uns mal jemand eingerichtet und nu läufts halt") würde ich mir überlegen ob ich nicht zumindest einmal blech stehenlasse um eben notfalls darüber die Leute abzufrühstücken wenn das virtuelle in die Knie geht.
Dabei sollte man eben nicht vergessen das HA zwar schön für die Ausfallsicherheit ist - aber WENNS mal knallt dann eben richtig und mit der Folge das es meistens sehr Zeitaufwändig wird das wiederherzustellen... (zumindest wenn man eben nur glaubt das man das Know-How im Haus hatte...)
die Antwort darauf ist m.E. eher bei euren Leuten zu suchen... Habt ihr das Know-How im Haus um ne virtuelle Umgebung wirklich sauber laufen zu lassen? Habt ihr das Know-How im Haus das ganze in einer HA-Umgebung zu betreiben? Wenn ja spricht m.E. nichts gegen was virtuelles... Wenn es nur der Standard-HA ist ("hat uns mal jemand eingerichtet und nu läufts halt") würde ich mir überlegen ob ich nicht zumindest einmal blech stehenlasse um eben notfalls darüber die Leute abzufrühstücken wenn das virtuelle in die Knie geht.
Dabei sollte man eben nicht vergessen das HA zwar schön für die Ausfallsicherheit ist - aber WENNS mal knallt dann eben richtig und mit der Folge das es meistens sehr Zeitaufwändig wird das wiederherzustellen... (zumindest wenn man eben nur glaubt das man das Know-How im Haus hatte...)
Hallo Ermiks,
danke für die prompte Rückmeldung.
???
Du meinst sicher nicht "Member Server", sondern er ist ein "einfacher" DC, ohne Rollen, mit Ausnahme des GC. Einer wichtigen Rollen ....
--> richtig, sorry hab mich falsch ausgedrückt
Die ESX an sich sind auch redundant? Also mehrere ESX im Cluster mit lizensiertem HA?
--> Ja betreiben eine kleine überschaubare redundante ESX Farm mit 7 Servern (mit lizensiertem HA) wo wir lokale Host-File auf jedem Host pflegen. Deshalb haben wir unsere ESX Server nicht in die Domäne eingebunden.
Wir haben bei uns ca. 30 DC's als VM und einen als Hardware. Der Grund für letzteren ist einfach die Tatsache, dass er auch DNS-Server ist und sich die Wartung der ganzen Infrastruktur (also auch der ESX) vereinfacht, wenn die Namensauflösung gegeben ist, auch wenn mal die komplette VM-Umgebung down ist.
Ein Gefahr besteht bei virtuakisierten DC's: Wenn mal jemand auf die doofe Idee, kommt, einen DC per Snapshot "auf die einfache Art zu sichern" und diesen dann auch tatsächlich mal "unkontrolliert" wiederherstellt. Das geht dann höchstwahrscheibnlich gegen den Baum.
Snapshot-Sicherung von DC's kann in bestimmten Szenarien möglich und sinnvoll sein, ist aber i.A. mit extremer Vorsicht zu genießen.
danke für die prompte Rückmeldung.
???
Du meinst sicher nicht "Member Server", sondern er ist ein "einfacher" DC, ohne Rollen, mit Ausnahme des GC. Einer wichtigen Rollen ....
--> richtig, sorry hab mich falsch ausgedrückt
Die ESX an sich sind auch redundant? Also mehrere ESX im Cluster mit lizensiertem HA?
--> Ja betreiben eine kleine überschaubare redundante ESX Farm mit 7 Servern (mit lizensiertem HA) wo wir lokale Host-File auf jedem Host pflegen. Deshalb haben wir unsere ESX Server nicht in die Domäne eingebunden.
Wir haben bei uns ca. 30 DC's als VM und einen als Hardware. Der Grund für letzteren ist einfach die Tatsache, dass er auch DNS-Server ist und sich die Wartung der ganzen Infrastruktur (also auch der ESX) vereinfacht, wenn die Namensauflösung gegeben ist, auch wenn mal die komplette VM-Umgebung down ist.
Ein Gefahr besteht bei virtuakisierten DC's: Wenn mal jemand auf die doofe Idee, kommt, einen DC per Snapshot "auf die einfache Art zu sichern" und diesen dann auch tatsächlich mal "unkontrolliert" wiederherstellt. Das geht dann höchstwahrscheibnlich gegen den Baum.
Snapshot-Sicherung von DC's kann in bestimmten Szenarien möglich und sinnvoll sein, ist aber i.A. mit extremer Vorsicht zu genießen.
Schau Dir mal die "Zitat"-Funktion an. So weiß ja keiner mehr, was von Dir komt und was nicht.
E.
E.
Zitat von @emeriks:
Ein Gefahr besteht bei virtuakisierten DC's: Wenn mal jemand auf die doofe Idee, kommt, einen DC per Snapshot "auf die
einfache Art zu sichern" und diesen dann auch tatsächlich mal "unkontrolliert" wiederherstellt. Das geht dann
höchstwahrscheibnlich gegen den Baum.
Snapshot-Sicherung von DC's kann in bestimmten Szenarien möglich und sinnvoll sein, ist aber i.A. mit extremer Vorsicht
zu genießen.
Ist vielleicht nun etwas OT, aber warum ist das mit Vorsicht zu genießen? Was kann passieren?Ein Gefahr besteht bei virtuakisierten DC's: Wenn mal jemand auf die doofe Idee, kommt, einen DC per Snapshot "auf die
einfache Art zu sichern" und diesen dann auch tatsächlich mal "unkontrolliert" wiederherstellt. Das geht dann
höchstwahrscheibnlich gegen den Baum.
Snapshot-Sicherung von DC's kann in bestimmten Szenarien möglich und sinnvoll sein, ist aber i.A. mit extremer Vorsicht
zu genießen.
Ich betreibe hier nen ESX mit der einfachen VmWare Recovery Appliance. Da macht er mir gemäß Zeitplan Sicherungen, die ich bisher glaube ich 1-2 mal zurück spielen musste und ich hatte nie irgendwelche Probleme.
Also was genau kann hier schief laufen?
Ich hab das Ding hier so seit 5 Jahren laufen ohne Mucken...
Gruß
Such mal im Google z.B. nach: Windows domain controller revert snapshot
Da sollte alles bei sein ...
E.
Jut, so weit so klar.. unterschiedliche USN.
z.b. hier gut beschrieben denke ich: http://www.windowspro.de/andreas-kroschel/warum-snapshots-bei-virtuelle ...
Aber: Leider wird nirgendwo erwähnt was denn so schlimm daran ist... was ist die Konsequenz?
Noch dazu: wie sicher ihn denn dann sicher?
edit: außerdem sagen sie immer: wenn er längere Zeit down war...
z.b. hier gut beschrieben denke ich: http://www.windowspro.de/andreas-kroschel/warum-snapshots-bei-virtuelle ...
Aber: Leider wird nirgendwo erwähnt was denn so schlimm daran ist... was ist die Konsequenz?
Noch dazu: wie sicher ihn denn dann sicher?
edit: außerdem sagen sie immer: wenn er längere Zeit down war...
Guten Morgen Xaero1982,
Bei Server 2012(R2) sieht es wieder ein bisschen anders aus. Mit der Einführung der VM Generation ID sieht die Welt dort ein bisschen anders aus. Aber ist auch mit vorsichtig zu genießen.
Grüße,
Dani
Aber: Leider wird nirgendwo erwähnt was denn so schlimm daran ist... was ist die Konsequenz?
Steht in deinem Link unten ganz gut erklärt.Domaincontroller physikalisch oder virtuell??
Auf jeden Fall physikalisch. Wir hatten gerade so ein Erlebnis mit VMWare, Sysprep und DCs. Migration von 2008R2 auf 2012R2 läuft schon ein Weilchen. Mit einem Bug im ESXi 5.1 lief Sysprep nicht mehr sauber und führte dazu, dass beim Aus/einschalten diese Funktion Endlos lief. So waren ganz schnell 3 DCs defekt! Froh war man, dass dieser Standort seit Anfang Jahr einen phy. DC hat. Stell das Blech hin, kostet zwar jetz Geld, aber später schont es deine Nerven.Bei Server 2012(R2) sieht es wieder ein bisschen anders aus. Mit der Einführung der VM Generation ID sieht die Welt dort ein bisschen anders aus. Aber ist auch mit vorsichtig zu genießen.
Noch dazu: wie sicher ihn denn dann sicher?
SystemState via Windows Server Sicherung. Das ist die einzigste Variante, bei der Microsoft Support (egal welche Stufe) uneingeschränkt mithilft, das AD wiederherzustellen (egal ob 2, 30 oder 100 DCs). Ist zwar lästig wie die Sau und nicht so bequem wie Snapshots aber wer mal einen größeren Crash erlebt hat, macht dies mit Freuden.außerdem sagen sie immer: wenn er längere Zeit down war...
Du meinst sicher die Tombstone Lifetime?!Grüße,
Dani
Zitat von @Dani:
Guten Morgen Xaero1982,
> Aber: Leider wird nirgendwo erwähnt was denn so schlimm daran ist... was ist die Konsequenz?
Steht in deinem Link unten ganz gut erklärt.
" Ein solcher Fehler ist nur schwer zu finden, wächst mit der Zeit und stellt über kurz oder lang ein großes Problem dar."Guten Morgen Xaero1982,
> Aber: Leider wird nirgendwo erwähnt was denn so schlimm daran ist... was ist die Konsequenz?
Steht in deinem Link unten ganz gut erklärt.
Bin ich wohl zu doof zu lesen was gemeint ist
Zitat von @Dani:
Auf jeden Fall physikalisch. Wir hatten gerade so ein Erlebnis mit VMWare, Sysprep und DCs. Migration von 2008R2 auf 2012R2
läuft schon ein Weilchen. Mit einem Bug im ESXi 5.1 lief Sysprep nicht mehr sauber und führte dazu, dass beim
Aus/einschalten diese Funktion Endlos lief. So waren ganz schnell 3 DCs defekt! Froh war man, dass dieser Standort seit Anfang
Jahr einen phy. DC hat. Stell das Blech hin, kostet zwar jetz Geld, aber später schont es deine Nerven.
Wobei das eine mit anderen ja nix zu tun hat. Wieso sollte im Zusammenhang mit Sysprep ein DC schrotti gehen? Wer sysprept denn einen DC?!! Selber schuld ...Auf jeden Fall physikalisch. Wir hatten gerade so ein Erlebnis mit VMWare, Sysprep und DCs. Migration von 2008R2 auf 2012R2
läuft schon ein Weilchen. Mit einem Bug im ESXi 5.1 lief Sysprep nicht mehr sauber und führte dazu, dass beim
Aus/einschalten diese Funktion Endlos lief. So waren ganz schnell 3 DCs defekt! Froh war man, dass dieser Standort seit Anfang
Jahr einen phy. DC hat. Stell das Blech hin, kostet zwar jetz Geld, aber später schont es deine Nerven.
@Xaero1982
siehe auch hier:
How to detect and recover from a USN rollback in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2
http://support.microsoft.com/kb/875495/en-us
E.
Wobei das eine mit anderen ja nix zu tun hat. Wieso sollte im Zusammenhang mit Sysprep ein DC schrotti gehen? Wer sysprept denn einen DC?!! Selber schuld ...
Wir nutzen VMWare über Vorlagen und damit wird auch Sysprep genutzt. 
Dabei gab es einen hübschen Bug der uns bei einer Umstellung die DCs zerlegt hat. Da bist du froh um einen phy. DC.Grüße,
Dani
Dani,
erkläre doch bitte mal, inwieweit Sysprep DC's "zerlegt", "zerlegen" kann. Sysprep wendet man bei promoteten DC's sinnvollerweise nicht an. Man kann sicherlich den Server, der einmal DC werden soll, per Template + Sysprep ausrollen. Aber bevor dieser nicht tadellos läuft, promote ich ihn doch nicht zum DC! Also, inwiefern hat das hier ne Relevanz?
Man kann auch einen DC, der auf eine andere Hardware übertragen werden soll, demoten, sysprepen, auf der anderem Hardware "wiederbeleben" und dann - wenn alles ok - und nur dann - wieder zum DC promoten. Wobei das Ganze sowieso nur in wenigen Szenarien sinnvoll erscheint, z.B. wenn der Server nicht nur DC ist und noch andere Software mit drauf ist.
E.
Edit:
Aufpassen muss man, wenn man mit einem Server, der von einem Template ausgerollt wurde, eine neue Domäne in eine bestehende Gesamtstruktur erstellen will. Hier muss man vorher dafür sorgen, dass dieser Server eine eindeutige lokale SID hat. Bei neuen Domänen erhält meines Wissens diese neue Domäne die SID des ersten DC, mit dem diese Domäne instanziert wird. Wenn es andere Server (auch nur Member) im selben AD gibt, welche vom selben Template bereitgestellt wurden und deshalb die selbe lokale SID haben, dann kommt es zu Probleme bei der Kommunikation dieser Server mit der neuen Domäne.
E.
erkläre doch bitte mal, inwieweit Sysprep DC's "zerlegt", "zerlegen" kann. Sysprep wendet man bei promoteten DC's sinnvollerweise nicht an. Man kann sicherlich den Server, der einmal DC werden soll, per Template + Sysprep ausrollen. Aber bevor dieser nicht tadellos läuft, promote ich ihn doch nicht zum DC! Also, inwiefern hat das hier ne Relevanz?
Man kann auch einen DC, der auf eine andere Hardware übertragen werden soll, demoten, sysprepen, auf der anderem Hardware "wiederbeleben" und dann - wenn alles ok - und nur dann - wieder zum DC promoten. Wobei das Ganze sowieso nur in wenigen Szenarien sinnvoll erscheint, z.B. wenn der Server nicht nur DC ist und noch andere Software mit drauf ist.
E.
Edit:
Aufpassen muss man, wenn man mit einem Server, der von einem Template ausgerollt wurde, eine neue Domäne in eine bestehende Gesamtstruktur erstellen will. Hier muss man vorher dafür sorgen, dass dieser Server eine eindeutige lokale SID hat. Bei neuen Domänen erhält meines Wissens diese neue Domäne die SID des ersten DC, mit dem diese Domäne instanziert wird. Wenn es andere Server (auch nur Member) im selben AD gibt, welche vom selben Template bereitgestellt wurden und deshalb die selbe lokale SID haben, dann kommt es zu Probleme bei der Kommunikation dieser Server mit der neuen Domäne.
E.
Alsoooo... wir hatten ESXi 5.1.1743533 im Einsatz. An einem Standort stand einen komplette DC Migration von 2008R2 auf 2012R2 an. das VMWare-Team hat die neuen DCs munter per Vorlage vorher angelegt und mit der Anpassungassistent durchlaufen lassen.
Das Windowsteam hat letzte Woche angefangen alle DCs umzuziehen, die alten zu entfernen, etc... Im obengenannten Build gibt es einen hübschen Bug. Die Gast-Anpassungen werden sauber durchgeführ. Aber die vmx-Datei nicht angepasst und die TMP-Datei nicht gelöscht. Solange die VM ausschließlich neugestartet wird, ist die Welt in Ordnung. Wird die VM aber aus/eingeschalten läuft der VMWare Sysprep - Prozess an und zerstört die VM bzw. den DC komplett. Da waren wir echt froh, dass ein phy. DC vor Ort stand. Denn sonst wäre es eine größere Ausfall geworden.
Das als Praxisbeispiel warum ein phy. DC manchmal sinnvoll ist.
Gruß,
Dani
Das Windowsteam hat letzte Woche angefangen alle DCs umzuziehen, die alten zu entfernen, etc... Im obengenannten Build gibt es einen hübschen Bug. Die Gast-Anpassungen werden sauber durchgeführ. Aber die vmx-Datei nicht angepasst und die TMP-Datei nicht gelöscht. Solange die VM ausschließlich neugestartet wird, ist die Welt in Ordnung. Wird die VM aber aus/eingeschalten läuft der VMWare Sysprep - Prozess an und zerstört die VM bzw. den DC komplett. Da waren wir echt froh, dass ein phy. DC vor Ort stand. Denn sonst wäre es eine größere Ausfall geworden.
Das als Praxisbeispiel warum ein phy. DC manchmal sinnvoll ist.
Gruß,
Dani
Ok, danke für die Info!
E.
E.
Hallo zusammen,
danke für´s Feedback. Anscheinend ist es wirklich sinnvoll einen physikalischen DC vorzuhalten (auch wenn dies mit Kosten verbunden).
danke für´s Feedback. Anscheinend ist es wirklich sinnvoll einen physikalischen DC vorzuhalten (auch wenn dies mit Kosten verbunden).
