Condividi tramite

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

  • Articolo

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

Pianificazioni dell'aggiornamento

Su base mensile circa, 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) attraverso tutti i data center. Un aggiornamento periodico dell'agente guest di Azure viene eseguito anche 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 verifica 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 offrire la possibilità di arrestare normalmente l'istanza.

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

Per altre informazioni sul processo di aggiornamento del sistema operativo host, vedere l'articolo relativo agli aggiornamenti dell'host di Azure: 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 (l'unità D) viene ricreata usando il sistema operativo aggiornato.

Il processo di aggiornamento del sistema operativo guest è molto più veloce dell'aggiornamento del sistema operativo host. Questo perché 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 l'arresto del 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, si verificano le azioni seguenti:

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

Per altre informazioni sul processo dell'agente guest e sul modo in cui interagisce con il servizio, vedere Flusso di lavoro dell'architettura classica delle macchine virtuali 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 al mese. Se sono disponibili aggiornamenti automatici del sistema operativo guest, è previsto che le istanze vengano riavviate di nuovo. In genere, i riavvii si differenziano per diverse ore. Tuttavia, questo intervallo di tempo può cambiare a seconda della composizione 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 nuova immagine dell'istanza. A causa di questi eventi, le istanze del ruolo devono essere in grado di gestire le procedure seguenti:

    • Riavvia
    • Ricreare l'immagine
    • Riciclare

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 tutte le operazioni eseguite dall'istanza del ruolo o per notificare a un amministratore che un'istanza è in fase di arresto.

È possibile sottoscrivere il feed RSS Aggiornamenti del sistema operativo di Azure. Questo feed deve essere aggiornato lo stesso giorno in cui gli aggiornamenti del sistema operativo iniziano a essere implementati 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 l'aggiornamento del feed RSS e l'avvio dell'aggiornamento del servizio ospitato.

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 al termine dell'implementazione del sistema operativo guest. Non è consigliabile usare la voce più recente in questi elenchi come indicazione del momento in cui sono in corso gli aggiornamenti del sistema operativo.

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 della macchina virtuale. A tale scopo, effettuare una delle operazioni seguenti:

  • Nell'app Visualizzatore eventi cercare USER32, ID evento 1074, nei registri eventi di sistema. 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 dell'infrastruttura di Azure (WaAppAgent.exe) ha avviato l'arresto della macchina virtuale.

  • In un editor di testo cercare in un file di log di runtime dell'agente app precedente (AppAgentRuntime.log.old) 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 Scenario di risoluzione dei problemi 6 - Riciclo dei ruoli dopo l'esecuzione per un certo periodo di tempo nell'archivio del blog di Azure.

Problemi e soluzioni comuni

Le sezioni seguenti illustrano alcuni problemi comuni che coinvolgono il riavvio 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 classica delle macchine virtuali di Windows Azure.

Problema 1: le attività o il codice di avvio non vengono eseguiti 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 succede se si esegue un'operazione in un'attività di avvio e quindi si esegue un comando che restituisce un errore dopo la seconda esecuzione? 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 avrà esito negativo alla seconda esecuzione. Il comando genera il messaggio di errore "New add object missing required attributes. Impossibile aggiungere una voce di raccolta duplicata di tipo..." Quindi, l'istanza del ruolo inizia il riciclo.

Soluzione 1: connettersi alla macchina virtuale ed eseguire il debug dell'avvio o dell'errore del codice in remoto

Per risolvere questo tipo di errore, usare Remote Desktop Protocol (RDP) per connettersi alla macchina virtuale in remoto. Esaminare i log eventi per verificare la presenza di errori e archiviare nel file WaHostBootstrapper.log gli errori delle attività di avvio. Durante il tipico processo di sviluppo e test, è 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à o il codice di avvio 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, viene ricreata l'immagine della partizione di Windows. Ciò potrebbe causare la perdita di queste installazioni e modifiche. Se il codice di avvio presuppone erroneamente che alcune modifiche del Registro di sistema esistano ancora 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 rivisitazione e l'attività di avvio non ripristinerà tale modifica del Registro di sistema perché l'attività non lo ritiene necessario. La modifica mancante del Registro di sistema può causare l'esito negativo del resto dell'attività di avvio.

Soluzione 2: testare la reimaging delle istanze del ruolo dal portale di Azure

Durante il tipico processo di sviluppo e test, è 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, è possibile che sia disponibile più di un'istanza del ruolo fuori servizio contemporaneamente. Questo scenario si verifica più comunemente quando un'attività di avvio esegue una di queste azioni:

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

Soluzione 3: Esaminare gli impatti e i requisiti del servizio

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

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

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

Soluzione 4a: correggere il codice di avvio

Se si è in grado di usare il protocollo RDP (Remote Desktop Protocol) 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 dell'avvio o dell'errore del codice in remoto.

Soluzione 4b: eliminare la distribuzione

Se non è possibile usare RDP per connettersi all'istanza del ruolo, probabilmente l'unico modo per ripristinare 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 siano in genere eseguite al 75% di utilizzo della CPU. Se un'istanza viene riavviata durante l'aggiornamento, il traffico viene reindirizzato all'istanza rimanente. Tale istanza non è in grado di gestire il carico aggiuntivo. Ciò causa 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 disponibile, dividere il numero uno per il numero di domini di aggiornamento. Ad esempio, se si dispone di due domini di aggiornamento, è necessario 1/2 = 50% di capacità 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 tuo sito Web richiede troppo tempo per riscaldarsi

Il tuo sito web richiede alcuni minuti per riscaldarsi? Ad esempio, il warmup del sito Web può essere costituito da IIS standard o ASP.NET precompilazione e caricamento del modulo oppure potrebbe riscaldare una cache o altre attività specifiche dell'app. In questo caso, i client potrebbero riscontrare un'interruzione o timeout casuali.

Dopo il riavvio di un'istanza del ruolo e il OnStart completamento dell'esecuzione del codice, l'istanza del ruolo viene ripristinata nella rotazione del servizio di bilanciamento del carico. L'istanza del ruolo inizierà quindi a ricevere le richieste in ingresso. Se il tuo sito Web è ancora in fase di riscaldamento, tutte le richieste in arrivo saranno in coda e 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 si sta ancora riscaldando. Questo scenario può causare un'interruzione completa del servizio fino al completamento 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 termine del warmup

È consigliabile evitare che il OnStart codice di gestione degli eventi per l'istanza del ruolo finisca fino a quando il sito Web non completa il riscaldamento. 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

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.