Virtualisierung – Server Rollen und “Spielregeln”

Anlass für diesen Post ist erst einmal ein relativ neuer TechNet Artikel: “Running domain controllers in Hyper-V”.

Eigentlich nichts besonderes – sollte man meinen. Wie meistens lauern aber auch hier ein paar Fallen im klassischen Detail. Nicht jeder trifft diese auch in seiner Umgebung, aber es kann halt passieren…

Zwei “simple” Beispiele: Zeitsynchronisation und Zeitzonen oder “Save State” und Löschen von Objekten im AD mit Tombstoning.

Virtuelle Maschinen haben keine batteriegepufferte Echtzeit Uhr. Daher initialisiert der Host beim Start einer VM die Uhr auf seine lokale Zeit und hält sie da auch, wenn man das nicht abschaltet. Wichtig ist hierbei, dass die Synchronisation nicht auf Basis der UTC passiert, sondern der lokalen Zeit.

Save State, Backup und Restore sind weitere Themen, die behandelt werden müssen, da Active Directory als Multi-Master fähiges System hier bestimmte Regeln erfordert. Aber, bevor ich alles hier schreibe, kann man es ja auch jederzeit im Artikel online nachlesen…

Ein weiteres wichtiges Thema, was sich in vielen Fragen widerspiegelt, ist die Dimensionierung bzw. Skalierung der Systeme für virtuelle Arbeitslasten. Letztens kam z.B. die Frage: Wenn ich ein Acht-Wege System mit Windows 2000 virtualisiere, wird das schnell genug funktionieren? Pauschal lässt sich das leider nie beantworten.

Frage: Geht das überhaupt und wird es auch unterstützt (von uns).

Antwort: In einer eins-zu-eins Umsetzung auf jeden Fall nicht…

Aktuell kann man einer virtuellen Maschine maximal vier Rechenkerne/CPUs zuordnen, ein Blick in die “Supported Configurations” beantwortet hier die Zusammenhänge zwischen Anzahl CPUs und installierter Windows Version – nicht alles, was ginge, wird von uns auch unterstützt, weil es z.B. bekannte Probleme in einzelnen Fällen gibt, die zu Einschränkungen führen. Auf der anderen Seite ist der bestehende Server bestimmt schon etwas älter, man bekommt also heute vermutlich mit weniger CPUs mehr oder vergleichbare Leistung. Außerdem skalieren heutige Windows Server erheblich besser bei mehreren CPUs als früher. Quintessenz: Man muss selber testen, ob man innerhalb der existierenden Grenzen die geforderte Leistung in so einem Fall erhält.

Bei vielen Frage, sei es Skalierung oder auch der Verwaltung lautet einer meiner “Standardsprüche”: “Ein virtueller Server ist in erster Linie… Genau: Ein Server!” Soll heißen, auch, wenn die Virtualisierung manches vereinfacht und optimiert, mache ich keinen Fehler, wenn ich die Maßstäbe eines entsprechenden physischen Servers zu Grunde lege. Das gilt auch für die Skalierung, z.B. bezüglich Arbeitsspeicher, Netzwerk und “Fest”platten. Wer seinem physischen Server für eine bestimmte Arbeitslast mehrere Volumes mit jeweils mehreren Spindeln zukommen lassen würde, darf nicht versuchen, dem virtuellen Server mehrere VHDs zuzuordnen, die alle auf der gleichen (großen) Spindel liegen. OK, das ist ein Extrem, soll aber nur das Prinzip verdeutlichen.

Auch bezüglich der Zuweisung von CPU Ressourcen gelten ähnliche Regeln – im wesentlichen muss man die Anforderungen der Arbeitslast kennen oder messen. Management Produkte wie der System Center Operations Manager (oder System Center Essentials in kleineren Umgebungen) liefern hier wertvolle Daten über existierende Server und Services. Virtuelle Maschinen mit den jeweils konfigurierten CPUs sind aus Sicht des Host einfach nur Threads, die auf die physischen CPU Kerne je nach Lastanforderungen und Systemkonfiguration verteilt werden. CPU intensive Arbeitslasten erfordern daher ggf. eine Planung mit einer 1:1 Zuordnung (Planung, nicht Zuweisung!), während andere Lasten mit 4:1 oder sogar (maximal) 8:1 eingeplant werden können.

Auch der Netzwerkbereich sollte sorgfältig “vermessen” und geplant werden. Hyper-V erzeugt virtuelle Switches, an den die virtuellen Maschinen mit einem virtuellen 10GB Adapter angebunden sind. Die “10GB” sind aber nur Adapter “Bezeichnungen”, da “normale” Netzwerkadapter an einem physischen Medium immer eine feste Datenrate habe. In der virtuellen Welt hängt der effektive Durchsatz aber auch von der verfügbaren Rechenleistung des Host ab. Untereinander auf dem gleichen Host können virtuelle Maschinen also sehr schnell kommunizieren – was man ggf. auch bei der Planung von Clusterressourcen berücksichtigen sollte. Mit der Außenwelt wird dann aber über den physischen Adapter kommuniziert, der dann wieder von allen VMs am entsprechenden virtuellen Switch geteilt wird. Mehrere “dedizierte” Adapter im Host können hier einen großen Vorteil bedeuten, auch, wenn dadurch die “interne” Kommunikation über eine externe Schnittstelle erfolgt. Gegebenenfalls sind hier auch mehrere Adapter in der VM sinnvoll, wobei auch Multihoming wieder verstanden sein will…
Auch neue Technologien sind hier wichtig zu berücksichtigen. Die nächste Version des Hyper-V (Bestandteil des kommenden Windows Server 2008 R2) wird hier die Virtualisierung in den (neuen) Netzwerkkarten unterstützen, die (aktuell) bis zu vier Warteschlangen (Queues) auf den Adaptern verwaltet, die dann einen direkten DMA in die VM ermöglichen können, ohne dass die Daten erst durch den Host geschleust werden müssten.

Einige Stichworte, aber ich hoffe hiermit Anregungen gegeben zu haben, virtuelle Systeme erfolgreich zu planen und zu betreiben. Dokumentiert ist eigentlich (fast) alles, man muss es nur wissen und danach auch finden…