Processo de migração ao vivo durante eventos de manutenção

Durante um evento de manutenção planeado para o hardware subjacente de uma instância de máquina virtual (VM) ou uma instância bare metal, o servidor anfitrião fica indisponível. Para manter uma instância em execução durante um evento do anfitrião, o Compute Engine executa uma migração em direto da instância para outro servidor anfitrião na mesma zona. Para mais informações sobre eventos de anfitriões, consulte o artigo Acerca dos eventos de anfitriões.

A migração em direto permite Google Cloud fazer manutenção sem interromper uma carga de trabalho, reiniciar uma instância ou modificar qualquer uma das propriedades da instância, como endereços IP, metadados, dados de armazenamento em blocos, estado da aplicação ou definições de rede.

A migração em direto mantém as instâncias em execução nas seguintes situações:

  • Manutenção da infraestrutura. A manutenção da infraestrutura inclui hardware do anfitrião, redes e redes elétricas em centros de dados, bem como o sistema operativo (SO) e a BIOS do anfitrião.

  • Atualizações relacionadas com a segurança e alterações à configuração do sistema. Estes incluem eventos como a instalação de patches de segurança e a alteração do tamanho da partição raiz do anfitrião para o armazenamento da imagem e dos pacotes do SO do anfitrião.

  • Falhas de hardware. Isto inclui falhas na memória, nas CPUs, nas placas de interface de rede e nos discos. Se a falha for detetada antes de ocorrer uma falha completa do servidor, o Compute Engine executa uma migração em direto preventiva da instância para um novo servidor anfitrião. Se o hardware falhar completamente ou impedir a migração em direto, a instância é terminada e reiniciada automaticamente.

O Compute Engine só executa uma migração em direto de VMs que tenham a política de manutenção do anfitrião definida para migrar. Para obter informações sobre como alterar a política de manutenção do anfitrião, consulte o artigo Defina a política de manutenção do anfitrião da VM.

Processo de migração ao vivo e discos SSD locais

O Compute Engine pode migrar instâncias em direto com discos SSD locais anexados (exceto instâncias Z3 com mais de 18 TiB de SSD Titanium anexado). O Compute Engine move as instâncias de VMs, juntamente com os respetivos dados do SSD local, para uma nova máquina antes de qualquer manutenção planeada.

Limitações

A migração em direto não é suportada para os seguintes tipos de VMs:

  • Instâncias bare metal. As instâncias criadas com um tipo de máquina bare metal não suportam a migração em direto. O comportamento de manutenção destas instâncias está definido como TERMINATE e RESTART, respetivamente.
  • Instâncias de VM mais confidenciais. A migração em direto para instâncias de VM confidenciais só é suportada em tipos de máquinas N2D com plataformas de CPU AMD EPYC Milan que executam AMD SEV. Todas as outras instâncias de VM confidenciais não suportam a migração em direto e têm de ser definidas para parar e, opcionalmente, reiniciar durante um evento de manutenção do anfitrião. Consulte o artigo Migração em direto para mais detalhes.

  • VMs com GPUs anexadas. As instâncias de VM com GPUs anexadas têm de ser definidas para parar e, opcionalmente, reiniciar. O Compute Engine oferece um aviso antes de uma instância de VM com uma GPU anexada ser parada, consoante o tipo de GPU:

    • Para a maioria das GPUs, o Compute Engine envia um aviso com 60 minutos de antecedência.
    • Para famílias de GPUs executadas no AI Hypercomputer Cluster Director, o Compute Engine envia um aviso 10 minutos antes.

    Para saber mais acerca destes avisos de eventos de manutenção, leia o artigo Consultar metadados do servidor para avisos de eventos de manutenção.

    Para saber como processar a manutenção do anfitrião com GPUs, leia o artigo Processar a manutenção do anfitrião na documentação sobre GPUs.

  • TPUs do Google Cloud. As TPUs na nuvem não suportam a migração em direto.
  • VMs otimizadas para armazenamento. As VMs Z3 com mais de 18 TiB de SSD de titânio anexado não suportam a migração em direto. O comportamento de manutenção destas VMs está definido como TERMINATE e RESTART.O Compute Engine preserva os dados no SSD Titanium durante o evento de manutenção, conforme descrito em Persistência do disco após a terminação da instância.

Como funciona o processo de migração em direto?

Quando uma VM está agendada para migração em direto, o Compute Engine envia uma notificação para que possa preparar as suas cargas de trabalho e aplicações para esta interrupção de migração em direto. Durante a migração em direto, Google Cloud observa um tempo de interrupção mínimo, que é normalmente muito inferior a 1 segundo. Se uma VM não estiver definida para migração em direto, o Compute Engine termina a VM durante a manutenção do anfitrião. As VMs definidas para terminar durante um evento do anfitrião param e (opcionalmente) são reiniciadas.

Quando Google Cloud migra uma VM em execução de um anfitrião para outro, move o estado completo da VM da origem para o destino de uma forma transparente para o SO convidado e tudo o que comunica com ele. Existem muitos componentes envolvidos no funcionamento perfeito deste processo, mas os passos de alto nível são apresentados na seguinte ilustração:

Migrar uma VM e cada um dos respetivos recursos para um novo sistema anfitrião sem exigir o reinício do sistema operativo convidado.
Componentes de migração em direto

O processo começa com uma notificação de que uma MV tem de ser movida do respetivo computador anfitrião atual. A notificação pode começar com uma alteração de ficheiro que indica que está disponível uma nova versão da BIOS, uma programação de operações de hardware para manutenção ou um sinal automático de uma falha de hardware iminente.

O software de gestão de clusters daGoogle Cloudmonitoriza constantemente estes eventos e agenda-os com base em políticas que controlam os centros de dados, como as taxas de utilização da capacidade e o número de VMs que um único cliente pode migrar de uma só vez.

Depois de selecionar uma VM para migração,o Google Cloud envia uma notificação ao convidado a informar que vai ocorrer uma migração em breve. Após um período de espera, é selecionado um anfitrião de destino e é pedido ao anfitrião que configure uma VM de "destino" nova e vazia para receber a VM de "origem" migratória. A autenticação é usada para estabelecer uma ligação entre a origem e o destino.

Existem três fases envolvidas na migração da VM:

  1. Fonte brownout. A VM continua a ser executada na origem, enquanto a maioria dos estados é enviada da origem para o destino. Por exemplo, Google Cloud copia toda a memória do convidado para o destino, enquanto monitoriza as páginas que foram alteradas na origem. O tempo gasto na indisponibilidade temporária da origem é uma função do tamanho da memória do convidado e da taxa à qual as páginas estão a ser alteradas.

  2. Blackout. Um momento muito breve em que a VM não está a ser executada em nenhum local, a VM de origem é pausada e todo o estado restante necessário para começar a executar a VM no destino é enviado. A VM entra na fase de falha de energia quando o envio de alterações de estado durante a fase de falha de energia da origem atinge um ponto de retornos decrescentes. É usado um algoritmo que equilibra o número de bytes de memória enviados com a taxa à qual a VM convidada está a fazer alterações.

    Durante eventos de falha de energia, o relógio do sistema parece avançar até 5 segundos. Se um evento de indisponibilidade exceder 5 segundos, Google Cloud para e sincroniza o relógio através de um daemon incluído nos pacotes convidados da VM.

  3. Alvo de falha de energia parcial. A VM é executada na VM de destino. A VM de origem está presente e pode fornecer suporte para a VM de destino. Por exemplo, até que a estrutura de rede alcance a nova localização da VM de destino, a VM de origem fornece serviços de encaminhamento para pacotes de e para a VM de destino.

Por fim, a migração é concluída e o sistema elimina a VM de origem. Pode ver que a migração ocorreu nos registos do Cloud Logging da sua VM.

Migração ao vivo de VMs de inquilino único

À medida que a carga de trabalho é executada, pode querer mover as VMs para um grupo de nós ou um nó de inquilino único diferente. Se mover uma VM para um grupo de nós, o Compute Engine determina em que nó a colocar. Para obter informações sobre a posse exclusiva, consulte o artigo Vista geral da posse exclusiva.

Para mover VMs de inquilino único para um nó ou um grupo de nós diferente, pode iniciar manualmente uma migração em direto. Também pode iniciar manualmente uma migração em direto para mover uma VM num anfitrião multiinquilino para um nó de inquilino único. Para mais informações, consulte o artigo Migre VMs manualmente em direto.

O que se segue?