Condividi tramite

Informazioni sul riavvio del sistema della macchina virtuale di Azure

  • Articolo

Si applica a: ✔️ macchine virtuali Linux ✔️ macchine virtuali Windows

Le macchine virtuali (VM) di Azure a volte possono riavviarsi senza un motivo apparente, senza che sia stata avviata l'operazione di riavvio. Questo articolo elenca le azioni e gli eventi che possono provocare il riavvio delle macchine virtuali e fornisce informazioni su come evitare problemi di riavvio imprevisto o ridurre le conseguenze di tali problemi.

Configurare le macchine virtuali per la disponibilità elevata

Il modo migliore per proteggere un'applicazione in esecuzione in Azure dalle conseguenze di riavvii e tempi di inattività delle macchine virtuali è quello di configurare le macchine virtuali per la disponibilità elevata.

Per garantire questo livello di ridondanza dell'applicazione, è consigliabile raggruppare due o più macchine virtuali in un set di disponibilità. Questa configurazione assicura infatti che, nel corso di un evento di manutenzione pianificata o non pianificata, almeno una delle macchine virtuali sia sempre disponibile e soddisfi per almeno il 99,95% i requisiti del contratto di servizio di Azure.

Per altre informazioni sui set di disponibilità, vedere Gestire la disponibilità delle macchine virtuali

Informazioni su Integrità risorse

Integrità risorse di Azure è un nuovo servizio che espone l'integrità delle singole risorse di Azure e offre consigli pratici per risolvere i problemi. In un ambiente cloud in cui non è possibile accedere direttamente ai server o agli elementi dell'infrastruttura, l'obiettivo di Integrità risorse è ridurre il tempo dedicato alla risoluzione dei problemi. in particolare lo scopo è ridurre il tempo impiegato per determinare se il problema è interno all'applicazione o dovuto a un evento specifico della piattaforma Azure. Per altre informazioni, vedere Panoramica su Integrità risorse di Azure.

Se Azure contiene altre informazioni sulla causa radice di un'indisponibilità avviata dalla piattaforma per una macchina virtuale, tali informazioni possono essere pubblicate nell'integrità delle risorse fino a 72 ore dopo l'indisponibilità iniziale.

Tempi di inattività delle macchine virtuali mancanti nel log attività

Integrità risorse gli avvisi vengono inviati in base alle informazioni del log attività. In alcuni casi, i tempi di inattività delle macchine virtuali potrebbero non essere visualizzati nel log attività. Se il tempo di inattività non viene visualizzato nel log attività, Integrità risorse gli avvisi non verranno inviati per il tempo di inattività. Il tempo di inattività è ancora visibile in Integrità risorse.

Ecco i casi in cui i tempi di inattività delle macchine virtuali non vengono visualizzati nel log attività:

  • Quando viene creata o eseguita la migrazione di una macchina virtuale a un nuovo host, la piattaforma Azure non visualizza correttamente lo stato della macchina virtuale e lo stato passa a Sconosciuto. Solo dopo aver stabilito tutti i processi di connettività di rete e nodi, lo stato della macchina virtuale diventa Disponibile. Il periodo prolungato dello stato Sconosciuto viene filtrato fuori dal log attività.
  • Quando lo stato di disponibilità della macchina virtuale passa da Disponibile a Non disponibile e quindi torna a Disponibile entro 35 secondi, il tempo di inattività non viene visualizzato nel log attività. Questo caso non si verifica se un tempo di inattività correlato viene inviato entro 15 minuti prima dell'occorrenza della prima transizione.
  • Se l'integrità della macchina virtuale passa da uno stato a Sconosciuto e quindi torna allo stato originale, lo stato sconosciuto intermittente e le transizioni correlate vengono filtrati fuori dal log attività.

I tempi di inattività delle macchine virtuali che non vengono visualizzati nel log attività vengono filtrati sul lato della piattaforma Azure per evitare che gli errori temporanei visualizzino tempi di inattività non corretti per i clienti. Con investimenti continui nella qualità dell'integrità delle macchine virtuali, i filtri potrebbero non essere più necessari e potrebbero causare modifiche rapide nell'integrità delle macchine virtuali per rimanere non segnalate. Microsoft sta lavorando a un piano di phase-out per offrire la migliore esperienza dei clienti.

Azioni e gli eventi che possono generare il riavvio della macchina virtuale

Manutenzione pianificata

Microsoft Azure esegue periodicamente aggiornamenti a livello globale per migliorare l'affidabilità, le prestazioni e la sicurezza dell'infrastruttura host sottostante alle macchine virtuali. Molti di questi aggiornamenti, inclusi gli aggiornamenti con mantenimento della memoria, vengono eseguiti senza alcun impatto sulle macchine virtuali o sui servizi cloud.

Altri aggiornamenti, invece, richiedono il riavvio. In questi casi, le macchine virtuali vengono arrestate durante l'applicazione delle patch all'infrastruttura e quindi riavviate.

Per informazioni sulla manutenzione pianificata di Azure e su come può influire sulla disponibilità delle macchine virtuali Linux, vedere gli articoli elencati qui. Gli articoli forniscono informazioni di base sul processo di manutenzione pianificata di Azure e su come pianificare la manutenzione per ridurre ulteriormente l'impatto.

Aggiornamenti con mantenimento della memoria

Per questa classe di aggiornamenti in Microsoft Azure, gli utenti non notano alcun impatto sulle macchine virtuali in esecuzione. Molti di questi aggiornamenti sono componenti o servizi che possono essere aggiornati senza interferire con l'istanza in esecuzione. Alcuni sono aggiornamenti dell'infrastruttura della piattaforma nel sistema operativo host, che possono essere applicati senza riavviare le macchine virtuali.

Questi aggiornamenti con mantenimento della memoria vengono eseguiti con una tecnologia che consente la migrazione sul posto in tempo reale. Quando viene aggiornata, la VM viene messa in pausa. Questo stato mantiene la memoria in RAM mentre il sistema operativo host sottostante riceve gli aggiornamenti e le patch necessari. La macchina virtuale viene ripresa in genere entro 30 secondi dalla sospensione. Dopo che la VM è stata ripresa, l'orologio viene sincronizzato automaticamente.

Grazie al breve periodo di pausa, la distribuzione degli aggiornamenti tramite questo meccanismo riduce considerevolmente l'impatto sulle VM. Non si possono tuttavia distribuire tutti gli aggiornamenti in questo modo.

Gli aggiornamenti a istanza multipla (per le macchine virtuali in un set di disponibilità) vengono applicati su un dominio di aggiornamento alla volta.

Nota

Con questo metodo di aggiornamento, i computer Linux con versioni precedenti del kernel sono interessati da un kernel panic. Per evitare questo problema, aggiornare il kernel alla versione 3.10.0-327.10.1 o successiva. Per altre informazioni, vedere Kernel panic di una macchina virtuale Linux di Azure basata su un kernel 3.10 dopo l'aggiornamento di nodo host.

Azioni di arresto o riavvio avviate dall'utente

Se si esegue un riavvio dal portale di Azure, Azure PowerShell, l'interfaccia della riga di comando o l'API REST, è possibile trovare l'evento nel log attività di Azure.

Se si esegue l'azione dal sistema operativo della VM, è possibile trovare l'evento nei log di sistema.

Il riavvio della macchina virtuale si verifica solitamente anche quando si eseguono più azioni di modifica della configurazione. In genere, viene visualizzato un messaggio di avviso in cui si specifica che l'esecuzione di una determinata azione comporterà il riavvio della macchina virtuale. Questi tipi di azione includono, ad esempio, operazioni di ridimensionamento della macchina virtuale, la modifica della password dell'account amministrativo o l'impostazione di un indirizzo IP statico.

Microsoft Defender per il cloud e Windows Update

Microsoft Defender per il cloud monitora le macchine virtuali Windows e Linux giornaliere per gli aggiornamenti mancanti del sistema operativo. Defender per il cloud recupera un elenco di aggiornamenti critici e di sicurezza disponibili da Windows Update o Windows Server Update Services (WSUS), a seconda del servizio configurato in una macchina virtuale Windows. Defender per il cloud verifica anche la presenza degli aggiornamenti più recenti per i sistemi Linux. Se la macchina virtuale manca un aggiornamento del sistema, Defender per il cloud consiglia di applicare gli aggiornamenti di sistema. L'applicazione di questi aggiornamenti di sistema viene controllata tramite il Defender per il cloud nel portale di Azure. Dopo l'applicazione di alcuni aggiornamenti, potrebbe essere necessario il riavvio della macchina virtuale. Per altre informazioni, vedere Applicare gli aggiornamenti di sistema in Microsoft Defender per il cloud.

Analogamente ai server locali, Azure non esegue il push degli aggiornamenti da Windows Update alle macchine virtuali Windows, perché queste macchine sono pensate per essere gestite dagli utenti. Tuttavia si consiglia di lasciare abilitata l'impostazione automatica di Windows Update. Con l'installazione automatica degli aggiornamenti da Windows Update, il riavvio può anche verificarsi dopo l'applicazione degli aggiornamenti. Per altre informazioni, vedere Windows Update: domande frequenti.

Altre situazioni che influiscono sulla disponibilità della macchina virtuale

Esistono altri casi in cui Azure può sospendere attivamente l'uso di una macchina virtuale. Si riceveranno tuttavia notifiche di posta elettronica prima che venga intrapresa questa azione e si avrà quindi la possibilità di risolvere i problemi sottostanti. Tra i problemi che compromettono la disponibilità delle VM sono incluse le violazioni della sicurezza e la scadenza dei metodi di pagamento.

Errori del server host

La macchina virtuale è ospitata in un server fisico in esecuzione in un data center di Azure. Il server fisico esegue un agente denominato agente host e alcuni altri componenti di Azure. Se questi componenti software di Azure nel server fisico non rispondono, il sistema di monitoraggio attiva un riavvio del server host per tentarne il ripristino. In molti casi, la macchina virtuale sarà nuovamente disponibile entro 10-15 minuti e continuerà a essere attiva nello stesso host di prima.

Gli errori del server vengono solitamente generati da errori hardware, ad esempio dal guasto di un disco rigido o di un'unità SSD. Azure monitorizza in modo continuo queste occorrenze, identifica i bug sottostanti e rilascia gli aggiornamenti dopo aver implementato e testato l'attenuazione.

Poiché alcuni errori del server host possono essere specifici del server, una situazione di riavvio ripetuto di una macchina virtuale può essere migliorata ridistribuendo manualmente la macchina virtuale in un altro server host. Questa operazione può essere attivata usando l'opzione Ridistribuisci nella pagina dei dettagli della macchina virtuale oppure arrestando e riavviando la macchina virtuale nel portale di Azure.

Ripristino automatico

Se il server host non può essere riavviato per qualsiasi motivo, la piattaforma Azure avvia un'azione di ripristino automatico per portare il server host in errore fuori dalla rotazione e consentirne un'analisi più approfondita.

Tutte le macchine virtuali presenti nell'host vengono automaticamente riassegnate a un server host diverso, integro. Anche se questo processo si completa in genere entro 15 minuti, il tempo necessario per il ripristino può variare in base a diversi fattori, tra cui la dimensione della memoria dell'host e i metodi di ripristino utilizzati. Per altre informazioni sul processo di ripristino automatico, vedere Auto-recovery of VMs (Ripristino automatico delle macchine virtuali).

Manutenzione non pianificata

In rare occasioni, è possibile che il team operativo di Azure debba eseguire alcune attività di manutenzione per garantire l'integrità complessiva della piattaforma Azure. Questo comportamento può influire sulla disponibilità della macchina virtuale e in genere determina la stessa azione di recupero automatico descritta in precedenza.

La manutenzione non pianificata include quanto segue:

  • Deframmentazione urgente di un nodo
  • Aggiornamenti urgenti di switch di rete

Arresti anomali della macchina virtuale

Una VM può venire riavviata a causa di problemi interni. Il ruolo o il carico di lavoro in esecuzione nella macchina virtuale può attivare un controllo bug nel sistema operativo guest. Per determinare il motivo dell'arresto anomalo, visualizzare i registri applicazioni e di sistema per le macchine virtuali Windows e i log seriali per le macchine virtuali Linux.

Le macchine virtuali in Azure si basano su dischi virtuali per il sistema operativo e l'archiviazione dati ospitata nell'infrastruttura di archiviazione di Azure. Ogni volta che la disponibilità o la connettività tra la macchina virtuale e i dischi virtuali associati viene interrotta per più di 120 secondi, la piattaforma Azure esegue un arresto forzato delle macchine virtuali per evitare il danneggiamento dei dati. Le macchine virtuali vengono automaticamente riaccese dopo aver ripristinato la connettività dell'archiviazione. La durata dell'arresto può essere di cinque minuti o molto più lunga.

Altri eventi imprevisti

In rare circostanze, un problema di ampia portata può interessare più server in un data center di Azure. In questo caso, il team di Azure invia notifiche di posta elettronica alle sottoscrizioni interessate. È possibile visualizzare il dashboard per l'integrità dei servizi di Azure e il portale di Azure per verificare lo stato delle interruzioni in corso e degli eventi imprevisti passati.

Diagnosticare i riavvii delle macchine virtuali

È possibile usare il pannello Diagnostica e risoluzione nel pannello della macchina virtuale per eseguire diagnostica aggiuntiva. Questo potrebbe rivelare motivi più specifici per il riavvio recente della macchina virtuale. In caso di problemi con il sistema operativo guest, raccogliere il dump della memoria e contattare il supporto tecnico.

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.