Manutenzione di routine per servizio app di Azure, riavvii e tempi di inattività

Il servizio app di Azure è una piattaforma distribuita come servizio (PaaS) per l'hosting di applicazioni Web, API REST e back-end per dispositivi mobili. Uno dei vantaggi dell'offerta è che la manutenzione pianificata viene eseguita in background. I clienti possono concentrarsi sulla distribuzione, l'esecuzione e la gestione del codice dell'applicazione anziché preoccuparsi delle attività di manutenzione per l'infrastruttura sottostante. La manutenzione del servizio app di Azure è un processo affidabile progettato per evitare o ridurre al minimo i tempi di inattività per le applicazioni ospitate. Questo processo rimane in gran parte invisibile agli utenti delle applicazioni ospitate. Tuttavia, i nostri clienti si domandano spesso i tempi di inattività che riscontrano siano il risultato della manutenzione pianificata, soprattutto se le due circostanze sembrano coincidere nel tempo.

Background

Il meccanismo di manutenzione pianificata si basa sull'architettura delle unità di scala che ospitano i server in cui vengono eseguite le applicazioni distribuite. Qualsiasi unità di scala specifica contiene diversi tipi di ruoli che interagiscono tra loro. I due ruoli più rilevanti per il meccanismo di aggiornamento della manutenzione pianificata sono i ruoli di lavoro e file server. Per una descrizione più dettagliata di tutti i diversi ruoli e altri dettagli sull'architettura del servizio app, vedere Architettura del servizio app di Azure

Esistono diversi metodi per progettare una strategia di aggiornamento, ciascuno con i propri vantaggi e svantaggi. Una delle strategie usate per aggiornamenti fondamentali è che tali aggiornamenti non vengono eseguiti su server/ruoli attualmente usati dai clienti. Le istanze vengono invece aggiornate "a ondate" e le istanze in fase di aggiornamento non vengono usate dalle applicazioni. Le istanze usate dalle applicazioni vengono gradualmente sostituite da istanze aggiornate. Ciò risulterà in un avvio o un riavvio dell'applicazione. Dal punto di vista statistico e da osservazioni empiriche, i riavvii di applicazioni sono molto meno dannosi rispetto all'esecuzione della manutenzione in server usati attivamente dalle applicazioni.

Dettagli dell'aggiornamento dell'istanza

Durante ogni ciclo di manutenzione pianificata, possono verificarsi due scenari leggermente diversi. Questi due scenari sono correlati agli aggiornamenti eseguiti nei ruoli di Lavoratore e File server. A livello generale, entrambi questi scenari appaiono simili dal punto di vista dell'utente finale, ma esistono alcune importanti differenze che possono talvolta causare comportamenti imprevisti.

Quando un ruolo di File server deve essere aggiornato, è necessario eseguire la migrazione del volume di archiviazione usato dall'applicazione da un'istanza di File Server a un'altra. Durante questa modifica, un ruolo di File server viene aggiunto all'applicazione. In questo modo, un processo di lavoro viene riavviato simultaneamente in tutte le istanze del ruolo di Lavoratore nel piano di servizio app. Il riavvio del processo di lavoro è sovrapposto: il meccanismo di aggiornamento avvia prima il nuovo processo di lavoro, consente ad esso di completare l'avvio e invia nuove richieste al nuovo processo di lavoro. Quando il nuovo processo di lavoro risponde, le richieste esistenti hanno per impostazione predefinita 30 secondi per completare il processo di lavoro precedente prima che venga arrestato.

Quando un ruolo di Lavoratore viene aggiornato, il meccanismo di aggiornamento viene sostituito in modo analogo con un nuovo ruolo di Lavoratore aggiornato. Il ruolo di lavoro viene sostituito come segue: viene aggiunto un ruolo di lavoro aggiornato ad ASP, l'applicazione viene avviata nel nuovo ruolo di lavoro, l'infrastruttura attende l'avvio dell'applicazione, le nuove richieste vengono inviate alla nuova istanza del ruolo di lavoro, le richieste possono essere completate nell'istanza precedente, quindi l'istanza precedente del ruolo di lavoro viene rimossa dall'ASP. Questa sequenza si verifica in genere una volta per ogni istanza del ruolo di lavoro in ASP e viene distribuita nel corso minuti o ore a seconda delle dimensioni del piano e dell'unità di scala.

Le principali differenze tra questi due scenari sono:

• Una modifica del ruolo di File server comporta un riavvio simultaneo del processo di lavoro sovrapposto in tutte le istanze, mentre una modifica del ruolo di Lavoratore comporta l'avvio di un'applicazione in una singola istanza.
• Una modifica del ruolo di File server indica che l'applicazione viene riavviata nella stessa istanza in cui era in esecuzione in precedenza, mentre una modifica del ruolo di Lavoratore comporta l'esecuzione dell'applicazione in un'istanza diversa dopo l'avvio.

Il meccanismo di riavvio sovrapposto comporta un tempo di inattività zero pari a zero la maggior parte delle applicazioni e la manutenzione pianificata passa completamente inosservata. Se l'applicazione richiede del tempo perché sia avviata, potrebbe riscontrare un tempo di inattività minimo dovuto alla lentezza o ad errori dell'applicazione durante o poco dopo l'avvio del processo. La piattaforma continua a tentare di avviare l'applicazione fino al successo, ma se l'applicazione fallisce totalmente l'avvio, potrebbe verificarsi un tempo di inattività più lungo. Il tempo di inattività persiste fino a quando non viene eseguita un'azione correttiva, ad esempio il riavvio manuale dell'applicazione in tale istanza.

Gestione di errori imprevisti

Anche se questo articolo è incentrato in gran parte sulle attività di manutenzione pianificata, vale la pena menzionare che un comportamento simile può verificarsi a causa del ripristino della piattaforma da errori imprevisti. Se si verifica un errore hardware imprevisto che influisce su un ruolo di Lavoratore, la piattaforma lo sostituisce in modo analogo con un nuovo ruolo di Lavoratore. L'applicazione viene avviata in questo nuovo ruolo di Lavoratore. Quando un errore o una latenza influisce su un ruolo File server associato all'applicazione, quest'ultimo viene sostituito con un nuovo File server. Un riavvio del processo di lavoro viene eseguito in tutti i ruoli Lavoratore. È importante tenere questo fatto in considerazione durante la valutazione di le strategie per migliorare il tempo di attività per le applicazioni.

Strategie per aumentare il tempo di attività

La maggior parte delle applicazioni ospitate riscontra un tempo di inattività limitato o pari a zero durante la manutenzione pianificata. Tuttavia, questo non risulta utile per specifiche applicazioni con un comportamento di avvio più complesso e pertanto soggette a tempi di inattività al riavvio. Se le applicazioni riscontrano tempi di inattività ogni volta che vengono riavviate, risolvere il tempo di inattività risulta ancora più urgente. Esistono diverse funzionalità disponibili nell'offerta del servizio app progettate per ridurre ulteriormente i tempi di inattività in questi scenari. In generale, esistono due categorie di strategie che possono essere impiegate:

• Miglioramento della coerenza di avvio dell'applicazione
• Riduzione al minimo dei riavvii dell'applicazione

Migliorare la velocità di avvio dell'applicazione e garantire che sia sistematicamente completato con successo ha statisticamente una percentuale di successo più elevata. È consigliabile esaminare prima le opzioni disponibili in quest'area. Alcune di esse sono abbastanza facili da implementare e possono produrre importanti miglioramenti. Le strategie di coerenza di avvio usano sia le funzionalità del servizio app che le tecniche correlate al codice o alla configurazione dell'applicazione. La riduzione al minimo dei riavvii consiste in un gruppo di opzioni che possono essere usate qualora non sia possibile migliorare l'avvio dell'applicazione in modo da garantire una coerenza sufficiente. Queste opzioni sono in genere più costose e meno affidabili perché proteggono da un subset di riavvii. Non è possibile evitare tutti i riavvii. L'uso di entrambi i tipi di strategie risulta estremamente efficace.

Strategie per la coerenza degli avvii

Inizializzazione dell'applicazione (AppInit)

Quando un'applicazione viene avviata in un ruolo Lavoratore di Windows, l'infrastruttura del servizio app di Azure tenta di determinare quando l'applicazione sia pronta per la gestione di richieste prima che le richieste esterne vengano instradate a questo ruolo Lavoratore. Per impostazione predefinita, una richiesta riuscita alla radice (/) dell'applicazione segnala che l'applicazione è pronta per la gestione delle richieste. Per alcune applicazioni, questo comportamento predefinito non è sufficiente per garantire che l'applicazione sia completamente riscaldata. In genere, ciò si verifica se la radice dell'applicazione ha dipendenze limitate, ma altri percorsi si basano su più librerie o dipendenze esterne per poter funzionare. Il Modulo di inizializzazione dell'applicazione IIS è ideale per ottimizzare il comportamento di riscaldamento. A livello generale, consente al proprietario dell'applicazione di definire il percorso o i percorsi usati come indicatori che l'applicazione è pronta per gestire le richieste. Per una descrizione dettagliata di come implementare questo meccanismo, vedere l'articolo seguente: Riscaldamento del Servizio app. Se implementata correttamente, questa funzionalità può comportare un tempo di inattività pari a zero anche se l'avvio dell'applicazione è più complesso.

Le applicazioni Linux possono usare un meccanismo simile usando l'impostazione dell'applicazione WEBSITE_WARMUP_PATH.

Controllo integrità

Controllo integrità è una funzionalità progettata per gestire errori imprevisti di codice e piattaforma durante la normale esecuzione dell'applicazione, ma può essere utile anche per aumentare la resilienza dell'avvio. Controllo integrità esegue due diverse funzioni di correzione: la rimozione di un'istanza non riuscita dal servizio di bilanciamento del carico e la sostituzione di un'intera istanza. È possibile usare la rimozione di un'istanza dal servizio di bilanciamento del carico per gestire errori di avvio intermittenti. Se un'istanza restituisce errori dopo l'avvio nonostante l'uso di tutte le altre strategie, il controllo integrità può rimuovere l'istanza dal servizio di bilanciamento del carico fino a quando tale istanza non restituisce nuovamente il codice di stato 200 alle richieste di controllo integrità. Questa funzionalità funge quindi da protezione contro errori per ridurre al minimo eventuali tempi di inattività post-avvio. Questa funzionalità può essere utile se gli errori successivi all'avvio sono temporanei e non richiedono il riavvio del processo.

Correzione automatica

Correzione automatica per Windows e Linux è un'altra funzionalità progettata per l'esecuzione normale dell'applicazione, ma può essere usata anche per migliorare il comportamento di avvio. Se si nota che l'applicazione può talvolta entrare in uno stato non recuperabile dopo l'avvio, il controllo integrità non sarà adatto. Tuttavia, il ripristino automatico può riavviare automaticamente il processo di lavoro, il che può risultare utile in questo scenario. È possibile configurare una regola di correzione automatica che monitora le richieste non riuscite e attiva un riavvio del processo in una singola istanza.

Test di avvio dell'applicazione

Testare l'avvio di un'applicazione in modo esaustivo è un'operazione che può talvolta essere trascurata. Eseguire test di avvio in combinazione con altri fattori, ad esempio errori di dipendenza, errori di carico della libreria, problemi di rete e così via costituisce una sfida più impegnativa. Una frequenza di errore relativamente ridotta per l'avvio potrebbe non essere rilevata, ma potrebbe comportare una frequenza di errore elevata quando più istanze vengono riavviate a ogni ciclo di aggiornamento. Un piano con 20 istanze e un'applicazione con una percentuale di errori all'avvio del 5% comporta il mancato avvio di tre istanze in media per ogni ciclo di aggiornamento. Generalmente, ci sono tre riavvii dell'applicazione per ogni istanza (20 spostamenti di istanza e 2 riavvii correlati al file server per ogni istanza).

È consigliabile testare diversi scenari

• Test di avvio generali (un'istanza alla volta) per stabilire la frequenza di avvio delle singole istanze. È consigliabile accertarsi che questo scenario più semplice raggiunga il 100% prima di passare ad altri scenari più complessi.
• Simulare un errore di dipendenza all'avvio. Se l'app ha dipendenze da altri servizi di Azure o non di Azure, simulare il tempo di inattività in tali dipendenze per rivelare il comportamento dell'applicazione in tali condizioni.
• Avvio simultaneo di molte istanze (preferibilmente più istanze che in ambiente di produzione). I test con più istanze spesso rivelano errori di dipendenza generalmente usati solo durante l'avvio, ad esempio riferimenti a KeyVault, Configurazione app, database e così via. Queste dipendenze devono essere testate per il volume burst di richieste generate da un riavvio simultaneo dell'istanza.
• Aggiunta di un'istanza con carico completo: assicurarsi che AppInit sia configurato correttamente e che l'applicazione possa essere inizializzata completamente prima che le richieste vengano inviate alla nuova istanza. Il ridimensionamento manuale è un metodo semplice per replicare uno spostamento di un'istanza durante la manutenzione.
• Riavvio del processo di lavoro sovrapposto: verifica di nuovo che AppInit si configurato correttamente e che le richieste possano essere completate quando il processo di lavoro precedente viene completato e ne viene avviato uno nuovo. La modifica di una variabile di ambiente sottoposta a caricamento può simulare la modifica di un File server.
• Più app in un piano: se sono presenti più app nello stesso piano, eseguire tutti i test contemporaneamente in tutte le app.

Registrazione di avvio

La possibilità di risolvere retroattivamente gli errori di avvio nell'ambiente di produzione è una considerazione diversa dall'uso di test per migliorare la coerenza di avvio. Tuttavia, è ugualmente o più importante poiché, nonostante gli sforzi, si potrebbe non riuscire a simulare tutti i tipi di errori reali in un ambiente di test o controllo di qualità. È anche l'area più debole per la registrazione, poiché l'inizializzazione dell'infrastruttura di registrazione rappresenta un'altra attività di avvio che deve essere eseguita. Per questo motivo, l'ordine delle operazioni per l'inizializzazione dell'applicazione è una considerazione importante e può diventare un problema dell'uovo e la gallina. Ad esempio, se è necessario configurare la registrazione in base a un riferimento a KeyVault e non è possibile ottenere il valore di KeyVault, come si registra questo errore? È possibile valutare la duplicazione della registrazione di avvio tramite un meccanismo di registrazione diverso che non dipende da altri fattori esterni. Ad esempio, la registrazione di questi tipi di errori di avvio nel disco locale. La semplice attivazione di una funzionalità di registrazione generale, ad esempio la registrazione stdout di .NET Core, può essere controproducente, poiché questa registrazione continua a generare dati di log anche dopo l'avvio e questo può riempire il disco nel corso del tempo. Questa funzionalità può essere usata in modo strategico per la risoluzione degli errori di avvio riproducibili.

Strategie per ridurre al minimo i riavvii

Le strategie seguenti possono ridurre significativamente il numero di riavvii di un'applicazione durante la manutenzione pianificata. Alcune delle strategie di questa sezione possono anche fornire maggiore controllo su quando si verificano tali riavvii. Queste strategie, sebbene efficaci, non possono evitare completamente i riavvii. Il motivo principale è che alcuni riavvii si verificano a causa di errori imprevisti anziché della manutenzione pianificata.

cache locale

Cache locale è una funzionalità progettata per migliorare la resilienza a errori di archiviazione esterni. A livello generale, crea una copia del contenuto dell'applicazione nel disco locale dell'istanza in cui viene eseguita. Ciò isola l'applicazione da errori di archiviazione imprevisti, ma impedisce anche i riavvii causati da modifiche al file server. L'utilizzo di questa funzionalità può ridurre notevolmente il numero di riavvii durante la manutenzione pubblica (in genere, può rimuoverne circa due terzi). Poiché evita principalmente i riavvii simultanei del processo di lavoro, il conseguente miglioramento della coerenza di avvio dell'applicazione può essere ancora maggiore. Cache locale presenta alcune implicazioni di progettazione e modifiche al comportamento dell'applicazione, pertanto è importante testare interamente l'applicazione per assicurarsi che sia compatibile con questa funzionalità.

Notifiche di manutenzione pianificata e aree abbinate

Se si vuole ridurre il rischio di riavvii correlati ad aggiornamenti nell'ambiente di produzione, è possibile usare le Notifiche di manutenzione pianificata per essere notificati di quando un'applicazione specifica verrà aggiornata. È quindi possibile configurare una copia dell'applicazione in un'Area abbinata e instradare il traffico alla copia secondaria dell'applicazione durante la manutenzione nella copia primaria. Questa opzione può essere costosa, poiché la finestra per questa manutenzione è piuttosto ampia, quindi la copia dell'applicazione secondaria deve essere eseguita in istanze sufficienti almeno per diversi giorni. Questa opzione può essere meno costosa se è già stata configurata un'applicazione secondaria per favorire la resilienza generale. Questa opzione può ridurre il numero di riavvii ma, come altre opzioni in questa categoria, non è in grado di eliminare tutti i riavvii.

Controllo della finestra di manutenzione pianificata nell'ambiente del servizio app v3

Il controllo della finestra per la manutenzione è disponibile solo negli ambienti dell'ambiente del servizio app isolato v3. Se si usa già un ambiente del servizio app o si ha la possibilità di usarne uno, questo permette ai clienti di controllare il Comportamento di manutenzione pianificata a un livello elevato. Non è possibile controllare il tempo di manutenzione pianificata in un ambiente multi-tenant.