Strategie di architettura per la riparazione automatica e l'auto-conservazione

Si applica a questa raccomandazione per l'affidabilità del framework ben progettato di Azure:

Questa guida descrive le raccomandazioni per la creazione di funzionalità di auto-conservazione e riparazione automatica nell'architettura dell'applicazione per ottimizzare l'affidabilità.

Le funzionalità di conservazione automatica aggiungono resilienza al carico di lavoro. Riducono la probabilità di un'interruzione completa e consentono al carico di lavoro di funzionare normalmente, o in uno stato danneggiato, quando si verificano errori. Le funzionalità di riparazione automatica consentono di evitare tempi di inattività creando nel rilevamento degli errori e azioni correttive automatiche per rispondere agli errori.

Definizioni

Progettare per la ridondanza

Una delle strategie più efficaci per proteggere il carico di lavoro da malfunzionamenti consiste nel creare ridondanza in tutti i relativi componenti ed evitare singoli punti di errore. La possibilità di eseguire il failover dei componenti o dell'intero carico di lavoro sulle risorse ridondanti offre un modo efficiente per gestire la maggior parte degli errori nel sistema.

Creare ridondanza a livelli diversi, prendere in considerazione componenti dell'infrastruttura ridondanti, ad esempio calcolo, rete e archiviazione, e prendere in considerazione la distribuzione di più istanze della soluzione. A seconda dei requisiti aziendali, è possibile creare ridondanza all'interno di una singola area o in più aree. È anche possibile decidere se è necessaria una progettazione attiva-attiva o passiva attiva per soddisfare i requisiti di ripristino. Per altre informazioni, vedere Strategie di architettura per la progettazione di strategie di ridondanza e architettura per l'uso di zone e aree di disponibilità.

Progettazione per la conservazione automatica

Per progettare il carico di lavoro per la conservazione automatica, seguire i modelli di progettazione dell'architettura dell'infrastruttura e dell'applicazione per ottimizzare la resilienza del carico di lavoro. Per ridurre al minimo la probabilità di un'interruzione completa dell'applicazione, aumentare la resilienza della soluzione eliminando singoli punti di guasto e riducendo al minimo il raggio di esplosione degli errori. Gli approcci di progettazione in questo articolo offrono diverse opzioni per rafforzare la resilienza del carico di lavoro e soddisfare gli obiettivi di affidabilità definiti del carico di lavoro.

Linee guida e modelli di progettazione dell'infrastruttura

A livello di infrastruttura, una progettazione dell'architettura ridondante deve supportare i flussi critici, con risorse distribuite tra zone o aree di disponibilità. Implementare la scalabilità automatica quando possibile. La scalabilità automatica consente di proteggere il carico di lavoro da picchi imprevisti nell'attività, rafforzando ulteriormente l'infrastruttura.

Usare il modello Deployment Stamps o il modello Bulkhead per ridurre al minimo il raggio dell'esplosione quando si verificano problemi. Questi modelli consentono di mantenere disponibile il carico di lavoro se un singolo componente non è disponibile. Usare i modelli di progettazione delle applicazioni seguenti in combinazione con la strategia di scalabilità automatica.

• Modello di stamp di distribuzione: effettuare il provisioning, gestire e monitorare un gruppo di risorse diverso per ospitare e gestire più carichi di lavoro o tenant. Ogni singola copia viene chiamata stamp o a volte un'unità di servizio, un'unità di scala o una cella.

• Modello di intestazione bulk: partizionare le istanze del servizio in gruppi diversi, noti come pool, in base ai requisiti di carico e disponibilità del consumer. Questa progettazione consente di isolare gli errori e di sostenere le funzionalità del servizio per alcuni consumer, anche durante un errore.

Linee guida e modelli di progettazione delle applicazioni

Evitare di compilare applicazioni monolitiche nella progettazione dell'applicazione. Usare servizi o microservizi ad accoppiamento libero che comunicano tra loro tramite standard ben definiti per ridurre il rischio di problemi estesi quando si verificano malfunzionamenti in un singolo componente. Ad esempio, è possibile standardizzare l'uso di un bus di servizio per gestire tutte le comunicazioni asincrone. La standardizzazione dei protocolli di comunicazione garantisce che la progettazione delle applicazioni sia coerente e semplificata, che rende il carico di lavoro più affidabile e più semplice da risolvere quando si verificano malfunzionamenti. Quando pratico, preferire la comunicazione asincrona tra i componenti rispetto alla comunicazione sincrona per ridurre al minimo i problemi di timeout, ad esempio i messaggi non recapitabili.

Usare modelli comprovati del settore per sviluppare gli standard di progettazione e semplificare gli aspetti dell'architettura. I modelli di progettazione che consentono di supportare l'affidabilità sono disponibili nell'articolo Modelli di affidabilità .

Progettazione per l'auto-riparazione

Per progettare il carico di lavoro per la riparazione automatica, implementare il rilevamento degli errori in modo che le risposte automatiche vengano attivate e i flussi critici vengano ripristinati normalmente. Abilitare la registrazione per fornire informazioni operative sulla natura dell'errore e sull'esito positivo del ripristino. Gli approcci da adottare per ottenere la riparazione automatica per un flusso critico dipendono dalle destinazioni di affidabilità definite per tale flusso e dai componenti e dalle dipendenze del flusso.

Linee guida per la progettazione dell'infrastruttura

A livello di infrastruttura, i flussi critici devono essere supportati da una progettazione dell'architettura ridondante, con failover automatizzato abilitato per i componenti che lo supportano. È possibile abilitare il failover automatico per i tipi di servizi seguenti:

• Risorse di calcolo: i set di scalabilità di macchine virtuali di Azure e la maggior parte dei servizi di calcolo PaaS (Platform as a Service) possono essere configurati per il failover automatico.

• Database: i database relazionali possono essere configurati per il failover automatico con soluzioni come cluster di failover SQL di Azure, gruppi di disponibilità AlwaysOn o funzionalità predefinite con servizi PaaS. I database NoSQL hanno funzionalità di clustering simili e funzionalità predefinite per i servizi PaaS.

• Archiviazione: usare le opzioni di archiviazione ridondanti con failover automatico.

Linee guida per la progettazione di applicazioni

Oltre a usare modelli di progettazione che supportano l'affidabilità, altre strategie che consentono di sviluppare meccanismi di riparazione automatica includono:

• Usare i checkpoint per le transazioni a esecuzione prolungata: i checkpoint possono fornire resilienza se un'operazione a esecuzione prolungata ha esito negativo. Quando l'operazione viene riavviata, ad esempio se viene prelevata da un'altra macchina virtuale, può riprendere dall'ultimo checkpoint. Prendere in considerazione l'implementazione di un meccanismo che registra le informazioni sullo stato dell'attività a intervalli regolari. Salvare questo stato in una risorsa di archiviazione durevole accessibile da qualsiasi istanza del processo che esegue l'attività. Se il processo viene arrestato, il lavoro che stava eseguendo può essere ripreso dall'ultimo checkpoint usando un'altra istanza. Sono disponibili librerie che forniscono questa funzionalità, ad esempio NServiceBus e MassTransit. Vengono mantenuti in modo trasparente, in cui gli intervalli sono allineati all'elaborazione dei messaggi dalle code nel bus di servizio di Azure.

• Implementare azioni di riparazione automatica: Usare azioni automatizzate attivate dalla soluzione di monitoraggio quando vengono rilevate modifiche dello stato di integrità predeterminato. Ad esempio, se il monitoraggio rileva che un'app Web non risponde alle richieste, è possibile compilare l'automazione tramite uno script di PowerShell per riavviare il servizio app. A seconda del set di competenze del team e delle tecnologie di sviluppo preferite, usare un webhook o una funzione per creare azioni di automazione più complesse. Per un esempio di uso di una funzione per rispondere alla limitazione della limitazione del database, vedere l'architettura di riferimento dell'automazione cloud basata su eventi. L'uso di azioni automatizzate consente di recuperare rapidamente e ridurre al minimo la necessità di intervento umano.

Implementare una modalità di riduzione delle prestazioni normale

Nonostante i meccanismi di auto-conservazione e riparazione automatica, è comunque possibile riscontrare situazioni in cui uno o più componenti non funzionano nella misura in cui non sono disponibili per un certo periodo di tempo. In questi casi, idealmente, il carico di lavoro può mantenere una funzionalità sufficiente per continuare in uno stato degradato. Per assicurarsi che ciò sia possibile, progettare e implementare una modalità di riduzione delle prestazioni normale. Si tratta di un flusso di lavoro distinto abilitato in reazione ai componenti non riusciti. Le considerazioni relative alla progettazione e all'implementazione includono:

• Rilevamento degli errori e avvio automatico: I sistemi di monitoraggio e avviso devono rilevare componenti degradati e non riusciti, quindi usare questi segnali per creare un flusso di lavoro che determina quando si passa alla modalità di riduzione delle prestazioni normale è necessaria. Il flusso di lavoro deve quindi reindirizzare automaticamente le chiamate da e verso i componenti interessati a componenti alternativi o altre azioni simili.
• Implementare un'esperienza utente danneggiata: Includere un meccanismo di notifica per gli utenti nella modalità di riduzione delle prestazioni normale per assicurarsi che sappiano quali funzionalità rimangono e cosa è cambiato. Questo in genere si riflette nei messaggi legati a diverse funzioni del carico di lavoro, ad esempio un popup quando si aggiungono elementi a un carrello.
• Creare percorsi alternativi per completare le funzioni essenziali del carico di lavoro: Riflettere sui flussi critici del carico di lavoro e determinare come gestire tali flussi quando i componenti di base non sono disponibili. Ad esempio, se un database è inattivo, l'applicazione potrebbe passare a una modalità di sola lettura usando i dati memorizzati nella cache. Per illustrare ulteriormente questo esempio, se un gateway di pagamento è inattivo, l'uso di dati memorizzati nella cache potrebbe consentire agli utenti di salvare il carrello e completare l'acquisto in un secondo momento.

Implementare meccanismi per la gestione degli errori temporanei

Gli errori temporanei, ad esempio i timeout di rete, sono un problema comune per i carichi di lavoro cloud, quindi la presenza di meccanismi per gestirli può ridurre al minimo i tempi di inattività e la risoluzione dei problemi durante il funzionamento del carico di lavoro nell'ambiente di produzione. Poiché la maggior parte delle operazioni che hanno esito negativo a causa di un errore temporaneo avrà esito positivo se è consentito tempo sufficiente prima di ritentare l'operazione, l'uso di un meccanismo di ripetizione dei tentativi è l'approccio più comune per gestire gli errori temporanei. Quando si progetta la strategia di ripetizione dei tentativi, considerare quanto segue:

Per una revisione completa delle raccomandazioni e delle considerazioni, vedere la guida alla progettazione degli errori temporanei .

Implementare processi in background

I processi in background sono un modo efficace per migliorare l'affidabilità di un sistema separando le attività dall'interfaccia utente. Implementare un'attività come processo in background se non richiede input o feedback dell'utente e se non influisce sulla velocità di risposta dell'interfaccia utente.

Esempi comuni di processi in background sono:

• Processi a elevato utilizzo di CPU, ad esempio l'esecuzione di calcoli complessi o l'analisi di modelli strutturali.
• Processi con utilizzo intensivo di I/O, ad esempio l'esecuzione di più operazioni di archiviazione o l'indicizzazione di file di grandi dimensioni.
• Processi batch, ad esempio l'aggiornamento regolare dei dati o l'elaborazione di attività in un momento specifico.
• Flussi di lavoro a esecuzione prolungata, ad esempio il completamento di un ordine o il provisioning di servizi e sistemi.

Fare riferimento alla guida alla progettazione dei processi in background per indicazioni dettagliate per una revisione completa delle raccomandazioni e delle considerazioni.

Facilitazione di Azure

La maggior parte dei servizi di Azure e degli SDK client include un meccanismo di ripetizione dei tentativi. Ma differiscono perché ogni servizio ha caratteristiche e requisiti diversi, quindi ogni meccanismo di ripetizione dei tentativi viene ottimizzato per un servizio specifico. Per altre informazioni, vedere Raccomandazioni per la gestione degli errori temporanei.

Usare i gruppi di azioni di Monitoraggio di Azure per le notifiche, ad esempio posta elettronica, voce o SMS e per attivare azioni automatizzate. Quando si riceve una notifica di errore, attivare un runbook di Automazione di Azure, Hub eventi di Azure, una funzione di Azure, un'app per la logica o un webhook per eseguire un'azione di correzione automatica.

Example

Ad esempio, i casi d'uso di alcuni modelli, vedere il modello di app Web affidabile per .NET. Seguire questa procedura per distribuire un'implementazione di riferimento.

Collegamenti correlati

• Modelli di affidabilità
• Gestire gli errori temporanei
• Sviluppare processi in background
• Modelli di progettazione cloud
• Progettazione per la riparazione automatica

Elenco di controllo per l'affidabilità

Fare riferimento al set completo di raccomandazioni.