Gestione dinamica delle risorse di nuova generazione

Le VM N4, basate su processori Intel Xeon di 5a generazione e Titanium, utilizzano la gestione dinamica delle risorse di nuova generazione per aumentare l'efficienza dei costi sfruttando meglio le risorse fisiche disponibili sulle macchine host e utilizzano anche uno scheduler CPU personalizzato e la migrazione in tempo reale in base alle prestazioni per bilanciare le esigenze di prestazioni del carico di lavoro con le risorse disponibili. Si tratta delle stesse tecnologie utilizzate dai servizi Google Search, Google Ads, Google Maps e YouTube per eseguire in modo efficiente i loro carichi di lavoro sensibili alla latenza.

La gestione dinamica delle risorse di nuova generazione ha anche una migliore affinità NUMA, una previsione più accurata dei requisiti delle risorse e un ribilanciamento più rapido mediante una migrazione live sensibile alle prestazioni.

Come funziona la gestione dinamica delle risorse

Le CPU virtuali (vCPU) sono implementate come thread pianificati per essere eseguiti on demand come qualsiasi altro thread su un host. Quando la vCPU ha del lavoro da svolgere, il lavoro viene assegnato a una CPU fisica disponibile su cui eseguirlo finché non si mette di nuovo in sospensione. Allo stesso modo, la RAM virtuale è mappata alle pagine host fisiche utilizzando le tabelle di pagina che vengono compilate al primo accesso a una pagina fisica guest. Questa mappatura rimane fissa finché la VM non indica che non è più necessaria una pagina fisica ospite.

La gestione dinamica delle risorse consente a Compute Engine di usare al meglio le CPU fisiche disponibili pianificando le VM sui server in base della domanda e la pianificazione di thread vCPU su CPU fisiche in modo che il tempo di attesa ridotto a icona. Nella maggior parte dei casi, possiamo farlo senza problemi, in modo che Google Cloud possa per eseguire le VM in modo più efficiente su meno server.

Componenti della gestione dinamica delle risorse

Compute Engine utilizza le seguenti tecnologie per le risorse dinamiche gestione dei dispositivi:

Server fisici più grandi ed efficienti

Il numero dei core e la densità della RAM sono aumentati costantemente, tanto che ora e i server hanno molte più risorse di qualsiasi singola VM. Google continuamente confronta il nuovo hardware e cerca piattaforme convenienti e le prestazioni migliori per la più vasta gamma di carichi di lavoro e servizi cloud, consentendo per sfruttare le tecnologie più recenti, non appena saranno disponibili.

Posizionamento VM intelligente

Il sistema di gestione dei cluster di Google osserva la CPU, la RAM, la larghezza di banda della memoria da parte delle VM in esecuzione su un server fisico. Utilizza queste informazioni per prevedere il rendimento di una VM appena aggiunta su quel server. Quindi, analizza migliaia di server per trovare la posizione migliore per aggiungere una VM. Queste osservazioni assicurano che, quando viene posizionata una nuova VM, sia compatibile con le VM vicine e che sia improbabile che si verifichino interferenze da parte di queste istanze.

Migrazione live in base alle prestazioni

Dopo aver posizionato le VM su un host, Compute Engine monitora continuamente le prestazioni e i tempi di attesa delle VM. Se le richieste di risorse delle VM aumentano, Compute Engine può utilizzare la migrazione live per spostare in modo trasparente i carichi di lavoro su altri host nel data center. Il criterio di migrazione in tempo reale è guidato da un approccio predittivo che dà a Compute Engine il tempo di spostare il carico, spesso prima che le VM debbano attendere.

Pianificatore della CPU dell'hypervisor

Lo scheduler di CPU hypervisor mappa dinamicamente CPU virtuale e memoria alla CPU fisica e alla memoria del server host on demand. Questa gestione dinamica consente di ottimizzare i costi delle VM sfruttando meglio le risorse fisiche. Un uso efficiente delle risorse significa Compute Engine possono eseguire VM in modo più efficiente su meno server, consentendo a Google Cloud di passare di risparmio per gli utenti.

Gestione delle risorse dinamiche di prima generazione

E2 è stata la prima serie di VM a offrire la gestione dinamica delle risorse utilizzando un dispositivo virtio balloon memory.

Dispositivo Virtio balloon memory con VM E2

L'aumento della memoria è un meccanismo di interfaccia tra host e guest per regolare dinamicamente le dimensioni della memoria riservata per il guest. E2 utilizza un dispositivo di ballooning della memoria virtio per implementare il ballooning della memoria. Attraverso il palloncino Virtio Memory dispositivo, un organizzatore può chiedere esplicitamente a un ospite di offrire una le pagine dei ricordi (detto anche gonfiaggio dei palloncini di memoria) e recuperare il ricordo in modo in modo che l'host possa utilizzare la memoria libera per altre VM. Allo stesso modo, la memoria virtio il palloncino può restituire le pagine dei ricordi all'ospite sgonfiando il palloncino con i ricordi. Le VM E2 sono l'unica famiglia di macchine che utilizza la memoria dispositivo a palloncino.

Le istanze VM E2 di Compute Engine basate su un'immagine pubblica dispongono di un dispositivo balloon della memoria virtio che monitora l'utilizzo della memoria del sistema operativo guest. L'ospite del sistema operativo comunica la sua memoria disponibile al sistema host. L'organizzatore rialloca la memoria inutilizzata ad altri processi on demand, utilizzando così in modo più efficace. Compute Engine raccoglie e utilizza questi dati per fornire consigli di dimensionamento adeguato più accurati.

Verifica dell'installazione del driver

Per verificare se nell'immagine è installato il driver per il fumetto con memoria virtio e caricato, esegui questo comando.

Linux

La maggior parte delle distribuzioni Linux include il driver del dispositivo fumetto virtio. Per verificare che il driver dell'immagine sia installato e caricato, esegui:

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 Keler Linux prima della 5.2, a volte il sistema di memoria Linux ha erroneamente consente di evitare allocazioni di grandi dimensioni quando è presente il palloncino. In pratica, raramente si tratta di un problema, ma ti consigliamo di modificare l'impostazione della memoria virtuale overcommit_memory in 1 per evitare che si verifichi. Questa modifica è già stata apportata per impostazione predefinita in tutti Immagini fornite da Google pubblicate dal 9 febbraio 2021.

Per correggere l'impostazione, utilizza il seguente comando per modificare il valore da Da 0 a 1:

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

Per mantenere questa modifica dopo i riavvii, aggiungi quanto segue al file/etc/sysctl.conf:

vm.overcommit_memory=1

Windows

Le immagini Windows di Compute Engine includono il dispositivo virtio balloon. Le immagini di Windows personalizzate, invece, non lo fanno. A verifica se nell'immagine Windows è installato il driver, esegui:

googet verify google-compute-engine-driver-balloon

Disattivazione del fumetto con memoria Virtio

L'utilizzo del dispositivo balloon della memoria virtio consente a Compute Engine di utilizzare le risorse di memoria in modo più efficace, in modo che Google Cloud possa offrire VM E2 a prezzi inferiori. Puoi disattivare il fumetto con memoria Virtio disattivando il driver del dispositivo. Dopo aver disattivato il dispositivo balloon della memoria virtio, continuerai a ricevere suggerimenti per il dimensionamento ottimale, ma potrebbero non essere altrettanto precisi.

Linux

Per disabilitare il dispositivo in Linux, esegui questo comando:

sudo rmmod virtio_balloon

Puoi aggiungere questo comando script di avvio per disabilitare automaticamente dispositivo all'avvio della VM.

Windows

Per disabilitare il dispositivo su Windows, esegui questo comando:

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

Puoi inserire questo comando nello script di avvio della VM per disattivare automaticamente il dispositivo all'avvio della VM.

Passaggi successivi