vSphere-Rightsizing: Verschwendung in überdimensionierten VMs, Snapshots und Cluster-Reserven finden

Warum Rightsizing bei Lizenzierung pro Kern zählt

Eine vSphere-Umgebung richtig zu dimensionieren heißt, Kapazität zu finden, die zugewiesen, aber nicht genutzt ist (überdimensionierte VMs, vergessene VMs und verwaiste Datenträger, alte Snapshots, eine nie überprüfte Cluster-Reserve), und sie zurückzugeben. Seit VMware pro Kern im Abonnement lizenziert wird, ist die Zahl der Hosts, die Sie brauchen, 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. Vor einer Verlängerung zeigt unser Engineering-Partner Vixen.UNO, wofür Sie heute zahlen und wie viel davon genutzt wird, sodass Sie die Zahl vor der Unterschrift sehen; gibt es nichts zu optimieren, sagen wir das. Schicken Sie uns Verlängerungstermin und Hostzahl.

Der zweite Grund ist die Leistung. Eine Umgebung, die sich langsam anfühlt, braucht unter Umständen kleinere VMs statt mehr Hosts; die Gründe im Scheduling beschreibt der Abschnitt zu CPU-Ready und Co-Stop weiter unten.

Vier Stellen, an denen Kapazität ungenutzt bleibt

Rückgewinnbare Kapazität liegt in einer vSphere-Umgebung meist an vier Stellen.

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 nur Belege für den Leerlauf braucht, keine Dimensionierungsdaten. Verkleinern als Drittes, weil es Daten braucht. Reserve zuletzt, weil dafür jemand entscheiden muss, der das Risiko trägt.

Mehr vCPU, langsamere VM: CPU-Ready und Co-Stop

Eine VM mit mehr vCPUs, als sie braucht, kann langsamer laufen als dieselbe VM mit weniger.

Der Grund ist das Scheduling. ESXi plant jede vCPU einzeln ein, 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 als eine mit 4 vCPU; auf einem ausgelasteten Host wird sie also häufiger angehalten. Ihre untätigen vCPUs kosten trotzdem etwas Overhead, und ist sie breiter als ein NUMA-Knoten, belegt sie obendrein 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 keine physische CPU bekam: Konkurrenz im Allgemeinen oder ein CPU-Limit. 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 (KB 438023) nennt in der Branche anerkannte Schwellenwerte, nach denen unter etwa 5 % Ready je vCPU unbedenklich sind und über 10 % eine spürbare Leistungsbeeinträchtigung bedeuten, und wertet Co-Stop unter etwa 3 % je vCPU als normal; anhaltender Co-Stop darüber deutet in der Regel auf zu viele vCPUs hin. 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.

Wie lange und wie Sie vor dem Verkleinern messen

Messdaten weniger Tage erfassen die zyklischen Spitzen nicht. Es gelten drei Regeln.

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-Erfassungsintervallen von vCenter werden 5-Minuten-Werte einen Tag lang aufbewahrt, 30-Minuten-Mittelwerte eine Woche und 2-Stunden-Mittelwerte einen Monat; ein Monat vCenter-Daten hat die Spitzen, die Sie suchen, also bereits eingeebnet, und Co-Stop speichert vCenter erst ab Statistikebene 2, eine Stufe über dem Standard. Halten Sie 5-Minuten-Messwerte für das ganze Fenster vor, mit VCF Operations (früher Aria Operations) 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. Dimensionieren Sie auf das 95. Perzentil der anhaltenden Nutzung und rechnen Sie die Reserve hinzu, die Sie festlegen.

In Schritten kürzen, und immer nur eine Größe. vCPU halbieren, zwei Wochen warten, wieder hinsehen; jede Verkleinerung erfordert das Ausschalten der VM. Wer CPU und Arbeitsspeicher im selben Fenster ändert, kann danach nicht sagen, welche Änderung die Beschwerde ausgelöst hat.

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 liefert

Ein brauchbares Audit-Ergebnis ist ein geordneter Plan, in dem jede Zeile eine Zahl und ein Risiko trägt:

Sofort und risikoarm: Snapshots älter als die Aufbewahrungs­richtlinie, verwaiste VMDK-Dateien, die nachweislich kein vCenter und kein Host mit Zugriff auf den Datenspeicher nutzt, ausgeschaltete VMs jenseits ihres Prüfdatums. Speicher noch am selben Tag zurück.

Nach Bestätigung: VMs mit kaum Netzverkehr und ohne Anmeldung seit 90 Tagen. Die Liste geht mit den Belegen an die Anwendungs­verantwortlichen.

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. In dieser Zeile zeigt sich eine Lizenzersparnis, falls es eine gibt; warum, steht in wie die Kernzahl berechnet wird.

Unser Infrastruktur-Audit arbeitet mit den Unterlagen und Exporten, die Sie bereitstellen, ohne Zugriff auf Ihre Produktivsysteme, und sein Umfang wird im Vertrag fixiert. Nennen Sie uns die Zahl Ihrer Hosts und VMs, unser Team hilft Ihnen weiter.

Ein durchgerechnetes Beispiel

Das folgende Beispiel dient der Veranschaulichung und ist kein Kundenfall. Ein Cluster mit acht Hosts, auf dem Papier entspannt: 62 % Arbeitsspeicher, 41 % CPU. Die Beschwerde lautete, das ERP-System sei „langsam geworden“.

In diesem Beispiel fand eine Messung über fünf Wochen drei Dinge. Die ERP-Datenbank-VM hatte 24 vCPU bei einem 95. Perzentil von sechs, mit einer Ready- und Co-Stop-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 12 und dann 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.

Was wir tun

Unser Infrastruktur-Audit ist ein eigenständiges Produkt mit Festpreis, dessen Umfang im Vertrag festgelegt wird: eine vollständige Inventur, die tatsächliche Ressourcennutzung mit Überschuss und Engpässen, ein ROI- und TCO-Modell und eine Roadmap. Die Roadmap gehört Ihnen: Sie können sie mit uns, selbst oder mit einem anderen Dienstleister umsetzen. Umgesetzt wird von unserem Engineering-Partner Vixen.UNO unter einem europäischen Vertrag. Siehe Infrastruktur-Audit und VMware-Optimierung.

FAQ