Comprendere le differenze: livelli Basic, Standard e Premium rispetto a Redis gestiti di Azure

Prima di eseguire la migrazione, esaminare le differenze principali tra Cache Redis di Azure e Azure Managed Redis in modo da poter pianificare in modo efficace.

Perché Azure Managed Redis è più efficiente

Redis gestito di Azure si basa sullo stack di software Redis Enterprise, che offre miglioramenti significativi delle prestazioni rispetto ai livelli Redis open source usati dai livelli Basic, Standard e Premium. Redis Enterprise usa un'architettura multithread che può gestire più operazioni al secondo, offrire latenze inferiori e usare in modo più efficiente l'hardware sottostante. Ciò significa che per la stessa quantità di memoria e calcolo, Azure Managed Redis può offrire una velocità effettiva notevolmente superiore rispetto alla cache di livello Basic, Standard o Premium equivalente.

Inoltre, Azure Managed Redis supporta strutture di dati avanzate tramite moduli Redis (ad esempio RediSearch, RedisJSON e RedisBloom) che non sono disponibili nei livelli Basic, Standard o Premium. Per altre informazioni sull'architettura, vedere Architettura di Redis gestita di Azure.

Principali differenze di funzionalità/funzionalità

Ecco le differenze importanti da tenere presenti quando si passa da Basic, Standard o Premium a Redis gestito di Azure:

• Struttura SKU. Azure Managed Redis organizza gli SKU in modo diverso rispetto ad Azure Cache for Redis. Anziché gli SKU basati su livelli (Basic, Standard, Premium) in cui le funzionalità variano in base al livello, gli SKU Redis gestiti di Azure si basano su due dimensioni: dimensioni della memoria e livello di prestazioni (bilanciato, ottimizzato per la memoria o ottimizzato per il calcolo). Tutte le funzionalità di disponibilità elevata e ripristino di emergenza (HADR), incluse la ridondanza della zona, la persistenza dei dati, la replica geografica e l'importazione/esportazione, sono disponibili in tutti i livelli di prestazioni e dimensioni. Non è più necessario scegliere uno SKU di livello superiore solo per accedere a queste funzionalità.

• Disponibilità elevata e disponibilità non elevata. Azure Managed Redis offre la possibilità di eseguire la distribuzione con o senza disponibilità elevata. L'opzione non ad alta disponibilità è progettata per carichi di lavoro non di produzione e di sviluppo/test per ridurre i costi. Le istanze non-HA non prevedono un SLA e comportano il rischio di perdita di dati durante la manutenzione. Al contrario, i livelli Basic, Standard e Premium non offrono questa flessibilità: Basic non ha HA, mentre Standard e Premium lo includono sempre.

• Raggruppamento. Redis gestito di Azure è cluster per impostazione predefinita e offre due criteri di clustering: clustering OSS e clustering aziendale. È consigliabile scegliere il clustering OSS per ottenere prestazioni ottimali. Se si usa attualmente una cache Basic o Standard non cluster, la configurazione della libreria client Redis potrebbe richiedere modifiche per funzionare con un'istanza in cluster, ad esempio la gestione dei MOVED reindirizzamenti tramite una libreria client compatibile con cluster. Se l'applicazione richiede assolutamente un'istanza non cluster, Azure Managed Redis offre una modalità non cluster per le cache fino a 25 GB.

• Isolamento della rete. Redis gestito di Azure non supporta l'inserimento della rete virtuale e la configurazione delle regole del firewall basate su IP. Se l'istanza di Cache Redis di Azure esistente usa l'inserimento della rete virtuale per l'isolamento della rete, è necessario passare all'uso del collegamento privato di Azure con la nuova istanza di Redis gestita di Azure.

• Scalabilità. Azure Managed Redis supporta la modifica delle dimensioni della memoria e del livello di prestazioni.

• Microsoft Entra ID. Entrambi i servizi supportano l'autenticazione di Microsoft Entra ID. Tuttavia, Azure Managed Redis non supporta attualmente il RBAC di Microsoft Entra ID.

• Aggiornamenti pianificati. Cache Redis di Azure supporta la configurazione di una finestra di aggiornamento pianificata per gli aggiornamenti del motore Redis. Azure Managed Redis supporta gli aggiornamenti pianificati attualmente in anteprima.

• Supporto delle porte TLS e non TLS. Nei livelli Basic, Standard e Premium di Cache Redis di Azure, la stessa istanza della cache può supportare simultaneamente le connessioni TLS (porta 6380) e testo normale (porta 6379), consentendo alle diverse applicazioni di connettersi con entrambe le modalità. In Redis gestito di Azure la cache supporta una sola modalità alla volta, ovvero TLS o non TLS. Dopo aver scelto la modalità durante la creazione della cache, tutte le applicazioni che si connettono a tale cache devono usare la stessa modalità.

• Ridondanza delle zone. Azure Managed Redis è ridondante per zona per impostazione predefinita quando è abilitata l'alta disponibilità e la regione è supportata da più zone di disponibilità. In confronto, la ridondanza della zona è disponibile solo nel livello "Premium" (e in anteprima per lo "Standard").

• Database. I livelli Basic, Standard e Premium supportano più database Redis (fino a 16 per impostazione predefinita, configurabili fino a 64 su Premium). Azure Managed Redis supporta solo un database singolo (database 0). Se l'applicazione usa più database, è necessario effettuare il refactoring del modello di dati per usare un singolo database o usare prefissi chiave per separare logicamente i dati prima della migrazione.

• Replica geografica. Azure Managed Redis supporta la replica geografica attiva, che consente operazioni di lettura e scrittura tra cache collegate in aree diverse. Il livello Premium supporta solo la replica geografica passiva, in cui la cache secondaria è di sola lettura. A differenza di Cache Redis di Azure, Azure Managed Redis non supporta un comando di failover esplicito. Al contrario, l'applicazione deve passare a un'istanza redis gestita di Azure con replica geografica diversa quando rileva che una delle aree è inattiva.

• Persistenza dei dati. Azure Managed Redis supporta la persistenza dei dati in tutti gli SKU. In Cache Redis di Azure la persistenza è disponibile solo nel livello Premium.

• Moduli Redis. Redis gestito di Azure supporta moduli Redis come RediSearch, RedisJSON, RedisBloom e RedisTimeSeries. Questi moduli non sono disponibili nei livelli Basic, Standard o Premium.

• IImportazione/Esportazione. Redis gestito di Azure supporta l'importazione e l'esportazione di RDB in tutti gli SKU. In Cache Redis di Azure questa funzionalità è disponibile solo nel livello Premium.

• Notifiche dello spazio chiave. Le notifiche keyspace sono supportate in Cache Redis di Azure, ma non sono attualmente disponibili in Redis gestito di Azure.

• Riavvia. Cache Redis di Azure supporta il riavvio manuale dei nodi della cache. Questa operazione non è disponibile in Azure Managed Redis, che gestisce automaticamente le operazioni del nodo. Se si usa Reboot per scaricare i dati dalla cache, Azure Managed Redis offre Flush come operazione di gestione. Le API Redis gestite di Azure per simulare gli eventi di manutenzione per testare la resilienza delle applicazioni sono nella roadmap.

Differenze principali per le applicazioni client

Esaminare queste differenze durante la pianificazione degli aggiornamenti dell'applicazione:

Scegliere la dimensione e lo SKU corretto di Redis gestito di Azure

La scelta dello SKU Redis gestito di Azure appropriato prevede due passaggi: la selezione delle dimensioni di memoria appropriate e la selezione del livello di prestazioni corretto.

Passaggio A: Scegliere le dimensioni di memoria corrette

1. Identificare le dimensioni della memoria cache corrente. Passare al portale di Azure, aprire la cache Basic, Standard o Premium e prendere nota delle dimensioni della memoria nella pagina Panoramica , ad esempio C3 = 13 GB, P2 = 13 GB.

1. Trova uno SKU di dimensioni simili in Azure Managed Redis. Cercare uno SKU di Redis gestito di Azure che offre la stessa o maggiore quantità di memoria utilizzabile. Quando si confrontano le dimensioni, si noti che Azure Managed Redis riserva circa 20% di memoria per le operazioni di sistema e il sovraccarico. Tenere conto di questa prenotazione quando si seleziona una dimensione, ad esempio gli SKU B10/M10/X10 offrono 12 GB di memoria totale, ma circa 9,6 GB di memoria utilizzabile per i dati dopo la prenotazione.

2. Ottimizzare in base all'utilizzo effettivo della memoria. Invece di corrispondere alle dimensioni della cache nominale, esaminare la metrica Memoria usata nella cache esistente in Azure Monitor. Controllare il picco di utilizzo della memoria nell'ultimo mese per identificare uno SKU più appropriato. Se l'utilizzo effettivo della memoria è ben inferiore alle dimensioni della cache, è possibile selezionare uno SKU Redis gestito di Azure più piccolo e conveniente.

Passaggio B: Scegliere il livello di prestazioni corretto

Azure Managed Redis offre tre livelli di prestazioni: bilanciati, ottimizzati per la memoria e ottimizzati per il calcolo. Selezionare in base alle caratteristiche del carico di lavoro:

• Bilanciato : un buon punto di partenza se non sei sicuro. Offre una combinazione integra di memoria e calcolo.
• Ottimizzata per la memoria: scegliere questa opzione se il carico di lavoro richiede un utilizzo elevato di memoria ed è più probabile che esaurisca la memoria prima della CPU.
• Ottimizzato per il calcolo: scegliere questa opzione se il carico di lavoro è a elevato utilizzo di velocità effettiva o sensibile alla latenza.

Per altre informazioni, vedere Scelta del livello corretto.

Considerazioni aggiuntive

• Disabilitare la disponibilità elevata per le migrazioni di livello Basic. Se si esegue la migrazione da una cache Basic (senza replica o contratto di servizio), disabilitare la disponibilità elevata nella nuova istanza di Redis gestita di Azure. In questo modo si riduce il costo e viene fornita una configurazione paragonabile per i carichi di lavoro di sviluppo/test.

Passo successivo

Contenuti correlati

• Panoramica sulla migrazione
• Che cos'è Redis gestito di Azure?
• Architettura di Redis gestita di Azure