DC virtualisieren + wie sichern (SingleDC-Environment)

Moin,
Der Artikel von Nils hat meiner Meinung nach ohne Ausnahme Gültigkeit.

Ich wollte nun nachfragen, wie ihr den DC denn im Notfall sichern/wiederherstellen würdet, wenn dieser virtualisiert wird?
Ich würde auf jeden Fall bei nur einem virtuellen DC einen weiteren in Form eines physkalischen Installation bereitstellen. Wenn es geht in einem anderen Gebäude.

Ich würde bei eurer Größe auf den physkalischen Server setzen.

Prinzipell richtig. Es gibt Techniken wie GenerationID, welche das Thema USN Rollback im Griff kriegen sollen. Aber man muss schon etwas Ahnung haben und gewisse Schritte berücksichtgen. Anderenfalls kann man auch ein Active Directory damit versenken!

Richtig. Aber das hast bei jedem Full-Recovery, egal ob Veeam, Acronis, IBM, etc...

Achja, ich rate dir auch dazu alle DCs mit der Windows-Serversichung zusätzlich zu sichern (SystemState). Den im Worst Case ist evtl. auch der Microsoft Support von nöten und der setzt vorraus, dass eine Sicherung mit Windows-Boardmitteln vorhanden ist. Alles andere interessiert ihn nicht.


Gruß,
Dani

Mahlzeit,

ich arbeite bei mir und Kunden mit Hyper-V. Es handelt sich zumeist um kleine Umgebungen mit max. 40 Usern.
Am liebsten sind mir auch 2 DCs, dabei einer als Blech.

Es ist aber grundsätzlich auch kein Problem, wenn man nur virtuelle DCs hat (ich schenke mir den 2. DC für meine Firma).
Bei mir ist Backup Exec auf dem Hyper-V-Host installiert, sichert den Host und die VMs und sollte der DC (VM) ausfallen, würde ich diesen aus der letzten Sicherung wiederherstellen.

Mit VMWare und Veeam fährst Du gut und richtig, wenn Du ein sauberes Konzept dahinter stehen hast.
Das Recover eines DC ist nicht einfach mal so getan. Es kann viel schiefgehen.

Was soll inkonsistent sein, wenn ich den DC aus dem letzten Backup von (zumeist) letzter Nach wiederherstelle?

Benutzer am PC abmelden und wieder anmelden, wenn tatsächlich ein Computerpasswordwechsel stattfand, dann diesen PC aus der Domäne herausnehmen und wieder aufnehmen.

Einzig die seit der letzten Sicherung vorgenommenen Änderungen sind natürlich nicht da. Aber bei kleinen Umgebungen werden nicht täglich Änderungen am AD vorgenommen und wenn, dann macht man eine Extra-Sicherung.

Denk mal an die vielen SBS-Umgebungen. Dort gibt es nur einen DC (meist als Blech, aber egal).

Moin,

ich klinke mich mal mit ein, auf die Gefahr, dass es geringfügig abschweift, was ich aber nicht glaube:
Wir haben aktuell zwei DCs, beide in einem VMWare-Cluster (mit darunter liegendem StorageHyperVisor) liegen. Keinen Hardware-DC, denn mir/ uns stellte sich folgende Frage:
Welchen Vorteil hat es, wenn ein DC auf einem dedizierten Blech läuft, unter der Gegebenheit, dass das gesamte Cluster ein Stretched-Cluster, verteilt auf >1 Raum, ist?

Wenn das Blech kaputt ist, muss ich den defekten DC ebenfalls irgendwie wiederherstellen oder aus dem AD sauber entfernen (weil irreperabel).
Der Backup-Server (welcher indes auf einer völlig anderen Hardware werkelt) ist in keinsterweise ans AD angebunden, somit brauche ich für einen Restore auch kein funktionierendes AD. Lediglich der Backup-Proxy (Bindeglied zwischen Backup-Server und VMWare) braucht einen User im vCenter, welcher aber kein AD-User sein muss.
Hat das komplette STorage-Cluster die biege gemacht: zum Restore brauche ich kein AD.
Der Umstand, dass aufgrund eines durch Löschwasser gefluteten Raum 1 ein Restore angestoßen werden muss, halte ich für unwahrscheinlich, da ja alle Daten in Raum 2 vorliegen, bestenfalls DC1 zuletzt im RAUM 1 aktiv war und DC2 im Raum 2.
Ist mein Netz von einem Virus befallen, hilft mir ein dedizierter DC auch nicht. Ist aufgrund eines Chemieunfalls mein gesamter Campus ebenerdig: Dann habe ich andere Sorgen

Mit einer Hyper-V Konstellation könnte ich es eher nachvollziehen ,weil die Hosts vermutlich (ich weiss es nicht, habe mit Hyper-V noch nie gearbeitet) eine AD-ANbindungen haben wollen!? aber bei VMWare, KVM ???

Mag sein, dass die weitläufige Empfehlung mit dem zweiten physikalischen DC berechtigt ist, aber aufgrund möglicherweise mangelndem Wissen meinerseits sehe ich aktuell keinen sinvollen Grund, warum ein weiterer DC physikalisch existent sein sollte.

Bzw. stelle ich zusätzlich die Frage: selbst wenn man einen zweiten DC auf einer "isolierten" Hardware betreiben sollte, muss dieser wirklich physikalisch sein, oder könnte man dort auch einen Standalone-ESXi laufen lassen und den DC darauf virtualisieren? Denn in einem Restore-Fall muss ich doch so oder so Hand am DC anlegen, oder irre ich?

Gruß
em-pie

Hallo,

nur ein Bsp.: Wenn Deine Verwaltungskonsole für die VMs auch in das AD integriert ist oder der "Verwaltungsserver" Mitglied der Domäne ist, kannst du dich dort nur anmelden, wenn der DC bzw. mindestens einer der DCs läuft. Wenn dein Host oder die DC-VMs nicht starten, kannst du dich nicht an die Verwaltungskonsole anmelden (die Domäne ist ja nicht vorhanden) und damit kannst du weder Haost noch VMs administrieren.
Bei Ausfall des Hosts und 2 DCs als VM hast du dann ein echtes Problem.

Jürgen

Zumindest unter VMware bleibt sowohl am vCenter als auch am Hypervisor die Möglichkeit sich mit root oder einem anderen VMware Konto anzumelden. Wir melden uns hier auch über die Domäne an aber wenn die AD mal nicht läuft dann eben mit dem vSphere Admin.

Hallo,

wenn das vCenter als Appliance unter Linux läuft, mag das gehen. Wenn das vCerter ein Windows-Server in der Domäne ist, wird es schwierig.

Und wenn du dich direkt am ESX anmeldest, stehen viele Admin-Funktionen nicht zur Verfügung. ZB. kannst du keine VM verschieben, was ja manchmal zur Problemlösung sinnvoll wäre.

Jürgen

Eigentlich nicht, der Windows Server (bei uns der Fall), braucht sich nicht anmelden und braucht keine Domäne zum booten auch wenn er Mitglied ist. Er kann im Anschluss ohne AD natürlich keine AD User authentifizieren, er kann aber sehr wohl seine eigenen User anmelden. Dazu gehört auch das vSphere eine eigene Domäne bei der Installation anlegt, man muss natürlich vorher User anlegen oder sich mit dem Admin begnügen.

Eine Anmeldung am Hypervisor ist natürlich eingeschränkt, sie bezieht sich nur auf den Hypervisor selbst. Wenn der vSphere aber rebootet, nicht läuft oder hängt braucht man das schonmal.