vSphere-Kapazitätsplanung: CPU, Arbeitsspeicher und Speicher für die nächsten drei Jahre prognostizieren

Wie Sie die vSphere-Kapazität für die nächsten drei Jahre planen

Die vSphere-Kapazitätsplanung für drei Jahre beginnt beim Bedarf, nicht bei der Zuweisung. Nehmen Sie das 95. Perzentil der Cluster-Summen für CPU und Arbeitsspeicher über 90 Tage mit Messwerten im 5-Minuten-Takt und den heute belegten Speicher, addieren Sie Jahr für Jahr das Wachstum, das sich aus Geschäftsplan und Projektliste ergibt, und halten Sie Reserve für einen Hostausfall und für Patch-Fenster vor. Stimmen Sie das Ergebnis dann mit der Verlängerung des Abonnements und der Hardware-Erneuerung ab, denn die Zahl der Hosts zu jedem Verlängerungstermin bestimmt die Zahl der lizenzierten Kerne.

Zuweisung ist, was VMs an vCPUs, konfiguriertem Arbeitsspeicher und provisionierten Festplatten erhalten haben, Bedarf ist, was sie nutzen. Wer zuerst überdimensionierte Zuweisungen zurückholt, wie es unser Leitfaden zur Verschwendung in vSphere-Umgebungen beschreibt, gibt dem Plan eine saubere Ausgangsbasis. VCF Operations, früher Aria Operations, berechnet vieles davon bis zu ein Jahr im Voraus; für das zweite und dritte Jahr brauchen Sie ein eigenes Modell.

Eingangsgrößen für eine vSphere-Kapazitätsprognose

Dokumentation zu vSphere 8.0 zur Verdichtung der Leistungsdiagramme (16. September 2026); Dokumentation zu VCF Operations 9.1 zur Kapazität (8. Oktober 2026); Programmdokumentation zu VVF (Juni 2026).

Das Messintervall entscheidet, ob die Spitzen noch in den Daten stecken. Laut der Dokumentation zu vSphere 8.0 aggregieren Hosts Statistiken alle 5 Minuten, und vCenter fasst sie für die längeren Diagramme zu einem Datenpunkt alle 30 Minuten zusammen, dann alle zwei Stunden, dann täglich. Eine 90-Tage-Historie aus diesen Diagrammen mittelt kurze Spitzen wie einen Batchlauf zum Monatsende zu Tageswerten; halten Sie deshalb 5-Minuten-Messwerte für das ganze Fenster vor, in VCF Operations oder einem externen Collector. Messen Sie je Cluster, denn ein freier Host in einem Cluster hilft einem anderen nicht.

Bedarfs- und Zuweisungsmodell in VCF Operations

VCF Operations dimensioniert Kapazität mit zwei Modellen. Das Bedarfsmodell (Demand) wird immer verwendet. Laut Broadcoms Dokumentation zu Richtlinien wird das Zuweisungsmodell (Allocation) „für Kapazitätsberechnungen nur verwendet, wenn Sie es in der Richtlinie aktivieren“, und seine Einstellung nimmt ein Overcommit-Verhältnis für CPU, Arbeitsspeicher oder Festplattenspeicher auf. Sind beide aktiv, hält Broadcoms KB 437777, geschrieben für VCF Operations 9.0 und Aria Operations 8.18, fest: „Die Kapazitäts-Engine warnt auf Grundlage des Modells (Demand oder Allocation), dessen Kapazität zuerst erschöpft ist.“

Dieselbe KB führt kritische CPU-Kapazitätswarnungen auf Clustern, die in vCenter ruhig wirken, auf historische Spitzen zurück, die das Bedarfsmodell einbezieht und die Momentanwerte von vCenter nicht zeigen, und rät davon ab, sie durch Aktivieren des Zuweisungsmodells mit willkürlichen Overcommit-Verhältnissen zu beheben.

Die Zuweisung gehört dennoch als zweite Prüfung in den Plan, denn ein Cluster mit freier Bedarfskapazität kann ein Verhältnis von vCPU zu Kern erreichen, bei dem CPU Ready je vCPU steigt. Ein Broadcom-Dokument, das einen allgemeinen Zielwert für dieses Verhältnis festlegt, haben wir nicht gefunden; wie Sie es prüfen, erklärt unser Leitfaden zu CPU Ready.

Wie VCF Operations Time Remaining und Capacity Remaining prognostiziert

Laut Broadcoms Dokumentation zu VCF 9.1, aktualisiert am 8. Oktober 2026, nimmt die Kapazitäts-Engine Bedarf und nutzbare Kapazität als Eingabe. Nutzbare Kapazität ist „die Gesamtkapazität abzüglich der Ressourcen, die vSphere HA Admission Control für das Failover reserviert“, und ohne HA entspricht sie der Gesamtkapazität. Ein Kapazitätspuffer in der Richtlinie, standardmäßig null, verringert die nutzbare Kapazität weiter, doch laut Broadcoms Richtliniendokumentation zu 9.0 ist er für Compute-Ressourcen von Clustern seit Version 8.6 veraltet.

Broadcom TechDocs, VCF 9.1, How Does VCF Operations Calculate and Forecast Capacity (8. Oktober 2026).

Mit dem Standard-Warnschwellenwert von 120 Tagen deckt die empfohlene Größe das prognostizierte Maximum 150 Tage voraus ab. Die Dokumentation ergänzt, dass der tatsächliche Dimensionierungsbedarf die empfohlene Größe plus Ihre Reservekapazität für vSphere HA ist.

Die Engine erfasst alle fünf Minuten Datenpunkte und verarbeitet sie einmal in 24 Stunden. Ältere Daten gewichtet sie exponentiell geringer, sodass eine anhaltende Spitze, die sich nicht wiederholt, verblasst, während periodische Spitzen wie ein Batchlauf zum Monatsende nicht abklingen und am stärksten zählen. Die Prognosen reichen ein Jahr in die Zukunft und decken 90 % der künftigen Datenpunkte zwischen einer oberen und einer unteren Grenze ab. Die konservative Risikostufe plant mit der oberen Grenze, die aggressive mit dem Mittelwert beider.

Die Dokumentation zu VCF 9.1 erlaubt, bis zu sechs Zeiträume aus den Kapazitätsberechnungen auszuschließen, eine Option, die Broadcoms VCF-Blog am 6. August 2025 für anomale Zeiträume vorgestellt hat. Nutzen Sie sie für ein Migrationswochenende oder einen hängenden Job, der tagelang lief, und lassen Sie die Spitzen zum Monatsende in den Daten, denn der Plan muss sie tragen.

Was-wäre-wenn-Analyse für neue Workloads und neue Hosts

Die Was-wäre-wenn-Analyse in VCF Operations bildet eine Änderung ab, bevor sie eintritt. Die Workload-Planung fügt VMs hinzu oder entfernt sie, konfiguriert über vCPUs, Arbeitsspeicher, Speicher und erwartete Nutzung in Prozent oder von bestehenden VMs als Vorlagen übernommen. Sie meldet, ob die Workload in den gewählten Cluster passt, und prognostiziert die verbleibende Zeit. Die Infrastrukturplanung fügt Server hinzu oder entfernt sie, von einem Typ, der bereits im Cluster läuft, einem zum Kauf freigegebenen Typ oder einer eigenen Konfiguration, und zeigt, ob die Zeit, bis CPU oder Arbeitsspeicher ausgehen, länger oder kürzer wird.

Beide verwenden standardmäßig ein Fenster von heute bis ein Jahr ab heute, die Grenze, die die Dokumentation setzt. Nutzen Sie die Was-wäre-wenn-Analyse für Projekte mit Termin in den nächsten zwölf Monaten, etwa eine neue Anwendung, die innerhalb des Jahres in Betrieb gehen soll, und übernehmen Sie jedes Ergebnis als Sprung in das Drei-Jahres-Modell. Setzen Sie als erwartete Nutzung die gemessene Nutzung vergleichbarer VMs an, nicht 100 %.

Eine Drei-Jahres-Prognose ohne VCF Operations

Ohne VCF Operations, oder für das zweite und dritte Jahr, genügt eine Tabellenkalkulation je Cluster. Die Schritte prognostizieren die Spitze; wie aus einer Spitze mit N+1 und HA Admission Control eine Zahl von Hosts wird, behandelt unser Leitfaden zur Host-Konsolidierung.

1. Exportieren Sie 90 Tage Cluster-Summen im 5-Minuten-Takt für CPU-Nutzung, verbrauchten Arbeitsspeicher und belegten Speicher, mit einem Quartalsende im Fenster.
2. Ermitteln Sie das 95. Perzentil und das Maximum von CPU und Arbeitsspeicher und notieren Sie, wann sie auftraten; beim Speicher nehmen Sie die belegte Kapazität am Ende des Fensters, da sie steigt, statt Spitzen zu bilden.
3. Leiten Sie das organische Wachstum je Jahr aus 12 bis 24 Monaten Quartalsendwerten ab, etwa Zahl der VMs und verbrauchter Arbeitsspeicher, und prüfen Sie es gegen den Geschäftsplan.
4. Listen Sie Stilllegungen und Projekte nach Quartal auf, jedes Projekt als VM-Profile mit vCPU, Arbeitsspeicher, Speicher und erwarteter Nutzung.
5. Wenden Sie das Wachstum Jahr für Jahr an, addieren und subtrahieren Sie die Projekte und vergleichen Sie die Spitze jedes Jahres mit der Kapazität des Clusters abzüglich eines Hosts bei der Auslastungsobergrenze, die Sie akzeptieren.
6. Wiederholen Sie die Rechnung mit einem hohen Fall: mehr Wachstum und die Projekte ein Quartal früher.

Das Beispiel dient der Veranschaulichung und ist kein Kundenfall. Ein Cluster aus 20 Hosts mit je zwei 32-Kern-CPUs und 1.024 GB Arbeitsspeicher betreibt 1.100 VMs. Seine 95. Perzentile liegen bei 420 Kernen CPU-Bedarf und 12.800 GB verbrauchtem Arbeitsspeicher, und er belegt heute 300 TiB Speicher. Der Geschäftsplan ergibt ein Wachstum von 6 % pro Jahr bei der CPU, 8 % beim Arbeitsspeicher und 15 % beim Speicher. Im Jahr 1 werden 60 Legacy-VMs mit 600 GB und 15 Kernen stillgelegt. Im Jahr 2 bringt ein ERP-Upgrade 40 VMs mit 160 vCPU bei 30 % erwarteter Nutzung, 2.048 GB und 40 TiB hinzu. Die Obergrenze liegt bei 80 % bei Ausfall eines Hosts.

Beispielwerte, unsere Rechnung: Hosts = Arbeitsspeicher ÷ 0,8 ÷ 1.024 GB, aufgerundet, plus ein Host für einen Ausfall; allein für die CPU wären 10 bis 12 Hosts mit 64 Kernen nötig.

Der Arbeitsspeicher bestimmt in jedem Jahr die Zahl der Hosts: heute drei Hosts Reserve, im Jahr 1 noch ausreichend, ein 21. Host, wenn das ERP-Projekt im Jahr 2 kommt, und 23 Hosts im Jahr 3. Mit 1.536 GB je Host kommt derselbe Plan im Jahr 3 mit 16 Hosts aus. Arbeitsspeicher trägt keine Lizenz, bei zwei 32-Kern-CPUs je Host macht diese Wahl also den Unterschied zwischen 1.472 und 1.024 lizenzierten Kernen. Der Speicher wächst schneller als beides und kann einen Kauf in einem Jahr erzwingen, in dem die Rechenkapazität noch reicht. Ein Cluster, der während eines Patch-Fensters einen Hostausfall tolerieren muss, braucht in jeder Zeile einen Host mehr.

Das Assessment unserer VMware-Optimierung prüft Versionen, Abonnements und die tatsächliche Ressourcennutzung und liefert einen Maßnahmenplan vor dem Renewal. Schicken Sie uns Ihre Cluster-Exporte und die Projektliste über das Formular unten.

Speicherwachstum im Kapazitätsplan

Thin-Disks wachsen in Richtung ihrer provisionierten Größe, Snapshots, bis sie gelöscht werden, und Log- und Staging-Volumes mit ihren Aufbewahrungseinstellungen statt mit den Nutzern. Verfolgen Sie die provisionierte Kapazität neben der belegten: Ein Datastore, der zu 70 % belegt, aber mit 150 % seiner Größe provisioniert ist, hat weniger Spielraum, als der Belegungswert vermuten lässt.

Unter vSAN ist die belegte Kapazität der Anfang der Rechnung. Hinzu kommen der Overhead der Speicherrichtlinie sowie die Betriebsreserve und die Host-Rebuild-Reserve, und die Rohkapazität zählt gegen den vSAN-Anspruch, 0,25 TiB je lizenziertem Kern mit VVF. Unser Leitfaden zum vSAN-ESA-Sizing rechnet belegte Kapazität in Rohkapazität und eine Zahl von Hosts um.

Den Plan auf Verlängerung und Hardware-Erneuerung abstimmen

Stimmen Sie den Horizont auf die Abonnementlaufzeit ab. Die Programmdokumentation zu VVF vom Juni 2026 lizenziert VVF je Kern mit einem Minimum von 16 Kernen je Prozessor und verlangt, dass jeder Kern des Servers lizenziert wird, auch im BIOS deaktivierte Kerne. Eine Laufzeit von drei Jahren wird als Zahl von Kernen gekauft, und jeder zusätzliche Host braucht mehr; bei Vertragsabschluss muss die Prognose daher die Zahl der Hosts und damit der Kerne für jedes Jahr der Laufzeit zeigen. Die Zählregeln und die Wahl der Stufe stehen in unserem Leitfaden zur Verlängerung mit Standard, VVF und VCF.

Für die meisten Pläne zählen drei Termine. Broadcoms VCF-Blog schreibt in einem Beitrag vom 1. August 2025 an SAP-Kunden, vSphere 8 „wird bis Oktober 2027 unterstützt, wobei ein optionaler zweijähriger Extended-Support-Zeitraum käuflich erworben werden kann“. Bestätigen Sie den Tag auf Broadcoms Seite zum Produktlebenszyklus, die eine Anmeldung erfordert, wie unser Leitfaden zum Ende des allgemeinen Supports von vSphere 8 erklärt. Broadcoms Beitrag vom 16. Juli 2025 nennt für die Codelinie VCF 9.x ein voraussichtliches Ende des Service am 17. Juni 2031. Er erwartet etwa alle neun Monate ein Minor-Release, mit 27 Monaten Support für die frühen und 45 für das letzte.

Der dritte Termin ist das Ende von Garantie und Support Ihrer Hosts; er entscheidet, ob der zusätzliche Host im Jahr 2 in den alten Cluster kommt oder einen erneuerten beginnt. Neue Hosts mit mehr Arbeitsspeicher je Kern ändern, welche Ressource die Zahl der Hosts bestimmt, und damit die lizenzierten Kerne. Planen Sie Erneuerung und Verlängerung gemeinsam, und rechnen Sie die Prognose jedes Quartal neu.

Unsere VMware-Optimierung liefert einen Maßnahmenplan vor Renewal und End of Support, mit Terminen. Nennen Sie uns Ihr Verlängerungsdatum und das Alter Ihrer Hosts im Formular unten.

Was wir tun

Eurokommerz hält den Vertrag und liefert Hardware und Lizenzen; die technische Umsetzung übernimmt unser Engineering-Partner Vixen.UNO. Im Rahmen der VMware-Optimierung auditiert das Vixen.UNO-Team die Umgebung einschließlich Versionen, Abonnements und tatsächlicher Ressourcennutzung, passt die Editionen an Ihre realen Workloads an und liefert einen Maßnahmenplan vor Renewal und End of Support, mit Terminen. Die Modernisierung wird mit einer Wirtschaftlichkeitsrechnung über 3 bis 5 Jahre geplant, und Änderungen laufen in vereinbarten Wartungsfenstern mit einem Rollback-Plan für jede Etappe. Unser Infrastruktur-Audit, unabhängig von jedem Kauf kalkuliert und geliefert, umfasst Compute und Virtualisierung, Storage, Netzwerke und Lizenzen anhand der Unterlagen und Exporte, die Sie bereitstellen, ohne Zugriff auf Ihre Produktivsysteme. Das erste Gespräch ist kostenlos; der Preis des technischen Assessments steht vor Beginn fest.

FAQ