Affidabilità nello spazio dei nomi Griglia di eventi e Griglia di eventi di Azure

Questo articolo contiene informazioni dettagliate su Griglia di eventi e sulla resilienza a livello di area del relativo spazio dei nomi con zone di disponibilità e ripristino di emergenza tra aree e continuità aziendale.

Per una panoramica dell’architettura sull'affidabilità in Azure, vedere Affidabilità di Azure.

Supporto della zona di disponibilità

Le zone di disponibilità di Azure sono costituite da almeno tre gruppi fisicamente separati di data center all'interno di ogni area di Azure. I data center all'interno di ogni zona sono dotati di alimentazione, raffreddamento e infrastruttura di rete indipendenti. Le zone di disponibilità sono progettate in modo che, in caso di errore in una zona locale, i servizi regionali, la capacità e la disponibilità elevata della zona interessata siano supportati dalle altre due zone.

Gli errori possono essere di tipo hardware o software oppure correlati a eventi come terremoti, inondazioni e incendi. La tolleranza agli errori viene conseguita mediante la ridondanza e l'isolamento logico dei servizi di Azure. Per informazioni più dettagliate sulle zone di disponibilità in Azure, vedere Aree e zone di disponibilità.

I servizi abilitati per le zone di disponibilità sono progettati per fornire il livello adeguato di affidabilità e flessibilità. Tali servizi possono essere configurati in due modi. Possono essere con ridondanza della zona, che prevede la replica automatica tra le zone, o a zona, con istanze aggiunte in una zona specifica. È anche possibile combinare questi approcci. Per altre informazioni sulle architetture a zona e con ridondanza della zona, vedere Raccomandazioni per l'uso delle zone e delle aree di disponibilità.

Le definizioni delle risorse di Griglia di eventi per argomenti, argomenti di sistema, domini e sottoscrizioni di eventi e dati degli eventi vengono replicate automaticamente in tre zone di disponibilità. Quando si verifica un errore a livello di area in una delle zone di disponibilità, le risorse di Griglia di eventi effettuano il failover automatico in un'altra zona di disponibilità senza intervento umano. Attualmente non è possibile controllare (abilitare o disabilitare) questa funzionalità. Quando un'area esistente inizia a supportare le zone di disponibilità, viene eseguito automaticamente il failover delle risorse di Griglia di eventi esistenti per sfruttare questa funzionalità. Non è richiesto alcun intervento da parte del cliente.

Spazio dei nomi di Griglia di eventi di Azure ottiene anche la disponibilità elevata all'interno dell'area usando le zone di disponibilità.

Prerequisiti

Per il supporto della zona di disponibilità, le risorse di Griglia di eventi devono trovarsi in un'area che supporta le zone di disponibilità. Per esaminare le aree che supportano le zone di disponibilità, vedere l'elenco delle aree supportate.

Prezzi

Poiché Griglia di eventi supporta automaticamente le zone di disponibilità nelle aree apposite, non vengono apportate modifiche al prezzo.

Creare una risorsa con zone di disponibilità abilitate

Poiché Griglia di eventi supporta automaticamente le zone di disponibilità nelle aree apposite, non è richiesta una configurazione.

Eseguire la migrazione al supporto della zona di disponibilità

Se si rilocano le risorse di Griglia di eventi in un'area che supporta le zone di disponibilità, si riceve automaticamente il supporto della zona di disponibilità. Per informazioni su come spostare le risorse in un'altra area che supporta le zone di disponibilità, vedere quanto segue:

• Rilocare gli argomenti di sistema di Griglia di eventi di Azure in un'altra area
• Rilocare gli argomenti personalizzati di Griglia di eventi di Azure in un'altra area
• Rilocare i domini di Griglia di eventi di Azure in un'altra area

Ripristino di emergenza e continuità aziendale tra aree

Il ripristino di emergenza si occupa del ripristino in caso di eventi a impatto elevato, come disastri naturali o distribuzioni non riuscite che comportano tempi di inattività e perdita di dati. Indipendentemente dalla causa, il miglior rimedio per un'emergenza è un piano di ripristino ben definito e testato e una progettazione di applicazioni che supporta attivamente tale ripristino. Prima di iniziare a pensare a un piano di ripristino di emergenza, vedere Raccomandazioni per la progettazione di una strategia di ripristino di emergenza.

Nell'ambito del ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello basato sulla responsabilità condivisa, Microsoft garantisce che l'infrastruttura di base e i servizi della piattaforma siano disponibili. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o eseguono il fallback da un'area in cui si è verificato un errore per effettuare la replica incrociata in un'altra area abilitata. Per tali servizi, l'utente ha la responsabilità di configurare un piano di ripristino di emergenza che funzioni per i propri carichi di lavoro. La maggior parte dei servizi eseguiti nelle offerte PaaS (Piattaforma distribuita come servizio) di Azure forniscono funzionalità e indicazioni per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido e sviluppare il piano di ripristino di emergenza.

Il ripristino di emergenza comporta in genere la creazione di una risorsa di backup per evitare interruzioni quando un'area diventa non integra. Durante questo processo sarà necessaria un'area primaria e secondaria delle risorse di Griglia di eventi di Azure nel carico di lavoro.

Esistono diversi modi per eseguire il ripristino da una grave perdita di funzionalità dell'applicazione. In questa sezione viene descritto l'elenco di controllo che è necessario seguire per preparare il client per il ripristino da un errore dovuto a una risorsa o a un'area non integra.

Griglia di eventi supporta sia il ripristino di emergenza geografico manuale che quello automatico (GeoDR) sul lato server. Per un maggiore controllo sul processo di failover è ancora possibile implementare la logica di ripristino di emergenza sul lato client. Per informazioni dettagliate sul ripristino di emergenza geografico automatico, vedere Ripristino di emergenza geografico sul lato server in Griglia di eventi di Azure. Per informazioni dettagliate su come implementare il ripristino di emergenza sul lato client, vedereImplementazione del failover lato client in Griglia di eventi di Azure.

La tabella seguente illustra il supporto per il failover lato client e il ripristino di emergenza geografico in Griglia di eventi.

Spazio dei nomi di Griglia di eventi

Lo spazio dei nomi di Griglia di eventi non supporta il ripristino di emergenza tra aree. Tuttavia, è possibile ottenere disponibilità elevata tra aree tramite l'implementazione del failover lato client creando spazi dei nomi primari e secondari.

Con un'implementazione del failover lato client, è possibile:

• Implementare un processo personalizzato (manuale o automatizzato) per replicare lo spazio dei nomi, le identità client e altre configurazioni** tra cui certificati CA, gruppi client, spazi di argomenti, associazioni di autorizzazioni e routing, tra aree primarie e secondarie.

• Implementare un servizio concierge che fornisca ai client endpoint primari e secondari eseguendo un controllo di integrità sugli endpoint. Il servizio concierge può essere un'applicazione Web replicata e mantenuta raggiungibile con tecniche di reindirizzamento DNS, ad esempio con Gestione traffico di Azure.

• Ottenere una soluzione di ripristino di emergenza attivo-attivo replicando i metadati e bilanciando il carico tra gli spazi dei nomi. È possibile ottenere una soluzione di ripristino di emergenza attivo-passivo replicando i metadati per mantenere pronto lo spazio dei nomi secondario in modo che, quando lo spazio primario non fosse disponibile, il traffico potrà essere indirizzato allo spazio dei nomi secondario.

Configurare il ripristino di emergenza

Per le aree abbinate, Griglia di eventi offre la possibilità di eseguire il failover del traffico di pubblicazione nell'area abbinata per argomenti personalizzati, argomenti di sistema e domini. Dietro le quinte, Griglia di eventi sincronizza automaticamente le definizioni di risorse di argomenti, argomenti di sistema, domini e sottoscrizioni di eventi nell'area abbinata. Tuttavia, i dati degli eventi non vengono replicati nell'area abbinata. Nello stato normale, gli eventi vengono archiviati nell'area selezionata per tale risorsa. Quando si verifica un'interruzione dell'area e Microsoft avvia il failover, i nuovi eventi iniziano a passare all'area geografica associata e vengono inviati da questa posizione senza alcun intervento da parte dell'utente. Gli eventi pubblicati e accettati nell'area originale vengono inviati da questa posizione dopo l'interruzione.

È possibile scegliere tra due opzioni di failover, avviato da Microsoft e avviato dal cliente. Per informazioni dettagliate su come configurare entrambe queste impostazioni, vedere Configurare la residenza dei dati.

• Il failover avviato da Microsoft viene eseguito da Microsoft in situazioni rare per il failover sulle risorse di Griglia di eventi da un'area interessata alla corrispondente area geografica abbinata. Microsoft si riserva il diritto di determinare quando questa opzione verrà esercitata. Questo meccanismo non implica il consenso dell'utente prima che il traffico dell'utente sia sottoposto a failover.

  Abilitare questa funzionalità aggiornando la configurazione per l'argomento o il dominio. Selezionare Cross-Geo (impostazione predefinita) per abilitare il failover avviato da Microsoft.

• Il failover avviato dal cliente è definito dal piano di ripristino di emergenza personalizzato per gli argomenti e i domini di Griglia di eventi di Azure, nessun dato di alcun tipo viene replicato in un'altra area da Microsoft. Anche se questa opzione di failover richiede un impegno maggiore, consente un failover più rapido e che permette il controllo della scelta delle aree secondarie. Se si vuole implementare il ripristino di emergenza sul lato client per gli argomenti di Griglia di eventi di Azure, vedere Creare un ripristino di emergenza sul lato client per Griglia di eventi di Azure.

  Esistono alcuni motivi per cui è consigliabile disabilitare la funzionalità di failover avviata da Microsoft:

  • Il failover avviato da Microsoft viene eseguito su base ottimale.
  • Alcune coppie geografiche non soddisfano i requisiti di residenza dei dati dell'organizzazione.

  Abilitare questa funzionalità aggiornando la configurazione per l'argomento o il dominio. Selezionare Area.

  

Esperienza di failover del ripristino di emergenza

Il ripristino di emergenza viene misurato con due metriche, Recovery Point Objective (RPO) e RTO (Recovery Time Objective).

Il failover automatico di Griglia di eventi include RPO e RTO diversi per i metadati (argomenti, domini, sottoscrizioni di eventi) e dati (eventi). Se sono necessarie specifiche diverse da quelle seguenti, è comunque possibile implementare il proprio failover lato client usando le API di integrità dell'argomento.

Obiettivo del punto di ripristino (RPO)

• RPO dei metadati: zero minuti. Per le risorse applicabili, quando una risorsa viene creata/aggiornata/eliminata, la definizione della risorsa viene replicata in modo sincrono nella coppia geografica. Quando si verifica un failover, non vengono persi metadati.

• RPO dati: quando si verifica un failover, i nuovi dati vengono elaborati dall'area abbinata. Non appena l'interruzione viene attenuata per l'area interessata, gli eventi non elaborati vengono inviati da questa posizione. Se il ripristino dell'area ha richiesto un tempo più lungo rispetto al set di valori time-to-live per gli eventi, i dati potrebbero essere eliminati. Per attenuare questa 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 sottoscrittore è in linea con la frequenza di pubblicazione e solo pochi secondi di dati vengono persi. Lo scenario peggiore si ha quando il sottoscrittore non elabora attivamente gli eventi: con un TTL massimo di 24 ore, la perdita di dati può arrivare proprio a 24 ore.

Obiettivo del tempo di ripristino (RTO)

• RTO metadati: il processo decisionale del failover si basa su fattori come la capacità disponibile nell'area abbinata e può durare 60 minuti o più. Dopo l'avvio del failover, entro 5 minuti Griglia di eventi inizia ad accettare chiamate di creazione/aggiornamento/eliminazione per argomenti e sottoscrizioni.

• RTO dati: uguale alle informazioni precedenti.

Passaggi successivi

• Creare un ripristino di emergenza lato client personalizzato per gli argomenti di Griglia di eventi di Azure.

• Affidabilità in Azure