Affidabilità in Griglia di eventi di Azure

Griglia di eventi di Azure è un servizio di messaggistica completamente gestito che consente la comunicazione basata su eventi tra servizi e applicazioni. Viene comunemente usato per la creazione di architetture guidate dagli eventi e l'integrazione di servizi di Azure con applicazioni personalizzate.

Quando si usa Azure, l'affidabilità è una responsabilità condivisa. Microsoft offre una gamma di funzionalità per supportare la resilienza e il ripristino. L'utente è responsabile della comprensione del funzionamento di tali funzionalità all'interno di tutti i servizi usati e della selezione delle funzionalità necessarie per soddisfare gli obiettivi aziendali e gli obiettivi di tempo di attività.

Questo articolo descrive come rendere Griglia di eventi di Azure resiliente a varie potenziali interruzioni e problemi, tra cui errori temporanei, errori della zona di disponibilità e errori a livello di area. Vengono inoltre evidenziate informazioni chiave sul contratto di servizio di Griglia di eventi di Azure.

Raccomandazioni per la distribuzione di produzione

Azure Well-Architected Framework offre raccomandazioni su affidabilità, sicurezza, costi, operazioni e prestazioni. Per comprendere come queste aree influiscono tra loro e contribuiscono a una soluzione Affidabile di Griglia di eventi di Azure, vedere Linee guida di Azure Well-Architected Framework per Griglia di eventi di Azure.

Panoramica dell'architettura di affidabilità

Questa sezione descrive alcuni degli aspetti importanti del funzionamento del servizio più rilevanti dal punto di vista dell'affidabilità. La sezione presenta l'architettura logica, che include alcune delle risorse e delle funzionalità distribuite e usate. Illustra anche l'architettura fisica, che fornisce informazioni dettagliate sul funzionamento del servizio sotto le quinte.

Architettura logica

Griglia di eventi di Azure instrada gli eventi dagli editori di eventi ai consumer di eventi. Viene usato sia dalle applicazioni dei clienti che dai servizi di Azure per generare e utilizzare eventi, ad esempio le notifiche quando vengono create, aggiornate o eliminate le risorse.

Griglia di eventi supporta più tipi di risorse e modelli di distribuzione:

• Gli argomenti sono le entità principali che ricevono e archiviano gli eventi.

  Gli argomenti di sistema vengono creati automaticamente dai servizi di Azure per generare eventi per tipi di risorse di Azure specifici. Gli argomenti personalizzati vengono creati e gestiti dall'utente.

  Gli argomenti possono supportare sia il recapito push che il recapito pull.

• I domini eventi raggruppano più argomenti personalizzati in un singolo endpoint, semplificando la pubblicazione di eventi. Per altre informazioni, vedere Informazioni sui domini eventi per la gestione degli argomenti di Griglia di eventi.

• Gli spazi dei nomi vengono usati con il livello standard e forniscono un contenitore per più risorse di Event Grid. Per altre informazioni, vedere Concetti relativi agli spazi dei nomi di Azure Event Grid.

Griglia di eventi supporta più livelli, tra cui il livello basic e il livello standard. Questi livelli offrono funzionalità diverse e differiscono dal modo in cui le risorse vengono distribuite e gestite. Per altre informazioni, vedere Scegliere il livello griglia di eventi appropriato per la soluzione.

Architettura fisica

Griglia di eventi di Azure è un servizio completamente gestito. Microsoft gestisce l'infrastruttura sottostante, incluse le risorse di calcolo e archiviazione. Nelle aree supportate, Event Grid distribuisce automaticamente le risorse tra le zone di disponibilità per fornire ridondanza zonale integrata.

Resilienza a errori temporanei

Gli errori temporanei sono errori brevi e intermittenti nei componenti. Si verificano spesso in un ambiente distribuito come il cloud e fanno parte delle normali operazioni. Gli errori temporanei si correggono dopo un breve periodo di tempo. È importante che le applicazioni possano gestire gli errori temporanei, in genere ritentando le richieste interessate.

Tutte le applicazioni ospitate nel cloud devono seguire le indicazioni sulla gestione degli errori temporanei di Azure quando comunicano con qualsiasi API, database e altri componenti ospitati nel cloud. Per altre informazioni, vedere Raccomandazioni per la gestione degli errori temporanei.

Quando si usa Griglia di eventi, prendere in considerazione le procedure seguenti per assicurarsi che la soluzione sia resiliente agli errori temporanei:

• Autori di eventi: Quando un'applicazione client pubblica eventi in Griglia di eventi, è responsabile della gestione degli errori temporanei. Le applicazioni devono implementare la logica di ripetizione dei tentativi durante la pubblicazione di eventi. Per altre informazioni, vedere Risolvere i problemi di connessione temporanei.

  È consigliabile usare gli SDK del piano dati di Griglia di eventi, che forniscono automaticamente la gestione degli errori temporanei.

• Consumer di eventi: Event Grid recapita gli eventi alle destinazioni configurate. Per queste connessioni in uscita, si configurano le politiche di ripetizione dei tentativi nelle sottoscrizioni di eventi. Questi criteri definiscono la frequenza e per quanto tempo Griglia di eventi ritenta il recapito quando si verificano errori, inclusi gli errori temporanei. Per altre informazioni, vedere Recapito push dei messaggi e ripetizione dei tentativi con gli argomenti dello spazio dei nomi

• Idempotenza: È consigliabile progettare l'architettura di eventi per l'idempotenza, il che significa che gli eventi possono essere ricevuti ed elaborati più volte in modo sicuro. Ad esempio, se si verifica un errore temporaneo o un altro problema quando l'applicazione elabora un evento, un approccio idempotente significa che l'applicazione può rielaborare il messaggio e recuperare.

  L'utente è responsabile della progettazione dell'architettura e dell'applicazione di eventi per supportare l'idempotenza. Per informazioni generali, vedere Idempotency.

• Dead-lettering: Event Grid supporta il dead-lettering per gli eventi non recapitabili, il che aiuta a rendere persistenti i dati durante guasti prolungati nei consumer di eventi. Per ulteriori informazioni, vedere Dead lettering per la sottoscrizione di eventi ai temi dei namespace in Azure Event Grid.

Resilienza ai guasti delle zone di disponibilità

Le zone di disponibilità sono gruppi di data center separati fisicamente all'interno di un'area di Azure. In caso di guasto in una zona, i servizi possono passare a una delle zone restanti.

Le risorse di Event Grid di Azure sono ridondanti in tutte le zone nelle aree che supportano le zone di disponibilità. La ridondanza della zona significa che anche quando una zona di disponibilità presenta un problema, le risorse di Griglia di eventi continuano a funzionare usando l'infrastruttura in altre zone. I dati degli eventi vengono replicati automaticamente in tre zone di disponibilità per garantire resilienza all'interno della regione, e Griglia di eventi si auto-ripara durante un'interruzione che colpisce l'intera zona. Non è necessario abilitare o configurare questa funzionalità.

Requisiti

Supporto per l'area: La ridondanza della zona è disponibile in tutte le aree di Azure che supportano le zone di disponibilità.

Cost

Non sono previsti costi aggiuntivi per la ridondanza della zona. Non è possibile abilitare o disabilitare questa funzionalità; è incluso per impostazione predefinita nelle aree supportate.

Configurare il supporto delle zone di disponibilità

Non è necessaria alcuna configurazione. Tutte le risorse Event Grid nelle aree supportate sono automaticamente con ridondanza zonale.

Comportamento quando tutte le zone sono integre

Questa sezione descrive cosa aspettarsi quando una risorsa Event Grid è a zone-redundant e tutte le zone sono operative.

• Operazione tra zone: Event Grid opera in un modello attivo-attivo nelle zone di disponibilità. Le connessioni client vengono bilanciate automaticamente tra le zone e il servizio indirizza le operazioni all'infrastruttura di messaggistica disponibile indipendentemente dalla zona.

• Replica dei dati tra zone: Griglia di eventi replica automaticamente i metadati e i dati degli eventi tra zone di disponibilità per mantenere la resilienza.

Comportamento durante un errore di zona

Questa sezione descrive cosa aspettarsi quando una risorsa Event Grid è zona ridondante e si verifica un'interruzione in una delle zone.

• Rilevamento e risposta: Event Grid rileva automaticamente i guasti della zona e avvia il failover verso zone funzionanti. Non è necessario eseguire alcuna operazione per avviare un failover di zona.

• Notifica: Microsoft non invia automaticamente una notifica quando una zona è inattiva. È tuttavia possibile usare Integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi eventuali errori di zona, ed è possibile configurare gli avvisi di integrità dei servizi per notificare eventuali problemi.

• Richieste attive: Durante un errore di zona, Griglia di eventi potrebbe eliminare le richieste attive. Se i loro client gestiscono in modo appropriato gli errori temporanei, ad esempio effettuando un nuovo tentativo dopo un breve periodo di tempo, in genere si evita un impatto significativo.

• Perdita di dati prevista: Il modello di ridondanza della zona di Griglia di eventi è progettato per consentire la resilienza agli errori di zona con un impatto minimo. Tuttavia, durante un errore di zona, è possibile che si verifichi una perdita di dati.

  Se è necessario assicurarsi che l'applicazione non perda i dati anche durante un errore di zona, è necessario:

  • Progettare i produttori e i consumatori di eventi per rispettare le raccomandazioni per la gestione degli errori temporanei, inclusi i tentativi e l'idempotenza.
  • Pianifica la durabilità degli eventi alla fonte o in un archivio eventi duraturo.

• Tempo di inattività previsto: Un errore di zona potrebbe causare alcuni secondi di inattività. Se i loro client gestiscono in modo appropriato gli errori temporanei, ad esempio effettuando un nuovo tentativo dopo un breve periodo di tempo, in genere si evita un impatto significativo.

• Reindirizzamento del traffico: Griglia di eventi rileva la perdita della zona e reindirizza automaticamente le nuove richieste all'infrastruttura in una delle zone di disponibilità integre.

Ripristino della zona

Quando la zona interessata viene ripristinata, Griglia di eventi lo reintegra automaticamente nel servizio senza richiedere l'azione del cliente. La zona ripristinata accetta quindi nuove connessioni ed elabora i messaggi insieme alle altre zone. I dati replicati nelle zone sopravvissute durante l'interruzione rimangono intatti e la replica normale riprende in tutte le zone. Non è necessario intervenire per il ripristino o la reintegrazione della zona.

Verifica dei guasti di zona

Event Grid gestisce il routing del traffico, il failover e il ripristino della zona per i guasti della zona, quindi non è necessario convalidare i processi di guasto delle zone di disponibilità o fornire ulteriore input.

Resilienza agli errori a livello di area

Le risorse di Griglia di eventi vengono distribuite in una singola area. Se si verifica un errore a livello di area, le risorse di Griglia di eventi non sono disponibili.

Nelle aree di Azure abbinate Griglia di eventi offre un ripristino di emergenza geografico limitato per i metadati delle risorse di Griglia di eventi. È anche possibile progettare e creare una soluzione in più aree, che può supportare la pianificazione del ripristino di emergenza. La tabella seguente illustra il supporto dei diversi tipi di risorse di Griglia di eventi per ogni modello:

Recupero da disastri geologici

Il recupero da disastro geografico replica i metadati di Event Grid nella regione associata alla regione primaria per le risorse supportate. I dati dell'evento non vengono replicati.

Il ripristino di emergenza geografico è progettato come un ripiego gestito al meglio da Microsoft per le gravi interruzioni regionali e non è inteso per offrire tempi di ripristino rapidi o prevedibili. Il failover avviato da Microsoft viene eseguito da Microsoft in situazioni rare per il failover delle risorse di Event Grid da un'area interessata alla corrispondente area geografica associata. Microsoft si riserva il diritto di determinare quando questa opzione verrà esercitata. Questo meccanismo non implica il consenso del cliente prima del failover del traffico.

Facoltativamente, è possibile disabilitare il ripristino di emergenza geografico e usare la propria soluzione personalizzata in più aree che soddisfi i requisiti per la selezione dell'area, il tempo di failover e altro ancora. Quando si disabilita il ripristino di emergenza geografico, nessun dato evento viene replicato in un'altra area da Microsoft.

Questa funzionalità non è disponibile nelle aree senza un'area abbinata.

Requisiti

• Supporto per l'area: Il ripristino di emergenza geografico è disponibile solo nelle aree di Azure con un'area abbinata.

• Tipi di risorsa: Argomenti e domini personalizzati supportano il ripristino di emergenza geografico. Gli argomenti di sistema sono abilitati automaticamente per il ripristino geo-disastro. Altri tipi di risorse, ad esempio spazi dei nomi e spazi dei nomi dei partner, non sono supportati.

Cost

Non ci sono costi aggiuntivi per il ripristino geografico di emergenza.

Configurare il supporto per più aree

Nelle aree supportate, gli argomenti di sistema vengono configurati automaticamente per il ripristino di emergenza geografico. Per altri tipi di risorse di Griglia di eventi:

• Per abilitare il ripristino di emergenza geografico: Aggiornare la configurazione per l'argomento o il dominio e selezionare Cross-Geo (impostazione predefinita).

• Per disabilitare il ripristino in caso di disastro geografico: Aggiornare la configurazione per l'argomento o il dominio e selezionare Regionale.

Comportamento quando tutte le aree sono integre

Questa sezione descrive cosa aspettarsi quando una risorsa di Griglia di eventi è configurata per il ripristino di emergenza geografico e tutte le aree sono operative.

• Operazione tra aree: Tutto il traffico viene instradato all'area primaria.

• Replica dei dati tra aree: I metadati vengono replicati in modo sincrono nell'area abbinata. I dati dell'evento non vengono replicati.

Comportamento durante un errore di area

Questa sezione descrive cosa aspettarsi quando una risorsa di Griglia di eventi è configurata per il ripristino di emergenza geografico ed è presente un'interruzione nell'area primaria.

• Rilevamento e risposta: Microsoft rileva gli errori dell'area e determina se e quando avviare il failover.

• Notifica: Microsoft non invia automaticamente una notifica quando un'area è inattiva. È tuttavia possibile usare Integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi gli eventuali errori dell'area e configurare gli avvisi di integrità dei servizi per notificare eventuali problemi.

• Richieste attive: Le richieste attive all'area primaria vengono terminate. Le applicazioni client devono ritentare queste richieste al termine del failover.

• Perdita di dati prevista:

  • Metadati: Griglia di eventi mantiene i metadati durante il failover. Poiché tutte le modifiche ai metadati vengono replicate in modo sincrono, non è prevista alcuna perdita di metadati.

  • Dati dell'evento: I dati degli eventi nell'area primaria non sono disponibili e potrebbero essere persi se l'area non è recuperabile.

    Dopo che si verifica un failover, i nuovi dati vengono elaborati dall'area abbinata. Gli eventi non elaborati vengono inviati dall'area primaria non appena viene attenuata l'interruzione. Se il ripristino dell'area primaria richiede più tempo rispetto al valore time-to-live impostato sugli eventi, i dati nell'area primaria potrebbero essere eliminati. Per ridurre la perdita di dati, è consigliabile configurare una destinazione di messaggi non recapitabili per una sottoscrizione di eventi.

    Se l'area interessata viene persa e non è recuperabile, si verifica una perdita di dati. Nello scenario migliore, il consumer è al passo con la frequenza di pubblicazione e solo pochi secondi di dati vengono persi. Lo scenario peggiore sarebbe quando il consumer non elabora attivamente gli eventi e con un tempo massimo di durata di 24 ore, la perdita di dati può essere fino a 24 ore.

    Annotazioni

    Event Grid non può garantire la conservazione dei dati durante un'interruzione della regione. Se è necessaria una conservazione garantita, è necessario progettare l'applicazione per archiviare gli eventi in modo permanente in un altro archivio dati.

• Tempo di inattività previsto: La quantità di tempo di inattività dipende dalla gravità dell'interruzione e dal tempo necessario per microsoft per valutare e avviare il failover. Il tempo di inattività dovrebbe essere di almeno un'ora e forse più lungo.

  Dopo l'avvio del failover, Event Grid inizia ad accettare il traffico per argomenti e sottoscrizioni entro cinque minuti, incluse le operazioni di creazione, aggiornamento ed eliminazione.

• Ridistribuzione: Al termine del failover, il traffico viene indirizzato automaticamente all'area secondaria.

Ripristino della regione

Microsoft gestisce il ripristino dell'area e il processo di ripristino dipende dallo scenario di interruzione specifico. In generale, il failover viene in genere considerato come un'operazione unidirezionale.

Testare gli errori dell'area

Griglia di eventi di Azure gestisce il routing del traffico, il failover e il ripristino per il ripristino di emergenza geografico. Non è necessario avviare nulla. Poiché questa funzionalità è completamente gestita, non è necessario convalidare i processi di errore dell'area.

Soluzioni personalizzate in più aree per la resilienza

È possibile disabilitare o non basarsi sul failover avviato da Microsoft per uno di questi motivi:

• È necessario replicare i dati degli eventi tra aree e non solo i metadati.
• È necessario garantire un tempo o un approccio di failover specifico. Il failover avviato da Microsoft viene eseguito su base ottimale.
• L'area non è associata a un'altra area di Azure.
• L'area abbinata della tua regione non soddisfa i requisiti di residenza dei dati dell'organizzazione.

Per livelli più elevati di controllo e prevedibilità, è possibile implementare architetture personalizzate in più aree. Questo approccio prevede la distribuzione di risorse di Griglia di eventi separate in più aree e la gestione del failover a livello di applicazione. Quando si usa questo modello, si è responsabili della distribuzione, della configurazione e della sincronizzazione delle risorse tra aree.

Quando si progetta una soluzione in più aree, tenere presenti i fattori seguenti:

• Replica: È consigliabile implementare un processo personalizzato per replicare le risorse di Griglia di eventi e la relativa configurazione tra aree primarie e secondarie. Ricordarsi di replicare le identità client, i certificati CA, i gruppi client, gli spazi di argomenti e i vincoli di autorizzazioni, se applicabile. È possibile decidere se implementare la replica manuale o automatizzata.

• Approcci di failover: È possibile scegliere tra una configurazione attiva-attiva o attiva-passiva:

  • È possibile ottenere soluzioni active-active replicando i metadati e bilanciando il carico tra gli spazi dei nomi.
  • È possibile ottenere soluzioni attive-passive replicando i metadati per mantenere pronto lo spazio dei nomi secondario in modo che, quando lo spazio dei nomi primario non è disponibile, il traffico può essere indirizzato allo spazio dei nomi secondario.

• Monitoraggio dell'integrità: È possibile usare le API di integrità predefinite fornite da Griglia di eventi per monitorare l'integrità degli argomenti.

  Le applicazioni client devono rilevare gli errori di un'area e instradare gli eventi a un'altra area appropriata.

  In alternativa, è possibile implementare un servizio concierge che indirizza i client agli endpoint primari o secondari per i loro argomenti o namespace, effettuando controlli di integrità su questi endpoint. Il servizio concierge può essere un'applicazione Web con replica geografica e raggiungibile usando tecniche di reindirizzamento DNS o servizi come Gestione traffico di Azure.

Per altre informazioni su un approccio, incluso il codice di esempio, vedere Implementazione del failover lato client in Griglia di eventi di Azure.

Backup e ripristino

Event Grid è principalmente un servizio di routing eventi e non dispone di funzionalità di backup o ripristino native.

Se è necessario implementare funzionalità di backup o se sono necessarie esigenze di conservazione a lungo termine, è consigliabile eseguire l'archiviazione nell'applicazione. A tale scopo, è necessario compilare la logica per instradare o copiare gli eventi in un archivio durevole, ad esempio Archiviazione BLOB di Azure, in parallelo con il percorso di recapito primario. Se i sistemi downstream non sono disponibili, l'applicazione può usare l'archivio per riprodurre gli eventi.

Resilienza alla manutenzione del servizio

Microsoft applica regolarmente gli aggiornamenti del servizio ed esegue altre operazioni di manutenzione. La piattaforma Azure gestisce automaticamente queste attività, assicurando che la manutenzione sia senza interruzioni e trasparente per l'utente. Non sono previsti tempi di inattività durante gli eventi di manutenzione, a meno che non sia stata comunicata tramite manutenzione pianificata di Azure Service Health.

Contratto di servizio

Il contratto di servizio per i servizi di Azure descrive la disponibilità prevista di ogni servizio e le condizioni che la soluzione deve soddisfare per raggiungere tale aspettativa di disponibilità. Per altre informazioni, vedere SLA per servizi online.

Il contratto di servizio per la disponibilità di Griglia di eventi copre la pubblicazione di eventi.

Contenuti correlati

• Affidabilità in Azure
• Linee guida di Azure Well-Architected Framework per Griglia di eventi di Azure
• Documentazione di Griglia di eventi di Azure