Dynamische Ressourcenverwaltung der nächsten Generation

N4-VMs mit Intel Xeon-Prozessoren der 5. Generation und Titanium nutzen die dynamische Ressourcenverwaltung der nächsten Generation. Dadurch werden die physischen Ressourcen auf Hostcomputern besser genutzt, um die Kosteneffizienz zu steigern. Außerdem sorgen ein benutzerdefinierter CPU-Planer und die leistungsorientierte Live-Migration für einen Ausgleich des Leistungsbedarfs von Arbeitslasten mit den verfügbaren Ressourcen. Dieselben Technologien kommen auch bei der Google Suche, Google Ads, Google Maps und YouTube zum Einsatz, um latenzempfindliche Arbeitslasten effizienter auszuführen.

Die dynamische Ressourcenverwaltung der nächsten Generation bietet auch eine bessere NUMA-Affinität, genauere Vorhersagen der Ressourcenanforderungen sowie einen schnelleren Neuausgleich mithilfe der leistungsorientierten Live-Migration.

So funktioniert die dynamische Ressourcenverwaltung

Virtuelle CPUs (vCPUs) werden als Threads implementiert, die wie alle anderen Threads auf einem Host nach Bedarf ausgeführt werden. Wenn die vCPU eine Aufgabe auszuführen hat, wird diese einer verfügbaren physischen CPU zugewiesen. Die Aufgabe wird auf dieser CPU ausgeführt, bis sie wieder in den Ruhezustand wechselt. Ebenso wird virtueller RAM über Seitentabellen physischen Hostseiten zugeordnet. Diese werden dann beim ersten Zugriff auf eine physische Gast-Seite ausgefüllt. Diese Zuordnung bleibt solange bestehen, bis die VM angibt, dass die physische Gast-Seite nicht mehr benötigt wird.

Mit der dynamischen Ressourcenverwaltung kann die Compute Engine die verfügbaren physischen CPUs besser nutzen, da die VMs für Server anhand des Ressourcenbedarfs geplant werden. Außerdem wird durch das Planen von vCPU-Threads für physische CPUs die Wartezeit verkürzt. In den meisten Fällen geschieht dies nahtlos, sodass Google Cloud VMs auf weniger Servern effizienter ausführen kann.

Komponenten der dynamischen Ressourcenverwaltung

Die Compute Engine verwendet für die dynamische Ressourcenverwaltung die folgenden Technologien:

Größere und effizientere physische Server

Die Anzahl der Cores sowie die RAM-Dichte wurden stetig erhöht, sodass Hostserver jetzt deutlich mehr Ressourcen haben als eine einzelne VM. Google führt kontinuierlich Benchmarks für neue Hardware durch und sucht nach kostengünstigen Plattformen, die für die meisten Cloud-Arbeitslasten und -Dienste die nötige Leistung bieten. So können Sie von den neuesten Technologien profitieren, sobald diese verfügbar sind.

Intelligente VM-Platzierung

Das Clusterverwaltungssystem von Google überwacht die CPU-, RAM- und anderen Ressourcenanforderungen von VMs, die auf einem physischen Server ausgeführt werden. Anhand dieser Informationen wird vorhergesagt, welche Leistung eine neu hinzugefügte VM auf diesem Server erbringen wird. Anschließend wird unter Tausenden von Servern nach dem besten Ausführungsort für die VM gesucht. Durch diese Überwachung wird sichergestellt, dass eine neue VM mit ihren Nachbar-VMs kompatibel ist und es höchstwahrscheinlich zu keinen Störungen durch diese Instanzen kommen wird.

Leistungsorientierte Live-Migration

Nachdem die VMs auf einem Host platziert wurden, überwacht die Compute Engine kontinuierlich die VM-Leistung und -Wartezeiten. Wenn sich die Ressourcenanforderungen der VMs erhöhen, kann die Compute Engine mithilfe der Live-Migration Arbeitslasten transparent auf andere Hosts im Rechenzentrum verschieben. Die Richtlinie für die Live-Migration verwendet einen vorausschauenden Ansatz, der der Compute Engine Zeit gibt, die Last zu verlagern, oft bevor es bei den VMs zu einer Wartezeit kommt.

Hypervisor-CPU-Planer

Der Hypervisor-CPU-Planer ordnet bei Bedarf virtuelle CPUs und Arbeitsspeicher dynamisch den physischen CPUs und Arbeitsspeichern auf Hostservern zu. Diese dynamische Verwaltung erhöht die Kosteneffizienz für VMs, da physische Ressourcen besser genutzt werden. Durch die effiziente Ressourcennutzung kann die Compute Engine VMs auf weniger Servern effizienter ausführen, sodass Google Cloud Einsparungen an Nutzer weitergeben kann.

Dynamische Ressourcenverwaltung der ersten Generation

Die erste VM-Serie, die eine dynamische Ressourcenverwaltung mit einem Virtio Memory Balloon Device ermöglichte, war E2.

Virtio Memory Balloon Device bei E2-VMs

Memory Ballooning ist ein Schnittstellenmechanismus zwischen Host und Gast, um die Größe des reservierten Speichers für den Gast dynamisch anzupassen. E2 verwendet hierfür ein Virtio Memory Balloon Device. Mithilfe des Virtio Memory Balloon Device kann ein Host einen Gast explizit auffordern, eine bestimmte Menge an freien Speicherseiten abzugeben (auch als „Memory Balloon-Inflation“ bezeichnet) und den Speicher zurückfordern, damit der Host den freien Speicher für andere VMs nutzen kann. Ebenso kann das Virtio Memory Balloon Device Speicherseiten an den Gast zurückgeben, indem es den Memory Balloon verkleinert. E2-VMs sind die einzige VM-Familie, die das Memory Balloon Device verwendet.

Compute Engine E2-VM-Instanzen, die auf einem öffentlichen Image beruhen, haben ein Virtio Memory Balloon Device, das den Arbeitsspeicherverbrauch des Gastbetriebssystems überwacht. Das Gastbetriebssystem teilt dem Hostsystem seinen verfügbaren Speicher mit. Der Host weist nicht genutzten Speicher bei Bedarf anderen Prozessen zu, wodurch der Speicher effizienter genutzt wird. Die Compute Engine erfasst und verwendet diese Daten, um genauere Empfehlungen für die Größenanpassung auszugeben.

Treiberinstallation prüfen

Mit dem folgenden Befehl können Sie prüfen, ob auf Ihrem Image der Treiber für das Virtio Memory Balloon Device installiert und geladen ist.

Linux

Die meisten Linux-Distributionen enthalten den Treiber für das Virtio Memory Balloon Device. So können Sie prüfen, ob auf dem Image der Treiber installiert und geladen ist:

sudo modinfo virtio_balloon > /dev/null && echo Balloon driver is \
installed || echo Balloon driver is not installed; sudo lsmod | grep \
virtio_balloon > /dev/null && echo Balloon driver is loaded || echo \
Balloon driver is not loaded

Bei Linux-Kerneln vor Version 5.2 verhindert das Linux-Speichersystem in manchen Fällen fälschlicherweise umfangreiche Zuweisungen, wenn das Virtio Memory Balloon Device vorhanden ist. Dies kommt in der Praxis selten vor. Dennoch empfehlen wir, die Einstellung overcommit_memory für virtuelle Speicher auf 1 zu ändern, um das Problem zu vermeiden. Diese Änderung ist bei allen von Google bereitgestellten Images, die nach dem 9. Februar 2021 veröffentlicht wurden, bereits Standard.

Mit dem folgenden Befehl können Sie den Wert von 0 auf 1 korrigieren:

sudo /sbin/sysctl -w vm.overcommit_memory=1

Fügen Sie der Datei /etc/sysctl.conf Folgendes hinzu, um diese Änderung auch nach Neustarts beizubehalten:

vm.overcommit_memory=1

Windows

Compute Engine Windows-Images enthalten das Virtio Memory Balloon Device, benutzerdefinierte Windows-Images hingegen nicht. Mit dem folgenden Befehl können Sie prüfen, ob der Treiber auf Ihrem Windows-Image installiert ist:

googet verify google-compute-engine-driver-balloon

Virtio Memory Balloon Device deaktivieren

Mithilfe des Virtio Memory Balloon Device kann die Compute Engine die Speicherressourcen effektiver nutzen, sodass Google Cloud E2-VMs zu niedrigeren Preisen anbieten kann. Zum Deaktivieren des Virtio Memory Balloon Device müssen Sie nur den entsprechenden Gerätetreiber deaktivieren. Nach dem Deaktivieren erhalten Sie weiterhin Empfehlungen zur Größenanpassung, die jedoch möglicherweise weniger genau sind.

Linux

Führen Sie den folgenden Befehl aus, um das Gerät unter Linux zu deaktivieren:

sudo rmmod virtio_balloon

Sie können diesen Befehl in das Startskript der VM einfügen, um das Gerät beim VM-Start automatisch zu deaktivieren.

Windows

Führen Sie den folgenden Befehl aus, um das Gerät unter Windows zu deaktivieren:

googet -noconfirm remove google-compute-engine-driver-balloon

Sie können diesen Befehl in das Startskript der VM einfügen, um das Gerät beim VM-Start automatisch zu deaktivieren.

Nächste Schritte