Gestão de recursos dinâmicos de próxima geração


As VMs N4, com base nos processadores Intel Xeon de 5.ª geração e no Titanium, usam a gestão dinâmica de recursos de nova geração para aumentar a rentabilidade através de uma melhor utilização dos recursos físicos disponíveis nas máquinas anfitriãs. Também usam um agendador de CPU personalizado e uma migração em direto com reconhecimento do desempenho para equilibrar as necessidades de desempenho da carga de trabalho com os recursos disponíveis. Estas são as mesmas tecnologias que os serviços Pesquisa Google, Google Ads, Google Maps e YouTube usam para executar as respetivas cargas de trabalho sensíveis à latência de forma eficiente.

A gestão dinâmica de recursos de próxima geração também tem uma melhor afinidade NUMA, uma previsão mais precisa dos requisitos de recursos e um reequilíbrio mais rápido através da migração em direto com reconhecimento do desempenho.

Como funciona a gestão dinâmica de recursos

As CPUs virtuais (vCPUs) são implementadas como threads agendados para serem executados a pedido, como qualquer outro thread num anfitrião. Quando a vCPU tem trabalho a fazer, o trabalho é atribuído a uma CPU física disponível na qual é executado até voltar a entrar em suspensão. Da mesma forma, a RAM virtual é mapeada para páginas de anfitrião físicas através de tabelas de páginas preenchidas quando uma página física convidada é acedida pela primeira vez. Este mapeamento permanece fixo até a MV indicar que já não é necessária uma página física do convidado.

A gestão dinâmica de recursos permite que o Compute Engine use melhor as CPUs físicas disponíveis agendando VMs para servidores com base na procura de recursos e agendando threads de CPUs virtuais para CPUs físicas de modo a minimizar o tempo de espera. Na maioria dos casos, podemos fazê-lo de forma integrada, o que Google Cloud permite executar VMs de forma mais eficiente em menos servidores.

Componentes da gestão dinâmica de recursos

O Compute Engine usa as seguintes tecnologias para a gestão dinâmica 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 anfitriões têm muito mais recursos do que qualquer VM individual. A Google realiza continuamente testes de referência de novo hardware e procura plataformas rentáveis e com bom desempenho para a mais ampla variedade de serviços e cargas de trabalho na nuvem, o que lhe permite tirar partido das tecnologias mais recentes quando estão disponíveis.

Posicionamento inteligente de VMs

O sistema de gestão de clusters da Google observa a CPU, a RAM e outras exigências de recursos das VMs em execução num servidor físico. Usa estas informações para prever o desempenho de uma VM adicionada recentemente nesse servidor. Em seguida, pesquisa em milhares de servidores para encontrar a melhor localização para adicionar uma VM. Estas observações garantem que, quando uma nova VM é colocada, é compatível com os respetivos vizinhos e é pouco provável que sofra interferências dessas instâncias.

Migração ao vivo com reconhecimento do desempenho

Depois de as VMs serem colocadas num anfitrião, o Compute Engine monitoriza continuamente o desempenho das VMs e os tempos de espera. Se as exigências de recursos das VMs aumentarem, o Compute Engine pode usar a migração em direto para transferir cargas de trabalho de forma transparente para outros anfitriões no centro de dados. A política de migração em direto é orientada por uma abordagem preditiva que dá ao Compute Engine tempo para mudar a carga, muitas vezes antes de as VMs terem qualquer tempo de espera.

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 anfitrião a pedido. Esta gestão dinâmica aumenta a rentabilidade das VMs, tirando melhor partido dos recursos físicos. A utilização eficiente dos recursos significa que o Compute Engine pode executar VMs de forma mais eficiente em menos servidores, o que permite Google Cloud transferir as poupanças para os utilizadores.

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

A série E2 foi a primeira série de VMs a oferecer gestão dinâmica de recursos através de um dispositivo de balão de memória virtio.

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

O aumento da memória é um mecanismo de interface entre o anfitrião e o convidado para ajustar dinamicamente o tamanho da memória reservada para o convidado. O E2 usa um dispositivo de balão de memória virtio para implementar o balão de memória. Através do dispositivo de balão de memória virtio, um anfitrião pode pedir explicitamente a um convidado que ceda uma determinada quantidade de páginas de memória livre (também denominada inflação do balão de memória) e recuperar a memória para que o anfitrião possa usar a memória livre para outras VMs. Da mesma forma, o dispositivo de balão de memória virtio pode devolver 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 de balão de memória.

As instâncias de VM E2 do Compute Engine baseadas numa imagem pública têm um dispositivo de balão de memória virtio , que monitoriza a utilização de memória do sistema operativo convidado. O sistema operativo convidado comunica a respetiva memória disponível ao sistema anfitrião. O anfitrião realoca qualquer memória não utilizada a outros processos a pedido, usando assim a memória de forma mais eficaz. O Compute Engine recolhe e usa estes dados para fazer recomendações de dimensionamento adequadas mais precisas.

Validar a instalação do controlador

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

Linux

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

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, por vezes, impede erradamente as grandes atribuições quando o dispositivo de balão está presente. Na prática, este problema é raro, mas recomendamos que altere a definição de memória virtual overcommit_memory para 1 para evitar que o problema ocorra. Esta alteração já é feita por predefinição em todas as imagens fornecidas pela Google publicadas desde 9 de fevereiro de 2021.

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

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

Para manter esta alteração nos reinícios, adicione o seguinte ao ficheiro /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 o fazem. Para verificar se a sua imagem do Windows tem o controlador instalado, execute:

googet verify google-compute-engine-driver-balloon

Desativar o dispositivo de balão de memória virtio

A utilização do dispositivo de balão de memória virtio permite que o Compute Engine utilize os recursos de memória de forma mais eficaz, pelo que Google Cloud pode oferecer VMs E2 a preços mais baixos. Pode desativar o dispositivo de balão de memória virtio desativando o controlador do dispositivo. Depois de desativar o dispositivo de balão de memória virtio, continua a receber recomendações de redimensionamento. No entanto, estas podem não ser tão precisas.

Linux

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

sudo rmmod virtio_balloon

Pode adicionar este comando ao script de arranque da VM para desativar automaticamente o dispositivo no arranque da VM.

Windows

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

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

Pode colocar este comando no script de arranque da VM para desativar automaticamente o dispositivo no arranque da VM.

O que se segue?