Hub eventi di Azure - Ripristino di emergenza geografico

La resilienza contro le interruzioni disastrose delle risorse di elaborazione dei dati è un requisito per molte aziende e in alcuni casi anche richiesto dalle normative del settore.

Hub eventi di Azure già distribuisce il rischio di errori irreversibili di singoli computer o anche di rack completi tra cluster che si estendono su più domini di errore all'interno di un data center e implementa meccanismi di rilevamento e failover trasparenti in modo che il servizio continuerà a funzionare all'interno dei livelli di servizio assicurati e in genere senza interruzioni evidenti in caso di errori di questo tipo. Se uno spazio dei nomi di Hub eventi è stato creato con l'opzione abilitata per le zone di disponibilità, il rischio di interruzione è ulteriormente distribuito tra tre strutture separate fisicamente e il servizio ha riserve di capacità sufficienti per affrontare immediatamente la perdita completa e irreversibile dell'intera struttura.

Il modello di cluster Hub eventi di Azure attivo con supporto della zona di disponibilità offre resilienza contro gravi errori hardware e anche una perdita irreversibile di intere strutture del data center. Tuttavia, potrebbero esserci situazioni gravi con distruzione fisica diffusa che anche tali misure non possono difendere sufficientemente contro.

La funzionalità di ripristino di emergenza geografico di Hub eventi è progettata per semplificare il ripristino da un'emergenza di questa grandezza e abbandonare un'area di Azure non riuscita correttamente e senza dover modificare le configurazioni dell'applicazione. L'abbandono di un'area di Azure prevede in genere diversi servizi e questa funzionalità mira principalmente a mantenere l'integrità della configurazione dell'applicazione composita.

La funzionalità di ripristino di Geo-Disaster garantisce che l'intera configurazione di uno spazio dei nomi (Hub eventi, gruppi di consumer e impostazioni) venga replicata continuamente da uno spazio dei nomi primario a uno spazio dei nomi secondario quando abbinata e consente di avviare un failover una sola volta dal failover primario al secondario in qualsiasi momento. Lo spostamento del failover rivirerà il nome alias scelto per lo spazio dei nomi secondario e quindi interromperà l'associazione. Il failover è quasi istantaneo dopo l'avvio.

Importante

  • La funzionalità consente la continuità istantanea delle operazioni con la stessa configurazione, ma non replica i dati dell'evento. A meno che l'emergenza non ha causato la perdita di tutte le zone, i dati degli eventi conservati nell'hub eventi primario dopo il failover saranno recuperabili e gli eventi cronologici possono essere ottenuti dopo il ripristino dell'accesso. Per la replica dei dati degli eventi e degli spazi dei nomi corrispondenti nelle configurazioni attive/attive per gestire interruzioni e emergenze, non si appoggiano a questo set di funzionalità di ripristino di emergenza geografico, ma seguire le indicazioni sulla replica.
  • Azure Active Directory (Azure AD) assegnazioni di controllo degli accessi in base al ruolo (RBAC) alle 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 proteggere l'accesso a tali assegnazioni di ruolo.

Emergenze e interruzioni

È importante notare la distinzione tra "interruzioni" e "disastri". Un'interruzione è l'indisponibilità temporanea di Hub eventi di Azure e può influire su alcuni componenti del servizio, ad esempio un archivio di messaggistica o anche 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 dello spazio dei nomi primario Livello dello 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

Configurazione

È 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. Nella portale di Azure passare allo spazio dei nomi primario.

  4. Selezionare Ripristino geografico nel menu a sinistra e selezionare Avvia associazione sulla barra degli strumenti.

    Initiate pairing from the primary namespace

  5. Nella pagina Avvia associazione seguire questa procedura:

    1. Selezionare uno spazio dei nomi secondario esistente 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 di ripristino geografico.
    3. Scegliere quindi Create (Crea).

    Select the secondary namespace

  6. Verrà visualizzata la pagina Alias di ripristino di emergenza geografica . È anche possibile passare a questa pagina dallo spazio dei nomi primario selezionando Il ripristino geografico nel menu a sinistra.

    Geo-DR alias page

  7. Nella pagina Alias di ripristino di emergenza geografico selezionare Criteri di accesso condiviso nel menu a sinistra per accedere alla stringa di connessione primaria per l'alias. Usare questa stringa di connessione anziché usare direttamente la stringa di connessione allo spazio dei nomi primario/secondario.

  8. In questa pagina Panoramica è possibile eseguire le azioni seguenti:

    1. Interrompere l'associazione tra spazi dei nomi primari e secondari. Selezionare Interruzione associazione sulla barra degli strumenti.

    2. Eseguire manualmente il failover nello spazio dei nomi secondario. Selezionare Failover sulla barra degli strumenti.

      Avviso

      Il failover attiva lo spazio dei nomi secondario e rimuove lo spazio dei nomi primario dall'associazione Geo-Disaster Ripristino. Creare un altro spazio dei nomi per avere una nuova coppia 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 di quando e quale parte eseguire il failover dipende 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 illustra come eseguire manualmente il failover usando portale di Azure, l'interfaccia della riga di comando, PowerShell, C# e così via.

  1. Nella portale di Azure passare allo spazio dei nomi primario.

  2. Selezionare Ripristino geografico nel menu a sinistra.

  3. Eseguire manualmente il failover nello spazio dei nomi secondario. Selezionare Failover sulla barra degli strumenti.

    Avviso

    Il failover attiverà lo spazio dei nomi secondario e rimuoverà lo spazio dei nomi primario dall'associazione Geo-Disaster Ripristino. Creare un altro spazio dei nomi per avere una nuova coppia 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 presenti le considerazioni seguenti:

  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 nessun dato venga replicato significa che le sessioni attive correnti 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à.

Zone di disponibilità

Hub eventi supporta zone di disponibilità, fornendo posizioni isolate dall'errore all'interno di un'area di Azure. Il supporto zone di disponibilità è disponibile solo nelle aree di Azure con zone di disponibilità. I metadati e i dati (eventi) vengono replicati nei data center nella zona di disponibilità.

Quando si crea uno spazio dei nomi, viene visualizzato il messaggio evidenziato seguente quando si seleziona un'area con zone di disponibilità.

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

Nota

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

Endpoint privati

In questa sezione vengono fornite 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 le stesse negli spazi dei nomi primario e secondario, inviare una richiesta di lettura, ad esempio Get per l'hub eventi, allo spazio dei nomi secondario dall'esterno della rete virtuale e verificare che si riceva 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.

Si supponga di avere due reti virtuali, VNET-1 e VNET-2, e gli spazi dei nomi, rispettivamente primario e secondario, EventHubs-Namespace1-Primary e 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. Esaminare gli scenari seguenti:

Failover della sola applicazione: in questo caso, l'applicazione non esiste in VNET-1 ma passa 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 del solo spazio dei nomi di 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 di controllo degli accessi in base al ruolo (RBAC) di Azure Active Directory (Azure AD) alle 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 proteggere l'accesso.

Passaggi successivi

Esaminare gli esempi o la documentazione di riferimento seguenti.