Entender uma reinicialização do sistema para Azure VM

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

Resumo

As máquinas virtuais (VMs) do Azure podem às vezes ser reinicializadas aparentemente sem motivo, sem evidência de que você iniciou a operação de reinicialização da máquina. 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 planejado ou não planejado, pelo menos uma VM esteja disponível e atenda aos 99,95% Azure SLA.

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

Informações sobre Resource Health

Azure Resource Health é um serviço que expõe a integridade de recursos de Azure individuais 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. Em particular, o objetivo é reduzir o tempo gasto determinando se a raiz do problema está no aplicativo ou em um evento dentro da plataforma Azure. Para obter mais informações, consulte Understand e use Resource Health.

Se a 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 publicadas na saúde do recurso até 72 horas após a indisponibilidade inicial.

Ausência de tempos de inatividade da VM no log de atividades

alertas de Integridade de Recursos 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 aparecer no log de atividades, alertas do Resource Health não serão enviados. O tempo de inatividade ainda está visível em 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, Azure plataforma não exibe o estado da VM corretamente e o estado é alterado 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 dentro de 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 são exibidos no log de atividades são filtrados no lado da plataforma Azure para evitar que erros transitórios mostrem tempos de inatividade incorretos aos 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. Microsoft está trabalhando em um plano de transição para proporcionar a melhor experiência ao cliente.

Ações e eventos que podem causar a reinicialização da VM

Manutenção planejada

Microsoft Azure executa periodicamente atualizações em todo o mundo para melhorar a confiabilidade, o desempenho e a segurança da infraestrutura de host que está por trás das 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 é Azure manutenção planejada e como ela pode afetar a disponibilidade de suas VMs linux, consulte os artigos listados aqui. Os artigos fornecem informações detalhadas sobre o Azure processo de manutenção planejada e como agendar a manutenção planejada para reduzir ainda mais o impacto.

• Manutenção planejada para VMs no Azure
• Como agendar a manutenção planejada em VMs Azure Windows
• Como agendar manutenção planejada em VMs Linux no Azure

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

Para essa classe de atualizações em Microsoft Azure, os usuários não enfrentam 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.

Atualizações de várias instâncias (para VMs em um conjunto de disponibilidade) são aplicadas em um domínio de atualização de cada vez.

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

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

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 Windows Update

Microsoft Defender para Nuvem monitora diariamente as VMs Windows e Linux para atualizações do sistema operacional ausentes. Defender para Nuvem recupera uma lista de atualizações críticas e de segurança disponíveis do Windows Update ou do WSUS (Serviços de Atualização Windows Server), dependendo de qual serviço está configurado em uma VM Windows. Defender para Nuvem também verifica se há atualizações mais recentes para sistemas Linux. Se a VM não tiver uma atualização do sistema, 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, as reinicializações da VM podem ser necessárias. Para obter mais informações, consulte Aplicar atualizações de sistema no Microsoft Defender para Nuvem.

Assim como os servidores locais, Azure não envia atualizações por push de Windows Update para Windows VMs, pois esses computadores devem ser gerenciados por seus usuários. No entanto, você é incentivado a deixar a configuração de Windows Update automática habilitada. A instalação automática de atualizações de Windows Update também pode fazer com que as reinicializações ocorram após a aplicação das atualizações. Para obter mais informações, consulte Windows Update perguntas frequentes.

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

Há outros casos em que 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 que está em execução dentro de um datacenter Azure. O servidor físico executa um agente chamado Agente de Host, além de alguns outros componentes Azure. Quando esses Azure componentes de software no servidor físico ficam sem resposta, o sistema de monitoramento dispara 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. Azure monitora continuamente essas ocorrências, identifica os bugs subjacentes e distribui atualizações depois que a mitigação é 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 disparada usando a opção redeploy na página de detalhes da VM ou parando e reiniciando a VM no portal Azure.

Recuperação automática

A plataforma Azure foi projetada para lidar com problemas no nó do host com impacto mínimo no desempenho da VM. Quando um nó de host encontra um problema, 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 o problema estiver relacionado ao hardware, Azure iniciará uma ação de recuperação automática para tirar o host defeituoso da rotação para uma investigação mais aprofundada. Como parte dessa recuperação automática, um processo conhecido como recuperação de serviço realocará automaticamente todas as VMs no host defeituoso para outra íntegro. Esse processo geralmente é concluído em 15 minutos, embora o tempo de recuperação possa variar dependendo de fatores como o tamanho da memória do host e os métodos de recuperação usados. A recuperação de serviço normalmente é usada como último recurso para falhas de hardware para garantir que as VMs continuem operando sem tempo de inatividade significativo.

Para obter mais detalhes sobre como Azure lida com esses cenários, consulte Service Healing – Recuperação automática de Máquinas Virtuais.

Manutenção não planejada

Em raras ocasiões, a equipe de operações de 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 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 ser reiniciadas devido a problemas internos de VM ou problemas de hardware, como um problema de disco do sistema operacional, conforme descrito anteriormente. A carga de trabalho ou a função em execução na VM pode disparar uma verificação de bug no sistema operacional convidado. Para encontrar o motivo da falha, verifique os logs do sistema e do aplicativo para Windows VMs e os logs serial para VMs do Linux. Coletar um dump de memória geralmente é a melhor maneira de identificar a causa raiz.

Para obter mais informações, consulte os seguintes artigos:

• Informações de despejo de memória de falhas do Windows
• Informações de despejo de falha do Linux

Desligamentos forçados relacionados ao armazenamento

As VMs no Azure dependem de discos virtuais para o sistema operacional e o armazenamento de dados hospedados na infraestrutura Armazenamento do Azure. Sempre que a disponibilidade ou conectividade entre a VM e os discos virtuais associados é afetada por mais de 180 segundos, a plataforma Azure executa um desligamento forçado das VMs para evitar a 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 circunstâncias raras, um problema generalizado pode afetar vários servidores em um datacenter Azure. Se esse problema ocorrer, a equipe de Azure enviará notificações por email para as assinaturas afetadas. Você pode verificar o painel Integridade do Serviço do Azure e o portal Azure para obter o status de interrupções contínuas e incidentes passados.

Diagnosticar reinicializações de VM

Você pode usar a aba Diagnosticar e Resolver na aba 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 de sistema operacional convidado (Guest OS), colete um dump de memória e entre em contato com o suporte.