Domänencontroller virtualisieren

Man könnte meinen, dass die Idee, Active-Directory-Domänencontroller zu virtualisieren, kein Thema wäre, das einer Diskussion bedarf, und dennoch stelle ich fest, dass regelmäßig die Frage aufkommt, ob AD-DCs virtualisiert werden sollten oder nicht. Theoretisch besteht keine Notwendigkeit, diese Frage zu stellen, denn wir verfügen in der Branche über weitaus allgemeinere Leitlinien, die uns sagen, dass alle möglichen Workloads virtualisiert werden sollten, und AD stellt gewiss keinen Sonderfall dar, mit dem sich eine Ausnahme von dieser seit Langem bestehenden und allgemeinen Regel begründen ließe.

Seltsamerweise scheinen die Leute jedoch regelmäßig gezielt nach Klarstellung zu genau diesem einen Workload zu suchen, und wenn man schlechten Rat sucht, wird ihn einem sicher jemand geben. Unzählige Leute veröffentlichen Ratschläge, in denen sie physische Server für Active Directory empfehlen, aber selten, wenn überhaupt, mit irgendeiner Erklärung, warum sie überhaupt empfehlen würden, gegen Best Practices zu verstoßen, geschweige denn bei einem so alltäglichen und wohlbekannten Workload.

Warum diejenigen, die AD-DCs implementieren, zu dem Schluss kommen, dass dies eine spezifische Untersuchung rund um die Virtualisierung rechtfertigt, während kein anderer Workload dies tut, kann ich nicht beantworten. Doch nach vielen Jahren der Auseinandersetzung mit diesem Phänomen habe ich einen gewissen Einblick in den Ursprung des leichtfertigen Rats rund um physische Bereitstellungen gewonnen.

Der erste Fehler entspringt einem allgemeinen Missverständnis darüber, was Virtualisierung überhaupt ist. Das ist bedauerlicherweise unglaublich weit verbreitet, und die Leute glauben recht häufig, dass Virtualisierung Konsolidierung bedeute, was natürlich nicht der Fall ist. Sie übernehmen also diesen Fehler und wenden dann die falsche Logik an, dass Konsolidierung bedeute, zwei AD-DCs auf demselben physischen Host zusammenzuführen. Es erfordert außerdem den Gedankensprung anzunehmen, dass es stets zwei oder mehr AD-DCs geben werde, doch auch das ist eine verbreitete Überzeugung. So kommen drei große Denkfehler zusammen und ergeben einige sehr schlechte Ratschläge, die sich, wenn man den Empfehlungen auf den Grund geht, normalerweise zurückverfolgen lassen. Dies scheint die Wurzel des Großteils des schlechten Rats zu sein.

Andere Ursachen liegen mitunter im Missverständnis tatsächlicher Best Practices, etwa der Aussage “Wenn Sie zwei AD-DCs haben, muss sich jeder auf einem separaten physischen Host befinden.” Diese Aussage sagt uns, dass in diesem Szenario zwei physisch voneinander getrennte Maschinen verwendet werden müssen, was absolut korrekt ist. Sie impliziert jedoch nicht, dass einer von ihnen keinen Hypervisor haben sollte, sondern nur, dass zwei verschiedene Hosts erforderlich sind. Die Formulierung, die für derartige Ratschläge verwendet wird, ist oft schwer zu verstehen, wenn man nicht über das vorhandene Verständnis verfügt, dass unter keinen Umständen ein nicht-virtueller Workload akzeptabel ist. Wenn man die Empfehlung mit diesem Verständnis liest, ist ihre Bedeutung klar und, hoffentlich, offensichtlich. Bedauerlicherweise wird diese Empfehlung oft aus dem Zusammenhang gerissen wiederholt, sodass die zugrunde liegende Bedeutung leicht verloren gehen kann.

Vor langer Zeit, etwa vor einem Jahrzehnt, hatten einige Virtualisierungsplattformen gewisse Probleme rund um Timing und Systemuhren, die mit geclusterten Datenbanksystemen wie Active Directory Chaos anrichten konnten. Dies war vor langer Zeit ein legitimes Problem, wurde aber längst gelöst, wie es für viele verschiedene Workloads gelöst werden musste. Dennoch entstand der Eindruck, dass AD möglicherweise eine Sonderbehandlung benötige, und dieser scheint fortzubestehen, obwohl seit diesem Problem in IT-Maßstäben eine oder zwei Generationen vergangen sind und es längst hätte vergessen sein sollen.

Ein weiterer Mythos, der zu schlechtem Rat führt, wurzelt in der Tatsache, dass AD-DCs, wie andere geclusterte Datenbanken, bei Verwendung im Clustermodus nicht per Snapshot gesichert werden sollten, da dies leicht zu Datenbankkorruption führt, wenn nur ein Knoten des Clusters auf diese Weise wiederhergestellt wird. Dies ist jedoch ein allgemeiner Aspekt von Speicher und Datenbanken und steht überhaupt nicht im Zusammenhang mit Virtualisierung. Dieselbe Information ist für physische AD-DCs in gleicher Weise notwendig. Dass Snapshots mit Virtualisierung assoziiert werden, ist ein weiterer Mythos; Virtualisierung impliziert kein derartiges Speicherartefakt.

Noch weitere Mythen entspringen der Annahme, dass Virtualisierung selbst auf Active Directory angewiesen sei, um zu funktionieren, und dass AD daher ohne Virtualisierung laufen müsse. Dies ist vollkommen ein Mythos und unsinnig. Es gibt keine derartige zirkuläre Abhängigkeit.

Bedauerlicherweise haben manche technischen Bereiche groß angelegte Mythen hervorgebracht, oft viele davon, die sie umgeben und es schwierig machen können, die Wahrheit herauszufinden. Virtualisierung ist gerade komplex genug, dass viele Leute zwar versuchen zu lernen, wie man sie benutzt, nicht aber, was sie konzeptionell ist, und zwar nur durch stures Auswendiglernen, was mitunter zu verrückten Missverständnissen führt, die so weit hergeholt sind, dass es schwer sein kann zu erkennen, dass es sich tatsächlich darum handelt. Und in einem Fall wie diesem summieren sich Missverständnisse rund um Virtualisierung, Geschichte, geclusterte Datenbanken, Hochverfügbarkeitstechniken, Speicher und mehr zu Schicht über Schicht von Missverständnissen, was es schwer macht herauszufinden, wie so viele Dinge rund um eine einzige Bereitstellungsfrage zusammenkommen können.

Letztlich sind nur wenige Workloads so ideal für die Virtualisierung geeignet wie Active-Directory-Domänencontroller. Es gibt keinen Fall, in dem die Idee, eine physische Bare-Metal-Betriebssystembereitstellung für einen DC zu verwenden, in Betracht gezogen werden sollte – virtualisieren Sie jedes Mal.