Virtuelle Domain Controller: Snapshots vermeiden

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 Transaktions­log 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.