Darf man einen Domänencontroller virtualisieren?

Auf diese Frage gibt es gleich zwei Antworten: eine kurze und eine längere. Die kurze ist: Ja, man darf, wenn man es richtig macht.

Die längere beschäftigt sich damit, wie man es richtig macht. Oder genauer: Was man besser nicht macht.

Grundsätzlich eignen sich Domänencontroller hervorragend für die Virtualisierung. Das AD ist in seinem Ressourcenverbrauch sehr genügsam: In den meisten Netzwerken reicht eine VM mit einer einzelnen CPU und einem oder zwei Gigabytes an Arbeitsspeicher völlig aus. Nur in großen Domänen können vier oder (selten) acht GB sinnvoll sein – mehrere CPUs oder eine besondere Plattenkonfiguration braucht man aber ebenso wenig wie besonders große virtuelle Festplatten.

Der Verzicht auf “echte” Hardware für den DC ergibt aber auch direkte Vorteile: Beim Recovery etwa ist es durchaus hilfreich, dass eine VM auf standardisierter virtueller “Hardware” ohne besondere Treiberanforderungen läuft. Das Backup einer VM lässt sich so ohne große Klimmzüge in einer neuen VM wiederherstellen.

Auch die Funktionen moderner Virtualisierer lassen sich für DCs gut nutzen: Durch Clustering etwa startet ein VM-DC nach einem Ausfall auf einem anderen Host von selbst wieder. Und per Live Migration (bei VMware “vMotion” genannt) kann man einige geplante Ausfallzeiten gleich ganz vermeiden.

Zurück in die Zukunft: USN Rollback

Virtualisierung verführt viele Admins zu Dingen, die nicht immer gut sind. Auf den Spitzenplätzen finden sich die P2V-Migration von Systemen, das Cloning und das Erzeugen von Snapshots für produktive Systeme. Domänencontroller sollte man nicht direkt aus einer physischen in eine virtuelle Installation umwandeln (Physical-to-virtual, P2V), denn hier lauern zahlreiche Fallen. Die meisten P2V-Werkzeuge erlauben es, den Vorgang “live” auszuführen, also während der physische Server noch läuft. Dazu erzeugen sie zu Beginn der Aktion einen Snapshot des Systems und kopieren diesen in eine virtuelle Maschine. Während dieser Zeit läuft der Originalserver weiter, und ganz am Ende schaltet das Werkzeug um vom physichen auf den neuen, scheinbar “identischen” virtuellen Server. Nur hat dieser eben den Zustand vom Beginn der Migration, er befindet sich also auf einem überholten Stand. Hierdurch droht ein gravierendes Problem, das als “USN Rollback” bekannt ist: Die Transaktionsnummern des AD passen nicht mehr zu den Replikationsinformationen der anderen Domänencontroller, und damit ist der virtuelle DC wertlos.

Wenn es sich gar nicht vermeiden lässt, einen DC per P2V-Methode zu virtualisieren, so darf das aus obigem Grund nur offline geschehen: Physischen DC herunterfahren, Offline-P2V ausführen, dann den physischen DC nie wieder anschalten. Wesentlich besser ist es allerdings, eine neue VM zu installieren und diese ganz normal per DCPromo zu einem neuen DC hochzustufen. Den alten physischen DC kann man dann ebenso geordnet herunterstufen und ggf. deinstallieren. Da Domänencontroller keine weiteren Funktionen haben sollten, ist dieses Verfahren in einem sauber aufgebauten Netzwerk sicher und schnell.

Auch die zweite “verführende” Technik birgt das hohe Risiko eines USN-Rollback: Der Snapshot einer VM. Alle Virtualisierer bieten eine Snapshot-Technik, die den Zustand einer VM zu einem bestimmten Zeitpunkt einfriert. Im Marketing gilt das dann als supereinfache Recovery-Möglichkeit. Das technische Kleingedruckte rät aber bei allen Herstellern davon ab, dies auf Produktionssystemen zu nutzen, denn neben einigen technischen Implikationen erzeugt es bei komplexeren Applikationen (und dazu gehört Active Directory zweifellos!) schnell heftige Probleme. Im Fall eines DCs ist es wiederum das USN Rollback, das durch das Zurückspringen auf einen Snapshot-Stand erzeugt wird.

Maschinen zu klonen ist in einer VM-Umgebung unglaublich einfach. Noch simpler, als die virtuelle Festplatte zu kopieren, geht es bei den meisten Produkten über eingebaute Kopierfunktionen, die aus einer bestehenden VM gleich eine zweite identische machen. Finger weg von solchen Funktionen in Produktionsumgebungen! Einen DC zu klonen, führt in einer Domäne zu erheblichen Problemen. Auch von der Idee, eine Kopie eines DC für Testzwecke zu erzeugen, sollte man lieber Abstand nehmen – mehr dazu weiter unten.

VM-Spiegelung – hier nicht

Einige Virtualisierungssysteme bieten die Möglichkeit, einen VM-Server live auf einen anderen Host zu spiegeln. Dadurch gibt es dann zwei identische Instanzen desselben Servers, die stets auf demselben Stand sind. Sollte die “Hauptkopie” ausfallen, so schaltet das System einfach um auf den “Spiegel” – idealerweise ohne Unterbrechung für die Anwender.

Doch nicht umsonst positionieren die Hersteller solche Techniken eher als Notlösung für Applikationen, die keine anderen Mechanismen für hohe Verfügbarkeit anbieten. Im Fokus stehen “kleine”, einfache Anwendungen, die eigentlich nicht für den produktionskritischen Einsatz gedacht (oder geeignet) sind, in einem Unternehmen aber trotzdem so genutzt werden. Auf Active Directory trifft diese Beschreibung aber nicht zu: Das AD bietet mit seinem Replikationssystem hervorragende Möglichkeiten, für Ausfallsicherheit zu sorgen. Das Spiegel-Verfahren ist also nicht nur unnötig, sondern es birgt die Gefahr, den DC oder gar das ganze AD zu beschädigen, wenn die Spiegelfunktion mal nicht richtig läuft.

Einmal Physik, bitte!

Eine gängige (und eigentlich immer zutreffende) Empfehlung besagt, dass es in jeder Domäne mindestens einen physischen, also nicht virtualisierten Domänencontroller geben sollte. Der Grund: In den meisten Umgebungen besteht eine Abhängigkeit der Virtualisierungsumgebung von Active Directory. Gibt es nun einmal ein Problem mit den VM-Hosts und keine separaten DCs, so ist guter Rat teuer: Die Hosts können die VMs nicht starten, weil AD nicht läuft, und AD läuft nicht, weil die VMs nicht starten …

Ganz offenkundig lässt sich diese Situation vermeiden, wenn es wenigstens einen DC außerhalb der VM-Umgebung gibt. Zusätzlich sollte dieser Server auch die Betriebsmasterrollen (FSMO Role Masters) innehaben – vor allem deshalb, weil der Betriebsmaster “PDC Emulator” der Zeitserver für die Domäne ist. Die Zeitquelle arbeitet aber am besten, wenn sie nicht virtualisiert ist. Näheres siehe unter:

[faq-o-matic.net » Virtuelle DCs: Zeitprobleme vermeiden]
http://www.faq-o-matic.net/2010/04/21/virtuelle-dcs-zeitprobleme-vermeiden/

Die Testkopie: Sicherheitsrisiko selbst gemacht

Allzu oft kommen Administratoren auf die Idee, einen produktiven Domänencontroller zu klonen und diesen Klon dann für eine Testumgebung zu nutzen. Was auf den ersten Blick pfiffig aussieht – schließlich ist der Klon ja identisch zum Original, und damit kann man doch hervorragend und realitätsnah testen – ist in Wirklichkeit ein Risiko ersten Ranges. Denn durch diesen Vorgang erzeugt man “mal eben” auch Kopien aller sicherheitsrelevanten Objekte des AD: Alle User mit ihren Security-IDs und ihren Kennwörtern liegen nun in der Testumgebung. Nun unterliegen solche Testserver allerdings in der Regel nicht denselben Sicherheitsmechanismen wie das echte Netzwerk. Meist laufen Test-VMs auf leicht zugänglichen Labor-Servern oder gar unter dem Schreibtisch des Admins. Der Manipulation öffnet man so ebensoweit die Tür wie dem Versehen: Da die Testumgebung ja exakt so aussieht wie die echte, passiert es leicht (und alles andere als selten!), dass ein Admin glaubt, in der Testwelt irgendwas zu ändern – um dann hinterher festzustellen, dass er leider doch in der “echten Welt” gearbeitet hat …

Netzwerke verbinden

Ein typischer Designfehler in VM-Netzwerken besteht darin, dass alle möglichen Server auf demselben Hostserver oder Host-Cluster laufen. Da tummeln sich dann kritische LAN-Systeme (AD, Exchange, Datenbanken) munter neben virtuellen Servern, die in der DMZ ihren Dienst versehen (Webserver, Mailgateway, Firewall). Als Rechtfertigung dient dann die Ansicht, dass ein VM-Host die virtuellen Maschinen ja in “Sandboxes” ausführe und dadurch kein Übergriff von einer auf die andere VM möglich sei.

Nun ist diese Ansicht allerdings bereits mehrfach nicht nur theoretisch, sondern auch praktisch widerlegt worden. Es hat immer wieder Angriffe gegeben, durch die es eben doch möglich war, von einer VM auf eine andere oder gleich direkt auf den Hostserver zu gelangen. Aus diesem Grund muss die physische Unterteilung von Netzwerken auch weiterhin als zwingend gelten – und das bedeutet eben, dass VMs aus unterschiedlichen Netzwerkzonen niemals auf demselben Host laufen dürfen.

Kein AD “auf dem Host”

In der Virtualisierung gilt: Ein Host ist ein Host ist ein Host. Zwar lässt Windows es durchaus zu, auf einem Hyper-V-Hostserver auch weitere Applikationen zu installieren, aber davon sollte man auf jeden Fall die Finger lassen. Hintergründe dazu liefert dieser Artikel:

[faq-o-matic.net » Warum der Hyper-V-Host keine (!) weiteren Dienste ausführen sollte]
http://www.faq-o-matic.net/2010/05/03/warum-der-hyper-v-host-keine-weiteren-dienste-ausfhren-sollte/

Außerdem …

Noch ein paar Dinge sollte man beachten:

• Eine VM, die als DC arbeitet, niemals in den “Pause”-Modus versetzen. Das führt schnell zu diversen Problemen, u.a. mit der Replikation des AD.
• Ebenso darf eine DC-VM nicht als Quelle oder Ableitung von “Linked Clones”, “Differencing Disks” oder ähnlichen Mechanismen arbeiten.
• Der Admin des Hostservers hat sehr weitgehende Kontrolle über die VMs, die auf diesem Host laufen. Er muss also absolut vertrauenswürdig sein. Eine Rollentrennung dieses Administrators von anderen administrativen Rollen ist derzeit praktisch nicht machbar.
• Domänencontroller sollten nicht “Multi-homed” sein, also nicht über mehrere Netzwerkkarten verfügen. Sonst gibt es schnell Probleme mit der Netzwerkkommunikation und der Namensauflösung.
• Auch in einer virtuellen Umgebung darf das Backup des Active Directory nur über den System State erfolgen. Snapshots, VM-Exports, Kopien der virtuellen Festplatten usw. sind tabu! (Siehe auch oben.)