CPU-Überbuchung bedeutet, dass die virtuellen Kerne in Summe mehr sind als die Kerne des Hosts. Das funktioniert, solange nicht alle Maschinen gleichzeitig rechnen, und es ist bei Datei- und kleinen Anwendungsservern üblich. RAM-Überbuchung bedeutet, dass die Maschinen zusammen mehr Arbeitsspeicher glauben zu haben, als physisch steckt. Das funktioniert schlechter. Sobald der Hypervisor Speicher abzieht, ballont oder auf Platte auslagert, verlieren Datenbank und Terminaldienst genau den Cache, von dem sie leben, und alle Gäste werden gemeinsam langsam.

Wann Überbuchung von einem Rechentrick zur Störung wird

Ein hoher CPU-Wert in der VM muss nicht bedeuten, dass der Host zu wenig Kerne hat. Er kann bedeuten, dass die VM auf Rechenzeit wartet, während der Scheduler andere Gäste bedient. Diese Wartezeit sieht man am Host, nicht im Task-Manager des Gastes, der sich für beschäftigt hält. Umgekehrt ist eine niedrige CPU am Nachmittag kein Beweis, dass man die Kerne der Datenbank halbieren kann: der Monatsabschluss am Ersten rechnet anders als ein Dienstag im Leerlauf.

Dynamischer Arbeitsspeicher sieht sparsam aus und verbirgt Knappheit. Eine VM, der der Hypervisor Speicher entzieht, gibt Cache ab; die Datenbank liest stärker von der Platte; die Platte ist derselbe Datastore, den alle anderen nutzen. Der Engpass wandert, die Ursache bleibt. Für SQL-ähnliche Dienste, Terminalserver und Domaincontroller weisen wir den benötigten RAM fest zu und überbuchen ihn nicht, solange der Host das hergibt. Leichte Datei- und Sprungserver dürfen sich Kerne teilen.

Messen, Datenbanken fest zuweisen, Ballooning begrenzen

  1. Messen. CPU-Wartezeit am Host und belegter RAM in den Gästen werden über einen Zeitraum mit Stoßlast gelesen. Ein ruhiger Nachmittag reicht nicht als Beleg.
  2. Datenbank. Der Speicher der Datenbank wird fest zugewiesen, inklusive Puffer, und nicht über den physischen RAM hinaus versprochen. Dieselbe Vorsicht gilt für Terminalserver, die viele Sitzungen tragen.
  3. Leichte Gäste. Dateiserver und kleine Dienste dürfen sich Kerne teilen. Ihre vCPU-Zahl bleibt nahe an dem, was sie wirklich auslasten, statt an einer runden Hochzahl.
  4. Auslagerung. Speicherauslagerung des Hypervisors auf Platte gilt als Störung, nicht als Normalzustand. Ballooning wird beobachtet und bei Datenbanken vermieden.
  5. Änderung. Es wird eine Größe angepasst und erneut gemessen. Gleichzeitiges Ändern von vCPU, RAM und Speicherlayout macht die Wirkung unlesbar.

Es gibt keine Verhältniszahl, die für jeden KMU-Host gilt. Ein Labor mit zehn idle VMs verträgt mehr virtuelle Kerne pro physischem Kern als ein Host, auf dem Warenwirtschaft und Terminaldienst gleichzeitig arbeiten. Wir starten konservativ, messen Wartezeit und Speicherdruck über einen Zeitraum mit echter Last und ändern dann eine Größe, nicht fünf gleichzeitig. Sonst ist am Ende unklar, welche Änderung geholfen hat.

Woran Projekte in der Praxis scheitern

  • Jeder VM so viele vCPUs geben, wie der Host Kerne hat, und damit den Scheduler beschäftigen.
  • Dynamischen RAM auf der Datenbank aktivieren und den Host auslagern lassen.
  • Nur den Task-Manager im Gast lesen und die Wartezeit am Host ignorieren.
  • Testmaschinen permanent mitlaufen lassen und ihren Speicher im Produktivhost mitzählen, ohne ihn zu bemerken.

Beispiel aus dem Betriebsalltag

Ein Steuerbüro hatte auf einem Host mit 64 GB RAM vier Terminalserver mit je 32 GB dynamischem Speicher und eine Datenbank ohne Limit. Am Vormittag der Lohnverrechnung lagerte der Host, alle Sitzungen ruckelten, und jede Fachkraft hielt die eigene Anwendung für schuld. Wir haben den Terminalservern feste, kleinere Kontingente gegeben, die Datenbank auf einen festen Anteil gesetzt, zwei selten genutzte Test-VMs abgeschaltet und die Wartezeit der CPU über den nächsten Abrechnungszeitraum gelesen. Der Host lagerte nicht mehr aus. Eine zusätzliche RAM-Bestellung wurde erst danach entschieden, anhand der Messung, nicht anhand des Gefühls am Vormittag.

Kurze Entscheidungshilfe

  • Lagert der Host unter Stoßlast Speicher auf Platte aus?
  • Hat die Datenbank ein festes RAM-Kontingent innerhalb des physischen Speichers?
  • Wird die CPU-Wartezeit am Hypervisor angesehen und nicht nur die Auslastung im Gast?
  • Ist eine Test-VM benannt, die vor dem nächsten Abschluss aus sein muss?

Wenn CPU- und RAM-Überbuchung bei Ihnen ansteht, klären wir den Umfang unverbindlich: Virtualisierung. ESXi-Host dimensionieren Alternativ direkt Kontakt aufnehmen oder die häufigen Fragen lesen.