17.4. Overcommitting mit KVM
Der KVM-Hypervisor unterstützt den sog. CPU-Overcommit und Speicher-Overcommit. Beim Overcommitting werden mehr virtualisierte CPUs oder mehr Speicher zugewiesen, als physische Ressourcen auf dem System vorhanden sind. Mit CPU-Overcommit können nicht voll ausgelastete virtualisierte Server oder Desktops auf weniger physischen Servern laufen, was sowohl Energie als auch Geld spart.
Xen-Unterstützung
CPU-Overcommitting wird nicht unterstützt für den Xen-Hypervisor. Overcommitting von CPUs mit dem Xen-Hypervisor kann zur Systeminstabilität und zu Abstürzen des Hosts und der virtualisierten Gäste führen.
Die meisten Betriebssysteme und Anwendungen nutzen nicht ständig 100% des zur Verfügung stehenden RAM. Dieses Verhalten kann mit KVM ausgenutzt werden, um mehr Speicher für virtualisierte Gäste zu verwenden, als physisch verfügbar ist.
Unter KVM werden virtuelle Maschinen wie Linux-Prozesse gehandhabt. Gäste auf dem KVM-Hypervisor haben keine zugewiesenen Blöcke physischen RAMs, sondern funktionieren stattdessen als Prozesse. Jedem Prozess wird Speicher zugewiesen, wenn dieser mehr Speicher anfragt. KVM nutzt dies, um Speicher für Gäste zuzuweisen, wenn das Gastbetriebssystem mehr oder weniger Speicher anfragt. Der Gast braucht nur wenig mehr physischen Speicher, als das virtualisierte Betriebssystem zu verwenden scheint.
Wenn der physische Speicher nahezu vollständig verbraucht ist oder der Prozess seit einer gewissen Zeit inaktiv ist, verlegt Linux den Speicher des Prozesses in den Swap-Bereich. Swap-Speicher ist in der Regel eine Partition auf einem Festplattenlaufwerk (HDD) oder Festkörperlaufwerk (SSD), das Linux zum Erweitern des virtuellen Speichers nutzt. Swap ist deutlich langsamer als RAM:
Da virtuelle Maschinen unter KVM Linux-Prozesse sind, kann der Speicher, der vom virtualisierten Gast verwendet wird, in den Swap-Berreich ausgelagert werden, wenn der Gast gerade wenig oder gar nicht ausgelastet ist. Speicher kann zugewiesen werden über die Gesamtgröße des Swap und physischen RAMs. Dies kann zu Problemen führen, wenn virtualsierte Gäste ihren RAM vollständig verbrauchen. Wenn nicht ausreichend Swap-Space für die Prozesse der virtuellen Maschinen zur Verfügung steht, beginnt der pdflush-Prozess. pdflush beendet Prozesse, um Speicher freizugeben und das System so vor einem Absturz zu bewahren. pdflush kann Fehler im Dateisystem verursachen und kann dazu führen, dass die virtualisierten Gäste nicht mehr starten können.
Warning
Falls nicht genügend Swap-Speicher verfügbar ist, werden Gastbetriebssysteme zwangsweise heruntergefahren. Dies kann dazu führen, dass Gäste funktionsunfähig werden. Sie sollten dies vermeiden und daher niemals mehr Speicher zuweisen, als Swap zur Verfügung steht.
Die Swap-Partition wird verwendet, um wenig verwendeten Speicher zur Festplatte auszulagern, so dass die Speicherleistung erhöht wird. Die Standardgröße der Swap-Partition wird auf Grundlage der RAM-Menge und Overcommit-Rate berechnet. Es wird empfohlen, Ihre Swap-Partition größer anzulegen, wenn Sie beabsichtigen, Speicher-Overcommit mit KVM durchzuführen. Die empfohlene Rate für das Overcommiting liegt bei 50% (0,5). Die verwendete Formel lautet:
(0,5 x RAM) + (Overcommit-Rate x RAM) = Empfohlene Swap-Größe
In der Red Hat Knowledgebase finden Sie einen Artikel darüber, wie die Größe der Swap-Partition sicher und effizient bestimmt werden kann — siehe
Knowledgebase.
Es ist möglich, eine Overcommit-Rate von mehr als dem Zehnfachen der Anzahl virtualisierter Gäste über dem physischen RAM des Systems zu haben. Dies funktioniert nur mit bestimmten Anwendungsauslastungen (z. B. Desktop-Virtualisierung mit weniger als 100% Auslastung). Die Formel zum Einstellen der Overcommit-Rate ist nicht sehr kompliziert, Sie müssen nur Ihre Rate testen und an Ihre Umgebung anpassen.
Der KVM-Hypervisor unterstützt das Overcommitting von virtualisierten CPUs. Das Overcommitting von virtualisierten CPUs wird nur durch die Auslastungsgrenze virtualisierter Gäste beschränkt. Seien Sie beim Overcommitting von virtualisierten CPUs jedoch vorsichtig, denn Auslastungen von beinahe 100% können dazu führen, dass Anfragen verworfen werden oder die Antwortzeiten untragbar lang werden.
Das Overcommitting von virtualisierten CPUs ist am besten, wenn jeder virtualisierte Gast nur über eine einzige VCPU verfügt. Der Linux Scheduler arbeitet sehr effizient mit dieser Art Auslastung. KVM sollte Gäste mit Auslastungen unter 100% bei einer Rate von 5 VCPUs sicher unterstützen. Overcommitting von virtualisierten Gästen mit einfachem VCPU stellt kein Problem dar.
Sie können kein Overcommitting bei Gästen mit symmetrischem Multiprocessing für mehr als die Anzahl physischer Prozessorkerne durchführen. Zum Beispiel sollte ein Gast mit vier VCPUs nicht auf einem Host mit Dual Core Prozessor ausgeführt werden. Overcommitting bei Gästen mit symmetrischem Multiprocessing für mehr als die Anzahl physischer Prozessorkerne hat deutliche Leistungseinbußen zur Folge.
Sie können Gästen VCPUs bis zur Anzahl der physischen Prozessorkerne zuweisen, dies funktioniert einwandfrei. So können Sie beispielsweise virtualisierte Gäste mit vier VCPUs auf einem Quad Core Host ausführen. Gäste mit Auslastungen von unter 100% sollten mit dieser Konfiguration effektiv arbeiten können.
Grundsätzlich vorher testen
Wenden Sie in einer Produktionsumgebung kein Overcomitting von Speicher oder CPUs an, ohne vorher umfangreiche Tests durchgeführt zu haben. Anwendungen, die 100% des Speichers oder der Prozessorressourcen brauchen, können in Umgebungen mit Overcommitment instabil werden. Testen Sie also gründlich vor dem Einsatz.
