Manutenção para máquinas virtuais no Azure

Aplica-se a: ✔️ VMs do Linux ✔️ VMs do Windows ✔️ Conjuntos de dimensionamento flexíveis ✔️ Conjuntos de dimensionamento uniformes

O Azure atualiza a plataforma periodicamente para aprimorar a confiabilidade, o desempenho e a segurança da infraestrutura de host para máquinas virtuais. A finalidade dessas atualizações vai desde a aplicação de patch de componentes de software no ambiente de hospedagem até a atualização de componentes de rede ou o encerramento de hardware.

As atualizações raramente afetam as VMs hospedadas. Quando as atualizações têm um efeito, o Azure escolhe o método menos impactante de atualizações:

• Se a atualização não exigir uma reinicialização, a VM será pausada, enquanto o host é atualizado ou a VM é migrada ao vivo para um host já atualizado.

• Se a atualização exigir uma reinicialização, Azure notificará você sobre a manutenção planejada. O Azure também fornece uma janela de tempo, na qual você pode iniciar a manutenção, em um momento mais oportuno para você. A janela de automanutenção depende do tipo de manutenção:

  • Descomissionamento de hardware: A janela de automanutenção normalmente é de 14 dias.
  • Manutenção do host: a janela de autoatendimento normalmente é de 35 dias, a menos que a manutenção seja urgente.

  Azure está investindo em tecnologias para reduzir o número de casos em que a manutenção planejada da plataforma exige que as VMs sejam reinicializadas. Para obter instruções sobre como gerenciar a manutenção planejada, consulte Como lidar com notificações de manutenção planejada usando o CLI do Azure, o PowerShell ou o portal.

Esta página descreve como o Microsoft Azure executa os dois tipos de manutenção. Para obter mais informações sobre eventos não planejados (interrupções), confira Gerenciar a disponibilidade das VMs para Windows ou o artigo correspondente para Linux.

De uma VM, você pode obter notificações sobre manutenção futura usando os Eventos Agendados para Windows ou para Linux.

Manutenção que não exige uma reinicialização

A maioria das atualizações de plataforma não afeta as VMs do cliente. Quando uma atualização sem impacto não é possível, o Azure escolhe o mecanismo de atualização menos impactante para as VMs dos clientes.

Quando a VM que afeta a manutenção é necessária, ela quase sempre será concluída por meio de uma pausa de VM por menos de 10 segundos. Em circunstâncias raras, não mais do que uma vez a cada 18 meses para tamanhos de VM de uso geral, o Azure usa um mecanismo que pausará a VM por cerca de 30 segundos. Após qualquer operação de pausa, o relógio da VM é sincronizado automaticamente após a retomada.

A manutenção de preservação de memória funciona para mais de 90% das VMs do Azure. Não funciona para as séries G, L, N e H. Para obter mais informações, consulte quais tamanhos de VM dão suporte à manutenção de preservação de memória. Cada vez mais, o Azure usa tecnologias de migração ao vivo e aprimora o mecanismo de manutenção de preservação de memória para reduzir as durações da pausa.

Essas operações de manutenção que não exigem uma reinicialização são aplicadas a um domínio de falha por vez. Elas serão interrompidas se receberem sinais de integridade de aviso das ferramentas de monitoramento de plataforma. As operações de manutenção que não exigem uma reinicialização podem ocorrer simultaneamente nas regiões emparelhadas ou Zonas de Disponibilidade. Para determinada alteração, a implantação é sequenciada principalmente entre Zonas de Disponibilidade e entre pares regionais, mas pode haver sobreposição na parte final.

Esses tipos de atualizações podem afetar alguns aplicativos. Quando a VM é migrada ao vivo para um host diferente, algumas cargas de trabalho confidenciais podem mostrar uma ligeira degradação do desempenho em alguns minutos que levam a pausar a máquina virtual. Para se preparar para a manutenção da VM e reduzir o impacto durante a manutenção do Azure, experimente usar os Eventos Agendados para Windows ou Linux para esses aplicativos.

Para obter maior controle sobre todas as atividades de manutenção, incluindo impacto zero e atualizações sem reinicialização, você pode criar um recurso de Configuração de Manutenção. A criação de uma Configuração de Manutenção oferece a opção de ignorar todas as atualizações de plataforma e aplicar as atualizações no momento que você escolher. Para obter mais informações, confira Gerenciar atualizações da plataforma com as Configurações de Manutenção.

Migração ao vivo

A migração ao vivo é uma operação que não exige uma reinicialização e preserva a memória da VM. Ela causa uma pausa ou um congelamento, normalmente com duração não superior a cinco segundos. Com exceção das séries G, L, N e H, todas as VMs IaaS (infraestrutura como serviço) são qualificadas para migração ao vivo. A migração em tempo real está disponível na maioria dos modelos da Série M. As VMs qualificadas representam mais de 90% das VMs de IaaS implantadas na frota do Azure.

A plataforma do Azure dispara a migração ao vivo nos seguintes cenários:

• Manutenção planejada
• Falha de hardware
• Otimizações de alocação

Alguns cenários de manutenção planejada usam a migração ao vivo, e você pode usar Eventos Agendados para saber com antecedência quando as operações de migração ao vivo serão iniciadas.

A migração dinâmica também pode ser usada para mover VMs quando algoritmos do Azure Machine Learning prevêem uma falha de hardware iminente ou otimização de alocações de VM. Para obter mais informações sobre modelagem preditiva que detecta instâncias de hardware degradado, confira Improving Azure VM resiliency with predictive machine learning and live migration (Aprimorar a resiliência da VM do Azure com o machine learning de previsão e a migração ao vivo). As notificações de migração ao vivo aparecem na portal do Azure nos logs de Monitoramento e de Integridade do Serviço, bem como nos Eventos Agendados se você usar esses serviços.

Resiliência de conexão TCP durante a migração ao vivo

Aplicativos que mantêm conexões TCP de longa duração, como servidores de banco de dados, agentes de mensagens e camadas de cache, podem sofrer interrupção de conexão durante a migração dinâmica. Embora a pausa da VM seja normalmente inferior a 5 segundos, o comportamento da pilha TCP durante e após a pausa pode estender o tempo de recuperação no nível do aplicativo se não for resolvido.

Como a migração dinâmica afeta as conexões TCP:

• Durante a pausa, os segmentos TCP em trânsito não são confirmados pela VM em migração.
• O lado remetente (cliente ou investigação de integridade do balanceador de carga) inicia a retransmissão TCP com retirada exponencial.
• Azure Standard Load Balancer envia um TCP RST para conexões ociosas que excedem o tempo limite ocioso configurado. No entanto, para conexões ativas com dados em trânsito, o balanceador de carga não envia um TCP RST durante a pausa da migração. A conexão permanece aberta, mas sem resposta, e o cliente não tem nenhum sinal imediato de falha.
• Sem ajuste no nível do aplicativo, o comportamento de retransmissão TCP padrão (tcp_retries2 = 15 no Linux) pode atrasar a detecção de falhas de conexão em aproximadamente 15 minutos.

Reduzir o raio de explosão com implantações de várias instâncias:

Antes de aplicar mitigações de nível TCP, considere a linha de base arquitetônica. A migração ao vivo afeta uma VM de cada vez dentro de um conjunto de disponibilidade ou conjunto de dimensionamento de máquinas virtuais. A disseminação de conexões entre várias instâncias de back-end limita o impacto de qualquer evento de migração única:

• Um conjunto de dimensionamento com três instâncias significa que cada evento de migração afeta no máximo um terço das conexões ativas.
• A implantação em Zonas de Disponibilidade garante que as migrações em zonas diferentes não se sobreponham.
• Os clientes com pools de conexão distribuídos em vários back-ends se recuperam mais rapidamente porque as conexões não afetadas continuam atendendo solicitações imediatamente.

Durante a pausa da VM, as sondas de integridade do Azure Standard Load Balancer para o back-end em pausa também falham. O balanceador de carga marca o backend como não saudável em aproximadamente 10 segundos (duas falhas consecutivas na sondagem no intervalo padrão de 5 segundos) e para de rotear novas conexões para ele. Essa condição significa que novas conexões são protegidas naturalmente. As mitigações TCP descritas neste artigo abordam conexões existentes que já foram estabelecidas antes do início da migração.

Mitigações recomendadas:

As mitigações a seguir são complementares. Quando implementados juntos, eles reduzem o impacto de um evento de migração ao vivo de minutos de tempo de inatividade potencial para segundos de recuperação automática.

Mitigação 1: TCP_USER_TIMEOUT (detecção mais rápida)

TCP_USER_TIMEOUT controla por quanto tempo o kernel aguarda a confirmação dos dados transmitidos antes de declarar uma conexão morta. Definir isso como 30 segundos (30000 ms) por soquete reduz significativamente o tempo de detecção.

// Per-socket (recommended)
int timeout = 30000; // 30 seconds in milliseconds
setsockopt(fd, IPPROTO_TCP, TCP_USER_TIMEOUT, &timeout, sizeof(timeout));

Alternativamente, reduza a contagem de retransmissões em todo o sistema:

# /etc/sysctl.conf — reduces retransmit ceiling to ~25-50 seconds
net.ipv4.tcp_retries2 = 5

Considerações sobre o Windows:

A opção TCP_USER_TIMEOUT de soquete é específica para o Linux. Em Windows, o comportamento de retransmissão do TCP é controlado de forma diferente:

• Windows usa como padrão cinco retransmissões (TcpMaxDataRetransmissions), que já fornecem aproximadamente 25 a 50 segundos de tempo de detecção sem nenhum ajuste.
• Para reduzir ainda mais o tempo de detecção em Windows, ajuste o registro:

# Reduce TCP retransmissions (system-wide, requires reboot)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" `
    -Name "TcpMaxDataRetransmissions" -Value 3 -Type DWord

Com TcpMaxDataRetransmissions definido como 3, o tempo de detecção reduz para aproximadamente 10 a 20 segundos, dependendo do tempo limite de retransmissão inicial.

Mitigação 2: Eventos Agendados (esvaziamento proativo)

O serviço eventos agendados fornece aviso prévio antes do início de uma migração ao vivo. Os aplicativos podem escutar eventos Freeze e drenar proativamente as conexões antes que a pausa ocorra.

GET http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01
Headers: Metadata: true

Um evento de migração ao vivo é exibido como:

{
  "EventType": "Freeze",
  "ResourceType": "VirtualMachine",
  "Resources": ["myVM"],
  "EventStatus": "Scheduled",
  "NotBefore": "2026-04-29T18:00:00Z"
}

Quando um Freeze evento é detectado:

1. Pare de aceitar novas conexões no nó afetado.
2. Escorra as conexões existentes (sinalize os clientes para se reconectarem a outros nós).
3. Aguarde a conclusão das operações em andamento com um tempo limite definido.
4. Opcionalmente, confirme o evento postando de volta a EventId.

Mitigação 3: Ajuste do keepalive do TCP

As sondas de keepalive do TCP detectam conexões que se tornam ociosas após o evento de migração:

net.ipv4.tcp_keepalive_time = 30      # seconds before first probe (default: 7200)
net.ipv4.tcp_keepalive_intvl = 10     # seconds between probes (default: 75)
net.ipv4.tcp_keepalive_probes = 3     # probes before declaring dead (default: 9)

Com essas configurações, uma conexão obsoleta ociosa é detectada dentro de 60 segundos (30 + 10 x 3). As sondagens de keepalive também contam como atividade para o tempo limite ocioso do Load Balancer padrão, impedindo que o balanceador de carga expire conexões ociosas de forma independente.

Mitigação 4: lógica de nova tentativa do lado do cliente

A reconexão no nível do aplicativo e a lógica de repetição garantem a recuperação independentemente do método de detecção de falhas:

1. Detectar erro de conexão (tempo limite, RST ou conexão recusada).
2. Feche a conexão morta e remova-a do pool de conexões.
3. Abra uma nova conexão com o mesmo nó ou com um nó diferente.
4. Tente novamente a operação com recuo exponencial.

Para SDKs de banco de dados e pools de conexões, habilite verificações de integridade periódicas (por exemplo, um ping leve a cada 10 a 15 segundos) para validar as conexões proativamente.

Configuração do pool de conexões:

Pools de conexões que mantêm conexões de longa duração se beneficiam de uma configuração de tempo de vida máximo. Essa configuração força a reciclagem periódica de conexão, garantindo que nenhuma conexão única acumule risco não associado de eventos de migração futuros:

Definir um tempo de vida máximo de 30 minutos significa que, mesmo sem verificações de integridade ativas, as conexões são naturalmente substituídas antes que possam permanecer obsoletas por longos períodos sem detecção.

Monitoramento e observabilidade:

Para detectar e medir o impacto dos eventos de migração ao vivo em conexões TCP, use as seguintes abordagens:

• Azure Monitor métrica de disponibilidade da VM (versão prévia): cai para 0 durante a pausa da VM. Crie uma regra VmAvailabilityMetric de alerta com um limite inferior a 1 para detectar eventos de migração.
• Log de Atividades de Eventos Agendados: Os eventos de migração dinâmica aparecem no Log de Atividades sob o provedor Microsoft.Compute, com o nome da operação Microsoft.Compute/virtualMachines/liveMigration/action, ou como eventos Freeze quando consultados pelo Serviço de Metadados.
• Taxa de erro de conexão no nível do aplicativo: Monitore as redefinições de conexão TCP, os tempos limite e as contagens de reconexão nas métricas do aplicativo. Um pico nos erros de conexão correlacionando-se com uma queda de disponibilidade de VM confirma o impacto na migração.
• Contadores de retransmissão TCP: No Linux, monitore /proc/net/netstat o campo TCPTimeouts ou use ss -ti para observar contagens de retransmissão em soquetes individuais. Retransmissões elevadas durante uma janela de manutenção conhecida indicam que as conexões foram afetadas.

# Linux: Check TCP timeout statistics
cat /proc/net/netstat | grep -i timeout
# Or per-socket retransmission info
ss -ti | grep -i retrans

Estabelecer uma linha de base para essas métricas durante a operação normal torna simples quantificar o impacto dos eventos de migração e validar que suas mitigações estão funcionando conforme o esperado.

Cargas de trabalho com tolerância zero para interrupção da migração em tempo real

Para cargas de trabalho que não podem tolerar nenhuma interrupção causada pela migração ao vivo, considere usar Hosts Dedicados do Azure com Configurações de manutenção. Os Hosts Dedicados permitem que você controle quando ocorre a manutenção no nível do host, eliminando migrações ao vivo inesperadas.

Manutenção que requer uma reinicialização

Quando as VMs precisarem ser reinicializadas para manutenção planejada, você será notificado com antecedência. A manutenção planejada tem duas fases: uma fase de autoatendimento e uma fase de manutenção agendada.

Durante a fase de autoatendimento, que geralmente dura quatro semanas, você inicia a manutenção em suas VMs. Como parte do autoatendimento, você pode consultar cada VM para ver o status e o resultado de sua última solicitação de manutenção.

Quando você inicia a manutenção de autoatendimento, sua VM é reimplantada em um nó já atualizado. Como a VM é reimplantada, o disco temporário é perdido e os endereços IP dinâmicos públicos associados ao adaptador de rede virtual são atualizados.

Se surgir um erro durante a manutenção de autoatendimento, a operação será interrompida, a VM não será atualizada e você terá a opção de tentar novamente a manutenção de autoatendimento.

Quando a fase de autoatendimento termina, a fase de manutenção agendada é iniciada. Durante essa fase, você ainda pode consultar a fase de manutenção, mas não pode iniciar a manutenção por conta própria.

Para obter mais informações sobre como gerenciar a manutenção que exige uma reinicialização, confira Lidar com notificações de manutenção planejada usando a CLI do Azure, o PowerShell ou o portal.

Considerações sobre disponibilidade durante a manutenção agendada

Se você decidir aguardar até a fase de manutenção agendada, há alguns aspectos a serem considerados para manter a disponibilidade mais alta de suas VMs.

Regiões emparelhadas

Cada região do Azure é emparelhada com outra na mesma proximidade geográfica. Juntas, elas fazem um par de regiões. Durante a fase de manutenção agendada, o Azure atualiza somente as VMs em uma só região de um par de regiões. Por exemplo, ao atualizar a VM no Centro-Norte dos EUA, o Azure não atualiza nenhuma VM no Centro-Sul dos EUA ao mesmo tempo. No entanto, outras regiões, como o Norte da Europa, podem estar em manutenção simultaneamente com Leste dos EUA. Noções básicas sobre como funcionam os pares de região podem ajudá-lo a melhor distribuir suas VMs entre regiões. Para obter mais informações, consulte pares de regiões do Azure.

Zonas de disponibilidade

As zonas de disponibilidade são locais físicos exclusivos em uma região do Azure. Cada zona é composta por um ou mais datacenters equipados com energia, resfriamento e rede independentes. Para garantir a resiliência, há um mínimo de três zonas separadas em todas as regiões habilitadas.

Uma zona de disponibilidade é uma combinação de um domínio de falha e um domínio de atualização. Se você criar três ou mais VMs em três zonas em uma região do Azure, as VMs serão efetivamente distribuídas em três domínios de falha e três domínios de atualização. A plataforma do Azure reconhece essa distribuição nos domínios de atualização para garantir que as VMs em diferentes zonas não sejam atualizadas ao mesmo tempo.

Cada atualização de infraestrutura é distribuída zona por zona, dentro de uma só região. No entanto, você pode ter uma implantação em andamento na Zona 1 e uma implantação diferente em andamento na Zona 2, ao mesmo tempo. Implantações não são todas serializadas. Porém, uma única implantação que exige uma reinicialização distribui apenas uma zona de cada vez para reduzir o risco. Em geral, as atualizações que exigem uma reinicialização são evitadas quando possível e o Azure tenta usar a Migração Dinâmica ou fornecer controle aos clientes.

conjuntos de escala de máquina virtual

Os conjuntos de dimensionamento de máquinas virtuais no modo de orquestração flexível são um recurso de computação do Azure que permite combinar a escalabilidade dos conjuntos de dimensionamento de máquinas virtuais no modo de orquestração uniforme com as garantias de disponibilidade regional dos conjuntos de disponibilidade.

Com a orquestração flexível, é possível escolher se suas instâncias são espalhadas por diversas zonas ou por domínios de falha em uma única região.

Conjuntos de disponibilidade e conjuntos de dimensionamento uniformes

Ao implantar uma carga de trabalho usando VMs do Azure, é possível criar as VMs em um conjunto de disponibilidade para fornecer alta disponibilidade para o aplicativo. Usando conjuntos de disponibilidade, você pode garantir que, durante uma interrupção ou eventos de manutenção que exijam uma reinicialização, pelo menos uma VM esteja disponível.

Em um conjunto de disponibilidade, VMs individuais são distribuídas em até 20 domínios de atualização. Durante a manutenção agendada, somente um domínio é atualizado em um período específico. Os domínios de atualização não são necessariamente atualizados em sequência.

Os conjuntos de dimensionamento de máquinas virtuais no modo de orquestração uniforme são um recurso de computação do Azure que pode ser usado para implantar e gerenciar um conjunto de VMs idênticas como um único recurso. O conjunto de dimensionamento é implantado automaticamente nos UDs, como VMs em um conjunto de disponibilidade. Assim como nos conjuntos de disponibilidade, ao usar conjuntos de dimensionamento uniforme, apenas um UD é atualizado por vez durante a manutenção agendada.

Para obter mais informações sobre como configurar suas VMs para alta disponibilidade, consulte Gerenciar a disponibilidade das VMs para Windows ou o artigo correspondente para Linux.

Próximas etapas

Para gerenciar a manutenção planejada, use o CLI do Azure, Azure PowerShell ou o portal.