Gerenciamento dinâmico de recursos de próxima geração


As VMs N4 , equipadas com processadores Intel Xeon de 5ª geração e Titanium , usam gerenciamento dinâmico de recursos de próxima geração para aumentar a eficiência de custos, fazendo melhor uso dos recursos físicos disponíveis nas máquinas host, e também usam um agendador de CPU personalizado e migração ao vivo 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 de Pesquisa Google, Google Ads, Google Maps e YouTube usam para executar suas cargas de trabalho sensíveis à latência com eficiência.

O gerenciamento dinâmico de recursos da próxima geração também tem melhor afinidade com NUMA, previsão mais precisa dos requisitos de recursos e reequilíbrio mais rápido usando migração ao vivo com reconhecimento de desempenho.

Como funciona o gerenciamento dinâmico de recursos

CPUs virtuais (vCPUs) são implementadas como threads programados para execução sob demanda como qualquer outro thread em um host. Quando a vCPU tem trabalho a fazer, o trabalho é atribuído a uma CPU física disponível na qual será executada até que ela entre em suspensão novamente. Da mesma forma, a RAM virtual é mapeada para páginas de host físicas 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 dinâmico de recursos permite que o Compute Engine use melhor as CPUs físicas disponíveis, agendando VMs para servidores com base na demanda de recursos e agendando threads de vCPU para CPUs físicas, de modo que o tempo de espera seja minimizado. Na maioria dos casos, podemos fazer isso perfeitamente, então Google Cloud pode executar VMs com mais eficiência em menos servidores.

Componentes do gerenciamento dinâmico de recursos

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

Servidores físicos maiores e mais eficientes

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

Posicionamento inteligente de VM

O sistema de gerenciamento de cluster do Google observa CPU, RAM, largura de banda de memória e outras demandas de recursos de VMs executadas 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 milhares de servidores para encontrar o melhor local para adicionar uma VM. Estas observações garantem que quando uma nova VM é colocada, ela é compatível com seus vizinhos e é improvável que sofra interferência dessas instâncias.

Migração ao vivo 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 as demandas de recursos das VMs aumentarem, o Compute Engine poderá usar a migração em tempo real para transferir de forma 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 transferir a carga, geralmente antes que as VMs tenham algum tempo de espera.

Agendador de CPU do hipervisor

O agendador 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 impulsiona a eficiência de custos nas VMs, fazendo melhor uso dos recursos físicos. O uso eficiente de recursos significa que o Compute Engine pode executar VMs com mais eficiência em menos servidores, permitindo Google Cloud para repassar economias aos usuários.

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

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

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

O balão de memória é um mecanismo de interface entre host e convidado para ajustar dinamicamente o tamanho da memória reservada para o convidado. E2 usa um dispositivo de balão de memória virtio para implementar o balão de memória. Por meio do dispositivo de balão de memória virtio, um host pode solicitar explicitamente a um convidado que libere uma certa quantidade de páginas de memória livre (também chamado de inflação de 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 ao convidado, esvaziando o balão de memória. As VMs E2 são a única família de máquinas que usa o dispositivo balão de memória.

As instâncias de 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 assim a memória de forma mais eficaz. O Compute Engine coleta e usa esses dados para fazer recomendações de redimensionamento mais precisas.

Verificando a instalação do driver

Para verificar se sua imagem possui o driver de dispositivo virtio memory Balloon 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 sua 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 Linux anteriores à versão 5.2, o sistema de memória Linux às vezes evita erroneamente grandes alocações quando o dispositivo balão está presente. Na prática, isso raramente é um problema, mas recomendamos alterar a configuração overcommit_memory da memória virtual para 1 para 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 persistir essa alteração durante as 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 balão virtio. No entanto, as imagens personalizadas do Windows não. Para verificar se a sua imagem do Windows tem o driver instalado, execute:

googet verify google-compute-engine-driver-balloon

Desativando o dispositivo balão de memória virtio

O uso do dispositivo de balão de memória virtio permite que o Compute Engine utilize recursos de memória de maneira mais eficaz. Google Cloud pode oferecer VMs E2 a preços mais baixos. Você pode cancelar o dispositivo de balão de memória virtio desativando o driver do dispositivo. Depois de desabilitar o dispositivo virtio memory Balloon, você continuará recebendo recomendações de redimensionamento ; no entanto, eles podem não ser tão precisos.

Linux

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

sudo rmmod virtio_balloon

Você pode adicionar este comando ao script de inicialização da VM para desabilitar automaticamente o dispositivo na inicialização da VM.

Windows

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

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

Você pode colocar este comando no script de inicialização da VM para desabilitar automaticamente o dispositivo na inicialização da VM.

O que vem a seguir