Falsches Performance-Management: CPU-Affinität bremst die VM-Leistung

CPU-Affinität ist keine Performance-Garantie

In VMware-Umgebungen übernimmt der VMkernel das Scheduling der verschiedenen virtuellen CPUs (vCPU), die der VM auf Basis der wesentlich geringeren Anzahl physischer CPUs des ESXi-Servers zugewiesen werden. Dieser Vorgang ermöglicht die CPU-Mehrfachvergabe („overcommit“), die ein zentraler Bestandteil der Kosteneinsparungen darstellt, die durch Virtualisierung möglich werden.

Alle paar Millisekunden registriert der VMkernel, welche vCPUs gerade auf welchem CPU-Kern laufen und entscheidet dabei, ob hier Änderungen nötig sind. Da die Workloads der virtuellen Maschinen bei ihren Performance-Ansprüchen ihre eigenen Höhen und Tiefen haben, muss der VMkernel in der Lage sein, theoretisch jede vCPU auf jeden physischen Kern migrieren und betreiben zu können. Der VMkernel wird dabei stets versuchen, jeden physischen Kern so einzusetzen, dass alle VMs die CPU-Zeit erhalten, nach der sie verlangen.

Das große Missverständnis bei der CPU-Affinität besteht im Glauben, damit würde ein CPU-Kern exklusiv einer bestimmten virtuellen Maschine zugewiesen. Das ist auch der Grund, warum Administratoren für eine kritische VM mit hohen Performance-Ansprüchen fälschlicherweise CPU-Affinität konfigurieren würden. In den meisten Fällen dürfte dies jedoch zu einer geringeren VM-Performance führen!

CPU-Affinität garantiert keine physischen CPU-Kerne. Ganz im Gegenteil verweigert es der fraglichen VM alle anderen Kerne. Derzeit gibt es mit vSphere keine Möglichkeit, einer virtuellen Maschine einen CPU-Kern zu garantieren. Die einzige Garantie, die möglich ist, wäre die Reservierung. Eine Reservierung wiederum ist aber nichts anderes als die Garantie, dass eine Ressource frei gemacht wird und keine dedizierte Zuweisung dieser Ressource. 

Für eine VM mit kritischen CPU-Ansprüchen sollte daher eine Reservierung in ausreichend hohem Maße für das SLA der virtuellen Maschine konfiguriert werden. Die Zuweisung einer CPU-Affinität wird die CPU-Performance dieser virtuellen Maschine nicht erhöhen, im Gegenteil wird die Performance eher sinken.

Der eigentliche Vorteil der CPU-Affinität liegt darin, dem VMkernel beim CPU-Scheduling etwas von seiner Flexibilität zu nehmen. CPU-Affinität schränkt dabei die Auswahl möglicher Kerne ein, die für die vCPU einer VM genutzt werden können. Jedes Mal, wenn die Flexibilität des VMkernel begrenzt wird, wird aber auch die Effizienz und damit die Performance reduziert.

Auf einem ESXi-Server mit 12 Kernen gibt es 12 Möglichkeiten für den VMkernel, vCPUs zu platzieren. Wenn für eine VM die CPU-Affinität für die CPU-Kerne 2 und 3 konfiguriert wird, dann können die übrigen zehn Kerne von dieser VM nicht mehr genutzt werden. Selbst wenn diese zehn physischen CPU-Kerne also im Leerlauf arbeiten, wird sie der VMkernel für diese spezielle VM nicht verwenden können. 

Noch schlimmer ist es, wenn auf zwei sehr anspruchsvollen VMs die CPU-Affinität für die gleichen beiden Kerne eingestellt wird. In diesem Fall müssten die beiden virtuellen Maschinen um die gleichen CPU-Kerne konkurrieren, obwohl die übrigen zehn Kerne nichts zu tun haben.

Beispiel für das Setzen der CPU-Affinität für die Kerne 2 und 3

Zusätzliche Probleme bei der Verwendung der CPU-Affinität

Ein weiteres Problem bei der Verwendung der CPU-Affinität besteht darin, dass sie vMotion deaktiviert. CPU-Affinität schreibt ja die Nutzung spezifischer CPU-Kerne eines ESXi-Servers vor, und da diese physischen Kerne natürlich nicht zwischen Hosts migriert werden können, trifft dies auch nicht mehr auf die virtuelle Maschine zu. 

Dies kann enorme Auswirkungen in Umgebungen mit DRS-Clustern (Distributed Resource Scheduler) haben. Hier werden normalerweise mit vCenter virtuelle Maschine über vMotion zwischen ESXi-Servern hin und her bewegt, um die beste Performance zu erhalten.

Sobald sich in so einem DRS-Cluster VMs befinden, die nicht per vMotion verschoben werden können, droht der gesamte Cluster in ein Performance-Ungleichgewicht zu fallen. Die VM-Migration mit vMotion gehört zudem zu den Voraussetzungen bei der Serverwartung, daher führen VMs, die nicht migriert werden können, auch hier zu zusätzlichen Problemen. 

Noch viel schlimmer ist es, wenn ein DRS-Cluster in den automatischen Modus geschaltet wird, da hier die Optionen zur CPU-Affinität nicht mehr angezeigt werden. Die Einstellungen zur CPU-Affinität sind dann zwar noch vorhanden, können aber mit Standardmitteln nicht mehr rückgängig gemacht werden.

Sobald die CPU-Affinität konfiguriert ist, kann diese Einstellung nicht mehr rückgängig gemacht werden, wenn der DRS-Cluster in den automatischen Modus geschaltet wird.

Immerhin verhindert die CPU-Affinität nicht den HA-Failover (VMware High Availability). In diesem Fall würde eine virtuelle Maschine auf einem anderen Host im HA-Cluster neu gestartet werden und ihre Einstellungen zur CPU-Affinität auch hier behalten.

Wofür benötigt man dann die CPU-Affinität?

Bei all den Nachteilen fragt man sich natürlich, wofür die CPU-Affinität dann eigentlich benötigt wird. Man kann CPU-Affinität zum Beispiel dafür nutzen, künstlich CPU-Flaschenhälse zu erzeugen. Wenn man zwei VMs per CPU-Affinität auf den gleichen Kern legt, können diese Performance-Engpässe auf dem Kern erzeugen, ohne den gesamten ESXi-Server zu beeinträchtigen. Das mag kein Nutzen für den Produktivbetrieb sein, ist aber ein interessantes Anwendungsszenario für Testumgebungen.

In Produktivumgebungen gibt es tatsächlich recht wenig praktische Anwendungsfälle. Möglich wäre aber zum Beispiel, dass eine alte Anwendung über eine virtuelle Maschine betrieben wird und die Anwendung über die Seriennummer des CPU-Kerns lizenziert wird, auf dem sie läuft. In diesem Fall ließe sich die Anwendung nur dann ordnungsgemäß in einer virtuellen Umgebung ausführen, wenn der virtuellen Maschine ein spezifischer Kern zugewiesen wird.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+ und Facebook!