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ì (anteprima)
Riduci No
Aumento del numero di istanze No Sì (anteprima)
Scala in No 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

Aumentare e ridurre le prestazioni usando il portale di Azure

  1. Per ridimensionare la cache, passare alla cache nel portale di Azure e selezionare Ridimensiona dal menu Risorsa.

    Screenshot showing Scale on the resource menu.

  2. Scegliere un piano tariffario nel riquadro di lavoro e quindi scegliere Seleziona.

    Screenshot showing the Azure Cache for Redis tiers.

  3. Mentre la cache viene ridimensionata al nuovo livello, viene visualizzata una notifica di Ridimensionamento della cache Redis.

    Screenshot showing the notification of scaling.

  4. Al termine dell'operazione, lo stato passa da Ridimensionamento a In esecuzione.

Nota

Quando si ridimensiona una cache verso l'alto o verso il basso usando il portale, sia che maxmemory-reservedmaxfragmentationmemory-reserved le impostazioni vengono ridimensionate automaticamente in proporzione alle dimensioni della cache. Ad esempio, se maxmemory-reserved è impostato su 3 GB in una cache da 6 GB e si passa alla cache da 12 GB, le impostazioni vengono aggiornate automaticamente a 6 GB durante il ridimensionamento. Quando si aumenta il numero di istanze, si verifica l'inverso.

Aumentare e ridurre le prestazioni con PowerShell

È possibile ridimensionare le istanze di cache di Azure per Redis con PowerShell usando il cmdlet Set-AzRedisCache quando vengono modificate le Sizeproprietà o Sku . Nell'esempio seguente viene illustrato come ridimensionare una cache denominata myCache in una cache da 6 GB nello stesso livello.

   Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -Size 6GB

Per altre informazioni sul ridimensionamento con PowerShell, vedere Per ridimensionare un cache di Azure per Redis usando PowerShell.

Aumentare e ridurre le prestazioni con 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 redis update. Usare la sku.capcity proprietà per ridimensionare all'interno di un livello, ad esempio da una cache Standard C0 a Standard C1:

az redis update --cluster-name myCache --resource-group myGroup --set "sku.capacity"="2"

Usare le proprietà "sku.name" e "sku.family" per passare a un livello diverso, ad esempio da una cache C1 Standard a una cache P1 Premium:

az redis update --cluster-name myCache --resource-group myGroup --set "sku.name"="Premium" "sku.capacity"="1" "sku.family"="P"

Per altre informazioni sul ridimensionamento tramite l'interfaccia della riga di comando di Azure, vedere Modificare le impostazioni di una Cache Redis esistente.

Nota

Quando si ridimensiona una cache verso l'alto o verso il basso a livello di codice ,ad esempio usando PowerShell o l'interfaccia della riga di comando di Azure, qualsiasi maxmemory-reserved o maxfragmentationmemory-reserved viene ignorata come parte della richiesta di aggiornamento. Viene rispettata solo la modifica del ridimensionamento. È possibile aggiornare queste impostazioni di memoria al termine dell'operazione di ridimensionamento.

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

  1. Per ridimensionare la cache, passare alla cache nel portale di Azure e selezionare Ridimensiona dal menu Risorsa.

    Screenshot showing Scale selected in the Resource menu for an Enterprise cache.

  2. 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.

    Screenshot showing the Enterprise tiers in the working pane.

  3. 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.

    Screenshot showing Capacity in the working pane a red box around it.

  4. Mentre la cache viene ridimensionata al nuovo livello, viene visualizzata una notifica di Ridimensionamento della cache Redis.

    Screenshot showing notification of scaling an Enterprise cache.

  5. 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?

  • 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, questa databases impostazione viene mantenuta e non vengono persi dati.
    • Se si usa un numero personalizzato di databases che supera i limiti del nuovo livello, l'impostazione databases viene ridotta ai limiti del nuovo livello e tutti i dati nei database rimossi andranno persi.
  • Quando si esegue la scalabilità a un piano tariffario con lo stesso limite o superiore databases rispetto al livello corrente, l'impostazione databases 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?

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}2e {key}3 poiché solo la key 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?

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