Condividi tramite

Dimensionare un'istanza della cache di Azure per Redis

  • Articolo

Cache di Azure per Redis dispone di differenti offerte di livello che offrono flessibilità nella scelta delle funzionalità e delle dimensioni 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 applicative. Questo articolo illustra come ridimensionare la cache usando il portale di Azure, nonché 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:

  • L'aumento delle prestazioni aumenta le dimensioni della VM (VM) che esegue il server Redis, aggiungendo più memoria, CPU virtuali (vCPU) e larghezza di banda di rete. L'aumento delle prestazioni è detto anche ridimensionamento verticale. L'opposto dell'aumento delle prestazioni è la riduzione delle prestazioni.

  • L'aumento del numero di istanze divide l'istanza della cache in più nodi delle stesse dimensioni, aumentando memoria, vCPU e larghezza di banda di rete tramite parallelizzazione. L'aumento del numero di istanze è anche definito ridimensionamento orizzontale o partizionamento orizzontale. L'opposto dell'aumento del numero di istanze è la riduzione del numero di istanze. Nella community di Redis, l'aumento del numero di istanze è spesso definito clustering.

Ambito della disponibilità

Livello Basic e Standard Premium Enterprise ed Enterprise Flash
Aumentare Sì Sì Sì
Riduci Sì Sì No
Aumento del numero di istanze No Sì Sì
Ridurre il numero di istanze 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.

Per determinare se è necessario un ridimensionamento, è possibile monitorare le metriche seguenti.

  • Caricamento del server Redis
    • Un carico elevato del server Redis indica che il server non è in grado di mantenere il passo 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 sovraccarico tra più processi Redis. L'aumento del numero di istanze consente anche di distribuire connessione/disconnessione e crittografia/decrittografia TLS, velocizzando le istanze della cache con TLS.
    • L'aumento delle prestazioni 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 del server Redis principale.
    • 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 vCPU multiple. Con più vCPU, sia l'aumento delle prestazioni che l'aumento del numero di istanze possono essere utili in questi livelli per ridurre il carico del server.
  • Utilizzo memoria
    • Un 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 in modo che disponga di più memoria. Sia l'aumento delle prestazioni che l'aumento del numero di istanze sono efficaci in questo caso.
  • Connessioni client
    • Ogni dimensione della cache ha un numero limite 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 a un livello più ampio. L'aumento del numero di istanze non aumenta il numero di connessioni client supportate.
    • Per altre informazioni sui limiti di connessione in base alle dimensioni della cache, vedere Prezzi di Cache di Azure per Redis.
  • Larghezza di banda della rete
    • Se il server Redis supera la larghezza di banda disponibile, potrebbe verificarsi il timeout delle richieste client perché il server non riesce a eseguire il push dei dati al client in modo sufficientemente rapido. Per verificare la quantità di larghezza di banda lato server usata, controllare le metriche "Lettura della cache" e "Scrittura nella cache". Se il server Redis supera la larghezza di banda di rete disponibile, è consigliabile aumentare il numero di istanze o le prestazioni per aumentare le dimensioni della cache e avere una larghezza di banda di rete superiore.
    • Per le cache di livello Enterprise che usano i criteri del cluster Enterprise, l'aumento del numero di istanze 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 Domande frequenti sulla pianificazione di Cache di Azure per Redis.
  • Analisi interne di Defender
    • Nelle cache standard C0 e C1, mentre l'analisi interna di Defender è in esecuzione nelle VM, potrebbero verificarsi brevi picchi di carico del server, non causati da un aumento delle richieste di cache. Si noterà una latenza più elevata per le richieste mentre le analisi interne di Defender vengono eseguite su questi livelli, un paio di volte al giorno. Le cache nei livelli C0 e C1 hanno un solo core per multitasking e dividono il lavoro di gestione delle analisi interne di Defender e delle richieste Redis. È possibile ridurre l'effetto ridimensionando a un'offerta di livello superiore con più core CPU, ad esempio C2.
    • L'aumento delle dimensioni della cache nei livelli superiori consente di risolvere eventuali problemi di latenza. Inoltre, al livello C2, è disponibile il supporto per un massimo di 2.000 connessioni client.

Per altre informazioni per determinare il piano tariffario della cache da usare, vedere Scelta del livello appropriato 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 di Cache di Azure per Redis

È possibile cambiare piano tariffario per aumentare/ridurre le prestazioni 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 a un qualsiasi piano di livello 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 differenti, è possibile eseguire in un secondo momento un'operazione di ridimensionamento per ottenere le dimensioni desiderate.
  • Non è possibile passare direttamente da una cache Basic a una cache Premium. È innanzitutto necessario passare da Basic a Standard con una prima operazione di ridimensionamento quindi da Standard a Premium nell’operazione successiva.
  • Non è possibile passare da una dimensione maggiore alla dimensione C0 (250 MB). Tuttavia, è possibile ridurre le prestazioni per ottenere le dimensioni desiderate all'interno dello stesso piano tariffario. Ad esempio, è possibile ridurre le prestazioni passando da C5 Standard a C1 Standard.
  • Non è possibile passare da una cache Premium, Standard o Basic a una cache Enterprise o Enterprise Flash.
  • Non è possibile passare da Enterprise a Enterprise Flash e viceversa.

È possibile aumentare/ridurre il numero di istanze con le restrizioni seguenti:

  • L'aumento del numero di istanze è supportato solo nei livelli Premium, Enterprise ed Enterprise Flash.
  • La riduzione del numero di istanze è supportata solo nel livello Premium.
  • Nel livello Premium è necessario abilitare il clustering prima di aumentare o ridurre il numero di istanze.
  • Nel livello Premium è in genere disponibile il supporto per l'aumento del numero di istanze fino a 10 partizioni. Il supporto fino a 30 partizioni è disponibile in anteprima. Per le cache con due repliche il limite di partizioni è 20, mentre per quelle con tre repliche il limite di partizioni è 15.
  • Solo i livelli Enterprise ed Enterprise Flash possono aumentare e ridurre il numero di istanze contemporaneamente.

Come ridimensionare - Livelli Basic, Standard e Premium

Aumentare e ridurre le prestazioni con il portale di Azure

  1. Per ridimensionare la cache, accedere alla cache nel portale di Azure e selezionare Ridimensionare nel menu Risorse.

    Screenshot che mostra Ridimensionare nel menu delle risorse.

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

    Screenshot che mostra i livelli di Cache di Azure per Redis.

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

    Screenshot che mostra la notifica del ridimensionamento.

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

Nota

Quando si aumentano o riducono le prestazioni di una cache usando il portale, le impostazioni maxmemory-reserved e maxfragmentationmemory-reserved vengono ridimensionate automaticamente in proporzione alle dimensioni della cache. Ad esempio, se maxmemory-reserved è impostata 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 riducono le dimensioni, 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 le proprietà Size o Sku vengono modificate. L'esempio seguente illustra come ridimensionare una cache denominata myCache in una cache di 6 GB nello stesso livello.

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

Per altre informazioni sul ridimensionamento con PowerShell, vedere Ridimensionare una cache di Azure per Redis con 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 proprietà sku.capcity per ridimensionare all'interno dello stesso livello, ad esempio da una cache C0 Standard a una C1 Standard:

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

Usare le proprietà "sku.name" e "sku.family" per aumentare le prestazioni andando a un livello differente, 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 aumentano o riducono le prestazioni di una cache a livello di codice, ad esempio con PowerShell o con 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 le prestazioni e il numero di istanze - Livelli Enterprise ed Enterprise Flash

I livelli Enterprise ed Enterprise Flash sono in grado di aumentare sia le prestazioni che il numero di istanze 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 delle prestazioni o di riduzione del numero di istanze.

Ridimensionare con il portale di Azure

  1. Per ridimensionare la cache, accedere alla cache nel portale di Azure e selezionare Ridimensionare nel menu Risorse.

    Screenshot che mostra l'opzione Ridimensionare selezionata nel menu Risorse per una cache Enterprise.

  2. Per aumentare le prestazioni, scegliere un tipo di cache differente quindi scegliere Salva.

    Importante

    In questo caso è solo possibile aumentare le prestazioni, mentre non è possibile ridurle.

    Screenshot che mostra i livelli Enterprise nel riquadro di lavoro.

  3. Per aumentare il numero di istanze, usare il dispositivo di scorrimento per aumentare la Capacità. La capacità aumenta in incrementi di due. Questo numero riflette il numero di nodi Redis Enterprise sottostanti che vengono 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 caso è solo possibile aumentare il numero di istanze, ovvero la capacità, ma non è possibile ridurle.

    Screenshot che mostra la Capacità nel riquadro di lavoro con una casella rossa intorno a essa.

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

    Screenshot che mostra la notifica del ridimensionamento di una cache Enterprise.

  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 proprietà Sku per aumentare le prestazioni dell'istanza. È possibile modificare la proprietà Capacity per aumentare il numero di istanze. 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 proprietà sku per aumentare le prestazioni dell'istanza. È possibile modificare la proprietà capacity per aumentare il numero di istanze. 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. È innanzitutto necessario passare da Basic a Standard con una prima operazione di ridimensionamento quindi da Standard a Premium con una successiva operazione.
  • Non è possibile passare da una cache Premium a una cache Enterprise o Enterprise Flash.
  • Se è stato abilitato il clustering durante la creazione della cache Premium, è possibile modificare la dimensione della cache. 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 una dimensione differente, la cache viene arrestata e viene eseguito il provisioning di una nuova cache utilizzando la nuova dimensione. Durante questo periodo, la cache non è disponibile e tutti i dati nella cache vengono persi.
  • Quando una cache Basic viene ridimensionata in una cache Standard, viene effettuato il provisioning di una cache di replica e i dati vengono copiati dalla cache principale alla cache di replica. Durante il processo di ridimensionamento, la cache rimane disponibile.
  • Quando si ridimensiona una cache Standard, Premium, Enterprise o Enterprise Flash a una dimensione differente, una delle repliche viene arrestata, ne viene rieffettuato il provisioning in base alla nuova dimensione e i dati vengono trasferiti. Viene quindi eseguito il failover dell'altra replica e successivamente ne viene rieffettuato il provisioning, in modo analogo a quanto accade in caso di 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 che vengono aggiunte al cluster del server Redis. I dati vengono quindi ripartizionati in tutte le partizioni.
  • Quando si riduce il numero di istanze di una cache in cluster, prima i dati vengono ripartizionati e poi le dimensioni del cluster vengono ridotte alle partizioni necessarie.
  • In alcuni casi, ad esempio il ridimensionamento o la migrazione della cache a un cluster differente, l'indirizzo IP sottostante della cache può cambiare. Il record DNS della cache cambia ed è trasparente per la maggior parte delle applicazioni. Tuttavia, se si usa un indirizzo IP per configurare la connessione alla cache o i gruppi di sicurezza di rete, o se si usano firewall che consentono il traffico verso la cache, a volte l'applicazione potrebbe avere problemi di connessione dopo l'aggiornamento del record DNS.

Durante il ridimensionamento i dati nella cache andranno persi?

  • Quando si ridimensiona una cache Basic, tutti i dati vengono persi e la cache non è disponibile durante l'operazione di ridimensionamento.
  • Quando una cache Basic viene ridimensionata in una cache Standard, generalmente i dati nella cache vengono mantenuti.
  • Quando si ridimensiona una cache Standard, Premium, Enterprise o Enterprise Flash a dimensioni maggiori, generalmente tutti i dati vengono 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 ridotte, quando si riducono le prestazioni della cache. 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:

  • Inserimento della rete virtuale
  • Aggiunta della ridondanza della zona
  • Uso di più repliche per la 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 passa a piano tariffario con un limite di databases inferiore a quello del piano corrente:
    • Se si usa il numero predefinito di databases, che è 16 per tutti i piani tariffari, non viene perso alcun dato.
    • Se si usa un numero personalizzato di databases compreso nei limiti per il piano a cui si passa, questa impostazione di databases viene mantenuta e non viene perso alcun dato.
    • Se si usa un numero personalizzato di databases che supera i limiti del nuovo piano, l'impostazione di databases viene ridotta ai limiti del nuovo piano e tutti i dati nei database rimossi vengono persi.
  • Quando si passa a un piano tariffario con un limite di databases uguale o superiore a quello del piano corrente, l'impostazione di databases viene mantenuta e non viene perso alcun dato.

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. Possono tuttavia verificarsi problemi di connessione durante il ridimensionamento di queste cache e anche durante il ridimensionamento da una cache Basic a una cache Standard. Questi problemi di connessione sono in genere di entità limitata e i client Redis possono generalmente ristabilire la connessione immediatamente.
  • Per le cache Enterprise ed Enterprise Flash che usano la replica geografica attiva, il ridimensionamento di un solo sottoinsieme di cache collegate può causare problemi nel tempo in alcuni casi. È consigliabile ridimensionare insieme 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 Basic rimangono disponibili quando si esegue il ridimensionamento da Basic a Standard, ma potrebbero verificarsi piccoli problemi di connessione. Se si verifica un problema di connessione, i client Redis possono generalmente ristabilire la connessione immediatamente.

Ci sono delle limitazioni di ridimensionamento con la replica geografica?

Con la replica geografica passiva configurata, si potrebbe notare che non è possibile ridimensionare una cache o modificare le partizioni in un cluster. Un link 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 differenti, è possibile eseguire un'operazione di ridimensionamento alle dimensioni desiderate in un secondo momento.
  • Non è possibile passare direttamente da una cache Basic a una cache Premium. È innanzitutto necessario passare da Basic a Standard con una prima operazione di ridimensionamento quindi da Standard a Premium con una successiva operazione.
  • 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 vengono replicati più dati tra nodi o partizioni
  • Carico server elevato: un carico server più elevato indica che il server Redis è occupato e sono disponibili cicli di CPU limitati per completare la ridistribuzione dei dati

Il ridimensionamento di una cache è un'azione non semplice e può richiedere molto tempo.

In base agli esempi reali, il tempo necessario per ridimensionare la cache con una o due partizioni può essere compreso tra 1 e 2 ore quando la cache non è sottoposta a carichi elevati. Se sono presenti più partizioni, il tempo necessario per la scalabilità non aumenta in modo lineare.

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 di Software open source o la Modalità Cluster Enterprise. La modalità Cluster di Software open source 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 Enterprise Redis, che non richiede modifiche al client per l'uso. Per altre informazioni, vedere Clustering.

Come vengono distribuite le chiavi in un cluster?

In base alla documentazione Redis relativa al modello di distribuzione delle 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 3 chiavi seguenti si trovano nella stessa partizione: {key}1, {key}2 e {key}3, poiché solo la parte key del nome viene sottoposta a hashing. 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, l'applicazione ha la responsabilità di assicurare 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 un codice di esempio sull'uso del clustering e sul posizionamento delle chiavi nella stessa partizione con il client StackExchange.Redis, vedere la porzione 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. Il 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 tutte. Controllare la documentazione per la libreria in uso per verificare di usare una libreria e una versione che supportino 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à di clustering e definisca anche nuove risposte di errore, ad esempio MOVED e CROSSSLOTS. Quando si tenta di usare una libreria client che non supporta il clustering, con una cache in modalità cluster, il risultato è molte eccezioni di reindirizzamento MOVED o interrompere semplicemente l'applicazione, se si eseguono richieste multichiavi tra slot.

Nota

Se si usa StackExchange.Redis come client, verificare che sia in uso la versione più recente di StackExchange.Redis 1.0.481 o versioni successive per il corretto funzionamento del clustering. Per altre informazioni in caso di problemi con le eccezioni MOVE, vedere Eccezioni MOVE.

Come ci si connette alla cache quando il clustering è abilitato?

È possibile connettersi alla cache con gli stessi endpoint, porte e chiavi usati per la connessione a una cache senza clustering abilitato. 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 di cache tramite l'utilità CLI Redis 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 Usare il cluster in https://redis.io nell'esercitazione sul cluster 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 di livello Premium abilitate per TLS, le porte sono disponibili nell'intervallo 150XX
  • Per le cache Enterprise ed Enterprise Flash che usano il clustering software open source, la connessione iniziale avviene tramite la porta 10000. La connessione a singoli nodi può essere eseguita 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 aumentandone le prestazioni. 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. Una cache con il clustering abilitato e una sola partizione si comporta in modo diverso da una cache delle stesse dimensioni senza clustering.

Tutte le cache di livello Enterprise ed Enterprise Flash sono sempre in cluster.

È 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?

Quando si usano StackExchange.Redis e il clustering si ottengono eccezioni MOVE. Cosa fare?

Se si usa StackExchange.Redis e si ricevono eccezioni MOVE quando si usa il clustering, assicurarsi di usare StackExchange.Redis 1.1.603 o versioni successive. 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 di software open source e clustering Enterprise nelle cache di livello Enterprise?

La modalità Cluster di Software open source 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 Enterprise Redis, che non richiede modifiche al client per l'uso. Per altre informazioni, vedere Clustering.

Quante partizioni vengono usate dalle 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 Configurazione del partizionamento orizzontale.

Passaggi successivi