Acerca dos eventos de anfitriões

Durante o ciclo de vida de uma instância de máquina virtual (VM) ou de uma instância bare metal, a máquina anfitriã na qual a sua instância é executada pode sofrer vários eventos de anfitrião. Um evento de anfitrião pode incluir a manutenção regular da infraestrutura do Compute Engine ou, em casos raros, um erro de anfitrião. Pode escolher como as instâncias de metal nu e de VM respondem durante ou após um evento do anfitrião configurando a política de manutenção do anfitrião.

Por predefinição, a maioria das instâncias está definida para migração em direto durante eventos do anfitrião. Para todas as séries de máquinas, exceto a Z3, pode substituir este comportamento e definir explicitamente a terminação das instâncias e, opcionalmente, o respetivo reinício. Alguns tipos de máquinas não suportam a migração em direto, como instâncias bare metal, instâncias com GPUs anexadas ou instâncias Z3 com mais de 18 TiB de SSD Titanium anexado. Estas instâncias terminam durante os eventos do anfitrião. Para mais informações, consulte o artigo Comportamentos de manutenção e reinício.

Tipos de eventos de anfitriões

Existem dois tipos de eventos de anfitrião, que são descritos mais detalhadamente nas secções seguintes:

Se a sua instância deixar de responder, isto também pode acionar um reinício ou a terminação da instância.

Eventos de manutenção

Um evento de manutenção ocorre quando o Compute Engine tem de realizar uma atividade de manutenção ou reparação que requer a mudança das VMs do servidor anfitrião. Se ativar a migração em direto política de manutenção do anfitrião para um tipo de instância suportado, o Compute Engine move a instância para um novo anfitrião, e a interrupção da sua aplicação é mínima.

O Compute Engine também aplica algumas atualizações de hipervisor e de rede simples em segundo plano de forma não disruptiva, mantendo a instância no mesmo anfitrião.

O comportamento da instância durante um evento de manutenção pode variar consoante a ocupação da instância e o tipo de máquina. Pode encontrar informações sobre o comportamento de manutenção de cada tipo de máquina na página da respetiva família de máquinas, da seguinte forma:

Para obter informações sobre as políticas de manutenção para instâncias com GPUs anexadas, consulte o artigo Faça a gestão de eventos de manutenção do anfitrião da GPU.

Para VMs de inquilino único, a frequência aproximada de eventos de manutenção planeada do anfitrião é de 4 a 6 semanas. O facto de a migração em direto ser suportada ou não depende da política de manutenção do anfitrião para a VM de inquilino único.

Erros do anfitrião

Um erro de anfitrião (compute.instances.hostError) significa que ocorreu um problema de hardware ou software na máquina física ou na infraestrutura do centro de dados que aloja a sua instância de computação, o que fez com que a instância falhasse. Um erro do anfitrião que envolva uma falha de hardware total ou outros problemas de hardware pode impedir a migração em direto da sua instância. Se a sua instância estiver definida para ser reiniciada automaticamente, que é a predefinição, o Compute Engine reinicia a instância, normalmente, no prazo de três minutos a partir do momento em que o erro foi detetado. Consoante o problema, o reinício pode demorar até 5,5 minutos.

Ocasionalmente, uma instância de computação pode deixar de responder antes de ser sinalizado um erro do anfitrião. Pode reduzir o tempo que o Compute Engine aguarda para reiniciar ou terminar a instância ao definir o limite de tempo de recuperação de erros do anfitrião. Para mais informações, consulte o artigo Defina políticas de disponibilidade.

As falhas físicas de hardware e software podem ocorrer ocasionalmente, mas são raras. Para proteger as suas aplicações e serviços destes eventos do sistema potencialmente disruptivos, reveja os seguintes recursos:

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

Vista geral da política de manutenção de anfitriões

A política de manutenção do anfitrião de uma instância determina o respetivo comportamento durante os seguintes eventos do anfitrião:

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

Pode configurar as instâncias para continuarem a ser executadas durante a manutenção do anfitrião, enquanto o Compute Engine as migra em direto para outro anfitrião, ou pode optar por parar a instância.

Pode alterar a política de manutenção do anfitrião de uma instância configurando as seguintes definições:

  • Comportamento de manutenção: se a instância é migrada em direto ou parada quando existe um evento de manutenção.
  • Comportamento de reinício: se o Compute Engine reinicia ou termina a instância se esta falhar, tiver um erro de anfitrião ou deixar de responder.
  • Tempo de deteção de erros do anfitrião: o tempo máximo que o Compute Engine aguarda para reiniciar ou terminar uma instância depois de detetar que a instância não está a responder.
  • Tempo de recuperação do SSD local: o tempo máximo que o Compute Engine dedica à recuperação dos dados em discos SSD locais após a deteção de um erro do anfitrião. Os dados do SSD local são perdidos se o tempo especificado decorrer sem uma recuperação bem-sucedida.

Pode atualizar a política de manutenção do anfitrião de uma instância em qualquer altura para controlar o comportamento das instâncias.

Comportamentos de manutenção e reinício

Quando ocorre um evento de anfitrião, a instância de computação pode usar a migração em direto ou a instância pode ser terminada. Se uma instância for terminada, pode optar por reiniciá-la manualmente ou fazer com que o Compute Engine a reinicie automaticamente.

As seguintes séries de máquinas podem não suportar a migração em direto e, em alternativa, requerem a terminação durante eventos do anfitrião:

Migre ao vivo

Por predefinição, a maioria dos tipos de instâncias está definida para migração em direto, excluindo os tipos de instâncias mencionados na secção anterior.

Durante a migração em direto, o Compute Engine migra automaticamente a sua instância de um evento de manutenção da infraestrutura, e a instância permanece em execução durante a migração. A sua instância pode ter um breve período de diminuição do desempenho, mas, em geral, a maioria das instâncias não deve ter um desempenho significativamente diferente. Isto é ideal para instâncias que requerem tempo de atividade constante e podem tolerar um curto período de diminuição do desempenho.

Quando o Compute Engine migra a sua instância, comunica um evento do sistema que é publicado na lista de operações de zona e nos registos de eventos do sistema. Pode rever este evento vendo as operações do Compute Engine para uma zona específica. Os eventos de migração em direto têm o seguinte tipo de operação:

compute.instances.migrateOnHostMaintenance

Terminar e reiniciar

Se não quiser que a sua instância seja migrada em direto ou se o seu tipo de instância não suportar a migração em direto, pode optar por permitir que oGoogle Cloud pare a instância quando ocorrer um evento do anfitrião. Com esta configuração, se ocorrer um evento de anfitrião, o Compute Engine envia um sinal de desligamento suave para encerrar a instância. Em seguida, aguarda 60 segundos para que a instância seja encerrada corretamente e define o estado da instância como TERMINATED. Se a instância não for encerrada corretamente em 60 segundos, é terminada à força.

Esta opção é ideal se as suas instâncias exigirem um desempenho máximo constante e se a sua aplicação geral for criada para processar falhas ou reinícios de instâncias.

Quando o Compute Engine para uma instância devido a um evento de anfitrião, comunica um evento do sistema que é publicado na lista de operações de zona e nos registos de eventos do sistema. Pode rever este evento vendo as operações do Compute Engine para uma zona específica. Os eventos de encerramento de instâncias têm o seguinte tipo de operação:

compute.instances.terminateOnHostMaintenance

Reinício automático

Se a sua instância estiver configurada para parar quando ocorrer um evento de manutenção ou se a sua instância falhar devido a um problema de hardware subjacente, o Compute Engine pode reiniciar automaticamente a instância. A instância é reiniciada no mesmo servidor anfitrião ou movida para outro servidor na mesma zona que não esteja a participar no evento de manutenção.

Por predefinição, o Compute Engine tenta recuperar instâncias com discos SSD locais anexados durante uma hora. Se o limite de tempo for atingido, o Compute Engine tenta reiniciar a instância num servidor anfitrião diferente na mesma zona. As instâncias Z3 e X4 têm tempos de espera predefinidos diferentes. Estes tipos de instâncias são reiniciados no mesmo servidor anfitrião após o encerramento da instância.

Para configurar o reinício automático, defina o campo da política de manutenção do anfitrião automaticRestart como true. Esta definição não se aplica se a instância for colocada offline devido a uma indisponibilidade zonal ou através de uma operação manual, como chamar sudo shutdown no SO convidado.

Quando o Compute Engine reinicia automaticamente a sua instância, comunica um evento do sistema que é publicado na lista de operações da zona. Pode rever este evento vendo as operações do Compute Engine para uma zona específica. Os eventos de reinício automático têm o seguinte tipo de operação:

compute.instances.automaticRestart

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

Uma vez que o Persistent Disk e o Hyperdisk são armazenamento associado à rede, quando a instância é reiniciada, o Compute Engine volta a associar o disco de arranque e todos os discos secundários à instância. Os dados nesses discos persistem durante a migração em direto e os reinícios de instâncias.

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

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

    • Configura a instância para a migração em direto e a instância passa por um evento de manutenção do anfitrião.
    • Ocorre um erro do anfitrião e o Compute Engine volta a ligar a instância aos discos SSD local dentro do limite de tempo.
    • Uma instância de computação com discos SSD locais anexados que suporta apenas a terminação e o reinício automático 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 anfitrião.

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

    • Encerra o sistema operativo convidado e força a paragem da instância.
    • Configura a instância para parar em eventos de manutenção do anfitrião e a instância passa por um evento de manutenção do anfitrião.
    • Ocorre um erro do anfitrião e o Compute Engine não consegue voltar a ligar os discos à instância antes do limite de tempo expirar. Neste caso, a instância é reiniciada sem recuperar os discos SSD locais. Quando a instância é reiniciada, o Compute Engine associa discos SSD locais em branco à instância reiniciada. Tem de formatar e montar estes discos antes de a instância os poder usar. Os dados nos discos SSD locais originais são irrecuperáveis.

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

Limite de tempo da recuperação do SSD local

Quando ocorre um erro de anfitrião, o Compute Engine tenta recuperar todos os discos SSD locais anexados à instância. Pode controlar a quantidade de tempo que o Compute Engine dedica a tentar recuperar os dados com a definição localSsdRecoveryTimeout da política do anfitrião.

Por predefinição, o Compute Engine dedica 1 hora à recuperação dos dados, mas os valores válidos para esta definição estão entre 0 e 168, em incrementos de 1 hora. Para instâncias Z3, o valor predefinido é 6, o que significa que as instâncias Z3 vão tentar recuperar os dados do SSD local durante 6 horas antes de atingir o limite de tempo limite.

Se definir o limite de tempo da recuperação do SSD local como 0, o Compute Engine não tenta recuperar nenhum disco SSD local associado. A instância é reiniciada assim que possível e os dados do SSD local são irrecuperáveis. Use esta configuração se a retoma da carga de trabalho for mais importante do que recuperar os dados do SSD local.

Se o limite de tempo de recuperação não estiver definido como 0, mas o limite de tempo for atingido antes de os dados do SSD local serem recuperados, o Compute Engine reinicia a instância sem o disco SSD local. O Compute Engine associa discos SSDs locais novos e vazios à instância reiniciada. Tem de formatar e montar estes discos antes de a instância os poder usar.

A instância encontra-se no estado REPAIRING enquanto o Compute Engine tenta recuperar os discos SSD locais. A instância e os discos SSD locais não estão disponíveis durante este período.

Se definir o limite de tempo de recuperação do SSD local para o valor máximo de 168, a instância permanece no estado REPAIRING durante um máximo de 7 dias enquanto o Compute Engine tenta recuperar os discos SSD local.

Pare a recuperação do disco SSD local

Pode interromper o processo de recuperação do disco SSD local antes de o Compute Engine atingir o limite de tempo limite de recuperação. Para tal, use o comando gcloud compute instances stop com a flag --discard-local-ssd=True.

Este comando para o processo de recuperação, para a instância de computação e rejeita os dados do SSD local. Em seguida, pode reiniciar a instância. Consulte o artigo Pare uma instância com SSD local para mais informações.

Esta opção não está disponível com instâncias Z3.

Para definir o limite de tempo da recuperação do SSD local, consulte o artigo Defina a política de manutenção do anfitrião da instância.

Agendamento de manutenção

Google Cloud oferece funcionalidades que permitem um controlo mais rigoroso da manutenção. Ao usar determinadas famílias de máquinas, pode especificar preferências de manutenção e receber notificações de eventos de manutenção futuros através do Cloud Logging, do servidor de metadados da instância, do comando compute instances describe da CLI gcloud ou do método instances.describe REST. Após a receção de uma notificação, tem um período durante o qual pode iniciar a manutenção agendada à hora que escolher. Se não acionar a manutenção agendada, o evento de manutenção ocorre no final do período de tempo da notificação, que é a hora agendada indicada na notificação.

Pode usar estas funcionalidades em combinação com a sua política de manutenção do anfitrião para personalizar uma agenda de manutenção adequada à sua carga de trabalho.

O que se segue?