Leistungs-Rätsel gelöst: Der Unterschied zwischen der Anzahl der virtuellen Sockets und Kerne pro Socket

In der Welt der Virtualisierung gibt es kaum ein Thema, das so viele Administratoren ins Grübeln bringt wie die korrekte Konfiguration von virtuellen CPU-Ressourcen. Insbesondere die Wahl zwischen der Anzahl der virtuellen Sockets und den Kernen pro Socket stellt eine scheinbar simple Entscheidung dar, die jedoch tiefgreifende Auswirkungen auf die Performance, die Stabilität und nicht zuletzt die Lizenzkosten Ihrer virtuellen Maschinen haben kann. Was auf den ersten Blick wie eine rein administrative Einstellung aussieht, entpuppt sich bei näherer Betrachtung als ein komplexes Zusammenspiel aus physischer Hardware-Topologie, Hypervisor-Scheduling und Software-Lizenzmodellen. Wir tauchen heute tief in dieses Thema ein, lüften das Geheimnis und zeigen Ihnen, wie Sie die optimale Konfiguration für Ihre Workloads finden.

Die Grundlagen verstehen: CPUs in der physischen und virtuellen Welt

Bevor wir uns den Feinheiten der virtuellen Konfiguration widmen, ist es entscheidend, die grundlegenden Konzepte der CPU-Architektur zu verstehen. Eine physische CPU, oft als Prozessor bezeichnet, ist der „Motor” Ihres Servers. Sie besteht aus mehreren Komponenten, die ihre Leistung bestimmen:

• Physische Sockets: Dies sind die Steckplätze auf dem Motherboard, in die die CPU-Pakete eingesetzt werden. Ein Server kann ein oder mehrere physische Sockets haben. Jeder Socket beherbergt einen vollständigen Prozessorchip.
• Physische Kerne (Cores): Innerhalb jedes physischen CPU-Chips befinden sich ein oder mehrere Kerne. Jeder Kern ist eine unabhängige Verarbeitungseinheit, die Anweisungen ausführen kann. Moderne CPUs haben oft 8, 16, 32 oder noch mehr Kerne pro Socket.
• Threads (logische Prozessoren): Viele moderne CPUs unterstützen Technologien wie Intel Hyper-Threading oder AMD Simultaneous Multi-threading (SMT). Hierbei kann jeder physische Kern bis zu zwei (oder mehr) logische Threads gleichzeitig verarbeiten. Dies bedeutet, dass ein physischer Kern dem Betriebssystem als zwei logische Prozessoren erscheint, was die Auslastung der Kernressourcen optimieren kann, aber nicht die Leistung eines echten zusätzlichen Kerns bietet.

Ein Hypervisor (wie VMware vSphere, Microsoft Hyper-V oder KVM) ist die Software, die die physischen Ressourcen des Servers – einschließlich der CPUs – abstrahiert und sie den virtuellen Maschinen (VMs) zur Verfügung stellt. Jede VM erhält dabei virtuelle CPUs (vCPUs), die vom Hypervisor auf die physischen CPU-Ressourcen des Hosts abgebildet werden.

Virtuelle Sockets und Kerne pro Socket: Die Konfigurationsoptionen

Wenn Sie eine neue VM erstellen oder eine bestehende konfigurieren, sehen Sie typischerweise zwei Einstellungen für die CPU-Ressourcen:

• Anzahl der virtuellen Sockets: Diese Einstellung bestimmt, wie viele separate „Prozessor”-Pakete der VM vom Hypervisor präsentiert werden. Für das Gast-Betriebssystem sieht es so aus, als hätte es einen Server mit dieser Anzahl von physischen CPUs.
• Anzahl der Kerne pro Socket: Diese Einstellung bestimmt, wie viele virtuelle Kerne jeder der virtuellen Sockets hat.

Die Gesamtanzahl der vCPUs, die der VM zugewiesen werden, ergibt sich immer aus der Multiplikation dieser beiden Werte (Virtuelle Sockets * Kerne pro Socket = Gesamt-vCPUs). Wenn Sie einer VM beispielsweise 8 vCPUs zuweisen möchten, könnten Sie dies auf verschiedene Weisen tun:

• 1 virtueller Socket mit 8 Kernen pro Socket
• 2 virtuelle Sockets mit 4 Kernen pro Socket
• 4 virtuelle Sockets mit 2 Kernen pro Socket
• 8 virtuelle Sockets mit 1 Kern pro Socket

Obwohl die Gesamtanzahl der vCPUs in all diesen Szenarien gleich ist, kann die Wahl der Konfiguration einen erheblichen Unterschied in der Leistung und im Verhalten des Gast-Betriebssystems ausmachen. Und genau hier liegt das „Rätsel”.

Der Einfluss auf die Performance: NUMA ist der Schlüssel

Der wohl wichtigste technische Faktor, der die Leistung beeinflusst, ist die NUMA-Architektur (Non-Uniform Memory Access). Moderne Multiprozessor-Server sind fast immer NUMA-Systeme. Das bedeutet:

• Jeder physische CPU-Socket hat seinen eigenen direkten Zugriff auf einen bestimmten Speicherbereich (seinen „lokalen” Speicher).
• Der Zugriff auf den Speicherbereich eines *anderen* Sockets (den „fremden” Speicher) ist langsamer, da die Daten über eine Interconnect-Verbindung (z.B. Intel UPI, AMD Infinity Fabric) transportiert werden müssen.

Ein Hypervisor versucht, die vCPUs und den Speicher einer VM so weit wie möglich innerhalb eines einzelnen physischen NUMA-Knotens zu halten. Wenn eine VM zu viele vCPUs oder zu viel Speicher benötigt, um in einen einzelnen physischen NUMA-Knoten zu passen, muss der Hypervisor die Ressourcen über mehrere NUMA-Knoten verteilen. Dies ist unvermeidlich, aber die Art und Weise, wie die vCPUs konfiguriert sind, kann die Auswirkungen auf die Leistung mildern oder verschärfen.

Wie die vCPU-Konfiguration NUMA beeinflusst:

Das Gast-Betriebssystem ist sich der von ihm genutzten virtuellen CPU-Topologie bewusst. Es erwartet, dass alle Kerne innerhalb eines virtuellen Sockets in Bezug auf den Speicherzugriff „nahe” beieinander liegen. Wenn Sie einer VM mehrere virtuelle Sockets zuweisen, interpretiert das Gast-OS dies als einen Multiprozessor-Server mit mehreren physischen CPUs – und versucht möglicherweise, seine eigenen NUMA-Optimierungen auf dieser *virtuellen* Topologie anzuwenden.

• Optimales Szenario (NUMA-Alignment): Wenn Sie weniger virtuelle Sockets mit mehr Kernen pro Socket konfigurieren (z.B. 1 virtueller Socket mit 8 Kernen), ist die Wahrscheinlichkeit höher, dass der Hypervisor alle vCPUs und den zugewiesenen Speicher der VM innerhalb eines einzigen physischen NUMA-Knotens des Host-Servers zuweisen kann. Dies führt zu einer optimalen Speicherzugriffsgeschwindigkeit für die VM, da alle vCPUs nur auf „lokalen” Speicher zugreifen müssen. Das Gast-Betriebssystem sieht nur einen „Prozessor” mit vielen Kernen und hat daher keine Gründe, interne NUMA-Optimierungen zu versuchen, die möglicherweise nicht mit der physischen NUMA-Topologie übereinstimmen.
• Suboptimales Szenario (NUMA-Unalignment/Fehlzuordnung): Wenn Sie mehrere virtuelle Sockets mit weniger Kernen pro Socket konfigurieren (z.B. 4 virtuelle Sockets mit 2 Kernen pro Socket), und diese virtuellen Sockets vom Hypervisor über physische NUMA-Knoten des Hosts verteilt werden müssen, kann dies zu Leistungsproblemen führen. Das Gast-Betriebssystem glaubt, es hätte mehrere „physische” CPUs, und könnte versuchen, seine Workloads und Speicherzuweisungen entsprechend zu optimieren – basierend auf der virtuellen NUMA-Topologie. Diese Optimierungen könnten jedoch nicht mit der tatsächlichen physischen NUMA-Topologie des Host-Servers übereinstimmen. Dies kann dazu führen, dass vCPUs auf „fremden” Speicher zugreifen müssen, was die Latenz erhöht und die Leistung beeinträchtigt. Der Hypervisor muss dann zusätzliche Anstrengungen unternehmen, um die vCPUs über die physischen NUMA-Knoten zu migrieren oder Speicherzugriffe über die Interconnects zu leiten, was den Overhead erhöht.

Kurz gesagt: Ziel ist es, die virtuelle NUMA-Topologie der VM so gut wie möglich an die physische NUMA-Topologie des Hosts anzupassen. Dies gelingt am besten, indem man die Anzahl der virtuellen Sockets minimiert und die Kerne pro Socket maximiert, solange die Gesamtanzahl der vCPUs in einen einzelnen physischen NUMA-Knoten des Hosts passt.

Weitere Performance-Faktoren

• Hypervisor-Scheduling: Jeder vCPU, den Sie einer VM zuweisen, muss vom Hypervisor auf einen verfügbaren physischen Kern des Hosts geplant werden. Bei zu vielen vCPUs oder einer ungünstigen Konfiguration kann das Scheduling komplexer werden und zu Verzögerungen (CPU Ready Time) führen. Das Gast-Betriebssystem versucht, Threads auf Kerne innerhalb desselben Sockets zu verteilen. Wenn ein virtueller Socket über physische NUMA-Knoten hinweggeht, können diese Scheduling-Entscheidungen des Gastes ineffizient sein.
• Anwendungs- und Workload-Spezifika: Einige Anwendungen sind sehr empfindlich gegenüber der CPU-Topologie. Datenbanken, High-Performance-Computing (HPC)-Anwendungen oder spezielle Enterprise-Software können von einer optimalen NUMA-Ausrichtung erheblich profitieren. Wenn eine Anwendung explizit für Multiprozessor-Systeme optimiert ist und die NUMA-Topologie ausnutzt, sollten Sie versuchen, die virtuelle Topologie so darzustellen, dass sie eine effiziente Nutzung ermöglicht, idealerweise innerhalb eines physischen NUMA-Knotens.
• Betriebssystem-Overhead: Das Gast-Betriebssystem selbst hat einen geringen Overhead für die Verwaltung jeder virtuellen CPU und jedes Sockets. Eine unnötig komplexe virtuelle Topologie kann diesen Overhead marginal erhöhen.

Der Einfluss auf die Lizenzierung: Eine Kostenfrage

Neben technischen Performance-Aspekten spielt die Lizenzierung eine oft noch entscheidendere Rolle bei der Wahl der vCPU-Konfiguration. Viele Software-Anbieter basieren ihre Lizenzmodelle auf der Anzahl der physischen Sockets oder der physischen Kerne. In einer virtualisierten Umgebung kann dies bedeuten:

• Socket-basierte Lizenzierung: Viele ältere Lizenzmodelle (und einige neue, z.B. bestimmte Oracle-Produkte oder ältere Microsoft SQL Server Editionen) basieren auf der Anzahl der physischen Sockets, die von einer Software verwendet werden. Wenn Sie einer VM zwei virtuelle Sockets zuweisen, wird dies von der Software möglicherweise als „zwei physische CPUs” interpretiert, auch wenn sie nur wenige Kerne pro Socket hat. Dies kann die Lizenzkosten erheblich in die Höhe treiben. In solchen Fällen ist es oft finanziell vorteilhafter, einen virtuellen Socket mit vielen Kernen pro Socket zu konfigurieren, um die Lizenzkosten zu minimieren, auch wenn dies möglicherweise nicht die technisch ideale NUMA-Optimierung darstellt (solange die Gesamt-vCPUs immer noch innerhalb eines physischen NUMA-Knotens bleiben).
• Core-basierte Lizenzierung: Immer mehr Software-Anbieter (z.B. Microsoft Windows Server, SQL Server (neuere Editionen), VMware vSphere) sind auf Core-basierte Lizenzmodelle umgestiegen. Hier spielt die Anzahl der virtuellen Sockets keine direkte Rolle mehr für die Lizenzkosten, da nur die Gesamtanzahl der zugewiesenen vCPUs zählt. In diesem Szenario können Sie sich primär auf die Performance-Optimierung (NUMA) konzentrieren.

Es ist absolut entscheidend, die Lizenzbedingungen der Software, die Sie auf Ihren VMs ausführen möchten, genau zu prüfen. Eine Fehlkonfiguration kann nicht nur zu Performance-Engpässen, sondern auch zu unerwartet hohen Lizenzkosten oder Compliance-Problemen führen.

Best Practices und Empfehlungen

Die „richtige” Konfiguration ist keine Einheitslösung, sondern ein Kompromiss, der von Ihren spezifischen Anforderungen abhängt. Hier sind einige Best Practices:

1. Priorisieren Sie NUMA-Optimierung (wenn die Lizenzierung es zulässt): Versuchen Sie, die Anzahl der virtuellen Sockets zu minimieren und die Kerne pro Socket zu maximieren. Ziel ist es, die Gesamtanzahl der vCPUs der VM innerhalb der Kapazität eines einzelnen physischen NUMA-Knotens des Host-Servers zu halten. Wenn Ihr Host z.B. zwei Sockets mit je 16 Kernen hat, ist jeder Socket ein NUMA-Knoten. Versuchen Sie, einer VM nicht mehr als 16 vCPUs (als 1 Socket mit 16 Kernen) zuzuweisen, wenn sie auf diesem Host läuft.
2. Berücksichtigen Sie die Software-Lizenzierung zuerst: Falls Ihre kritischen Anwendungen socket-basiert lizenziert sind, kann dies die wichtigste Stellschraube sein. Minimieren Sie die Anzahl der virtuellen Sockets, auch wenn dies bedeutet, dass Sie mehr Kerne pro Socket zuweisen, als in einem physischen NUMA-Knoten verfügbar sind. Hier müssen Sie eine bewusste Abwägung zwischen Lizenzkosten und potenziellen Performance-Einbußen treffen. Eine vorherige Performance-Messung ist hier unabdingbar.
3. Verstehen Sie Ihre Workloads: Eine Datenbank, die viele gleichzeitige Abfragen verarbeitet, profitiert stark von optimaler NUMA-Ausrichtung. Ein einfacher Webserver hingegen ist möglicherweise weniger empfindlich. Analysieren Sie die CPU-Auslastung und das Verhalten Ihrer Anwendungen.
4. Überprovisionierung vermeiden: Weisen Sie VMs nicht mehr vCPUs zu, als sie tatsächlich benötigen. Zu viele vCPUs für eine VM können das Hypervisor-Scheduling erschweren und die Leistung anderer VMs auf demselben Host beeinträchtigen, selbst wenn die VM nicht alle vCPUs auslastet. Starten Sie mit der kleinstmöglichen Anzahl und erhöhen Sie diese bei Bedarf.
5. Monitoring ist der Schlüssel: Überwachen Sie die Performance Ihrer VMs genau. Achten Sie auf Metriken wie „CPU Ready Time” (VMware) oder „Run Queue Length” (Hyper-V), die auf CPU-Ressourcenengpässe hindeuten. Nutzen Sie auch Host-spezifische NUMA-Statistiken, um eine Fehlzuordnung zu erkennen.
6. Informieren Sie sich über die Hypervisor-Einstellungen: Moderne Hypervisoren bieten oft erweiterte NUMA-Einstellungen (z.B. vNUMA bei VMware vSphere), die automatisch versuchen, die optimale Topologie für die VM zu präsentieren. Es ist jedoch wichtig zu verstehen, wie diese funktionieren und ob sie manuell angepasst werden müssen.

Praxisbeispiele und Szenarien

• Szenario 1: Datenbankserver mit hohen Anforderungen und Core-basierter Lizenzierung.

  Ein Server hat 2 physische Sockets mit je 16 Kernen (32 Kerne gesamt). Eine VM benötigt 12 vCPUs und ist mit einer Core-basierten Lizenz ausgestattet.
  Empfehlung: 1 virtueller Socket mit 12 Kernen pro Socket. Dies hält die vCPUs innerhalb eines physischen NUMA-Knotens (12 von 16 Kernen), optimiert die Speicherzugriffszeiten und das Gast-OS sieht eine optimierte Topologie.

• Szenario 2: Altes ERP-System mit Socket-basierter Lizenzierung.

  Ein Server hat 2 physische Sockets mit je 16 Kernen. Eine VM benötigt 4 vCPUs, um gut zu laufen, aber die verwendete ERP-Software ist pro physischem Socket lizenziert.
  Empfehlung: 1 virtueller Socket mit 4 Kernen pro Socket. Dies minimiert die Lizenzkosten auf „1 Socket” und ist gleichzeitig optimal für die NUMA-Ausrichtung, da 4 vCPUs leicht in einen physischen NUMA-Knoten passen.

• Szenario 3: Große In-Memory-Datenbank mit 24 vCPUs auf einem Host mit 2×16 Kernen.

  Hier übersteigt die Anforderung von 24 vCPUs die Kapazität eines einzelnen physischen NUMA-Knotens (16 Kerne).
  Empfehlung: 2 virtuelle Sockets mit 12 Kernen pro Socket. Der Hypervisor kann die 2 virtuellen Sockets dann jeweils einem physischen NUMA-Knoten zuweisen, was die virtuellen und physischen Topologien gut miteinander in Einklang bringt. Das Gast-Betriebssystem sieht zwei „Prozessoren” und kann seine NUMA-Optimierungen auf dieser Basis durchführen.

Fazit: Das Rätsel ist gelöst – es ist ein Balanceakt

Das „Leistungs-Rätsel” der virtuellen Sockets und Kerne pro Socket ist kein Mysterium mehr, sondern ein komplexes Zusammenspiel aus technischen Notwendigkeiten und wirtschaftlichen Realitäten. Es gibt keine universelle „beste” Konfiguration, sondern immer eine Entscheidung, die auf den spezifischen Anforderungen Ihrer Anwendung, der Lizenzierungslogik der Software und der physischen Hardware-Topologie Ihres Host-Servers basiert.

Indem Sie die Prinzipien der NUMA-Architektur verstehen und die Auswirkungen Ihrer Konfiguration auf Software-Lizenzmodelle berücksichtigen, können Sie fundierte Entscheidungen treffen, die sowohl die Performance Ihrer virtuellen Maschinen maximieren als auch unnötige Kosten vermeiden. Kontinuierliches Monitoring und eine iterative Anpassung Ihrer vCPU-Einstellungen sind der Schlüssel zu einer optimierten, effizienten und kostengünstigen Virtualisierungsumgebung. Das Rätsel ist gelöst: Es geht darum, die richtige Balance zu finden.