Warum sollte ein Domänencontroller nach einem unsauberen Herunterfahren einen USN-Rollback durchführen?


8

Ich habe diesen Windows Server 2008 R2-Domänencontroller auf einem physischen Dell-Server, Modell PowerEdge R510.

Hier gibt es einige elektrische Probleme, daher ist ein Stromausfall leider weit verbreitet. Es gibt USVs, die jedoch nicht so zuverlässig sind, wie sie sein sollten, und manchmal kommt es bei Servern zu unreinen Abschaltungen.

Aus irgendeinem Grund kann ich das wirklich nicht verstehen. Manchmal tritt dieser spezifische DC nach einem unsauberen Herunterfahren auf und stößt auf einen USN-Rollback , der uns zwingt, ihn herabzustufen und wieder zu fördern.

Dies ist überhaupt nicht sinnvoll, da es sich bei dem Server um einen physischen Server handelt und noch nie ein Snapshot, Klonen und / oder Wiederherstellen durchgeführt wurde. Außerdem ist keine zusätzliche Software darauf installiert, sondern führt nur DC-Aufgaben aus. Insbesondere ist kein Klonen / Wiederherstellen / welche Software auch immer vorhanden.

Eine Beschädigung des Dateisystems wäre zumindest sinnvoll, ein USN-Rollback jedoch nicht, da der Server auf keinen Fall in einen früheren Zustand zurückversetzt werden kann. Dies ist jedoch in den letzten zwei Monaten mindestens dreimal passiert, so dass es definitiv kein einmaliges verrücktes Ereignis war. aber ich kann überhaupt keine Erklärung finden.

Was könnte der Grund für dieses Problem sein?


3
Wie genau haben Sie festgestellt, dass es sich tatsächlich um einen USN-Rollback handelt?
Mathias R. Jessen

HKLM\System\CurrentControlSet\Services\NTDS\Parameters\DSA not writable= 4
Massimo

Sehr gute Frage. Ich habe jetzt seit ein paar Stunden darüber nachgedacht. Ich weiß es immer noch nicht. Haben Sie im Übrigen bestätigt, dass das Schreib-Caching auf allen Volumes immer noch deaktiviert ist, da Sie davon ausgehen, dass auf dem Server häufig Stromausfälle auftreten? Ich weiß, dass dies die Standardeinstellung ist, wenn Sie dcpromo verwenden, aber sie kann überschrieben werden. Ich möchte nur sicherstellen, dass Sie das Schreib-Caching nicht wieder aktiviert haben.
Ryan Ries

Gute Vermutung zum Schreiben von Caching. Neben dem Systemcache verfügt der Server über einen Hardware-RAID-Controller, der ebenfalls überprüft werden sollte. Ich werde morgen einen Blick darauf werfen.
Massimo

Antworten:


6

Ich habe heute ein paar Stunden darüber nachgedacht. Es ist ein bisschen verwirrend, aber wie ich in meinem Kommentar angedeutet habe, ist meine beste Vermutung, dass entweder eine Art Festplatten-Caching stattfindet, das nicht auf die Festplatte übertragen wird, bevor der Stromausfall / das schmutzige Herunterfahren den Inhalt des Caches gelöscht hat ... Oder, da Sie auf einem RAID-Volume arbeiten, auf dem ntds.dit gespeichert ist, kann der Stromausfall dazu führen, dass Ihr RAID-Volume vorübergehend unterbrochen oder inkohärent wird, wenn auch nur für einen Moment.

Wir wissen, dass die Parteilinie bei USN-Rollbacks besteht, wenn ein DC in einem früheren Zustand wiederhergestellt wird. Das klassische Beispiel ist das Wiederherstellen eines virtualisierten DC aus einem Snapshot. Ich weiß, dass dies nicht genau auf Sie zutrifft ... aber selbst bei einer Festplatte mit einem Schreibcache können Sie sich vorstellen, dass die Daten, die sich physisch auf der Festplatte befinden, einen "vorherigen Status" enthalten, während sich der Schreibcache befindet ist das, was tatsächlich den aktuellsten Zustand des DC enthält ... selbst wenn die beiden Zustände nur eine halbe Sekunde voneinander entfernt sind.

Denken Sie über diese Kommentare von Microsoft nach:

Richtlinien für virtualisierte Domänencontroller

Virtuelle SCSI-Festplatten bieten im Vergleich zur virtuellen IDE eine höhere Leistung und unterstützen Forced Unit Access (FUA). FUA stellt sicher, dass das Betriebssystem Daten direkt von den Medien schreibt und liest, wobei alle Caching-Mechanismen umgangen werden.

Ich weiß, dass Ihr DC keine VM ist, aber das Konzept gilt immer noch. Festplatten-Caching und DCs werden nicht gemischt. Aus diesem Grund wird durch die Installation von Active Directory das Schreib-Caching als Windows-Richtlinie deaktiviert. Sie können jedoch weiterhin Caching-Mechanismen in Ihrem Hardware-RAID-Controller usw. verwenden.

Szenario B: Starten von Active Directory von anderen Laufwerken in einem defekten Spiegel

  1. Heraufstufen eines Domänencontrollers. Suchen Sie die Datei Ntds.dit auf einem gespiegelten Laufwerk.

  2. Brechen Sie den Spiegel.

  3. Fahren Sie mit der eingehenden und ausgehenden Replikation fort, indem Sie die Datei Ntds.dit auf dem ersten Laufwerk im Spiegel verwenden.

  4. Starten Sie den Domänencontroller mithilfe der Datei Ntds.dit auf dem zweiten Laufwerk im Spiegel.

Das ist ein Replikationskiller, der mich auf physischen DCs mit RAID 1-Volumes sehr gebissen hat. Ich persönlich hatte noch nie einen tatsächlichen USN-Rollback, der dadurch verursacht wurde, aber die Replikation auf diesem DC wird dadurch beendet. Ich meine, stellen Sie sich ein RAID 1-Volume mit 2 Festplatten vor. 1 Antrieb stirbt. Sie entfernen es, legen ein neues Laufwerk ein ... aaaaaaund DSA nicht beschreibbar.

Aus dem AskDS-Blog :

Wenn Sie keine unterbrechungsfreien Stromversorgungen (USV) für Ihre VM-Hosts oder die Speicherplatte haben, auf der sich die Active Directory-Datenbank befindet, stellen Sie sicher, dass das Schreib-Caching auf dem Host-Computer der virtuellen Maschine deaktiviert ist. Weitere Hinweise finden Sie unter diesem Link. Wenn umgekehrt das Schreib-Caching für den VM-Host, auf dem sich der DC befindet, aktiviert bleiben muss, installieren Sie eine USV, um Schäden an den DCs zu vermeiden.

Auch hier geht es um virtualisierte DCs, aber das Disk-Caching-Konzept gilt auch für physische DCs.

Da ist also meine Idee. Ich denke, es hat etwas mit Ihrem Speichersystem zu tun. Auf jeden Fall möchten Sie alle Caching-Mechanismen zumindest auf dem Volume ntds.dit deaktivieren, insbesondere wenn Sie zu Stromausfällen neigen.


2
Genau meine Gedanken. Schreiben Sie den Cache auf den Array-Adapter, aber nicht batteriegepuffert. Würde 0,05 GBP darauf setzen :-)
Simon Catlin

1
Der Schreibcache war auf dem RAID-Controller tatsächlich aktiviert, und das Betriebssystem konnte ihn nicht automatisch deaktivieren. Ich habe es manuell deaktiviert und hoffe, dass dies das Problem ein für alle Mal behoben hat. Diese Konfiguration war sehr wahrscheinlich die Hauptursache.
Massimo

Nett! Das sollte dich so lange aufhalten, bis du UPS besser machen kannst! ;)
Ryan Ries

Bestätigt: Das Problem trat nie wieder auf, nachdem der (nicht batteriegepufferte) Schreibcache auf dem physischen Festplattencontroller deaktiviert wurde.
Massimo

@Massimo Ich liebe es, dass du nach 4 Jahren zurückgekommen bist, um dies zu bestätigen. :)
Ryan Ries
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.