Condividi tramite

Configurare la replica geografica passiva per le istanze di Cache Redis di Azure Premium

  • Articolo

Questo articolo illustra come configurare la replica geografica passiva in una coppia di istanze di Cache di Azure per Redis usando il portale di Azure.

La replica geografica passiva collega due istanze di Cache di Azure per Redis di livello Premium e crea una relazione di replica dei dati attiva-passiva. Attivo-passivo significa che è presente una coppia di cache, primaria e secondaria, che ha i dati sincronizzati. Tuttavia, è possibile scrivere solo su un lato della coppia, ovvero la replica primaria. L'altro lato della coppia, la cache secondaria, è di sola lettura.

Confrontare attivo-passivo con attivo-attivo, in cui è possibile scrivere su entrambi i lati della coppia, e si sincronizza con l'altro lato.

Con la replica geografica passiva, le istanze della cache si trovano in genere in aree di Azure diverse, anche se non è necessario. Un'istanza funge da primaria e l'altra come secondaria. Il database primario gestisce le richieste di lettura e scrittura, e la replica primaria propaga le modifiche al database secondario.

Il failover non è automatico. Per altre informazioni su come usare il failover, vedere Avviare un failover dalla replica geografica primaria a quella geografica secondaria.

Nota

La replica geografica passiva è progettata come soluzione di ripristino di emergenza.

Ambito della disponibilità

Livello Basic e Standard Premium Enterprise, Enterprise Flash
Disponibile No Sì Sì

La replica geografica passiva è disponibile solo nel livello Premium di Cache di Azure per Redis. I livelli Enterprise ed Enterprise Flash offrono anche la replica geografica, ma questi livelli usano una versione più avanzata denominata replica geografica attiva.

Prerequisiti per la replica geografica

Per configurare la replica geografica tra due cache, devono essere soddisfatti i prerequisiti seguenti:

  • Entrambe le cache sono cache di livello Premium.
  • Entrambe le cache si trovano nella stessa sottoscrizione di Azure.
  • La cache collegata secondaria è la stessa dimensione della cache o una dimensione della cache maggiore rispetto alla cache collegata primaria. Per usare il failover geografico, entrambe le cache devono avere le stesse dimensioni.
  • Vengono create entrambe le cache e in uno stato di esecuzione.
  • Entrambe le cache eseguono la stessa versione del server Redis.

Nota

Il trasferimento dei dati tra aree di Azure viene addebitato a velocità di larghezza di banda standard.

Alcune funzionalità non sono supportate con la replica geografica:

  • La ridondanza della zona non è supportata con la replica geografica.
  • La persistenza non è supportata con la replica geografica.
  • Le cache con più repliche non possono essere replicate geograficamente.
  • Il clustering è supportato se entrambe le cache hanno il clustering abilitato e hanno lo stesso numero di partizioni.
  • Sono supportate le cache nella stessa rete virtuale.
  • Le cache in reti virtuali diverse sono supportate con avvertenze. Per altre informazioni, vedere È possibile usare la replica geografica con le cache in una rete virtuale?

Dopo aver configurato la replica geografica, si applicano le restrizioni seguenti alla coppia di cache collegate:

  • La cache collegata secondaria è di sola lettura. È possibile leggerla, ma non è possibile scrivervi dati. Se si sceglie di leggere dall'istanza geo-secondaria quando si verifica una sincronizzazione completa dei dati tra l’istanza geografica primaria e quella geografica secondaria, l'istanza geografica secondaria genera errori su qualsiasi operazione Redis su di essa fino al completamento della sincronizzazione completa dei dati. Gli errori segnalano che è in corso una sincronizzazione completa dei dati. Inoltre, gli errori vengono generati quando viene aggiornata l’istanza geografica primaria o geografica secondaria e in alcuni scenari di riavvio. Le applicazioni che leggono dall’istanza geografica secondaria devono essere compilate per eseguire il fallback all'area geografica primaria ogni volta che il database geografico secondario genera tali errori.

  • Tutti i dati presenti nella cache collegata secondaria prima dell'aggiunta del collegamento vengono rimossi. Se la replica geografica viene rimossa in un secondo momento, i dati replicati rimangono nella cache collegata secondaria.

  • Non è possibile ridimensionare nessuna delle due cache mentre le cache sono collegate.

  • Non è possibile modificare il numero di partizioni se è abilitato il clustering della cache.

  • Non è possibile abilitare la persistenza in nessuna delle cache.

  • È possibile Esportare da entrambe le cache.

  • Non è possibile Importare nella cache collegata secondaria.

  • Non è possibile eliminare la cache collegata o il gruppo di risorse che le contiene fino a quando non si scollegano le cache. Per altre informazioni, vedere Perché, quando si è tentato di eliminare la cache collegata, l'operazione non è riuscita?

  • Se le cache si trovano in aree diverse, i costi di uscita di rete si applicano ai dati spostati tra aree. Per altre informazioni, vedere Quanto costa replicare i dati nelle aree di Azure?

  • Il failover non è automatico. È necessario avviare il failover dalla cache primaria alla cache collegata secondaria. Per altre informazioni su come usare il failover, vedere Avviare un failover dalla replica geografica primaria a quella geografica secondaria.

  • Non è possibile aggiungere collegamenti privati alle cache già replicate geograficamente. Per aggiungere un collegamento privato a una cache con replica geografica: 1. Scollegare la replica geografica. 2. Aggiungere un collegamento privato. 3. Infine, ricollegare la replica geografica.

  1. Per collegare due cache per la replica geografica, selezionare prima Replica geografica dal menu Risorsa della cache che si intende utilizzare come cache collegata primaria. Selezionare quindi Aggiungi collegamento di replica della cache nel riquadro di lavoro.

    Screenshot che mostra il menu Replica geografica della cache.

  2. Selezionare il nome della cache secondaria desiderata dall'elenco Cache compatibili. Se la cache secondaria non viene visualizzata nell'elenco, verificare che vengano soddisfatti i prerequisiti di replica geografica per la cache secondaria. Per filtrare le cache in base all'area, selezionare l'area nella mappa per visualizzare solo le cache nell'elenco Cache compatibili.

    Screenshot che mostra le cache compatibili per il collegamento con la replica geografica.

    È anche possibile avviare il processo di collegamento o visualizzare i dettagli sulla cache secondaria usando il menu di scelta rapida.

    Screenshot che mostra il menu di scelta rapida Replica geografica.

  3. Selezionare Collega per collegare le due cache e iniziare il processo di replica.

    Screenshot che mostra come collegare le cache per la replica geografica.

  4. È possibile visualizzare lo stato di avanzamento del processo di replica usando la replica geografica nel menu Risorsa.

    Screenshot che mostra lo stato del collegamento corrente.

    È anche possibile visualizzare lo stato del collegamento usando Panoramica dal menu Risorsa per le cache primarie e secondarie.

    Screenshot che evidenzia come visualizzare lo stato del collegamento per le cache primaria e secondaria.

    Al termine del processo di replica, lo stato del provisioning del collegamento viene modificato in Operazione completata.

    Screenshot che mostra lo stato di collegamento della cache come Operazione completata.

    La cache collegata primaria rimane disponibile per l'uso durante il processo di collegamento. La cache collegata secondaria non è disponibile fino al completamento del processo di collegamento.

URL primario geografico

Dopo aver collegato le cache, viene generato un URL per ogni cache che punta sempre alla cache geografica primaria. Se un failover viene avviato dal database primario geografico alla replica geografica secondaria, l'URL rimane invariato e il record DNS sottostante viene aggiornato automaticamente in modo da puntare al nuovo database geografico primario.

Screenshot che mostra quattro URL creati aggiungendo la replica geografica.

Vengono visualizzati tre URL:

  • L’URL primario geografico è un URL proxy con il formato di <cachename>.geo.redis.cache.windows.net. L'URL punta sempre alla cache nella coppia di replica geografica, ovvero la replica geografica corrente.
  • La cache primaria geografica corrente è l'indirizzo diretto della cache che attualmente è la replica geografica primaria. L'indirizzo è redis.cache.windows.net non geo.redis.cache.windows.net. L'indirizzo elencato nel campo cambia se viene avviato un failover.
  • La cache geografica secondaria corrente è l'indirizzo diretto della cache attualmente secondaria geografica. L'indirizzo è redis.cache.windows.net non geo.redis.cache.windows.net. L'indirizzo elencato nel campo cambia se viene avviato un failover.

Avviare un failover da replica geografica primaria a secondaria geografica

Con una selezione, è possibile attivare un failover dal database primario geografico alla replica geografica secondaria.

Screenshot delle cache collegate con Failover evidenziato.

In questo modo è necessario eseguire i passaggi seguenti:

  1. La cache geografica secondaria viene alzata di livello a replica geografica primaria.
  2. I record DNS vengono aggiornati per reindirizzare gli URL geografici primari al nuovo database geografico primario.
  3. La cache geografica precedente viene abbassata di livello a quella secondaria e tenta di creare un collegamento alla nuova cache geografica primaria.

Il completamento del processo di failover geografico richiede alcuni minuti.

Impostazioni da controllare prima di avviare il failover geografico

Quando viene avviato il failover, le cache geografica primaria e geografica secondaria vengono scambiate. Se la nuova replica geografica primaria è configurata in modo diverso rispetto alla replica geografica secondaria, può creare problemi per l'applicazione.

Assicurarsi di controllare gli elementi seguenti:

  • Se si usa un firewall in una delle due cache, assicurarsi che le impostazioni del firewall siano simili in modo da non avere problemi di connessione.
  • Assicurarsi che entrambe le cache usino la stessa porta e le stesse impostazioni TLS/SSL
  • Le cache geografiche primarie e geografiche secondarie hanno chiavi di accesso diverse. Se viene attivato un failover, assicurarsi che l'applicazione possa aggiornare la chiave di accesso usata per trovare la corrispondenza con la nuova replica geografica primaria. In alternativa, usare i token di Microsoft Entra per l'autenticazione della cache, che consentono di usare le stesse credenziali di autenticazione sia per la cache geografica primaria che per la cache geografica secondaria.

Failover con perdita minima di dati

Gli eventi di failover geografico possono introdurre incoerenze dei dati durante la transizione, soprattutto se il client mantiene una connessione al vecchio database geografico primario durante il processo di failover. È possibile ridurre al minimo la perdita di dati in un evento di failover geografico pianificato usando i suggerimenti seguenti:

  • Controllare la metrica di offset della sincronizzazione dei dati di replica geografica. La metrica viene generata dalla cache geografica primaria corrente. Questa metrica indica quanti dati devono ancora essere replicati nell'area geografica primaria. Se possibile, avviare il failover solo se la metrica indica che rimangono meno di 14 byte.
  • Eseguire il comando CLIENT PAUSE nell'area geografica corrente prima di avviare il failover. L'esecuzione di CLIENT PAUSE blocca le nuove richieste di scrittura e restituisce invece errori di timeout al client Cache di Azure per Redis. Il comando CLIENT PAUSE richiede un periodo di timeout in millisecondi. Assicurarsi che venga fornito un periodo di timeout sufficientemente lungo per consentire l'esecuzione del failover. Impostare il valore di pausa su circa 30 minuti (1.800.000 millisecondi) è un buon punto di partenza. È sempre possibile ridurre questo numero in base alle esigenze.

Non è necessario eseguire il comando UNPAUSE CLIENT perché la nuova replica geografica primaria mantiene la sospensione del client.

Nota

L'uso dell'autenticazione basata sull'ID di Microsoft Entra per la cache è consigliato negli scenari di failover geografico perché rimuove la difficoltà di gestire chiavi di accesso diverse per la cache geografica primaria e secondaria geografica.

  1. Per rimuovere il collegamento tra due cache e arrestare la replica geografica, selezionare Scollega cache dalla replica geografica a sinistra.

    Screenshot che mostra come scollegare le cache.

    Al termine del processo di scollegamento, la cache secondaria è disponibile per le operazioni di lettura e scrittura.

Nota

Quando viene rimosso il collegamento di replica geografica, i dati replicati dalla cache collegata primaria restano nella cache secondaria.

Domande frequenti sulla replica geografica

È possibile usare la replica geografica con una cache di livello Standard o Basic?

No, la replica geografica passiva è disponibile solo nel livello Premium. Una versione più avanzata della replica geografica denominata replica geografica attiva è disponibile nel livello Enterprise ed Enterprise Flash.

La cache è disponibile per l'uso durante il processo di collegamento o scollegamento?

  • La cache collegata primaria rimane disponibile fino al completamento del processo di collegamento.
  • La cache collegata secondaria non è disponibile fino al completamento del processo di collegamento.
  • Entrambe le cache rimangono disponibili fino al completamento del processo di scollegamento.

Quando è possibile scrivere nel nuovo database primario geografico dopo l'avvio del failover?

Quando il processo di failover viene avviato, viene visualizzato l'aggiornamento dello stato del provisioning dei collegamenti a Eliminazione, che indica che il collegamento precedente è in corso di pulizia. Al termine, lo stato del provisioning del collegamento viene aggiornato a Creazione. Ciò indica che la nuova replica geografica primaria è operativa e tenta di ristabilire un collegamento di replica geografica alla cache geografica precedente. A questo punto, è possibile connettersi immediatamente alla nuova istanza della cache primaria geografica sia per le letture che per le scritture.

Sì, sono disponibili diverse metriche per tenere traccia dello stato della replica geografica. Queste metriche sono disponibili nel portale di Azure.

  • Replica geografica integra mostra lo stato del collegamento di replica geografica. Il collegamento viene visualizzato come non integro se le cache geografiche primarie o geografiche secondarie sono inattive. Questo è in genere dovuto a operazioni standard di applicazione di patch, ma potrebbe anche indicare una situazione di errore.
  • Il ritardo di connettività della replica geografica mostra l'ora dell'ultima sincronizzazione dei dati riuscita tra la replica geografica primaria e quella geografica secondaria.
  • L’offset di sincronizzazione dati replica geografica mostra la quantità di dati che devono ancora essere sincronizzati con la cache geografica secondaria.
  • L'avvio dell'evento di sincronizzazione completa della replica geografica indica che è stata avviata un'azione di sincronizzazione completa tra le cache geografiche primarie e geografiche secondarie. Ciò si verifica se la replica standard non riesce a tenere il passo con il numero di nuove scritture.
  • Evento di sincronizzazione completa replica geografica completato indica che è stata completata un'azione di sincronizzazione completa.

È disponibile anche una cartella di lavoro predefinita denominata Dashboard replica geografica che include tutte le metriche di integrità della replica geografica in un'unica visualizzazione. È consigliabile usare questa vista perché aggrega le informazioni generate solo dalle istanze della cache geografica primaria o geografica secondaria.

No, è possibile collegare due cache solo quando si usa la replica geografica passiva. La replica geografica attiva supporta fino a cinque cache collegate.

No, entrambe le cache devono trovarsi nella stessa sottoscrizione di Azure.

Sì, purché la cache collegata secondaria sia più grande della cache collegata primaria. Tuttavia, non è possibile usare la funzionalità di failover se le cache sono di dimensioni diverse.

È possibile usare la replica geografica con il clustering abilitato?

Sì, purché entrambe le cache abbiano lo stesso numero di partizioni.

È possibile usare la replica geografica con le cache in una rete virtuale?

È consigliabile usare il collegamento privato di Azure nella maggior parte dei casi tramite l'inserimento della rete virtuale. Per altre informazioni, vedere Eseguire la migrazione da cache di inserimento della rete virtuale a cache di collegamento privato.

Sebbene sia ancora tecnicamente possibile usare l'inserimento di reti virtuali durante la replica geografica delle cache, è consigliabile usare il collegamento privato di Azure.

Importante

Cache di Azure per Redis consiglia di usare il collegamento privato di Azure, che semplifica l'architettura di rete e protegge la connessione tra gli endpoint in Azure. È possibile connettersi a un'istanza della cache di Azure per Redis dalla propria rete virtuale tramite un endpoint privato, a cui viene assegnato un indirizzo IP privato in una subnet entro la rete virtuale. I collegamenti privati di Azure sono disponibili a tutti i livelli, includono assistenza per i Criteri di Azure e la gestione semplificata delle regole del gruppo di sicurezza di rete. Per altre informazioni, vedere la documentazione relativa ai collegamenti privati. Per eseguire la migrazione delle cache inserite nella rete virtuale al collegamento privato, vedere Eseguire la migrazione da cache di inserimento reti virtuali a cache di collegamento privato.

Per altre informazioni sul supporto per la replica geografica con reti virtuali, vedere Replica geografica tramite inserimento di reti virtuali con cache Premium.

Che cos'è la pianificazione della replica per la replica geografica Redis?

La replica è continua e asincrona. Non avviene in base a una pianificazione specifica. Tutte le operazioni di scrittura eseguite nel database primario vengono replicate istantaneamente e in modo asincrono sul database secondario.

Quanto tempo richiede la replica geografica?

La replica è incrementale, asincrona e continua e il tempo impiegato non è molto diverso dalla latenza tra le aree. In determinate circostanze, la cache secondaria può essere necessaria per eseguire una sincronizzazione completa dei dati dal database primario. Il tempo di replica in questo caso dipende da molti fattori, ad esempio il carico sulla cache primaria, la larghezza di banda di rete disponibile e la latenza tra aree. È stato rilevato che il tempo di replica per una coppia con replica geografica completa da 53 GB può essere compreso tra 5 e 10 minuti. È possibile tenere traccia della quantità di dati che devono ancora essere replicati usando la metrica Geo Replication Data Sync Offset in Monitoraggio di Azure.

Il punto di recupero della replica è garantito?

Per le cache in modalità con replica geografica, la persistenza è disabilitata. Se una coppia con replica geografica è scollegata, ad esempio un failover avviato dal cliente, la cache collegata secondaria mantiene i dati sincronizzati fino a quel momento. In tali situazioni non è garantito alcun punto di ripristino.

Per ottenere un punto di ripristino, esportare da una delle due cache. In seguito è possibile importare nella cache collegata primaria.

È possibile usare PowerShell o l'interfaccia della riga di comando di Azure per gestire la replica geografica?

Sì, la replica geografica può essere gestita usando il portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure. Per altre informazioni, vedere la documentazione di PowerShell o la documentazione dell'interfaccia della riga di comando di Azure.

Quanto costa replicare i dati nelle aree di Azure?

Quando si usa la replica geografica, i dati dalla cache collegata primaria vengono replicati nella cache collegata secondaria. Non è previsto alcun addebito per il trasferimento dei dati se le due cache collegate si trovano nella stessa area. Se le due cache collegate si trovano in aree diverse, l'addebito per il trasferimento dei dati è il costo in uscita di rete dei dati che si spostano in entrambe le aree. Per altre informazioni, vedere Dettagli sui prezzi per la larghezza di banda.

Perché, quando si è tentato di eliminare la cache collegata, l'operazione non è riuscita?

Le cache con replica geografica e i relativi gruppi di risorse non possono essere eliminati mentre sono collegati, finché non si rimuove il collegamento di replica geografica. Se si tenta di eliminare il gruppo di risorse che contiene una o entrambe le cache collegate, vengono eliminate le altre risorse nel gruppo di risorse, ma il gruppo di risorse rimane nello stato deleting mentre le cache collegate nel gruppo di risorse rimangono nello stato running. Per eliminare completamente il gruppo di risorse e le cache collegate al suo interno, scollegare le cache come descritto in Rimuovere un collegamento di replica geografica.

Quale area si deve usare per la cache collegata secondaria?

In generale, è consigliabile che la cache sia presente nella stessa area di Azure dell'applicazione che accede ad essa. Per le applicazioni con aree primarie e di fallback separate, è consigliabile che le cache primarie e secondarie esistano in queste stesse aree. Per altre informazioni sulle aree abbinate, vedere Continuità aziendale e ripristino di emergenza nelle aree geografiche abbinate di Azure.

È possibile configurare un firewall con la replica geografica?

Sì, è possibile configurare un firewall con la replica geografica. Per il funzionamento della replica geografica insieme a un firewall, assicurarsi che l'indirizzo IP della cache secondaria venga aggiunto alle regole del firewall della cache primaria. Tuttavia, se l'accesso alla rete pubblica è disabilitato nella cache e solo l'endpoint privato è abilitato, l'uso del firewall nella cache non è supportato.

Passaggi successivi

Altre informazioni sulle funzionalità della cache di Azure per Redis.