Quali sono le procedure consigliate per i livelli Enterprise ed Enterprise Flash
Di seguito sono riportate le procedure consigliate quando si usano i livelli Enterprise ed Enterprise Flash della cache di Azure per Redis.
Ridondanza della zona
È consigliabile distribuire nuove cache in una configurazione con ridondanza della zona. La ridondanza della zona garantisce che i nodi Redis Enterprise vengano distribuiti tra tre zone di disponibilità, aumentando la ridondanza dalle interruzioni a livello di data center. L'uso della ridondanza della zona aumenta la disponibilità. Per altre informazioni, vedere Contratti di servizio (SLA) per i servizi online.
La ridondanza della zona è importante nel livello Enterprise perché l'istanza della cache usa sempre almeno tre nodi. Due di essi sono nodi dati, che contengono i dati, e un nodo quorum. L'aumento della capacità consente di ridimensionare il numero di nodi dati in incrementi di numero pari.
Esiste anche un altro nodo, denominato nodo quorum. Questo nodo monitora i nodi dati e seleziona automaticamente il nuovo nodo primario in caso di failover. La ridondanza della zona garantisce che i nodi vengano distribuiti uniformemente tra tre zone di disponibilità, riducendo al minimo il rischio di perdita del quorum. Ai clienti non viene addebitato il nodo quorum e non sono previsti altri costi per l'uso della ridondanza della zona oltre gli addebiti per la larghezza di banda all'interno dell'area.
Scalabilità
Nei livelli Enterprise ed Enterprise Flash della cache di Azure per Redis è consigliabile dare priorità allo scaling up rispetto allo scaling out. Dare priorità allo scaling up perché i livelli Enterprise sono basati su Redis Enterprise, che è in grado di usare più core CPU in macchine virtuali di dimensioni maggiori.
Al contrario, la raccomandazione opposta è vera per i livelli Basic, Standard e Premium, basati su Redis open source. In questi livelli è consigliabile dare priorità allo scaling out rispetto allo scaling up nella maggior parte dei casi.
Partizionamento orizzontale e utilizzo della CPU
Nei livelli Basic, Standard e Premium della cache di Azure per Redis, determinare il numero di CPU virtuali (vCPU) usate è semplice. Ogni nodo Redis viene eseguito in una macchina virtuale dedicata. Il processo del server Redis è a thread singolo, usando una vCPU in ogni nodo primario e in ogni nodo replica. Le altre vCPU nella macchina virtuale vengono usate anche per altre operazioni, ad esempio il coordinamento del flusso di lavoro per diverse attività, il monitoraggio dello stato e il carico TLS, tra le altre.
Quando si usa il clustering, l'effetto è di distribuire i dati in più nodi con una partizione per nodo. Aumentando il numero di partizioni, si aumenta in modo lineare il numero di vCPU usati, in base al numero di partizioni presenti nel cluster.
Redis Enterprise, d'altra parte, può utilizzare più vCPU per l'istanza Redis stessa. In altre parole, tutti i livelli della cache di Azure per Redis possono utilizzare più vCPU per le attività in background e di monitoraggio, ma solo i livelli Enterprise e Enterprise Flash sono in grado di utilizzare più vCPU per macchina virtuale per partizioni Redis. La tabella mostra il numero di vCPU effettivi utilizzati per ogni SKU e la capacità (ovvero la scalabilità orizzontale) della configurazione.
Le tabelle mostrano il numero di vCPU utilizzati per le partizioni primarie, non le partizioni di replica. Le partizioni non eseguono il mapping uno-a-uno al numero di vCPU. Le tabelle illustrano solo le vCPU, non le partizioni. Alcune configurazioni usano più partizioni rispetto alle vCPU disponibili per migliorare le prestazioni in alcuni scenari di utilizzo.
E1
| Capacità | VCPU effettivi |
|---|---|
| 2 | 1 (burstable) |
E5
| Capacità | VCPU effettivi |
|---|---|
| 2 | 1 |
| 4 | 2 |
| 6 | 6 |
E10
| Capacità | VCPU effettivi |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E20
| Capacità | VCPU effettivi |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E50
| Capacità | VCPU effettivi |
|---|---|
| 2 | 6 |
| 4 | 6 |
| 6 | 6 |
| 8 | 30 |
| 10 | 30 |
E100
| Capacità | VCPU effettivi |
|---|---|
| 2 | 6 |
| 4 | 30 |
| 6 | 30 |
| 8 | 30 |
| 10 | 30 |
E200
| Capacità | VCPU effettivi |
|---|---|
| 2 | 30 |
| 4 | 60 |
| 6 | 60 |
| 8 | 120 |
| 10 | 120 |
E400
| Capacità | VCPU effettivi |
|---|---|
| 2 | 60 |
| 4 | 120 |
| 6 | 120 |
| 8 | 240 |
| 10 | 240 |
F300
| Capacità | VCPU effettivi |
|---|---|
| 3 | 6 |
| 9 | 30 |
F700
| Capacità | VCPU effettivi |
|---|---|
| 3 | 30 |
| 9 | 30 |
F1500
| Capacità | VCPU effettivi |
|---|---|
| 3 | 30 |
| 9 | 90 |
Clustering in Enterprise
I livelli Enterprise e Enterprise Flash sono intrinsecamente raggruppati, a differenza dei livelli Basic, Standard e Premium. L'implementazione dipende dai criteri di clustering selezionati. I livelli Enterprise offrono 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 OSS implementano la stessa API del cluster Redis di Redis open source. L'API del cluster Redis consente al client Redis di connettersi direttamente a ogni nodo Redis, riducendo al minimo la latenza e ottimizzando la velocità effettiva di rete. Di conseguenza, viene ottenuta una scalabilità quasi lineare quando si aumenta il numero di istanze del cluster con più nodi. I criteri di clustering OSS offrono in genere le migliori prestazioni di latenza e velocità effettiva, ma è necessaria la libreria client per supportare il clustering Redis. 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 tale approccio è che le librerie client Redis non devono supportare il clustering Redis per sfruttare i vantaggi di più nodi. 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.
Comandi a più chiavi
Poiché i livelli Enterprise usano una configurazione in cluster, è possibile che vengano visualizzate eccezioni CROSSSLOT 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.
Procedure consigliate per Enterprise Flash
Il livello Enterprise Flash usa sia l'archiviazione Flash NVMe che la RAM. Poiché l'archiviazione Flash è un costo inferiore, l'uso del livello Enterprise Flash consente di ridurre alcune prestazioni per l'efficienza dei prezzi.
Nelle istanze Flash aziendali, 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 Enterprise Flash
I carichi di lavoro che probabilmente funzionano correttamente nel livello Enterprise Flash hanno spesso 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 Enterprise Flash
Alcuni carichi di lavoro hanno caratteristiche di accesso meno ottimizzate per la progettazione del livello 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.
Gestione degli scenari di inattività dell'area con la replica geografica attiva
La replica geografica attiva è una funzionalità potente per aumentare notevolmente la disponibilità quando si usano i livelli Enterprise della cache di Azure per Redis. È tuttavia consigliabile eseguire le operazioni necessarie per preparare le cache in caso di interruzione a livello di area.
Si considerino, ad esempio, i suggerimenti seguenti:
- Identificare in anticipo l'altra cache nel gruppo di replica geografica a cui passare in caso di arresto di un'area.
- Assicurarsi che i firewall siano impostati in modo che tutte le applicazioni e i client possano accedere alla cache di backup identificata.
- Ogni cache nel gruppo di replica geografica ha una propria chiave di accesso. Determinare il modo in cui l'applicazione passa a chiavi di accesso diverse quando la destinazione è una cache di backup.
- Se una cache nel gruppo di replica geografica diventa inattiva, viene avviata una compilazione di metadati in tutte le cache del gruppo di replica geografica. I metadati non possono essere eliminati finché non è possibile sincronizzare nuovamente le scritture in tutte le cache. È possibile impedire la compilazione dei metadati forzando lo scollegamento della cache inattiva. Prendere in considerazione il monitoraggio della memoria disponibile nella cache e lo scollegamento in caso di utilizzo elevato di memoria, in particolare per carichi di lavoro con intensa attività di scrittura.
È inoltre possibile usare un modello di interruttore. Usare il modello per reindirizzare automaticamente il traffico da una cache che riscontra un'interruzione dell'area verso una cache di backup nello stesso gruppo di replica geografica. Usare servizi di Azure come Gestione traffico di Azure o Azure Load Balancer per abilitare il reindirizzamento.
Persistenza dei dati e backup dei dati
La funzionalità di persistenza dei dati nei livelli Enterprise e Enterprise Flash è progettata per fornire automaticamente un punto di ripristino rapido per i dati quando una cache viene disattivata. Il ripristino rapido è reso possibile archiviando il file RDB o AOF in un disco gestito montato nell'istanza della cache. I file di persistenza sul disco non sono accessibili agli utenti.
Molti clienti vogliono usare la persistenza per eseguire backup periodici dei dati nella cache. Non è consigliabile usare la persistenza dei dati in questo modo. Usare invece la funzionalità di importazione/esportazione. È possibile esportare copie dei dati della cache in formato RDB direttamente nell'account di archiviazione scelto e attivare l'esportazione dei dati con la frequenza necessaria. L'esportazione può essere attivata dal portale o usando l'interfaccia della riga di comando, PowerShell o gli strumenti SDK.
Limitazioni dello SKU E1
Lo SKU E1 è destinato principalmente agli scenari di sviluppo/test. E1 viene eseguito in macchine virtuali con burst più piccole. Le macchine virtuali con burst offrono prestazioni variabili in base alla quantità di CPU usata. A differenza di altre offerte di SKU Enterprise, non è possibile aumentare le prestazioni dello SKU E1, anche se è ancora possibile aumentare le prestazioni fino a uno SKU di dimensioni maggiori. Lo SKU E1 non supporta anche la replica geografica attiva.