Entender uma reinicialização do sistema para VM do Azure

Aplica-se a: ✔️ VMs do Linux ✔️ VMs do Windows

As VMs (máquinas virtuais) do Azure às vezes podem reinicializar sem motivo aparente, sem prova de que você iniciou a operação de reinicialização. Este artigo lista as ações e os eventos que podem fazer com que as VMs reinicializem e forneçam informações sobre como evitar problemas de reinicialização inesperada ou reduzir o impacto desse tipo de problema.

Configurar as VMs para alta disponibilidade

A melhor maneira de proteger um aplicativo em execução no Azure contra reinicializações de VM e tempo de inatividade é configurar as máquinas virtuais para alta disponibilidade.

Para oferecer esse nível de redundância ao seu aplicativo, recomendamos que agrupe uma ou mais VMs em um conjunto de disponibilidade. Essa configuração garante que durante um evento de manutenção planejada ou não planejada, pelo menos uma VM estará disponível e atenderá os 99,95% de SLA do Azure.

Para obter mais informações sobre conjuntos de disponibilidade, consulte Gerenciar a disponibilidade de VMs

Informações do Resource Health

O Azure Resource Health é um serviço que expõe a integridade de recursos individuais do Azure e fornece diretrizes acionáveis para solucionar problemas. Em um ambiente de nuvem em que não é possível acessar diretamente servidores ou elementos de infraestrutura, o objetivo do Resource Health é reduzir o tempo gasto na solução de problemas. O objetivo é, especificamente, reduzir o tempo gasto determinando se a causa do problema está no aplicativo ou em um evento da plataforma Azure. Para saber mais, confira Compreender e usar o Resource Health.

Se o Azure tiver mais informações sobre a causa raiz de uma indisponibilidade iniciada pela plataforma para uma Máquina Virtual, essas informações poderão ser postadas na integridade do recurso até 72 horas após a indisponibilidade inicial.

Tempos de inatividade da VM ausentes no log de atividades

Os alertas do Resource Health são enviados com base nas informações do Log de atividades . Em alguns casos, os tempos de inatividade da VM podem não aparecer no log de atividades. Se o tempo de inatividade não for exibido no log de atividades, os alertas do Resource Health não serão enviados para o tempo de inatividade. O tempo de inatividade ainda está visível no Resource Health.

Aqui estão os casos em que os tempos de inatividade da VM não são exibidos no log de atividades:

  • Quando uma VM é criada ou migrada para um novo host, a plataforma do Azure não exibe o estado da VM corretamente e o estado é alterado para Desconhecido. Somente depois que todos os processos de nó e conectividade de rede forem estabelecidos, o estado da VM será alterado para Disponível. O período prolongado do estado Desconhecido é filtrado do log de atividades.
  • Quando o estado de disponibilidade da VM muda de Disponível para Indisponível e, em seguida, volta para Disponível em 35 segundos, o tempo de inatividade não é exibido no log de atividades. Esse caso não ocorrerá se um tempo de inatividade correlacionado for enviado dentro de 15 minutos antes da ocorrência da primeira transição.
  • Se a integridade da VM mudar de um estado para Desconhecido e depois voltar para o estado original, o estado intermitente Desconhecido e as transições relacionadas serão filtrados do log de atividades.

Os tempos de inatividade da VM que não são mostrados no log de atividades são filtrados no lado da plataforma do Azure para evitar que erros transitórios mostrem tempos de inatividade incorretos para os clientes. Com investimentos contínuos na qualidade da integridade da VM, os filtros podem não ser mais necessários e podem fazer com que alterações rápidas na integridade da VM permaneçam não relatadas. A Microsoft está trabalhando em um plano de eliminação gradual para oferecer a melhor experiência ao cliente.

Ações e eventos que podem fazer a VM reiniciar

Manutenção planejada

O Microsoft Azure realiza atualizações periodicamente em todo o mundo para aumentar a confiabilidade, o desempenho e a segurança da infraestrutura de host subjacente a VMs. Muitas dessas atualizações, incluindo atualizações com preservação de memória, são realizadas sem nenhum impacto sobre as VMs ou os serviços de nuvem.

No entanto, algumas atualizações requerem uma reinicialização. Nesses casos, as VMs são desligadas enquanto renovamos a infraestrutura e depois são reiniciadas.

Para compreender o que é a manutenção planejada do Azure e como ela pode afetar a disponibilidade de suas VMs Linux, confira os artigos listados aqui. Os artigos fornecem informações detalhadas sobre o processo de manutenção planejada do Azure e como agendar a manutenção planejada para reduzir ainda mais o impacto.

Atualizações que preservam a memória

Para essa classe de atualizações no Microsoft Azure, os usuários não têm impacto em suas VMs em execução. Muitas dessas atualizações são componentes ou serviços que podem ser atualizados sem interferir na instância em execução. Algumas são as atualizações de infraestrutura de plataforma no sistema operacional do host que podem ser aplicadas sem a reinicialização das VMs.

Essas atualizações com preservação de memória são realizadas com a tecnologia que permite a migração ao vivo local. Quando ela está sendo atualizada, a VM é colocada em um estado pausado. Esse estado preserva a memória na RAM enquanto o sistema operacional do host subjacente recebe os patches e as atualizações necessárias. A VM é retomada normalmente dentro de 30 segundos após ser pausada. Depois que a VM é reiniciada, seu relógio é sincronizado automaticamente.

Devido à pequena pausa, a implantação de atualizações por meio desse mecanismo reduz consideravelmente o impacto sobre as VMs. No entanto, nem todas as atualizações podem ser implantadas dessa maneira.

Atualizações de múltiplas instâncias (para VMs em um conjunto de disponibilidade) são aplicadas em um domínio de atualização por vez.

Observação

As máquinas Linux que têm versões antigas do kernel são afetadas por um pânico de kernel durante esse método de atualização. Para evitar esse problema, atualize para o kernel versão 3.10.0-327.10.1 ou versão posterior. Para saber mais, confira Uma VM Linux do Azure em um kernel com base em 3.10 sofre pane após uma atualização de nó host.

Ações de reinicialização ou desligamento iniciadas pelo usuário

Se você executar uma reinicialização no portal do Azure, no Azure PowerShell, na interface de linha de comando ou na API REST, poderá encontrar o evento no Log de Atividades do Azure.

Se você executar a ação do sistema operacional da VM, poderá encontrar o evento nos logs do sistema.

Outro cenário que geralmente faz com que a VM reinicie inclui várias ações de configuração. Você normalmente verá uma mensagem de aviso que indica que a execução de determinada ação resultará em uma reinicialização da VM. Exemplos incluem operações de redimensionamento da VM, alteração da senha da conta administrativa e definição de endereço IP estático.

Microsoft Defender para Nuvem e Windows Update

O Microsoft Defender para Nuvem monitora diariamente as VMs do Windows e do Linux em busca de atualizações ausentes do sistema operacional. O Defender para Nuvem recupera uma lista de atualizações críticas e de segurança disponíveis do Windows Update ou do Windows Server Update Services (WSUS), dependendo de qual serviço está configurado em uma VM do Windows. O Defender para Nuvem também verifica as atualizações mais recentes para sistemas Linux. Se a VM não tiver uma atualização do sistema, o Defender para Nuvem recomenda que você aplique atualizações do sistema. A aplicação dessas atualizações do sistema é controlada por meio do Defender para Nuvem no portal do Azure. Depois de aplicar algumas atualizações, pode ser necessário reiniciar algumas VMs. Para obter mais informações, consulte Aplicar atualizações do sistema no Microsoft Defender para Nuvem.

Assim como os servidores locais, o Azure não efetua push de atualizações do Windows Update para VMs do Windows porque essas máquinas devem ser gerenciadas pelos próprios usuários. No entanto, é recomendável que os clientes deixem a configuração automática do Windows Update habilitada. A instalação automática de atualizações do Windows Update pode causar reinicializações após a aplicação. Para saber mais, confira Perguntas frequentes sobre o Windows Update.

Outras situações que afetam a disponibilidade da VM

Há outros casos em que o Azure pode suspender ativamente o uso de uma VM. Você receberá notificações de email antes da ação para ter a oportunidade de resolver problemas subjacentes. Violações de segurança e a expiração de métodos de pagamento são exemplos de problemas que afetam a disponibilidade da VM.

Falhas do servidor host

A máquina virtual está hospedada em um servidor físico que está em execução dentro de um datacenter do Azure. O servidor físico é executado em um agente chamado o Agente Host, além de alguns outros componentes do Azure. Quando esses componentes de software do Azure no servidor físico param de responder, o sistema de monitoramento dispara uma reinicialização do servidor host para tentar recuperá-los. Em muitos casos, a VM estará disponível novamente dentro de 10 a 15 minutos e continuará a residir no mesmo host de antes.

As falhas de servidor normalmente são causadas por falha de hardware, como falha de um disco rígido ou de uma unidade de estado sólido. O Azure monitora essas ocorrências continuamente, identifica os bugs subjacentes e distribui atualizações depois que a mitigação é implantada e testada.

Como algumas falhas de servidor host podem ser específicas desse servidor, uma situação de reinicialização VM repetida pode ser melhorada com a reimplantação manual da VM em outro servidor host. Essa operação pode ser acionada usando a opção reimplantação na página de detalhes da VM ou interrompendo e reiniciando a máquina virtual no portal do Azure.

Recuperação automática

Se o servidor host não puder ser reiniciado por qualquer motivo, a plataforma do Azure iniciará uma ação de recuperação automática para remover o servidor host e investigar.

Todas as máquinas virtuais no host são realocadas automaticamente para um servidor host diferente e íntegro. Embora esse processo normalmente seja concluído dentro de 15 minutos, o tempo necessário para a recuperação pode variar dependendo de vários fatores, incluindo o tamanho da memória do host e os métodos de recuperação empregados. Para saber mais sobre o processo de recuperação automática, confira Recuperação automática de VMs.

Manutenção não planejada

Em raras ocasiões, a equipe de operações do Azure pode precisar executar atividades de manutenção para garantir a integridade geral da plataforma Azure. Esse comportamento pode afetar a disponibilidade da VM e normalmente resulta na mesma ação de recuperação automática descrita anteriormente.

A manutenção não planejada inclui o seguinte:

  • Desfragmentação de nó urgente
  • Atualizações de comutador de rede urgentes

Falhas de VM

Máquinas virtuais podem ser reiniciadas devido a problemas de dentro da VM. A carga de trabalho ou função em execução na VM pode disparar uma verificação de bug no sistema operacional convidado. Para ajudar a determinar o motivo da falha, exiba os logs de sistema e do aplicativo para VMs Windows e logs seriais para VMs Linux.

As VMs no Azure dependem de discos virtuais para o sistema operacional e o armazenamento de dados que é hospedado na infraestrutura do Armazenamento do Azure. Sempre que a disponibilidade ou a conectividade entre a VM e os discos virtuais associados é afetada por mais de 120 segundos, a plataforma Azure executa um desligamento forçado das VMs para evitar dados corrompidos. As VMs são ativadas automaticamente novamente depois que a conectividade de armazenamento é restaurada. A duração do desligamento pode demorar mais de cinco minutos, mas também pode ser significativamente maior.

Outros incidentes

Em raras circunstâncias, um problema mais amplo pode afetar vários servidores em um data center do Azure. Se esse problema ocorrer, a equipe do Azure envia notificações por email para assinaturas afetadas. Você pode verificar o painel de integridade do serviço Azure e o portal do Azure para ver o status de interrupções e incidentes passados.

Diagnosticar reinicializações de VM

Você pode usar a folha Diagnosticar e Resolver na folha da VM para executar diagnósticos adicionais. Isso pode revelar motivos mais específicos para a reinicialização recente da VM. Se houver algum problema do sistema operacional convidado, colete o despejo de memória e o suporte ao contato.

Entre em contato conosco para obter ajuda

Se você tiver dúvidas ou precisar de ajuda, crie uma solicitação de suporte ou peça ajuda à comunidade de suporte do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.