Sobre os eventos de host

Durante o ciclo de vida de uma instância de máquina virtual (VM) ou bare metal, a máquina host em que a instância é executada pode passar por vários eventos de host. Um evento de host pode incluir a manutenção regular da infraestrutura do Compute Engine ou, em casos raros, um erro de host. Você pode escolher como as instâncias de computação respondem durante ou após um evento de host configurando a política de manutenção do host.

Por padrão, a maioria das instâncias é definida para migração em tempo real durante eventos do host. Para todas as séries de máquinas, exceto a Z3, é possível substituir esse comportamento e definir explicitamente que as instâncias sejam encerradas e, opcionalmente, reiniciadas. As instâncias criadas com determinados tipos de máquina ou configurações não são compatíveis com a migração em tempo real, como as seguintes:

  • Instâncias H4D
  • Instâncias Z3 com mais de 18 TiB de SSD Titanium anexado
  • Instâncias Z4D com mais de 42 TiB de SSD Titanium anexado
  • Instâncias bare metal
  • Instâncias com GPUs anexadas

Essas instâncias são encerradas durante eventos de host. Para mais informações, consulte Comportamentos de manutenção e reinicialização.

Tipos de eventos de host

Há três tipos de eventos de host, que são descritos em mais detalhes nas seções a seguir:

Se a instância parar de responder, isso também poderá acionar uma reinicialização ou encerramento dela.

Eventos de manutenção

Um evento de manutenção ocorre quando o Compute Engine precisa realizar uma atividade de manutenção ou reparo que exige a remoção das VMs do servidor host. Se você ativar a migração em tempo real política de manutenção do host para um tipo de instância compatível, o Compute Engine vai mover a instância para um novo host, e haverá uma interrupção mínima no aplicativo.

O Compute Engine também aplica alguns hipervisores leves e upgrades de rede em segundo plano sem interrupções, mantendo a instância no mesmo host.

O comportamento da instância durante um evento de manutenção pode variar dependendo da locação da instância e do tipo de máquina.

Para VMs de locatário individual, a frequência aproximada de eventos de manutenção de host planejados é de 4 a 6 semanas. A compatibilidade com a migração em tempo real depende da política de manutenção do host da VM de locatário único.

Você pode encontrar informações sobre o comportamento de manutenção de cada tipo de máquina na página da família de máquinas correspondente, da seguinte forma:

Para famílias de máquinas com otimização de acelerador, consulte as seguintes páginas:

Manutenção emergencial

Um evento de manutenção emergencial ocorre quando o Compute Engine detecta uma falha iminente no host ou outro problema de hardware que exige manutenção urgente. Para esses eventos, o Compute Engine programa o evento de manutenção e cria uma notificação. Os eventos de manutenção emergencial geralmente têm uma janela de notificação menor do que os eventos de manutenção padrão.

Um evento de manutenção emergencial normalmente é avisado com 7 a 14 dias de antecedência. Dependendo da gravidade do problema, a janela de notificação pode ser menor. Leia a notificação de manutenção para saber quais funcionalidades são compatíveis, como iniciar a manutenção em um horário de sua escolha. Se nenhuma ação for tomada ou se não for possível iniciar a manutenção manualmente, o Compute Engine vai iniciar a manutenção automaticamente quando a janela de notificação terminar.

Se um evento de manutenção planejada estiver pendente quando o Compute Engine emitir uma notificação de manutenção emergencial, o evento emergencial vai substituir o planejado.

Verifique o motivo da manutenção emergencial no campo maintenanceReasons dos metadados da instância. Esse campo contém um valor que representa a categoria de falha.

Erros de host

Um erro de host (compute.instances.hostError) significa que houve um problema de hardware ou software na máquina física ou na infraestrutura do data center que hospeda a instância de computação que causou a falha da instância. Um erro de host que envolve uma falha total de hardware ou outros problemas de hardware pode impedir a migração em tempo real da sua instância. Se a instância estiver configurada para reiniciar automaticamente, o que é a configuração padrão, o Compute Engine a reiniciará, normalmente em três minutos a partir do momento em que o erro foi detectado. Dependendo do problema, a reinicialização pode levar até 5,5 minutos.

Depois que uma instância de computação encontra um erro de host ou você informa que o host está com falha, ele precisa de manutenção de emergência e não planejada. Por padrão, o Compute Engine avisa com algumas horas de antecedência quando agenda esse tipo de manutenção.

Às vezes, uma instância de computação pode não responder antes que um erro do host seja sinalizado. É possível reduzir o tempo que o Compute Engine aguarda para reiniciar ou encerrar a instância definindo o tempo limite de recuperação de erros do host. Para mais informações, consulte Definir a política para uma instância atual.

Falhas físicas de hardware e software podem acontecer ocasionalmente, mas são raras. Para proteger aplicativos e serviços contra esses eventos de sistema potencialmente prejudiciais, analise os seguintes recursos:

O Google também oferece serviços gerenciados, como o App Engine e o ambiente flexível do App Engine.

Visão geral da política de manutenção do host

A política de manutenção do host de uma instância determina como ela se comporta durante os seguintes eventos do host:

  • Evento de manutenção
  • Evento de manutenção emergencial
  • Evento de erro do host ou instância que não responde

É possível configurar as instâncias para continuarem em execução durante a manutenção do host, enquanto o Compute Engine as migra em tempo real para outro host ou pode optar por interromper as instâncias.

É possível mudar a política de manutenção do host de uma instância configurando as seguintes opções:

  • Comportamento de manutenção:se a instância é migrada em tempo real ou interrompida quando há um evento de manutenção.
  • Comportamento de reinicialização:se o Compute Engine reinicia ou encerra a instância caso ela falhe, apresente um erro de host ou pare de responder.
  • Tempo de detecção de erros do host:o tempo máximo que o Compute Engine aguarda para reiniciar ou encerrar uma instância depois de detectar que ela não está respondendo.
  • Tempo de recuperação do SSD local:o tempo máximo que o Compute Engine gasta na recuperação dos dados em discos SSD locais após detectar um erro de host. Os dados do SSD local serão perdidos se o tempo especificado se esgotar sem uma recuperação bem-sucedida.

É possível atualizar a política de manutenção do host de uma instância a qualquer momento para controlar o comportamento das instâncias.

Comportamentos de manutenção e reinicialização

Quando um evento de host ocorre, a instância de computação pode usar a migração em tempo real ou ser encerrada. Se uma instância for encerrada, você poderá reiniciá-la por conta própria ou deixar que o Compute Engine faça isso automaticamente.

As seguintes séries de máquinas podem não ser compatíveis com a migração em tempo real e, em vez disso, exigem encerramento durante eventos de host:

Migração em tempo real

Por padrão, a maioria dos tipos de instância é definida como migração em tempo real, exceto os tipos de instância mencionados na seção anterior.

Durante a migração em tempo real, o Compute Engine migra automaticamente sua instância para fora de um evento de manutenção de infraestrutura, e ela permanece em execução durante a migração. A instância pode ter um curto período de desempenho reduzido, mas, em geral, a maioria das instâncias não tem um desempenho notavelmente diferente. Isso é ideal para instâncias que exigem tempo de atividade constante e podem tolerar um período curto de desempenho reduzido.

Quando o Compute Engine migra sua instância, ele informa um evento de sistema que é publicado na lista de operações de zona e nos logs de eventos do sistema. É possível analisar esse evento ao visualizar as operações do Compute Engine para uma zona específica. Os eventos de migração em tempo real têm o seguinte tipo de operação:

compute.instances.migrateOnHostMaintenance

Encerrar e reiniciar

Se você não quiser que a instância seja migrada em tempo real ou se o tipo de instância não for compatível com a migração em tempo real, permita que o Google Cloud interrompa a instância quando ocorrer um evento do host. Com essa configuração, se ocorrer um evento de host, o Compute Engine enviará um sinal de desligamento suave para encerrar a instância. Em seguida, ele aguarda 60 segundos para que a instância seja encerrada corretamente e define o status da instância como TERMINATED. Se a instância não for encerrada corretamente em 60 segundos, ela será encerrada à força.

Essa opção é ideal se as instâncias exigem desempenho máximo e constante e se o aplicativo geral foi criado para lidar com falhas ou reinicializações de instâncias.

Quando o Compute Engine interrompe uma instância devido a um evento do host, ele informa um evento do sistema que é publicado na lista de operações de zona e nos logs de eventos do sistema. É possível analisar esse evento ao visualizar as operações do Compute Engine para uma zona específica. Os eventos de encerramento de instância têm o seguinte tipo de operação:

compute.instances.terminateOnHostMaintenance

Reinicialização automática

Se a instância estiver configurada para ser interrompida quando houver um evento de manutenção ou se ela falhar devido a um problema de hardware subjacente, o Compute Engine poderá reiniciar a instância automaticamente. A instância é reiniciada no mesmo servidor host ou movida para outro servidor na mesma zona que não esteja participando do evento de manutenção.

Por padrão, o Compute Engine tenta recuperar instâncias com discos SSD locais anexados por uma hora. Se o limite de tempo for atingido, o Compute Engine tentará reiniciar a instância em um servidor host diferente na mesma zona. As instâncias Z4D, Z3, X4 e H4D têm tempos de espera padrão diferentes. Esses tipos de instância são reiniciados no mesmo servidor host após a interrupção da instância.

Para configurar a reinicialização automática, defina o campo da política de manutenção do host automaticRestart como true. Essa configuração não se aplica se a instância for desativada devido a uma interrupção zonal ou por operação manual, como chamar sudo shutdown no SO convidado.

Quando o Compute Engine reinicializa a instância automaticamente, ele informa um evento de sistema publicado na lista de operações de zona. É possível analisar esse evento ao visualizar as operações do Compute Engine para uma zona específica. Os eventos de reinicialização automática têm o seguinte tipo de operação:

compute.instances.automaticRestart

Persistência do disco após o encerramento da instância

Como o disco permanente e o hiperdiscosão armazenamentos conectados à rede, quando a instância é reiniciada, o Compute Engine reconecta o disco de inicialização e todos os discos secundários à instância. Os dados nesses discos permanecem durante a migração em tempo real e as reinicializações de instâncias.

O Compute Engine preserva os dados em discos SSD locais após um evento de host sempre que possível. No entanto, o Compute Engine não garante a persistência de dados do SSD local.

  • Os discos SSD locais são preservados nos seguintes cenários:

    • Você reinicia o sistema operacional (SO) convidado.
    • Você configura a instância para migração em tempo real e ela passa por um evento de manutenção do host.
    • Ocorre um erro de host, e o Compute Engine reconecta a instância aos discos SSD locais dentro do limite de tempo limite.
    • Você opta por preservar os dados do SSD local ao interromper ou suspender a instância (prévia).
    • Uma instância de computação com discos SSD locais anexados que só aceita encerramento e reinicialização automática passa por um evento de manutenção. A instância é reiniciada no local, preservando os dados do SSD local, em vez de migrar para um novo host.

  • Os discos SSD locais não são preservados nos seguintes cenários:

    • Você desliga o sistema operacional convidado e força a parada da instância.
    • Você cria uma VM spot ou uma VM preemptiva e a VM passa pelo processo de preempção.
    • Você configura a instância para ser interrompida em eventos de manutenção do host em vez de usar a migração em tempo real, e a instância passa por um evento de manutenção do host.
    • Você configura incorretamente um disco SSD local, e ele fica inacessível.
    • Você desativa o faturamento do projeto, fazendo com que a instância seja interrompida.
    • Se automaticRestart não estiver configurado na instância.
    • Ocorre um erro de host, e o Compute Engine não consegue reconectar os discos à instância antes que o tempo limite expire. Nesse caso, a instância é reiniciada sem recuperar os discos SSD locais. Quando a instância é reiniciada, o Compute Engine anexa discos SSD locais em branco à instância reiniciada. É necessário formatar e ativar esses discos antes que a instância possa usá-los. Os dados nos discos SSD locais originais são irrecuperáveis.

Google Cloud usa uma abordagem de melhor esforço para manter os dados do SSD local intactos. No entanto, há casos em que não é possível recuperar os dados, como um tempo limite. Para mais informações sobre quando os discos SSD locais são preservados, consulte Permanência de dados do SSD local.

Tempo limite de recuperação do SSD local

Quando ocorre um erro de host, o Compute Engine tenta recuperar todos os discos SSD locais anexados à instância. É possível controlar quanto tempo o Compute Engine passa tentando recuperar os dados com a configuração localSsdRecoveryTimeout da política de host.

Por padrão, o Compute Engine gasta uma hora recuperando os dados, mas os valores válidos para essa configuração ficam entre 0 e 168, em incrementos de 1 hora. Os seguintes tipos de máquinas têm valores padrão diferentes:

  • Tipos de máquina de VM Z4D e Z3: o valor padrão é 6, o que significa que essas instâncias tentam recuperar os dados do SSD local por 6 horas antes de atingir o limite de tempo limite.
  • Bare metal Z3 z3-highmem-192-highlssd-metal: o valor padrão é de 168 horas (7 dias).

Se você definir o tempo limite de recuperação do SSD local como 0, o Compute Engine não tentará recuperar os discos SSD locais anexados. A instância é reiniciada assim que possível, e os dados do SSD local se tornam irrecuperáveis. Use essa configuração se a retomada da carga de trabalho for mais importante do que a recuperação dos dados do SSD local.

Se o tempo limite de recuperação não estiver definido como 0, mas o limite de tempo for atingido antes da recuperação dos dados do SSD local, o Compute Engine reiniciará a instância sem o disco SSD local. O Compute Engine anexa discos SSD locais novos e vazios à instância reiniciada. Formate e ative esses discos antes que a instância possa usá-los.

A instância fica no estado REPAIRING enquanto o Compute Engine tenta recuperar os discos SSD locais. A instância e os discos SSD locais ficam indisponíveis durante esse período.

Se você definir o tempo limite de recuperação do SSD local como o valor máximo de 168, a instância vai permanecer no estado REPAIRING por até 7 dias enquanto o Compute Engine tenta recuperar os discos SSD locais.

Interromper a recuperação do disco SSD local

É possível interromper o processo de recuperação do disco SSD local antes que o Compute Engine alcance o limite de tempo limite de recuperação. Para fazer isso, use o comando gcloud compute instances stop com a flag --discard-local-ssd=True.

Esse comando interrompe o processo de recuperação, a instância de computação e descarta os dados do SSD local. Em seguida, reinicie a instância. Consulte Interromper uma instância com SSD local para mais informações.

Para definir o tempo limite de recuperação do SSD local, consulte Definir política de manutenção do host da instância.

Programação de manutenção

Google Cloud oferece recursos que permitem maior controle da manutenção. Ao usar determinadas famílias de máquinas, é possível especificar preferências de manutenção e receber notificações de eventos de manutenção futuros pelo Cloud Logging, o servidor de metadados da instância, o comando compute instances describe da CLI gcloud ou o método instances.describe REST. Ao receber uma notificação, você tem um período para iniciar a manutenção programada no horário que preferir. Se você não acionar a manutenção programada, o evento de manutenção vai ocorrer no final do período de notificação, que é o horário programado listado na notificação.

É possível usar esses recursos em combinação com a política de manutenção do host para personalizar uma programação de manutenção que se adapte à sua carga de trabalho.

A seguir