Replica geografica (anteprima pubblica)

Esistono due funzionalità che forniscono il ripristino di emergenza geografico in Hub eventi di Azure.

• Ripristino di emergenza geografico (ripristino di emergenza metadati), che fornisce la replica dei soli metadati.
• Replica geografica (anteprima pubblica), che fornisce la replica sia dei metadati sia dei dati.

Nota

La funzionalità di replica geografica è supportata solo dal livello dedicato.

Queste funzionalità non devono essere confuse con le zone di disponibilità. Entrambe le funzionalità di ripristino geografico offrono resilienza tra aree di Azure, ad esempio Stati Uniti orientali e Stati Uniti occidentali. Il supporto della zona di disponibilità offre resilienza all'interno di un'area geografica specifica, ad esempio Stati Uniti orientali. Per altre informazioni sulle zone di disponibilità, vedere Supporto delle zone di disponibilità in Hub eventi.

Importante

• Questa funzionalità è attualmente in anteprima pubblica e, di conseguenza, non deve essere usata negli scenari di produzione.
• Le aree seguenti sono attualmente supportate nell'anteprima pubblica.

Paese	Paese	Paese
Australiacentrale	GermaniaNorth	NorvegiaWest
AustraliaCentral2	GermanyWestCentral	PoloniaCentral
Australiaorientale	IsraeleCentral	SouthAfricaNorth
Australiasud-orientale	ItaliaNorth	SouthAfricaWest
BrasileSoutheast	JapanEast	SoutheastAsia
CanadaCentral	JapanWest	SouthIndia
Canadaorientale	JioIndiaCentral	SpagnaCentral
CentralIndia	JioIndiaWest	SwedenCentral
CentralUS	KoreaCentral	SwitzerlandNorth
CentralUSEUAP	KoreaSouth	SwitzerlandWest
EastAsia	MessicoCentral	Emirati Arabi UnitiCentral
EastUS2	NorthCentralUS	UAENorth
FranceCentral	NorthEurope	UKSouth
FranceSouth	NorwayEast	UKWest

Confronto tra ripristino di emergenza e replica geografica di metadati e dati

La funzionalità Ripristino di emergenza metadati replica le informazioni di configurazione per uno spazio dei nomi da uno spazio dei nomi primario a uno spazio dei nomi secondario. Supporta un failover una sola volta nell'area secondaria. Durante il failover avviato dal cliente, il nome alias per lo spazio dei nomi viene ripuntato allo spazio dei nomi secondario e quindi l'associazione viene interrotta. Non vengono replicati dati diversi dalle informazioni di configurazione, né vengono replicate assegnazioni di autorizzazioni.

La funzionalità di replica geografica più recente replica le informazioni di configurazione e tutti i dati da uno spazio dei nomi primario a uno o più spazi dei nomi secondari. Quando viene eseguito un failover, lo spazio dei nomi secondario selezionato diventa primario e lo spazio dei nomi primario precedente diventa secondario. Gli utenti possono eseguire un nuovo failover nell'area primaria originale quando lo desiderano.

La parte rimanente di questo articolo illustra la funzionalità di replica geografica. Per informazioni dettagliate sulla funzionalità di ripristino di emergenza metadati, vedere Ripristino di emergenza geografico di Hub eventi per i metadati.

Replica geografica

L'anteprima pubblica della funzionalità di replica geografica è supportata per gli spazi dei nomi nei cluster dedicati di scalabilità self-service di Hub eventi. È possibile usare la funzionalità con spazi dei nomi nuovi o esistenti all'interno di cluster self-service dedicati. Le funzionalità seguenti non sono supportate con la replica geografica:

• Chiavi gestite dal cliente (CMK)
• Identità gestita per l'acquisizione
• Funzionalità della rete virtuale (endpoint servizio o endpoint privati)
• Supporto di messaggi di grandi dimensioni (ora in anteprima pubblica)
• Transazioni Kafka (ora in anteprima pubblica)

Alcuni degli aspetti principali dell'anteprima pubblica della replica geografica dei dati sono:

• Modello di replica primario-secondario: la replica geografica è basata sul modello di replica primario-secondario, in cui in un momento specifico è presente un solo spazio dei nomi primario che gestisce le richieste di producer di eventi e consumer 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 di dominio completo (FQDN) dello spazio dei nomi stabile: il nome di dominio completo non deve cambiare quando viene eseguita la promozione.
• Coerenza di replica: sono disponibili due impostazioni di coerenza della replica, sincrona e asincrona.
• Promozione gestita dall'utente di un'area secondaria affinché diventi la nuova primaria.

Il passaggio da un'area secondaria a una nuova primaria viene eseguito in due modi:

• Pianificato: promozione dell'area secondaria a primaria, in cui il traffico non viene elaborato fino a quando la nuova primaria non viene aggiornata con tutti i dati contenuti nell'istanza dell'area primaria precedente.
• Forzato: come un failover, in cui l'area secondaria diventa primaria il più rapidamente possibile. La funzionalità di replica geografica replica tutti i dati e i metadati dall'area primaria alle aree secondarie selezionate. Il nome di dominio completo dello spazio dei nomi punta sempre all'area primaria.

Quando si avvia una promozione di un'area secondaria, il nome di dominio completo punta all'area selezionata come nuova primaria. L'area primaria precedente diventa quindi secondaria. È possibile promuovere l'area secondaria come nuova primaria per motivi diversi da un failover. Questi motivi possono includere aggiornamenti dell'applicazione, test di failover o qualsiasi altro motivo. In queste situazioni, è tipico tornare alla versione precedente quando tali attività vengono completate.

Le aree secondarie vengono aggiunte o rimosse a discrezione del cliente. Esistono alcune limitazioni correnti che vale la pena notare:

• Non è possibile supportare visualizzazioni di sola lettura nelle aree secondarie.
• Non esiste alcuna funzionalità automatica di promozione/failover. Tutte le promozioni vengono avviate dai clienti.
• Le aree secondarie devono essere diverse dall'area primaria. Non è possibile selezionare un altro cluster dedicato nella stessa area.
• Per l'anteprima pubblica è supportata una sola area secondaria.

Coerenza della replica

Esistono due configurazioni di coerenza della replica, sincrona e asincrona. È importante conoscere le differenze tra le due configurazioni perché esercitano un impatto sulle applicazioni e sulla coerenza dei dati.

Replica asincrona

Con la replica asincrona abilitata, viene eseguito il commit di tutti i messaggi nell'area primaria e quindi vengono inviati all'area secondaria. Gli utenti possono configurare una quantità accettabile di tempo di ritardo che l'area secondaria deve recuperare. Quando il ritardo per un'area secondaria attiva è maggiore della configurazione di ritardo dell'utente, l'area primaria limita le richieste di pubblicazione in ingresso.

Replica sincrona

Quando la replica sincrona è abilitata, gli eventi pubblicati vengono replicati nell'area secondaria, che deve confermare il messaggio prima del commit nell'area primaria. Con la replica sincrona, l'applicazione pubblica alla velocità necessaria a pubblicare, replicare, confermare ed eseguire il commit. Ciò significa anche che l'applicazione è associata alla disponibilità di entrambe le aree. Se l'area secondaria diventa inattiva, non è possibile confermare o eseguire il commit dei messaggi.

Confronto tra coerenza di replica

Con la replica sincrona:

• La latenza è più lunga a causa del commit distribuito.
• La disponibilità è legatta a quella di due aree. Se un'area diventa inattiva, lo spazio dei nomi non è disponibile.
• I dati ricevuti risiedono sempre in almeno due aree. Nell'anteprima pubblica iniziale, sono supportate solo due aree.

La replica sincrona garantisce la massima sicurezza dei dati. Se si dispone di una replica sincrona, il commit viene effettuato in tutte le aree configurate per la replica geografica. Quando la replica sincrona è abilitata, tuttavia, la disponibilità dell'applicazione può essere ridotta in base alla disponibilità di entrambe le aree.

L'abilitazione della replica asincrona non influisce particolarmente sulla latenza e la disponibilità del servizio non è influenzata dalla perdita di un'area secondaria. La replica asincrona non offre la garanzia assoluta che tutte le aree abbiano a disposizione i dati prima di eseguirne il commit, come avviene nella replica sincrona. È anche possibile impostare il tempo durante cui l'area secondaria può essere non sincronizzata prima che il traffico in ingresso venga limitato. L'impostazione può essere da 5 a 1.440 minuti, ovvero un giorno. Se si vogliono utilizzare aree con una distanza elevata tra di esse, è probabile che la replica asincrona costituisca l'opzione migliore.

La configurazione della coerenza di replica può cambiare dopo la configurazione della replica geografica. È possibile passare da sincrona ad asincrona o da asincrona a sincrona. Se si passa da sincrona ad asincrona, si verifica un miglioramento della latenza e della disponibilità dell'applicazione. Se si passa da asincrona a sincrona, la replica secondaria viene configurata come sincrona quando il ritardo raggiunge lo zero. Se, per qualsiasi motivo, il ritardo è continuo, potrebbe essere necessario sospendere i server di pubblicazione affinché il ritardo raggiunga lo zero e la modalità possa passare a quella sincrona.

I motivi generali per cui è abilitata la replica sincrona sono legati all'importanza dei dati, alle esigenze aziendali specifiche o a motivi di conformità. Se l'obiettivo principale è la disponibilità dell'applicazione anziché la garanzia dei dati, è probabile che la coerenza asincrona rappresenti la scelta migliore.

Selezione dell'area secondaria

Per abilitare la funzionalità di replica geografica, è necessario usare un'area primaria e secondaria in cui è abilitata la funzionalità di replica geografica. È anche necessario che sia già presente un cluster di Hub eventi nelle aree primaria e secondaria.

La funzionalità di replica geografica dipende dalla possibilità di replicare gli eventi pubblicati dall'area primaria all'area secondaria. Se l'area secondaria si trova in un altro continente, ciò esercita un impatto significativo sul ritardo della replica dall'area primaria all'area secondaria. Se si usa la replica geografica per motivi di disponibilità e affidabilità, è preferibile che le aree secondarie si trovino almeno nello stesso continente, se possibile. Per comprendere meglio la latenza indotta dalla distanza geografica, è possibile ottenere altre informazioni dalle Statistiche sulla latenza round trip della rete di Azure | Microsoft Learn.

Gestione della replica geografica

La funzionalità di replica geografica consente ai clienti di configurare un'area secondaria in cui replicare la configurazione e i dati. È possibile:

• Configurare la replica geografica: le aree secondarie possono essere configurate in qualsiasi spazio dei nomi esistente in un cluster dedicato self-service in un'area con il set di funzionalità di replica geografica abilitato. Possono anche essere configurate durante la creazione dello spazio dei nomi negli stessi cluster dedicati. Per selezionare un'area secondaria, è necessario disporre di un cluster dedicato disponibile in tale area secondaria. Inoltre, l'area secondaria deve anche avere il set di funzionalità di replica geografica abilitato per tale area.
• Configurare la coerenza di replica: la replica sincrona e asincrona viene impostata quando è configurata la replica geografica, ma può anche essere modificata in seguito. Con la coerenza asincrona, è possibile configurare il tempo di ritardo consentito per un'area secondaria.
• Attivazione di promozione/failover: tutte le promozioni o i failover vengono avviati dal cliente. Durante la promozione è possibile scegliere di forzarla dall'inizio o anche cambiare idea dopo l'avvio di una promozione e renderla forzata.
• Rimuovere un'area secondaria: se in qualsiasi momento si vuole rimuovere l'associazione geografica tra aree primaria e secondaria, è possibile eseguire tale operazione e i dati nell'area secondaria verranno eliminati.

Monitoraggio della replica dei dati

Gli utenti possono monitorare lo stato di avanzamento del processo di replica grazie al monitoraggio della metrica di ritardo della replica all'interno dei log delle metriche dell'applicazione.

• Per abilitare i log delle metriche dell'applicazione nello spazio dei nomi di Hub eventi, seguire la procedura riportata in Monitoraggio di Hub eventi di Azure - Hub eventi di Azure | Microsoft Learn.

• Dopo aver abilitato i log delle metriche dell'applicazione, è necessario produrre e utilizzare 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 di Hub eventi e selezionare Log nel menu a sinistra. È possibile usare la query seguente per trovare il ritardo di replica (in secondi) tra lo spazio dei nomi primario e quello secondario.

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

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

Pubblicazione dei dati

Le applicazioni di pubblicazione di eventi possono pubblicare i dati negli spazi dei nomi con replica geografica tramite il nome di dominio completo dello spazio dei nomi stabile dello spazio dei nomi con replica geografica. L'approccio di pubblicazione degli eventi è identico al caso di ripristino di emergenza non geografico e non sono necessarie modifiche alle applicazioni client.

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

• Durante il periodo di tolleranza di failover, l'area primaria esistente rifiuta eventuali 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 che utilizzano eventi possono utilizzare i dati tramite il nome di dominio completo dello spazio dei nomi stabile di uno spazio dei nomi con replica geografica. Le operazioni consumer non sono supportate, dal momento in cui il failover viene avviato fino al completamento.

Gestione checkpoint/offset

Le applicazioni che utilizzano gli eventi possono continuare a gestire gli offset come farebbero con un singolo spazio dei nomi.

Kafka

Gli offset vengono sottoposti direttamente a commit in Hub eventi e vengono replicati in più aree. Pertanto, i consumer possono iniziare l'utilizzo da dove è stato interrotto nell'area primaria.

SDK di Hub eventi/Advance Message Queueing Protocol

I client che usano l'SDK di Hub eventi devono eseguire l'aggiornamento alla versione di aprile 2024 dell'SDK. La versione più recente dell'SDK di Hub eventi supporta il failover con un aggiornamento al checkpoint. Il checkpoint viene gestito dagli utenti con archivio checkpoint, ad esempio Archiviazione BLOB di Azure o una soluzione di archiviazione personalizzata. Se si verifica un failover, l'archivio checkpoint deve essere disponibile dall'area secondaria, in modo che i client possano recuperare i dati del checkpoint ed evitare la perdita di messaggi.

Prezzi

Il prezzo dei cluster dedicati di Hub eventi è indipendente dalla replica geografica. L'uso della replica geografica con Hub eventi dedicato richiede la presenza di almeno due cluster dedicati in aree separate. I cluster dedicati usati come istanze secondarie per la replica geografica possono essere usati per altri carichi di lavoro. È previsto un addebito per la replica geografica in base alla larghezza di banda pubblicata * il numero di aree secondarie. Nell'anteprima pubblica anticipata, non vi è alcun addebito della replica geografica.

Contenuto correlato

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