VMware oder Hyper-V, Tipps bei der Virtualisierung

Die Virtualisierung hat längst Einzug in vielen Unternehmen genommen. Sei es Dateiserver, Druckserver oder Applikationsserver, Dank der Virtualisierung lassen sich alle Serverrollen virtualisieren. Nicht nur das dadurch in Bezug auf Green IT Rechnung getragen wird, durch die Virtualisierung lassen sich auch die Hardwarekosten deutlich senken.

Welche Dienste unter welchem Hypervisor supportet werden, kann man hier in Erfahrung bringen:

Windows Server Catalog

Grundsätzlich lassen sich auch die Infrastrukturserver wie Domänencontroller (DC), Exchange Server und SQL Server virtualisieren. Doch gerade bei diesen Serverrollen und insbesondere bei virtuellen DCs (vDCs), gibt es einiges mehr im Betrieb zu beachten als bei physikalischen Servern. Sonst kann es unter Umständen und je nach Größe der Umgebung im Extremfall, in einem Desaster enden! Bei vDCs muss man die Stolperfallen kennen, alleine schon aus dem Grund, da bei physikalischen Servern viele Möglichkeiten erst gar nicht zur Verfügung stehen. Dabei spielt es keine Rolle, welcher Hypervisor (Hyper-V, ESX…) sich im Einsatz befindet.

Die Virtualisierung von DCs hat aber auch, neben Green IT und der Hardwareersparnis, weitere Vorteile. Sichert man einen vDC auf einer anderen Hardware zurück, kann man sich die Hardware-Abstraktion zunutze machen, da man weniger Treiberprobleme hat, als wenn man einen physikalischen DC auf einer anderen Hardware rücksichert. Auch bei der Rollentrennung hilft die Virtualisierung.

 


Die GOs und NO-GOs bei virtuellen DCs
* Die Zeit: Die Zeitsynchronisation innerhalb einer AD Umgebung ist von großer Bedeutung! Denn Microsoft setzt in einer AD Umgebung seit Windows 2000 das Authentifizierungsprotokoll Kerberos in der Version 5 ein und dieses toleriert standardmäßig eine Zeitdifferenz von gerade einmal fünf Minuten. Weicht die Zeit mehr als fünf Minuten ab, verliert das Kerberos Ticket Granting Ticket (kurz TGT) seine Gültigkeit.

* Der für die Zeit verantwortliche DC einer Gesamtstruktur ist der DC, der die FSMO-Rolle des PDC-Emulators in der Root-Domäne innehat! Man sollte den PDC-Emulator der Root-Domäne gegen eine externe Quelle (entweder aus dem Internet oder Hardware-Uhr) abgleichen lassen. Auf der Firewall muss dazu der Port 123 offen sein, wenn mit einer Quelle aus dem Internet abgeglichen werden soll. Der PDC-Emulator muss aber nicht seine Zeit mit einer externen Quelle abgleichen. Die tatsächliche Zeit ist nicht zwingend notwendig. Sie muss nur innerhalb einer Gesamtstruktur synchron sein!

* Alle DCs holen sich ihre Zeit dann vom PDC-Emulator. Die Clients sowie Mitgliedsserver synchronisieren sich ihre Zeit mit ihrem Anmeldeserver, also von dem DC, bei dem sich der Client bzw. Mitgliedsserver authentisiert. Dieser muss nicht zwingend der PDC-Emulator sein.

* Die PDC-Emulatoren der Subdomänen holen sich wiederum ihre Zeit, vom PDC-Emulator der Root-Domäne. Der PDC-Emulator der Root-Domäne ist die maßgebliche Zeitquelle für die Gesamtstruktur.

* Die Zeitsynchronisation mit einer Quelle aus dem Internet, wird auf dem PDC-Emulator der Root-Domäne mit dem folgenden Befehl eingerichtet:

* w32tm /config /update /manualpeerlist:de.pool.ntp.org /syncfromflags:MANUAL /reliable:YES

* Wenn an W32time nichts verstellt wurde (per GPO), hat man anschließend eine funktionierende Zeitsynchronisation!
*
Es sollte darauf geachtet werden, dass virtuelle Maschinen und gerade vDCs ihre Zeit nicht vom Hostsystem (was zum Beispiel unter Hyper-V in den Integrationsdiensten der VM standardmäßig der Fall ist), sondern von der Domäne übernehmen. Oder wenn es gewünscht ist das die vDCs ihre Zeit vom Hostsystem übernehmen, so sollte darauf geachtet werden das auf dem Hostsystem derselbe Zeitserver konfiguriert ist, der auch auf dem PDC-Emulator konfiguriert wurde.


* Kein AD in der Hyper-V Parent Partition: Das Ausführen von DCPROMO auf einem Hyper-V Host ist ein NO-GO, erst recht nicht wenn bereits VMs auf dem Host in Betrieb sind! Auch wenn es technisch möglich ist in der Parent Partition zusätzliche Dienste auszuführen, ist es mitnichten empfohlen dies zu tun. Da unter Hyper-V sich die Treiber für die Hardware in der Parent Partition befinden und der gesamte I/O für den Speicher- sowie Netzwerkzugriff von und zu den VMs durch die Parent Partition verläuft, sollte man den Hyper-V Host nicht unnötig noch mit weiteren Diensten an seine Leistungsgrenzen bringen. Deshalb sollte der Hyper-V Host ausschließlich zur Verwaltung der VMs dienen und keineswegs zum DC gestuft werden!

* Befinden sich alle in der Domäne verfügbaren vDCs auf demselben Host, wäre da noch bei einem Neustart des Hosts das Henne-Ei Problem. Ist der Host ein vDC und würden alle in der Domäne verfügbaren vDCs auf demselben Host betrieben werden, würde der Neustart des Hosts länger dauern. Denn nach einem Neustart des Hosts muss zuerst das AD-integrierte DNS auf den vDCs zur Verfügung stehen. Da bei einem Neustart aber kein DC der die DNS-Zone zur Verfügung stellt bereitsteht, kommt es zu erheblichen Verzögerungen während eines Neustarts.

* Wenn es sich um einen Hyper-V Cluster handelt und alle in der Domäne verfügbaren vDCs befinden sich auf dem Cluster, so hat man bei einem Neustart größere Probleme, da der Cluster ohne einen DC nicht startet!

* Die Ausfallsicherheit: Die Ausfallsicherheit beim AD ist bereits dann gewährleistet, wenn mindestens zwei DCs innerhalb einer Domäne existieren. Natürlich sollten in einer virtualisierten Umgebung nicht alle in der Domäne verfügbaren vDCs auf demselben Host betrieben werden, sonst hat man einen Single Point of Failure (SPoF). Die Erklärung dürfte selbsterklärend sein, denn wenn der einzig verfügbare Host beispielsweise wegen einem Hardwaredefekt ausfallen sollte, würde kein vDC mehr zur Verfügung stehen und die Domäne wäre erst mal verloren. Daher ist es ratsam vDCs mindestens auf mehrere Hosts zu verteilen, wenn nicht noch zusätzlich ein physikalischer DC existiert (was zu empfehlen ist!).

    Wie immer gilt, in jeder Domäne sollten sich mindestens zwei DCs befinden!
    Wie viele DCs pro Domäne werden benötigt?


* Mindestens ein physikalischer DC: Es ist empfehlenswert mindestens einen physikalischen DC in der Domäne zu betreiben. Denn wenn alle DCs einer Domäne virtuell wären, ist man gegen einen Ausfall des Hypervisors (beispielsweise durch ein Windows Update) nicht geschützt. Fällt der Hypervisor aus und existieren ausschließlich vDCs, wäre die Domäne verloren. Des Weiteren ist es empfehlenswert, dass der physikalische DC die Rolle des PDC-Emulators wegen der Zeitsynchronisation innehat. Empfehlenswert ist es auch, neben dem PDC-Emulator noch die beiden gesamtstrukturweiten FSMO-Rollen Schemamaster sowie Domänennamenmaster auf den physikalischen DC zu verschieben.
    Die FSMO-Rollen verschieben


    Kein Snapshot von vDCs erstellen: Allgemein ist das Erstellen eines Snapshots eine nützliche Funktion. Ein Snapshot ist eine Momentaufnahme einer VM. Vor einer Konfigurationsänderung einer VM, kann man einen Snapshot erstellen und nach einer fehlgeschlagenen Konfigurationsänderung, zum vorherigen Zustand Dank des Snapshots zurückkehren. Diese Funktion sollte aber mit Bedacht und nur auf supporteten VMs eingesetzt werden!

    Da es sich beim AD um ein verteiltes Datenbanksystem handelt, darf das Snapshotfeature zum Sichern und Wiederherstellen eines vDCs keineswegs verwendet werden (nicht zu verwechseln mit dem NTDSUTIL-Snapshot)! Erst recht nicht in einer AD Umgebung mit mehr als einem DC! Ein Snapshot ist auf einem vDC, egal welcher Hypervisor eingesetzt wird, stets zu 100% nicht supportet(!) und ist ein striktes NO-GO! Denn damit verursacht man in einer AD Umgebung mit mehr als einem DC ein USN Rollback und gefährdet somit die Datenkonsistenz. Sichert man einen Snapshot zurück, wird das Betriebssystem und die AD Datenbank in einen früheren Zustand versetzt und genau durch diese Vorgehensweise, erzeugt man ein USN Rollback. Wurde ein vDC mit einem Shapshot zu einem vorherigen Stand rückgesichert, stellen ab sofort die Replikationspartner die AD-Replikation zu und von diesem vDC ein. Des Weiteren richtet das Rücksichern eines Snapshots auf einem vDC unter Umständen (RID-Master) einen erheblichen Schaden an.

    Auch wenn man vorher alle DCs einer Domäne herunterfährt und danach von einem vDC ein Snapshot erstellt, bleibt die Problematik dieselbe. Sobald man einen Snapshot auf einem vDC in einer AD Umgebung mit mehr als einem DC zurücksichert, entsteht ein USN Rollback. Dabei ist es irrelevant, ob die vDCs online oder offline sind. Wenn ein Snapshot auf einem vDC zurückgesichert wird, ist mindestens der rückgesicherte vDC zerstört.
    Snapshots dienen auch keineswegs als Datensicherung! Auf virtuellen DCs sollte so wie auf physikalischen DCs, regelmäßig auf mindestens zwei vDCs eine System State Sicherung durchgeführt werden.


    Kein Klon erstellen: Das Klonen eines vDCs, im Form von Duplizieren der virtuellen Festplatte (z.B. VHD), ist weder supportet und genauso wie ein SnapShot, ein striktes NO-GO! Denn wenn ein Klon in derselben Gesamtstruktur wie das Original online geht, sind die Folgen Katastrophal! Lediglich den Computernamen und die IP-Adresse zu ändern, bringt überhaupt nichts. Denn entscheidend ist der Directory Service Agent-GUID (kurz DSA-GUID), auch bekannt als objectGUID. Dieser lässt sich nicht ändern und ist in der Gesamtstruktur eindeutig.

    Ferner existieren doppelte RIDs (Relative Identifiers) und doppelte SIDs. Handelt es sich bei dem geklonten vDC auch noch um den FSMO-Rolleninhaber und speziell um den RID-Master bzw. PDC-Emulator, sind die Probleme viel schlimmer! Der Anruf beim Microsoft Produkt Support Service (MSPSS) ist jedenfalls sicher.

    Der RID-Master und sein RID-Pool

    Zu Sicherungszwecken ist ein Klon so wie ein Snapshot, ebenfalls ganz und gar nicht geeignet und ist auch nicht supportet! Denn die Problematik ist dieselbe wie beim Rücksichern eines Snapshots. Wird ein Klon wiederhergestellt, versetzt man den vDC zu einem früheren Zustand. Auch hierbei entsteht ein USN Rollback und in einer Umgebung mit mehr als einem DC, stellen die Replikationspartner umgehend die AD-Replikation ein.

    Es sollte auch vermieden werden, einen Klon in einer angeblich abgeschotteten Testumgebung zu starten, um verschiedene Tests durchzuführen. Denn das Risiko ist zu groß, das irgendwann einmal die Testumgebung aus welchen Gründen auch immer, doch Verbindung zur Produktivumgebung erhält.
    Möchte man sich eine Template-VM erstellen, sollte unbedingt nach der Betriebssysteminstallation SYSPREP (und nicht NEWSID!) ausgeführt werden. Denn erst wenn Sysprep (unter Windows Server 2008 R2 im Verzeichnis %windir%\System32\sysprep) ausgeführt wurde, wird die VM anonymisiert. Erst danach darf das Template geklont werden.


    Keine Image-basierte Sicherung durchführen: Eine Image-basierte Sicherung kann beispielsweise sein, wenn ein vDC automatisiert heruntergefahren, danach kopiert und anschließend automatisiert hochgefahren wird. Oder wenn mit einem Drittanbieter Werkzeug ein Image eines vDCs erstellt wird. Die Wiederherstellung durch solch eine Sicherungsart ist ebenfalls nicht supportet und ist zugleich ein striktes NO-GO! Denn bei einer Wiederherstellung würde man so wie bei einem Snapshot oder Klon, dass Betriebssystem und die AD Datenbank in einen früheren Zustand versetzen. Die USN Rollback Problematik und vor allem der Schaden, mindestens an dem zurück geimageten vDC, ist sicher!

    Deshalb gilt hier das gleiche wie bei einem Snapshot und bei einem Klon: Finger weg von dieser nicht supporteten Sicherungsart!
    Images als Sicherung?


    Die vDC-Sicherung: Wie bei physikalischen DCs, sollte auf mindestens zwei vDCs das System State regelmäßig gesichert werden.

    Es gibt aber noch zwei weitere Methoden, die zum Sichern und Wiederherstellen eines vDCs unterstützt werden:

    1. Das Ausführen der Windows Server-Sicherung im Gastbetriebssystem ist supportet.
    2. Das Ausführen der Windows Server-Sicherung auf dem Hyper-V Host ist supportet. Denn dadurch wird der VSS Writer (Volume Shadow Copy Service, Volumeschattenkopie-Dienst) des Gastbetriebssystems aufgerufen, um sicherzustellen, dass die Sicherung ordnungsgemäß durchgeführt wird.

    Durch diese beiden Methoden, genauso wie beim Wiederherstellen einer System State-Sicherung, wird die invocationId der AD-Datenbank im Gast-vDC zurückgesetzt. Das ist zwingend notwendig, damit in einer AD Umgebung mit mehreren DCs die Replikationspartner bei einer Wiederherstellung eines DCs erkennen, dass ein DC ordnungsgemäß (supportet!) wiederhergestellt wurde. Die AD-Replikation wird dann ab dem Zeitpunkt des Sicherungsdatums, mit dem wiederhergestellten vDC neu aufgebaut.

    Das elementare für die erfolgreiche Wiederherstellung eines DCs ist, dass die invocationId der AD-Datenbank zurückgesetzt werden muss! Denn nur so ist sichergestellt, dass der Neuaufbau der AD-Replikation in einer AD Umgebung mit mehreren DCs erfolgreich verläuft. Das ist auch der Grund, warum ein Snapshot, Klon oder Image eines DCs nicht supportet ist, da bei diesen Methoden die invocationId nicht zurückgesetzt wird!
    Zwei wichtige IDs eines DCs: DC GUID und InvocationId


    Virenscanner auf dem Host: Ist auf dem Hostsystem (Hyper-V, KVM…) ein Virenscanner installiert, sollten die Verzeichnisse in denen sich zum einen die Virtuellen Festplatten (VHD…) und zum anderen die Konfigurationsdateien befinden, vom Echtzeitscanner (On-Access) des Virenscanners ausgeschlossen werden. Unter Hyper-V sind das standardmäßig die beiden Verzeichnisse C\Users\Public\Documents\Hyper-V\Virtual Hard Disks und C:\ProgramData\Microsoft\Windows\Hyper-V. Wurden andere Verzeichnisse festgelegt, sollten diese vom Echtzeitscanner ausgeschlossen werden.

    Natürlich sollten auch in den VMs bestimmte Verzeichnisse vom Echtzeitscanner ausgeschlossen werden. Welche das sind, steht hier:
    Antivirenprogramm


    DCs offline konvertieren (P2V): Das online Konvertieren (Physical-to-Virtual, kurz P2V) eines DCs ist nicht supportet! Wenn man einen physikalischen DC konvertieren möchte, muss der DC ausgeschaltet (heruntergefahren, nicht angehalten oder ausgesetzt) und offline konvertiert werden! Denn ausschließlich die offline Konvertierung eines DCs (unter Hyper-V z.B. mit dem System Center Virtual Machine Manager, kurz VMM) ist der einzige Weg, welcher auch von Microsoft supportet wird. Nach der offline Konvertierung darf der physikalische DC nie mehr in der Domäne gestartet werden!
    Aber ein P2V ist bei einem DC ohnehin nicht empfehlenswert. Empfohlen ist es auf dem Host einen zusätzlichen DC zu installieren und den physikalischen DC herunterzustufen.


    Die VM-Sicherheit: Bei dem Thema „Sicherheit“ gelten für einen vDC mindestens die gleichen Sicherheitsregeln, wie für physikalische DCs. Weiterhin muss klar definiert sein, wer beispielsweise unter Hyper-V den Host administrieren darf. Denn wer Zugriff auf die virtuellen Festplatten (und somit auf die vDCs) hat, könnte diese kopieren und hätte prinzipiell Zugriff auf alle Kennwörter! Deshalb muss der Zugriff auf die virtuellen Festplatten von vDCs genauso eingeschränkt sein, wie der Zugriff auf physikalische DCs!


* Einen virtuellen DC niemals anhalten und niemals den Status speichern: Ein virtueller DC sollte niemals angehalten (pausiert) und es sollte niemals der Status gespeichert werden! Denn wenn ein vDC angehalten oder der Status gespeichert wird, friert man de facto die Uhrzeit und das Datum des vDCs ein. Genau das kann aber beim Wiedereinschalten des vDCs zum Problem werden, so dass die Replikationspartner die AD-Replikation mit diesem vDC einstellen und dadurch Lingering Objects (zu Deutsch, herumlungernde Objekte) entstehen. Ein vDC sollte stets heruntergefahren werden.
    Lingering Objects (veraltete Objekte)


* Virtuelle Festplatten mit fixer Größe konfigurieren: Es ist empfehlenswert, eine virtuelle Festplatte mit einer festen Größe zu konfigurieren. Konfiguriert man eine dynamische virtuelle Festplatte, muss man beim sizing des Hosts ohnehin die maximale Größe, die man bei einer dynamischen virtuellen Festplatte angegeben hat kalkulieren.


* Keine differenzierende virtuelle Festplatte konfigurieren: Man sollte es tunlichst vermeiden, eine differenzierende virtuelle Festplatte für einen vDC zu implementieren! Dadurch ist es zu einfach, den vDC in einen früheren Zustand zu versetzen.


* Nicht einen vDC unter Hyper-V exportieren: Das Exportieren eines vDCs unter Hyper-V sollte nicht durchgeführt werden.