Ein häufig wiederkehrendes Thema bei der Implementierung von Lösungen für die Virtualisierung ist das grundlegende Verständnis – oder eben Missverständnis – der Zuordnungen virtueller CPU-Ressourcen auf physische Kerne des Hypervisors. Die Meinungen der Administratoren und Berater gehen bei diesem Themenkomplex weit auseinander. Besonders bei Beschaffung und Auslastung starten wirre Diskussionen. Werden vier Sockel benötigt? Lieber Quad- oder Hexcore? Wie viele vCPUs eigentlich für alle VMs? Dieser Artikel soll etwas Klarheit anhand von Hyper-V schaffen.
Vom CPU-Sockel, zum Prozessorkern, bis zur VM
Für das Gesamtverständnis wird ein wenig Theorie benötigt. Eine virtuelle CPU (innerhalb einer VM) ist dabei gar nicht allzu virtualisiert. Zwar gibt es eine virtuelle Schicht zwischen dem virtuellen und dem physischen Prozessor, jedoch gilt generell der Grundsatz nicht mehr virtuelle Kerne zu verteilen als physisch verbaut sind. So kann in einem 4 Sockel-Server mit 16-Kern-CPUs eine Gesamtzahl von 64 Kernen den virtuellen Maschinen zugeordnet werden. Für den klassischen Administrator mit Versicherungsgedanke wäre die Reise an dieser Stelle dann auch schon zu Ende.
Für die Synergie-Denker gibt es jedoch einen riesigen Vorteil in der Virtualisierung: Oversubscription oder Überbuchung. Dabei ist es natürlich durch die Virtualisierungsschicht möglich, dass physische Ressourcen einer VM, sofern diese nicht gerade beansprucht werden, einer anderen VM zugeordnet werden können. Das passiert automatisch, ist in Hyper-V aber auch durch einige Einstellungen gezielt konfigurierbar.
Interessant ist daneben die Überlegung was geschieht, wenn mehr CPU-Performance (oder Auslastung) benötigt wird als physisch vorhanden ist. In diesem Falle kommt es zu langen Warteschlangen (Congestion) bei der Verarbeitung, auch innerhalb des Hostsystems. Überbuchungen sind also möglich, sinnvoll, wirtschaftlich und im Kern der wahre Vorteil der Virtualisierung. Jedoch wird dann eine ordentliche und fachlich fundierte Überwachung der Ressourcen vorausgesetzt.
Die Kombi-Admins, einer Mischung aus Versicherungsjunkie und Neumode-Synergie-Denker, finden sich in der Regel in einer Hybridumgebung wieder. Häufigstes Mittel bieten hier klassische Failovercluster für Hyper-V. So können dann zwei physische Hosts unter Berücksichtigung des Versicherungsgedanken an ihre maximal physischen Ressourcen gebunden werden, bilden aber im Fehlerfall (und auch nur im Fehlerfall) die doppelte Menge an VMs (und Kernen) ab. Wäre auf jedem Clustermitglied bereits mit Überbuchungen gearbeitet worden, müssten diese Fehlerfall-Überlegungen auch für das Ausfallszenario betrachtet werden. Häufig kommen daher 3- oder 5-Knoten Cluster zum Einsatz.
Wie viele vCPUs (Kerne) sollen es pro VM sein?
“Das hängt von der betriebenen Applikation ab”, ist hier die häufigste aller Antworten. Sie ist jedoch auch vollkommen korrekt. Der Grundsatz “viel hilft viel” bringt den ambitionierten VM-Admin jedenfalls nicht zum Ziel. Insbesondere dann nicht, wenn Windows als Host- und Gastsystem eingesetzt wird. Denn wenn eine Software in ihrem Programmcode nicht in der Lage ist Rechenoperationen auch an unterschiedliche Prozessoren oder Threads zu delegieren, sind physische Ressourcen grundlos verschwendet worden. Für die häufigsten Überlegungen sollten daher Dual-Core VMs (1x Windows, 1x Apps) ausreichen. Datenbanken bilden neben optimierter Branchensoftware jedoch eine große Ausnahme, ebenso wie Terminal-Emulationen alá Citrix. Das genaue Studium der Dokumentationen kann daher schnell einen ersten Einblick ermöglichen. Von den “gewürfelten” Systemanforderungen manch einer Software ist hier aber nicht die Rede.
Think about the hypervisor itself
Ein häufiger Stolperstein ist auch die Planung der Ressourcen für den Hyper-V Host. So werden beispielsweise bei einem Server mit 32 Kernen auch 32 virtuelle Kerne verteilt, ohne dabei den Ressourcenbedarf der Management-Maschine bedacht zu haben. Ein wichtiger Grundstein für die Planung ist das Verständnis der Hyper-V Partitions. So bildet das Management-OS (Parent Partition) ebenso wie jede VM (Child Partitions) eine isolierte Einheit. Man könnte sagen, dass Hyper-V im ersten Schritt sein Management-OS selbst virtualisiert. Mit diesem Verständnis ist auch klar, dass zu Managementzwecken auch für das Systembetriebssystem eine Reserve von vielleicht 8 Kernen berücksichtigt werden sollte. Die gleiche Denkweise kann auch auf andere Ressourcen wie z.B. den Arbeitsspeicher übertragen werden.
Monitoring der CPU-Auslastung
Einher mit der Partitionsfrage geht auch die Erklärung einer sinnigen Überwachung der physischen CPU-Ressourcen. Wenig überraschend sollte an dieser Stelle klar sein, dass der Task-Manager des Host-Betriebssystems dabei die schlechteste Alternative darstellt. Auf Grund der Partitionierung ist hier lediglich die Auslastung der Parent-Partition sichtbar.
Eine wirkliche Alternative bietet in Enterprise-Umgebungen der System Center Virtual Machine Manager (SCVMM). Dieser bietet u.a. eine Zuordnungstabelle und Ansichten zur Filterung der Auslastung einzelner VMs. Sparfüchse und Mittelständler bedienen sich jedoch häufig des Hyper-V Managers und sind daher auf andere Werkzeuge angewiesen. Die CPU-Mittelwertanzeige werte ich an dieser Stelle absichtlich nicht als Überwachungswerkzeug. Einen ersten Anfang könnte beispielsweise Perfmon (siehe Befehlszeilenreferenz) bieten. Für eine ordentliche Analyse und Alarmierung sollten aber Enterprise-Werkzeuge in Betracht gezogen werden.
Über den Autor