Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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
- Vantaggi del passaggio da cache Basic, Standard o Premium a Redis gestito 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ì | Sì (impostazione predefinita) |
| Modalità non a disponibilità elevata | NO | Sì (per sviluppo/test) |
| Salvataggio permanente dei dati | Sì (in anteprima) | Sì |
| Scaling | Sì | Sì |
| Supporto della versione di TLS | 1.2,1.3 | 1.2,1.3 |
| Autenticazione dell'ID Microsoft Entra | NO | Sì |
| 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:
- Passare al portale di Azure e selezionare Panoramica dal menu delle risorse.
- 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.
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:
- Esportare RDB dalla cache Redis Enterprise esistente nell'account di archiviazione di Azure.
- Importare dati dall'account di archiviazione di Azure in una nuova cache Redis gestita di Azure.
- 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:
- Modificare l'applicazione per scrivere sia nella cache di Azure per Redis Enterprise esistente che nella nuova cache Redis Gestito di Azure.
- Continuare a leggere e scrivere dalla cache di Redis Enterprise.
- 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 | Sì | Sì | Sì | Sì | Sì | Sì |
| Isolamento della rete | Sì | Sì | Sì | Sì | Sì | Sì |
| Aumento/ampliamento delle prestazioni | Sì | Sì | Sì | Sì | Sì | Sì |
| Riduzione/bilanciamento delle prestazioni | Sì | Sì | Sì | NO | NO | NO |
| Clustering di software open source | NO | NO | Sì | Sì | Sì | Sì |
| Salvataggio permanente dei dati | NO | NO | Sì | Sì | Sì | Sì |
| Ridondanza della zona | NO | Sì (anteprima) | Sì | Sì | Sì | Sì |
| Replica geografica | NO | NO | Sì (passivo) | Sì (attivo) | Sì (attivo) | Sì (attivo) |
| Log di controllo della connessione | NO | NO | Sì | Sì (basato su eventi) | Sì (basato su eventi) | Sì (basato su eventi) |
| Moduli Redis | NO | NO | NO | Sì | Sì | Sì |
| Importazione/Esportazione | NO | NO | Sì | Sì | Sì | Sì |
| Riavvio | Sì | Sì | Sì | NO | NO | NO |
| Aggiornamenti pianificati | Sì | Sì | Sì | NO | NO | NO |
| Autenticazione dell'ID Microsoft Entra | Sì | Sì | Sì | Sì | Sì | Sì |
| Controllo degli accessi in base al ruolo di Microsoft Entra ID | Sì | Sì | Sì | NO | NO | NO |
| Notifica keyspace | Sì | Sì | Sì | NO | NO | NO |
| Disponibilità non elevata | Non disponibile | NO | NO | Sì | Sì | Sì |
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:
- Creare una nuova istanza di Redis gestita di Azure.
- Aggiornare l'applicazione per usare la nuova istanza.
- 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:
- Creare una nuova istanza di Redis gestita di Azure con le stesse dimensioni (o maggiore di) dell'istanza di Cache Redis di Azure esistente.
- Esportare il file RDB dall'istanza esistente di Cache Redis di Azure usando queste istruzioni di esportazione o il cmdlet di esportazione di PowerShell
- Importare il file RDB nella nuova istanza di Redis gestita di Azure usando queste istruzioni di importazione o il cmdlet di importazione di PowerShell
- 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:
- 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.
- Modificare il codice dell'applicazione per scrivere sia nell’istanza nuova che in quella originale.
- Continuare a leggere i dati dall'istanza originale fino a quando la nuova istanza non viene sufficientemente popolata con i dati.
- Aggiornare il codice dell'applicazione per leggere e scrivere solo dalla nuova istanza.
- 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:
- 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.
- Creare una nuova istanza di Redis gestita di Azure.
- 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.
- 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.