Domande frequenti sui riavvii dell'istanza del ruolo causati dagli aggiornamenti del sistema operativo della macchina virtuale

Non è possibile rifiutare esplicitamente gli aggiornamenti del sistema operativo host. Microsoft deve mantenere sistemi operativi host aggiornati all'interno del data center. È possibile rifiutare esplicitamente l'aggiornamento del sistema operativo guest specificando una versione del sistema operativo guest. Tuttavia, se si esegue questa operazione, il servizio non riceverà più aggiornamenti della sicurezza e potrebbe essere lasciato vulnerabile. Per altre informazioni, vedere Gestire una versione del sistema operativo guest.

Non è possibile controllare quando viene aggiornata una singola istanza o un servizio per il sistema operativo host. L'aggiornamento viene avviato in tutti i data center di Azure in tutto il mondo all'incirca nello stesso momento. L'infrastruttura funziona continuamente per l'aggiornamento di ogni data center. A causa della complessità di assicurarsi che le regole di dominio di aggiornamento vengano seguite per tutti i servizi cloud, questo processo richiede diversi giorni. Non è possibile controllare o determinare quando verrà interessata un'istanza specifica. Per controllare l'aggiornamento del sistema operativo guest, è possibile specificare una versione fissa del sistema operativo guest e quindi aggiornarla ogni volta che si è pronti.

Non è disponibile alcun supporto per la connessione a una macchina virtuale PaaS di Azure tramite Remote Desktop Protocol (RDP) e l'applicazione di modifiche o l'installazione di software. In qualsiasi momento, la macchina virtuale può essere ricompilata e le modifiche apportate andranno perse. Questo scenario può verificarsi se l'hardware ha esito negativo ed è necessario avviare una nuova macchina virtuale nel nuovo hardware. Si verificherà anche durante l'aggiornamento del sistema operativo guest, quando la partizione di Windows viene ricompilati. Se è necessario installare il software o apportare modifiche alla macchina virtuale, creare un'attività di avvio ed eseguire il lavoro da qui. Questo processo assicura che quando la macchina virtuale viene ricreata, la configurazione verrà eseguita di nuovo.

Gli aggiornamenti installati nella nuova versione del sistema operativo guest sono disponibili pubblicamente e gli hotfix accuratamente testati. Questi hotfix vengono distribuiti anche ai server di tutto il mondo tramite Windows Update e la possibilità di effetti negativi sul servizio è ridotta. Per quanto riguarda i servizi locali, è necessario gestire le patch del sistema operativo nelle macchine virtuali di Azure usando un ambiente di gestione temporanea in cui si testano prima gli aggiornamenti.

Se si vuole configurare un ambiente di staging per testare gli aggiornamenti prima dell'ambiente di produzione, configurare il servizio di produzione in modo che usi una stringa del sistema operativo con versione fissa nel file con estensione cscfg. Quindi, quando è disponibile un nuovo sistema operativo guest, è possibile distribuire il servizio nello slot di staging usando la versione del sistema operativo guest più recente. Dopo aver verificato che il servizio funzioni correttamente nel sistema operativo guest più recente, è possibile eseguire uno scambio VIP. In alternativa, è possibile eseguire un aggiornamento sul posto del servizio di produzione per usare il sistema operativo più recente.

Un malinteso comune è che più aggiornamenti vengono applicati, più tempo richiederà il processo. Questo presupposto si basa sulla convinzione che l'aggiornamento funzioni in modo analogo a come si verifica un aggiornamento Windows Update nel computer desktop locale. In un aggiornamento di Windows, molti aggiornamenti vengono copiati in Windows e installati includendo i riavvii successivi. Tuttavia, questo processo non è il funzionamento dell'aggiornamento in Azure.

Quando viene rilasciata una nuova versione del sistema operativo in Azure, il team del sistema operativo acquisisce l'immagine più recente, applica gli aggiornamenti e quindi crea un disco rigido virtuale (VHD) che contiene questa nuova immagine di base. Questa immagine di base viene quindi copiata in un repository in Azure. Quando viene richiesto di eseguire un aggiornamento del sistema operativo, l'infrastruttura eseguirà prima un passaggio di copia. Nel data center che verrà aggiornato, l'infrastruttura copia questo nuovo disco rigido virtuale dell'immagine di base nel disco rigido di ogni server. Al termine di questo processo, l'infrastruttura avvia il processo di aggiornamento, seguendo le normali regole del dominio di aggiornamento.

Quando un guest verrà aggiornato, l'infrastruttura esegue un normale arresto del sistema operativo e quindi avvia una nuova macchina virtuale usando la nuova immagine di base. Il tempo necessario per aggiornare una determinata macchina virtuale per un sistema operativo guest è all'incirca lo stesso tempo necessario per eseguire un normale arresto e riavvio di Windows.

La tempistica per un aggiornamento del sistema operativo host è diversa. Quando un host viene aggiornato, si verifica la sequenza seguente:

• L'host invia il messaggio di arresto a ogni sistema operativo guest in esecuzione nell'host.

• A ogni sistema operativo guest vengono assegnati l'evento standard OnStop e il tempo di arresto di Windows per completare l'arresto.

• Dopo l'arresto di ogni sistema operativo guest, il sistema operativo host esegue un arresto normale e passa attraverso la normale procedura di arresto.

• Dopo l'arresto del sistema operativo host, l'host viene riavviato usando la nuova immagine del sistema operativo.

• Dopo che l'host è attivo e in esecuzione, avvia ogni sistema operativo guest.

Questo processo di aggiornamento del sistema operativo host richiede in genere da 15 a 20 minuti. Il tempo può variare a seconda di quanti altri guest si trovano in tale host e di quanto tempo è necessario per elaborarli. Tuttavia, ci saranno sempre eccezioni se si verifica un errore in un nodo specifico e l'infrastruttura di Azure determina che i guest in tale nodo devono essere spostati in un altro nodo.

Quando il sistema operativo viene aggiornato, Azure Fabric esegue un normale arresto dell'istanza del ruolo. Questa procedura significa che il codice ASP.NET riceverà l'evento Application_End e il runtime del servizio di Azure genererà gli Stopping eventi e OnStop . Il codice avrà cinque minuti per completare il lavoro di pulizia prima OnStop dell'arresto del processo. Dopo l'arresto del processo host di Azure, Windows eseguirà un normale arresto normale, che include l'aumento degli eventi standard OnStop e correlati per i servizi Windows.

Per altre informazioni su come gestire un arresto dell'istanza, vedere Il modo corretto per gestire gli eventi di Azure OnStop, Personalizzare il ciclo di vita di un ruolo Web o di lavoro in .NET e Il metodo RoleEntryPoint.OnStop().

Ulteriori informazioni

• Riavvii dell'istanza del ruolo causati dagli aggiornamenti del sistema operativo della macchina virtuale di Azure

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.