Quali sono le procedure consigliate per i livelli Enterprise ed Enterprise Flash
Ecco le procedure consigliate quando si usano i livelli Enterprise e Enterprise Flash di 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 nodi 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. I clienti non vengono addebitati per 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 e Enterprise Flash di cache di Azure per Redis, è consigliabile assegnare priorità all'aumento delle prestazioni rispetto alla scalabilità orizzontale. Assegnare priorità all'aumento delle prestazioni 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 definire la priorità dell'aumento delle istanze rispetto all'aumento delle prestazioni nella maggior parte dei casi.
Partizionamento orizzontale e utilizzo della CPU
Nei livelli Basic, Standard e Premium di 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 di ogni nodo di replica. Le altre vCPU nella macchina virtuale vengono ancora usate per altre attività, ad esempio il coordinamento del flusso di lavoro per diverse attività, il monitoraggio dell'integrità e il carico TLS, tra gli altri.
Quando si usa il clustering, l'effetto consiste nel 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 nel cluster.
Redis Enterprise, d'altra parte, può usare più vCPU per l'istanza redis stessa. In altre parole, tutti i livelli di cache di Azure per Redis possono usare più vCPU per le attività di monitoraggio e in background, ma solo i livelli Enterprise e Enterprise Flash possono usare più vCPU per vm per partizioni Redis. La tabella mostra il numero di vCPU effettivi usati per ogni SKU e la capacità (ovvero la scalabilità orizzontale) della configurazione.
Le tabelle mostrano il numero di vCPU usati 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.
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 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, la scalabilità quasi lineare viene ottenuta 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 richiede la libreria client per supportare il clustering Redis. I criteri di clustering oss non possono essere usati anche con il modulo RediSearch.
I criteri di clustering aziendale sono una configurazione più semplice che usa un singolo endpoint per tutte le connessioni client. L'uso dei criteri di clustering aziendale 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 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 che nella velocità effettiva di rete. I criteri di clustering aziendale sono 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 CROSSSLOT eccezioni sui comandi che operano su più chiavi. Il comportamento varia a seconda dei criteri di clustering usati. Se si usano i criteri di clustering oss, i comandi con più chiavi richiedono il mapping di tutte le chiavi allo stesso slot hash.
È anche possibile che vengano visualizzati CROSSSLOT errori con i criteri di clustering aziendale. Solo i comandi con più chiavi seguenti sono consentiti tra slot con clustering aziendale: DEL, MSETMGETEXISTS, , UNLINK, e .TOUCH
Nei database Active-Active i comandi di scrittura a più chiavi (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 di 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. La posizione dei valori viene determinata in modo intelligente dal software Redis. I valori "hot" a cui si accede vengono archiviati in modo fequently sulla RAM, mentre i valori "Cold" 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 optmerà per ottenere prestazioni ottimali, l'istanza riempirà prima di tutto la RAM disponibile prima di aggiungere elementi all'archiviazione Flash. Ciò ha alcune implicazioni per le prestazioni:
- Quando si esegue il test con un utilizzo ridotto della memoria, le prestazioni e la latenza possono essere significativamente migliori rispetto a quelle di un'istanza della cache completa perché viene usata solo la RAM.
- Quando si scrivono più dati nella cache, la percentuale di dati in 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 che vengono 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, questo può 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.
- Accesso casuale o uniforme ai dati paterni nella maggior parte del set di dati.
- Nomi di chiave lunghi con dimensioni di valore relativamente ridotte.
Gestione degli scenari di inattivo 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 di 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é le scritture non possono essere sincronizzate di nuovo in tutte le cache. È possibile impedire la compilazione dei metadati forzando l'scollegamento della cache inattiva. Prendere in considerazione il monitoraggio della memoria disponibile nella cache e l'scollegamento in caso di utilizzo elevato di memoria, in particolare per carichi di lavoro con intensa attività di scrittura.
È anche possibile usare un modello di interruttore. Usare il modello per reindirizzare automaticamente il traffico da una cache che riscontra un'interruzione dell'area e verso una cache di backup nello stesso gruppo di replica geografica. Usare i servizi di Azure, ad esempio 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.