Tags: Virtualisierung, System-Management, Windows Server, Active Directory
Dass man laufende Datenbanken wie etwa Exchange oder SQL nicht per Snapshot abbilden und von einem solchen Abbild wiederherstellen soll, ist allgemein bekannte Best Practice. Die Begründung liegt auf der Hand: Datenbanken speichern nicht alle Änderungen sofort, sondern schreiben sie zunächst in ein Transaktionslog oder Journal. Ein Snapshot einer Datenbank ist also höchstwahrscheinlich nicht konsistent – es sei denn, sie wurde heruntergefahren, läuft längere Zeit ohne Schreibzugriff oder aber das Datenbank-Produkt kann mit der Snapshot-Technik umgehen, analog wie man es etwa per VSS ein konsistentes Backup erstellen würde.
Domain Controller: Nie Snapshots!
Für virtuelle Domain Controller gilt ein erweitertes Verbot: Auch wenn man für Konsistenz sorgt, indem man den Server etwa vor dem Snapshot herunterfährt, bleiben Snapshots verboten. Genauer gesagt, sind es nicht die Snapshots – davon darf man beliebig viele erstellen –, sondern deren Wiederherstellung. Der Grund dafür ist die Art, wie Objekte im Active Directory aktualisiert werden: Die Multi-Master-Replikation kennt keine zentrale Kontrollinstanz.
Jedes Objekt besitzt eine Update Sequence Number (USN), die bei dessen Änderung erhöht wird. Journaling Dateisysteme benutzen ähnliche Mechanismen, so zum Beispiel NTFS. Allerdings wird die USN pro DC separat geführt, nicht repliziert und ist pro Objekt auf allen DCs unterschiedlich. Auch die DCs selbst besitzen USNs, die jeweils pro Änderung erhöht werden und pro DC unterschiedlich sind.
Erreicht wird dies durch unterschiedliche Startwerte, deshalb kann das beim Restaurieren eines Snapshots beschriebene unerwünschte Szenario auch anders auftreten, etwa durch Überlauf, wenn man einen ausgeschalteten DC nach langer Zeit wieder ans Netz anschließt.
Durch Restaurieren eines Snapshots kommt es zum USN-Rollback, das heißt der DC ist plötzlich und unerwartet mit einer alten USN im Netz. Die Folgen sind unangenehm bis zerstörend, je nachdem.
Das passiert beim USN-Rollback
Die aktuelle USN jedes DCs wird in den anderen DCs gespeichert. Regt einer von ihnen eine Replikation mit einer niedrigeren USN an, als er vorher bereits propagierte, wird er zum Schutz des Active Directory isoliert – richtigerweise gehen die anderen DCs von einer fehlerhaften Wiederherstellung aus und stellen ihn unter Quarantäne. Das ist der einfache Fall – lästig, weil man den Domain Controller neu aufsetzen muss, aber nicht übermäßig schlimm.
Wenn bei der nächsten Replikation die USN bereits wieder höher ist, hat das Active Directory keine Chance, den Fehler festzustellen. Der restaurierte DC erhält dann Objekt-Updates, die zwar zu seiner USN passen, aber nicht zu den tatsächlich auf ihm gespeicherten Objektdaten, die ja einen früheren Stand repräsentieren.
Das bleibt dauerhaft unbemerkt und man besitzt einen Domain Controller, dessen Active-Directory-Datenbank eine andere ist als die der restlichen DCs, was aber durch die Replikation weder bemerkbar noch behebbar ist. Ein solcher Fehler ist nur schwer zu finden, wächst mit der Zeit und stellt über kurz oder lang ein großes Problem dar.
Täglich Know-how für IT-Pros mit unserem Newsletter
Ähnliche Beiträge
Weitere Links
3 Kommentare
Eine Frage: Wenn bei der nächsten Replikation die USN wieder höher ist .... Wann tritt dieser Fall ein. Beim Image Restore ist si USN niedriger und die anderen DCs replizieren nicht mit dem Restore DC. Wenn ich nun den "Restore DC" demote und/oder demote und neu promote/installiere, vorher das AD bereinige, dann wird diese DC als neuer DC hinzugefügt und die Replikation funktioniert einwandfrei, oder?
Oder anderes herum gefragt: Wann bekommt ein DC der per Image restored wurde wieder Obejektänderungen von den anderen DCs. ich dachte bis dass die anderen DCs die Replikation verweigern würden.
Den restaurierten DC zu demoten, sein AD zu bereinigen und dann wieder zu promoten, ist auch die Notfallempfehlung vom Microsoft, etwa in KB875495 nachzulesen. Dort finden Sie auch jedes Detail über die Auswirkung des Rollbacks.
Das Grundproblem besteht darin, daß die anderen DCs nicht wissen können, daß die AD-Datenbank des restaurierten DCs out of date ist. Tools wie etwa Umove können hier noch etwas retten, indem sie das AD auch von einem Image so restaurieren, daß der DC „weiß“, daß er zurückgesichert wurde und die anderen DCs entsprechend benachrichtigen kann. In diesem Falle replizieren sie ihn wieder auf den aktuellen Stand.
Herzliche Grüße,
Andreas Kroschel
Ich hätte dazu auch eine Frage.
Wenn ich im Forest nur einen DC habe - ist der Snapshot und die Anwendung/Rücksetzen unproblematisch?
Und wäre es unproblematisch, wenn ich mehrere DCs im Forest habe und alle herunterfahre bis auf einen – auf diesem einen dann den Snapshot erstelle und ggf Anwende/Rücksetze und den Snapshot wieder lösche bevor ich die anderen DCs wieder Einschalte?