Cache Restriktion bei DC deaktivieren

Hallo,

das Problem tritt bei einem WS2012R2 Domaincontroller auf. Mit dem Start (oder einem Reboot) der Maschine wird der Cache des Controllers deaktiviert. Diese Sicherheitsfunktion wurde anscheinend mit WS2012 wieder eingeführt. Kennt jemand den passenden Eintrag oder das "Häkchen" um diese Sicherheitsfunktion zu deaktivieren?

Danke!

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 275340

Url: https://administrator.de/contentid/275340

Ausgedruckt am: 22.11.2024 um 05:11 Uhr

8 Kommentare

Neuester Kommentar

Sers,

das "Häkchen" kannst du dir sparen indem du die fürs AD relevanten Daten - sprich SYSVOL und Konsorten - auf ein anderes Laufwerk schiebst.
Damit ist dein Windows Server wieder flott, und kann den Cache nutzen, während die AD Daten weiterhin geschützt sind.

Ein sauberer Weg wird dir hier gezeigt.
Alternativ könntest du natürlich auch einfach den DC - sofern er hoffentlich nicht der einzige ist - demoten, säubern, und beim erneuten Promoten das neue Laufwerk als Speicherort angeben. Rollenverteilung nicht vergessen!

Solltest du tatsächlich Festplatten- und Controllercaches auf dem Laufwerk mit den AD Daten aktivieren wollen, dann verbiete ich dir hiermit auch nur in irgend einer Art und Weise zu jammern (bzw. flehen) wenn dir unweigerlich irgendwann der DC abrauchen wird.

Grüße,
Philip

Hallo Philip,

danke für die Info. Das Verschieben der entsprechenden Ordner bringt in sofern nichts, da der cache dennoch deaktiviert wird, egal auf welcher Partition verschoben wird. Also bleibt nur noch seperate HDD's oder alles virtualisieren.

Danke!

Zitat von @siehe0815:
[...] Also bleibt nur noch seperate HDD's oder alles virtualisieren. [...]

Drum schrieb ich auch "Laufwerk" und nicht Partition. Ob das jetzt eine eigene LUN auf nem SAN ist, oder ein Array auf dem Controller ohne Cache... nuja.

Was bringt dir denn die Virtualisierung an der Stelle? Dass der DC nicht mitbekommt dass seine Datenträger als VHDX/VMDK/sonstwas auf einem Array liegen, dessen Controller die Caches nutzt? Was passiert dann wenn der Hypervisor bzw sein Controller ein Problem hat? Dann bist du auch im A.

Was erhoffst du dir eigentlich durch die paar "gewonnenen" IOPS?

nunja, abgesehen von den "paar" iops wäre der controller mit seinem cache dann ja völlig überflüssig. leider merken wir die iops sehr stark bei einer älteren anwendung auf dos ebene. leider ist das programm hauptbestandteil der unternehmung :/

Bitte sprich mir nach:

Ein DC ist ein DC ist ein DC ist ein DC ist ein DC ist ein DC ist ein DC ist ein DC ist ein DC ist ein DC und kein Applikationsserver.

Kauf dir lieber noch ein weiteres Stück Blech für deine Applikationen. Damit wirst du mehr Freude haben.

mein held bist du erst wenn du mir den grund dafür nennen kannst. das es eine microsoft vorgabe ist zählt nicht.
technisch gesehen kann ich das nicht wirklich nachvollziehen. also die frage: warum wird der write-cache eines dc deaktiviert?

Zitat von @siehe0815:

also die frage: warum wird der write-cache eines dc deaktiviert?

Weil der DC nur so sicher sein kann, das jeder als abgeschlossen gekennzeichnete Schreibvorgang auch wirklich geschrieben wurde, und nicht erst noch in irgend einem Cache rum lungert.

Stell dir mal vor du trägst auf DC 1 einen neuen Benutzer ein. Der versucht das jetzt in seine DB zu schreiben. Sobald er den Erfolg des Schreibvorgangs bescheinigt bekommt fängt er an DC 2 und DC 3 über den neuen Benutzer zu benachrichtigen. Es ändern sich dabei - wie erwartet - die USN.
Jetzt nehmen wir an der DC 1 fällt aus, bevor die Daten wirklich auf der Festplatte liegen. Der Controller hat dem DC zu der Zeit bereits den Erfolg des Schreibens quittiert.
Resultat: DC 1 fehlen die Daten. DC 2 und DC 3 glauben dass DC 1 diese hat. Tada, das AD ist inkonsistent.
Das kann speziell dann passieren wenn du etwa noch andere Anwendungen auf dem DC laufen lässt. Mal eine WSUS & Exchange DB Wartung auf einem SBS 2008/11 mit 2x 1TB SATA Platten im Raid1 gemacht? Da sind Warteschlangen auf dem Array bzw. dem Volume von >5s ganz schnell dabei. Geschweige denn wann die Daten dann endlich wirklich auf den Platten sind.

Auch könnten beispielsweise Controller Cache oder Festplattencache defekt sein.

Es geht MS einfach nur darum die Abläufe auf dem DC möglichst sicher zu gestalten. Mögliche Fehlerquellen auszuschließen. Und weil der DC als solcher recht wenige IOPS für seine Rolle braucht geht MS diesen Weg der Sicherheit.

Sprich mir nach: Ein DC ist ein DC ist ein DC ist immer noch ein DC, und immer noch kein Applikationsserver.