Dimensionare un'istanza della cache di Azure per Redis
cache di Azure per Redis offre diverse offerte di livelli che offrono flessibilità nella scelta delle dimensioni e delle funzionalità della cache. Con il ridimensionamento è possibile modificare le dimensioni, il livello e il numero di nodi dopo aver creato un'istanza della cache in base alle esigenze dell'applicazione. Questo articolo illustra come ridimensionare la cache usando il portale di Azure, oltre a strumenti come Azure PowerShell e l'interfaccia della riga di comando di Azure.
Tipi di scalabilità
Esistono fondamentalmente due modi per ridimensionare un'istanza di cache di Azure per Redis:
La scalabilità verticale aumenta le dimensioni della macchina virtuale (VM) che esegue il server Redis, aggiungendo più memoria, CPU virtuali (vCPU) e larghezza di banda di rete. La scalabilità verticale è detta anche ridimensionamento verticale. L'opposto della scalabilità verticale è l'aumento delle prestazioni.
La scalabilità orizzontale divide l'istanza della cache in più nodi delle stesse dimensioni, aumentando memoria, vCPU e larghezza di banda di rete tramite parallelizzazione. La scalabilità orizzontale viene anche definita scalabilità orizzontale o partizionamento orizzontale. L'opposto dell'aumento del numero di istanze è l'aumento del numero di istanze. Nella community di Redis, il ridimensionamento orizzontale viene spesso definito clustering.
Ambito della disponibilità
Livello | Basic e Standard | Premium | Enterprise ed Enterprise Flash |
---|---|---|---|
Aumentare | Sì | Sì | Sì (anteprima) |
Riduci | Sì | Sì | No |
Aumento del numero di istanze | No | Sì | Sì (anteprima) |
Scala in | No | Sì | No |
Quando è necessario ridimensionare la cache
È possibile usare le funzionalità di monitoraggio di cache di Azure per Redis per monitorare l'integrità e le prestazioni della cache. Usare queste informazioni per determinare quando ridimensionare la cache.
È possibile monitorare le metriche seguenti per determinare se è necessario ridimensionare.
- Caricamento del server Redis
- Un carico elevato del server Redis indica che il server non è in grado di mantenere il ritmo con le richieste provenienti da tutti i client. Poiché un server Redis è un processo a thread singolo, in genere è più utile aumentare il numero di istanze anziché aumentare le prestazioni. L'aumento del numero di istanze abilitando il clustering consente di distribuire le funzioni di overhead tra più processi Redis. La scalabilità orizzontale consente anche di distribuire crittografia/decrittografia TLS e connessione/disconnessione, velocizzando le istanze della cache usando TLS.
- La scalabilità verticale può comunque risultare utile per ridurre il carico del server perché le attività in background possono sfruttare più vCPU e liberare il thread per il processo principale del server Redis.
- I livelli Enterprise ed Enterprise Flash usano Redis Enterprise anziché Redis open source. Uno dei vantaggi di questi livelli è che il processo del server Redis può sfruttare più vCPU. Per questo motivo, sia la scalabilità verticale che l'aumento del numero di istanze in questi livelli possono essere utili per ridurre il carico del server. Per altre informazioni, vedere Procedure consigliate per i livelli Enterprise e Enterprise Flash di cache di Azure per Redis.
- Utilizzo memoria
- Utilizzo elevato della memoria indica che le dimensioni dei dati sono troppo grandi per le dimensioni correnti della cache. Valutare la possibilità di ridimensionare le dimensioni della cache con una memoria maggiore. La scalabilità verticale o l'aumento del numero di istanze è efficace in questo caso.
- Connessioni client
- Ogni dimensione della cache ha un limite al numero di connessioni client che può supportare. Se le connessioni client sono vicine al limite per le dimensioni della cache, valutare la possibilità di aumentare le prestazioni fino a un livello più ampio. La scalabilità orizzontale non aumenta il numero di connessioni client supportate.
- Per altre informazioni sui limiti di connessione in base alle dimensioni della cache, vedere cache di Azure per Redis Prezzi.
- Larghezza di banda della rete
- Se il server Redis supera la larghezza di banda disponibile, le richieste dei client potrebbero verificarsi un timeout perché il server non riesce a eseguire il push dei dati al client in modo sufficientemente rapido. Controllare le metriche "Lettura cache" e "Scrittura cache" per verificare la quantità di larghezza di banda lato server in uso. Se il server Redis supera la larghezza di banda di rete disponibile, è consigliabile aumentare o aumentare le dimensioni della cache con una larghezza di banda di rete superiore.
- Per le cache di livello Enterprise che usano i criteri del cluster Enterprise, la scalabilità orizzontale non aumenta la larghezza di banda di rete.
- Per altre informazioni sulla larghezza di banda disponibile per la rete in base alle dimensioni della cache, vedere cache di Azure per Redis domande frequenti sulla pianificazione.
Per altre informazioni sulla determinazione del piano tariffario della cache da usare, vedere Scelta del livello corretto e domande frequenti sulla pianificazione di cache di Azure per Redis.
Nota
Per altre informazioni su come ottimizzare il processo di ridimensionamento, vedere la guida alle procedure consigliate per il ridimensionamento
Prerequisiti/limitazioni del ridimensionamento cache di Azure per Redis
È possibile aumentare o ridurre le prestazioni a un piano tariffario diverso con le restrizioni seguenti:
- Non è possibile passare da un piano tariffario superiore a uno inferiore.
- Non è possibile passare da una cache Enterprise o Enterprise Flash fino a qualsiasi altro livello.
- Non è possibile passare da una cache Premium a una cache Standard o Basic.
- Non è possibile passare da una cache Standard a una cache Basic.
- È possibile passare da una cache Basic a una cache Standard, ma non è possibile modificare contemporaneamente la dimensione. Se sono necessarie dimensioni diverse, è possibile eseguire in un secondo momento un'operazione di ridimensionamento per le dimensioni desiderate.
- Non è possibile passare direttamente da una cache Basic a una cache Premium. Prima di tutto, passare da Basic a Standard in un'operazione di ridimensionamento e quindi da Standard a Premium nell'operazione di ridimensionamento successiva.
- Non è possibile passare da una dimensione maggiore alla dimensione C0 (250 MB) . Tuttavia, è possibile ridurre le dimensioni a qualsiasi altra dimensione all'interno dello stesso piano tariffario. Ad esempio, è possibile ridurre le prestazioni da C5 Standard a C1 Standard.
- Non è possibile passare da una cache Premium, Standard o Basic fino a una cache Enterprise o Enterprise Flash .
- Non è possibile passare da Enterprise a Enterprise Flash.
È possibile aumentare o ridurre il numero di istanze con le restrizioni seguenti:
- La scalabilità orizzontale è supportata solo nei livelli Premium, Enterprise ed Enterprise Flash .
- La scalabilità orizzontale è supportata solo nel livello Premium .
- Nel livello Premium è necessario abilitare il clustering prima di aumentare o aumentare le prestazioni.
- Nel livello Premium è disponibile il supporto disponibile a livello generale per aumentare le istanze fino a 10 partizioni. Il supporto per un massimo di 30 partizioni è disponibile in anteprima. Per le cache con due repliche, il limite di partizioni è 20. Con tre repliche, il limite di partizioni è 15.
- Solo i livelli Enterprise e Enterprise Flash possono aumentare e aumentare il numero di istanze contemporaneamente.
Come ridimensionare - Livelli Basic, Standard e Premium
Come aumentare e aumentare le prestazioni - Livelli Enterprise ed Enterprise Flash
I livelli Enterprise ed Enterprise Flash sono in grado di aumentare e aumentare le prestazioni in un'unica operazione. Altri livelli richiedono operazioni separate per ogni azione.
Attenzione
I livelli Enterprise ed Enterprise Flash non supportano ancora le operazioni di riduzione o riduzione delle prestazioni .
Ridimensionare usando il portale di Azure
Per ridimensionare la cache, passare alla cache nel portale di Azure e selezionare Ridimensiona dal menu Risorsa.
Per aumentare le prestazioni, scegliere un tipo di cache diverso e quindi scegliere Salva.
Importante
È possibile aumentare le prestazioni solo in questo momento. Non è possibile ridurre le prestazioni.
Per aumentare il numero di istanze, aumentare il dispositivo di scorrimento Capacità . La capacità aumenta in incrementi di due. Questo numero riflette il numero di nodi Redis Enterprise sottostanti aggiunti. Questo numero è sempre un multiplo di due per riflettere i nodi aggiunti sia per le partizioni primarie che per le partizioni di replica.
Importante
In questo momento è possibile aumentare la capacità solo aumentando la capacità. Non è possibile aumentare il numero di istanze.
Mentre la cache viene ridimensionata al nuovo livello, viene visualizzata una notifica di Ridimensionamento della cache Redis.
Al termine dell'operazione, lo stato passa da Ridimensionamento a In esecuzione.
Ridimensionare la cache tramite PowerShell
È possibile ridimensionare le istanze di cache di Azure per Redis con PowerShell usando il cmdlet Update-AzRedisEnterpriseCache. È possibile modificare la Sku
proprietà per aumentare le prestazioni dell'istanza. È possibile modificare la Capacity
proprietà per aumentare il numero di istanze dell'istanza. Nell'esempio seguente viene illustrato come ridimensionare una cache denominata myCache
in un'istanza enterprise E20 (25 GB) con capacità di 4.
Update-AzRedisEnterpriseCache -ResourceGroupName myGroup -Name myCache -Sku Enterprise_E20 -Capacity 4
Ridimensionare la cache tramite l'interfaccia della riga di comando di Azure
Per ridimensionare le istanze di cache di Azure per Redis usando l'interfaccia della riga di comando di Azure, chiamare il comando az redisenterprise update. È possibile modificare la sku
proprietà per aumentare le prestazioni dell'istanza. È possibile modificare la capacity
proprietà per aumentare il numero di istanze dell'istanza. Nell'esempio seguente viene illustrato come ridimensionare una cache denominata myCache
in un'istanza enterprise E20 (25 GB) con capacità di 4.
az redisenterprise update --cluster-name "myCache" --resource-group "myGroup" --sku "Enterprise_E20" --capacity 4
Domande frequenti relative al ridimensionamento
Nell'elenco seguente sono fornite le risposte alle domande poste comunemente sulla rete virtuale di Cache Redis di Azure.
- È possibile eseguire un ridimensionamento verso, da o in una cache Premium?
- Dopo il ridimensionamento, è necessario modificare il nome della cache o le chiavi di accesso?
- Come funziona il ridimensionamento?
- Si perdono dati dalla cache durante il ridimensionamento?
- È possibile usare tutte le funzionalità del livello Premium dopo il ridimensionamento?
- L'impostazione databases personalizzata viene modificata durante il ridimensionamento?
- La cache rimarrà disponibile durante il ridimensionamento?
- Esistono limitazioni di ridimensionamento con la replica geografica?
- Operazioni non supportate
- Quanto tempo richiede il ridimensionamento?
- Come è possibile stabilire quando il ridimensionamento è completato?
- È necessario apportare modifiche all'applicazione client per usare il clustering?
- Come vengono distribuite le chiavi in un cluster?
- Quali sono le dimensioni massime della cache che è possibile creare?
- Tutti i client Redis supportano il clustering?
- Come ci si connette alla cache quando il clustering è abilitato?
- È possibile connettersi direttamente a singole partizioni della cache?
- È possibile configurare il clustering per una cache creata in precedenza?
- È possibile configurare il clustering per una cache Basic o Standard?
- È possibile usare il clustering con il provider di stato della sessione ASP.NET Redis e il provider di cache di output?
- Si ricevono eccezioni MOVE quando si usano StackExchange.Redis e il clustering, cosa è necessario fare?
- Qual è la differenza tra clustering OSS ed Enterprise Clustering nelle cache di livello Enterprise?
- Quante partizioni usano le cache di livello Enterprise?
È possibile eseguire un ridimensionamento verso, da o in una cache Premium?
- Non è possibile passare da una cache Premium a un piano tariffario Basic o Standard.
- È possibile scalare dal piano tariffario di una cache Premium a un altro.
- Non è possibile passare direttamente da una cache Basic a una cache Premium. Prima di tutto, passare da Basic a Standard in un'operazione di ridimensionamento e quindi da Standard a Premium in un'operazione di ridimensionamento successiva.
- Non è possibile passare da una cache Premium a una cache Enterprise o Enterprise Flash .
- Se è stato abilitato il clustering quando è stata creata la cache Premium , è possibile modificare le dimensioni del cluster. Se la cache è stata creata senza clustering abilitato, è possibile configurare il clustering in un secondo momento.
Dopo il ridimensionamento, è necessario modificare il nome della cache o le chiavi di accesso?
No, il nome della cache e le chiavi restano invariati durante un'operazione di ridimensionamento.
Come funziona il ridimensionamento?
- Quando si ridimensiona una cache Basic a dimensioni diverse, viene arrestata e viene effettuato il provisioning di una nuova cache usando le nuove dimensioni. Durante questo periodo, la cache non è disponibile e tutti i dati nella cache vengono persi.
- Quando si ridimensiona una cache Basic in una cache Standard, viene effettuato il provisioning di una cache di replica e i dati vengono copiati dalla cache primaria alla cache di replica. Durante il processo di ridimensionamento, la cache rimane disponibile.
- Quando si ridimensiona una cache Flash Standard, Premium, Enterprise o Enterprise a dimensioni diverse, una delle repliche viene arrestata e sottoposta di nuovo il provisioning alle nuove dimensioni e ai dati trasferiti e quindi l'altra replica esegue un failover prima del nuovo provisioning, simile al processo che si verifica durante un errore di uno dei nodi della cache.
- Quando si aumenta il numero di istanze di una cache in cluster, viene effettuato il provisioning di nuove partizioni e viene aggiunto al cluster del server Redis. I dati vengono quindi partizionati in tutte le partizioni.
- Quando si esegue la scalabilità in una cache in cluster, i dati vengono prima partizionati e quindi le dimensioni del cluster vengono ridotte alle partizioni necessarie.
- In alcuni casi, ad esempio il ridimensionamento o la migrazione della cache a un cluster diverso, l'indirizzo IP sottostante della cache può cambiare. Il record DNS per la cache cambia ed è trasparente per la maggior parte delle applicazioni. Tuttavia, se si usa un indirizzo IP per configurare la connessione alla cache o per configurare gruppi di sicurezza di rete o firewall che consentono il traffico verso la cache, l'applicazione potrebbe avere problemi di connessione qualche volta dopo l'aggiornamento del record DNS.
Si perdono dati dalla cache durante il ridimensionamento?
- Quando si ridimensiona una cache Basic a una nuova dimensione, tutti i dati vengono persi e la cache non è disponibile durante l'operazione di ridimensionamento.
- Quando si ridimensiona una cache Basic in una cache Standard , i dati nella cache vengono in genere mantenuti.
- Quando si ridimensiona una cache Flash Standard, Premium, Enterprise o Enterprise a dimensioni maggiori, tutti i dati vengono in genere mantenuti. Quando si ridimensiona una cache Standard o Premium a dimensioni inferiori, i dati possono andare persi se le dimensioni dei dati superano le nuove dimensioni inferiori quando vengono ridotte. Se durante la riduzione i dati vengono persi, le chiavi vengono rimosse mediante il criterio di rimozione allkeys-lru .
È possibile usare tutte le funzionalità del livello Premium dopo il ridimensionamento?
No, alcune funzionalità possono essere impostate solo quando si crea una cache nel livello Premium e non sono disponibili dopo il ridimensionamento.
Queste funzionalità non possono essere aggiunte dopo la creazione della cache Premium:
- Aggiunta di una rete virtuale
- Aggiunta della ridondanza della zona
- Uso di più repliche per ogni replica primaria
Per usare una di queste funzionalità, è necessario creare una nuova istanza della cache nel livello Premium.
L'impostazione databases personalizzata viene modificata durante il ridimensionamento?
Se è stato configurato un valore personalizzato per l'impostazione databases
durante la creazione della cache, tenere presente che alcuni piani tariffari hanno limiti di database differenti. Di seguito sono descritte alcune considerazioni relative all'esecuzione del ridimensionamento in questo scenario:
- Quando si esegue la scalabilità a un piano tariffario con un limite inferiore
databases
al livello corrente:- Se si usa il numero predefinito di
databases
, ovvero 16 per tutti i piani tariffari, non vengono persi dati. - Se si usa un numero personalizzato di
databases
che rientra nei limiti per il livello a cui si esegue il ridimensionamento, questadatabases
impostazione viene mantenuta e non vengono persi dati. - Se si usa un numero personalizzato di
databases
che supera i limiti del nuovo livello, l'impostazionedatabases
viene ridotta ai limiti del nuovo livello e tutti i dati nei database rimossi andranno persi.
- Se si usa il numero predefinito di
- Quando si esegue la scalabilità a un piano tariffario con lo stesso limite o superiore
databases
rispetto al livello corrente, l'impostazionedatabases
viene mantenuta e non vengono persi dati.
Anche se le cache Standard, Premium, Enterprise ed Enterprise Flash hanno un contratto di servizio per la disponibilità, non esiste alcun contratto di servizio per la perdita di dati.
La cache rimarrà disponibile durante il ridimensionamento?
- Le cache Standard, Premium, Enterprise ed Enterprise Flash rimangono disponibili durante l'operazione di ridimensionamento. Tuttavia, i blip di connessione possono verificarsi durante il ridimensionamento di queste cache e anche durante il ridimensionamento dalle cache Basic a Standard . Questi blip di connessione dovrebbero essere piccoli e i client Redis possono in genere ristabilire immediatamente la connessione.
- Per le cache Enterprise ed Enterprise Flash che usano la replica geografica attiva, la scalabilità di un solo subset di cache collegate può introdurre problemi nel tempo in alcuni casi. È consigliabile ridimensionare tutte le cache nel gruppo di replica geografica, se possibile.
- Le cache Basic sono offline durante le operazioni di ridimensionamento a dimensioni diverse. Le cache di base rimangono disponibili durante il ridimensionamento da Basic a Standard , ma potrebbero verificarsi piccoli problemi di connessione. Se si verifica un blip di connessione, i client Redis possono in genere ristabilire immediatamente la connessione.
Esistono limitazioni di ridimensionamento con la replica geografica?
Con la replica geografica passiva configurata, è possibile notare che non è possibile ridimensionare una cache o modificare le partizioni in un cluster. Un collegamento di replica geografica tra due cache impedisce l'operazione di ridimensionamento o la modifica del numero di partizioni in un cluster. Per eseguire questi comandi è necessario scollegare la cache. Per altre informazioni, vedere Configurare la replica geografica.
Con la replica geografica attiva configurata, non è possibile ridimensionare una cache. Tutte le cache in un gruppo di replica geografica devono avere le stesse dimensioni e capacità.
Operazioni non supportate
- Non è possibile passare da un piano tariffario superiore a uno inferiore.
- Non è possibile passare da una cache Premium a una cache Standard o Basic.
- Non è possibile passare da una cache Standard a una cache Basic.
- È possibile passare da una cache Basic a una cache Standard, ma non è possibile modificare contemporaneamente la dimensione. Se sono necessarie dimensioni diverse, è possibile eseguire un'operazione di ridimensionamento per le dimensioni desiderate in un secondo momento.
- Non è possibile passare direttamente da una cache Basic a una cache Premium. Passare prima da Basic a Standard in un'operazione di ridimensionamento e quindi da Standard a Premium in un'operazione successiva.
- Non è possibile passare da una cache Premium a una cache Enterprise o Enterprise Flash .
- Non è possibile passare da una dimensione maggiore alla dimensione C0 (250 MB) .
Se un'operazione di ridimensionamento ha esito negativo, il servizio tenta di annullare l'operazione e la dimensione originale della cache viene ripristinata.
Quanto tempo richiede il ridimensionamento?
Il tempo di ridimensionamento dipende da alcuni fattori. Ecco alcuni fattori che possono influire sulla durata del ridimensionamento.
- Quantità di dati: la replica di grandi quantità di dati richiede più tempo
- Richieste di scrittura elevate: un numero più elevato di scritture significa che più dati vengono replicati tra nodi o partizioni
- Carico server elevato: un carico server superiore indica che il server Redis è occupato e ha cicli di CPU limitati per completare la ridistribuzione dei dati
In genere, quando si ridimensiona una cache senza dati, sono necessari circa 20 minuti. Per le cache in cluster, il ridimensionamento richiede circa 20 minuti per partizione con dati minimi.
Come è possibile stabilire quando il ridimensionamento è completato?
Nel portale di Azure è possibile visualizzare l'operazione di ridimensionamento in corso. Quando il ridimensionamento è completo, lo stato della cache passa a In esecuzione.
È necessario apportare modifiche all'applicazione client per usare il clustering?
Quando il clustering è abilitato, sarà disponibile solo il database 0. Se l'applicazione client usa più database e tenta di leggere o scrivere in un database diverso da 0, viene generata l'eccezione seguente:
Unhandled Exception: StackExchange.Redis.RedisConnectionException: ProtocolFailure on GET --->
StackExchange.Redis.RedisCommandException: Multiple databases are not supported on this server; cannot switch to database: 6
Per altre informazioni, vedere la specifica sul cluster Redis: subset implementato.
Se si usa StackExchange.Redis, è necessario usare la versione 1.0.481 o successiva. Connettersi alla cache usando gli stessi endpoint, porte e chiavi usati per la connessione a una cache in cui il clustering è disabilitato. L'unica differenza consiste nel fatto che tutte le operazioni di lettura e scrittura devono essere eseguite nel database 0.
Altri client possono avere requisiti diversi. Vedere Tutti i client Redis supportano il clustering?
Se l'applicazione usa più operazioni chiave raggruppate in un singolo comando, tutte le chiavi devono trovarsi nella stessa partizione. Per individuare le chiavi nella stessa partizione, vedere Come vengono distribuite le chiavi in un cluster?
Se si usa Redis ASP.NET provider di stato sessione, è necessario usare la versione 2.0.1 o successiva. Vedere È possibile usare il clustering con il provider di stato della sessione ASP.NET Redis e i provider di output caching?
Importante
Quando si usano i livelli Enterprise o Enterprise FLash, è possibile scegliere la modalità cluster OSS o la modalità cluster Enterprise. La modalità cluster OSS equivale al clustering nel livello Premium e segue la specifica del clustering open source. La modalità Cluster Enterprise può essere meno efficiente, ma usa il clustering Redis Enterprise che non richiede alcuna modifica del client da usare. Per altre informazioni, vedere Clustering in Enterprise.
Come vengono distribuite le chiavi in un cluster?
Per la documentazione di Redis sul modello di distribuzione chiavi: lo spazio delle chiavi è suddiviso in 16.384 slot. Viene eseguito l'hashing di ogni chiave e le chiavi vengono assegnate a uno di questi slot, che vengono distribuiti in tutti i nodi del cluster. È possibile configurare la parte della chiave sottoposta a hashing, per assicurare che più chiavi vengano inserite nella stessa partizione mediante i tag hash.
- Chiavi con tag hash: se una parte della chiave è racchiusa tra
{
e}
, solo tale parte della chiave verrà sottoposta a hashing allo scopo di determinare lo slot hash di una chiave. Ad esempio, le tre chiavi seguenti si trovano nella stessa partizione:{key}1
,{key}2
e{key}3
poiché solo lakey
parte del nome è hash. Per un elenco completo di specifiche dei tag hash per le chiavi, vedere la pagina relativa ai tag hash per le chiavi. - Chiavi senza un tag hash: l'intero nome della chiave viene usato per l'hashing, con conseguente distribuzione statisticamente uniforme tra le partizioni della cache.
Per prestazioni e velocità effettiva ottimali, è consigliabile distribuire le chiavi in modo uniforme. Se si usano chiavi con un tag hash, è responsabilità dell'applicazione assicurarsi che le chiavi vengano distribuite in modo uniforme.
Per altre informazioni, vedere le pagine relative al modello di distribuzione delle chiavi, al partizionamento orizzontale del cluster Redis e ai tag hash per le chiavi.
Per il codice di esempio sull'uso del clustering e dell'individuazione delle chiavi nella stessa partizione con il client StackExchange.Redis, vedere la parte clustering.cs dell'esempio Hello World .
Quali sono le dimensioni massime della cache che è possibile creare?
Le dimensioni massime della cache che è possibile avere sono di 4,5 TB. Questo risultato è una cache F1500 in cluster con capacità 9. Per altre informazioni, vedere Prezzi di Cache Redis di Azure.
Tutti i client Redis supportano il clustering?
Molte librerie client supportano il clustering Redis, ma non tutti. Controllare la documentazione per la libreria in uso per verificare di usare una libreria e una versione che supportano il clustering. StackExchange.Redis è una libreria che supporta il clustering, nelle versioni più recenti. Per altre informazioni su altri client, vedere la sezione dedicata alle prove con il cluster nell'esercitazione per il cluster Redis.
Il protocollo di clustering Redis richiede che ogni client si connetta a ogni partizione direttamente in modalità clustering e definisca anche nuove risposte di errore, ad esempio 'MOVED' na 'CROSSSLOTS'. Quando si tenta di usare una libreria client che non supporta il clustering, con una cache in modalità cluster, il risultato può essere rappresentato da molte eccezioni di reindirizzamento spostate o semplicemente interrompere l'applicazione, se si eseguono richieste multichiavi tra slot.
Nota
Se si usa StackExchange.Redis come client, verificare di usare la versione più recente di StackExchange.Redis 1.0.481 o versione successiva per il corretto funzionamento del clustering. Per altre informazioni sui problemi relativi alle eccezioni di spostamento, vedere Spostare le eccezioni.
Come ci si connette alla cache quando il clustering è abilitato?
È possibile connettersi alla cache usando gli stessi endpoint, porte e chiavi usati per la connessione a una cache in cui non è abilitato il clustering. Redis gestisce il clustering sul back-end in modo che non sia necessario gestirlo dal client.
È possibile connettersi direttamente a singole partizioni della cache?
Il protocollo di clustering richiede al client di stabilire le connessioni di partizione corrette, pertanto il client deve stabilire connessioni di condivisione. Ciò premesso, ogni partizione è costituita da una coppia di cache primaria/di replica nota complessivamente come un'istanza della cache. È possibile connettersi a queste istanze della cache usando l'utilità Redis-CLI nel ramo instabile del repository Redis in GitHub. Questa versione implementa il supporto di base quando avviata con il passaggio -c
. Per altre informazioni, vedere Riproduzione con il cluster in nell'esercitazione sul clusterhttps://redis.io Redis.
È necessario usare l'opzione -p
per specificare la porta corretta a cui connettersi. Usare il comando CLUSTER NODES per determinare le porte esatte usate per i nodi primario e di replica. Vengono usati gli intervalli di porte seguenti:
- Per le cache di livello Premium non TLS, le porte sono disponibili nell'intervallo
130XX
- Per le cache del livello Premium abilitate per TLS, le porte sono disponibili nell'intervallo
150XX
- Per le cache Enterprise ed Enterprise Flash che usano il clustering OSS, la connessione iniziale avvierà tramite la porta 10000. Connessione ai singoli nodi può essere eseguito usando le porte nell'intervallo 85XX. Le porte 85xx cambieranno nel tempo e non dovrebbero essere hardcoded nell'applicazione.
È possibile configurare il clustering per una cache creata in precedenza?
Sì. Prima di tutto, assicurarsi che la cache sia nel livello Premium aumentandola. Successivamente, è possibile visualizzare le opzioni di configurazione del cluster, inclusa un'opzione per abilitare il cluster. Modificare le dimensioni del cluster dopo la creazione della cache o dopo aver abilitato il clustering per la prima volta.
Importante
Non è possibile annullare l'abilitazione del clustering. E una cache con clustering abilitato e una sola partizione si comporta in modo diverso rispetto a una cache con le stesse dimensioni senzaclustering.
Tutte le cache del livello Enterprise e Enterprise Flash vengono sempre raggruppate.
È possibile configurare il clustering per una cache Basic o Standard?
Il clustering è disponibile solo per le cache Premium, Enterprise ed Enterprise Flash.
È possibile usare il clustering con il provider di stato della sessione ASP.NET Redis e il provider di cache di output?
- Provider di cache di output Redis : nessuna modifica necessaria.
- Provider di stato sessione Redis: per usare il clustering, è necessario usare RedisSessionStateProvider 2.0.1 o versione successiva o viene generata un'eccezione, che è una modifica che causa un'interruzione. Per altre informazioni, vedere Dettagli delle modifiche di rilievo della versione 2.0.0.
Si ricevono eccezioni MOVE quando si usano StackExchange.Redis e il clustering, cosa è necessario fare?
Se si usa StackExchange.Redis e si ricevono MOVE
eccezioni quando si usa il clustering, assicurarsi di usare StackExchange.Redis 1.1.603 o versione successiva. Per le istruzioni di configurazione delle applicazioni .NET per l'uso di StackExchange.Redis, vedere l'articolo sulla configurazione dei client della cache.
Qual è la differenza tra clustering OSS ed Enterprise Clustering nelle cache di livello Enterprise?
La modalità cluster OSS equivale al clustering nel livello Premium e segue la specifica del clustering open source. La modalità Cluster Enterprise può essere meno efficiente, ma usa il clustering Redis Enterprise, che non richiede modifiche client da usare. Per altre informazioni, vedere Clustering in Enterprise.
Quante partizioni usano le cache di livello Enterprise?
A differenza delle cache di livello Basic, Standard e Premium, le cache Enterprise ed Enterprise Flash possono sfruttare più partizioni in un singolo nodo. Per altre informazioni, vedere Partizionamento orizzontale e utilizzo della CPU.
Passaggi successivi
Commenti e suggerimenti
https://aka.ms/ContentUserFeedback.
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedereInvia e visualizza il feedback per