Questo articolo risponde alle domande frequenti sui riavvii dell'istanza del ruolo causati dagli aggiornamenti al sistema operativo Windows in una macchina virtuale PaaS (Platform as a Service) di Microsoft Azure.
Come è possibile rifiutare esplicitamente gli aggiornamenti del sistema operativo?
Non è possibile rifiutare esplicitamente gli aggiornamenti del sistema operativo host. Microsoft deve mantenere aggiornati i sistemi operativi host 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ù gli aggiornamenti della sicurezza e potrebbe essere vulnerabile. Per altre informazioni, vedere Gestire una versione del sistema operativo guest.
Come si forzano gli aggiornamenti e i riavvii solo durante gli orari non lavorativi?
Non è possibile controllare quando viene aggiornata una singola istanza o servizio per il sistema operativo host. L'aggiornamento viene avviato in tutti i data center di Azure in tutto il mondo contemporaneamente. La rete lavora continuamente sull'aggiornamento di ogni data center. A causa della complessità di assicurarsi che le regole di dominio di aggiornamento siano 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.
È stato installato qualcosa nella macchina virtuale. Ma ora la macchina virtuale è stata riavviata e il software installato non è più disponibile. Perché il software è scomparso?
Non è disponibile alcun supporto per la connessione a una macchina virtuale PaaS di Azure tramite Remote Desktop Protocol (RDP) e apportare modifiche o installare software. In qualsiasi momento, la macchina virtuale può essere ricompilata e tutte le modifiche apportate andranno perse. Questo scenario può verificarsi se l'hardware ha esito negativo ed è necessario avviare una nuova macchina virtuale in un nuovo hardware. Si verificherà anche durante l'aggiornamento del sistema operativo guest, quando la partizione di Windows viene ricostruita. Se è necessario installare il software o apportare modifiche alla macchina virtuale, creare un'attività di avvio ed eseguire il lavoro da questa posizione. Questo processo assicura che quando la macchina virtuale viene ricreata, la configurazione verrà eseguita di nuovo.
Uno degli aggiornamenti nella nuova versione del sistema operativo guest può interrompere il servizio?
Gli aggiornamenti installati nella nuova versione del sistema operativo guest sono hotfix disponibili pubblicamente e testati accuratamente. Questi hotfix vengono distribuiti anche ai server in tutto il mondo tramite Windows Update e la possibilità di effetti negativi sul servizio è ridotta. Per quanto riguarda i servizi locali, è consigliabile 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 da usare 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 più recente del sistema operativo guest. Dopo aver verificato che il servizio funzioni correttamente nel sistema operativo guest più recente, è possibile eseguire uno scambio di indirizzi VIP. In alternativa, è possibile eseguire un aggiornamento sul posto del servizio di produzione per usare il sistema operativo più recente.
Quanto tempo richiederà l'aggiornamento? Per quanto tempo la macchina virtuale sarà inattiva?
Un malinteso comune è che più aggiornamenti vengono applicati, più il processo richiederà più tempo. Questo presupposto si basa sulla convinzione che l'aggiornamento funzioni in modo analogo a come si verifica un aggiornamento di 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 che contiene questa nuova immagine di base. Questa immagine di base viene quindi copiata in un repository in Azure. Quando l'infrastruttura viene incaricata di eseguire un aggiornamento del sistema operativo, eseguirà prima un passaggio di copia. Nel datacenter che verrà aggiornato, l'infrastruttura copia questa nuova immagine di base VHD sul disco rigido di ogni server. Al termine di questo processo, l'infrastruttura avvia il processo di aggiornamento, seguendo le consuete regole di dominio di aggiornamento.
Quando un guest verrà aggiornato, l'infrastruttura esegue un arresto normale 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 è approssimativamente lo stesso tempo necessario per eseguire un arresto e un riavvio di Windows normale.
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 ciascun sistema operativo Guest viene assegnato l'evento standard
OnStope il tempo di arresto di Windows necessario per completare l'arresto.Dopo l'arresto di ogni sistema operativo guest, il sistema operativo host effettua uno spegnimento graduale e segue la sua procedura abituale di arresto.
Dopo l'arresto del sistema operativo host, l'host viene riavviato usando la nuova immagine del sistema operativo.
Dopo che l'host è operativo, 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 del numero di ospiti presenti nell'host e del tempo necessario per il loro processamento. Tuttavia, ci saranno sempre eccezioni se si verifica un errore in un determinato nodo e l'infrastruttura di Azure determina che i guest in tale nodo devono essere spostati in un altro nodo.
Come si gestisce l'arresto del sistema operativo?
Quando il sistema operativo viene aggiornato, Azure Fabric esegue un'interruzione controllata 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 in OnStop prima che il processo venga arrestato. Dopo l'arresto del processo host di Azure, Windows eseguirà un arresto normale e graduale, che include il sollevamento degli eventi standard OnStop e correlati per i servizi Windows.
Per altre informazioni su come gestire un arresto dell'istanza, vedere Il modo giusto per gestire gli eventi OnStop di Azure, Personalizzare il ciclo di vita di un ruolo Web o di lavoro in .NET e RoleEntryPoint.OnStop().