Replica geografica in Hub eventi di Azure

Hub eventi di Azure replica geografica mantiene copie dei metadati dello spazio dei nomi (entità, configurazione e proprietà) e dei dati degli eventi in più aree Azure. Se l'area primaria riscontra un'interruzione, è possibile alzare di livello un'area secondaria per mantenere le applicazioni di streaming in esecuzione con una perdita minima di dati.

Le sezioni seguenti illustrano il funzionamento della replica geografica, confrontano le modalità di replica sincrona e asincrona e descrivono come gestire le aree secondarie.

Note

La funzionalità di replica geografica di Hub eventi è disponibile solo nei livelli Premium e Dedicato.

La replica geografica garantisce che i metadati e i dati di uno spazio dei nomi vengano replicati continuamente da un'area primaria all'area secondaria. Lo spazio dei nomi può essere considerato esteso a più aree, con un'area primaria e l'altra secondaria.

In qualsiasi momento, l'area secondaria può essere promossa per diventare un'area primaria. La promozione di un database secondario fa riferimento al nome di dominio completo dello spazio dei nomi (nome di dominio completo) all'area secondaria selezionata e l'area primaria precedente viene abbassata di livello a un'area secondaria.

Scenari

La replica geografica di Hub eventi può essere usata in più scenari.

Garantire la continuità aziendale e il ripristino di emergenza

La replica geografica garantisce il ripristino di emergenza e la continuità aziendale per tutti i dati di streaming nello spazio dei nomi. Replicando i dati tra aree, le organizzazioni possono proteggersi dalla perdita di dati e garantire che le applicazioni rimangano operative anche in caso di interruzione a livello di area. Questa funzionalità è fondamentale per le applicazioni cruciali che richiedono disponibilità elevata e tempi di inattività minimi.

Distribuzione globale dei dati

La replica geografica può essere usata per distribuire i dati a livello globale, consentendo alle applicazioni di accedere ai dati dall'area più vicina. Ciò riduce la latenza e migliora le prestazioni per i carichi di lavoro situati in diverse parti del mondo.

Sovranità e conformità dei dati

Le organizzazioni che operano in più paesi o aree geografiche spesso devono rispettare le leggi sulla sovranità dei dati che richiedono l'archiviazione dei dati entro limiti geografici specifici. La replica geografica consente a queste organizzazioni di replicare i dati in aree conformi alle normative locali, assicurandosi che soddisfino i requisiti legali mantenendo al tempo stesso una piattaforma dati unificata.

Migrazione e aggiornamenti

La replica geografica può essere usata anche per facilitare la migrazione dei dati, la manutenzione e gli aggiornamenti del sistema. Le organizzazioni possono eseguire la migrazione dello spazio dei nomi in modo proattivo da un'area primaria a un'area secondaria per consentire la manutenzione e gli aggiornamenti nell'area primaria.

Concetti di base

La funzionalità di replica geografica usa un modello di replica primaria secondaria per replicare metadati e dati. In qualsiasi momento, è presente una singola area primaria che serve sia i produttori che i consumer. L'area secondaria funge da area hot standby, quindi non è possibile interagire con l'area secondaria. Tuttavia, viene eseguito nella stessa configurazione dell'area primaria, il che significa che può intervenire rapidamente dopo la promozione.

Alcuni degli aspetti chiave della funzionalità di replica geografica sono:

• Modello di replica primaria-secondaria: la replica geografica è basata su un modello di replica primaria-secondaria, in cui in un determinato momento è presente un solo spazio dei nomi primario che serve produttori di eventi e consumatori di eventi.
• Hub eventi esegue una replica byte-to-byte completamente gestita dei metadati, dei dati degli eventi e degli offset dei consumer tra gli spazi dei nomi secondari con i livelli di coerenza configurati.
• Nome host di un singolo namespace: dopo aver configurato correttamente un namespace con replica geografica abilitata, usare il hostname del namespace nell'applicazione client. Il nome host si comporta in modo indipendente dalle aree primarie e secondarie configurate e punta sempre all'area primaria.
• Quando si avvia una promozione, il nome host punta all'area selezionata come nuova area primaria. La primaria precedente diventa un'area secondaria.
• Non è possibile leggere o scrivere nelle aree secondarie.
• La promozione gestita dal cliente dall'area primaria all'area secondaria fornisce la proprietà completa e la visibilità per eseguire la risoluzione dell'interruzione. Sono disponibili metriche che consentono di automatizzare la promozione dal lato cliente.
• È possibile aggiungere o rimuovere aree secondarie.
• Coerenza della replica: sono disponibili due impostazioni di coerenza della replica: sincrona e asincrona.

stato	Diagramma
Prima del failover (innalzamento di livello secondario)
Dopo il failover (innalzamento di livello secondario)

Modalità di replica

Sono disponibili due configurazioni di coerenza della replica: sincrona e asincrona. Comprendere le differenze tra queste due configurazioni perché influiscono sulle applicazioni e sulla coerenza dei dati.

La replicazione asincrona

Quando si usa la replica asincrona, il server primario esegue il commit di tutte le richieste e quindi invia un riconoscimento al client. La replica nelle aree secondarie avviene in modo asincrono. È possibile configurare la quantità massima di tempo di ritardo accettabile, ovvero l'offset sul lato servizio tra l'azione più recente nelle regioni primarie e secondarie. Il servizio replica continuamente i dati e i metadati, assicurando che il ritardo rimanga il più piccolo possibile. Se il ritardo per un database secondario attivo aumenta oltre il ritardo massimo di replica configurato dall'utente, il database primario avvia la limitazione delle richieste in ingresso.

Replica sincrona

Quando si usa la replica sincrona, il sistema invia tutte le richieste al percorso secondario. La sede secondaria effettua il commit e conferma l'operazione prima del commit della sede primaria. Di conseguenza, l'applicazione pubblica con la frequenza necessaria per pubblicare, replicare, confermare e fare il commit. Questo processo indica che l'applicazione dipende dalla disponibilità di entrambe le aree. Se l'area secondaria è in ritardo o non è disponibile, l'area primaria non conferma o registra i messaggi e limita le richieste in ingresso.

Confronto della coerenza della replicazione

Con la replica sincrona:

• La latenza è più lunga a causa delle operazioni di commit distribuito.
• La disponibilità dipende dalla disponibilità di due aree. Se un'area diventa inattiva, lo spazio dei nomi non è disponibile.

D'altra parte, la replica sincrona garantisce la massima sicurezza dei dati. Con la replica sincrona, i dati vengono confermati in tutte le aree configurate per la replica geografica, offrendo la migliore garanzia possibile sui dati.

Con la replica asincrona:

• La latenza è influenzata in minima parte.
• La perdita di un'area secondaria non influisce immediatamente sulla disponibilità. Tuttavia, la disponibilità viene influenzata dopo il raggiungimento del ritardo massimo di replica configurato.

Di conseguenza, non ha la garanzia assoluta che tutte le aree dispongano dei dati prima del commit, ad esempio la replica sincrona, e la perdita o la duplicazione dei dati potrebbe verificarsi. Tuttavia, poiché non si è più influenzati immediatamente quando una singola regione si ritarda o non è disponibile, la disponibilità dell'applicazione migliora, oltre ad avere una latenza inferiore.

Capacità	Replica sincrona	La replicazione asincrona
Latenza	Più lunga a causa delle operazioni di commit distribuite	Impatto minimo
Disponibilità	Associato alla disponibilità delle aree secondarie	La perdita di un'area secondaria non influisce immediatamente sulla disponibilità
Coerenza dei dati	Dati sempre sottoposti a commit in entrambe le aree prima del riconoscimento	Commit dei dati nell'area primaria solo prima del riconoscimento
Obiettivo punto di ripristino (RPO)	RPO 0, nessuna perdita di dati per la promozione	RPO > 0, possibile perdita di dati in caso di promozione

È possibile modificare la modalità di replica dopo la configurazione della replica geografica. È possibile passare da sincrona a asincrona o da asincrona a sincrona. Se si passa da asincrona a sincrona, l'area secondaria viene configurata come sincrona dopo che il ritardo raggiunge zero. Se si riscontra un ritardo continuo per qualsiasi motivo, potrebbe essere necessario sospendere i sistemi di pubblicazione affinché il ritardo raggiunga zero e la modalità operativa possa passare a sincrona. I motivi per abilitare la replica sincrona, anziché la replica asincrona, sono legati all'importanza dei dati, alle esigenze aziendali specifiche o ai motivi di conformità, anziché alla disponibilità dell'applicazione.

Note

Se un'area secondaria subisce un ritardo o non è più disponibile, l'applicazione non può replicare in questa area e avvia il rallentamento una volta raggiunto il ritardo di replica. Per continuare a usare lo spazio dei nomi nella posizione primaria, rimuovere l'area secondaria afflitta. Se rimuovi tutte le aree secondarie, lo spazio dei nomi prosegue senza che la replica geografica sia abilitata. È possibile aggiungere altre aree secondarie in qualsiasi momento. Le entità di primo livello, che sono hub eventi, vengono replicate in modo sincrono, indipendentemente dalla modalità di replica configurata.

Selezione dell'area secondaria

Per abilitare la funzionalità di replica geografica, usare le aree primarie e secondarie in cui è abilitata la funzionalità. La funzionalità di replica geografica dipende dalla possibilità di replicare i messaggi pubblicati dalla replica primaria alle aree secondarie. Se l'area secondaria si trova in un altro continente, questa scelta ha un impatto significativo sul ritardo della replica dall'area primaria all'area secondaria. Se si usa la replica geografica per motivi di disponibilità, scegliere le aree secondarie nello stesso continente, dove possibile. Per comprendere meglio la latenza indotta dalla distanza geografica, vedere le statistiche di latenza di round-trip della rete di Azure.

Note

La replica geografica richiede che le copie primarie e secondarie di Hub eventi siano nello stesso livello. Non è possibile configurare la replica geografica tra livelli.

Gestione della replica geografica

La funzionalità di replica geografica consente di configurare un'area secondaria verso cui replicare metadati e dati. Di conseguenza, è possibile eseguire le attività di gestione seguenti:

• Configurare la replica geografica : è possibile configurare le aree secondarie in qualsiasi spazio dei nomi nuovo o esistente in un'area abilitando la funzionalità di replica geografica.
• Configurare la coerenza della replica : impostare la replica sincrona e asincrona quando si configura la replica geografica. È anche possibile cambiare questa impostazione in un secondo momento.
• Attivazione di promozione/failover: tutte le promozioni vengono avviate dal cliente.
• Rimuovere un database secondario : se si vuole rimuovere un'area secondaria, è possibile farlo. I dati nell'area secondaria vengono eliminati.

Criteri per attivare la promozione

Ecco alcuni casi in cui potrebbe essere attivata una promozione da secondario a primario.

• Interruzione a livello di area: in caso di interruzione a livello di area che interessa l'area primaria, promuovere l'area secondaria per garantire la continuità aziendale e ridurre al minimo i tempi di inattività.

• Attività di manutenzione: durante le attività di manutenzione pianificata nell'area primaria, la promozione dell'area secondaria può contribuire a mantenere la disponibilità elevata per le applicazioni cruciali.

• Ripristino di emergenza: in caso di emergenza che interessa l'area primaria, la promozione dell'area secondaria garantisce che i dati rimangano accessibili e le applicazioni continuino a funzionare.

• Problemi di prestazioni: se l'area primaria riscontra problemi di prestazioni che influiscono sulla disponibilità o sull'affidabilità degli hub eventi, la promozione dell'area secondaria può contribuire a mitigare questi problemi.

Testate occasionalmente i meccanismi di failover per garantire che il piano di continuità aziendale sia efficace e le applicazioni possano commutare senza interruzioni alla regione secondaria quando necessario.

Monitoraggio della replica dei dati

È possibile monitorare lo stato di avanzamento del processo di replica controllando la metrica di ritardo della replica nei log delle metriche dell'applicazione.

• Abilita i log delle metriche dell'applicazione nel namespace di Event Hubs seguendo Monitoraggio Hub eventi di Azure - Hub eventi di Azure | Microsoft Learn.

• Dopo aver abilitato i log delle metriche dell'applicazione, produrre e usare i dati dallo spazio dei nomi per alcuni minuti prima di iniziare a visualizzare i log.

• Per visualizzare i log delle metriche dell'applicazione, passare alla sezione Monitoraggio della pagina Hub eventi e selezionare Log nel menu a sinistra. Usare la query seguente per trovare il ritardo di replica (in secondi) tra i namespace primario e secondario.

  AzureDiagnostics
    | where TimeGenerated > ago(1h)
    | where Category == "ApplicationMetricsLogs"
    | where ActivityName_s == "ReplicationLag
  

• La colonna count_d mostra il ritardo di replica in secondi tra l'area primaria e quella secondaria.

Pubblicazione dei dati

Le applicazioni di pubblicazione possono inviare dati agli spazi dei nomi geo-replicati tramite il nome host dello spazio dei nomi abilitato alla geo-replicazione. L'approccio di pubblicazione è identico al caso di replica non geografica. Non è necessario apportare modifiche agli SDK del piano dati o alle applicazioni client.

La pubblicazione di eventi potrebbe non essere disponibile nelle seguenti circostanze:

• Dopo aver richiesto l'innalzamento di livello di un'area secondaria, l'area primaria esistente rifiuta tutti i nuovi eventi pubblicati nell'hub eventi.
• Quando il ritardo di replica tra le aree primaria e secondaria raggiunge la durata massima del ritardo di replica, il carico di lavoro in ingresso del server di pubblicazione potrebbe essere limitato.

Le applicazioni del server di pubblicazione non possono accedere direttamente agli spazi dei nomi nelle aree secondarie.

Utilizzo dei dati

Le applicazioni possono consumare dati utilizzando il nome host di uno spazio dei nomi con la funzionalità di replica geografica abilitata. Le operazioni dei consumatori non sono supportate dal momento in cui la promozione inizia fino al termine della promozione.

Gestione di checkpoint e offset

Le applicazioni che utilizzano eventi possono mantenere la gestione degli offset allo stesso modo in cui eseguono con uno spazio dei nomi non con replica geografica. I namespace abilitati per la replica geografica non richiedono considerazioni speciali per la gestione degli offset.

Avvertimento

In caso di failover forzato(ovvero failover non normale), alcuni dati potrebbero essere persi perché non sono ancora stati copiati. Questa perdita di dati potrebbe causare variazioni negli offset di quei dati specifici tra le aree primarie e secondarie dello spazio dei nomi. Tuttavia, gli offset rimangono entro i limiti della latenza massima di replica configurata per lo spazio dei nomi. In questi casi, iniziare a consumare dall'ultimo offset di cui è stato eseguito il commit. Alcuni dati potrebbero avere un'elaborazione duplicata ed è necessario gestirli sul lato client.

Kafka

I consumer eseguono il commit degli offset direttamente in Event Hubs, e il sistema replica gli offset tra regioni. Pertanto, i consumatori possono iniziare a consumare da dove hanno lasciato nella regione primaria.

Ecco un elenco dei client Apache Kafka supportati:

Nome del client	Versione
Apache Kafka	2.1.0 o versione successiva
Librerie librdkafka e derivate	2.1.0 o versione successiva

Per altre librerie, il supporto dipende dalla versione dell'API:

Nome API	Versione supportata
API dei metadati	7 o più recenti
Fetch API	9 o superiore
ListOffset API	4 o versione successiva
OffsetFetch API	5 o versione successiva
OffsetForLeaderEpoch API	0 o versione successiva

SDK di Event Hubs e AMQP

Per il protocollo AMQP, gli utenti gestiscono i checkpoint usando un archivio checkpoint, ad esempio Azure Blob Storage o una soluzione di storage personalizzata. Se si verifica un failover, l'area secondaria deve avere l'archivio checkpoint in modo che i client possano recuperare i dati del checkpoint ed evitare la perdita di messaggi.

La versione più recente dello SDK di Event Hubs include un aggiornamento nella rappresentazione dei checkpoint per facilitare i failover. Usare le versioni più recenti degli SDK, ma sono supportate anche le versioni precedenti degli SDK seguenti.

Lingua	Nome del pacchetto
C#	Azure.Messaging.EventHubs
C#	Microsoft.Azure.EventHubs

Avvertimento

Nell'ambito dell'implementazione, il formato del checkpoint viene adattato quando si abilita la replica geografica in uno spazio dei nomi. I checkpoint successivi dopo l'associazione di replica geografica vengono scritti con un nuovo formato. Se si forza la promozione di un'area secondaria a primaria subito dopo il completamento dell'associazione di replica geografica, ma prima che venga archiviato un nuovo checkpoint (questa situazione potrebbe verificarsi in caso di promozione o failover forzato), i nuovi dati pubblicati dopo la promozione potrebbero perdersi.

In questi casi, iniziare a consumare dall'ultimo offset di cui è stato eseguito il commit. Alcuni dati potrebbero avere un'elaborazione duplicata ed è necessario gestirli sul lato client.

Eseguire l'aggiornamento alle versioni più recenti degli SDK.

Considerazioni

Tenere presente quanto segue:

• Nella pianificazione della promozione prendere in considerazione il fattore di tempo. Ad esempio, se si perde la connettività per più di 15-20 minuti, è possibile decidere di avviare la promozione.
• È consigliabile ripetere la promozione di un'infrastruttura distribuita complessa almeno una volta.

Prezzi

I prezzi variano in base al livello scelto, ma in genere ha due parametri:

• Addebito di calcolo per il cluster o il namespace.
• Costo della larghezza di banda per i dati replicati tra le regioni primarie e secondarie.

Note

Per determinare gli addebiti, vedere i dettagli dei prezzi elencati in Hub eventi di Azure. L'addebito per la replica geografica dipende dalla posizione dell'area primaria.

Cluster Hub eventi Dedicato

Quando si usa la replica geografica con cluster dedicati di Hub eventi, sono necessari almeno due cluster dedicati in aree separate. È possibile usare questi cluster per ospitare namespace diversi da quello replicato geograficamente. Si paga separatamente per questi cluster dedicati in base al numero di unità di capacità (CU) allocate a ognuna.

Quando si abilita la replica geografica, l'unico costo aggiuntivo è il costo della larghezza di banda per i dati replicati dal database primario al secondario. Questo addebito dipende dalla posizione dell'area primaria.

Namespace Premium

Per gli spazi dei nomi Premium, quando si abilita la replica geografica, si ottiene lo stesso numero di unità di elaborazione (UR) nell'area secondaria. Si paga per il numero di PU utilizzate e la larghezza di banda utilizzata per il trasferimento dei dati tra la regione primaria e secondaria.

Ad esempio, se si abilita la replica geografica in uno spazio dei nomi Premium che hai effettuato il provisioning con 4 PUs, si paga per

• 4 UR nell'area primaria,
• 4 UR nell'area secondaria,
• Addebito della replica geografica per GB di dati replicati.

Si pagano costi per la larghezza di banda in base ai dati trasferiti tra le aree primarie e secondarie.

Contatori dei prezzi

I contatori dei prezzi per il costo della larghezza di banda per il trasferimento dei dati di replica geografica vengono visualizzati con i dettagli seguenti:

Nome prodotto	Descrizione misuratore
Bus di servizio	Bus di servizio - Trasferimento di 1 GB di dati, zona di replica geografica 1 - NOME AREA GEOGRAFICA
Bus di servizio	Bus di servizio - Trasferimento di 2 GB di dati, zona di replica geografica 2 - NOME AREA GEOGRAFICA
Bus di servizio	Bus di servizio - Trasferimento di 3 GB di dati, zona di replica geografica 3 - NOME AREA GEOGRAFICA

Endpoint privati

In questa sezione vengono fornite considerazioni aggiuntive quando si usa la replica geografica con spazi dei nomi che usano endpoint privati. Per informazioni generali sull'uso di endpoint privati con Hub eventi, vedere Integrate Hub eventi di Azure con collegamento privato di Azure.

Quando si implementa la georeplica per uno spazio dei nomi di Event Hubs che usa endpoint privati, creare endpoint privati per le regioni primarie e secondarie. Configurare questi endpoint su reti virtuali che ospitano istanze primarie e secondarie dell'applicazione. Ad esempio, se si dispone di due reti virtuali, VNET-1 e VNET-2, è necessario creare due endpoint privati nello spazio dei nomi di Hub eventi, usando rispettivamente subnet da VNET-1 e VNET-2. Configurare le reti virtuali con peering tra aree, in modo che i client possano comunicare con uno degli endpoint privati. Infine, gestire il DNS affinché tutti i client ricevano le informazioni DNS che indirizzano l'endpoint del namespace (namespacename.servicebus.windows.net) all'indirizzo IP dell'endpoint privato nella regione primaria attuale.

Importante

Quando si promuove una regione secondaria per gli Hub di eventi, aggiornare la voce DNS affinché punti all'endpoint corrispondente.

Questo approccio offre il vantaggio che il failover può verificarsi indipendentemente a livello di applicazione o nello spazio dei nomi di Event Hubs.

• Failover solo applicazione: In questo scenario, l'applicazione passa da VNET-1 a VNET-2. Poiché gli endpoint privati sono configurati sia in VNET-1 che in VNET-2 per gli spazi dei nomi primario e secondario, l'applicazione continua a funzionare senza problemi.
• Failover solo dello spazio dei nomi di Event Hubs: Se il failover si verifica solo a livello di spazio dei nomi di Event Hubs, l'applicazione rimane operativa perché gli endpoint privati sono configurati in entrambe le reti di virtualizzazione.

Seguendo queste linee guida, è possibile garantire meccanismi di failover robusti e affidabili per i namespace di Event Hubs che utilizzano endpoint privati.

Contenuti correlati

Per informazioni su come usare la funzionalità di replica geografica, vedere Usare la replica geografica.