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, um die Kosteneffizienz durch bessere Nutzung der auf Hostcomputern verfügbaren physischen Ressourcen zu steigern und nutzt außerdem einen benutzerdefinierten CPU-Planer und eine leistungsorientierte Live-Migration, um die Anforderungen an die Arbeitslastleistung mit den verfügbaren Ressourcen auszugleichen. Dabei handelt es sich um dieselben Technologien, mit denen die Google Suche, Google Ads, Google Maps und YouTube ihre latenzempfindlichen Arbeitslasten effizient ausführen.

Die dynamische Ressourcenverwaltung der nächsten Generation bietet außerdem eine bessere NUMA-Affinität, eine genauere Vorhersage der Ressourcenanforderungen und einen schnelleren Ausgleich durch leistungsorientierte Live-Migration.

Funktionsweise der dynamischen Ressourcenverwaltung

Virtuelle CPUs (vCPUs) werden als Threads implementiert, die nach Bedarf wie jeder andere Thread auf einem Host ausgeführt werden sollen. Wenn die vCPU Arbeit hat, wird die Arbeit einer verfügbaren physischen CPU zugewiesen, auf der diese ausgeführt werden kann, bis sie wieder in den Ruhezustand wechselt. Virtueller RAM wird physischen Hostseiten über Seitentabellen zugeordnet, die beim ersten Zugriff auf eine physische Seite ausgefüllt werden. Diese Zuordnung bleibt bestehen, bis die VM anzeigt, dass eine Gast-Seite nicht mehr benötigt wird.

Die dynamische Ressourcenverwaltung ermöglicht Compute Engine, die verfügbaren physischen CPUs besser zu nutzen. Dazu werden VMs anhand des Ressourcenbedarfs geplant und vCPU-Threads so für physische CPUs geplant, dass die Wartezeit minimiert wird. In den meisten Fällen ist dies nahtlos möglich, sodass Google Cloud VMs effizienter auf weniger Servern ausführen kann.

Komponenten der dynamischen Ressourcenverwaltung

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

Größere, effizientere physische Server

Die Anzahl der Kerne und die RAM-Dichte haben sich stetig erhöht, sodass die Hostserver jetzt viel mehr Ressourcen haben als jede einzelne E2-VM. Google vergleicht kontinuierlich neue Hardware und sucht nach Plattformen, die kostengünstig und für die meisten Cloud-Arbeitslasten und -Dienste leistungsfähig sind. So können Sie die neuesten Technologien nutzen, sobald sie verfügbar sind.

Intelligente VM-Platzierung

Das Clusterverwaltungssystem von Google berücksichtigt die CPU-, RAM-, Arbeitsspeicherbandbreite und andere Ressourcenanforderungen von VMs, die auf einem physischen Server ausgeführt werden. Anhand dieser Informationen wird vorhergesagt, wie gut eine neu hinzugefügte VM auf diesem Server ist. Anschließend wird über Tausende von Servern nach dem besten Standort für das Hinzufügen einer VM gesucht. Diese Beobachtungen stellen sicher, dass eine neue VM mit ihren Nachbarn kompatibel ist und es unwahrscheinlich ist, dass sie von diesen Instanzen gestört wird, wenn sie platziert wird.

leistungsorientierte Live-Migration

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

Hypervisor-CPU-Planer

Der Hypervisor-CPU-Planer ordnet bei Bedarf dynamisch die virtuelle CPU und den Arbeitsspeicher der physischen CPU und dem Arbeitsspeicher des Hostservers zu. Diese dynamische Verwaltung erhöht die Kosteneffizienz in VMs durch bessere Nutzung der physischen Ressourcen. Durch die effiziente Ressourcennutzung kann Compute Engine VMs auf weniger Servern effizienter ausführen, sodass Google Cloud Einsparungen an die Nutzer weitergeben kann.

Dynamische Ressourcenverwaltung der ersten Generation

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

Virtio Memory Balloon Device mit E2-VMs

Die Speicherbereinigung ist ein Schnittstellenmechanismus zwischen Host und Gast, um die Größe des reservierten Speichers für den Gast dynamisch anzupassen. E2 verwendet ein Virtio Memory Balloon Device , um Memory Ballooning zu implementieren. Über das 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 Maschinenfamilie, 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. Compute Engine erfasst und verwendet diese Daten, um genauere Bemessungsempfehlungen ausgeben zu können.

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

In Linux-Kerneln vor Version 5.2 verhindert das Linux-Speichersystem fälschlicherweise manchmal 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 standardmäßig bereits in allen von Google bereitgestellten Images durchgesetzt, die nach dem 9. Februar 2021 veröffentlicht wurden.

Mit dem folgenden Befehl können Sie den Wert von 0 in 1 ändern, um die Einstellung zu korrigieren:

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

Fügen Sie der Datei /etc/sysctl.conf Folgendes hinzu, um diese Änderung auch bei 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 Compute Engine die Speicherressourcen effektiver nutzen, sodass Google Cloud E2-VMs zu niedrigeren Preisen anbieten kann. Zum Deaktivieren des Virtio Memory Balloon Device können Sie dessen Gerätetreiber deaktivieren. Nach der Deaktivierung des Virtio Memory Balloon Device erhalten Sie weiterhin Bemessungsempfehlungen, 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