t-6 schrieb:
Bitte nicht falsch verstehen: Ich virtualisiere alles was sich virtualisieren lässt - und ggf. nicht Oracle heißt ^^ Also auch einen zweiten DC auf anderer Hardware.
Aber ein replizierter Domänen-Controller ist kein Ersatz für einen zweiten Domänen-Controller. Zumal, wie weit willst du das skalieren?
Das gebe ich so zurück! Die Rede ist von kleinen Umgebungen. Klein sind für mich übliche SMB Installationen mit 1-10 VMs und bis 100 Benutzern. Selbst bei 500 Benutzern besteht nur wegen Lastaufteilung kein Bedarf für einen zweiten DC, vermutlich auch nicht bei 1000.
Ich könnte dir Bücher über Probleme schreiben die MIT mehreren DC passieren können und wiederhole nochmal gerne meinen Standpunkt. Mit EINEM DC und Hyper-V Hosts in einer Arbeitsgruppe sind die wenigsten Probleme zu erwarten. Ein zweiter DC hebt praktisch jegliche Vorteile einer solchen Lösung auf.
Einzelne DCs in kleinen Umgebungen sichere ich häufig nur einmal die Woche, in den meisten Umgebungen ändert sich am AD monatelang nichts, außer bei den von dir angesprochenen Accounts für Computer. Dateiserver mit DC Rolle logischerweise regelmäßig.
Eine Datensicherung ist Pflicht, häufig ergänzt durch Hyper-V Replikation. Ausfallzeit ist wie erwähnt unter 10 Minuten. Wie lange brauchst du für ein Failover oder Rücksicherung von einem DC? Sowas geht heutzutage instant. Ohne DC Replikation kann sowieso kaum etwas passieren, eine Datenbank zerbröselt nicht durch anschauen. Mögliche Fälle sind hier ein Systemabsturz oder ein beschädigter Datenträger und genau gegen solche Fälle schützt Replikation und Datensicherung.
Anfällig wird AD doch erst wenn mehrere DCs vorhanden sind, weil dann auch ein unbeabsichtigter Neustart (Hard) schon zu Problemen führen kann die man erst später merkt. Bei einem DC kann man (vereinfacht ausgedrückt) sich entweder anmelden oder nicht. Wenn es nicht geht macht man eine Rücksicherung, nutzt ein Replikationssnapshot oder kopiert einfach die AD Dateien aus der Sicherung in die VM und fertig ist die Laube.
t-6 schrieb:
Ein zweiter DC, ein geDFSRter File, zweiter Exchange+DAG & ein zweiter TS (aber mit repliziertem Broker) erreicht das auch und noch besser. Bis auf die User am TS & ggf. Outlook-Schluckauf bekommt in diesem Fall idealerweise niemand mit dass gerade ein Server brennt.
Du verdoppelst die Ausgaben für Software und Hardware. Vervierfachst die Kosten für Einrichtung und Wartung und holst dir mit gleich drei verschiedenen Replikationsarten + TS Broker mehr Probleme ins Haus, die du je mit einer einfachen Installation bekommen könntest.
Spätestens wenn du feststellst, dass du nach einem Jahr die meiste Zeit und Aufwand, für die Beseitigung von Problemen benötigt hast die mit Replikation zu tun haben, stellst du dir schnell die Frage ob das alles so gut war.
Wie schon erwähnt, das was du vorschlägst hat man gemacht, als die Server noch physikalisch waren. Heutzutage kannst du VMs sogar direkt aus einer Sicherung starten oder beim Ausfall eines ganzen Standorts aus einer Azure Cloud. Replikation auf Anwendungsebene macht bei einer Replikation auf Virtualisierungsebene genau 0 Sinn. Es wird erst dann wieder interessant wenn man die Last aufteilen muss (Exchange) oder verteilte Standorte hat (DC) und da reden wir schon über ganz andere Dimensionen.
t-6 schrieb:
Dein einer Domänen-Controller macht unspezifische Probleme (Klassiker: DNS-Service fällt ständig aus)
Weiss du wieso es diesen "Klassiker" überhaupt gibt? Weil Microsoft die schlaue Idee hatte, DNS im AD zu replizieren und gleichzeitig AD vom DNS abhängig zu machen. Das ist ein Klassiker den es nur gibt, wenn du mehrere DC hast und DNS im AD speichern lässt.
Wirf den zweiten DC raus, speichere DNS in einer Datei und ich versichere dir, du wirst in den nächsten 100 Jahren diese Probleme nie wieder bekommen.
Das soll jetzt nicht heißen, dass alles was Microsoft sagt total Schwachsinn ist. Einiges davon ist allerdings weit von "Best Practice" entfernt, lässt sich auf kleinere Umgebungen nicht übertragen oder gilt schon lange nicht für aktuelle Möglichkeiten. Eine Domäne "xyz.local" zu nennen ist vermutlich der grösste Blödsinn, den Microsoft jahrelang propagiert hat, die (falsche) Behauptung man könne eine Domäne mit einem installierten Exchange Server nicht umbenennen kostet jedes Jahr tausende Arbeitsstunden und die Empfehlung zu mehreren DCs gehört längst ad Acta gelegt.
