> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/knowledge-base/de/system-administration/cpu-overprovisioning-guide.md). # CPU-Überprovisionierung und Ressourcenplanung ## Ü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 {% hint style="warning" %} **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 {% endhint %} ## 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 | {% hint style="success" %} **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. {% endhint %} ## 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 1. **Hohe CPU-Ready-Zeit:** VMs, die auf verfügbare physische CPU warten 2. **Inkonsistente Leistung:** Anwendungen, die manchmal gut und manchmal schlecht laufen 3. **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 {% hint style="warning" %} **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. {% endhint %} ## Bewährte Verfahren ### Allgemeine Richtlinien 1. **Vor der Zuweisung überwachen:** Verstehen Sie die tatsächlichen CPU-Nutzungsmuster, bevor Sie Kapazität hinzufügen 2. **VMs angemessen dimensionieren:** Beginnen Sie mit weniger vCPUs und erhöhen Sie sie bei Bedarf 3. **Reserve einplanen:** Halten Sie 20–30 % Kapazität für Spitzen und Failover frei 4. **CPU-Grenzwerte sparsam verwenden:** Sie verhindern, dass VMs verfügbare Leerlaufressourcen nutzen ### Cluster-Design 1. **Einheitliche Knotengröße:** Vereinfacht die Kapazitätsplanung 2. **Für N+1 planen:** Gehen Sie immer davon aus, dass ein Knoten nicht verfügbar sein wird 3. **Annahmen dokumentieren:** Halten Sie Ihre Overcommit-Ziele und die Gründe dafür fest ### VM-Konfiguration 1. **vCPUs an den Workload anpassen:** Mehr vCPUs bedeuten nicht immer bessere Leistung 2. **NUMA berücksichtigen:** Halten Sie bei großen VMs die vCPU-Anzahl innerhalb der Grenzen eines NUMA-Knotens 3. **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 1. Navigieren Sie zu **Infrastruktur** > **Cluster** 2. CPU-Auslastungsgrafiken anzeigen 3. Klicken Sie auf einzelne Knoten, um Knotenmetriken anzuzeigen 4. Prüfen Sie die CPU-Statistiken der VM im Dashboard jeder VM Weitere Details zur Cluster-Überwachung finden Sie unter [Cluster-Übersicht](/run-the-platform/system-administration/clusters-overview.md). ## 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. ## Verwandte Themen * [Cluster-Übersicht](/run-the-platform/system-administration/clusters-overview.md) - Cluster-Architektur verstehen * [Cluster-Konfigurationsoptionen](/run-the-platform/system-administration/cluster-settings.md) - Alle Cluster-Einstellungen erklärt * [Best Practices für VMs](/run-the-platform/virtual-machines/vm-best-practices.md) - Empfehlungen für die VM-Konfiguration * [Virtuelle Maschinen erstellen](/run-the-platform/virtual-machines/creating-vms.md) - Anleitung zum Erstellen von VMs * [Live-Migrationen](/run-the-platform/virtual-machines/live-migrations.md) - VMs zwischen Knoten verschieben --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.verge.io/knowledge-base/de/system-administration/cpu-overprovisioning-guide.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.