Wo in einer vSphere-Umgebung die Verschwendung wirklich sitzt

Warum sich das gerade jetzt lohnt

Kapazität zurückzugewinnen war früher Hausarbeit. Das hörte auf, als die Lizenzierung auf ein Abo pro Kern umgestellt wurde: Die Zahl der Hosts, die Sie brauchen, ist heute ein wiederkehrender Posten auf der Rechnung und nicht mehr ein einmaliger Kauf, den Sie längst getätigt haben. Genug Last freizuräumen, um einen Host stillzulegen, nimmt dessen Kerne zur nächsten Verlängerung von der Rechnung – und in jedem Jahr danach.

Der zweite Grund fällt weniger auf: Die meisten Umgebungen, die sich langsam anfühlen, haben keinen Kapazitätsmangel. Sie sind schlecht geschnitten. Die Korrektur kostet nichts und macht die Sache oft messbar schneller.

Die vier Orte, an denen sie sitzt

In den Umgebungen, die wir auditieren, liegt praktisch die gesamte rückgewinnbare Kapazität in vier Töpfen.

Die Reihenfolge zählt. Snapshots zuerst, weil sie ein Risiko sind und nicht bloß ein Kostenpunkt. Vergessene Maschinen als Zweites, weil ihre Entfernung nichts kostet und keine Messung braucht. Verkleinern als Drittes, weil es Daten braucht. Reserve zuletzt, weil dafür jemand entscheiden muss, der das Risiko trägt.

Der Gegenintuitive: mehr vCPU, langsamere VM

Dieser Befund überrascht regelmäßig, deshalb im Klartext: Eine VM mit mehr vCPUs, als sie braucht, kann langsamer laufen als dieselbe VM mit weniger.

Der Grund ist die Planung. ESXi plant jede vCPU für sich, muss die vCPUs einer VM aber ungefähr im Gleichschritt halten: Fallen einige vCPUs einer VM gegenüber ihren Geschwistern um mehr als einen Schwellenwert zurück, werden die vorauslaufenden per Co-Stop angehalten, bis die Nachzügler aufgeholt haben (Relaxed Co-Scheduling). Eine VM mit 16 vCPU hat mehr Geschwister im Gleichschritt zu halten und mehr untätige vCPUs zu bedienen als eine mit 4 vCPU – auf einem ausgelasteten Host wird sie also häufiger angehalten und belegt obendrein NUMA-Knoten, die sie nicht gebraucht hätte. Im Gast sieht das aus wie eine langsame Anwendung, während die CPU-Kurve ruhig bleibt.

Zwei Zahlen machen das sichtbar. Die CPU-Ready-Zeit ist die Zeit, in der eine vCPU bereit war und keinen physischen Kern bekam – Konkurrenz im Allgemeinen. Die Co-Stop-Zeit gibt es nur bei VMs mit mehreren vCPUs, und sie ist die Strafe für breite VMs selbst. Broadcoms Leitfaden zur Dimensionierung setzt die Schwellen bei unter 5 % Ready je vCPU als unbedenklich und über 10 % als echte Beeinträchtigung, und bei unter 3 % Co-Stop je vCPU als normal; anhaltender Co-Stop darüber bedeutet zu viele vCPUs. Die Auslastung sagt, wie hart eine VM gearbeitet hat; Ready und Co-Stop sagen, wie lange sie gewartet hat. Eine Umgebung kann überall angenehme Auslastungswerte zeigen und ihre größten VMs trotzdem aushungern. Betrachten Sie beide je vCPU, nicht je VM – die Summen wachsen sonst allein mit der Breite der Maschine.

Beim Arbeitsspeicher gibt es das Gegenstück: Ballooning und Auslagern auf Host-Ebene bedeuten, dass der Host sich Speicher von den Gästen zurückholt. Eine VM, die auslagert, hat ein Leistungsproblem, das keine Optimierung im Gast löst.

Ehrlich messen

Verkleinern auf Basis eines Blicks von letztem Dienstag ist der Weg zum Störfall. Drei Regeln halten es sicher.

Mindestens dreißig Tage, in Fünf-Minuten-Auflösung. Monatsabschluss, Lohnlauf, Berichtszyklen und Sicherungsfenster verschieben die Spitze, und eine Woche verpasst mindestens eines davon. Gibt es einen Quartalsabschluss, beobachten Sie für alles in dessen Nähe ein Quartal. Achten Sie darauf, woher die Daten kommen: Mit den Standard-Statistikstufen von vCenter ist alles, was älter als eine Woche ist, ein 30-Minuten- oder 2-Stunden-Mittelwert, und ein Perzentil auf 2-Stunden-Mittelwerten hat die Spitzen, die Sie suchen, bereits eingeebnet. Halten Sie 5-Minuten-Messwerte für das ganze Fenster vor – mit VCF Operations (Aria) oder einem externen Collector.

Nach Perzentilen dimensionieren, nicht nach Mittel- oder Höchstwert. Der Mittelwert ist bei einer stoßweisen Last bedeutungslos, der Höchstwert meist eine einzelne anomale Messprobe. Das 95. Perzentil der anhaltenden Nutzung, mit bewusster Reserve obendrauf, ist die Zahl, die den Kontakt mit der Produktion überlebt.

In Schritten kürzen, und immer nur eine Größe. vCPU halbieren, zwei Wochen warten, wieder hinsehen. Wer CPU und Arbeitsspeicher im selben Fenster ändert, kann die Beschwerde danach niemandem zuordnen.

Eine Ausnahme lohnt sich zu kennen: Bei Gastsoftware, die pro Kern oder pro vCPU lizenziert wird – manche Datenbanken rechnen so ab – kann die Softwarelizenz die Entscheidung vollständig bestimmen, und die richtige vCPU-Zahl ist die, für die der Datenbankhersteller am wenigsten verlangt. Prüfen Sie das, bevor Sie irgendetwas anfassen.

Was ein Audit tatsächlich liefert

Was nützt, ist keine Befundliste, sondern ein geordneter Plan, in dem jede Zeile eine Zahl und ein Risiko trägt:

Sofort und risikofrei: Snapshots älter als die Aufbewahrungsrichtlinie, verwaiste VMDK-Dateien, ausgeschaltete VMs jenseits ihres Prüfdatums. Speicher noch am selben Tag zurück.

Nach Bestätigung: VMs ohne Netzverkehr und ohne Anmeldung seit 90 Tagen. Da muss jemand zustimmen, also geht die Liste mit den Belegen an die Anwendungsverantwortlichen.

Verkleinern nach Messung: vorgeschlagene vCPU- und Arbeitsspeicherwerte je VM mit den Perzentildaten dahinter, sortiert danach, wie viel sie freigeben.

Konsolidieren: wie die Umgebung danach aussieht, wie viele Hosts sie wirklich braucht und was das über die Abolaufzeit mit der lizenzierten Kernzahl macht. Diese Zeile bezahlt in der Regel die ganze Übung – warum, steht in wie die Kernzahl berechnet wird.

Ein durchgerechnetes Beispiel

Ein Cluster mit acht Hosts, auf dem Papier entspannt: 62 % Arbeitsspeicher, 41 % CPU. Die Beschwerde lautete, das ERP-System sei „langsam geworden“.

Die Messung über fünf Wochen fand drei Dinge. Die ERP-Datenbank-VM hatte 24 vCPU bei einem 95. Perzentil von sechs, mit einer Ready-Zeit, die die Beschwerde vollständig erklärte. Neunzehn VMs hatten seit über 90 Tagen keine Anmeldung und kaum Netzverkehr. Und 4,1 TB Datenspeicher lagen in elf Snapshots, der älteste vierzehn Monate alt.

Das Löschen der Snapshots gab den Speicher noch in derselben Woche zurück. Das Stilllegen der vergessenen Maschinen nach Freigabe gab Arbeitsspeicher frei. Die Reduktion der ERP-VM von 24 auf 8 vCPU machte sie schneller – dasselbe Ergebnis, das der Anwendungshersteller mit einem größeren Host erreichen wollte. Der Rest passte auf sechs Hosts bei gleicher Ausfalltoleranz, und zwei Hosts fielen aus der lizenzierten Kernzahl.

Keine neue Hardware, kein Plattformwechsel – und die ursprüngliche Beschwerde behoben, indem der klagenden Maschine Ressourcen weggenommen wurden.

Was wir tun

Unser Infrastruktur-Audit ist ein Festpreisprojekt mit festem Ergebnis: die Bestandskarte, die gemessene Tabelle zur Dimensionierung, die Konsolidierungsvarianten und die Lizenzkern-Differenz je Variante. Der Bericht gehört Ihnen, unabhängig davon, ob Sie die Umsetzung mit uns machen – er ist so geschrieben, dass Sie ihn einem anderen Anbieter geben können. Umgesetzt wird von unserem Engineering-Partner Vixen.UNO unter einem europäischen Vertrag. Siehe Infrastruktur-Audit und VMware-Optimierung.

FAQ