Domänen-Controller unter Windows Server 2012 virtualisieren

    Snapshots im Hyper-V-ManagerDie Hypervisor-Hersteller erheben den Anspruch, dass sich mittlerweile fast alle Workloads in virtuellen Maschinen ausführen lassen, darunter auch unternehmenskritische Anwendungen wie SAP. Daher liegt es nahe, auch die Domänen-Controller des Active Directory zu virtualisieren. Bis Windows Server 2008 R2 konnte dies jedoch zu ernsthaften Nebenwirkungen für den Verzeichnisdienst führen. Die Domänendienste in Server 2012 zeigen sich nun resistenter gegen Hypervisor-Aktionen wie Snapshots oder Cloning.

    Die Argumente für die Virtualisierung von Domänen-Controllern sind grundsätzlich die gleichen wie bei allen anderem Anwendungen: Sie verbessert die Auslastung der vorhandenen Hardware-Ressourcen, virtualisierte DCs lassen sich in Backup und DR für die virtuelle Infrastruktur einbeziehen, und Hochverfügbarkeit kann relativ einfach ohne herkömmliche Cluster auf OS-Ebene erreicht werden.

    Hürden für virtuelle Domänen-Controller

    Allerdings drohen auch einige gewichtige Schwierigkeiten bei der Virtualisierung von Domänen-Controllern:

    • Wenn das Management von Active Directory und virtueller Infrastruktur in einer Firma organisatorisch getrennt sind, dann kann dies aufgrund der sicherheitskritischen Rolle des AD zu unerwünschten Überschneidungen von Kompetenzen führen.
    • Die Kapazitätsplanung für virtualisierte DCs ist schwierig, weil Domänen-Controller oft sehr unregelmäßige Auslastungsmuster mit hohen Leistungsspitzen aufweisen.
    • Eine ungeschickte Konfiguration der virtuellen Infrastruktur kann dazu führen, dass mehrere oder alle DCs auf einem Host konzentriert werden und so ein Single Point of Failure entsteht. Dafür kann auch die organisatorische Trennung von AD- und Virtualisierungs-Management verantwortlich sein, wenn etwa die Vitualisierungs-Admins aufgrund undurchsichtiger Namenskonventionen nicht wissen, in welchen VMs ein DC läuft.
    • Aus Gründen der einfacheren Verwaltung sollten die Hosts, wenn sie unter Hyper-V laufen, Mitglied einer Domäne sein. Beim Booten des Hosts stehen DCs, die auf ihm in einer VM ausgeführt werden, natürlich noch nicht zur Verfügung. Dies könnte dazu führen, dass auf dem Host das restriktive Firewall-Profil Öffentlich greift und den Remote-Zugriff behindert.
    • Die Zeitsynchronisierung kann in eine Endlosschleife geraten, wenn das Gast-OS in einer VM seine Systemzeit vom Host erhält und umgekehrt der Host seine Zeiteinstellung vom DC aus der VM bezieht.

    USN-Rollback als größtes Problem

    Die genannten Hürden lassen sich mit entsprechender Planung und den geeigneten Maßnahmen überwinden. Bis dato war allerdings kein Kraut gegen die Folgen gewachsen, zu denen das Zurücksetzen einer VM auf einen früheren Snapshot führte. Dieser Fall kann auch Eintreten, ohne dass ein Admin diesen Vorgang explizit auslöst, wenn der Host per Voreinstellung die VMs beim Herunterfahren per Snapshot sichert.

    Bis dato war ein Domain Controller nicht darüber informiert, wenn er mit den Mitteln der Plattform, auf der er lief, auf einen früheren Zustand zurückgesetzt wurde. Daraus resultierten 2 Arten von Problemen:

    • USN Bubble: Die Replikation der Domänendienste nutzt die InvocationID (eine eindeutige Kennung für die Datenbank eines jeden DC) in Kombination mit der Update Sequence Number (USN), um festzustellen, welche Änderungen weitergegeben werden müssen. Die USN wird normalerweise bei jedem Schreibzugriff hochgezählt, würde aber bei der Restaurierung eines Snapshots auf einen früheren Stand zurückgesetzt. Daher werden alle Änderungen bis zum Erreichen der höchsten schon vergebenen USN von der Replikation ignoriert, weil sie aufgrund ihrer USN als bereits abgearbeitet gelten.
    • Lingering Objects: Bekanntlich entfernt das Löschen eines AD-Objekts dieses nicht sofort aus dem Verzeichnis, sondern belässt es noch für einen bestimmten Zeitraum als Thumbstone. Der Löschvorgang wird zwischen allen DCs einer Domäne repliziert und nach Ablauf der Thumbstone Lifetime wird das Objekt endgültig aus allen DC-Datenbanken getilgt.
      Wird ein DC jedoch auf einen früheren Zustand zurückversetzt, dann kann er Objekte enthalten, die auf anderen DCs bereits entfernt wurden. Er wird aber per Replikation nicht mehr über diesen Löschvorgang informiert, so dass sie auf Dauer zurückbleiben und damit möglicherweise ein Sicherheitsrisiko darstellen.

    Virtualisierungsbewusste Domain Services

    Windows Server 2012 beugt diesen Replikationsproblemen vor, indem die Domänendienste nun Kenntnis darüber erhalten, dass die VM auf einen früheren Zustand zurückgesetzt oder kopiert wurde. Zu diesem Zweck blendet der Hypervisor in den Adressraum einer VM eine eindeutige, 128 Bit lange VM-GenerationID ein, die das Gastsystem über einen eigenen Treiber auslesen kann.

    Die AD-Domänendienste übernehmen bei ihrer Installation diese VM-GenerationID und schreiben sie in das Attribut msDS-GenerationID des Computer-Objekts, das den DC repräsentiert. Anschließend vergleichen sie bei jedem Neustart des Domänen-Controllers den gespeicherten ursprünglichen Wert mit jenem, den der Hypervisor aktuell anzeigt. Wurde die VM auf einen Snapshot zurückgesetzt oder geklont, dann ändert der Hypervisor die VM-GenerationID und die Domänendienste erkennen den problematischen Zustand anhand der voneinander abweichenden IDs.

    Keine Wiederverwendung von USNs

    Tritt dieser Fall ein, dann wird die InvocationID der Datenbank zurückgesetzt und der RID-Pool des Domänen-Controllers verworfen. Das verhindert die Wiederverwendung von bereits benutzten USNs und damit die Entstehung von Replikationsproblemen. Außerdem wird bei dieser Gelegenheit das SYSVOL-Verzeichnis synchronisiert. Auch wenn die AD DS nun gegen die Wiederherstellung eines VM-Snapshots gesichert sind, empfiehlt Microsoft, diese nicht als Alternative zu einem DC-Backup zu verwenden.

    Systemvoraussetzungen

    Es liegt auf der Hand, dass die Abstimmung zwischen Hypervisor und Domänendienste entsprechende Fähigkeiten auf beiden Seiten voraussetzt. Daher muss zum einen der DC unter Windows Server 2012 laufen, zum anderen muss der Hypervisor die VM-GenerationID im erforderlichen Format erzeugen. Dazu ist Windows Server 2012 Hyper-V oder der kostenlose Hyper-V Server 2012 erforderlich. Auf der Website von VMware gibt es keine explizite Bestätigung für den Support von VM-GenerationID durch ESXi, aber die Beschreibung dieses Patches (PR886363) für vSphere 5.0 lässt darauf schließen, dass es dieses Feature unterstützt.

    1 Kommentar

    Bild von Andi Sichel
    Andi Sichel sagt:
    9. November 2012 - 11:17

    Hallo, danke für den Beitrag. Ich habe eine kleine Installationsanweisung geschrieben wie ein Domänencontroller unter Windows Server 2012 geklont werden kann.

    http://blog.asichel.de/active-directory-domaincontroller-klonen/

    MfG Andi Sichel