Wie viele Kerne braucht meine virtuelle Maschine? Und wie viel RAM? Diese Fragen sind gar nicht so leicht zu beantworten. In erster Näherung machen zusätzliche virtuelle CPU-Kerne (vCPU) eine VM schneller, ebenso mehr RAM. Man kann es aber auch schnell übertreiben, und dann leidet das komplette System. Um die richtige Balance zu finden, ist etwas Hintergrundwissen hilfreich.
Eine virtuelle CPU ist aus Sicht des Host-Systems zunächst ein gewöhnlicher Prozess. Als physische CPUs nur eine einzelne Ausführungseinheit enthielten, wies der Scheduler im Linux-Kern einzelnen Prozessen reihum CPU-Zeit zu; das Scheduling-Verfahren, die aktuelle und andere Parameter legten fest, welcher Prozess wann wie lange an die Reihe kommt. In Multi-Core-Systemen muss der Kernel zudem auswählen, welcher Prozess auf welchem CPU-Kern laufen soll. Dabei gibt es erstmals echte Parallelität. Bei Multi-Prozessor-Systemen müssen Prozesse zusätzlich noch zwischen CPUs verteilt werden
Den Overhead in Kauf nehmen
Dummerweise kommen auch neue Overheads dazu. Das liegt zum Beispiel an der NUMA-Architektur von Multi-Prozessor-Maschinen: Non-Uniform Memory Access. Bei dieser auf Servern üblichen Speicherarchitektur hat jede physische CPU (Sockel) ihren eigenen RAM-Bereich, auf den sie deutlich schneller zugreifen kann als auf den RAM-Bereich einer anderen CPU. Das hat zur Folge, dass ein Prozess je nach seinem RAM-Speicherort auf den Kernen einer CPU schneller arbeitet als auf einer anderen CPU. Außerdem werden beim Wechsel der CPU auch die internen Caches ungültig.
Jetzt einfach jeden Prozess fix immer auf der gleichen CPU laufen zu lassen, verspricht die beste Performance, geht aber auf Kosten der Flexibilität. Schließlich ist deren Rechenbedarf dynamisch, sprich: Wenn zufällig zwei Prozesse auf derselben CPU laufen und maximale Performance benötigen, ist es durchaus sinnvoller, sie zu verteilen, trotz allem Overhead. Die feste Zuordnung (Pinning genannt) lohnt sich nur in speziellen Anwendungen.
Was heißt das nun für die Auslegung einer virtuellen Maschine? Jede virtuelle CPU ist aus Sicht des Host-Systems ein Prozess beziehungsweise, genauer gesagt, ein Thread. Es ist einer der riesigen Vorzüge der Virtualisierung, dass man auf einer Host-CPU mit vielleicht 16 Kernen problemlos 32 virtuelle Maschinen mit je acht Kernen laufen lassen kann. Die physischen Kerne sind dann 16-fach belegt. Das geht, allerdings hat jede virtuelle CPU dann unter Umständen deutlich weniger Performance, als die physischen CPUs hoffen lassen – vor allem, wenn viele virtuelle Kerne gleichzeitig Last erzeugen.
Die Balance finden
Es gibt grobe Richtwerte, dass man die physischen CPUs maximal vier- bis achtfach belegen sollte. Klingt nach einfachen Grundrechenarten, aber in der Praxis hängt es auch massiv davon ab, wie viel Rechenleistung die einzelnen Maschinen wirklich benötigen, und ob sie diese Leistung gleichzeitig oder vielleicht zeitversetzt anfordern. Klar ist aber, dass ein verschwenderischer Umgang mit vCPUs, die das Gastsystem real gar nicht benötigt, kontraproduktiv wäre.
Beim Speicher ist die Rechenaufgabe übrigens viel einfacher: RAM kann man kaum sinnvoll überprovisionieren. Im Gegenteil ist es sinnvoll, auf dem Host ordentlich Speicher vorzuhalten. Bei einem Cluster-Set-up wie dem CoreBiz VSB sollte mindestens die Hälfte frei bleiben, damit beim Ausfall eines der beiden Server alle virtuellen Maschinen auf dem zweiten Server starten können – und noch etwas Platz für den Buffer-Cache bleibt, der Lesezugriffe beschleunigt.
Wer kann und die Muße hat, sollte neue virtuelle Maschinen also zunächst mit einer kleineren Anzahl von CPUs aufsetzen. Wenn diese dann alle zum großen Teil ausgelastet sind, lohnt es sich, mehr CPUs zuzuweisen und die Auslastung weiter zu beobachten. Ob das dann zum Erfolg führt, hängt davon ab, wie sehr die Anwendungen im Gastsystem parallelisierbar sind. Im Extremfall lastet eine Applikation eine vCPU voll aus, profitiert vielleicht von einer zweiten vCPU (die alle anderen Prozesse des Gastsystems abarbeitet), aber jede weitere vCPU wäre reine Verschwendung.
Von Microsoft empfohlen
Bei einem Microsoft-AD empfiehlt der Hersteller beispielsweise eine vCPU pro 1000 gleichzeitiger Benutzer. Auch Fileserver und viele Applikationsserver sind mit ein oder zwei CPUs ausreichend bedient. Spannend wird es zum Beispiel beim Terminalserver, da sich hier die Lastprofile je nach Anwendung enorm unterscheiden. Microsoft nutzt eine grobe Einteilung in „Light“, „Medium“, „Heavy“ und „Power“, außerdem Single- und Multi-Session-Systeme. Daraus leiten sich Empfehlungen für die Anzahl an vCPUs ab, aber auch für den RAM- und Filesystem-Bedarf.
- VMs sollten immer mehr als zwei Kerne haben. Die UI-Komponenten in Windows verwenden für einige Rendering-Vorgänge mindestens zwei parallele Threads. Vier Kerne sind die niedrigste empfohlene Anzahl von Kernen, die eine stabile Multisession-VM haben sollte.
- VMs sollten nicht mehr als 32 Kerne haben. Mit zunehmender Anzahl von Kernen steigt auch der Synchronisierungsaufwand des Systems. Bei den meisten Workloads bringt ab etwa 16 Kernen jeder zusätzliche Kern immer weniger Nutzen. Hier sind zwei VMs mit je 16 Kernen besser als eine VM mit 32 Kernen.
Im Blick behalten
Wer die oben getroffene Empfehlung beherzigt und seine virtuellen Maschinen zunächst eher zurückhaltend mit vCPUs und RAM ausstattet, sollte diese im Betrieb tunlichst per Monitoring-System überwachen. Das zeigt am besten, welche VM am Anschlag ist bei CPU-Last und RAM-Belegung – wo es sich also lohnt, doch etwas mehr Ressourcen zu vergeben.