Architettura di Redis gestita di Azure (anteprima)
Redis gestito di Azure (anteprima) 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 Azure Managed Redis è progettato, incluse le informazioni che possono essere utili per gli utenti esperti.
Importante
Azure Managed Redis è attualmente disponibile in ANTEPRIMA. Vedere le condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure per termini legali aggiuntivi che si applicano a funzionalità di Azure in versione beta, in anteprima o in altro modo non ancora disponibili a livello generale.
Confronto con cache di Azure per Redis
I livelli Basic, Standard e Premium di cache di Azure per Redis sono stati basati sull'edizione community di Redis. Questa versione di Redis presenta diverse limitazioni significative, tra cui la progettazione a thread singolo. Ciò riduce significativamente le prestazioni e rende il ridimensionamento meno efficiente perché le vCPU non vengono usate completamente dal servizio. Un'istanza di cache di Azure per Redis tipica usa un'architettura simile alla seguente:
Si noti che vengono usate due macchine virtuali, ovvero una replica 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 è in grado di eseguire un singolo processo del server Redis a causa della progettazione a thread singolo di Redis della community.
Miglioramenti dell'architettura di Redis gestito di Azure
Redis gestito di Azure usa un'architettura più avanzata simile alla seguente:
Esistono numerose differenze:
- Ogni macchina virtuale (o "node") 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 come la replica geografica attiva
Clustering
Poiché Redis Enterprise è in grado di usare più partizioni per nodo, ogni istanza di Redis gestita di Azure è configurata internamente per l'uso del clustering in tutti i livelli e gli SKU. Che 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 due criteri del cluster che determinano il protocollo disponibile per i client Redis per la connessione all'istanza della cache.
Criteri di cluster
Redis gestito di Azure offre due opzioni per i criteri di clustering: OSS ed Enterprise. I criteri del cluster OSS sono consigliati per la maggior parte delle applicazioni perché supportano una velocità effettiva massima più elevata, ma esistono vantaggi e svantaggi per ogni versione.
I criteri di clustering del sistema operativo implementano la stessa API cluster Redis di Redis dell'edizione community. 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, consentendo la velocità effettiva quasi lineare man mano che aumenta il numero di partizioni e vCPU. I criteri di clustering oss offrono in genere le migliori prestazioni di latenza e velocità effettiva. I criteri del cluster OSS, tuttavia, 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. Inoltre, i criteri di clustering OSS non possono essere utilizzati con il modulo RediSearch.
Il criterio di clustering Enterprise è una configurazione più semplice, che fa uso di un singolo endpoint per tutte le connessioni client. L'utilizzo dei criteri di clustering Enterprise indirizza tutte le richieste a un singolo nodo Redis, che viene quindi usato come proxy, indirizzando internamente le richieste al nodo corretto nel cluster. Il vantaggio di questo approccio è che rende Azure Managed Redis non cluster agli utenti. Ciò significa che le librerie client Redis non devono supportare Il clustering Redis per ottenere alcuni dei vantaggi delle prestazioni di Redis Enterprise, aumentando la compatibilità con le versioni precedenti e semplificando la connessione. Lo svantaggio è che il proxy a nodo singolo può essere un collo di bottiglia, sia nell'utilizzo di calcolo sia nella velocità effettiva di rete. Il criterio di clustering Enterprise è l'unico che può essere usato con il modulo RediSearch. Anche se i criteri del cluster enterprise rendono un'istanza di Redis gestita di Azure non cluster agli utenti, presenta ancora alcune limitazioni con i comandi a più chiavi.
Aumento o aggiunta di nodi
Il software Redis Enterprise principale è in grado di aumentare le prestazioni (usando macchine virtuali di dimensioni maggiori) o di aumentare il numero di istanze (aggiungendo più nodi/macchine virtuali). In definitiva, l'azione di ridimensionamento esegue la stessa operazione, aggiungendo 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 l'utente per evitare confusione, complessità e configurazioni non ottimali. Ogni SKU è invece progettato con una configurazione del nodo per ottimizzare le vCPU e la memoria. Alcuni SKU di Azure Managed Redis usano solo due nodi, mentre altri usano di più.
Comandi a più chiavi
Poiché le istanze di Redis gestite di Azure sono progettate con 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 usano criteri di clustering OSS, i comandi a più chiavi richiedono il mapping di tutte le chiavi allo stesso slot hash.
È inoltre possibile che vengano visualizzati errori CROSSSLOT con criteri di clustering Enterprise. Solo i comandi a più chiavi seguenti sono consentiti tra slot con clustering Enterprise: DEL, MSET, MGET, EXISTS, UNLINK e TOUCH.
Nei database Active-Active i comandi di scrittura a più chiavi (DEL, MSET, UNLINK) possono essere eseguiti solo su chiavi situate nello stesso slot. Tuttavia, i comandi a più chiavi seguenti sono consentiti tra gli slot nei database Active-Active: MGET, EXISTS e TOUCH. Per altre informazioni, vedere Clustering del database.
Configurazione del partizionamento orizzontale
Ogni SKU di Redis gestito di Azure è configurato per eseguire un numero specifico di processi del server Redis, partizioni in parallelo. La relazione tra le prestazioni della velocità effettiva, il numero di partizioni e il numero di vCPU disponibili in ogni istanza è complicata. L'aggiunta di partizioni aumenta in genere le prestazioni man mano che le operazioni Redis possono essere eseguite in parallelo. Tuttavia, se le partizioni non sono in grado di eseguire comandi perché non sono disponibili vCPU per eseguire comandi, le prestazioni possono effettivamente diminuire. La tabella seguente illustra la configurazione di partizionamento orizzontale per ogni SKU di Redis gestito di Azure. Queste partizioni vengono mappate per ottimizzare l'utilizzo di ogni vCPU riservando cicli vCPU per le attività proxy, agente di gestione e sistema operativo di Redis Enterprise che influiscono anche sulle prestazioni.
Nota
Il numero di partizioni e vCPU usate in ogni SKU può cambiare nel tempo perché le prestazioni sono ottimizzate dal team di Redis gestito di Azure.
| Livelli | Ottimizzato per Flash | Ottimizzato per la memoria | Bilanciato | Con ottimizzazione per il calcolo |
|---|---|---|---|---|
| Dimensione (GB) | vCPU/partizioni primarie | vCPU/partizioni primarie | vCPU/partizioni primarie | vCPU/partizioni primarie |
| 0,5 | - | - | 2/2 | - |
| 1 | - | - | 2/2 | - |
| 3 | - | - | 2/2 | 4/2 |
| 6 | - | - | 2/2 | 4/2 |
| 12 | - | 2/2 | 4/2 | 8/6 |
| 24 | - | 4/2 | 8/6 | 16/12 |
| 60 | - | 8/6 | 16/12 | 32/24 |
| 120 | - | 16/12 | 32/24 | 64/48 |
| 180 | - | 24/24 | 48/48 | 96/96 |
| 240 | 8/6 | 32/24 | 64/48 | 128/96 |
| 360 | - | 48/48 | 96/96 | 192/192 |
| 480 | 16/12 | 64/48 | 128/96 | 256/192 |
| 720 | 24/24 | 96/96 | 192/192 | 384/384 |
| 960 | 32/24 | 128/192 | 256/192 | - |
| 1440 | 48/48 | 192/192 | - | - |
| 1920 | 64/48 | 256/192 | - | - |
| 4500 | 144/96 | - | - | - |
Esecuzione senza la modalità a disponibilità elevata abilitata
È possibile eseguire senza la modalità a disponibilità elevata abilitata. Ciò significa che l'istanza di Redis non ha la replica abilitata e non ha accesso al contratto di servizio di disponibilità. Non è consigliabile eseguire in modalità non a disponibilità elevata all'esterno degli scenari di sviluppo/test. Non è possibile disabilitare la disponibilità elevata in un'istanza già creata. È possibile abilitare la disponibilità elevata in un'istanza che non lo ha, tuttavia. Poiché un'istanza in esecuzione senza disponibilità elevata usa meno macchine virtuali/nodi, le vCPU non possono essere usate in modo efficiente, quindi le prestazioni potrebbero essere inferiori.
Memoria riservata
In ogni istanza di Redis gestita di Azure, circa il 20% della memoria disponibile è riservato come buffer per le operazioni non incache, 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
Il ridimensionamento non è attualmente supportato in Redis gestito di Azure. Per altre informazioni, vedere Prerequisiti/limitazioni del ridimensionamento di Redis gestito di Azure.
Livello con ottimizzazione flash
Il livello Flash Optimized usa sia l'archiviazione Flash NVMe che la RAM. Poiché l'archiviazione Flash è un costo inferiore, l'uso del livello Flash Optimized consente di ridurre alcune prestazioni per ottenere un'efficienza dei prezzi.
Nelle istanze ottimizzate 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 i valori ad accesso sporadico meno comunemente usati 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. I test con un'istanza della cache completa possono produrre prestazioni inferiori perché solo la RAM viene usata nella fase di test dell'utilizzo della memoria insufficiente.
- 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 possono essere eseguiti correttamente nel livello Ottimizzato per Flash spesso presentano le caratteristiche seguenti:
- Lettura elevata, con un rapporto elevato tra i comandi di lettura e la scrittura dei comandi.
- L'accesso è incentrato su un subset di chiavi usate 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:
- Scrivere carichi di lavoro pesanti.
- 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.