4
Domänencontroller - Datenbank auf anderen Datenträger
Hallo Leute,
ich hatte heute eine Diskussion mit einem ehemaligen Kollegen.
Er setzt die Datenbank, Logfiles und SYSVOL jeweils auf verschiedene Datenträger.
Ich tue dies nicht. Mir wurde mal erzählt das kann je nachdem zu Problemen führen.
Wie seht ihr das?
ich hatte heute eine Diskussion mit einem ehemaligen Kollegen.
Er setzt die Datenbank, Logfiles und SYSVOL jeweils auf verschiedene Datenträger.
Ich tue dies nicht. Mir wurde mal erzählt das kann je nachdem zu Problemen führen.
Wie seht ihr das?
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: 359191
Url: https://administrator.de/contentid/359191
Ausgedruckt am: 26.11.2024 um 01:11 Uhr
4 Kommentare
Neuester Kommentar
Hi,
Grundsätzlich ist es eine Microsoft Empfehlung, die Datenbank-Datei und Logs zu verschieben, auf einen nicht System Datenträger, wie auch bei anderen Produkten auch.
https://blogs.technet.microsoft.com/canitpro/2015/03/31/step-by-step-mov ...
Das Sysvol ist ja nur eine Dateifreigabe und kann natürlich auch woanders liegen.
Ich denke die Empfehlung entstand wegen Recovery-Scenarien. Ich persönlich würde bei einem DC Fehler ihn eher neu Aufsetzen..
Mfg
Grundsätzlich ist es eine Microsoft Empfehlung, die Datenbank-Datei und Logs zu verschieben, auf einen nicht System Datenträger, wie auch bei anderen Produkten auch.
https://blogs.technet.microsoft.com/canitpro/2015/03/31/step-by-step-mov ...
Das Sysvol ist ja nur eine Dateifreigabe und kann natürlich auch woanders liegen.
Ich denke die Empfehlung entstand wegen Recovery-Scenarien. Ich persönlich würde bei einem DC Fehler ihn eher neu Aufsetzen..
Mfg
Das hängt von deinen Datenträgern ab. Nehmen wir mal an du hast bei dir im Server nen Raid50 oder 60 laufen - dann würde ich ohne Probleme die Daten darauf legen da die Ausfallwahrscheinlichkeit doch eher gering ist. Hast du dagegen den Server auf SSD's laufen würde ich ggf. grad Logfiles auf einen seperaten Datenträger packen da diese üblicherweise auch gerne viele Schreibzugriffe haben.
Ich würde daher einfach das an meine Hardware anpassen - am besten natürlich auf verschiedene Datenträger da ich dann eben die ganzen Zugriffe nicht immer auf der Systemplatte habe. Nur dafür muss der Rest eben auch passen.
Ich würde daher einfach das an meine Hardware anpassen - am besten natürlich auf verschiedene Datenträger da ich dann eben die ganzen Zugriffe nicht immer auf der Systemplatte habe. Nur dafür muss der Rest eben auch passen.
Moin.
Probleme kann es geben, wenn z.B. die "anderen Aufgaben" die Platte, auf der die NTDS-Datenbank liegt, soweit auslasten, dass der DC die Anmeldungen nicht mehr zeitgerecht verarbeiten kann etc. Ist mir in 20-jähriger Praxis bisher nur einmal untergekommen. Anderes Szenario wäre z.B. mehrere tausend (!!) gleichzeitige Client-Anmeldungen am einzigen DC der Domain etc.
Was Recovery angeht halte ich es wie @7Gizmo7:
Da wir mehrere DCs haben, wir im Falle des Falles eben nicht wiederhergestellt, sondern einfach ein neuer DC installiert (und je nach Grund des Ausfalls der "alte" per ntdsutil aus den Metadaten des AD entfernt).
Andersherum: Plant man seine Infrastruktur entsprechend, muss man sich darüber eigentlich keine Birne (mehr) machen.
Cheers,
jsysde
Zitat von @Jens1982:
[...]Ich tue dies nicht. Mir wurde mal erzählt das kann je nachdem zu Problemen führen.>
Wie seht ihr das?
Naja, steht so im "Lehrbuch" - das aus einer Zeit stammt, in der man einen (den einzigen) DC auf Blech betrieben und ihm noch zig andere Aufgaben aufgebürdet hat. Oder nen SBS eingesetzt hat, bei dem das ja so sein musste (Thomas, hau mich jetzt nicht gleich wieder *g*).[...]Ich tue dies nicht. Mir wurde mal erzählt das kann je nachdem zu Problemen führen.>
Wie seht ihr das?
Probleme kann es geben, wenn z.B. die "anderen Aufgaben" die Platte, auf der die NTDS-Datenbank liegt, soweit auslasten, dass der DC die Anmeldungen nicht mehr zeitgerecht verarbeiten kann etc. Ist mir in 20-jähriger Praxis bisher nur einmal untergekommen. Anderes Szenario wäre z.B. mehrere tausend (!!) gleichzeitige Client-Anmeldungen am einzigen DC der Domain etc.
Was Recovery angeht halte ich es wie @7Gizmo7:
Da wir mehrere DCs haben, wir im Falle des Falles eben nicht wiederhergestellt, sondern einfach ein neuer DC installiert (und je nach Grund des Ausfalls der "alte" per ntdsutil aus den Metadaten des AD entfernt).
Andersherum: Plant man seine Infrastruktur entsprechend, muss man sich darüber eigentlich keine Birne (mehr) machen.
Cheers,
jsysde
Moin,
grundsätzlich gib es verschiedene Gründe, um die Datebank inkl. Protokolldateien zu verschieben. In großen Umgebungen (> 100.000 Benutzer/Computer) kann die Größe der DB bzw. Protokoll schnell zum Problem werden. Es plustert die Systempartition nur unnötig auf und drückt auf die Performance. Bei virtualisierten Domain Controller wird daher eine zweite Festplatte erzeugt. Diese wird nicht dem bestehenden SCSI-Controller zugeordnet sondern einem Weiteren.
Anderes Szenario wäre ein physikalischer Domain Controller, in dem verschiedene Festplattentypen im RAID verbaut sind. Je nach Größe der Datenbank/Protokolle bzw. Festplattentypen (SATA, SAS, SSD) ist es sinnvoll die Dateien zu separieren.
Gruß,
Dani
grundsätzlich gib es verschiedene Gründe, um die Datebank inkl. Protokolldateien zu verschieben. In großen Umgebungen (> 100.000 Benutzer/Computer) kann die Größe der DB bzw. Protokoll schnell zum Problem werden. Es plustert die Systempartition nur unnötig auf und drückt auf die Performance. Bei virtualisierten Domain Controller wird daher eine zweite Festplatte erzeugt. Diese wird nicht dem bestehenden SCSI-Controller zugeordnet sondern einem Weiteren.
Anderes Szenario wäre ein physikalischer Domain Controller, in dem verschiedene Festplattentypen im RAID verbaut sind. Je nach Größe der Datenbank/Protokolle bzw. Festplattentypen (SATA, SAS, SSD) ist es sinnvoll die Dateien zu separieren.
Da wir mehrere DCs haben, wir im Falle des Falles eben nicht wiederhergestellt, sondern einfach ein neuer DC installiert (und je nach Grund des Ausfalls der "alte" per ntdsutil aus den Metadaten des AD entfernt).
Dazu sollte auf dem DC keine weitere Rollen (z.B. Zertifizierungsstelle, WSUS, etc...) oder 3rd Party Software installiert sein. Anderenfalls ist das Recovery meist der schnellere Weg.Gruß,
Dani
1
