/ EUR
Virtualisierung verführt mit Einfachheit – „VMs auf den Host werfen und es läuft”. In der Praxis funktioniert das nur, wenn Kerne, RAM und Storage berechnet wurden, bevor man auf „VMware installieren” geklickt hat. Ein Server für eine Mehrmaschinen-Umgebung ist kein „größerer Computer”. Das ist eine Plattform, die ein Dutzend, manchmal mehrere Dutzend Systeme gleichzeitig tragen muss – mit unterschiedlichen Lastprofilen, unterschiedlichem Hunger auf Speicher und I/O. Wenn Sie VMware, Proxmox oder Hyper-V im Unternehmen einsetzen möchten – fangen Sie mit der Leistung an.
Wie viele vCPUs brauchen Sie wirklich, um einen Server für Virtualisierung zu konfigurieren? Bevor Sie auf „zweiten Prozessor hinzufügen” klicken, rechnen Sie es richtig durch
Berechnen Sie zuerst die Summe der vCPUs aller geplanten Maschinen und wählen Sie dann die physischen Kerne aus – die umgekehrte Reihenfolge endet mit Überdimensionierung oder Host-Überlastung.
- Konservativer Produktionsstart: CPU-Overcommit 1:1 bis 1:2 (vCPU : logischer Thread).
- Ein physischer Server-Prozessor 16c/32t liefert 32 logische Threads, die der Hypervisor auf VMs verteilt.
- Zu hoher Overcommit = wachsendes CPU Ready und wartende VMs auf Kernzugang.
- Neue VMs beginnen mit 1–2 vCPUs, erhöht wird erst nach Lastanalyse.
Klingt einfach, aber hier wird am häufigsten ein Fehler begangen. Das sieht man regelmäßig: Ein Unternehmen plant 15 VMs, jede bekommt „auf Vorrat” 4 vCPUs, weil „mehr besser ist”. Plötzlich sind es 60 vCPUs auf einem Host mit 16 Kernen. Der Hypervisor-Scheduler beginnt, Threads zu jonglieren, CPU Ready taucht auf, Anwendungen reagieren langsamer, und in vCenter sieht „scheinbar” alles gut aus. Virtualisierung mag keine Überallokation.
Eine gute Praxis ist Start small and scale up – also minimale Zuteilung, Monitoring und erst dann Korrektur. In vielen KMU-Umgebungen reicht 1 leistungsstarker CPU mit 12–16 Kernen bei vernünftiger Taktung problemlos für ein Dutzend leichte VMs. Ein zweiter Prozessor macht Sinn, wenn die Maschinenanzahl dynamisch wächst oder Lasten wie SQL, VDI oder Analysesysteme auftreten. Erst rechnen. Dann ausbauen.
Kerne vs. Taktung – warum „mehr” in einer VMware-Umgebung nicht immer „besser” bedeutet
In der Virtualisierung zählt die Balance zwischen Kernanzahl und Einzelkernleistung – allein die Kerndichte garantiert keine bessere VM-Performance.
- Hyper-Threading / SMT bewirkt, dass 1 Kern = 2 logische Threads ergibt, aber das verdoppelt nicht die Leistung.
- Zu viele langsame Kerne mit niedriger Taktung erhöhen die Arbeit des Schedulers.
- Eine VM mit 16–32 vCPUs kann langsamer laufen als dieselbe mit 4–8 vCPUs.
- Die Topologie „Sockets × Cores” ist wichtig bei NUMA und der CPU-Sicht des Gastsystems.
Das ist der Moment, in dem die Spezifikation nicht mehr offensichtlich ist. Ein Prozessor mit einer riesigen Anzahl von Kernen sieht beeindruckend aus, aber wenn die meisten Ihrer VMs Anwendungsserver, AD, Dateien oder Monitoring sind – ist oft eine stabile, höhere Einzelkerntaktung wichtiger. Virtualisierung verteilt die Last. Wenn eine Maschine viele Threads gleichzeitig synchronisieren muss, kann eine zu große vCPU-Zuteilung sie… verlangsamen, weil der Scheduler wartet, bis alle logischen Threads gleichzeitig frei sind.
Deshalb geht es bei der Leistungsplanung für VMware nicht um die „maximale Kernanzahl”. Es geht um die Anpassung der Kerne an das reale Lastprofil. Sonst fließt das Budget in CPUs, und die eigentliche Engstelle entpuppt sich trotzdem als RAM oder Storage. Aber das ist bereits ein ganz anderes Gespräch.
Server-Konfiguration für Virtualisierung: 128, 256 oder 512 GB RAM? Sehen Sie, wie viel Speicher ein Dutzend VMs wirklich „frisst”
In der Praxis ist RAM – nicht die CPU – am häufigsten der begrenzende Faktor für die Anzahl virtueller Maschinen auf einem Host.
- AD, DNS, kleine Dienste – 4–8 GB RAM.
- Dateiserver, Geschäftsanwendungen – 8–16 GB RAM.
- Kleines SQL / ERP – 16–32 GB RAM (mehr bei größeren Datenbanken).
- Der Hypervisor benötigt in der Regel 10–20 % RAM für sich selbst.
- Produktionsumgebungen streben 1,0–1,3× vRAM gegenüber dem physischen Speicher an.
Ein Host mit 128 GB RAM trägt problemlos ein Dutzend leichte VMs ohne aggressiven Overcommit. Bei 256 GB beginnt der Komfort – 20–40 Maschinen mit gemischtem Profil, unter Beibehaltung eines Sicherheitspuffers. 512 GB und mehr sind bereits dichte Umgebungen: VDI, mehrere Datenbanken, Berichtssysteme.
Speicher-Overcommit wird technisch unterstützt, aber wenn man es übertreibt, erscheinen Ballooning, Komprimierung und Swapping. Und Swapping in einer Produktionsumgebung bedeutet eines – Latenzspitzen bei Diensten. Deshalb halten sich erfahrene Administratoren bei kritischen Systemen in der Regel nahe am physischen Speicher, und Overcommit wird als Puffer, nicht als Fundament behandelt.
Kurz gesagt: Wenn Sie sich fragen, ob 128 GB ausreichen, beantworten Sie sich eine Frage – wie viel RAM verbrauchen Ihre VMs zur Spitzenzeit, nicht nachts. Dieser Wert sollte die Host-Konfiguration bestimmen. CPU können Sie noch „dehnen”. RAM nicht.
NVMe für den Datastore – wann wird Storage zum Engpass des gesamten Clusters?
Wenn VMs trotz freier CPU- und RAM-Kapazität langsamer reagieren, ist der Engpass fast immer der Storage – und bei vielen virtuellen Maschinen tötet ihn das zufällige I/O.
- NVMe PCIe 4.0/5.0 – bis zu 1 Mio.+ IOPS, Latenzen im Bereich von einigen Dutzend µs
- SSD SATA/SAS – in der Regel 100–200 Tsd. IOPS, Latenz in Hunderten von µs
- HDD 10K/15K – mehrere ms Latenz und ein Drama bei vielen gleichzeitigen Operationen
- 4–8 NVMe-Festplatten in RAID 10 als lokaler Datastore sind heute das vernünftige Minimum für die Produktion
- SDS (vSAN, Ceph) ermöglicht die Zusammenführung lokaler NVMe in einen leistungsstarken und redundanten Cluster
In einer Mehrmaschinen-Umgebung erzeugt jede VM ihre kleinen, verteilten Operationen – Logs, Indizes, Systemdateien, Snapshots, Backups. Das ist kein sequenzielles Kopieren großer Dateien. Das ist kontinuierlicher, zufälliger Datenverkehr. Und genau deshalb beginnen rotierende Festplatten, und sogar einige ältere SSDs, zu „würgen”.
In der Praxis liefert ein Satz von 4–8 NVMe in RAID 10 nicht nur enormen Durchsatz, sondern auch Stabilität bei Spitzen – Systemupdates, Snapshots, Backups oder dem Massenstart von VMs nach einem Host-Neustart. Bei kleinen 2–3-Knoten-Clustern bewährt sich das Modell lokale NVMe + Software-Defined Storage (vSAN / Ceph) sehr gut – man erhält sowohl die Leistung einer lokalen Festplatte als auch Redundanz zwischen den Hosts.
EPYC oder Xeon Gold? VM-Dichte vs. Single-Core-Leistung und Kompatibilität – wählen Sie bewusst
Die Wahl der Prozessorplattform entscheidet darüber, wie viele VMs wirklich auf einem Host Platz finden und wie die Kosten pro Kern oder Thread aussehen.
- Dell PowerEdge R7615 (1× AMD EPYC) – bis zu 128 Kerne pro Socket, DDR5 4800 MT/s, PCIe 5.0
- Dell PowerEdge R7625 (2× AMD EPYC) – noch höhere Dichte, sogar mehrere TB RAM, Ziel für VDI und große Cluster
- Xeon Gold – starke Single-Core-Performance, sehr ausgereiftes Ökosystem und Kompatibilität
- EPYC – mehr Speicherkanäle und PCIe-Lanes = höhere RAM- und Storage-Bandbreite
Wenn Ihr Ziel die maximale Anzahl von VMs auf einem Host und ein gutes TCO pro Thread ist, bieten EPYC in den Modellen R7615 / R7625 heute enorme Flexibilität. Hohe Kernanzahl, viele Speicherkanäle und modernes PCIe 5.0 ermöglichen eine dichte Umgebung ohne I/O-Engpässe.
Andererseits ist Xeon Gold immer noch eine sehr starke Option, wo Einzelkernleistung und breite Kompatibilität mit bestimmten Storage- oder HCI-Lösungen zählen. In manchen Anwendungsumgebungen liefert höhere Single-Core-Taktung bessere Ergebnisse als die bloße Kernanzahl.
Das ist keine „besser–schlechter”-Wahl. Das ist die Wahl: Bauen Sie einen Host für maximale VM-Dichte oder für ausgewogenere, klassische Lasten? Deshalb ist es sinnvoll, das CPU-Thema im Konfigurator zu verankern – den Unterschied bei Kernanzahl, RAM und NVMe bei einem konkreten Budget zu sehen.
Ein Host oder ein 2–3-Knoten-Cluster? Wenn Sie an HA denken, beginnen Sie mit dieser Entscheidung
Virtualisierung ohne Hochverfügbarkeit funktioniert – bis zum ersten schwerwiegenden Host-Ausfall.
- 2-Knoten-Cluster + Witness – Minimum für sinnvolles HA
- 3-Knoten-Cluster – vollständigere Redundanz und Servicekomfort
- Automatische VM-Migration (HA / Failover) bei Host-Verlust
- vSAN / Ceph / Storage Spaces Direct – Datenreplikation zwischen Knoten
- Möglichkeit geplanter Wartungsarbeiten ohne Ausfallzeiten
Ein einzelner Host ist günstiger und einfacher. Wenn jedoch auf diesen VMs Buchhaltung, ERP, CRM oder ein Produktionssystem läuft, ist ein einzelner Fehlerpunkt ein reales Ausfallrisiko. Ein 2-Knoten-Cluster mit zusätzlichem Witness ermöglicht bereits den Aufbau von grundlegendem HA – bei Ausfall eines Hosts starten die VMs auf dem zweiten.
Ein 3-Knoten-Cluster bietet mehr Flexibilität. Sie können einen Knoten für Wartungsarbeiten abschalten und trotzdem Redundanz beibehalten. Bei lokalen NVMe und SDS erhalten Sie Leistung und Ausfallsicherheit, ohne eine umfangreiche SAN-Infrastruktur aufbauen zu müssen.
Wenn Sie also Virtualisierung „ernsthaft” planen, lautet die Frage nicht, ob HA notwendig ist. Die Frage lautet: Welches Ausfallniveau können Sie akzeptieren? Von dieser Antwort beginnt die Architektur.
Überprüfen Sie Ihre Konfiguration in der Praxis!
Anstatt zu raten, wie viele Kerne und wie viele NVMe Sie brauchen, testen Sie verschiedene Varianten in unserem Server-Konfigurator.
Wählen Sie:
- die Plattform,
- Anzahl der Kerne und Threads,
- 128–512 GB RAM und mehr,
- NVMe-Konfiguration für den Datastore,
- Variante eines einzelnen Hosts oder eines 2–3-Knoten-Clusters.
In wenigen Minuten sehen Sie, wie sich Kosten und Skalierbarkeit bei verschiedenen Szenarien verändern. Wenn Sie nicht sicher sind – besser das Projekt vor der Implementierung überprüfen als nach der ersten Host-Überlastung.
FAQ
Reicht ein einzelner Host für ein kleines Unternehmen?
Ja, wenn Sie das Fehlen von HA akzeptieren. Bei kritischen Produktionssystemen wird mindestens ein 2-Knoten-Cluster empfohlen.
Kann man CPU stark overcommiten?
Technisch ja, aber für die Produktion empfiehlt sich 1:1–1:2, und der Faktor sollte erst nach dem Monitoring erhöht werden.
Begrenzt RAM oder CPU den Host schneller?
In den meisten KMU-Umgebungen ist RAM das erste Limit, nicht die CPU.
Ist NVMe für VMware notwendig?
Bei einem Dutzend und mehr VMs – praktisch ja. Zufälliges I/O legt schnell die Grenzen von HDDs und älteren SSDs offen.
EPYC oder Xeon Gold – was wählen?
Wenn Sie maximale VM-Dichte anstreben – EPYC. Wenn Kompatibilität und Single-Core wichtiger sind – Xeon Gold. Die Entscheidung hängt vom Lastprofil ab.
