Partilhar via

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

  • Artigo

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

Às vezes, as máquinas virtuais (VMs) do Azure podem ser reinicializadas sem motivo aparente, sem evidências de que você iniciou a operação de reinicialização. Este artigo lista as ações e eventos que podem causar a reinicialização das VMs e fornece informações sobre como evitar problemas inesperados de reinicialização ou reduzir o impacto de tais problemas.

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 VMs para alta disponibilidade.

Para fornecer esse nível de redundância ao seu aplicativo, recomendamos que você agrupe duas 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 esteja disponível e atenda a 99,95 por cento do Azure SLA.

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

Informações de saúde do recurso

Azure Resource Health é um serviço que expõe a integridade de recursos individuais do Azure e fornece orientação acionável 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. Em particular, o objetivo é reduzir o tempo que você gasta determinando se a raiz do problema está no aplicativo ou em um evento dentro da plataforma Azure. Para obter mais informações, consulte Entender e usar a Integridade do Recurso.

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 ausentes da VM no log de atividades

Os alertas de Integridade do Recurso são enviados com base nas informações do registro 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 aparecer no log de atividades, os alertas de Integridade do recurso não serão enviados para o tempo de inatividade. O tempo de inatividade ainda é visível no Resource Health.

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

  • Quando uma VM é criada ou migrada para um novo host, a plataforma Azure não exibe o estado da VM corretamente e o estado muda para Desconhecido. Somente depois que toda a conectividade de rede e processos de nó forem estabelecidos, o estado da VM mudará 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 depois volta para Disponível em 35 segundos, o tempo de inatividade não aparece no log de atividades. Este caso não ocorrerá se um downtime correlacionado for enviado 15 minutos antes da ocorrência da primeira transição.
  • Se a integridade da VM mudar de um estado para Desconhecido e, em seguida, voltar ao estado original, o estado Desconhecido intermitente e as transições relacionadas serão filtrados do log de atividades.

Os tempos de inatividade da VM que não aparecem no log de atividades são filtrados no lado da plataforma 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 fazer com que alterações rápidas na integridade da VM não sejam 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 causar a reinicialização da VM

Manutenção planejada

O Microsoft Azure realiza periodicamente atualizações em todo o mundo para melhorar a confiabilidade, o desempenho e a segurança da infraestrutura de host subjacente às VMs. Muitas dessas atualizações, incluindo atualizações de preservação de memória, são executadas sem qualquer impacto em suas VMs ou serviços em nuvem.

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

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

Atualizações de preservação de memória

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

Essas atualizações de preservação de memória são realizadas com tecnologia que permite a migração ao vivo no local. Quando 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 as atualizações e correções necessárias. A VM é retomada normalmente em 30 segundos após a pausa. Depois que a VM é retomada, seu relógio é sincronizado automaticamente.

Devido ao curto período de pausa, a implantação de atualizações por meio desse mecanismo reduz bastante o impacto nas VMs. No entanto, nem todas as atualizações podem ser implantadas dessa maneira.

As atualizações de várias 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 possuem versões antigas do kernel são afetadas por um kernel panic durante este método de atualização. Para evitar esse problema, atualize para a versão do kernel 3.10.0-327.10.1 ou posterior. Para obter mais informações, consulte Uma VM Azure Linux em um kernel baseado em 3.10 entra em pânico após uma atualização de nó de host.

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

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

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

Outros cenários que geralmente causam a reinicialização da VM incluem várias ações de alteração de configuração. Normalmente, você verá uma mensagem de aviso indicando que a execução de uma determinada ação resultará na reinicialização da VM. Os exemplos incluem qualquer operação de redimensionamento da VM, alteração da senha da conta administrativa e configuração de um endereço IP estático.

Microsoft Defender para nuvem e atualização do Windows

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

Assim como os servidores locais, o Azure não envia atualizações do Windows Update para VMs do Windows, porque essas máquinas devem ser gerenciadas por seus usuários. Você é, no entanto, encorajado a deixar a configuração automática do Windows Update habilitada. A instalação automática de atualizações do Windows Update também pode causar reinicializações após a aplicação das atualizações. Para obter mais informações, consulte Perguntas Frequentes sobre o Windows Update.

Outras situações que afetam a disponibilidade da sua VM

Há outros casos em que o Azure pode suspender ativamente o uso de uma VM. Você receberá notificações por e-mail antes que essa ação seja executada, para ter a chance de resolver os problemas subjacentes. Exemplos de problemas que afetam a disponibilidade da VM incluem violações de segurança e expiração de métodos de pagamento.

Falhas do servidor host

A VM é hospedada em um servidor físico em execução em um datacenter do Azure. O servidor físico executa um agente chamado Host Agent, 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 aciona uma reinicialização do servidor host para tentar a recuperação. Em muitos casos, a VM ficará disponível novamente em 10 a 15 minutos e continua a residir no mesmo host de antes.

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

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

Recuperação automática

A plataforma do Azure foi projetada para lidar com problemas de nó de host com impacto mínimo no desempenho da VM. Quando um nó de host encontra um problema, o Azure primeiro tenta o método de recuperação menos disruptivo, que é reinicializar o host. Se a reinicialização do host não for possível ou se o problema original estiver relacionado ao hardware, o serviço de plataforma corrigirá todas as VMs no host afetado para um nó íntegro. Embora a reinicialização de um host geralmente tenha um impacto menor, as VMs de reparo de serviço podem ser mais complexas e demoradas, dependendo do número de VMs, suas restrições de implantação e disponibilidade de recursos locais. A recuperação de serviço normalmente é usada como último recurso para falhas de hardware, pois garante que as VMs continuem operando sem tempo de inatividade significativo.

Se um servidor host não puder reinicializar, o Azure iniciará uma ação de recuperação automática para tirar o host defeituoso da rotação para uma investigação mais aprofundada. Durante esse processo de recuperação automática, todas as VMs no host são realocadas automaticamente para outro servidor host íntegro. Embora esse processo geralmente seja concluído em 15 minutos, o tempo de recuperação pode variar com base em fatores como o tamanho da memória do host e os métodos de recuperação usados. Para obter mais detalhes sobre como o Azure lida com esses cenários, consulte Reparo do Serviço – Recuperação automática de máquinas virtuais.

Manutenção não planejada

Em raras ocasiões, a equipe de operações do Azure pode precisar realizar atividades de manutenção para garantir a integridade geral da plataforma Azure. Esse comportamento pode afetar a disponibilidade da VM e geralmente 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 urgentes do switch de rede

VM falha

As VMs podem reiniciar devido a problemas na própria VM. A carga de trabalho ou função em execução na VM pode acionar uma verificação de bug no sistema operacional convidado. Para obter ajuda para determinar o motivo da falha, exiba os logs do sistema e do aplicativo para VMs do Windows e os logs seriais para VMs do Linux.

As VMs no Azure dependem de discos virtuais para sistema operacional e armazenamento de dados hospedados na infraestrutura de armazenamento do Azure. Sempre que a disponibilidade ou conectividade entre a VM e os discos virtuais associados for afetada por mais de 120 segundos, a plataforma Azure executa um desligamento forçado das VMs para evitar corrupção de dados. As VMs são religadas automaticamente após a restauração da conectividade de armazenamento. A duração do desligamento pode ser tão curta quanto cinco minutos, mas pode ser significativamente mais longa.

Outros incidentes

Em raras circunstâncias, um problema generalizado pode afetar vários servidores em um datacenter do Azure. Se esse problema ocorrer, a equipe do Azure enviará notificações por email para as assinaturas afetadas. Você pode verificar o painel do Azure Service Health e o portal do Azure para obter o status de interrupções contínuas e incidentes anteriores.

Diagnosticar reinicializações de VM

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

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.