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

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Durante um evento de manutenção planejado para o hardware subjacente de uma instância de máquina virtual (VM) ou instância bare metal, o servidor host não estará disponível. Para manter uma instância em execução durante um evento de host, o Compute Engine realiza uma migração em tempo real da instância para outro servidor host na mesma zona. Para obter mais informações sobre eventos de host, consulte Sobre eventos de host .

A migração ao vivo permite Google Cloud execute a manutenção sem interromper uma carga de trabalho, reinicializar uma instância ou modificar qualquer propriedade da instância, como endereços IP, metadados, dados de armazenamento em bloco, estado do aplicativo ou configurações de rede.

A migração em tempo real mantém as instâncias em execução durante as seguintes situações:

• Manutenção de infraestrutura. A manutenção da infraestrutura inclui hardware de host, rede e redes de energia em data centers, além de sistema operacional (SO) e BIOS de host.

• Atualizações relacionadas à segurança e alterações na configuração do sistema. Isso inclui eventos como instalação de patches de segurança e alteração do tamanho da partição raiz do host para armazenamento da imagem e dos pacotes do sistema operacional host.

• Falhas de hardware. Isso inclui falhas na memória, CPUs, placas de interface de rede e discos. Se a falha for detectada antes de ocorrer uma falha completa do servidor, o Compute Engine realizará uma migração preventiva em tempo real da instância para um novo servidor host. Se o hardware falhar completamente ou impedir a migração em tempo real, a instância será encerrada e reiniciada automaticamente.

O Compute Engine realiza apenas uma migração em tempo real de VMs que têm a política de manutenção do host definida para migração. Para obter informações sobre como alterar a política de manutenção do host, consulte Definir política de manutenção do host da VM .

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

O Compute Engine pode migrar instâncias em tempo real com discos SSD locais anexados (excluindo instâncias Z3). O Compute Engine move as instâncias de VM junto com os dados do SSD local para uma nova máquina antes de qualquer manutenção planejada.

Limitações

A migração em tempo real não é compatível com os seguintes tipos de VM:

• Instâncias sem sistema operacional . As instâncias bare metal C3 e X4 não oferecem suporte à migração em tempo real. O comportamento de manutenção para essas instâncias é definido como TERMINATE e RESTART , respectivamente.
• A maioria das instâncias de VM confidenciais . A migração em tempo real para instâncias de VM confidenciais só é compatível com tipos de máquinas N2D com plataformas de CPU AMD EPYC Milan que executam AMD SEV. Todas as outras instâncias de VM confidencial não oferecem suporte à migração em tempo real e devem ser configuradas para parar e, opcionalmente, reiniciar durante um evento de manutenção do host. Consulte Migração ao vivo para obter mais detalhes.

• VMs com GPUs anexadas . As instâncias de VM com GPUs anexadas devem ser configuradas para serem interrompidas e, opcionalmente, reiniciadas. O Compute Engine oferece um aviso de 60 minutos antes que uma instância de VM com uma GPU anexada seja interrompida. Para saber mais sobre esses avisos de eventos de manutenção, leia Obtendo avisos de migração em tempo real .

  Para saber mais sobre como lidar com a manutenção do host com GPUs, leia Como lidar com a manutenção do host na documentação das GPUs.

• TPUs na nuvem . As Cloud TPUs não são compatíveis com migração em tempo real.
• VMs otimizadas para armazenamento . As VMs Z3 não oferecem suporte à migração ao vivo. O comportamento de manutenção para VMs Z3 está definido como TERMINATE .

Como funciona o processo de migração ao vivo?

Quando uma VM está programada para migração em tempo real, o Compute Engine fornece uma notificação para que você possa preparar suas cargas de trabalho e aplicativos para essa interrupção da migração em tempo real. Durante a migração ao vivo, Google Cloud garante um tempo mínimo de interrupção, que normalmente é muito inferior a 1 segundo. Se uma VM não estiver configurada para migração em tempo real, o Compute Engine encerrará a VM durante a manutenção do host. As VMs configuradas para serem encerradas durante um evento de host param e (opcionalmente) são reiniciadas .

Quando Google Cloud migra uma VM em execução de um host para outro, ele move o estado completo da VM da origem para o destino de uma forma que seja transparente para o sistema operacional convidado e para qualquer coisa que se comunique com ele.Há muitos componentes envolvidos para que isso funcione perfeitamente, mas as etapas de alto nível são mostradas na ilustração a seguir:

O processo começa com uma notificação de que uma VM precisa ser movida de sua máquina host atual. A notificação pode começar com uma alteração de arquivo indicando que uma nova versão do BIOS está disponível, uma operação de hardware agendando manutenção ou um sinal automático de uma falha iminente de hardware.

Google CloudO software de gerenciamento de cluster da Microsoft monitora constantemente esses eventos e os agenda com base em políticas que controlam os data centers, como taxas de utilização de capacidade e o número de VMs que um único cliente pode migrar de uma só vez.

Depois que uma VM for selecionada para migração, Google Cloud fornece uma notificação ao convidado de que uma migração acontecerá em breve. Após um período de espera, um host de destino é selecionado e o host é solicitado a configurar uma nova VM de "destino" vazia para receber a VM de "origem" em migração. A autenticação é usada para estabelecer uma conexão entre a origem e o destino.

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

1. Queda de energia da fonte. A VM ainda está em execução na origem, enquanto a maior parte do estado é enviada da origem para o destino. Por exemplo,Google Cloud copia toda a memória guest para o destino, enquanto rastreia as páginas que foram alteradas na origem. O tempo gasto na indisponibilidade da fonte é uma função do tamanho da memória do convidado e da taxa na qual as páginas estão sendo alteradas.

2. Apagão. Um breve momento em que a VM não está em execução em nenhum lugar, 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 no estágio de blecaute quando o envio de alterações de estado durante o estágio de blecaute de origem atinge um ponto de retornos decrescentes. É usado um algoritmo que equilibra o número de bytes de memória enviados em relação à taxa na qual a VM convidada está fazendo alterações.

   Durante eventos de blecaute, o relógio do sistema parece avançar até 5 segundos. Se um evento de apagão exceder 5 segundos, Google Cloud para e sincroniza o relógio usando um daemon incluído como parte dos pacotes de convidados da VM.

3. Queda de energia do alvo. 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 da rede alcance o novo local da VM de destino, a VM de origem fornece serviços de encaminhamento de pacotes de e para a VM de destino.

Finalmente, a migração é concluída e o sistema exclui a VM de origem. Você pode ver que a migração ocorreu nos registros do Cloud Logging da sua VM.

Migração em tempo real de VMs de locatário individual

À medida que sua carga de trabalho é executada, talvez você queira mover VMs para um nó de locatário individual ou grupo de nós diferente. Se você mover uma VM para um grupo de nós, o Compute Engine determinará em qual nó ela será colocada. Para obter informações sobre locatário individual, consulte Visão geral de locatário individual .

Para mover VMs de locatário individual para um nó ou grupo de nós diferente, você pode iniciar manualmente uma migração em tempo real. Você também pode iniciar manualmente uma migração ao vivo para mover uma VM em um host multilocatário para um nó de locatário individual. Para obter mais informações, consulte Migrar VMs manualmente em tempo real .

O que vem a seguir

• Defina opções de política de manutenção de host de VM para configurar suas instâncias para migração em tempo real.

• Leia dicas para projetar um sistema robusto que possa lidar com interrupções de serviço.

Durante um evento de manutenção planejado para o hardware subjacente de uma instância de máquina virtual (VM) ou instância bare metal, o servidor host não estará disponível. Para manter uma instância em execução durante um evento de host, o Compute Engine realiza uma migração em tempo real da instância para outro servidor host na mesma zona. Para obter mais informações sobre eventos de host, consulte Sobre eventos de host .

A migração ao vivo permite Google Cloud execute a manutenção sem interromper uma carga de trabalho, reinicializar uma instância ou modificar qualquer propriedade da instância, como endereços IP, metadados, dados de armazenamento em bloco, estado do aplicativo ou configurações de rede.

A migração em tempo real mantém as instâncias em execução durante as seguintes situações:

• Manutenção de infraestrutura. A manutenção da infraestrutura inclui hardware de host, rede e redes de energia em data centers, além de sistema operacional (SO) e BIOS de host.

• Atualizações relacionadas à segurança e alterações na configuração do sistema. Isso inclui eventos como instalação de patches de segurança e alteração do tamanho da partição raiz do host para armazenamento da imagem e dos pacotes do sistema operacional host.

• Falhas de hardware. Isso inclui falhas na memória, CPUs, placas de interface de rede e discos. Se a falha for detectada antes de ocorrer uma falha completa do servidor, o Compute Engine realizará uma migração preventiva em tempo real da instância para um novo servidor host. Se o hardware falhar completamente ou impedir a migração em tempo real, a instância será encerrada e reiniciada automaticamente.

O Compute Engine realiza apenas uma migração em tempo real de VMs que têm a política de manutenção do host definida para migração. Para obter informações sobre como alterar a política de manutenção do host, consulte Definir política de manutenção do host da VM .

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

O Compute Engine pode migrar instâncias em tempo real com discos SSD locais anexados (excluindo instâncias Z3). O Compute Engine move as instâncias de VM junto com os dados do SSD local para uma nova máquina antes de qualquer manutenção planejada.

Limitações

A migração em tempo real não é compatível com os seguintes tipos de VM:

• Instâncias sem sistema operacional . As instâncias bare metal C3 e X4 não oferecem suporte à migração em tempo real. O comportamento de manutenção para essas instâncias é definido como TERMINATE e RESTART , respectivamente.
• A maioria das instâncias de VM confidenciais . A migração em tempo real para instâncias de VM confidenciais só é compatível com tipos de máquinas N2D com plataformas de CPU AMD EPYC Milan que executam AMD SEV. Todas as outras instâncias de VM confidencial não oferecem suporte à migração em tempo real e devem ser configuradas para parar e, opcionalmente, reiniciar durante um evento de manutenção do host. Consulte Migração ao vivo para obter mais detalhes.

• VMs com GPUs anexadas . As instâncias de VM com GPUs anexadas devem ser configuradas para serem interrompidas e, opcionalmente, reiniciadas. O Compute Engine oferece um aviso de 60 minutos antes que uma instância de VM com uma GPU anexada seja interrompida. Para saber mais sobre esses avisos de eventos de manutenção, leia Obtendo avisos de migração em tempo real .

  Para saber mais sobre como lidar com a manutenção do host com GPUs, leia Como lidar com a manutenção do host na documentação das GPUs.

• TPUs na nuvem . As Cloud TPUs não são compatíveis com migração em tempo real.
• VMs otimizadas para armazenamento . As VMs Z3 não oferecem suporte à migração ao vivo. O comportamento de manutenção para VMs Z3 está definido como TERMINATE .

Como funciona o processo de migração ao vivo?

Quando uma VM está programada para migração em tempo real, o Compute Engine fornece uma notificação para que você possa preparar suas cargas de trabalho e aplicativos para essa interrupção da migração em tempo real. Durante a migração ao vivo, Google Cloud garante um tempo mínimo de interrupção, que normalmente é muito inferior a 1 segundo. Se uma VM não estiver configurada para migração em tempo real, o Compute Engine encerrará a VM durante a manutenção do host. As VMs configuradas para serem encerradas durante um evento de host param e (opcionalmente) são reiniciadas .

Quando Google Cloud migra uma VM em execução de um host para outro, ele move o estado completo da VM da origem para o destino de uma forma que seja transparente para o sistema operacional convidado e para qualquer coisa que se comunique com ele.Há muitos componentes envolvidos para que isso funcione perfeitamente, mas as etapas de alto nível são mostradas na ilustração a seguir:

O processo começa com uma notificação de que uma VM precisa ser movida de sua máquina host atual. A notificação pode começar com uma alteração de arquivo indicando que uma nova versão do BIOS está disponível, uma operação de hardware agendando manutenção ou um sinal automático de uma falha iminente de hardware.

Google CloudO software de gerenciamento de cluster da Microsoft monitora constantemente esses eventos e os agenda com base em políticas que controlam os data centers, como taxas de utilização de capacidade e o número de VMs que um único cliente pode migrar de uma só vez.

Depois que uma VM for selecionada para migração, Google Cloud fornece uma notificação ao convidado de que uma migração acontecerá em breve. Após um período de espera, um host de destino é selecionado e o host é solicitado a configurar uma nova VM de "destino" vazia para receber a VM de "origem" em migração. A autenticação é usada para estabelecer uma conexão entre a origem e o destino.

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

1. Queda de energia da fonte. A VM ainda está em execução na origem, enquanto a maior parte do estado é enviada da origem para o destino. Por exemplo,Google Cloud copia toda a memória guest para o destino, enquanto rastreia as páginas que foram alteradas na origem. O tempo gasto na indisponibilidade da fonte é uma função do tamanho da memória do convidado e da taxa na qual as páginas estão sendo alteradas.

2. Apagão. Um breve momento em que a VM não está em execução em nenhum lugar, 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 no estágio de blecaute quando o envio de alterações de estado durante o estágio de blecaute de origem atinge um ponto de retornos decrescentes. É usado um algoritmo que equilibra o número de bytes de memória enviados em relação à taxa na qual a VM convidada está fazendo alterações.

   Durante eventos de blecaute, o relógio do sistema parece avançar até 5 segundos. Se um evento de apagão exceder 5 segundos, Google Cloud para e sincroniza o relógio usando um daemon incluído como parte dos pacotes de convidados da VM.

3. Queda de energia do alvo. 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 da rede alcance o novo local da VM de destino, a VM de origem fornece serviços de encaminhamento de pacotes de e para a VM de destino.

Finalmente, a migração é concluída e o sistema exclui a VM de origem. Você pode ver que a migração ocorreu nos registros do Cloud Logging da sua VM.

Migração em tempo real de VMs de locatário individual

À medida que sua carga de trabalho é executada, talvez você queira mover VMs para um nó de locatário individual ou grupo de nós diferente. Se você mover uma VM para um grupo de nós, o Compute Engine determinará em qual nó ela será colocada. Para obter informações sobre locatário individual, consulte Visão geral de locatário individual .

Para mover VMs de locatário individual para um nó ou grupo de nós diferente, você pode iniciar manualmente uma migração em tempo real. Você também pode iniciar manualmente uma migração ao vivo para mover uma VM em um host multilocatário para um nó de locatário individual. Para obter mais informações, consulte Migrar VMs manualmente em tempo real .

O que vem a seguir

• Defina opções de política de manutenção de host de VM para configurar suas instâncias para migração em tempo real.

• Leia dicas para projetar um sistema robusto que possa lidar com interrupções de serviço.