Einführung

Proxmox Virtual Environment (VE) ist eine leistungsstarke Open-Source-Plattform für die Virtualisierung in Unternehmen. Sie unterstützt erweiterte Funktionen für die dynamische Speicherverwaltung, darunter Kernel Samepage Merging (KSM) und Memory Ballooning, mit denen sich die Speichernutzung optimieren und die Leistung verbessern lässt. In diesem Blogbeitrag wird die Effektivität der KSM- und Memory-Ballooning-Funktionen in Proxmox VE anhand von Linux-Virtual Machines (VMs) bewertet. Wir richten eine VM mit Proxmox VE für eine Testumgebung ein, führen Tests durch und analysieren die Ergebnisse, um zu verstehen, wie diese Funktionen virtualisierten Umgebungen zugute kommen können. Darüber hinaus werden wir uns mit den Sicherheitsbedenken bei der Aktivierung von KSM und den Risiken im Zusammenhang mit der Verwendung von Ballooning befassen, insbesondere in Datenbankumgebungen.

Was ist KSM?

Kernel Samepage Merging (KSM) ist eine Funktion zur Speicherdeduplizierung im Linux-Kernel, die nach identischen Speicherseiten in verschiedenen Prozessen sucht und diese zu einer einzigen Seite zusammenfasst, um den Speicherverbrauch zu reduzieren. Dies ist besonders nützlich in virtualisierten Umgebungen, in denen mehrere VMs ähnliche oder identische Daten im Speicher haben können, beispielsweise wenn dasselbe Betriebssystem oder dieselben Anwendungen ausgeführt werden.

KSM wurde bereits vor langer Zeit mit der Linux-Kernel-Version 2.6.32 im Jahr 2009 eingeführt. Das hindert die Entwickler jedoch nicht daran, neue Funktionen für KSM einzuführen, wie der 6.x-Kernel zeigt. Es gibt neue Änderungen, die Sie hier finden können: Aufschlüsselung der Änderungen an Kernel Samepage Merging (KSM) nach Kernel-Version. Wie Sie sehen können, fügen die Kernel-Entwickler dem Linux-Kernel ständig neue Funktionen für KSM hinzu, um dessen Funktionalität weiter zu verbessern.

Der derzeit in Proxmox VE verwendete Linux-Kernel ist beispielsweise 6.8.x. Er unterstützt die neu hinzugefügte Funktion „Smart Scan“, die wir in diesem Blogbeitrag gemeinsam testen werden.

Was ist Memory Ballooning?

Memory Ballooning ist eine Technik, die in virtualisierten Umgebungen verwendet wird, um die Speicherzuweisung von VMs dynamisch an ihren aktuellen Bedarf anzupassen. Ein „Balloon-Treiber” innerhalb der Gast-VM weist ungenutzten Speicher einem Speicherpool (dem „Balloon”) zu, sodass der Hypervisor Speicherressourcen bei Bedarf anderen VMs zuweisen kann. Dies trägt zur Optimierung der Speichernutzung im gesamten Hostsystem bei und stellt sicher, dass der Speicher effizient genutzt und nicht für inaktive VMs verschwendet wird.

Testaufbau

Um die KSM- und Ballooning-Funktionen in Proxmox VE zu evaluieren, haben wir einen Testcluster eingerichtet, der aus einem Knoten besteht, den wir in einer VM mit 16 GB RAM betreiben. Auf diesem Beispielcluster werden dann mehrere Linux-Gast-VMs ausgeführt, um die KSM- und Memory-Ballooning-Funktionen zu demonstrieren.

Die folgende Abbildung zeigt eine Übersicht über unsere Test-VM-Konfiguration:

Proxmox VE Host:

• Eine VM zur Installation von Proxmox VE 8.2.
  • 8 Cores vCPU
  • 16GB RAM
  • 200GB Virtio storage

Linux Gast VM Template:

• Linux Gast
  • 2GB RAM
  • Installiertes Debian LXQt desktop
  • 16GB Virtio storage

Linux Gast VMs:

• 8 VMs, Linked-Clone aus dem Template

Tests durchführen

Wir führen zwei Testreihen durch. Zunächst bewerten wir nur KSM. Anschließend führen wir eine weitere Testreihe durch, um Memory Ballooning ohne KSM zu testen.

Einrichtung von Gast-VMs für KSM-Tests:

1. Wir haben 8 VMs aus unserer VM-Vorlage mit jeweils 2 GB RAM geklont, wie Sie in der Abbildung unten sehen können.
   Jede VM wurde mit 2 GB RAM konfiguriert, ohne dass Ballooning aktiviert wurde.

2. Als Nächstes starten wir diese 8 VMs und starten sie mit LXQt Desktop Auto-Login, ohne KSM auszulösen. Hier möchten wir überprüfen, wie viel Speicher jede dieser VMs verbraucht, bevor wir irgendeine Art von Reduzierungsmechanismus anwenden.

   

3. Wie Sie sehen können, verbrauchen alle 8 VMs insgesamt 13.154,1 MB. Der obige Screenshot wurde auf unserem Proxmox VE-Host aufgenommen.

4. Aktivieren Sie KSM Smart Scan mit dem folgenden Befehl auf dem Host:

   # echo "scan-time" > /sys/kernel/mm/ksm/advisor_mode

5. KSM aktivieren:

   # echo 1 > /sys/kernel/mm/ksm/run

Beobachtungen zu KSM Smart Scan

Die KSM-Funktion Smart Scan scheint im Vergleich zur klassischen ksmtuned-Methode effizienter zu sein, da sie Optimierungen für das Scannen von Seiten enthält, die Seiten überspringen, wenn die Deduplizierung bei früheren Versuchen nicht erfolgreich war. Dadurch wird die für das Scannen von Seiten erforderliche CPU-Zeit erheblich reduziert, was besonders hilfreich ist, wenn das System einen „stabilen Zustand” erreicht hat. Während unserer Tests haben wir nicht beobachtet, dass ksmd nennenswerte Systemressourcen beansprucht, sodass KSM Smart Scan die Speichernutzung mit minimalem Overhead optimieren kann.

Testergebnisse

1. Nach einer Weile, während KSM die Seiten scannt und zusammenführt, reduziert sich der verwendete Speicher auf 6.770,1 Mib.
   
2. Wir können auch den KSM-Freigabestatus in der Proxmox VE WebUI sehen.
   

Es wurde eine deutliche Verringerung des Speicherverbrauchs festgestellt. Obwohl während des KSM-Betriebs ein leichter Anstieg der CPU-Auslastung durch ksmd zu verzeichnen war, kam es zu keiner nennenswerten Verschlechterung der VM-Leistung. Dies zeigt, dass KSM effizient arbeitet, ohne das System stark zu belasten. Die Zusammenführung identischer Seiten führte zu einer besseren Speichernutzung, sodass mehr VMs ohne zusätzliche Hardware auf demselben Host ausgeführt werden konnten.

Kernel Samepage Merging (KSM) in Windows-VMs

KSM ist eine native Funktion des Linux-Kernels, die auf Hypervisor-Ebene arbeitet, Speicherseiten aller VMs scannt und identische Seiten zu einer einzigen gemeinsamen Seite zusammenführt. Dieser Prozess reduziert den Gesamtspeicherbedarf der VMs.

Bei Windows-VMs behandelt der Hypervisor deren Speicher ähnlich wie bei Linux-VMs, indem er identische Seiten identifiziert und zusammenführt. Das bedeutet, dass die Vorteile von KSM auch auf Windows-VMs ausgeweitet werden können, die auf Proxmox VE laufen, da Proxmox selbst unter Linux läuft und daher die KSM-Kernel-Funktion nutzt, unabhängig davon, welches Betriebssystem die Gast-VMs auf Proxmox VE ausführen.

Einrichtung der Gast-VMs für Ballooning-Tests:

Als Nächstes sehen wir uns Memory Balloning in einem weiteren Test an. Um die Balloning-Funktionen in Proxmox VE zu bewerten, werden wir die für KSM-Tests verwendete Proxmox VE-Umgebung mit den folgenden Anpassungen umfunktionieren:

1. Behalten Sie drei VMs und entfernen Sie die anderen.
2. Aktivieren Sie Ballooning in jeder VM.
3. Stellen Sie den minimalen Speicher auf 2048 MB und den maximalen Speicher auf 5120 MB in jeder VM ein.
   .

Deaktivieren Sie KSM:

Um KSM manuell zu deaktivieren, führen Sie den folgenden Befehl aus:

# echo 2 > /sys/kernel/mm/ksm/run

Das folgende Bild zeigt eine Übersicht über die Einrichtung unserer Ballooning-Test-VMs:

Aufgrund des Memory Ballooning sollte nun für jede VM mehr Speicher verfügbar sein. Testen wir dies, indem wir mit stress-ng jeder Gast-VM 4 GB Speicher zuweisen und den zugewiesenen Speicher für eine von Ihnen festgelegte Anzahl von Sekunden halten:

$ stress-ng --vm-bytes 4G -m 1 --vm-hang <seconds>

Die Option –vm-hang <Sekunden> gibt an, wie viele Sekunden die VM hängen bleibt, bevor der Speicher freigegeben wird.

OOM-Killer!

Wir haben beobachtet, dass der OOM-Killer auf dem Proxmox VE-Host ausgelöst wurde.

Die Auslösung des OOM-Killers auf dem Host ist problematisch. Die Zuweisung von 5 GB Speicher an jede VM führte zu einer übermäßigen Überbelegung, wodurch der OOM-Killer aufgrund unzureichender Speicherressourcen zur Bewältigung der Host-Workload aktiviert wurde.

Das Auslösen des OOM-Killers ist immer problematisch, aber auf dem Host ist es noch schlimmer als in Gast-VMs, da man nie weiß, welche VM beendet und getötet wird, oder es zumindest sehr schwer vorherzusagen ist.

Einer der Hauptzwecke von Memory Ballooning ist es, die Auslösung des OOM-Killers auf dem Host-System zu vermeiden, da dieser „mehr“ Schaden anrichten kann als ein OOM-Killer, der innerhalb einer bestimmten VM ausgelöst wird.

Reduzieren Sie die maximale Speicherkonfiguration in VMs für Ballooning-Tests.

Um das Problem der Überbelegung zu beheben, reduzieren wir die maximale Speicherkonfiguration in jeder VM auf 4 GB.

1. Passen Sie die maximale Speichereinstellung für jede VM auf 4 GB an.
   
2. Starten Sie drei VMs.

Als Nächstes verwenden wir stress-ng in der Gast-VM, um 3 GB Speicher zuzuweisen und dann für eine bestimmte Dauer ohne CPU-Auslastung auf jeder Gast-VM zu hängen:

$ stress-ng --vm-bytes 3G -m 1 --vm-hang <seconds>

Dies ist der Befehl top in der Gast-VM.

Überprüfen der Speichernutzung auf dem Host

Nach dem Ausführen des stress-ng-Tests überprüfen wir die Speichernutzung auf dem Host:

Der freie Speicherplatz auf dem Host ist nun knapp. Die dritte VM, die versucht, Speicherplatz zuzuweisen, weist aufgrund der begrenzten Ressourcen auf dem Host eine sehr hohe CPU-Auslastung auf.

Nach einer Weile können wir beobachten, wie der Ballooning-Treiber beginnt, Speicherplatz von den Gast-VMs auf dem Host zurückzugewinnen. Der RES (belegter physischer Speicher) jeder VM wurde reduziert:

Der Ballooning-Treiber fordert nun Speicher von jeder Gast-VM zurück, um den verfügbaren freien Speicher auf dem Host zu erhöhen. Diese Maßnahme trägt dazu bei, die Arbeitslast des Hosts aufrechtzuerhalten, führt jedoch aufgrund der reduzierten Speicherzuweisung zu einer Verlangsamung aller anderen Gast-VMs.

Auswirkungen von Ballooning auf Gast-VMs

Die verlangsamten VMs verfügen schließlich nicht mehr über genügend freien Speicher, um ihre Workloads aufrechtzuerhalten. Infolgedessen wird der OOM-Killer innerhalb der Gast-VMs ausgelöst:

Alle VMs hängen eine Weile, dann löst der OOM-Killer aus, um den Prozess stress-ng zu beenden. Danach kehren die VMs in ihren normalen Zustand zurück, und auf dem Host ist ausreichend freier Speicher verfügbar:

Wann wird Memory Stealing ausgelöst?

Um festzustellen, wann Memory Stealing ausgelöst wird, führen wir einen weiteren Test durch. Wir verwenden denselben Befehl stress-ng, um 3 GB Speicher auf zwei VMs zuzuweisen.

Als Nächstes weisen wir der dritten VM nach und nach Speicher zu, beginnend mit 512 MB, und fügen dann schrittweise weitere 512 MB hinzu, bis wir beobachten, dass die Speicherrückgewinnung ausgelöst wird.

Während wir die Speicherzuweisung auf der dritten VM schrittweise erhöhen, überwachen wir die Speichernutzung des Hosts:

Wir stellen fest, dass Memory Stealing noch nicht ausgelöst wird, wenn der verfügbare freie Speicher auf dem Host 2.978,1 MB (ca. 18,5 %) des Gesamtspeichers erreicht.

Weisen wir der dritten VM etwas mehr Speicher zu, um den verfügbaren freien Speicher auf dem Host weiter zu reduzieren. Wir haben festgestellt, dass der Ballooning-Treiber Speicher von den Gast-VMs stiehlt, wenn der verfügbare freie Speicher auf dem Host etwa 15 % des Gesamtspeichers erreicht:

An dieser Stelle können wir sehen, dass der den VMs zugewiesene Speicher reduziert wird und die CPU-Auslastung deutlich ansteigt.

Der Speicherentnahmeprozess wird fortgesetzt, bis der verfügbare freie Speicher auf dem Host wieder 20 % des Gesamtspeichers erreicht. Nach der Freigabe des zugewiesenen Speichers aus der dritten VM stellen wir fest, dass der Rückgewinnungsprozess stoppt, wenn der verfügbare freie Speicher auf dem Host 20 % des Gesamtspeichers erreicht.

Visualisierung der Ergebnisse der Ballooning-Tests

Die folgende Abbildung veranschaulicht die Beobachtungen aus unseren Tests:

Auf diesem Bild sehen Sie die folgenden wichtigen Punkte:

1. Mehr als 20 % freier Speicherplatz auf dem Host: Die anfängliche Speicherzuweisung für die VMs, wobei jede VM so konfiguriert ist, dass ihr maximal 4 GB Speicher zugewiesen werden können.
3. Auslösen von Memory Stealing: Der Punkt, an dem der verfügbare freie Speicher auf dem Host auf etwa 15 % des Gesamtspeichers sinkt, wodurch der Ballooning-Treiber ausgelöst wird, um Speicher von den Gast-VMs zurückzugewinnen. Die rote Farbe in Gast-VMs zeigt eine erhöhte CPU-Auslastung an, da der Ballooning-Treiber Speicher stiehlt und dadurch die Leistung der Gast-VMs beeinträchtigt.

Memory Ballooning in Windows VMs

Memory Ballooning funktioniert auch mit Windows-VMs in Proxmox VE durch Windows VirtIO-Treiber. Die Treiber-ISO finden Sie im Proxmox-Wiki oder können direkt von VirtIO-Treiber-ISO heruntergeladen werden.

Vergleich zu Linux VMs

Memory Hot Plug wird in Linux-VMs unterstützt, sodass sich die Gesamtspeichermenge dynamisch ändern kann, wenn der Ballooning-Treiber aktiv ist. Das bedeutet, dass Sie in Linux-VMs sehen können, wie sich die Gesamtspeicherzuweisung in Echtzeit anpasst, während der Ballooning-Treiber arbeitet. Windows unterstützt Memory Hot Plug nicht auf die gleiche Weise. Daher sehen Sie in einer Windows-VM keine Anpassung der Gesamtspeichermenge. Stattdessen werden Sie eine Zunahme der verwendeten Speichermenge beobachten. Trotz dieses Unterschieds ist das Endergebnis dasselbe: Der verfügbare freie Speicher wird reduziert, wenn der Ballooning-Treiber Speicher zurückgewinnt.

Dieser Screenshot zeigt, dass der belegte Speicher zunimmt, wenn Ballooning aktiv ist, um Speicher innerhalb der Windows-VM zu stehlen.

Ergebnisse

Memory Ballooning in Proxmox VE ist eine leistungsstarke Funktion zur dynamischen Verwaltung der Speicherzuweisung zwischen VMs, wodurch die Gesamtspeichernutzung des Hosts optimiert wird. Es ist jedoch wichtig, die Schwellenwerte zu kennen, die die Speicherrückgewinnung auslösen, um Leistungseinbußen zu vermeiden. Es wird empfohlen, eine angemessene Mindestspeichergrenze festzulegen, um sicherzustellen, dass bei Erreichen dieses Mindestschwellenwerts kein weiterer Speicher entzogen werden kann. Auf diese Weise wird die Stabilität der Gast-VM gewährleistet und verhindert, dass der OOM-Killer Prozesse innerhalb der Gast-VM beendet. Durch geeignete Einstellungen, sorgfältige Überwachung und Anpassung der Speicherzuweisungen können Sie eine stabile und effiziente virtuelle Umgebung sicherstellen.

Sicherheitsbedenken

Auswirkungen der Aktivierung von KSM

Risiken bei der Verwendung von Datenbanken mit Ballooning

Memory Ballooning passt die Speicherzuweisung von VMs dynamisch an den Bedarf an. Diese Funktion ist zwar vorteilhaft für die Optimierung der Speichernutzung, birgt jedoch gewisse Risiken, wenn sie mit Datenbanken wie PostgreSQL verwendet wird, deren Leistung stark vom verfügbaren Speicher abhängt. Wenn der Balloon-Treiber zu viel Speicher zurückgewinnt, kann es durch Überbelegung von Speicherseiten dazu kommen, dass OOM-Killer den Prozess mit der höchsten Punktzahl beendet, bis die Situation mit hoher Speicherauslastung vorbei ist. Und der Prozess mit den höchsten Metrikwerten könnte sich auf den Speicherverbrauch beziehen, was höchstwahrscheinlich die Datenbank selbst betrifft.

In diesem Fall sollten Sie den Datenbankserver in einer VM ohne aktiviertes Memory Ballooning ausführen oder keine Überbelegungsrichtlinie im Linux-Kernel innerhalb der Gast-VM festlegen, wenn Sie keine solche Kontrolle haben.

Schlussfolgerung

Unsere Tests zeigen, dass KSM und Memory Ballooning in Proxmox VE effektive Funktionen zur Optimierung der Speichernutzung in virtualisierten Umgebungen sind. KSM kann den Speicherverbrauch durch die Zusammenführung identischer Seiten über VMs hinweg erheblich reduzieren, während Memory Ballooning eine dynamische Anpassung der Speicherzuweisung je nach Bedarf ermöglicht.

Memory Ballooning in Proxmox VE ist eine leistungsstarke Funktion zur dynamischen Verwaltung der Speicherzuweisung zwischen VMs, wodurch die Gesamtspeichernutzung des Hosts optimiert wird. Es ist jedoch wichtig, die Schwellenwerte zu kennen, die die Speicherrückgewinnung auslösen, um Leistungseinbußen zu vermeiden. Durch sorgfältige Überwachung und Anpassung der Speicherzuweisungen können Sie eine stabile und effiziente virtuelle Umgebung gewährleisten.

Zusammen können diese Funktionen die Effizienz und Leistung virtualisierter Workloads verbessern und Proxmox VE zu einer robusten Lösung für die Virtualisierung in Unternehmen machen.

Durch die Nutzung von KSM und Memory Ballooning können Unternehmen eine bessere Ressourcenauslastung erzielen und möglicherweise Hardwarekosten senken. Wenn Sie die volle Kontrolle über den Host und alle VMs haben, sollten Sie diese Funktionen in Proxmox VE aktivieren, um diese potenziellen Vorteile zu nutzen.

Dieser Artikel wurde ursprünglich von Andrew Lee verfasst.