Condividi tramite


Eseguire la migrazione dai livelli Basic, Standard, Premium ed Enterprise a Redis gestito di Azure

Questo articolo illustra perché e come eseguire la migrazione da Cache Redis di Azure (inclusi i livelli Basic, Standard, Premium ed Enterprise) a Redis gestito di Azure.

Vengono fornite informazioni su:

  • Vantaggi della scelta di Redis gestito di Azure rispetto ai livelli precedenti.
  • Differenze principali tra le funzionalità tra i servizi.
  • Strategie per la migrazione dei dati della cache.
  • Modi per garantire un processo di migrazione senza problemi.
  • Indicazioni su come selezionare lo SKU e il livello di prestazioni di Redis gestiti di Azure corretti per le proprie esigenze.
  • Considerazioni e consigli per l'aggiornamento delle applicazioni client.

Indipendentemente dal fatto che si usino livelli Basic, Standard, Premium oEnterprise o OSS, questa guida consente di pianificare ed eseguire la migrazione a Redis gestita di Azure.

Il documento si divide in due sezioni. Uno riguarda le istanze aziendali. L'altro riguarda i livelli Basic, Standard e Premium di Cache Redis di Azure.

Vantaggi del passaggio da Enterprise a Redis gestito di Azure

Redis gestito di Azure si basa sul software Redis Enterprise avanzato. Redis gestito di Azure è un'offerta di prima parte di Azure, ovvero non è coinvolto alcun componente di Azure Marketplace e gli utenti non devono eseguire transazioni separatamente con Marketplace. È possibile effettuare il provisioning, la gestione e il pagamento di Redis Gestito di Azure come qualsiasi altro servizio o prodotto nativo di Azure.

Redis gestito di Azure non richiede il nodo quorum che porta a risorse sottoutilizzate e limita le aree o i cloud in cui è possibile offrire Cache Redis Enterprise di Azure. Redis gestito di Azure è ora disponibile nella maggior parte delle aree di Azure e verrà supportato anche in altri cloud sovrani. Per ulteriori informazioni sul nodo di quorum, vedere i livelli Enterprise e Enterprise Flash. Rimuovendo il nodo quorum inutilizzato, si ottiene una maggiore efficienza dei costi perché tutti i nodi possono essere usati come nodi dati.

Redis Gestito di Azure è con ridondanza della zona per impostazione predefinita.

È possibile usare Redis gestito di Azure senza disponibilità elevata per gli ambienti di sviluppo e test. L'uso di ambienti non di produzione senza disponibilità elevata dimezza il costo dell'istanza.

La struttura SKU per Azure Redis gestito è basata sulle vostre esigenze di memoria e prestazioni. Invece di gestire fattori di scala o capacità come con Cache Redis di Azure per Redis Enterprise, è possibile scegliere tra tre livelli di prestazioni in Azure Managed Redis. Per altre informazioni, vedere Scelta del livello corretto.

Infine, Azure Managed Redis offre l'autenticazione dell'ID Entra di Microsoft quando si crea una cache per migliorare il comportamento di sicurezza del carico di lavoro.

Confronto delle funzionalità

Caratteristica / Funzionalità cache di Azure per Redis Enterprise Redis Gestito di Azure
Versione di Redis 7.2 7.4
Politica di clustering Software open source, Enterprise Software open source, Enterprise, non cluster
Replica geografica Active Active
SLA Fino a 99,999% Fino a 99,999%
Ridondanza della zona Sì (impostazione predefinita)
Modalità non a disponibilità elevata NO Sì (per sviluppo/test)
Salvataggio permanente dei dati Sì (in anteprima)
Scaling
Supporto della versione di TLS 1.2,1.3 1.2,1.3
Autenticazione dell'ID Microsoft Entra NO
Supporto per aree di Azure Limitato Estensivo
Supporto per il Cloud Sovrano di Azure NO Sì (presto disponibile)
Suffisso DNS del nome host <name>.<region>.redisenterprise.cache.azure.net <name>.<region>.redis.azure.net

Considerazioni relative al passaggio da Enterprise a Redis gestito di Azure

Azure Managed Redis utilizza lo stesso stack software di Azure Cache for Redis Enterprise, quindi le applicazioni esistenti che utilizzano il livello Enterprise non devono apportare molte modifiche. L'eccezione significativa è la necessità di modificare le credenziali di connessione.

Nome host e suffisso diversi

Anche se il software principale per Azure Cache for Redis Enterprise e Azure Managed Redis è simile, il suffisso DNS per il nome host del cluster Redis è diverso. Quando si passa a Redis gestito di Azure, l'applicazione deve modificare il nome host del cluster Redis. Se si usano le chiavi di accesso per la connessione alla cache, è necessario aggiornare anche la chiave di accesso usata per connettersi alla cache.

Importante

È consigliabile aggiornare il codice che si connette alla cache. Invece di usare le chiavi di accesso, usare Microsoft Entra ID. È consigliabile usare Microsoft Entra ID anziché le chiavi di accesso.

Scelta della dimensione e dello SKU corretti per Redis Gestito di Azure

Redis gestito di Azure offre molte dimensioni di memoria e tre livelli di prestazioni. Per altre informazioni sulle dimensioni della memoria e sui livelli di prestazioni, vedere Scelta del livello corretto.

Identificare la dimensione della memoria dell'istanza esistente di Azure Cache for Redis Enterprise

Le istanze di Cache Redis Enterprise di Azure possono essere ridimensionate per fornire più memoria e più risorse di calcolo, quindi è importante prendere nota del fattore di scalabilità orizzontale per la cache. La scalabilità orizzontale è correlata anche alla capacità, che consiste essenzialmente nel numero di macchine virtuali in esecuzione nel cluster.

Per scegliere le dimensioni corrette della memoria redis gestita di Azure:

  1. Passare al portale di Azure e selezionare Panoramica dal menu delle risorse.
  2. Controllare il campo Stato nella Panoramica dell'istanza aziendale. Il campo Stato mostra le dimensioni della memoria dell'istanza di Redis Enterprise.

Si esaminerà ora un possibile scenario.

Screenshot della panoramica di una cache aziendale.

Esaminando lo stato nel riquadro Panoramica , viene visualizzato Running - Enterprise 8GB (2 x 4GB). Questa notazione indica che la cache usa attualmente uno SKU E5 Enterprise con una scala di 2, producendo una cache da 8 GB. Pertanto, è consigliabile iniziare con almeno 10 GB di cache in Azure Managed Redis.

In questo caso, usare uno dei livelli che offrono 12 GB di memoria.

SKU Tier
M10 Con ottimizzazione per la memoria
B10 Bilanciato
X10 Con ottimizzazione per il calcolo

Identificare il livello di prestazioni

È anche consigliabile prendere in considerazione se il carico di lavoro è a elevato utilizzo di memoria o a elevato utilizzo di calcolo. Se è più frequente che l'istanza Enterprise corrente esaurisca la memoria prima della CPU, il carico di lavoro è ad alta intensità di memoria. Valutare la possibilità di scegliere tra il livello di prestazioni Ottimizzato per la memoria .

Se il carico di lavoro è intensivo in termini di throughput o presenta troppa latenza, allora è intensivo di calcolo. Valutare la possibilità di scegliere tra il livello di prestazioni ottimizzato per il calcolo .

Se non si è certi, è possibile iniziare con il livello di prestazioni Bilanciato perché offre una combinazione integra di memoria e prestazioni.

Se attualmente si usa il livello Flash Di Redis Enterprise, è consigliabile scegliere il livello Ottimizzato per Flash.

Creare una nuova istanza di Redis gestita di Azure

Dopo aver scelto il livello di memoria e prestazioni per la nuova istanza di Redis gestita di Azure, è possibile creare la nuova istanza di Redis gestita di Azure. Per altre informazioni sulla creazione di una cache, vedere Avvio rapido: Creare un'istanza di Redis gestita di Azure.

Successivamente, è necessario scegliere una strategia per lo spostamento dei dati. Infine, è necessario aggiornare l'applicazione per usare la nuova cache.

Aggiornare l'app per connettersi all'istanza di Redis gestita di Azure

Dopo aver creato una nuova istanza di Redis gestita di Azure, è necessario modificare l'endpoint/il nome host Redis e la chiave di accesso nell'applicazione in modo che punti alla nuova istanza di Redis gestita di Azure. È consigliabile pubblicare questa modifica dell'endpoint durante gli orari di minore attività perché comporta un blip di connettività.

Annotazioni

Se ti connetti all'istanza Redis Enterprise esistente tramite un endpoint privato, assicurati che anche la nuova cache gestita di Azure Redis sia sottoposta a peering alla rete virtuale della tua applicazione. La nuova cache deve avere una configurazione simile a quella esistente di Redis Enterprise.

Verificare che l'applicazione sia in esecuzione come previsto e quindi eliminare l'istanza precedente di Redis Enterprise.

Spostamento dei dati dalla cache aziendale a una nuova cache Redis gestita di Azure

Quando si esegue la migrazione all'istanza di Redis gestita di Azure, è necessario prendere in considerazione il modo migliore per spostare i dati dall'istanza di Redis Enterprise esistente alla nuova istanza di Redis gestita di Azure. Se l'applicazione può tollerare la perdita di dati o ha altri meccanismi per riattivare la cache senza effetti negativi, ignorare questo passaggio e procedere con i passaggi successivi.

Se l'applicazione deve assicurarsi che i dati vengano migrati anche nella nuova istanza di Redis gestita di Azure, scegliere una delle opzioni seguenti:

Esportazione e importazione di dati con un file RDB

  • Vantaggi: mantiene lo snapshot dei dati.
  • Contro: rischio di perdita di dati se le scritture si verificano dopo lo snapshot.

Ecco la procedura di esportazione/importazione di base:

  1. Esportare RDB dalla cache Redis Enterprise esistente nell'account di archiviazione di Azure.
  2. Importare dati dall'account di archiviazione di Azure in una nuova cache Redis gestita di Azure.
  3. Per altre informazioni sull'esportazione/importazione dei dati, vedere Importare ed esportare dati in Redis gestito di Azure.

Strategia di doppia scrittura

  • Vantaggi: tempo di inattività zero, transizione sicura.
  • Cons: richiede la configurazione temporanea della doppia cache.

Ecco la procedura di base per la doppia scrittura:

  1. Modificare l'applicazione per scrivere sia nella cache di Azure per Redis Enterprise esistente che nella nuova cache Redis Gestito di Azure.
  2. Continuare a leggere e scrivere dalla cache di Redis Enterprise.
  3. Dopo una sincronizzazione sufficiente dei dati, commutare le letture su Azure Managed Redis ed eliminare l'istanza di Redis Enterprise.

Migrazione a livello di codice tramite RIOT-X

RIOT-X consente di eseguire la migrazione del contenuto da Enterprise a Redis gestito di Azure. Per altre informazioni, vedere Migrazione dei dati con RIOT-X per Redis gestito di Azure.

  • Pro: controllo completo, personalizzabile.
  • Contro: richiede uno sforzo di sviluppo.

Vantaggi del passaggio da cache Basic, Standard o Premium a Redis gestito di Azure

Se si usa uno degli SKU OSS, Basic, Standard o Premium, il passaggio a Redis gestito di Azure offre più funzionalità a ogni livello della cache.

Ecco una tabella che confronta le funzionalità di Cache Redis di Azure con le funzionalità di Azure Managed Redis

Descrizione della funzionalità Basic
OSS
Normale
OSS
Di alta qualità
OSS
Bilanciato
AMR
Con ottimizzazione per la memoria
AMR
Con ottimizzazione per il calcolo
AMR
Disponibilità Non disponibile 99,9% 99,9% Fino a 99,999% Fino a 99,999% Fino a 99,999%
Crittografia di dati in transito
Isolamento della rete
Aumento/ampliamento delle prestazioni
Riduzione/bilanciamento delle prestazioni NO NO NO
Clustering di software open source NO NO
Salvataggio permanente dei dati NO NO
Ridondanza della zona NO Sì (anteprima)
Replica geografica NO NO Sì (passivo) Sì (attivo) Sì (attivo) Sì (attivo)
Log di controllo della connessione NO NO Sì (basato su eventi) Sì (basato su eventi) Sì (basato su eventi)
Moduli Redis NO NO NO
Importazione/Esportazione NO NO
Riavvio NO NO NO
Aggiornamenti pianificati NO NO NO
Autenticazione dell'ID Microsoft Entra
Controllo degli accessi in base al ruolo di Microsoft Entra ID NO NO NO
Notifica keyspace NO NO NO
Disponibilità non elevata Non disponibile NO NO

OSS fa riferimento a Cache Redis di Azure
AMR fa riferimento a Redis gestito di Azure

Ecco alcune altre differenze da considerare quando si implementa Redis gestito di Azure. Prendere in considerazione queste modifiche all'applicazione client:

Descrizione della funzionalità Cache di Azure per Redis Redis Gestito di Azure
Suffisso DNS (solo per il cloud PROD) .redis.cache.windows.net <region>.redis.azure.net
Porta TLS 6380 10.000
Porta non TLS 6379 Non supportato
Porte TLS a nodo singolo 13XXX 85xx
Porta non TLS a nodo singolo 15XXX Non supportato
Supporto del clustering Modalità di clustering OSS Modalità del cluster OSS e Enterprise
Comandi non supportati Comandi non supportati Comandi a più chiavi
Disponibilità regionale Tutte le aree di Azure * Vedere l'elenco delle aree dopo questa sezione.
Versione di Redis 6 7.4
Versioni di TLS supportate 1.2 e 1.3 1.2 e 1.3

Eseguire la migrazione della cache Basic, Standard o Premium in Azure Managed Redis

In base alla tabella, ecco alcune mappature tra gli SKU di Azure Cache per Redis e le opzioni per le cache in Redis gestito su Azure.

Annotazioni

Usare l'opzione non a disponibilità elevata di Redis gestita di Azure per la migrazione di SKU di base

Cache di Azure per Redis Redis Gestito di Azure Memoria aggiuntiva (%)
Base/Standard - C0 Bilanciato - B0 50
Basic/Standard - C1 Bilanciato - B1 0
Basic/Standard - C2 Bilanciato - B3 17
Basic/Standard - C3 Bilanciato - B5 0
Base/Standard - C4 Ottimizzato per la memoria - M10* -8
Basic/Standard - C4 Ottimizzato per la memoria - M20** 46
Basico/Standard - C5 Ottimizzato per la memoria - M20* -8
Basic/Standard - C5 Ottimizzato per la memoria - M50** 57
Base/Standard - C6 Ottimizzato per la memoria - M50 12
Premium - P1 Bilanciato - B5 0
Premium - P2 Bilanciato - B10* -8
Premium - P2 Bilanciato - B20** 46
Premium P3 Bilanciato - B20* -8
Premium P3 Bilanciato - B50** 57
Premium P4 Bilanciato - B50 12
Premium - P5 Bilanciato - B100 0
  • * Questa opzione è per l'efficienza dei costi. Verificare che il picco di memoria totale usata nell'ultimo mese sia inferiore alla memoria Redis gestita di Azure consigliata per scegliere questa opzione.
  • ** Questa opzione è per un consumo di memoria abbondante.

Cache di Azure per Redis Premium in cluster

  • Per il cluster partizionato, scegliere un livello ottimizzato per la memoria con memoria totale equivalente.
  • Per i cluster con più repliche in lettura, scegliere un livello ottimizzato per il calcolo con memoria totale equivalente come replica primaria.

Opzioni di migrazione

Le applicazioni client devono essere in grado di usare un'istanza di Redis gestita di Azure con modalità e endpoint di clustering diversi. Cache Redis di Azure e Redis gestita di Azure sono compatibili, quindi per la maggior parte degli scenari non sono necessarie modifiche al codice dell'applicazione diverse dalle configurazioni di connessione.

Per altre informazioni, vedere:

Opzioni per la migrazione di Cache Redis di Azure a Redis gestito di Azure

Opzione Vantaggi Svantaggi
Creare una nuova cache Più semplice da implementare. È necessario ripopolare i dati nella nuova cache, che potrebbe non funzionare con molte applicazioni.
Esportare e importare dati tramite file RDB Compatibile con qualsiasi cache Redis in genere. Alcuni dati potrebbero andare persi, se vengono scritti nella cache esistente dopo la generazione del file RDB.
Dati con doppia scrittura in due cache Senza perdita di dati e tempi di inattività Operazioni ininterrotte della cache esistente. Test più semplici della nuova cache. Richiede due cache per un lungo periodo di tempo.
Eseguire la migrazione dei dati a livello di codice Controllo completo sulla modalità di spostamento dei dati. Richiede codice personalizzato.

Creare una nuova cache di Azure per Redis

Questo approccio tecnicamente non è una migrazione. Se la perdita di dati non è un problema, il modo più semplice per passare al livello Redis gestito di Azure consiste nel creare una nuova istanza della cache e connetterla all'applicazione. Ad esempio, se si usa Redis come cache look-aside dei record di database, è possibile ricompilare facilmente la cache da zero. I passaggi generali per implementare questa opzione sono:

  1. Creare una nuova istanza di Redis gestita di Azure.
  2. Aggiornare l'applicazione per usare la nuova istanza.
  3. Eliminare l'istanza precedente di Cache Redis di Azure.

Esportare i dati in un file RDB e importarli in Redis gestito di Azure

Questa opzione è applicabile solo alle cache di livello Premium. Redis open source definisce un meccanismo standard per la creazione di uno snapshot del set di dati in memoria di una cache e salvarlo in un file. Un'altra cache Redis può leggere il file RDB esportato. Cache di Azure per Redis livello Premium supporta l'esportazione di dati da un'istanza della cache tramite file RDB. È possibile usare un file RDB per trasferire i dati da un'istanza di Cache Redis di Azure esistente all'istanza di Redis gestita di Azure.

I passaggi generali per implementare questa opzione sono:

  1. Creare una nuova istanza di Redis gestita di Azure con le stesse dimensioni (o maggiore di) dell'istanza di Cache Redis di Azure esistente.
  2. Esportare il file RDB dall'istanza esistente di Cache Redis di Azure usando queste istruzioni di esportazione o il cmdlet di esportazione di PowerShell
  3. Importare il file RDB nella nuova istanza di Redis gestita di Azure usando queste istruzioni di importazione o il cmdlet di importazione di PowerShell
  4. Aggiornare l'applicazione per usare la nuova stringa di connessione dell'istanza di Redis gestita di Azure.

Scrivere in due cache Redis contemporaneamente durante il periodo di migrazione

Invece di spostare direttamente i dati tra le cache, è possibile usare l'applicazione per scrivere dati sia in una cache esistente che in una nuova che si sta configurando. L'applicazione legge ancora i dati dalla cache esistente inizialmente. Quando la nuova cache contiene i dati necessari, si passa l'applicazione su tale cache e si ritira quella precedente. Si supponga, ad esempio, di usare Redis come archivio sessioni e che le sessioni dell'applicazione siano valide per sette giorni. Dopo aver scritto nelle due cache per una settimana, si sarà certi che la nuova cache contenga tutte le informazioni di sessione non scadute. Da questo momento in poi vi si può fare affidamento senza preoccuparsi della perdita di dati.

I passaggi generali per implementare questa opzione sono:

  1. Creare una nuova istanza di Redis gestita di Azure con le stesse dimensioni dell'istanza di Cache Redis di Azure esistente o superiore a quella esistente.
  2. Modificare il codice dell'applicazione per scrivere sia nell’istanza nuova che in quella originale.
  3. Continuare a leggere i dati dall'istanza originale fino a quando la nuova istanza non viene sufficientemente popolata con i dati.
  4. Aggiornare il codice dell'applicazione per leggere e scrivere solo dalla nuova istanza.
  5. Eliminare l'istanza originale.

Eseguire la migrazione a livello di programmazione

Creare un processo di migrazione personalizzato leggendo i dati a livello di codice da un'istanza di Cache Redis di Azure esistente e scrivendoli nell'istanza di Redis gestita di Azure. Sono disponibili due strumenti open source che è possibile provare:

  • Redis-copy
    • Questo strumento open source può essere usato per copiare dati da un'istanza di Cache Redis di Azure a un'altra. Questo strumento è utile per lo spostamento dei dati tra istanze della cache in aree di Cache di Azure diverse. È disponibile anche una versione compilata. È anche possibile trovare il codice sorgente per essere una guida utile per la scrittura di uno strumento di migrazione personalizzato.
  • RIOT
    • RIOT è un altro strumento di migrazione diffuso testato dalla community di Redis. Si tratta di un'utilità della riga di comando progettata per consentire l'accesso e l'uscita dei dati da Redis.

Annotazioni

Questo strumento non è ufficialmente supportato da Microsoft.

I passaggi generali per implementare questa opzione sono:

  1. Creare una macchina virtuale nell'area in cui si trova la cache esistente. Se il set di dati è di grandi dimensioni, scegliere una macchina virtuale relativamente potente per ridurre il tempo necessario per copiarlo.
  2. Creare una nuova istanza di Redis gestita di Azure.
  3. Scaricare i dati dalla nuova cache per assicurarsi che sia vuota. Questo passaggio è obbligatorio perché lo strumento di copia stesso non sovrascrive alcuna chiave esistente nella cache di destinazione. Importante: assicurarsi di NON scaricare dalla cache di origine.
  4. Usare un'applicazione come lo strumento open source menzionato in precedenza per automatizzare la copia dei dati dalla cache di origine alla destinazione. Tenere presente che il processo di copia potrebbe richiedere del tempo a seconda delle dimensioni del set di dati.

Disponibilità a livello di area per Azure Managed Redis

Redis Gestito di Azure si espande continuamente in nuove aree. Per verificare la disponibilità di un prodotto in base all'area geografica, vedere Prodotti disponibili in base all'area geografica.