Manutenção de 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 periodicamente a sua plataforma para melhorar a fiabilidade, o desempenho e a segurança da infraestrutura de anfitrião para máquinas virtuais. O objetivo destas atualizações vai da correção de componentes de software no ambiente anfitrião à atualização de componentes de rede ou desativação de hardware.

As atualizações raramente afetam as VMs alojadas. Quando as atualizações têm efeito, o Azure escolhe o método com menos impacto para as atualizações:

• Se a atualização não exigir um reinício, a VM será colocada em pausa enquanto o anfitrião é atualizado ou a VM será migrada em direto para um anfitrião já atualizado.

• Se a atualização exigir um reinício, o Azure notifica-o da manutenção planeada. O Azure também fornece uma janela de tempo na qual o utilizador pode iniciar a manutenção, num momento que lhe for conveniente. A janela de manutenção automática depende do tipo de manutenção:

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

  A Azure está a investir em tecnologias para reduzir o número de casos em que a manutenção planeada da plataforma exige o reinício das VMs. Para instruções sobre como gerir a manutenção planeada, consulte Gestão de notificações de manutenção planeada usando o CLI do Azure, PowerShell ou portal.

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

Dentro de uma VM, você pode receber notificações sobre manutenção futura usando Eventos Agendados para Windows ou Linux.

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

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

Quando a manutenção com impacto na VM é necessária, ela quase sempre será concluída por meio de uma pausa da 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 oferecem suporte à manutenção de preservação de memória. O Azure usa cada vez mais tecnologias de migração ao vivo e melhora os mecanismos de manutenção de preservação de memória para reduzir as durações de pausa.

Essas operações de manutenção que não exigem uma reinicialização são aplicadas um domínio de falha de cada vez. Eles param se receberem sinais de saúde de aviso das ferramentas de monitoramento da plataforma. As operações de manutenção que não exigem uma reinicialização podem ocorrer simultaneamente em regiões emparelhadas ou zonas de disponibilidade. Para uma determinada alteração, as implementações são maioritariamente sequenciadas entre Zonas de Disponibilidade e entre pares de Regiões, mas pode haver sobreposição na fase 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 de desempenho nos poucos minutos que antecedem a pausa da VM. Para se preparar para a manutenção de VM e reduzir o impacto durante a manutenção do Azure, tente usar Eventos Agendados para Windows ou Linux para esses aplicativos.

Para maior controle sobre todas as atividades de manutenção, incluindo atualizações de impacto zero e sem reinicialização, você pode criar um recurso de Configuração de Manutenção. A criação de uma Configuração de Manutenção dá-lhe a opção de ignorar todas as atualizações da plataforma e aplicar as atualizações à sua escolha. Para obter mais informações, consulte Gerenciando atualizações de plataforma com configurações de manutenção.

Migração em direto

A migração em direto é uma operação que não requer uma reinicialização e que preserva a memória da VM. Provoca uma pausa ou congelamento, normalmente não durando mais de 5 segundos. Com exceção das séries G, L, N e H, todas as VMs de infraestrutura como serviço (IaaS) são qualificadas para migração ao vivo. A migração ao vivo está disponível na maioria das SKUs da série M. As VMs qualificadas representam mais de 90% das VMs IaaS implantadas na frota do Azure.

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

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

Alguns cenários de manutenção planejada usam 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 em tempo real também pode ser usada para mover VMs quando algoritmos de Aprendizagem Automática do Azure prevêem uma falha de hardware iminente ou otimização das alocações de VMs. Para obter mais informações sobre a modelagem preditiva que deteta instâncias de hardware degradado, consulte Melhorando a resiliência da VM do Azure com aprendizado de máquina preditivo e migração ao vivo. As notificações de migração em direto aparecem no portal do Azure, nos registos do Azure Monitor e do Estado de Funcionamento do Serviço, bem como em Eventos Agendados, se utilizar estes serviços.

Resiliência da ligação TCP durante migração em tempo real

Aplicações que mantêm ligações TCP de longa duração, como servidores de base de dados, brokers de mensagens e camadas de cache, podem sofrer interrupções de ligação durante a migração em tempo real. Embora a pausa da VM seja tipicamente inferior a 5 segundos, o comportamento da pilha TCP durante e após a pausa pode prolongar o tempo de recuperação ao nível da aplicação se não for resolvido.

Como a migração em tempo real afeta as ligações TCP:

• Durante a pausa, os segmentos TCP em voo não são reconhecidos pela VM em migração.
• O lado emissor (sonda de saúde do cliente ou do balanceador de carga) inicia a retransmissão TCP com recuo exponencial.
• Azure Balanceador de Carga Standard envia um TCP RST para ligações inativas que excedam o timeout de inatividade configurado. No entanto, para ligações ativas com dados em voo, o balanceador de carga não envia um TCP RST durante a pausa de migração. A ligação mantém-se aberta mas sem resposta, e o cliente não tem qualquer sinal imediato de falha.
• Sem sintonia ao nível da aplicação, o comportamento padrão de retransmissão TCP (tcp_retries2 = 15 no Linux) pode atrasar a deteção de falhas de ligação em aproximadamente 15 minutos.

Reduza o raio de explosão com implantações multi-instância:

Antes de aplicar mitigações ao nível TCP, considere a linha base arquitetónica. A migração em direto afeta uma VM de cada vez num conjunto de disponibilidade ou num conjunto de dimensionamento de máquinas virtuais. Distribuir as ligações por várias instâncias de backend limita o impacto de um único evento de migração:

• Um conjunto de escalas com três instâncias significa que cada evento de migração afeta, no máximo, um terço das ligações ativas.
• A implementação em várias zonas de disponibilidade assegura que as migrações em diferentes zonas não se sobreponham.
• Os clientes com pools de ligações distribuídos por múltiplos backends recuperam mais rapidamente porque as ligações não afetadas continuam a servir pedidos imediatamente.

Durante a pausa da VM, as sondas de estado de funcionamento do Azure Balanceador de Carga Standard para o backend em pausa também falham. O balanceador de carga marca o backend como pouco saudável em aproximadamente 10 segundos (duas falhas consecutivas da sonda no intervalo padrão de 5 segundos) e impede de encaminhar novas ligações para ele. Esta condição significa que as novas ligações são naturalmente protegidas. As mitigações de TCP descritas neste artigo abordam ligações existentes que já estavam estabelecidas antes do início da migração.

Mitigações recomendadas:

As seguintes mitigações são complementares. Quando implementados em conjunto, reduzem o impacto de um evento de migração em tempo real de minutos de inatividade potencial para segundos de recuperação automática.

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

TCP_USER_TIMEOUT Controla quanto tempo o kernel espera pelo reconhecimento dos dados transmitidos antes de declarar uma ligação como morta. Definir isto para 30 segundos (30000 ms) por socket reduz significativamente o tempo de deteção.

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

Em alternativa, reduza o número 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 TCP_USER_TIMEOUT opção socket é específica para Linux. No Windows, o comportamento de retransmissão TCP é controlado de forma diferente:

• O Windows define por defeito 5 retransmissões (TcpMaxDataRetransmissions), o que já proporciona aproximadamente 25-50 segundos de tempo de deteção sem qualquer sintonia.
• Para reduzir ainda mais o tempo de deteção no Windows, ajuste o registo:

# 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 deteção é reduzido para aproximadamente 10-20 segundos, dependendo do tempo limite inicial de retransmissão.

Mitigação 2: Eventos Programados (drenagem proativa)

O serviço de Eventos Programados fornece aviso prévio antes do início da migração em direto. As aplicações podem detetar eventos Freeze e encerrar as ligações de forma preventiva antes de ocorrer a pausa.

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

Um evento de migração ao vivo aparece como:

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

Quando um Freeze evento é detetado:

1. Deixe de aceitar novas ligações no nó afetado.
2. Drenar as ligações existentes (sinalizar os clientes para se reconectarem a outros nós).
3. Aguardar que as operações em curso se concluam dentro de um limite de tempo definido.
4. Opcionalmente, reconheça o evento publicando de volta o EventId.

Mitigação 3: ajuste do TCP keepalive

As sondas TCP keepalive detetam ligações que ficam inativas 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 estas definições, uma ligação inativa e obsoleta é detetada em 60 segundos (30 + 10 x 3). As sondagens Keepalive também contam como atividade para o tempo limite de inatividade do Balanceador de Carga Standard, impedindo que o balanceador de carga encerre por tempo limite as ligações inativas de forma independente.

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

A lógica de reconexão e repetição ao nível da aplicação assegura a recuperação, independentemente do método de deteção de falhas:

1. Detetar erro de ligação (timeout, RST ou ligação recusada).
2. Fecha a ligação morta e remove-a do pool de ligações.
3. Abra uma nova ligação ao mesmo nó ou a outro diferente.
4. Tente novamente a operação com recuo exponencial.

Para SDKs de bases de dados e pools de ligações, permita verificações periódicas de saúde (por exemplo, um ping leve a cada 10-15 segundos) para validar as ligações de forma proativa.

Configuração do pool de ligações:

Os pools de ligações que mantêm ligações de longa duração beneficiam de uma definição de tempo de vida máximo. Esta configuração obriga a reciclagem periódica da ligação, garantindo que nenhuma ligação individual acumule risco ilimitado devido a futuros eventos de migração:

Definir uma vida útil máxima de 30 minutos significa que, mesmo sem verificações de saúde ativas, as ligações são naturalmente restauradas antes de acumularem longos períodos de estagnação não detetada.

Monitorização e observabilidade:

Para detetar e medir o impacto de eventos de migração em tempo real nas ligações TCP, utilize as seguintes abordagens:

• Azure Monitor VM Availability Metric (Preview): Desce para 0 durante a pausa da VM. Crie uma regra de alerta em VmAvailabilityMetric com um limiar inferior a 1 para detetar eventos de migração.
• Registo de atividades dos eventos agendados: Os eventos de migração em direto aparecem no Registo de Atividades sob o fornecedor Microsoft.Compute, com o nome de operação Microsoft.Compute/virtualMachines/liveMigration/action, ou como eventos Freeze quando consultados através do Serviço de Metadados.
• Taxa de erro de ligação ao nível da aplicação: Monitoriza os resets, timeouts e contagens de reconexão TCP nas métricas da tua aplicação. Um pico nos erros de ligação correlacionados com uma queda na Disponibilidade de VM confirma o impacto da migração.
• Contadores de retransmissão TCP: No Linux, monitore /proc/net/netstat o campo TCPTimeouts ou use ss -ti para observar as contagens de retransmissão em sockets 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 estas métricas durante o funcionamento normal torna simples quantificar o impacto dos eventos de migração e validar que as suas mitigações estão a funcionar como 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 qualquer interrupção durante a migração em direto, considere utilizar Azure Dedicated Hosts com Configurações de manutenção. Os Hosts Dedicados permitem-lhe controlar quando ocorre a manutenção ao nível do servidor anfitrião, eliminando migrações em direto inesperadas.

Manutenção que requer uma reinicialização

No caso raro em que as VMs precisam ser reinicializadas para manutenção planejada, você será notificado com antecedência. A manutenção planejada tem duas fases: a fase de autoatendimento e a fase de manutenção programada.

Durante a fase de autoatendimento, que normalmente dura quatro semanas, você inicia a manutenção em suas VMs. Como parte do autoatendimento, você pode consultar cada VM para ver seu status e o resultado da 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 à interface 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 repetir a manutenção de autoatendimento.

Quando a fase de autoatendimento termina, a fase de manutenção programada começa. Durante essa fase, você ainda pode consultar a fase de manutenção, mas não pode iniciar a manutenção sozinho.

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

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

Se você decidir esperar até a fase de manutenção agendada, há algumas coisas que você deve considerar para manter a mais alta disponibilidade de suas VMs.

Regiões emparelhadas

Cada região do Azure é emparelhada com outra região dentro da mesma vizinhança geográfica. Em conjunto, formam um par de regiões. Durante a fase de manutenção agendada, o Azure atualiza apenas as VMs numa única 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 a Europa do Norte, podem estar em manutenção ao mesmo tempo que o Leste dos EUA. Compreender como os pares de regiões funcionam pode ajudá-lo a distribuir melhor 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 dentro de uma região do Azure. Cada zona é composta por um ou mais datacenters equipados com energia, refrigeração e rede independentes. Para garantir 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, suas VMs serão efetivamente distribuídas em três domínios de falha e três domínios de atualização. A plataforma Azure reconhece essa distribuição entre domínios de atualização para garantir que as VMs em zonas diferentes não sejam atualizadas ao mesmo tempo.

Cada atualização de infraestrutura é implantada zona por zona, dentro de uma única região. Mas pode ter uma implementação a decorrer na Zona 1 e uma implementação diferente na Zona 2, ao mesmo tempo. As implantações não são todas serializadas. Mas, uma única implantação que exija 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 ao Vivo ou fornecer controle aos clientes.

Conjuntos de dimensionamento de máquinas virtuais

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

Com a orquestração flexível, você pode escolher se suas instâncias estão espalhadas por várias zonas ou entre domínios de falha em uma única região.

Conjuntos de disponibilidade e conjuntos de escalas uniformes

Ao implementar uma carga de trabalho em VMs do Azure, pode criar as VMs num conjunto de disponibilidade para garantir elevada disponibilidade à sua aplicação. Utilizando conjuntos de disponibilidade, pode garantir que, durante uma indisponibilidade ou eventos de manutenção que exijam um reinício, pelo menos uma VM esteja disponível.

Dentro de um conjunto de disponibilidade, as VMs individuais são distribuídas em até 20 domínios de atualização. Durante a manutenção agendada, apenas um domínio de atualização é atualizado a qualquer momento. Os domínios de atualização não são necessariamente atualizados sequencialmente.

Os conjuntos de dimensionamento de máquinas virtuais no modo de orquestração Uniform são um recurso de computação do Azure que pode utilizar para implementar e gerir um conjunto de VMs idênticas enquanto recurso único. O conjunto de dimensionamento é automaticamente implementado em UDs, tal como as VMs num conjunto de disponibilidade. Assim como acontece com os conjuntos de disponibilidade, quando você usa conjuntos de escala uniforme, apenas uma UD é atualizada a qualquer momento durante a manutenção agendada.

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

Próximos passos

Para gerir a manutenção planeada, utilize o CLI do Azure, o Azure PowerShell ou o portal.