CPU-Überprovisionierung und Ressourcenplanung

Verständnis von CPU-Zuweisung, Überbelegungsquoten und Leistungsfolgen in VergeOS, einschließlich empfohlener Quoten nach Workload-Typ und Berechnungen zur Kapazitätsplanung.

Überblick

CPU-Überprovisionierung (auch Overcommit genannt) ermöglicht es Ihnen, Workloads mehr virtuelle CPU-Kerne zuzuweisen, als physische Kerne verfügbar sind. Dieser Leitfaden erklärt, wie VergeOS CPU-Ressourcen verwaltet, welche Auswirkungen Overprovisionierung hat und welche Best Practices es für die Kapazitätsplanung gibt.

Wie die CPU-Zuweisung in VergeOS funktioniert

Virtuelle vs. physische Kerne

Wenn Sie einer VM vCPUs zuweisen, weisen Sie virtuelle Kerne zu, die auf physische CPU-Kerne eingeplant werden. VergeOS reserviert physische Kerne nicht exklusiv für VMs – stattdessen nutzt es Time-Slicing, um physische Ressourcen gemeinsam zu teilen.

Wichtige Punkte:

vCPUs sind standardmäßig nicht an physische Kerne gebunden
Mehrere vCPUs aus verschiedenen VMs können sich denselben physischen Kern teilen
Der Hypervisor-Scheduler verwaltet die Zuweisung der CPU-Zeit

Die Einstellung „Max. Kerne pro Maschine“

Diese Cluster-Einstellung steuert die maximale Anzahl an CPU-Kernen, die einem einzelnen Workload (VM, Tenant-Knoten oder NAS-Dienst) zugewiesen werden können.

Ort: Infrastruktur > Cluster > [Clustername] > Bearbeiten

Kritische Beschränkungen

Dieser Wert sollte niemals überschreiten die gesamten physischen Kerne Ihres kleinsten Knotens
In den meisten Fällen sollte er innerhalb eines einzelnen CPU-Sockets für optimale NUMA-Leistung
VMs, die diesen Grenzwert nach einer Änderung überschreiten, können nicht migrieren bis die Kernanzahl reduziert wird

CPU-Overcommit-Verhältnisse

Was ist ein Overcommit-Verhältnis?

Das Verhältnis der insgesamt zugewiesenen vCPUs zu den gesamten physischen Kernen:

Overcommit-Verhältnis = Insgesamt zugewiesene vCPUs / Gesamte physische Kerne

Beispiel: Ein 2-Knoten-Cluster mit jeweils 32 Kernen (insgesamt 64), auf dem VMs mit insgesamt 96 vCPUs laufen, hat ein Overcommit-Verhältnis von 1,5:1.

Empfohlene Verhältnisse nach Workload-Typ

Workload-Typ

Verhältnis

Hinweise

Leichte/Büro-Workloads

4:1 bis 6:1

Desktop-VMs, Dateiserver

Gemischte Allzweck-Workloads

2:1 bis 4:1

Typische Unternehmensmischung

Datenbank-/Anwendungsserver

1:1 bis 2:1

Leistungssensibel

Hochleistungsrechnen

1:1 oder weniger

CPU-intensive Workloads

Konservativ beginnen

Beginnen Sie mit niedrigeren Verhältnissen und erhöhen Sie diese auf Grundlage des Monitorings. Es ist einfacher, Kapazität hinzuzufügen, als sich von schlechter Leistung zu erholen.

Auswirkungen auf die Leistung

Wann Overcommit gut funktioniert

Spitzenlast-Workloads: VMs mit gelegentlichen CPU-Spitzen, die aber meist im Leerlauf sind
Unterschiedliche Zeitpunkte: Workloads, die zu unterschiedlichen Zeiten Spitzenwerte erreichen
I/O-gebundene Anwendungen: VMs, die eher auf Festplatte oder Netzwerk als auf die CPU warten

Wann Overcommit Probleme verursacht

CPU-intensive Workloads: Anwendungen, die ständig 100 % CPU verwenden
Latenzsensitive Anwendungen: Echtzeitsysteme, VoIP, Handel
Gleichzeitiger Bedarf: Alle VMs, die gleichzeitig CPU benötigen

Anzeichen für zu starkes Overcommitment

Hohe CPU-Ready-Zeit: VMs, die auf verfügbare physische CPU warten
Inkonsistente Leistung: Anwendungen, die manchmal gut und manchmal schlecht laufen
Gastbetriebssystem zeigt hohe CPU-Auslastung: Aber der Hypervisor zeigt eine geringere Auslastung

Kapazitätsplanung

Berechnung der verfügbaren CPU-Kapazität

Für einen Cluster mit N+1-Redundanz:

Verfügbare Kerne = (Knoten - 1) × Kerne pro Knoten
Nutzbare vCPUs = Verfügbare Kerne × Ziel-Overcommit-Verhältnis

Beispiel: 4-Knoten-Cluster, jeweils 32 Kerne, Zielverhältnis 2:1

Verfügbar: (4-1) × 32 = 96 Kerne
Nutzbare vCPUs: 96 × 2 = 192 vCPUs

Überlegungen zur Migration

Wenn ein Knoten ausfällt oder in den Wartungsmodus wechselt:

Alle VMs müssen auf die verbleibenden Knoten passen
Jede VM muss innerhalb der Einstellung „Max. Kerne pro Maschine“ passen
VMs mit vielen vCPUs können hängen bleiben, wenn kein einzelner Knoten sie aufnehmen kann

Migrationsbereitschaft

Wenn eine VM 64 vCPUs hat, Ihre Knoten aber nur 32 Kerne, dann kann diese VM können nicht migrieren während Wartungs- oder Ausfallszenarien nicht migriert werden. Halten Sie die Kernanzahl von VMs innerhalb der Kapazität eines einzelnen Knotens.

Bewährte Verfahren

Allgemeine Richtlinien

Vor der Zuweisung überwachen: Verstehen Sie die tatsächlichen CPU-Nutzungsmuster, bevor Sie Kapazität hinzufügen
VMs angemessen dimensionieren: Beginnen Sie mit weniger vCPUs und erhöhen Sie sie bei Bedarf
Reserve einplanen: Halten Sie 20–30 % Kapazität für Spitzen und Failover frei
CPU-Grenzwerte sparsam verwenden: Sie verhindern, dass VMs verfügbare Leerlaufressourcen nutzen

Cluster-Design

Einheitliche Knotengröße: Vereinfacht die Kapazitätsplanung
Für N+1 planen: Gehen Sie immer davon aus, dass ein Knoten nicht verfügbar sein wird
Annahmen dokumentieren: Halten Sie Ihre Overcommit-Ziele und die Gründe dafür fest

VM-Konfiguration

vCPUs an den Workload anpassen: Mehr vCPUs bedeuten nicht immer bessere Leistung
NUMA berücksichtigen: Halten Sie bei großen VMs die vCPU-Anzahl innerhalb der Grenzen eines NUMA-Knotens
Leistung testen: Führen Sie Benchmarks mit realistischen Workloads durch

CPU-Gesundheit überwachen

Wichtige Metriken, auf die Sie achten sollten

Metrik

Gesunder Bereich

Maßnahme bei Überschreitung

Cluster-CPU-Auslastung

< 70 % im Durchschnitt

Knoten hinzufügen oder VMs reduzieren

Knoten-CPU-Auslastung

< 80 % dauerhaft

VM-Verteilung prüfen

CPU einzelner VMs

Variiert je nach Workload

Richtig dimensionieren oder untersuchen

Verwendung des VergeOS-Dashboards

Navigieren Sie zu Infrastruktur > Cluster
CPU-Auslastungsgrafiken anzeigen
Klicken Sie auf einzelne Knoten, um Knotenmetriken anzuzeigen
Prüfen Sie die CPU-Statistiken der VM im Dashboard jeder VM

Weitere Details zur Cluster-Überwachung finden Sie unter Cluster-Übersicht.

FAQ

Kann ich einer einzelnen VM mehr vCPUs als physische Kerne zuweisen?

Ja, aber das bringt selten Vorteile. Eine VM mit mehr vCPUs als physische Kerne auf einem Knoten kann Verzögerungen bei der Planung erfahren, weil der Hypervisor wartet, bis gleichzeitig genügend Kerne verfügbar sind.

Unterstützt VergeOS CPU-Pinning?

VergeOS unterstützt kein CPU-Pinning (Affinity). Intern verwendet VergeOS den Linux Completely Fair Scheduler (CFS) für die CPU-Planung. Jede vCPU wird einem Linux-Prozess/-Thread zugeordnet, und alle vCPU-Threads teilen sich dieselbe CFS-Run-Queue. Der Scheduler verwendet eine globale Fairness-Logik, um zu bestimmen, welcher Prozess wann CPU-Zeit erhält.

Dieses Design sorgt für eine optimale Ressourcennutzung und erhält die Mobilität von VMs für Live-Migration und Failover. Wenn Sie CPU-Ressourcen überbuchen, teilen Sie diesen Pool physischer Kerne mit anderen VMs und Mandanten.

Wie wirkt sich das auf Software-Lizenzen aus?

Einige Softwareprodukte (Oracle, SQL Server) werden pro physischem Kern oder Socket lizenziert. Die dynamische Planung von VergeOS bedeutet, dass Sie CPU-Ressourcen nicht „hart partitionieren“ können. Informieren Sie sich über die Virtualisierungs-Lizenzbedingungen Ihres Softwareanbieters – viele bieten Lizenzmodelle pro vCPU oder pro VM an, die mit modernen Hypervisors besser funktionieren.

Und NUMA?

Bei VMs mit vielen vCPUs versucht VergeOS, Speicher- und CPU-Zuweisungen nach Möglichkeit innerhalb desselben NUMA-Knotens zu halten. Für beste NUMA-Leistung sollten die vCPU-Anzahlen von VMs die Kernanzahl eines einzelnen Sockets nicht überschreiten.