Architettura di Redis gestito di Azure

Redis gestito di Azure viene eseguito nello stack Redis Enterprise , che offre vantaggi significativi rispetto all'edizione community di Redis. Le informazioni seguenti forniscono maggiori dettagli sul modo in cui Redis Gestito di Azure è progettato, incluse le informazioni che possono essere utili per gli utenti esperti.

Confronto con cache di Azure per Redis

I livelli Basic, Standard e Premium di Cache Redis di Azure vengono eseguiti nell'edizione community di Redis. Questa edizione community di Redis presenta diverse limitazioni significative, tra cui la modalità a thread singolo. Questa limitazione riduce significativamente le prestazioni e rende il ridimensionamento meno efficiente perché il servizio non usa completamente più vCPU. Un'istanza di cache di Azure per Redis tipica usa un'architettura simile alla seguente:

Si noti che vengono usate due macchine virtuali: una primaria e una replica. Queste macchine virtuali sono dette anche nodi. Il nodo primario contiene il processo Redis principale e accetta tutte le scritture. La replica viene eseguita in modo asincrono nel nodo di replica per fornire una copia di backup durante la manutenzione, il ridimensionamento o un errore imprevisto. Ogni nodo può eseguire un singolo processo del server Redis a causa della progettazione a thread singolo di Redis della community.

Miglioramenti dell'architettura di Azure Managed Redis

Redis Gestito di Azure usa un'architettura più avanzata simile alla seguente:

Esistono varie differenze:

• Ogni macchina virtuale (o nodo) esegue più processi del server Redis (denominati partizioni) in parallelo. Più partizioni consentono un utilizzo più efficiente delle vCPU in ogni macchina virtuale e prestazioni superiori.
• Non tutte le partizioni Redis primarie si trovano nello stesso nodo/macchina virtuale. Le partizioni primarie e di replica vengono invece distribuite in entrambi i nodi. Poiché le partizioni primarie usano più risorse della CPU rispetto alle partizioni di replica, questo approccio consente l'esecuzione in parallelo di più partizioni primarie.
• Ogni nodo ha un processo proxy ad alte prestazioni per gestire le partizioni, gestire la gestione delle connessioni e attivare la riparazione automatica.

Questa architettura consente prestazioni più elevate e funzionalità avanzate, ad esempio la replica geografica attiva.

Raggruppamento

Ogni istanza di Redis gestita di Azure è configurata internamente per l'uso del clustering in tutti i livelli e gli SKU. Redis gestito di Azure si basa su Redis Enterprise, che può usare più partizioni per nodo. Questa funzionalità include istanze più piccole configurate solo per l'uso di una singola partizione. Il clustering è un modo per dividere i dati nell'istanza di Redis tra più processi Redis, detti anche partizionamento orizzontale. Redis gestito di Azure offre tre criteri del cluster che determinano il protocollo disponibile per i client Redis per la connessione all'istanza della cache.

Politiche di cluster

Redis gestito di Azure offre tre criteri di clustering: OSS, Enterprise e Non cluster. I criteri del cluster OSS sono validi per la maggior parte delle applicazioni perché supportano una velocità effettiva massima più elevata, ma ogni versione presenta vantaggi e svantaggi specifici.

• Se si passa da una topologia non cluster Basic, Standard o Premium, è consigliabile usare il clustering OSS per migliorare le prestazioni. Usare configurazioni non cluster solo se l'applicazione non può supportare topologie OSS o Enterprise. I criteri di clustering OSS implementano la stessa API del software Redis open source. L'API cluster Redis consente al client Redis di connettersi direttamente alle partizioni in ogni nodo Redis, riducendo al minimo la latenza e ottimizzando la velocità effettiva di rete. Il throughput scala quasi linearmente con l'aumentare del numero di partizioni e delle vCPU. La politica di clustering OSS offre generalmente la latenza più bassa e le migliori prestazioni di larghezza di banda. Tuttavia, i criteri del cluster OSS richiedono la libreria client per supportare l'API cluster Redis. Attualmente, quasi tutti i client Redis supportano l'API Cluster Redis, ma la compatibilità potrebbe essere un problema per le versioni client precedenti o librerie specializzate.

Non è possibile usare i criteri di clustering OSS con il modulo RediSearch.

Il protocollo di clustering oss richiede al client di stabilire le connessioni di partizione corrette. La connessione iniziale è tramite la porta 10000. La connessione a singoli nodi usa porte nell'intervallo 85XX. Le porte 85xx possono cambiare nel tempo e non dovresti impostarle in modo fisso nell'applicazione. I client Redis che supportano il clustering usano il comando CLUSTER NODES per determinare le porte esatte usate per le partizioni primarie e di replica e stabilire automaticamente le connessioni di partizione.

I criteri di clustering aziendale sono una configurazione più semplice che usa un singolo endpoint per tutte le connessioni client. Quando si usano i criteri di clustering aziendale, instrada tutte le richieste a un singolo nodo Redis che funge da proxy. Questo nodo indirizza internamente le richieste al nodo corretto nel cluster. Il vantaggio di questo approccio è che rende Redis Gestito di Azure non raggruppato in cluster per gli utenti. Ciò significa che le librerie client Redis non devono supportare il clustering Redis per ottenere alcuni dei vantaggi in termini di prestazioni di Redis Enterprise. L'uso di un singolo endpoint aumenta la compatibilità con le versioni precedenti e semplifica la connessione. Lo svantaggio è che il proxy a nodo singolo può essere un collo di bottiglia nell'utilizzo di calcolo o nella velocità effettiva di rete.

Il criterio di clustering dell'enterprise è l'unico che si può utilizzare con il modulo RediSearch. Anche se i criteri di cluster Enterprise fanno apparire un'istanza di Redis gestita di Azure come non raggruppata agli utenti, presenta ancora alcune limitazioni con i comandi a più chiavi.

Il criterio di clustering Non raggruppato in cluster archivia i dati in ogni nodo senza sharding. Si applica solo alle cache di dimensioni pari a 25 GB e dimensioni inferiori. Gli scenari per l'uso della politica di clustering non clusterizzata includono:

• Quando si esegue la migrazione da un ambiente Redis non shardato. Ad esempio, le topologie non suddivise in shard degli SKU Basic, Standard e Premium di Azure Cache per Redis.
• Quando si eseguono comandi tra slot in modo esteso e dividendo i dati in partizioni, si verificherebbero errori. Ad esempio, i comandi MULTI.
• Quando si usa Redis come broker di messaggi e non è necessario partizionamento orizzontale.

Le considerazioni per l'uso della politica non cluster sono:

• Questo criterio si applica solo ai livelli redis gestiti di Azure minori o uguali a 25 GB.
• Non è altrettanto efficiente di altri criteri di clustering, perché le CPU possono eseguire il multithreading solo con il software Redis Enterprise quando la cache è partizionata.
• Se si vuole aumentare le prestazioni della cache Redis gestita di Azure, è prima necessario modificare i criteri del cluster.
• Se si passa da una topologia non cluster Basic, Standard o Premium, è consigliabile usare cluster OSS per migliorare le prestazioni. Usare configurazioni non cluster solo se l'applicazione non può supportare topologie OSS o Enterprise.

Aumento o aggiunta di nodi

Il software centrale di Redis Enterprise si espande utilizzando macchine virtuali con risorse maggiori o si distribuisce aggiungendo più nodi o macchine virtuali. Entrambe le opzioni di ridimensionamento aggiungono più memoria, più vCPU e più partizioni. A causa di questa ridondanza, Azure Managed Redis non offre la possibilità di controllare il numero specifico di nodi usati in ogni configurazione. Questo dettaglio di implementazione è astratto per evitare confusione, complessità e configurazioni non ottimali. Ogni SKU è invece progettato con una configurazione del nodo che ottimizza le vCPU e la memoria. Alcuni SKU di Azure Managed Redis usano due nodi, mentre altri usano di più.

Comandi a più chiavi

Poiché le istanze di Redis gestite di Azure usano una configurazione in cluster, è possibile che vengano visualizzate CROSSSLOT eccezioni sui comandi che operano su più chiavi. Il comportamento varia a seconda dei criteri di clustering usati. Se si usa la politica di clustering OSS, tutte le chiavi nei comandi multichiave devono essere mappate allo stesso slot hash.

È inoltre possibile che vengano visualizzati errori CROSSSLOT con criteri di clustering Enterprise. Solo i comandi multichiave seguenti sono consentiti tra slot con clustering enterprise: DEL, MSET, MGET, EXISTS, UNLINK e TOUCH.

Nei database Active-Active, i comandi di scrittura multichiave (DEL, MSET, UNLINK) possono essere eseguiti solo su chiavi che si trovano nello stesso slot. Tuttavia, i comandi multichiave seguenti sono consentiti tra gli slot nei database Active-Active: MGET, EXISTSe TOUCH. Per altre informazioni, vedere Clustering del database.

Configurazione del partizionamento orizzontale

Ogni SKU di Redis gestito di Azure esegue un numero specifico di processi del server Redis, denominati shard, in parallelo. La relazione tra le prestazioni della velocità effettiva, il numero di partizioni e il numero di vCPU disponibili in ogni istanza è complessa. Non è possibile modificare manualmente il numero di partizioni.

Per una determinata dimensione di memoria, la versione ottimizzata per la memoria ha il minor numero di vCPU e partizioni, mentre la versione ottimizzata per il calcolo ha il valore più alto.

L'aumento del numero di partizioni aumenta in genere le prestazioni man mano che le operazioni Redis possono essere eseguite in parallelo. Tuttavia, se non sono disponibili vCPU per eseguire comandi, le prestazioni possono essere ridotte.

Le partizioni vengono mappate per ottimizzare l'utilizzo di ogni vCPU riservando cicli vCPU per il processo del server Redis, l'agente di gestione e le attività del sistema operativo che influiscono anche sulle prestazioni. Le applicazioni client che crei interagiscono con Azure Managed Redis come se fosse un singolo database logico. Il servizio gestisce il routing tra le vCPU e le partizioni.

Per aumentare il numero di partizioni in uno SKU, usare un livello più ampio in tale SKU. È anche possibile modificare gli SKU in base alle esigenze di prestazioni.

Nella tabella seguente viene illustrato il rapporto tra vCPU e partizioni primarie a una determinata dimensione del livello. I dati nelle colonne non rappresentano una garanzia che si tratti del numero di vCPU o di shard. Le tabelle sono solo per l'illustrazione.

Annotazioni

Redis gestito di Azure ottimizza le prestazioni nel tempo modificando il numero di partizioni e vCPU usate in ogni SKU.

Versioni ottimizzate per la memoria, bilanciate e ottimizzate per il calcolo

Questa tabella mostra un esempio generale della relazione tra Dimensioni e vCPU/partizioni primarie.

Piani	Con ottimizzazione per la memoria	Bilanciato	Con ottimizzazione per il calcolo
Dimensioni (GB)	vCPU/partizioni primarie	vCPU/partizioni primarie	vCPU/partizioni primarie
24 ¹	4/2	8/6	16/12
60 ¹	8/6	16/12	32/24

¹ Il rapporto tra vCPU e partizioni primarie per una specifica dimensione di livello non rappresenta una garanzia per lo SKU né per il livello.

Versione ottimizzata per Flash

Questa tabella mostra un esempio generale della relazione tra Dimensioni e vCPU/partizioni primarie.

Piani	Flash Optimized (anteprima)
Dimensioni (GB)	vCPU/partizioni primarie
480 ¹ ²	16/12
720 ¹ ²	24 ore su 24

¹ Questi livelli sono in anteprima pubblica.

² Il rapporto tra vCPU e partizioni primarie a una determinata dimensione del livello non rappresenta una garanzia per lo SKU o il livello.

Importante

Tutti i livelli in memoria che usano più di 235 GB di spazio di archiviazione sono disponibili in anteprima pubblica, inclusi M350 ottimizzati per la memoria e versioni successive; B350 bilanciato e superiore; e Compute Optimized X350 e versioni successive. Tutti questi livelli e versioni successive sono disponibili in anteprima pubblica.

Tutti i livelli con ottimizzazione flash sono disponibili in anteprima pubblica.

Esecuzione senza la modalità a disponibilità elevata abilitata

È possibile eseguire senza la modalità a disponibilità elevata abilitata. Questa configurazione significa che l'istanza di Redis non ha la replica abilitata e non ha accesso al contratto di servizio di disponibilità. All'esterno degli scenari di sviluppo e test, non eseguire in modalità a bassa disponibilità. Non è possibile disabilitare la disponibilità elevata in un'istanza già creata. È possibile abilitare l'alta disponibilità in un'istanza che non la ha. Poiché un'istanza in esecuzione senza disponibilità elevata usa meno macchine virtuali e nodi, le vCPU non vengono usate in modo efficiente, quindi le prestazioni potrebbero essere inferiori.

Memoria riservata

In ogni istanza di Redis Gestito di Azure, circa il 20% della memoria disponibile è riservato come buffer per le operazioni non in cache, ad esempio la replica durante il failover e il buffer di replica geografica attiva. Questo buffer consente di migliorare le prestazioni della cache e prevenire la fame di memoria.

Riduzione

La riduzione delle prestazioni non è attualmente supportata in Azure Managed Redis. Per altre informazioni, vedere Limitazioni del ridimensionamento di Azure Managed Redis.

Livello con ottimizzazione per Flash

Il livello Ottimizzato per Flash usa sia l'archiviazione Flash NVMe che la RAM. Poiché l'archiviazione Flash è un costo inferiore, l'uso del livello Ottimizzato per Flash consente di ridurre alcune prestazioni per ottenere un'efficienza dei prezzi.

Nelle istanze Ottimizzato per Flash il 20% dello spazio della cache è sulla RAM, mentre l'altro 80% usa l'archiviazione Flash. Tutte le chiavi vengono archiviate nella RAM, mentre i valori possono essere archiviati nell'archiviazione Flash o nella RAM. Il software Redis determina in modo intelligente la posizione dei valori. I valori ad accesso frequente vengono archiviati frequentemente nella RAM, mentre quelli ad accesso saltuario usati meno comunemente vengono mantenuti in Flash. Prima che i dati vengano letti o scritti, devono essere spostati nella RAM, diventando dati ad accesso frequente.

Poiché Redis ottimizza le prestazioni migliori, l'istanza riempie la RAM disponibile prima di aggiungere elementi all'archiviazione Flash. Il riempimento della RAM ha prima alcune implicazioni per le prestazioni:

• Prestazioni migliori e bassa latenza possono verificarsi durante i test con un utilizzo ridotto della memoria. Il test con un'istanza di cache completa può produrre prestazioni inferiori perché viene utilizzata solo la RAM durante la fase di test del basso utilizzo della memoria.
• Quando si scrivono più dati nella cache, la percentuale di dati nella RAM rispetto all'archiviazione Flash diminuisce, causando in genere una riduzione della latenza e delle prestazioni della velocità effettiva.

Carichi di lavoro adatti per il livello Ottimizzato per Flash

I carichi di lavoro che vengono eseguiti correttamente nel livello Con ottimizzazione flash presentano spesso le caratteristiche seguenti:

• Lettura elevata, con un rapporto elevato tra i comandi di lettura e la scrittura dei comandi.
• Accesso incentrato su un subset di chiavi che si usano molto più frequentemente rispetto al resto del set di dati.
• Valori relativamente grandi rispetto ai nomi delle chiavi. (poiché i nomi delle chiavi vengono sempre archiviati nella RAM, i valori di grandi dimensioni possono diventare un collo di bottiglia per la crescita della memoria).

Carichi di lavoro non adatti per il livello Ottimizzato per Flash

Alcuni carichi di lavoro hanno caratteristiche di accesso meno ottimizzate per la progettazione del livello Ottimizzato per Flash:

• Carichi di lavoro con intensa attività di scrittura.
• Modelli di accesso ai dati casuali o uniformi nella maggior parte del set di dati.
• Nomi di chiave lunghi con dimensioni di valore relativamente ridotte.

Contenuti correlati

• Ridimensionare un'istanza di Redis gestita di Azure