Hub eventi di Azure - Ripristino di emergenza geografico
Questo articolo descrive la funzionalità di ripristino di emergenza geografico che replica i metadati ed è disponibile a livello generale. Non descrive la funzionalità di replica geografica in anteprima pubblica, che replica sia i dati che i metadati. Per altre informazioni, vedere Replica geografica.
Il modello di cluster sempre attivo di Hub eventi di Azure con supporto delle zone di disponibilità fornisce resilienza nei confronti di interruzioni di hardware e data center. Tuttavia, se a causa di un'emergenza un'intera area e tutte le zone non sono disponibili, è possibile usare il ripristino di emergenza geografico per ripristinare il carico di lavoro e la configurazione dell'applicazione. Il ripristino di emergenza geografico garantisce che tutta la 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, se associati.
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. Con il ripristino di emergenza geografico, è possibile avviare lo spostamento di un failover una sola volta dallo spazio dei nomi primario allo spazio dei nomi secondario in qualsiasi momento. Lo spostamento del failover punta il nome alias scelto per lo spazio dei nomi allo spazio dei nomi secondario. Dopo lo spostamento, l'associazione viene quindi rimossa. 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.
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 i livelli 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 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 |
Importante
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.
Nota
La funzionalità di ripristino di emergenza geografico non supporta un failover automatico.
Attrezzaggio
È 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.
Creare lo spazio dei nomi primario.
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.
Nel portale di Azure, passare allo spazio dei nomi primario.
Selezionare Ripristino geografico nel menu di sinistra, quindi Avvia associazione nella barra degli strumenti.
Alla pagina Avvia associazione, seguire questi passaggi:
- Selezionare uno spazio dei nomi secondario o crearne uno in un'area diversa. In questo esempio, viene selezionato uno spazio dei nomi esistente.
- Per Alias, immettere un alias per l'associazione del ripristino di emergenza geografico.
- Quindi, selezionare Crea.
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.
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.
Nella pagina Panoramica è possibile eseguire le azioni seguenti:
Interrompere l'associazione tra gli spazi dei nomi primario e secondario. Selezionare Interrompi associazione nella barra degli strumenti.
Effettuare manualmente il failover allo spazio dei nomi secondario. Selezionare Failover nella barra degli strumenti.
Avviso
Il failover attiva lo spazio dei nomi secondario e rimuove 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 e 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:
- È 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.
- 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.
Failover manuale
Questa sezione mostra come effettuare manualmente il failover tramite portale di Azure, interfaccia della riga di comando, PowerShell, C#, ecc.
Nel portale di Azure, passare allo spazio dei nomi primario.
Ripristino Ripristino geografico nel menu di sinistra.
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:
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.
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.
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.
È necessario provare a effettuare il failover di un'infrastruttura distribuita complessa almeno una volta.
La sincronizzazione delle entità può richiedere tempo, circa un minuto per 50-100 entità.
Alcuni aspetti del piano di gestione per lo spazio dei nomi secondario diventano di sola lettura mentre è attiva l'associazione del ripristino geografico.
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.
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.
Configurazione consigliata
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
, VNET-2
e questi 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 daVNET-1
eVNET-2
- In
EventHubs-Namespace2-Secondary
, creare due endpoint privati che usano le stesse subnet daVNET-1
eVNET-2
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à VNET-1
ma passerà a VNET-2
. Poiché entrambi gli endpoint privati sono configurati sia in VNET-1
che in 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.
Contenuto correlato
Rivedere gli esempi seguenti o la documentazione di riferimento.