Hub eventi di Azure - Ripristino di emergenza geografico

  • Articolo

La resilienza nei confronti di interruzioni disastrose delle risorse di elaborazione dati è un requisito per molte aziende e in alcuni casi è persino richiesta dalle normative di settore.

Hub eventi di Azure estende già il rischio di errori catastrofici di singole macchine o persino rack completi in cluster che comprendono più domini con errori in un data center. Implementa un rilevamento trasparente degli errori e meccanismi di failover, in modo che il servizio possa continuare a operare ai livelli di servizio garantiti e in genere senza interruzioni rilevanti in presenza di tali errori. Se crei uno spazio dei nomi di Hub eventi con zone di disponibilità abilitate, riduci il rischio di ulteriori interruzioni e abiliti una disponibilità elevata. Con le zone di disponibilità, il rischio di interruzione viene ulteriormente esteso in tre strutture fisicamente separate, in modo che il servizio disponga delle riserve di capacità sufficienti per gestire all'istante la perdita catastrofica completa di tutta la struttura.

Il modello in cluster sempre attivo di Hub eventi di Azure con supporto per le zone di disponibilità fornisce resilienza nei confronti di errori hardware gravi e perdite catastrofiche di strutture di data center intere. Potrebbero comunque verificarsi situazioni gravi con distruzione fisica diffusa, che persino queste misure potrebbero non riuscire a contrastare.

La funzionalità di ripristino di emergenza geografico di Hub eventi di Azure è progettata per semplificare il ripristino da un disastro di questo calibro e abbandonare definitivamente un'area di Azure con errori senza dover cambiare le configurazioni delle applicazioni. L'abbandono di un'area di Azure in genere comporta diversi servizi e questa funzionalità punta prevalentemente a preservare l'integrità della configurazione composita delle applicazioni.

La funzionalità di ripristino di emergenza geografico garantisce che tutta la configurazione di uno spazio dei nomi (Hub eventi, gruppi di consumer e impostazioni) viene replicata continuamente da uno spazio dei nomi primario a uno spazio dei nomi secondario, se associati, e consente di avviare uno spostamento di failover una tantum da quello primario a quello secondario in qualsiasi momento. Lo spostamento di failover punterà di nuovo il nome alias prescelto per lo spazio dei nomi allo spazio dei nomi secondario e quindi interromperà l'associazione. Una volta avviato, il failover è pressoché istantaneo.

Importante

  • La funzionalità abilita la continuità istantanea delle operazioni con la stessa configurazione, ma non replica i dati dell'evento. A meno che il disastro abbia causato la perdita di tutte le zone, i dati dell'evento preservati nell'hub eventi primario dopo il failover saranno ripristinabili e, una volta ripristinato l'accesso, sarà possibile recuperare gli eventi storici da esso. Per risolvere interruzioni e disastri tramite la replica dei dati dell'evento e la gestione degli spazi dei nomi corrispondenti in configurazioni attive, non fare affidamento su questo set di funzionalità di ripristino di emergenza geografico, ma seguire le linee guida sulla replica.
  • Le assegnazioni del controllo degli accessi in base al ruolo di Microsoft Entra a entità nello spazio dei nomi primario non vengono replicate nello spazio dei nomi secondario. Creare manualmente assegnazioni di ruolo nello spazio dei nomi secondario per accedervi.

Emergenze e interruzioni

È importante notare la distinzione tra "interruzioni" ed "emergenze". Un'interruzione è l'indisponibilità temporanea di Hub eventi di Azure e può interessare alcuni componenti del servizio, ad esempio un archivio di messaggistica, oppure l'intero data center. Dopo la risoluzione del problema, tuttavia, Hub eventi torna di nuovo disponibile. Un'interruzione non determina in genere la perdita di messaggi o di altri dati. Un'interruzione può essere provocata ad esempio da un'interruzione dell'alimentazione nel data center. Alcune interruzioni sono solo brevi perdite di connessione dovute a problemi di rete o temporanei.

Il termine emergenza indica la perdita permanente o a lungo termine di un cluster di Hub eventi, un'area di Azure o un data center. L'area o il data center potrebbe o meno tornare di nuovo disponibile oppure potrebbe rimanere inattivo per ore o giorni. Un'emergenza può essere causata, ad esempio, da un incendio, un'inondazione o un terremoto. Una situazione di emergenza che diventa permanente potrebbe causare la perdita di alcuni messaggi, eventi o altri dati. Tuttavia, nella maggior parte dei casi non dovrebbe esserci perdita di dati e i messaggi possono essere ripristinati dopo aver eseguito il backup del data center.

La funzionalità di ripristino di emergenza geografico di Hub eventi di Azure è una soluzione di ripristino di emergenza. I concetti e il flusso di lavoro illustrati in questo articolo sono applicabili a scenari di emergenza, non a interruzioni temporanee. Per una descrizione dettagliata del ripristino di emergenza in Microsoft Azure, vedere questo articolo.

Concetti e terminologia di base

La funzionalità di ripristino di emergenza implementa il ripristino di emergenza dei metadati e si basa sugli spazi dei nomi primari e secondari di ripristino di emergenza.

La funzionalità di ripristino di emergenza geografico è disponibile solo per gli SKU standard, premium e dedicati. Non è necessario apportare modifiche alla stringa di connessione, perché la connessione viene effettuata tramite un alias.

In questo articolo viene usata la terminologia seguente:

  • Alias: nome per una configurazione di ripristino di emergenza impostata. L'alias fornisce una singola stringa di connessione FQDN (nome di dominio completo) stabile. Le applicazioni usano questa stringa di connessione alias per connettersi a uno spazio dei nomi.

  • Spazio dei nomi primario/secondario: spazi dei nomi corrispondenti all'alias. Lo spazio dei nomi primario è "attivo" e riceve i messaggi (può essere uno spazio dei nomi esistente o nuovo). Lo spazio dei nomi secondario è "passivo" e non riceve messaggi. I metadati vengono sincronizzati tra entrambi gli spazi dei nomi, quindi entrambi possono facilmente accettare messaggi senza modifiche al codice dell'applicazione o alla stringa di connessione. Per fare in modo che solo lo spazio dei nomi attivo riceva i messaggi, è necessario usare l'alias.

  • Metadati: entità come Hub eventi e gruppi di consumer e le relative proprietà del servizio associate allo spazio dei nomi. Solo le entità e le relative impostazioni vengono replicate automaticamente. I messaggi e gli eventi non vengono replicati.

  • Failover: processo di attivazione dello spazio dei nomi secondario.

Coppie di spazi dei nomi supportate

Sono supportate le combinazioni seguenti di spazi dei nomi primari e secondari:

Livello spazio dei nomi primario Livello spazio dei nomi secondario consentito
Standard Standard, Dedicato
Premium Premium
Dedicato Dedicato

Nota

Non è possibile associare spazi dei nomi che si trovano nello stesso cluster dedicato. È possibile associare spazi dei nomi che si trovano in cluster separati.

Configurazione e flusso del failover

La sezione seguente è una panoramica del processo di failover e illustra come configurare il failover iniziale.

Image showing the overview of failover process

Impostazione

È prima di tutto necessario creare uno spazio dei nomi primario o usarne uno esistente e creare un nuovo spazio dei nomi secondario, quindi associare i due spazi dei nomi. L'associazione fornisce un alias che può essere usato per la connessione. Poiché si usa un alias, non è necessario modificare le stringhe di connessione. È possibile aggiungere solo nuovi spazi dei nomi all'associazione di failover.

  1. Creare lo spazio dei nomi primario.

  2. Creare lo spazio dei nomi secondario in un'area diversa. Questo passaggio è facoltativo. È possibile creare lo spazio dei nomi secondario durante la creazione dell'associazione nel passaggio successivo.

  3. Nel portale di Azure, passare allo spazio dei nomi primario.

  4. Selezionare Ripristino geografico nel menu di sinistra, quindi Avvia associazione nella barra degli strumenti.

    Initiate pairing from the primary namespace

  5. Alla pagina Avvia associazione, seguire questi passaggi:

    1. Selezionare uno spazio dei nomi secondario o crearne uno in un'area diversa. In questo esempio, viene selezionato uno spazio dei nomi esistente.
    2. Per Alias, immettere un alias per l'associazione del ripristino di emergenza geografico.
    3. Quindi, selezionare Crea.

    Select the secondary namespace

  6. Si dovrebbe vedere la pagina Alias ripristino di emergenza geografico. È possibile passare a questa pagina anche dallo spazio dei nomi primario selezionando Ripristino geografico nel menu di sinistra.

    Geo-DR alias page

  7. Alla pagina Alias ripristino di emergenza geografico, selezionare Criteri di accesso condiviso nel menu di sinistra per accedere alla stringa di connessione primaria per l'alias. Usare questa stringa di connessione al posto della stringa di connessione diretta allo spazio dei nomi primario/secondario.

  8. Nella pagina Panoramica è possibile eseguire le azioni seguenti:

    1. Interrompere l'associazione tra gli spazi dei nomi primario e secondario. Selezionare Interrompi associazione nella barra degli strumenti.

    2. Effettuare manualmente il failover allo spazio dei nomi secondario. Selezionare Failover nella barra degli strumenti.

      Avviso

      Il failover attiverà lo spazio dei nomi secondario e rimuoverà lo spazio dei nomi primario dall'associazione di ripristino di emergenza geografico. Creare un altro spazio dei nomi per predisporre una nuova associazione di ripristino di emergenza geografico.

Infine, è necessario aggiungere funzionalità di monitoraggio per rilevare i casi in cui è necessario un failover. Nella maggior parte dei casi, il servizio fa parte di un ecosistema di grandi dimensioni, quindi i failover automatici sono raramente possibili, in quanto spesso i failover devono essere eseguiti in modo sincronizzato con il sottosistema o l'infrastruttura rimanente.

Esempio

In un esempio di questo scenario, si consideri una soluzione POS che genera messaggi o eventi. Hub eventi passa gli eventi a una soluzione di mapping o riformattazione, che quindi inoltra i dati mappati a un altro sistema per un'ulteriore elaborazione. A questo punto, tutti questi sistemi possono essere ospitati nella stessa area di Azure. La decisione relativa a quando effettuare il failover o quale parte del sistema dipenda dal flusso di dati nell'infrastruttura.

È possibile automatizzare il failover con sistemi di monitoraggio o con soluzioni di monitoraggio personalizzate. Tale automazione, tuttavia, richiede pianificazione e lavoro aggiuntivi che esulano dall'ambito di questo articolo.

Flusso del failover

Se si avvia il failover, sono necessari due passaggi:

  1. È necessario poter eseguire di nuovo il failover nel caso in cui si verifichi un'altra interruzione. Configurare quindi un altro spazio dei nomi passivo e aggiornare l'associazione.

  2. Eseguire il pull dei messaggi dallo spazio dei nomi primario precedente quando è di nuovo disponibile. Successivamente, usare tale spazio dei nomi per la messaggistica regolare di fuori della configurazione del ripristino geografico oppure eliminare lo spazio dei nomi primario precedente.

Nota

È supportata solo la semantica di inoltro in caso di errore. In questo scenario, si esegue il failover e quindi si esegue di nuovo l'associazione con un nuovo spazio dei nomi. Il failback, ad esempio in un cluster SQL, non è supportato.

Image showing the failover flow

Failover manuale

Questa sezione mostra come effettuare manualmente il failover tramite portale di Azure, interfaccia della riga di comando, PowerShell, C#, ecc.

  1. Nel portale di Azure, passare allo spazio dei nomi primario.

  2. Ripristino Ripristino geografico nel menu di sinistra.

  3. Effettuare manualmente il failover allo spazio dei nomi secondario. Selezionare Failover nella barra degli strumenti.

    Avviso

    Il failover attiverà lo spazio dei nomi secondario e rimuoverà lo spazio dei nomi primario dall'associazione di ripristino di emergenza geografico. Creare un altro spazio dei nomi per predisporre una nuova associazione di ripristino di emergenza geografico.

Gestione

Se si commette un errore, ad esempio associando le aree non corrette durante la configurazione iniziale, è possibile interrompere l'associazione dei due spazi dei nomi in qualsiasi momento. Per usare gli spazi dei nomi associati come normali spazi dei nomi, eliminare l'alias.

Considerazioni

Tenere presente quanto segue:

  1. Da progettazione, il ripristino di emergenza geografico di Hub eventi non replica i dati e non è quindi possibile riutilizzare il valore di offset precedente dell'hub eventi primario per l'hub eventi secondario. È consigliabile riavviare il ricevitore di eventi con uno dei metodi seguenti:

    • EventPosition.FromStart() - Se si vogliono leggere tutti i dati nell'hub eventi secondario.
    • EventPosition.FromEnd() - Se si vogliono leggere tutti i nuovi dati dal momento della connessione all'hub eventi secondario.
    • EventPosition.FromEnqueuedTime(dateTime) - Se si vogliono leggere tutti i dati ricevuti nell'hub eventi secondario a partire da una data e da un'ora specificate.

  2. Quando si pianifica il failover, è consigliabile considerare anche il fattore tempo. Ad esempio, se si perde la connettività per più di 15-20 minuti, è possibile decidere di avviare il failover.

  3. Il fatto che non vengano replicati dati significa che le sessioni attive non vengono replicate. Il rilevamento dei duplicati e i messaggi pianificati potrebbero inoltre non funzionare. Le nuove sessioni, i messaggi pianificati e i nuovi duplicati funzioneranno.

  4. È necessario provare a effettuare il failover di un'infrastruttura distribuita complessa almeno una volta.

  5. La sincronizzazione delle entità può richiedere tempo, circa un minuto per 50-100 entità.

  6. Alcuni aspetti del piano di gestione per lo spazio dei nomi secondario diventano di sola lettura mentre è attiva l'associazione del ripristino geografico.

  7. Il piano dati dello spazio dei nomi secondario sarà di sola lettura mentre l'associazione di ripristino geografica è attiva. Il piano dati dello spazio dei nomi secondario accetterà richieste GET per abilitare la convalida della connettività del client e dei controlli di accesso.

Zone di disponibilità

Hub eventi supporta le zone di disponibilità, fornendo posizioni con isolamento degli errori all'interno di un'area di Azure. Il supporto per le zone di disponibilità è disponibile solo nelle aree di Azure con zone di disponibilità. Sia i metadati sia i dati (eventi) vengono replicati nei data center della zona di disponibilità.

Quando si crea uno spazio dei nomi, si vedrà il messaggio evidenziato seguente alla selezione di un'area con zone di disponibilità.

Image showing the Create Namespace page with region that has availability zones

Nota

Quando si usa il portale di Azure, la ridondanza della zona tramite supporto per le zone di disponibilità viene abilitata automaticamente. Non è possibile disabilitarla. È possibile usare il comando dell'interfaccia della riga di comando di Azure az eventhubs namespace con --zone-redundant=false o usare il comando PowerShell New-AzEventHubNamespace con -ZoneRedundant=false per creare uno spazio dei nomi con ridondanza della zona disabilitata.

Endpoint privati

Questa sezione presenta altre considerazioni sull'uso del ripristino di emergenza geografico con spazi dei nomi che usano endpoint privati. Per informazioni generali sull'uso di endpoint privati con Hub eventi, vedere Configurare gli endpoint privati.

Nuove associazioni

Se si tenta di creare un'associazione tra uno spazio dei nomi primario con un endpoint privato e uno spazio dei nomi secondario senza un endpoint privato, l'associazione ha esito negativo. L'associazione avrà esito positivo solo se entrambi gli spazi dei nomi, primario e secondario, hanno endpoint privati. È consigliabile usare le stesse configurazioni per gli spazi dei nomi primario e secondario e per le reti virtuali in cui sono stati creati gli endpoint privati.

Nota

Quando si tenta di associare lo spazio dei nomi primario con un endpoint privato e uno spazio dei nomi secondario, il processo di convalida controlla solo se esiste un endpoint privato nello spazio dei nomi secondario. Non controlla se l'endpoint funziona o se funzionerà dopo il failover. È responsabilità dell'utente assicurarsi che lo spazio dei nomi secondario con endpoint privato funzioni come previsto dopo il failover.

Per verificare che le configurazioni degli endpoint privati siano uguali nello spazio dei nomi primario e secondario, inviare una richiesta di lettura (ad esempio Get Event Hub) allo spazio dei nomi secondario dall'esterno della rete virtuale e verificare di ricevere un messaggio di errore dal servizio.

Associazioni esistenti

Se l'associazione tra uno spazio dei nomi primario e uno secondario esiste già, la creazione di endpoint privati nello spazio dei nomi primario ha esito negativo. Per risolvere il problema, creare prima un endpoint privato nello spazio dei nomi secondario e quindi crearne uno per lo spazio dei nomi primario.

Nota

Mentre l'accesso allo spazio dei nomi secondario è consentito in sola lettura, è possibile eseguire aggiornamenti nelle configurazioni degli endpoint privati.

Quando si crea una configurazione di ripristino di emergenza per l'applicazione e gli spazi dei nomi di Hub eventi, è necessario creare endpoint privati per entrambi gli spazi dei nomi, primario e secondario, di Hub eventi nelle reti virtuali che ospitano entrambe le istanze, primaria e secondaria, dell'applicazione.

Immaginiamo di disporre di due reti virtuali: VNET-1, VNET-2 e due spazi dei nomi, primario e secondario: EventHubs-Namespace1-Primary, EventHubs-Namespace2-Secondary. È necessario eseguire la procedura seguente:

  • In EventHubs-Namespace1-Primary creare due endpoint privati che usano subnet da VNET-1 e VNET-2
  • In EventHubs-Namespace2-Secondary creare due endpoint privati che usano le stesse subnet da VNET-1 e VNET-2

Private endpoints and virtual networks

Il vantaggio di questo approccio è che il failover può verificarsi a livello di applicazione indipendentemente dallo spazio dei nomi di Hub eventi. Si considerino gli scenari seguenti:

Failover solo applicazione: qui, l'applicazione non esisterà in VNET-1 ma passerà a VNET-2. Poiché entrambi gli endpoint privati sono configurati sia in VNET-1 che VNET-2 per entrambi gli spazi dei nomi primario e secondario, l'applicazione funzionerà.

Failover solo spazio dei nomi Hub eventi: anche in questo caso, poiché entrambi gli endpoint privati sono configurati in entrambe le reti virtuali per entrambi gli spazi dei nomi primario e secondario, l'applicazione funzionerà.

Nota

Per materiale sussidiario sul ripristino di emergenza geografico di una rete virtuale, vedere Rete virtuale - Continuità aziendale.

Controllo degli accessi in base al ruolo

Le assegnazioni del controllo degli accessi in base al ruolo di Microsoft Entra a entità nello spazio dei nomi primario non vengono replicate nello spazio dei nomi secondario. Creare manualmente assegnazioni di ruolo nello spazio dei nomi secondario per accedervi.

Passaggi successivi

Rivedere gli esempi seguenti o la documentazione di riferimento.