CPU, Speicher und Platzierung

Konfiguriert ist nicht verbraucht und verbraucht ist nicht bedient

Eine VM mit acht vCPUs und 32 GiB virtuellem RAM besitzt zunächst eine Konfiguration. Daraus folgt weder, dass der Workload acht CPUs parallel nutzt, noch dass 32 GiB jederzeit physisch exklusiv bereitstehen, noch dass eine bestimmte Antwortzeit erreicht wird. Virtualisierung trennt drei Größen: Zuweisung, Nachfrage und Bedienung. Diagnose beginnt damit, sie nicht zu vermischen. ``text Workload erzeugt Nachfrage ↓ Gastkernel plant Prozesse und Speicher ↓ Hypervisor plant vCPUs und Gastseiten ↓ Host liefert physische CPU-Zeit, RAM und Lokalität `` Eine hohe Gast-CPU-Auslastung zeigt Nachfrage innerhalb der VM. Sie erklärt nicht allein, ob die vCPUs zeitnah auf physischen CPUs laufen. Eine niedrige Gastauslastung schließt Wartezeit auf Hostplanung, I/O oder Speicher nicht aus. Beim RAM kann eine große Zuweisung neben einer kleinen aktiven Arbeitsmenge existieren; umgekehrt kann gleichzeitiger Host- und Gastdruck trotz scheinbar ausreichender Maximalwerte hohe Latenz erzeugen. Formuliere jede Änderung als Hypothese: „Wenn fehlende CPU-Parallelität die SLO-Verletzung verursacht, dann verbessert eine begrenzte vCPU-Erhöhung unter gleicher Last diese Messwerte.“ Ohne erwartetes Signal und Rückweg ist Upsizing nur eine dauerhafte Kapazitätsentnahme.

Mit SLO und Lastfenster beginnen

Right-Sizing beginnt nicht bei einem Durchschnittswert, sondern beim Dienstziel. Definiere messbar, welches Symptom verbessert werden soll: p95-Antwortzeit, Jobdauer, Durchsatz, Fehlerrate oder Einhaltung eines Batchfensters. Notiere zugleich den repräsentativen Lastkontext. Ein CPU-Wert aus ruhiger Nacht und eine Latenzspitze aus dem Monatsabschluss gehören nicht in dieselbe Kausalaussage. Wähle ein Zeitfenster, das Anstieg, Spitze und Erholung enthält. Synchronisiere Uhren und markiere Deployments, Backups, Migrationen sowie Hostwartung. Vergleiche einen betroffenen Workload möglichst mit seiner eigenen gesunden Baseline und mit einer ähnlichen, gesunden Instanz auf anderer Platzierung. Ein einzelner Momentwert ist anfällig für kurze Scheduler- oder Garbage-Collection-Ereignisse. Erfasse mindestens vier Ebenen: Anwendungssignal, Prozess- und Gastressource, VM-Signal des Hypervisors sowie gemeinsame Hostnachfrage. Unter Linux liefert vmstat einen kompakten zeitlichen Überblick über Run Queue, CPU, freien Speicher, Paging und I/O: ``bash vmstat 1 60 `` Das Kommando allein diagnostiziert keine Virtualisierungsursache. Es liefert Gast- oder Hostevidenz, je nachdem wo es läuft. Beschrifte daher jedes Artefakt mit System, Ebene und Zeitraum. Erst die zeitliche Korrelation beantwortet, ob ein Anwendungseinbruch mit CPU-Wartezeit, Speicherreklamation, Gast-Swapping oder einem unabhängigen Ereignis zusammenfällt.

vCPU ist ein planbarer Ausführungskontext

Der Gast plant Threads auf seine vCPUs; der Hypervisor plant diese vCPUs auf physische Ausführungseinheiten. Mehr vCPUs erhöhen die mögliche Parallelität, aber nur, wenn der Workload parallel arbeiten kann und der Host genügend passende CPU-Zeit besitzt. Zusätzliche vCPUs vergrößern außerdem die Menge planbarer Zustände und können für synchronisierte Workloads oder große VMs die Platzierung erschweren. Lies drei Signalklassen zusammen. Gastnachfrage zeigt, wie viele Prozesse laufbereit sind und wie stark die vCPUs ausgelastet werden. Hypervisorsignale zeigen Laufzeit, Warte- oder Konkurrenzindikatoren nach Plattform. Hostsignale zeigen Gesamtlast, Queue, Topologie und konkurrierende VMs. Produktnamen unterscheiden sich: Ein Ready-, Wait- oder Steal-Wert besitzt nur im Kontext seiner Definition und Einheit Bedeutung. Vergleiche keine Prozentwerte verschiedener Plattformen ohne ihre Messsemantik. Libvirt kann mit domstats unter anderem vCPU- und Balloon-Statistiken einer Domain liefern: ``bash virsh domstats app-01 --state --vcpu --balloon `` Diese Werte ersetzen keine Anwendungsmetrik und enthalten nicht automatisch jede gewünschte Konkurrenzkennzahl. Sie verbinden aber die Domainidentität mit einem Hypervisorblick. Wenn Gast-CPU moderat ist, die Anwendung langsam wird und mehrere VMs desselben Hosts zeitgleich Konkurrenzsignale zeigen, prüfe Hostlast und Platzierung vor einer vCPU-Erhöhung. Eine größere VM kann dieselbe knappe physische Ressource nicht vermehren.

Right-Sizing testet Parallelität statt eine Auslastungszahl

Eine dauerhafte CPU-Größe braucht einen Workloadgrund. Bei serieller Arbeit bleibt ein Kern der Engpass, während weitere vCPUs meist ungenutzt bleiben. Bei parallelisierbarer Arbeit kann eine Erhöhung Durchsatz verbessern, bis Locking, I/O oder ein anderer Grenzwert übernimmt. Eine hohe Gesamtauslastung bei gutem SLO kann effizient und unproblematisch sein; eine niedrige Auslastung bei schlechter Latenz kann auf Warten statt Rechnen hinweisen. Führe Größenänderungen einzeln und reversibel durch. Sichere Baseline, ändere eine Dimension in begrenztem Umfang, halte Last und Platzierung soweit möglich konstant und vergleiche Dienstsignal sowie Gast-, VM- und Hostmetriken. Lege vorab fest, wie groß die erwartete Verbesserung sein muss und bei welchem Nebeneffekt du zurückrollst. Sonst wird jedes zufällige Schwanken als Erfolg interpretiert. Downsizing verdient denselben Schutz. Weniger vCPUs können Planung und Konsolidierung verbessern, dürfen aber keine seltene Spitzenlast brechen. Nutze repräsentative Fenster und schrittweise Wellen statt Flottendurchschnitt. Dokumentiere nach dem Test nicht nur den neuen Wert, sondern die Begründung: Workloadmuster, beobachtete Parallelität, SLO-Wirkung und verbleibende Hostreserve. Die kleinste ausreichende Größe ist kein Selbstzweck. Sie hält Kapazität für Nachbarn, Wartung und Failover verfügbar und reduziert gleichzeitig den Umfang jeder späteren Platzierungsentscheidung.

Virtueller Speicher besitzt mehrere Druckstufen

Beim Arbeitsspeicher müssen konfigurierte Maximalgröße, aktuelle Zuweisung, aktive Arbeitsmenge und physische Hostverfügbarkeit unterschieden werden. Plattformen können Speicher dynamisch zuweisen oder über einen Balloon-Treiber vom Gast zurückfordern. Der Balloon belegt im Gast Seiten, damit der Gast selbst auswählt, welche Inhalte er freigibt. Das ist koordinierter als ein blindes Entziehen, aber nicht kostenlos: Muss der Gast aktive Seiten verdrängen oder auslagern, steigt Latenz. Zusätzlich kann der Gast eigenen Swap nutzen, während der Host selbst unter Speicherdruck steht. Diese Ebenen dürfen nicht isoliert bewertet werden. Gast-Swapping kann auch durch eine lokale Anwendungsspitze entstehen; Host-Reclamation kann unkritisch sein, solange nur wirklich freie Seiten zurückgegeben werden. Kritisch wird die Korrelation: mehrere Gäste zeigen gleichzeitig Paging oder steigende Latenz, während der Host aggressiv reklamiert und seine Reserve schrumpft. Unter Linux zeigt Pressure Stall Information, wie viel Zeit Tasks wegen knapper CPU-, Speicher- oder I/O-Ressourcen nicht vorankommen. Die Dateien unter /proc/pressure/ liefern Zeitfenster und kumulierte Stallzeit: ``bash cat /proc/pressure/memory cat /proc/pressure/cpu `` PSI ist ein Signal des Systems, auf dem du es liest. Gast-PSI und Host-PSI beantworten unterschiedliche Fragen. Korreliere sie mit VM-Metriken und Anwendungslatenz, bevor du Ballooning deaktivierst, RAM erhöhst oder Workloads verschiebst.

Limits, Reservierungen und Gewichtungen erfüllen andere Zwecke

Ressourcensteuerungen sind keine Synonyme. Ein Limit begrenzt maximal nutzbare Ressource und kann Leistung drosseln, obwohl der Host frei ist. Eine Reservierung hält nach Plattformsemantik eine Mindestressource oder Admission-Zusage bereit und reduziert damit den frei planbaren Pool. Eine Gewichtung oder Priorität beeinflusst die Konkurrenzverteilung, wenn Nachfrage die verfügbare Kapazität übersteigt. Die exakte Wirkung muss in der Dokumentation der eingesetzten Plattform geprüft werden. Setze eine Reservierung nur für einen belegten Mindestbedarf. Eine Vollreservierung für jede VM verhindert flexible Konsolidierung und kann Wartung oder Failover blockieren. Keine Reservierung für einen nachweislich kritischen Mindestbedarf kann dagegen bedeuten, dass dieser Dienst in Konkurrenzsituationen sein Ziel verliert. Rechne deshalb jede Zusage gegen Normalbetrieb und vereinbarten Hostausfall. Limits sind besonders tückisch, weil die Gastmetrik hohe Auslastung zeigen kann, während der Host Kapazität besitzt, die VM sie aber nicht erhalten darf. Prüfe bei unerwarteten Plateaus, ob eine Richtlinie den Workload begrenzt. Entferne ein Limit nicht blind; vielleicht schützt es Nachbarn oder Kosten. Belege zuerst, dass es die SLO-Verletzung verursacht, und bewerte den neuen Blast Radius. Dokumentiere Zweck, Owner, Ablauf und Messsignal jeder Sonderregel. Eine alte Reservierung ohne aktuellen Workloadgrund ist gebundene Clusterkapazität; ein altes Limit ohne Owner ist unsichtbare Drosselung.

NUMA macht Speicherlokalität sichtbar

Bei Non-Uniform Memory Access sind CPUs und Speicher in Knoten organisiert. Zugriff auf lokalen Speicher ist günstiger als Zugriff über eine Verbindung zu einem anderen Knoten. Der Hypervisor kann diese Topologie dem Gast präsentieren und vCPUs sowie Speicher passend platzieren. Eine große VM, die die Kapazität eines Knotens überschreitet, benötigt möglicherweise Ressourcen aus mehreren NUMA-Bereichen. Das ist nicht automatisch falsch, verändert aber den Latenz- und Platzierungsvertrag. Erfasse zuerst physische und virtuelle Topologie. lscpu kann CPU-, Sockel- und NUMA-Zuordnung anzeigen; Libvirt beschreibt NUMA- und CPU-Platzierung in der Domaindefinition. Vergleiche VM-Größe, Hostknoten und Workloadzugriff, bevor du manuell bindest. Eine feste Pinningregel kann Lokalität verbessern, schränkt aber Schedulerfreiheit, Wartung und Zielhostmenge ein. ``bash lscpu -e=CPU,NODE,SOCKET,CORE virsh dumpxml db-01 `` Wenn eine Datenbank nach gleichzeitiger vCPU- und RAM-Erhöhung unregelmäßiger wird, prüfe, ob die neue Größe eine Topologiegrenze überschritten hat. Sichere die vorherige Größe und Platzierung, korreliere lokale beziehungsweise entfernte Speicherwirkung mit dem Dienstsignal und teste eine Änderung. „Noch größer“ ist keine Diagnose. NUMA-Optimierung ohne reproduzierbare Last kann zufällige Verbesserungen erzeugen und die VM unnötig an eine Hostklasse binden. Verwende sie für nachgewiesene große oder latenzsensitive Workloads, nicht als pauschale Baseline für jede VM.

Platzierung steuert Leistung und Ausfallradius zugleich

Eine belastete VM kann durch Umplatzierung freie Ressourcen erhalten, doch dieselbe Entscheidung verändert Fehlerdomäne, Netz- und Storagepfad sowie verbleibende Reserve. Prüfe vor einer Migration daher nicht nur den Zielhost im aktuellen Leerlauf. Er muss die Workload auch während ihrer Spitze und innerhalb des vereinbarten Ausfallfalls tragen. Anti-Affinity trennt Instanzen, die nicht gemeinsam mit einem Host ausfallen dürfen. Affinity kann nötig sein, wenn Kommunikations- oder Geräteanforderungen eine Platzierung verbinden. Beide Regeln sind fachliche Verträge, keine dekorativen Labels. Eine harte Regel kann Admission blockieren, wenn nicht genügend passende Hosts existieren; eine weiche Regel kann im Engpass bewusst verletzt werden. Das erwartete Verhalten muss vor dem Ausfall bekannt sein. Kapazität und Verfügbarkeit konkurrieren. Ein dicht konsolidierter Cluster kann im Normalbetrieb effizient aussehen, aber keinen Host mehr evakuieren. Umgekehrt können übergroße Einzel-VMs nur noch auf wenigen Hosts starten und die Wiederherstellung verlangsamen. Berücksichtige deshalb bei jedem Right-Sizing die Zahl zulässiger Zielhosts und die Ressourcen nach Abzug bereits zugesagter Reservierungen. OpenStack Nova verwendet Server Groups für Affinity- und Anti-Affinity-Richtlinien; andere Plattformen besitzen vergleichbare Mechanismen mit eigener Semantik. Entscheidend ist nicht der Produktname, sondern dass die Dienstbeziehung maschinenlesbar in der Platzierung ankommt und regelmäßig gegen den realen Zustand geprüft wird.

Überbuchung ist ein Nachfragerisiko, keine einzelne Quote

Eine vCPU- oder RAM-Überbuchungsquote vergleicht konfigurierte Ansprüche mit physischer Kapazität. Sie sagt allein nicht, ob der Host sein SLO einhält. Zehn selten aktive VMs können trotz hoher nomineller Quote problemlos zusammenpassen; mehrere korrelierte Batchjobs können eine niedrigere Quote gleichzeitig überfordern. Entscheidend sind Gleichzeitigkeit, aktive Nachfrage, zulässige Verzögerung und der zugesagte Ausfallfall. Bewerte Überbuchung deshalb als Risikobudget. Lege fest, welche Workloadklassen Ressourcen teilen dürfen, welche Spitzen gemeinsam auftreten, welche Mindestzusagen existieren und welche Last nach dem Verlust eines Hosts auf den verbleibenden Pool fällt. Historische Messung ist nötig, aber nicht hinreichend: Ein bisher nie eingetretener Monatsabschluss plus Hostausfall kann trotzdem Teil des vereinbarten Szenarios sein. Ergänze Beobachtung um geplante Stress- oder Evakuierungstests. Trenne Normalreserve von Recoveryreserve. Normalreserve fängt Messrauschen, Boot und gewöhnliche Spitzen ab. Recoveryreserve erlaubt Wartung oder den definierten Hostausfall. Wird sie im Alltag für neue VMs verbraucht, ist der Cluster nominell online, aber nicht mehr im vereinbarten Zustand. Eine Alarmierung sollte deshalb nicht erst bei physischer Erschöpfung beginnen, sondern beim Unterschreiten der jeweils zugesagten Reserve. Ein Admission Gate verwendet mehrere Grenzen: aktuelle und prognostizierte Nachfrage, harte Reservierungen, zulässige Zielhosts, NUMA- oder Geräteanforderungen und verbleibende Kapazität nach Ausfall. Eine pauschale Flottenquote kann ein Berichtssignal sein, ersetzt diese Entscheidung aber nicht. Dokumentiere jede Überschreitung als zeitlich begrenzte Ausnahme mit Owner, SLO-Risiko und Rückbauplan. So bleibt Konsolidierung eine bewusste wirtschaftliche Entscheidung und wird nicht zu versteckter Leistungs- oder Verfügbarkeitschuld.

Eine Ressourcenänderung braucht Baseline, Wirkung und Rückweg

CPU- und RAM-Änderungen können einen Gastneustart, andere NUMA-Platzierung, neue Admission-Berechnung oder veränderte Lizenzierung auslösen. Behandle sie deshalb als kontrollierte Änderung. Der Plan enthält Symptom, Hypothese, Messfenster, alte und neue Größe, Plattformgrenzen, Zielwert, Abbruchsignal und technischen Rückweg. Ändere nur eine erklärende Dimension pro Test. Werden gleichzeitig vCPU, RAM, Host und Anwendungskonfiguration verändert, ist ein Erfolg nicht mehr zuordenbar. Eine notwendige Notfallentlastung kann mehrere Maßnahmen bündeln, muss dann aber als Stabilisierung und nicht als bewiesenes Right-Sizing dokumentiert werden. Die dauerhafte Konfiguration folgt nach einer separaten Messung. Prüfe nach der Änderung sowohl Verbesserung als auch Nebenwirkung: Dienst-SLO, Gastqueue, VM-Konkurrenzsignal, Hostreserve, Nachbarlatenz, zulässige Zielhosts und Failoverkapazität. Ein schnellerer Workload ist kein vollständiger Erfolg, wenn der Cluster danach keinen Hostausfall mehr tragen kann. Setze nach dem Beobachtungsfenster eine Entscheidung: übernehmen mit neuer Begründung, zurückrollen, oder nächste einzelne Hypothese testen. Entferne temporäre Reservierungen und Platzierungsausnahmen. So bleibt die Ressourcenlandschaft Ergebnis nachvollziehbarer Experimente statt einer Folge kumulierter Notfallwerte.

Arbeitsbeispiel: mehr vCPU verschlechtert den Monatsabschluss