Hardware Kapazitätsplanung in Zeiten von RAMaggedon

Wer heute Hardware für eine VMware-Private-Cloud plant, entscheidet unter Kostendruck: Speicher ist teuer, Server-Budgets sind knapp, und die Lizenzierung orientiert sich an Cores. Die klassische Faustformel, etwa ein festes Verhältnis von vCPU zu pCPU, liefert dabei eine einfache Zahl, aber keine belastbaren Ergebnisse. Sie sagt, was zugewiesen wurde, nicht, was die Workloads tatsächlich brauchen.

VCF 9.1 setzt hier an zwei Punkten an: Advanced Memory Tiering senkt den Bedarf an teurem DRAM, und VCF Operations rechnet Kapazität standardmässig auf Basis der realen Auslastung (Demand). Dieser Beitrag zeigt, wie Sie beides in einer What-If-Analyse zusammenbringen und daraus eine Hardware-Entscheidung ableiten.

Capacity Planning und What-If in VCF Operations

VCF Operations berechnet Kapazität aus gemessener Nachfrage (Demand) und nutzbarer Kapazität, nicht aus Zuweisungen. Die Engine sammelt Messwerte alle fünf Minuten, wertet sie einmal täglich aus und prognostiziert bis zu einem Jahr voraus. Ergebnis sind Time Remaining (Tage bis zum Erreichen der Schwelle), Capacity Remaining sowie eine empfohlene Grösse. Als nutzbare Kapazität zählt die Gesamtkapazität abzüglich der Reserve, die vSphere HA für den Ausfall zurückhält, sowie eines allfällig in der Policy definierten Kapazitätspuffers.

Die What-If-Analyse (Manage, Capacity, Plan) beantwortet daraus konkrete Planungsfragen:

• Workload hinzufügen oder entfernen: Passt ein Projekt mit definierten vCPU, Memory und Storage noch in den Cluster, und wie lange reicht die Kapazität danach?
• Kapazität hinzufügen oder entfernen: Wie wirkt sich ein zusätzlicher oder ausser Betrieb genommener Host auf die Time Remaining aus?
• Migration: Wohin passt ein Workload, und welcher Cluster ist das beste Ziel?
• Neuer Cluster: Wie gross muss neue Hardware sein, wenn der Workload nirgends mehr passt?

Das Resultat zeigt, ob der Workload passt, welcher Cluster das Ziel ist und wie viel Zeit bleibt. Passt er nicht, weist VCF Operations die Unterdeckung aus. Ein Szenario lässt sich auf bis zu ein Jahr in die Zukunft projizieren.

Memory Tiering: mehr Speicher pro Host, ohne mehr DRAM zu kaufen

Mit Advanced Memory Tiering nutzt ein ESX-Host lokale NVMe-Laufwerke als zweite Speicherebene neben dem DRAM. Hot Pages bleiben im schnellen DRAM, Cold Pages wandern auf NVMe. Die VMs sehen den kombinierten, logischen Speicher.

Broadcom nennt für VCF 9.1 bis zu viermal so viel verfügbaren Speicher pro Host, doppelt so gute Konsolidierung und bis zu 40 Prozent tieferen TCO. Das sind Herstellerangaben, die wir in jedem Projekt am eigenen Workload prüfen. soulTec rechnet im Normalfall mit einem Verhältnis von 1:1, sprich: Aus 1 TB DRAM pro Host werden 2 TB logischer Speicher pro Host.

Für die Planung zählen vor allem diese Rahmenbedingungen aus der Broadcom-Dokumentation:

• Verhältnis: Standard ist 1:1 zwischen DRAM und NVMe, konfigurierbar von 1 bis 400 Prozent, mit maximal 4 TB pro Tier-Partition.
• Eignung: Die aktive Speichernutzung des Hosts sollte 50 Prozent des DRAM nicht überschreiten. Laut Broadcom sind die meisten Workloads zu 10 bis 30 Prozent aktiv.
• Hardware: lokale NVMe-Laufwerke mit hoher Schreib-Endurance (in der Praxis Mixed Use mit mindestens 3 DWPD), nicht über Fabric oder Ethernet angebunden, dediziert und nicht für vSAN, Boot oder Datastore verwendet.
• Ausfallschutz: In 9.1 ist Software-Mirroring der NVMe-Laufwerke ohne RAID-Controller möglich.
• Einschränkungen: Memory Overcommit wird bei aktivem Tiering nicht unterstützt. Grosse VMs (ab 512 GB Memory oder 64 vCPU) können Leistungseinbussen zeigen. vMotion getierter VMs dauert 1,5- bis 2-mal länger.

Für die Kapazitätsplanung heisst das: Speicher ist nicht mehr nur eine DRAM-Zahl pro Host, sondern ein Design-Parameter mit eigener Eignungsprüfung.

Hardwarekosten im What-If: DRAM gegen NVMe

VCF Operations simuliert den Effekt von Memory Tiering direkt auf die Hardwarekosten. Die Simulation vergleicht, was es kostet, die Speicherkapazität pro Host mit DRAM zu erweitern verglichen mit den Kosten für NVMe für dieselbe Kapazität. Als Kandidaten gelten Cluster mit einer aktiven Speichernutzung unter 50 Prozent. Die Rechnung basiert auf einem 1:1-Verhältnis zwischen DRAM und NVMe.

Annahme in VCF Operations	Wert
Preis DRAM	10 CHF pro GB
Preis NVMe	rund 1 CHF pro GB
Beispiel: zusätzlicher Speicherbedarf	4’600 GB
Kosten mit DRAM	46’000 CHF
Kosten mit NVMe (ohne Mirroring)	rund 4’600 CHF
Differenz	rund 41’400 CHF

 

Mit gespiegelten NVMe-Laufwerken (Mirroring) verdoppeln sich die NVMe-Kosten auf rund 9’200 CHF. Die Differenz liegt dann bei rund 36’800 CHF.

Die Preise sind feste Annahmen der Simulation, decken sich aber aktuell relativ gut mit den uns bekannten Preisen. Für eine Investitionsentscheidung ersetzen wir die Annahmen durch die tatsächlichen Hersteller-Offerten, denn DRAM- und NVMe-Preise schwanken stark. Die Aussage bleibt: Je grösser die Preisdifferenz zwischen DRAM und Enterprise-NVMe, desto grösser der Hebel.

Zu beachten ist, dass VMs mit Reservierungen aus dem Tiering ausgeschlossen sind und somit diese Reservierungen den effektiven DRAM-Pool reduzieren.

Abschied vom vCPU:pCPU-Ratio: Nachfrage statt Zuweisung

In VCF Operations ist das Demand-Modell der Standard und fliesst immer in die Kapazitätsberechnung ein. Ein Overcommit-Verhältnis ist nur ein optionales Allocation-Modell, das pro Cluster in der Policy ein- oder ausgeschaltet wird. Das ist der eigentliche Wechsel: Eine feste Zielzahl wie ein bestimmtes vCPU-zu-pCPU-Verhältnis ist kein Planungsinput mehr, sondern höchstens eine zusätzliche Leitplanke.

Der Unterschied zeigt sich in der Praxis:

• Allocation: Ist ein Overcommit-Verhältnis gesetzt und überschritten, fällt Capacity Remaining auf null, auch wenn die CPUs real kaum ausgelastet sind. Das führt zu Hardware, die nur wegen einer Regel gekauft wird.
• Demand: Die Prognose folgt dem tatsächlichen Lastverhalten, einschliesslich periodischer Spitzen wie Monatsabschluss oder Batch-Läufen. Diese haben laut Dokumentation den grössten Einfluss auf die Planung.
• Risikoprofil: Conservative rechnet mit der oberen Prognosegrenze, Aggressive mit dem Mittelwert aus oberer und unterer Grenze. So wird die Risikobereitschaft eine bewusste Entscheidung statt einer versteckten Annahme.

Bei Memory Tiering kommt hinzu: Memory Overcommit wird bei aktivem Tiering nicht unterstützt. Auch deshalb sollte die Planung auf gemessener aktiver Speichernutzung beruhen und nicht auf einem Verhältnis.

Empfehlungen und Fazit

Vor der nächsten Hardware-Beschaffung lohnt sich ein strukturiertes Sizing in VCF Operations. Wir empfehlen diese Reihenfolge:

1. Bestand messen: Aktive Speichernutzung und CPU-Auslastung pro Cluster erfassen, damit klar ist, welche Cluster für Memory Tiering unter der 50-Prozent-Grenze liegen.
2. Policy prüfen: Festlegen, ob ein Allocation-Modell mit Overcommit-Verhältnis überhaupt gebraucht wird, und das Risikoprofil (Conservative oder Aggressive) bewusst wählen.
3. What-If rechnen: Geplante Workloads, zusätzliche Hosts und Memory Tiering als getrennte Szenarien simulieren und die Time Remaining vergleichen.
4. Kosten mit Offerten hinterlegen: Die Annahmen der Simulation durch reale DRAM- und NVMe-Preise ersetzen, inklusive NVMe-Mirroring.
5. Pilot mit Fallback: Tiering zuerst auf einem Cluster mit gut verstandenem Workload einsetzen, inklusive NVMe-Mirroring und Ausnahmen für grosse oder reservierte VMs.

Das Fazit: Kapazitätsplanung in VCF 9.1 beantwortet nicht mehr «Wie viele vCPU pro Core?», sondern «Wie viel Nachfrage entsteht, und was kostet es, sie zu decken?». Memory Tiering ist dabei ein Hebel auf der Kostenseite, die What-If-Analyse das Werkzeug, um ihn zu prüfen.

soulTec unterstützt dich bei der Kapazitätsanalyse, der What-If-Modellierung und der Hardware-Auswahl für VMware Cloud Foundation. Sprich uns an.