Sobre eventos de hospedagem,Sobre eventos de hospedagem

Durante a vida útil de uma instância de máquina virtual (VM) ou de uma instância bare metal, a máquina host em que sua instância é executada pode experimentar 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 suas instâncias de VM e bare metal respondem durante ou após um evento de host configurando a política de manutenção de host .

Por padrão, a maioria das instâncias está configurada para migração em tempo real durante eventos de host. Você pode substituir esse comportamento e definir explicitamente as instâncias para encerrar e, opcionalmente, reiniciar. Alguns tipos de máquinas não suportam migração em tempo real, como instâncias bare metal ou VMs com GPUs anexadas. Essas instâncias terminam durante eventos de host. Para obter mais informações, consulte Comportamentos de manutenção e reinicialização .

Tipos de eventos anfitriões

Existem dois tipos de eventos de host, que são descritos com mais detalhes nas seções a seguir:

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

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 que as VMs sejam movidas para fora do servidor host. Se você ativar a política de manutenção do host de migração em tempo real para um tipo de instância compatível, o Compute Engine moverá a instância para um novo host e haverá interrupção mínima no seu aplicativo.

O Compute Engine também aplica alguns hipervisores leves e atualizações 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 , bem como do tipo de máquina. A tabela a seguir resume o comportamento dos eventos de manutenção planejada.

Locação de host Manutenção aproximada
frequência do evento		 Migração ao vivo suportada Seleção de anfitrião
Multilocatário (compartilhado) A cada 2 semanas Sim Mecanismo de computação
Inquilino único A cada 4 a 6 semanas Depende da política de manutenção do host Depende da política de manutenção do host
X4 Mínimo de 90 dias Não Mecanismo de computação
C3 Mínimo de 30 dias Não Mecanismo de computação

Para VMs de locatário individual, a frequência aproximada de eventos planejados de manutenção do host é a cada 4 a 6 semanas. O suporte ou não da migração ao vivo depende da política de manutenção do host da VM de locatário individual.

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 sua instância de computação que causou a falha da instância. Um erro de host envolvendo 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, que é a configuração padrão, o Compute Engine a reiniciará, normalmente dentro de 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.

Ocasionalmente, uma instância de computação pode parar de responder antes que um erro de host seja sinalizado. Você pode reduzir o tempo que o Compute Engine espera para reiniciar ou encerrar a instância definindo o tempo limite de recuperação de erros do host. Para obter mais informações, consulte Definir políticas de disponibilidade .

Falhas físicas de hardware e software podem acontecer ocasionalmente, mas são ocorrências raras. Para proteger seus aplicativos e serviços contra esses eventos de sistema potencialmente perturbadores, revise 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 de host de uma instância determina como ela se comporta durante os seguintes eventos de host:

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

Você pode configurar 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 sua instância.

Você pode alterar a política de manutenção do host de uma instância definindo as seguintes configuraçõ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 se ela falhar, sofrer um erro de host ou parar 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 após detectar que a instância não responde.
  • Tempo de recuperação de SSD local: o tempo máximo que o Compute Engine gasta recuperando os dados em discos SSD locais após detectar um erro de host. Os dados do SSD local serão perdidos se o tempo especificado decorrer sem uma recuperação bem-sucedida.

Você pode atualizar a política de manutenção do host de uma instância a qualquer momento para controlar como deseja que suas instâncias se comportem.

Comportamentos de manutenção e reinicialização

Quando ocorre um evento de host, a instância de computação pode usar a migração ao vivo ou a instância pode ser encerrada. Se uma instância for encerrada, você mesmo poderá optar por reiniciá-la ou fazer com que o Compute Engine a reinicie automaticamente.

As seguintes séries de máquinas não suportam migração em tempo real e, em vez disso, são encerradas durante eventos de host:

Migração ao vivo

Por padrão, a maioria dos tipos de instância são configurados para migração em tempo real , excluindo 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 de um evento de manutenção de infraestrutura, e ela permanece em execução durante a migração. Sua instância pode passar por um curto período de queda no desempenho, mas, em geral, a maioria das instâncias não deve ter um desempenho visivelmente diferente. Isso é ideal para instâncias que exigem tempo de atividade constante e podem tolerar um curto período de diminuição do desempenho.

Quando o Compute Engine migra sua instância, ele relata um evento do sistema que é publicado na lista de operações da zona e nos registros de eventos do sistema. Você pode revisar esse evento visualizando 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 sua 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, você poderá optar por permitirGoogle Cloud para interromper a instância quando ocorrer um evento de 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 suas instâncias exigirem desempenho máximo e constante e se seu aplicativo geral for criado para lidar com falhas ou reinicializações de instâncias.

Quando o Compute Engine interrompe uma instância devido a um evento de host, ele relata um evento do sistema que é publicado na lista de operações da zona e nos registros de eventos do sistema. Você pode revisar esse evento visualizando 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 sua instância estiver configurada para parar quando houver um evento de manutenção ou se ela falhar devido a um problema de hardware subjacente, o Compute Engine poderá reiniciá-la 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 Z3 e X4 têm tempos de espera padrão diferentes. Esses tipos de instância são reiniciados no mesmo servidor host após o encerramento da instância.

Para configurar a reinicialização automática, configure o campo de política de manutenção do host automaticRestart como true . Essa configuração não se aplica se a instância for colocada off-line devido a uma interrupção zonal ou por meio de uma ação do usuário, como chamar sudo shutdown no sistema operacional convidado.

Quando o Compute Engine reinicia automaticamente sua instância, ele relata um evento do sistema que é publicado na lista de operações de zona. Você pode revisar esse evento visualizando as operações do Compute Engine para uma zona específica. Os eventos de reinicialização automática possuem o seguinte tipo de operação:

compute.instances.automaticRestart

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

Porque Disco Permanente eHiperdiscos são armazenamentos conectados à rede. Quando a instância é reiniciada, o Compute Engine reconecta o disco de inicialização e quaisquer discos secundários à instância. Os dados nesses discos persistem durante a migração em tempo real e reinicializações de instâncias.

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

  • Os discos SSD locais serão preservados se:

    • Você configura sua instância para migração em tempo real e a instância passa por um evento de manutenção de host.
    • Ocorre um erro de host e o Compute Engine reconecta a instância aos discos SSD locais dentro do limite de tempo limite.
    • Uma instância de computação com discos SSD locais anexados que suporta apenas encerramento e reinicialização automática passa por um evento de manutenção. A instância é reiniciada, preservando os dados do SSD local, em vez de migrar para um novo host.

  • Os discos SSD locais não serão preservados se:

    • Você desliga o sistema operacional convidado e força a parada da instância.
    • Você configura a instância para parar em eventos de manutenção de host e a instância passa por um evento de manutenção de host.
    • Ocorre um erro de host e o Compute Engine não consegue reconectar os discos à instância antes que o tempo limite expire. Neste 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. Você deve formatar e montar esses discos antes que a instância possa usá-los. Os dados nos discos SSD locais originais são irrecuperáveis.

Google Cloud faz o possível para garantir que os dados do SSD local permaneçam intactos. No entanto, há casos em que os dados não podem ser recuperados, como um caso de tempo limite. Para obter mais informações sobre quando os discos SSD locais são preservados, consulte Persistência de dados SSD local .

Tempo limite de recuperação de SSD local

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

Por padrão, o Compute Engine gasta 1 hora recuperando os dados, mas os valores válidos para essa configuração estão entre 0 e 168, em incrementos de 1 hora. Para instâncias Z3, o valor padrão é 6, o que significa que as instâncias Z3 tentarão recuperar os dados do SSD local por 6 horas antes de atingir o limite de tempo limite.

Se você definir o tempo limite de recuperação do SSD local como 0, o Compute Engine não tentará recuperar nenhum disco SSD local anexado. A instância é reiniciada assim que possível e os dados do SSD local ficam irrecuperáveis. Use esta 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 que os dados do SSD local sejam recuperados, o Compute Engine reiniciará a instância sem o disco SSD local. O Compute Engine anexa discos SSD locais novos e em branco à instância reiniciada. Você deve formatar e montar esses discos antes que a instância possa usá-los.

A instância está 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 para o valor máximo de 168, a instância permanecerá no estado REPAIRING por até sete dias enquanto o Compute Engine tenta recuperar os discos SSD locais.

Pare a recuperação do disco SSD local

Você pode interromper o processo de recuperação do disco SSD local antes que o Compute Engine atinja o limite de tempo limite de recuperação. Para fazer isso, use o comando gcloud compute instances stop com a sinalização --discard-local-ssd=True .

Este comando interrompe o processo de recuperação, interrompe a instância de computação e descarta os dados do SSD local . Você pode então reiniciar a instância. Consulte Interromper uma instância com SSD local para obter mais informações.

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

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 fornece recursos que permitem um controle mais rígido da manutenção. Ao usar determinadas famílias de máquinas , você pode especificar preferências de manutenção e receber notificações de eventos de manutenção futuros por meio do Cloud Logging, do servidor de metadados da instância, do comando gcloud CLI compute instances describe ou do método REST instances.describe . Ao receber uma notificação , você tem um período de tempo para iniciar a manutenção programada no horário que desejar. Se você não acionar a manutenção agendada, o evento de manutenção ocorrerá no final do período de notificação, que é o horário agendado listado na notificação.

Você pode usar esses recursos em combinação com sua política de manutenção do host para personalizar um cronograma de manutenção adequado à sua carga de trabalho.

O que vem a seguir

,

Durante a vida útil de uma instância de máquina virtual (VM) ou de uma instância bare metal, a máquina host em que sua instância é executada pode experimentar 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 suas instâncias de VM e bare metal respondem durante ou após um evento de host configurando a política de manutenção de host .

Por padrão, a maioria das instâncias está configurada para migração em tempo real durante eventos de host. Você pode substituir esse comportamento e definir explicitamente as instâncias para encerrar e, opcionalmente, reiniciar. Alguns tipos de máquinas não suportam migração em tempo real, como instâncias bare metal ou VMs com GPUs anexadas. Essas instâncias terminam durante eventos de host. Para obter mais informações, consulte Comportamentos de manutenção e reinicialização .

Tipos de eventos anfitriões

Existem dois tipos de eventos de host, que são descritos com mais detalhes nas seções a seguir:

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

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 que as VMs sejam movidas para fora do servidor host. Se você ativar a política de manutenção do host de migração em tempo real para um tipo de instância compatível, o Compute Engine moverá a instância para um novo host e haverá interrupção mínima no seu aplicativo.

O Compute Engine também aplica alguns hipervisores leves e atualizações 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 , bem como do tipo de máquina. A tabela a seguir resume o comportamento dos eventos de manutenção planejada.

Locação de host Manutenção aproximada
frequência do evento		 Migração ao vivo suportada Seleção de anfitrião
Multilocatário (compartilhado) A cada 2 semanas Sim Mecanismo de computação
Inquilino único A cada 4 a 6 semanas Depende da política de manutenção do host Depende da política de manutenção do host
X4 Mínimo de 90 dias Não Mecanismo de computação
C3 Mínimo de 30 dias Não Mecanismo de computação

Para VMs de locatário individual, a frequência aproximada de eventos planejados de manutenção do host é a cada 4 a 6 semanas. O suporte ou não da migração ao vivo depende da política de manutenção do host da VM de locatário individual.

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 sua instância de computação que causou a falha da instância. Um erro de host envolvendo 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, que é a configuração padrão, o Compute Engine a reiniciará, normalmente dentro de 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.

Ocasionalmente, uma instância de computação pode parar de responder antes que um erro de host seja sinalizado. Você pode reduzir o tempo que o Compute Engine espera para reiniciar ou encerrar a instância definindo o tempo limite de recuperação de erros do host. Para obter mais informações, consulte Definir políticas de disponibilidade .

Falhas físicas de hardware e software podem acontecer ocasionalmente, mas são ocorrências raras. Para proteger seus aplicativos e serviços contra esses eventos de sistema potencialmente perturbadores, revise 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 de host de uma instância determina como ela se comporta durante os seguintes eventos de host:

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

Você pode configurar 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 sua instância.

Você pode alterar a política de manutenção do host de uma instância definindo as seguintes configuraçõ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 se ela falhar, sofrer um erro de host ou parar 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 após detectar que a instância não responde.
  • Tempo de recuperação de SSD local: o tempo máximo que o Compute Engine gasta recuperando os dados em discos SSD locais após detectar um erro de host. Os dados do SSD local serão perdidos se o tempo especificado decorrer sem uma recuperação bem-sucedida.

Você pode atualizar a política de manutenção do host de uma instância a qualquer momento para controlar como deseja que suas instâncias se comportem.

Comportamentos de manutenção e reinicialização

Quando ocorre um evento de host, a instância de computação pode usar a migração ao vivo ou a instância pode ser encerrada. Se uma instância for encerrada, você mesmo poderá optar por reiniciá-la ou fazer com que o Compute Engine a reinicie automaticamente.

As seguintes séries de máquinas não suportam migração em tempo real e, em vez disso, são encerradas durante eventos de host:

Migração ao vivo

Por padrão, a maioria dos tipos de instância são configurados para migração em tempo real , excluindo 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 de um evento de manutenção de infraestrutura, e ela permanece em execução durante a migração. Sua instância pode passar por um curto período de queda no desempenho, mas, em geral, a maioria das instâncias não deve ter um desempenho visivelmente diferente. Isso é ideal para instâncias que exigem tempo de atividade constante e podem tolerar um curto período de diminuição do desempenho.

Quando o Compute Engine migra sua instância, ele relata um evento do sistema que é publicado na lista de operações da zona e nos registros de eventos do sistema. Você pode revisar esse evento visualizando 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 sua 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, você poderá optar por permitirGoogle Cloud para interromper a instância quando ocorrer um evento de 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 suas instâncias exigirem desempenho máximo e constante e se seu aplicativo geral for criado para lidar com falhas ou reinicializações de instâncias.

Quando o Compute Engine interrompe uma instância devido a um evento de host, ele relata um evento do sistema que é publicado na lista de operações da zona e nos registros de eventos do sistema. Você pode revisar esse evento visualizando 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 sua instância estiver configurada para parar quando houver um evento de manutenção ou se ela falhar devido a um problema de hardware subjacente, o Compute Engine poderá reiniciá-la 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 Z3 e X4 têm tempos de espera padrão diferentes. Esses tipos de instância são reiniciados no mesmo servidor host após o encerramento da instância.

Para configurar a reinicialização automática, configure o campo de política de manutenção do host automaticRestart como true . Essa configuração não se aplica se a instância for colocada off-line devido a uma interrupção zonal ou por meio de uma ação do usuário, como chamar sudo shutdown no sistema operacional convidado.

Quando o Compute Engine reinicia automaticamente sua instância, ele relata um evento do sistema que é publicado na lista de operações de zona. Você pode revisar esse evento visualizando as operações do Compute Engine para uma zona específica. Os eventos de reinicialização automática possuem o seguinte tipo de operação:

compute.instances.automaticRestart

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

Porque Disco Permanente eHiperdiscos são armazenamentos conectados à rede. Quando a instância é reiniciada, o Compute Engine reconecta o disco de inicialização e quaisquer discos secundários à instância. Os dados nesses discos persistem durante a migração em tempo real e reinicializações de instâncias.

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

  • Os discos SSD locais serão preservados se:

    • Você configura sua instância para migração em tempo real e a instância passa por um evento de manutenção de host.
    • Ocorre um erro de host e o Compute Engine reconecta a instância aos discos SSD locais dentro do limite de tempo limite.
    • Uma instância de computação com discos SSD locais anexados que suporta apenas encerramento e reinicialização automática passa por um evento de manutenção. A instância é reiniciada, preservando os dados do SSD local, em vez de migrar para um novo host.

  • Os discos SSD locais não serão preservados se:

    • Você desliga o sistema operacional convidado e força a parada da instância.
    • Você configura a instância para parar em eventos de manutenção de host e a instância passa por um evento de manutenção de host.
    • Ocorre um erro de host e o Compute Engine não consegue reconectar os discos à instância antes que o tempo limite expire. Neste 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. Você deve formatar e montar esses discos antes que a instância possa usá-los. Os dados nos discos SSD locais originais são irrecuperáveis.

Google Cloud faz o possível para garantir que os dados do SSD local permaneçam intactos. No entanto, há casos em que os dados não podem ser recuperados, como um caso de tempo limite. Para obter mais informações sobre quando os discos SSD locais são preservados, consulte Persistência de dados SSD local .

Tempo limite de recuperação de SSD local

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

Por padrão, o Compute Engine gasta 1 hora recuperando os dados, mas os valores válidos para essa configuração estão entre 0 e 168, em incrementos de 1 hora. Para instâncias Z3, o valor padrão é 6, o que significa que as instâncias Z3 tentarão recuperar os dados do SSD local por 6 horas antes de atingir o limite de tempo limite.

Se você definir o tempo limite de recuperação do SSD local como 0, o Compute Engine não tentará recuperar nenhum disco SSD local anexado. A instância é reiniciada assim que possível e os dados do SSD local ficam irrecuperáveis. Use esta 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 que os dados do SSD local sejam recuperados, o Compute Engine reiniciará a instância sem o disco SSD local. O Compute Engine anexa discos SSD locais novos e em branco à instância reiniciada. Você deve formatar e montar esses discos antes que a instância possa usá-los.

A instância está 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 para o valor máximo de 168, a instância permanecerá no estado REPAIRING por até sete dias enquanto o Compute Engine tenta recuperar os discos SSD locais.

Pare a recuperação do disco SSD local

Você pode interromper o processo de recuperação do disco SSD local antes que o Compute Engine atinja o limite de tempo limite de recuperação. Para fazer isso, use o comando gcloud compute instances stop com a sinalização --discard-local-ssd=True .

Este comando interrompe o processo de recuperação, interrompe a instância de computação e descarta os dados do SSD local . Você pode então reiniciar a instância. Consulte Interromper uma instância com SSD local para obter mais informações.

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

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 fornece recursos que permitem um controle mais rígido da manutenção. Ao usar determinadas famílias de máquinas , você pode especificar preferências de manutenção e receber notificações de eventos de manutenção futuros por meio do Cloud Logging, do servidor de metadados da instância, do comando gcloud CLI compute instances describe ou do método REST instances.describe . Ao receber uma notificação , você tem um período de tempo para iniciar a manutenção programada no horário que desejar. Se você não acionar a manutenção agendada, o evento de manutenção ocorrerá no final do período de notificação, que é o horário agendado listado na notificação.

Você pode usar esses recursos em combinação com sua política de manutenção do host para personalizar um cronograma de manutenção adequado à sua carga de trabalho.

O que vem a seguir