Gerenciamento de recursos dinâmicos de última geração

As VMs N4, com processadores Intel Xeon de quinta geração e o Titanium, usam o gerenciamento de recursos dinâmicos de última geração para aumentar a eficiência de custo ao fazer melhor uso dos recursos físicos disponíveis nas máquinas host, além de usar um programador de CPU personalizado e uma migração em tempo real com reconhecimento de desempenho para equilibrar as necessidades de desempenho da carga de trabalho com os recursos disponíveis. Essas são as mesmas tecnologias que os serviços da Pesquisa Google, do Google Ads, do Google Maps e do YouTube usam para executar cargas de trabalho sensíveis à latência de maneira eficiente.

O gerenciamento de recursos dinâmicos de última geração também tem melhor afinidade de NUMA, previsão mais precisa dos requisitos de recursos e rebalanceamento mais rápido usando a migração em tempo real com reconhecimento de desempenho.

Como funciona o gerenciamento de recursos dinâmicos

As CPUs virtuais (vCPUs) são implementadas como linhas de execução programadas para serem executadas sob demanda como qualquer outra linha de execução em um host. Quando a vCPU tem um trabalho a fazer, ele é atribuído a uma CPU física disponível em que será executado até ficar inativo novamente. Da mesma forma, a RAM virtual é mapeada para páginas de host físico usando tabelas de páginas que são preenchidas quando uma página física convidada é acessada pela primeira vez. Esse mapeamento permanece fixo até que a VM indique que uma página física convidada não é mais necessária.

O gerenciamento de recursos dinâmicos permite que o Compute Engine utilize melhor as CPUs físicas disponíveis programando VMs para servidores com base na demanda de recursos e programando linhas de execução de vCPU para CPUs físicas, de modo que o tempo de espera seja minimizado. Na maioria dos casos, é possível fazer isso sem problemas, para que o Google Cloud possa executar VMs com mais eficiência em menos servidores.

Componentes do gerenciamento de recursos dinâmicos

O Compute Engine usa as seguintes tecnologias para o gerenciamento dinâmico de recursos:

Servidores físicos maiores e mais eficientes

A contagem de núcleos e a densidade de RAM aumentaram constantemente. Agora, os servidores host têm muito mais recursos do que qualquer VM individual. O Google compara continuamente hardwares novos e procura plataformas que sejam econômicas e tenham um bom desempenho para a mais ampla variedade de cargas de trabalho e serviços em nuvem, permitindo que você aproveite as tecnologias mais recentes quando elas estiverem disponíveis.

Colocação inteligente de VM

O sistema de gerenciamento de clusters do Google observa a CPU, a RAM, a largura de banda da memória e outras demandas de recursos de VMs em execução em um servidor físico. Ele usa essas informações para prever o desempenho de uma VM recém-adicionada nesse servidor. Em seguida, ele pesquisa em milhares de servidores para encontrar o melhor local para adicionar uma VM. Essas observações garantem que, quando uma nova VM for colocada, ela será compatível com os vizinhos e provavelmente não sofrerá interferência dessas instâncias.

Migração em tempo real com reconhecimento de desempenho

Depois que as VMs são colocadas em um host, o Compute Engine monitora continuamente o desempenho e os tempos de espera da VM. Se a demanda de recursos das VMs aumentar, o Compute Engine poderá usar a migração em tempo real para transferir de maneira transparente as cargas de trabalho para outros hosts no data center. A política de migração em tempo real é orientada por uma abordagem preditiva que dá ao Compute Engine tempo para mudar a carga, geralmente antes de qualquer tempo de espera das VMs.

Programador de CPU do hipervisor

O programador de CPU do hipervisor mapeia dinamicamente a CPU virtual e a memória para a CPU física e a memória do servidor host sob demanda. Esse gerenciamento dinâmico gera eficiência de custo nas VMs com um melhor uso dos recursos físicos. O uso eficiente dos recursos significa que o Compute Engine pode executar VMs de maneira mais eficiente em menos servidores, permitindo que o Google Cloud repasse a economia aos usuários.

Gerenciamento de recursos dinâmicos de primeira geração

A série de VMs E2 foi a primeira a oferecer gerenciamento de recursos dinâmicos usando um dispositivo de balão de memória Virtio.

Dispositivo de balão de memória Virtio com VMs E2

O balão de memória é um mecanismo de interface entre o host e o convidado para ajustar dinamicamente o tamanho da memória reservada para o convidado. A série E2 usa um dispositivo de balão de memória Virtio para implementar o balão de memória. Com o dispositivo de balão de memória Virtio , um host pode pedir explicitamente que um convidado produza uma certa quantidade de páginas de memória livre (também chamada de inflação do balão de memória) e recuperar a memória para que o host possa usar a memória livre para outras VMs. Da mesma forma, o dispositivo de balão de memória Virtio pode retornar páginas de memória para o convidado, descarregando o balão de memória. As VMs E2 são a única família de máquinas que usa o dispositivo de balão de memória.

As instâncias da VM E2 do Compute Engine baseadas em uma imagem pública têm um dispositivo de balão de memória Virtio que monitora o uso de memória do sistema operacional convidado. O sistema operacional convidado comunica sua memória disponível ao sistema host. O host realoca qualquer memória não utilizada para outros processos sob demanda, usando a memória de forma mais eficaz. O Compute Engine coleta e usa esses dados para fazer recomendações de redimensionamento mais precisas.

Como verificar a instalação do driver

Para verificar se a imagem tem o driver de dispositivo do balão de memória virtio instalado e carregado, execute o seguinte comando.

Linux

A maioria das distribuições Linux inclui o driver de dispositivo de balão de memória virtio. Para verificar se a imagem tem o driver instalado e carregado, execute:

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

Nos kernels do Linux anteriores à versão 5.2, o sistema de memória do Linux às vezes evita por engano grandes alocações quando o dispositivo de balão está presente. Raramente isso é um problema na prática, mas recomendamos que você altere a configuração overcommit_memory da memória virtual para 1 a fim de evitar que o problema ocorra. Essa alteração já é feita por padrão em todas as imagens fornecidas pelo Google publicadas desde 9 de fevereiro de 2021.

Para corrigir a configuração, use o seguinte comando para alterar o valor de 0 para 1:

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

Para manter essa alteração nas reinicializações, adicione o seguinte ao seu arquivo /etc/sysctl.conf:

vm.overcommit_memory=1

Windows

As imagens do Windows do Compute Engine incluem o dispositivo de balão Virtio. No entanto, as imagens personalizadas do Windows não. Para verificar se a imagem do Windows tem o driver instalado, execute:

googet verify google-compute-engine-driver-balloon

Como desativar o dispositivo de balão de memória virtio

O uso do dispositivo de balão de memória virtio permite que o Compute Engine use recursos de memória com mais eficiência. Assim, o Google Cloud pode oferecer VMs E2 a preços mais baixos. Desative o dispositivo de balão de memória virtio desativando o driver de dispositivo. Depois de desativar o dispositivo de balão de memória virtio, você continuará a receber recomendações de redimensionamento. No entanto, elas podem não ser tão precisas.

Linux

Para desativar o dispositivo no Linux, execute o seguinte comando:

sudo rmmod virtio_balloon

Adicione esse comando ao script de inicialização da VM para desativar automaticamente o dispositivo após a inicialização da VM.

Windows

Para desativar o dispositivo no Windows, execute o seguinte comando:

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

Coloque esse comando no script de inicialização da VM para desativar automaticamente o dispositivo após a inicialização da VM.

A seguir