Delen via

Hyper-V Replica Failover fuer Domain Controller

  • Artikel

Hallo, hier wieder einmal Rol mit einem Ausflug in die neuen Server 2012 Feature-Gefilde von Hyper-V.
Einige von euch haben vom neuen Virtualisierungs-Feature “Hyper-V Replica” sicher schon gehört, siehe auch “Hyper-V Replica Overview”, https://technet.microsoft.com/en-us/library/jj134172.aspx  
Dahinter steckt eine eigene Synchronisation einer virtualisierten Disk, die als Replica mit einer primären Instanz nach initialer VM-Replikation periodisch auf Stand gehalten wird.
Dennoch kann nicht garantiert werden, daß der Stand 100% identisch ist. Für Domain Controller ergibt sich beim Failover auf das VM-Replica damit natürlich automatisch die Frage, ob dadurch nicht ein USN Rollback möglich ist, wie beschrieben in “USN and USN Rollback”; https://technet.microsoft.com/en-us/library/d2cae85b-41ac-497f-8cd1-5fbaa6740ffe(v=ws.10)#usn_and_usn_rollback und dabei die weitere AD Replikation unterbunden wird, siehe KB Artikel “ 875495 How to detect and recover from a USN rollback in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2”; https://support.microsoft.com/kb/875495/EN-US ?

Bei Server 2012 Domain Controller Guest gibt es bei Server 2012 Hyper-V das neue Feature der “VM-Generation ID”, bei der der DC Guest bei einer Änderung einem potentiellen USN Rollback automatisch vorbeugt, indem er die AD Replikation mit einer neuen “Incovation ID” betreibt. Dieser Mechanismus ist sehr schön beschrieben in “ Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100) ”, https://technet.microsoft.com/en-us/library/hh831734.aspx als Einführung für das ebenfalls neue Feature “ Virtualized domain controller cloning ” (beschrieben in  “ Virtualized Domain Controller Technical Reference (Level 300) ”; https://technet.microsoft.com/en-us/library/jj574214.aspx ), aber funktioniert das auch mit dem eingangs beschriebenen Virtualisierungs-Feature “Hyper-V Replica”?

Da wir auf der Suche in unseren Microsoft Whitepapern dazu keine klare Aussage finden konnten, haben Robert, unser Hyper-V Experte  (der auch seinen eigenen Blog “https://blogs.msdn.com/b/robertvi” pflegt), und ich das ganze ausprobiert.

Zunächst hatte Robert ein Server 2012 Hyper-V Replica angelegt. Im Hyper-V Manager wird das für seinen DC Guest vDC2 in einem eigenen Tab “Replication” angezeigt:

replica-1

Im Anschluß haben wir dann den Ausfall von vDC2 auf dem Primären Server, hier Host CL1N2 simuliert, sind auf den Replica Server CL2N1 gegangen und haben dort den Failover von Guest vDC2 initiiert:

replica2-1

Hier kommt dann die allgemeine Warnung über möglichen Datenverlust. Das reflektierte dann zunächst unsere Bedenken bezüglich USN Rollback:

replica31

Umso gespannter waren wir also, nachdem der Replica DC gestartet war. Doch die folgenden Directory Service Events gaben dann schnell Entwarnung, daß dar Failover Vorgang über die “VM-Generation ID” sauber gehandhabt worden war (Failover wurde um 9:25 Uhr ausgeführt). Hier die DS Events von Replica vDC2:

Zunächst prüft der 2012 DC Guest über seinen Hypervisor Driver ob “VM Generation ID” unterstützt wird und welcher Wert übermittelt wird:

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 28.11.2012 09:25:22
Event ID: 2168
Task Category: Internal Configuration
Level: Information
Keywords: Classic
User: ANONYMOUS LOGON
Computer: VDC2.CONTOSO.COM
Description: The DC is running on a supported hypervisor. VM Generation ID is detected.
Current value of VM Generation ID: 4763348314524170831

Im Anschluß überprüft der DC dann den Wert seines eigenen Computer Attributes msDS-GenerationId im AD:

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 28.11.2012 09:25:22
Event ID: 2172
Task Category: Internal Configuration
Level: Information
Keywords: Classic
User: ANONYMOUS LOGON
Computer: VDC2.CONTOSO.COM
Description: Read the msDS-GenerationId attribute of the Domain Controller's computer object.
msDS-GenerationId attribute value: 7055439790112386533

So ermittelt er die Änderung als Auslöser für das sogenannte “Virtualization Safeguarding”:

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 28.11.2012 09:25:22
Event ID: 2170
Task Category: Internal Configuration
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: VDC2.CONTOSO.COM
Description: A Generation ID change has been detected.
Generation ID cached in DS (old value): 7055439790112386533
Generation ID currently in VM (new value): 4763348314524170831
The Generation ID change occurs after the application of a virtual machine snapshot, after a virtual machine import operation or after a live migration operation. Active Directory Domain Services will create a new invocation ID to recover the domain controller. Virtualized domain controllers should not be restored using virtual machine snapshots. The supported method to restore or rollback the content of an Active Directory Domain Services database is to restore a system state backup made with an Active Directory Domain Services aware backup application.

Wie erwartet ändert er nun seine "Invocation ID" wie bei einem Restore, das vermeidet dann auch USN Rollback:

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 28.11.2012 09:25:22
Event ID: 1109
Task Category: Replication
Level: Information
Keywords: Classic
User: ANONYMOUS LOGON
Computer: VDC2.CONTOSO.COM
Description: The invocationID attribute for this directory server has been changed. The highest update sequence number at the time the backup was created is as follows:
InvocationID attribute (old value): dd1a3c48-9ddc-4706-adfd-59cf21d6a731
InvocationID attribute (new value): 7b305219-e3dc-443a-a9d2-8f1f3be9e58b
Update sequence number: 671753
The invocationID is changed when a directory server is restored from backup media, is configured to host a writeable application directory partition, has been resumed after a virtual machine snapshot has been applied, after a virtual machine import operation, or after a live migration operation. Virtualized domain controllers should not be restored using virtual machine snapshots. The supported method to restore or rollback the content of an Active Directory Domain Services database is to restore a system state backup made with an Active Directory Domain Services-aware backup application.

Dies ist auch nachvollziehbar mit der Ausgabe von REPADMIN /SHOWSIG <DCNAME> über die gesamte Invocation History:

Repadmin: running command /showsig against full DC localhost
Default-First-Site-Name\VDC2
Current DSA invocationID: 7b305219-e3dc-443a-a9d2-8f1f3be9e58b
dd1a3c48-9ddc-4706-adfd-59cf21d6a731 retired on 2012-11-28 09:25:22 at USN 671753
c9669f31-192d-40ea-9305-d793c81b634b retired on 2012-11-27 15:19:27 at USN 663560 (richtig, Test vom Vortag :) )

Die neue Invocation ID wird mit REPADMIN /SHOWREPL <DCNAME> sichtbar:

Repadmin: running command /showrepl against full DC localhost
Default-First-Site-Name\VDC2
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 28381ac8-100c-4584-9778-c474c7245fcf
DSA invocationID: 7b305219-e3dc-443a-a9d2-8f1f3be9e58b
==== INBOUND NEIGHBORS ======================================
DC=CONTOSO,DC=COM
    Default-First-Site-Name\DC1 via RPC
        DSA object GUID: ce5ca510-a1a3-4d99-a27a-ae5ff9330ce1
        Last attempt @ 2012-11-28 13:49:00 was successful.
CN=Configuration,DC=CONTOSO,DC=COM
    Default-First-Site-Name\DC1 via RPC
        DSA object GUID: ce5ca510-a1a3-4d99-a27a-ae5ff9330ce1
        Last attempt @ 2012-11-28 12:49:16 was successful
…

Auch Sysvol wird Non-Authoritative zurückgesetzt:

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 28.11.2012 09:25:22
Event ID: 2208
Task Category: Internal Configuration
Level: Information
Keywords: Classic
User: N/A
Computer: VDC2.CONTOSO.COM
Description: Active Directory Domain Services deleted DFSR databases to initialize SYSVOL replica during a non-authoritative restore.
Active Directory detected that the virtual machine that hosts the domain controller was reverted to a previous state. Active Directory Domain Services needs to initialize a non-authoritative restore on the local SYSVOL replica. For DFSR, this is done by stopping the DFSR service, deleting DFSR databases, and re-starting the service. Upon restarting DFSR will rebuild the databases and start the initial sync.

Abschließend setzt der DC sein Computer Attribute msDS-GenerationId im AD zu dem neuen Wert, den er vom Hypervisor über “VM Generation ID” erhalten hat:

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 28.11.2012 09:25:22
Event ID: 2179
Task Category: Internal Configuration
Level: Information
Keywords: Classic
User: ANONYMOUS LOGON
Computer: VDC2.CONTOSO.COM
Description: The msDS-GenerationId attribute of the Domain Controller's computer object has been set to the following parameter:
GenerationID attribute: 4763348314524170831

Damit ist er dann fertig – ich kann nur sagen “gut gemacht”:

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 28.11.2012 09:25:32
Event ID: 1000
Task Category: Service Control
Level: Information
Keywords: Classic
User: ANONYMOUS LOGON
Computer: VDC2.CONTOSO.COM
Description: Microsoft Active Directory Domain Services startup complete, version 6.2.9200.16384

So ist nun bewiesen, daß die Features “Hyper-V Replica” und “Virtualization Safeguarding” vom DC Guest gut zusammenarbeiten. Für die Verfügbarkeit von Server 2012 DCs ist das schon eine super Sache!!!
Dennoch ist natürlich angeraten, alle Spielarten selbst auszutesten, denn nichts hilft für den Ernstfall mehr, als eigene Erfahrung.

Damit nun “Happy Virtualization” !
Robert und Rol

Comments

  • Anonymous
    January 01, 2003
    Hallo! Dieses Henne-Ei Problem war jetzt nicht das Thema dieses Blogs. Nun ist das Thema immer sehr aktiv auf den TechNet-Foren, deswegen ist es wert das mal in größerem Rahmen zu besprechen. Das ist ein Problem nur mit Hyper-V Clustern vor Windows Server 2012, das Thema ist mit Windows Server 2012 Hyper-V Host komplett gelöst. Damit Hyper-V Gäste starten kann, ist kein Domain Controller mehr nötig, der Dienst läuft unter LocalSystem und kann das Cluster-Volume allokieren ohne eine Domain-Anmeldung. Abgesehen davon empfehlen wir nicht, alle Domain Controller auf derselben Hardware-Plattform zu betreiben, siehe "Avoid creating single points of failure": technet.microsoft.com/.../virtual_active_directory_domain_controller_virtualization_hyperv(v=WS.10).aspx Wichtig: Das Whitepaper empfiehlt nicht, mindestens einen DC pro Domain in Hardware zu betreiben. Es geht um Diversifizierung in der Hardware, andere unterstützte Hyper-Visoren sind also auch akzeptabel. Vielleicht ist je nach Kundensituation aber auch ein komplett getrennter Hyper-V Cluster auch akzeptabel, da Microsoft sicher keinen Fehler einbaut, der Hyper-V Hosts als ganzes lahm legt. Auch in Hardware ist man vor solchen Problemen nicht geschützt. Ein Beispiel wäre, wenn man nur  gleiche Server mit demselben Raid Controller hat, und die neueste Version der Firmware hat einen Bug, der die Volumes korrumpiert. Oder alle DCs arbeiten mit demselben SAN Backend und dieses hat einen Totalschaden. Und ja, jedes dieser Beispiele ist schon mindestens einmal bei unseren Kunden passiert. Außer einem kompletten Hyper-V Ausfall, der war mit einem anderen, hier ungenannt bleibenden, Hyper-Visor. Also insgesamt ein weiterer Grund, mit DCs und Hyper-V komplett auf Windows Server 2012 zu wechseln. Viel Erfolg dabei wünscht Herbert Mauerer

  • Anonymous
    November 28, 2012
    Sehr schöne Ausführung und Beschreibung!

  • Anonymous
    December 26, 2012
    The comment has been removed

  • Anonymous
    February 20, 2013
    Vielen Dank für den schönen Artikel! :)

  • Anonymous
    June 04, 2013
    Waren eure beiden HyperV Hosts nur in einer Workgroup, also ohne extra physischen Domänencontroller?