Manutenzione per macchine virtuali in Azure

Applies to: ✔️ Macchine virtuali Linux ✔️ Macchine virtuali Windows ✔️ Set di scalabilità flessibili ✔️ Set di scalabilità uniformi

Azure aggiorna periodicamente la piattaforma per migliorare l'affidabilità, le prestazioni e la sicurezza dell'infrastruttura host per le macchine virtuali. Lo scopo di questi aggiornamenti include l'applicazione di patch ai componenti software nell'ambiente host, l'aggiornamento dei componenti di rete e la rimozione delle autorizzazioni per l'hardware.

Gli aggiornamenti influiscono raramente sulle macchine virtuali ospitate. Nel caso in cui producano invece un effetto, Azure sceglie il metodo di aggiornamento a minor impatto:

• Se l'aggiornamento non richiede il riavvio, durante l'aggiornamento dell'host la macchina virtuale viene sospesa o migrata in tempo reale su un host già aggiornato.
• Se un intervento di manutenzione richiede il riavvio, si riceve una notifica relativa alla manutenzione pianificata. Azure offre anche una finestra temporale in cui avviare la manutenzione manualmente, in un momento opportuno per l'utente. L'intervallo di manutenzione automatica è in genere di 35 giorni (per le macchine host), a meno che l'intervento non sia urgente. Azure investe in tecnologie che consentano di ridurre i casi in cui la manutenzione pianificata della piattaforma richiede il riavvio delle macchine virtuali. Per istruzioni sulla gestione della manutenzione pianificata, vedere Gestire gli avvisi relativi alla manutenzione pianificata usando l'interfaccia della riga di comando di Azure, PowerShell o il portale.

Questa pagina descrive come Azure esegue entrambi i tipi di manutenzione. Per altre informazioni sugli eventi non pianificati (interruzioni), vedere Gestisci la disponibilità delle VM per Windows o l'articolo corrispondente per Linux.

È possibile ottenere notifiche sulla manutenzione programmata direttamente nella macchina virtuale tramite Eventi pianificati per Windows o Linux.

Interventi di manutenzione che non richiedono il riavvio

La maggior parte degli aggiornamenti della piattaforma non influisce sulle macchine virtuali dei clienti. Quando non è possibile un aggiornamento senza alcun effetto, Azure sceglie il metodo di aggiornamento a minor impatto sulle macchine virtuali dei clienti.

Se è richiesta la VM che influisce sulla manutenzione, verrà quasi sempre completata tramite una pausa della VM per meno di 10 secondi. In circostanze rare, non più di una volta ogni 18 mesi per le VM di dimensioni generali per utilizzo generico, Azure utilizza un meccanismo che mette in pausa la VM per circa 30 secondi. Dopo qualsiasi operazione di pausa, l'orologio della VM viene sincronizzato automaticamente al momento della ripresa.

La manutenzione con mantenimento della memoria è supportata da oltre il 90% delle macchine virtuali di Azure. Non funziona per la serie G, L, N e H. Per altre informazioni, vedere quali dimensioni delle macchine virtuali supportano la manutenzione con mantenimento della memoria. Azure usa sempre più spesso tecnologie di migrazione in tempo reale e meccanismi di manutenzione con mantenimento della memoria per ridurre la durata delle interruzioni.

Queste operazioni di manutenzione che non richiedono un riavvio vengono applicate per ogni dominio di errore e vengono interrotte solo se ricevono segnali di avviso di integrità dagli strumenti di monitoraggio delle piattaforme. Le operazioni di manutenzione che non richiedono un riavvio possono verificarsi contemporaneamente in aree abbinate o zone di disponibilità. Per una determinata modifica, la distribuzione viene eseguita principalmente in sequenza tra zone di disponibilità e tra coppie di aree, ma è possibile sovrapporsi alla coda.

Questi tipi di aggiornamenti possono influire su alcune applicazioni. Nel caso in cui la macchina virtuale venga migrata in tempo reale su un host diverso, è possibile che alcuni carichi di lavoro subiscano un lieve peggioramento delle prestazioni nei pochi minuti che precedono la sospensione della macchina virtuale. Per preparare la manutenzione della macchina virtuale e ridurre al minimo l'impatto durante la manutenzione di Azure, può essere utile usare Eventi pianificati per Windows o Linux.

Per un maggiore controllo su tutte le attività di manutenzione, inclusi gli aggiornamenti senza riavvio e con impatto zero, è possibile creare la funzionalità Controllo di manutenzione. La creazione di una Configurazione di manutenzione consente di ignorare tutti gli aggiornamenti della piattaforma e di applicare gli aggiornamenti a scelta. Per altre informazioni, vedere Gestione degli aggiornamenti della piattaforma con configurazioni di manutenzione.

Live Migration

La migrazione in tempo reale è un'operazione che non richiede il riavvio e mantiene la memoria per la macchina virtuale. Genera una pausa o un blocco, che in genere non dura più di 5 secondi. Ad eccezione delle serie G, L, N e H, in tutte le VM IaaS (Infrastructure as a Service) è possibile eseguire la migrazione in tempo reale. La migrazione in tempo reale è disponibile per la maggior parte degli SKU serie M. Le macchine virtuali idonee rappresentano più del 90% delle macchine virtuali IaaS distribuite nell'ecosistema Azure.

La piattaforma Azure attiva la migrazione in tempo reale negli scenari seguenti:

• Manutenzione pianificata
• Errore hardware
• Ottimizzazioni di allocazione

In alcuni scenari di manutenzione pianificata viene usata la migrazione in tempo reale ed è possibile usufruire di Eventi pianificati per stabilire in anticipo l'ora di avvio delle operazioni di migrazione.

La migrazione in tempo reale può essere usata anche per spostare le macchine virtuali quando gli algoritmi di Azure Machine Learning prevedono un errore hardware in sospeso o l'ottimizzazione delle allocazioni di macchine virtuali. Per altre informazioni sulla modellazione predittiva in grado di rilevare eventuali istanze di hardware danneggiato, vedere Improving Azure VM resiliency with predictive machine learning and live migration (Migliorare la resilienza delle macchine virtuali di Azure con l'apprendimento automatico predittivo e la migrazione in tempo reale). Se si usano questi servizi, le notifiche di migrazione in tempo reale vengono visualizzate nei log di Monitoraggio di Azure e di integrità dei servizi del portale di Azure e in Eventi pianificati.

Resilienza della connessione TCP durante la migrazione in tempo reale

Le applicazioni che mantengono connessioni TCP di lunga durata, ad esempio server di database, broker messaggi e livelli di memorizzazione nella cache, possono riscontrare interruzioni della connessione durante la migrazione in tempo reale. Mentre la pausa della macchina virtuale è in genere inferiore a 5 secondi, il comportamento dello stack TCP durante e dopo la pausa può estendere il tempo di ripristino a livello di applicazione se non risolto.

Impatto della migrazione in tempo reale sulle connessioni TCP:

• Durante la pausa, i segmenti TCP in transito non vengono confermati dalla macchina virtuale in fase di migrazione.
• Il lato di invio (probe di integrità del client o del servizio di bilanciamento del carico) inizia la ritrasmissione TCP con backoff esponenziale.
• Azure Load Balancer Standard invia un'RST TCP alle connessioni inattive che superano il timeout di inattività configurato. Tuttavia, per le connessioni attive con dati in transito, il bilanciatore del carico non invia un RST TCP durante la pausa della migrazione. La connessione rimane aperta ma non risponde e il client non ha alcun segnale immediato di errore.
• Senza l'ottimizzazione a livello di applicazione, il comportamento di ritrasmissione TCP predefinito (tcp_retries2 = 15 in Linux) può ritardare il rilevamento degli errori di connessione di circa 15 minuti.

Ridurre il raggio di esplosione con distribuzioni a istanze multipla:

Prima di applicare misure di mitigazione a livello TCP, considerare la configurazione di base dell'architettura. La migrazione in tempo reale influisce su una macchina virtuale alla volta all'interno di un set di disponibilità o di un set di scalabilità di macchine virtuali. La distribuzione di connessioni tra più istanze back-end limita l'impatto di qualsiasi singolo evento di migrazione:

• Un set di scalabilità con tre istanze significa che ogni evento di migrazione influisce al massimo su un terzo delle connessioni attive.
• La distribuzione tra zone di disponibilità garantisce che le migrazioni in zone diverse non si sovrappongano.
• I client con pool di connessioni distribuiti tra più back-end vengono ripristinati più velocemente perché le connessioni non interessate continuano a gestire immediatamente le richieste.

Durante la pausa della VM, anche le probe di integrità di Azure Load Balancer Standard del back-end in pausa non riescono. Il servizio di bilanciamento del carico contrassegna il back-end come non integro entro circa 10 secondi (due errori di probe consecutivi all'intervallo predefinito di 5 secondi) e arresta il routing di nuove connessioni. Questa condizione indica che le nuove connessioni sono naturalmente protette. Le mitigazioni TCP descritte in questo articolo riguardano le connessioni esistenti già stabilite prima dell'inizio della migrazione.

Mitigazioni consigliate:

Le mitigazioni seguenti sono complementari. Quando implementati insieme, riducono l'impatto di un evento di migrazione in tempo reale da minuti di tempo di inattività potenziale a secondi di ripristino automatico.

Mitigazione 1: TCP_USER_TIMEOUT (rilevamento più veloce)

TCP_USER_TIMEOUT controlla per quanto tempo il kernel attende il riconoscimento dei dati trasmessi prima di dichiarare una connessione inattiva. L'impostazione di questo valore su 30 secondi (30000 ms) per socket riduce significativamente il tempo di rilevamento.

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

In alternativa, ridurre il numero di ritrasmissioni a livello di sistema:

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

Considerazioni su Windows:

L'opzione TCP_USER_TIMEOUT socket è specifica per Linux. In Windows, il comportamento di ritrasmissione TCP viene controllato in modo diverso:

• In Windows, il valore predefinito è 5 ritrasmissioni (TcpMaxDataRetransmissions), il che garantisce già circa 25-50 secondi di tempo di rilevamento senza alcuna configurazione.
• Per ridurre ulteriormente il tempo di rilevamento in Windows, modificare il Registro di sistema:

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

Con TcpMaxDataRetransmissions impostato su 3, il tempo di rilevamento si riduce a circa 10-20 secondi a seconda del timeout di ritrasmissione iniziale.

Mitigazione 2: Eventi pianificati (drenaggio proattivo)

Il servizio Eventi pianificati fornisce una notifica anticipata prima dell'inizio di una migrazione in tempo reale. Le applicazioni possono restare in ascolto degli Freeze eventi e svuotare in modo proattivo le connessioni prima che si verifichi la pausa.

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

Un evento di migrazione in tempo reale viene visualizzato come:

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

Quando viene rilevato un Freeze evento:

1. Interrompere l'accettazione di nuove connessioni nel nodo interessato.
2. Svuotare le connessioni esistenti (segnalare ai client di riconnettersi ad altri nodi).
3. Attendere il completamento delle operazioni in corso entro un timeout massimo.
4. Facoltativamente, confermare l'evento inviando l'EventId.

Mitigazione 3: ottimizzazione del keepalive TCP

I probe keepalive TCP rilevano connessioni inattive dopo l'evento di migrazione:

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)

Con queste impostazioni, viene rilevata una connessione inattiva entro 60 secondi (30 + 10 x 3). Anche le probe keepalive vengono conteggiate come attività ai fini del timeout di inattività del Load Balancer Standard, impedendo al servizio di bilanciamento del carico di interrompere autonomamente per timeout le connessioni inattive.

Mitigazione 4: logica di ripetizione dei tentativi lato client

La riconnessione a livello di applicazione e la logica di ripetizione dei tentativi garantisce il ripristino indipendentemente dal metodo di rilevamento degli errori:

1. Rilevare l'errore di connessione (timeout, RST o connessione rifiutata).
2. Chiudere la connessione inattiva e rimuoverla dal pool di connessioni.
3. Aprire una nuova connessione allo stesso nodo o a un nodo diverso.
4. Riprova l'operazione con backoff esponenziale.

Per gli SDK e i pool di connessioni del database, abilitare controlli di integrità periodici (ad esempio, un ping leggero ogni 10-15 secondi) per convalidare le connessioni in modo proattivo.

Configurazione del pool di connessioni:

I pool di connessioni che mantengono connessioni di lunga durata traggono vantaggio da un'impostazione di durata massima. Questa impostazione forza il riciclo periodico della connessione, assicurando che nessuna singola connessione accumuli rischi non associati da eventi di migrazione futuri:

L'impostazione di una durata massima di 30 minuti significa che, anche senza controlli di integrità attivi, le connessioni vengono naturalmente sostituite prima di poter accumulare lunghi periodi di decadimento non rilevato.

Monitoraggio e osservabilità:

Per rilevare e misurare l'impatto degli eventi di migrazione in tempo reale sulle connessioni TCP, usare gli approcci seguenti:

• Monitoraggio di Azure metrica di disponibilità della macchina virtuale (anteprima): scende a 0 durante la pausa della macchina virtuale. Creare una regola di avviso su VmAvailabilityMetric con una soglia inferiore a 1 per rilevare gli eventi di migrazione.
• Registro attività eventi pianificati: Gli eventi di migrazione live vengono visualizzati nel Registro attività nel provider Microsoft.Compute con il nome operazione Microsoft.Compute/virtualMachines/liveMigration/action o come eventi Freeze quando vengono interrogati tramite il servizio metadati.
• Frequenza degli errori di connessione a livello di applicazione: Monitorare le reimpostazioni della connessione TCP, i timeout e i conteggi di riconnessione nelle metriche dell'applicazione. Un picco negli errori di connessione correlati a un dip della disponibilità della macchina virtuale conferma l'impatto della migrazione.
• Contatori di ritrasmissione TCP: In Linux, monitorare /proc/net/netstat il campo TCPTimeouts o usare ss -ti per osservare i conteggi di ritrasmissione su singoli socket. Un numero elevato di ritrasmissioni durante una finestra di manutenzione nota indica che le connessioni sono state interessate.

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

La definizione di una baseline per queste metriche durante il normale funzionamento rende più semplice quantificare l'impatto degli eventi di migrazione e verificare che le mitigazioni funzionino come previsto.

Carichi di lavoro con tolleranza zero per l'interruzione della migrazione in tempo reale

Per i carichi di lavoro che non possono tollerare interruzioni dalla migrazione in tempo reale, è consigliabile usare Azure host dedicati con configurazioni di manutenzione. Gli host dedicati consentono di controllare quando si verifica la manutenzione a livello di host, eliminando gli eventi di migrazione in tempo reale a sorpresa.

Interventi di manutenzione che richiedono il riavvio

Nel caso raro in cui sia necessario riavviare le macchine virtuali per la manutenzione pianificata, si riceve una notifica in anticipo. La manutenzione pianificata prevede due fasi: la fase self-service e una fase di manutenzione pianificata.

Nel corso della fase self-service, che in genere dura quattro settimane, viene avviata la manutenzione delle macchine virtuali. Durante questa fase, è possibile eseguire query su ogni macchina virtuale per visualizzarne lo stato e controllare il risultato dell'ultima richiesta di manutenzione.

Quando si avvia la manutenzione self-service, la macchina virtuale viene ridistribuita su un nodo già aggiornato. A causa delle ridistribuzioni della VM, il disco temporaneo viene perduto e gli indirizzi IP dinamici pubblici che sono associati all'interfaccia di rete virtuale vengono aggiornati.

Se si verifica un errore durante il processo di manutenzione self-service, l'operazione viene arrestata, la macchina virtuale non viene aggiornata ed è possibile scegliere di riprovare ad avviare la manutenzione self-service.

Al termine della fase self-service, ha inizio la fase di manutenzione pianificata. Durante questa fase, è ancora possibile eseguire una query sulla fase di manutenzione, ma non avviare la manutenzione manualmente.

Per altre informazioni sulla gestione degli interventi di manutenzione che richiedono il riavvio, vedere Gestire gli avvisi relativi alla manutenzione pianificata usando l'interfaccia della riga di comando di Azure, PowerShell o il portale.

Considerazioni sulla disponibilità durante la manutenzione pianificata

Se si decide di attendere fino alla fase di manutenzione pianificata, sono necessarie alcune considerazioni per mantenere la disponibilità più elevata possibile delle macchine virtuali.

Aree abbinate

Ogni area di Azure è abbinata a un'altra area con la stessa collocazione geografica; formano insieme una coppia di aree. Durante la fase di manutenzione pianificata, Azure aggiornerà solo le macchine virtuali di una sola area della coppia. Se, ad esempio, si aggiornano le macchine virtuali negli Stati Uniti centro-settentrionali, Azure non aggiorna contemporaneamente anche le macchine virtuali negli Stati Uniti centro-meridionali. Tuttavia, altre aree, ad esempio Europa settentrionale, possono essere sottoposte a manutenzione contemporaneamente a Stati Uniti orientali. Sapendo come funzionano le coppie di aree, è possibile distribuire meglio le VM tra le aree. Per altre informazioni, vedere Coppie di aree di Azure.

Zone di disponibilità

Le zone di disponibilità sono località fisiche esclusive all'interno di un'area di Azure. Ogni zona è costituita da uno o più data center dotati di impianti indipendenti per l'alimentazione, il raffreddamento e la connettività di rete. Per garantire la resilienza, sono presenti almeno tre zone separate in tutte le aree abilitate.

Una zona di disponibilità è una combinazione di un dominio di errore e un dominio di aggiornamento. Se si creano tre o più macchine virtuali in tre zone di un'area di Azure, le macchine virtuali vengono distribuite in modo efficace in tre domini di errore e tre domini di aggiornamento. La piattaforma di Azure riconosce questa distribuzione in domini di aggiornamento per assicurarsi che le macchine virtuali in diverse aree non vengano aggiornate contemporaneamente.

All'interno di un'area, ogni aggiornamento dell'infrastruttura viene distribuito zona per zona. È possibile, tuttavia, che contemporaneamente a una distribuzione in Zona 1 venga eseguita anche una distribuzione Zona 2. Le distribuzioni non sono tutte serializzate. Tuttavia, una singola distribuzione che richiede un riavvio viene distribuito una zona alla volta per ridurre il rischio. In generale, gli aggiornamenti che richiedono un riavvio vengono evitati quando possibile e Azure tenta di usare Live Migration o fornire ai clienti il controllo.

set di scalabilità di macchine virtuali

I set di scalabilità di macchine virtuali con modalità di orchestrazione Flexible sono una risorsa di ambiente di calcolo Azure che consente di combinare la scalabilità dei set di scalabilità di macchine virtuali in modalità di orchestrazione uniforme con le garanzie di disponibilità a livello di area dei set di disponibilità.

Con l'orchestrazione Flexible, è possibile scegliere se le istanze vengono distribuite in più zone o distribuite tra domini di errore all'interno di una singola area.

Set di disponibilità e set di scalabilità Uniform

Quando si distribuisce un carico di lavoro nelle VM di Azure, è possibile creare le VM in un set di disponibilità per garantire una disponibilità elevata per l'applicazione. Usando i set di disponibilità, è possibile avere la certezza che, durante un'interruzione o un evento di manutenzione che richiede il riavvio, sia disponibile almeno una macchina virtuale.

All'interno di un set di disponibilità, le singole macchine virtuali vengono distribuite su un massimo di 20 domini di aggiornamento. Durante la manutenzione pianificata, in un dato momento viene aggiornato un unico dominio di aggiornamento. I domini di aggiornamento non vengono necessariamente aggiornati in modo sequenziale.

I set di scalabilità delle macchine virtuali in Uniform sono una risorsa di calcolo di Azure che consente di distribuire e gestire un set di VM identiche come una singola risorsa. Il set di scalabilità viene distribuito automaticamente nei domini di aggiornamento, ad esempio le macchine virtuali in un set di disponibilità. Come con i set di disponibilità, anche con i set di scalabilità Uniform viene aggiornato un solo dominio di aggiornamento per volta durante la manutenzione pianificata.

Per altre informazioni sulla configurazione delle VM per la disponibilità elevata, vedere Gestisci la disponibilità delle VM per Windows o l'articolo corrispondente per Linux.

Passaggi successivi

Per gestire la manutenzione pianificata, usare il interfaccia della riga di comando di Azure, Azure PowerShell o il portale.