I riavvii dell'istanza del ruolo causati dagli aggiornamenti del sistema operativo della macchina virtuale di Azure

Questo articolo illustra gli effetti degli aggiornamenti del sistema operativo (VM) delle macchine virtuali di Microsoft Azure in caso di riavvio delle istanze del ruolo. Contiene informazioni dettagliate sulle pianificazioni di aggiornamento del sistema operativo e dell'agente guest, sugli impatti e sui requisiti del servizio, sulla notifica, sul rilevamento e su come risolvere i problemi comuni.

Aggiornare le pianificazioni di

Su base mensile, Microsoft rilascia una nuova versione del sistema operativo guest per le macchine virtuali PaaS (Platform as a Service) di Azure. La pianificazione esatta varia e la tendenza cronologica è visibile nelle versioni del sistema operativo guest di Azure e nella matrice di compatibilità dell'SDK. Durante questa implementazione, il controller di infrastruttura di Azure esegue due passaggi (un passaggio del sistema operativo host e un passaggio del sistema operativo guest) in tutti i data center. Viene eseguito anche un aggiornamento periodico dell'agente guest di Azure all'interno della macchina virtuale.

Le sezioni seguenti forniscono altri dettagli sui due passaggi di aggiornamento e sull'aggiornamento dell'agente guest.

Passaggio 1: sistema operativo host

Il primo passaggio aggiorna il sistema operativo host. Il sistema operativo host riavvia le istanze del ruolo e il controller di infrastruttura assicura che vengano riavviate solo le istanze di un dominio di aggiornamento alla volta. Durante questo riavvio, le istanze del ruolo passano attraverso il processo di arresto standard. L'evento RoleEnvironment.OnStop viene quindi eseguito per consentire l'arresto normale dell'istanza.

L'aggiornamento del sistema operativo host può richiedere diversi giorni per consentire all'infrastruttura di coordinare gli aggiornamenti in tutti i diversi servizi ospitati e i diversi domini di aggiornamento all'interno di un data center. In genere, diverse istanze della distribuzione vengono aggiornate diverse ore a parte.

Per altre informazioni sul processo di aggiornamento del sistema operativo host, vedere l'articolo relativo agli aggiornamenti dell'host di Azure: Why, when, and how Azure blog (Perché, quando e come Azure).

Passaggio 2: sistema operativo guest

Al termine dell'aggiornamento del sistema operativo host nel data center, il sistema operativo guest viene aggiornato per i servizi configurati per l'uso delle versioni automatiche del sistema operativo guest. Questo aggiornamento continua usando le regole di dominio di aggiornamento standard per il servizio. La macchina virtuale viene riavviata e la partizione di Windows (unità D) viene ricreata usando il sistema operativo aggiornato.

Il processo di aggiornamento del sistema operativo guest è molto più veloce rispetto all'aggiornamento del sistema operativo host. Ciò è dovuto al fatto che l'infrastruttura deve coordinare solo l'aggiornamento all'interno del servizio ospitato e dei domini di aggiornamento. La durata del processo di aggiornamento del sistema operativo guest per il servizio dipende in gran parte dai fattori seguenti:

• Numero di istanze del ruolo
• Numero di domini di aggiornamento
• Tempo necessario per arrestare il servizio (Stopping ed OnStop eventi)
• Tempo necessario per l'avvio del servizio (attività di avvio e evento OnStart )

Agente guest

L'agente guest di Azure viene aggiornato su base mensile circa. Quando l'agente guest viene aggiornato, vengono eseguite le azioni seguenti:

• Il processo host che esegue il ruolo (in genere WaWorkerHost o WaWebHost) viene arrestato normalmente.
• L'agente guest si aggiorna.
• Il processo host viene avviato di nuovo.

Per altre informazioni sul processo dell'agente guest e sul modo in cui interagisce con il servizio, vedere Flusso di lavoro dell'architettura della macchina virtuale classica di Windows Azure.

Impatto e requisiti del servizio

L'elenco seguente descrive gli effetti e i requisiti per il servizio cloud:

• Se uno dei ruoli ha una sola istanza, il servizio potrebbe riscontrare tempi di inattività. È necessario avere almeno due istanze di ogni ruolo perché il contratto di servizio richiede un tempo di attività del 99,95%.

• Si prevede che le istanze del ruolo vengano riavviate per l'aggiornamento del sistema operativo host circa una volta ogni mese. Se si dispone di aggiornamenti automatici del sistema operativo guest, attendere il riavvio delle istanze. In genere, i riavvii sono diverse ore a parte. Tuttavia, questo intervallo di tempo può cambiare a seconda del trucco dei diversi servizi esistenti all'interno di un data center.

• Il ruolo deve rispettare le regole che regolano gli aggiornamenti del sistema operativo host. In particolare, le istanze del ruolo devono raggiungere lo Ready stato entro 30 minuti dall'avvio delle attività di avvio. Per altre informazioni su questa limitazione, vedere Come procede un aggiornamento.

• L'aggiornamento del sistema operativo host causa un riavvio dell'istanza del ruolo e l'aggiornamento del sistema operativo guest causa l'equivalente di una ricreazione dell'immagine dell'istanza. A causa di questi eventi, le istanze del ruolo devono essere in grado di gestire le procedure seguenti:

  • Riavviare
  • Ricreare l'immagine
  • Ripetere il ciclo

Notifica

Attualmente, la piattaforma Azure non offre notifiche proattive quando si verifica un aggiornamento del sistema operativo. Le istanze del ruolo riceveranno un RoleEnvironment.Stopping evento prima dell'arresto. È possibile usare tale evento per terminare normalmente qualsiasi operazione eseguita dall'istanza del ruolo o per notificare a un amministratore che un'istanza sta arrestando.

È possibile sottoscrivere il feed RSS aggiornamenti del sistema operativo di Azure. Questo feed deve essere aggiornato nello stesso giorno in cui gli aggiornamenti del sistema operativo iniziano a essere distribuiti nel data center. Il feed in genere non fornisce notifiche proattive avanzate, ma consente di identificare quando si verificano gli aggiornamenti. Il completamento del processo di aggiornamento può richiedere diversi giorni. Pertanto, potrebbe essere necessario attendere uno o più giorni tra il momento in cui il feed RSS viene aggiornato e il servizio ospitato inizia l'aggiornamento.

L'elenco delle versioni del sistema operativo guest di Azure e l'elenco delle versioni del sistema operativo disponibili per la selezione nel portale di Azure vengono in genere aggiornate dopo il completamento dell'implementazione del sistema operativo guest. Non è consigliabile usare la voce più recente in questi elenchi come indicazione del momento in cui gli aggiornamenti del sistema operativo sono in corso.

Rilevamento

Attualmente, non esiste un modo diretto per rilevare un aggiornamento del sistema operativo host. Tuttavia, è possibile visualizzare l'evidenza del riavvio all'interno dei log nella macchina virtuale. A tale scopo, effettuare una delle operazioni seguenti:

• Nell'app Visualizzatore eventi cercare nei registri eventi di sistema l'origine evento USER32, l'ID evento 1074. Questo evento contiene il messaggio seguente:

  Il processo D:\Packages\GuestAgent\WaAppAgent.exe (RD00155D50206D) ha avviato l'arresto del computer RD00155D50206D per conto dell'utente NT AUTHORITY\SYSTEM per il motivo seguente: Arresto dell'API legacy

  Questo messaggio indica che l'agente guest di Infrastruttura di Azure (WaAppAgent.exe) ha avviato un arresto della macchina virtuale.

• In un editor di testo cercare un file di log di runtime dell'agente app precedente (AppAgentRuntime.log.old) per un _Context_Start messaggio in cui Context è uguale a StopContainer(). Per altre informazioni su come esaminare le voci di contesto nel log di runtime dell'agente app, vedere Risoluzione dei problemi relativi allo scenario 6 - Riciclo dei ruoli dopo l'esecuzione per un certo periodo di tempo nell'archivio del blog di Azure.

Problemi noti e soluzioni

Le sezioni seguenti illustrano alcuni problemi comuni che coinvolgono i riavvii dell'istanza del ruolo e come risolverli. Per altre informazioni sui processi in esecuzione e sul percorso dei file di log che è possibile usare per la risoluzione dei problemi, vedere Flusso di lavoro dell'architettura della macchina virtuale classica di Windows Azure.

Problema 1: le attività di avvio o il codice non riesce a eseguire la seconda volta dopo il riavvio di un sistema operativo host

Le attività di avvio o il codice nella OnStart funzione o Run potrebbero non riuscire la seconda volta dopo il riavvio di un sistema operativo host. Il riavvio dovrebbe richiamare le attività di avvio per l'esecuzione di nuovo. Questo errore impedisce all'istanza del ruolo di raggiungere lo Ready stato.

Cosa accade se si esegue un'operazione in un'attività di avvio e quindi si esegue un comando che restituisce un errore dopo l'esecuzione della seconda volta? In questo caso, l'attività di avvio avrà esito negativo e causerà l'avvio del riciclo dell'istanza del ruolo. Ad esempio, se si usa il comando appCMD set config per aggiungere una sezione di configurazione in Internet Information Services (IIS), il comando non riesce al secondo esecuzione. Il comando genera il messaggio di errore "New add object missing required attributes.The command generate the error message, "New add object missing required attributes. Impossibile aggiungere una voce di raccolta duplicata di tipo..." L'istanza del ruolo inizia quindi a riciclare.

Soluzione 1: Connettersi alla macchina virtuale ed eseguire il debug dell'errore di avvio o codice in modalità remota

Per risolvere questo tipo di errore, usare Remote Desktop Protocol (RDP) per connettersi alla macchina virtuale in modalità remota. Esaminare i registri eventi per individuare gli errori e archiviare nel file di WaHostBootstrapper.log gli errori delle attività di avvio. Durante il processo di sviluppo e test tipico, è consigliabile avviare in modo proattivo un riavvio delle istanze del ruolo dal portale di Azure. Questo passaggio consente di testare il servizio per assicurarsi che funzioni correttamente in questo scenario.

Una correzione comune per gli errori delle attività di avvio consiste nell'aggiungere un exit /b 0 comando alla fine dello script dell'attività di avvio. Questo comando di uscita termina lo script usando un codice di uscita che indica l'esito positivo. Per altre informazioni sul motivo per cui questo comando è necessario, vedere Come configurare ed eseguire attività di avvio per un servizio cloud di Azure (versione classica).

Problema 2: l'attività di avvio o il codice non viene eseguito dopo la ricreazione dell'immagine della partizione di Windows

La partizione di Windows (unità D) è in genere la posizione in cui vengono archiviate le installazioni del programma e le modifiche del Registro di sistema. Durante la parte del sistema operativo guest di un aggiornamento, la partizione di Windows viene ricreata l'immagine. Ciò potrebbe causare la perdita di queste installazioni e modifiche. Se il codice di avvio presuppone erroneamente che alcune modifiche del Registro di sistema siano ancora presenti dopo la ricreazione dell'immagine della partizione di Windows, l'istanza del ruolo potrebbe non funzionare correttamente. Questo errore impedisce all'istanza del ruolo di raggiungere lo Ready stato.

Ad esempio, l'attività di avvio potrebbe apportare una modifica al Registro di sistema. Archivia quindi un record di tale modifica nell'unità C o E per assicurarsi che la modifica del Registro di sistema non venga eseguita una seconda volta. Tuttavia, la modifica del Registro di sistema nell'unità D andrà persa a causa della ricreazione dell'immagine e l'attività di avvio non ripristinerà tale modifica del Registro di sistema perché l'attività non ritiene che sia necessaria. La modifica del Registro di sistema mancante può causare l'esito negativo del resto dell'attività di avvio.

Soluzione 2: Testare la ricreazione dell'immagini delle istanze del ruolo dal portale di Azure

Durante il processo di sviluppo e test tipico, è consigliabile avviare in modo proattivo una ricreazione dell'immagine delle istanze del ruolo dal portale di Azure. Questo passaggio consente di testare il servizio e assicurarsi che funzioni correttamente in questo scenario.

Problema 3: il completamento del codice di avvio richiede più di 30 minuti

Se il codice di avvio richiede più di 30 minuti, potrebbe essere presente più di un'istanza del ruolo fuori servizio contemporaneamente. Questo scenario si verifica in genere quando un'attività di avvio esegue una di queste azioni:

• Installa un programma o una funzionalità
• Scarica i dati della cache
• Scarica informazioni sul sito Web

Soluzione 3: Esaminare l'impatto e i requisiti del servizio

Esaminare la sezione Impatto e requisiti del servizio per sapere cosa aspettarsi e come è possibile prevenire o attenuare eventuali ritardi di avvio.

Problema 4: Azure non riavvia il sistema operativo host o guest dopo un aggiornamento

In rari casi, Azure potrebbe non riavviare l'host o il sistema operativo guest dopo un aggiornamento. In questo scenario, probabilmente verrà visualizzato un messaggio "In attesa di host" nel portale che non cambia dopo 30 minuti o più.

Soluzione 4a: Correggere il codice di avvio

Se è possibile usare Remote Desktop Protocol (RDP) per connettersi all'istanza del ruolo, potrebbe verificarsi un errore nel codice di avvio che è possibile correggere. Per altre informazioni su come correggere il codice di avvio, vedere Soluzione 1: Connettersi alla macchina virtuale ed eseguire il debug remoto dell'avvio o del codice.

Soluzione 4b: Eliminare la distribuzione

Se non è possibile usare RDP per connettersi all'istanza del ruolo, probabilmente l'unico modo per recuperare l'istanza consiste nell'eliminare la distribuzione.

Problema 5: Una o più istanze del ruolo non sono disponibili durante l'aggiornamento del sistema operativo

Se le istanze del ruolo non sono disponibili durante l'aggiornamento del sistema operativo, ciò può causare una riduzione della capacità del servizio. Si supponga, ad esempio, di avere due istanze di un ruolo Web e che entrambe le istanze vengono in genere eseguite al 75% dell'utilizzo della CPU. Se un'istanza viene riavviata durante l'aggiornamento, il traffico viene reindirizzato all'istanza rimanente. L'istanza non può gestire il carico aggiuntivo. Ciò comporta una riduzione della disponibilità del servizio.

Soluzione 5: Mantenere una capacità in eccesso sufficiente nel servizio

Assicurarsi che il servizio disponga di capacità in eccesso sufficiente per assorbire una determinata percentuale di istanze del ruolo non disponibili. Per calcolare la quantità di capacità in eccesso che è necessario rendere disponibili, dividere il numero uno per il numero di domini di aggiornamento. Ad esempio, se si dispone di due domini di aggiornamento, è necessaria una capacità di 1/2 = 50% in eccesso per gestire un dominio di aggiornamento che diventa non disponibile. Se si dispone di cinque domini di aggiornamento, è necessario 1/5 = 20% di capacità in eccesso per gestire la perdita di disponibilità in uno dei cinque domini di aggiornamento.

Problema 6: i client riscontrano interruzioni o timeout perché il sito Web richiede troppo tempo per scaldarsi

Il sito Web richiede alcuni minuti per scaldarsi? Ad esempio, il riscaldamento del sito Web potrebbe essere costituito da IIS standard o ASP.NET precompilazione e caricamento di moduli oppure potrebbe essere in fase di riscaldamento di una cache o di altre attività specifiche dell'app. In questo caso, i client potrebbero riscontrare interruzioni o timeout casuali.

Dopo il riavvio di un'istanza del ruolo e il OnStart codice ne completa l'esecuzione, l'istanza del ruolo viene ripristinata nella rotazione del servizio di bilanciamento del carico. L'istanza del ruolo inizierà quindi a ricevere richieste in ingresso. Se il sito Web è ancora in fase di riscaldamento, tutte le richieste in ingresso verranno messe in coda e si verifica il timeout. Si supponga di avere solo due istanze del ruolo Web. In questo caso, l'istanza riceverà il IN_0 100% delle richieste in ingresso mentre l'istanza IN_1 viene riavviata per l'aggiornamento del sistema operativo guest. Tuttavia, l'istanza IN_0 è ancora in fase di riscaldamento. Questo scenario può causare un'interruzione completa del servizio fino al termine del riscaldamento del sito Web in entrambe le istanze.

Soluzione 6: Arrestare la ricezione di richieste in ingresso da parte di un'istanza del ruolo fino al completamento del riscaldamento

È consigliabile mantenere il codice di gestione degli eventi per l'istanza OnStart del ruolo fino al completamento del sito Web. Per implementare questo processo di evento, è possibile usare il codice di esempio seguente:

public class WebRole : RoleEntryPoint {
    public override bool OnStart () {
        // For information about handling configuration changes, see the article
        // "Customize the Lifecycle of a Web or Worker role in .NET" at
        // https://learn.microsoft.com/azure/cloud-services/cloud-services-role-lifecycle-dotnet.
        IPHostEntry ipEntry = Dns.GetHostEntry (Dns.GetHostName ());
        string ip = null;
        foreach (IPAddress ipaddress in ipEntry.AddressList) {
            if (ipaddress.AddressFamily.ToString () == "InterNetwork") {
                ip = ipaddress.ToString ();
            }
        }
        string urlToPing = "https://" + ip;
        HttpWebRequest req = HttpWebRequest.Create (urlToPing) as HttpWebRequest;
        WebResponse resp = req.GetResponse ();
        return base.OnStart ();
    }
}

Ulteriori informazioni

• Domande frequenti sul riavvio dell'istanza del ruolo 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.