Creare una nuova cache con il ridimensionamento orizzontale usando il clustering
Quando si crea una nuova cache di Azure per Redis, il clustering viene abilitato durante la creazione della cache dal riquadro di lavoro.
Usare la guida di avvio rapidoCreare una cache Redis open source per iniziare a creare una nuova cache usando il portale di Azure.
Nella scheda Avanzate per un'istanza della cache Premium, configurare le impostazioni per la porta non TLS, il clustering e il salvataggio permanente dei dati. Per abilitare il clustering, selezionare Abilita.
È possibile includere fino a 30 partizioni nel cluster. Dopo aver selezionato Abilita, scorrere il dispositivo di scorrimento o digitare un numero compreso tra 1 e 30 in Numero di partizioni e selezionare OK.
Ogni partizione è una coppia di cache primaria/di replica gestita da Azure. La dimensione totale della cache viene calcolata moltiplicando il numero di partizioni per la dimensione della cache selezionata nel piano tariffario.
Dopo aver creato la cache, è possibile connettersi ad essa e usarla esattamente come una cache non in cluster. Redis distribuisce i dati in tutte le partizioni della cache. Se la diagnostica è abilitata, le metriche vengono acquisite separatamente per ogni partizione e possono essere visualizzate in Cache Redis di Azure usando il menu Risorsa.
Completare la creazione della cache usando la guida di avvio rapido.
La creazione della cache richiede un po' di tempo. È possibile monitorare lo stato di avanzamento nella pagina Panoramica della cache di Azure per Redis. Quando l'elemento Stato indica In esecuzione, la cache è pronta per l'uso.
Per un codice di esempio sull'uso del clustering con il client StackExchange.Redis, vedere la porzione clustering.cs dell'esempio Hello World.
Ridimensionare orizzontalmente una cache Premium in esecuzione
Per modificare le dimensioni di un cluster nella cache Premium creata in precedenza e già in esecuzione con il clustering abilitato, selezionare Dimensioni cluster nel menu Risorsa.
Per modificare le dimensioni del cluster, usare il dispositivo di scorrimento oppure digitare un numero compreso tra 1 e 30 nella casella di testo Numero di partizioni. Selezionare quindi OK per salvare.
Aumentando la dimensione del cluster si aumentano la massima velocità effettiva e la dimensione massima della cache, ma non il numero massimo di connessioni disponibili per i client.
Aumentare e ridurre il numero di istanze con PowerShell
È possibile aumentare il numero di istanze di cache di Azure per Redis con PowerShell usando il cmdlet Set-AzRedisCache quando la proprietà ShardCount viene modificata. Nell'esempio seguente viene illustrato come aumentare il numero di istanze di una cache denominata myCache per usare tre partizioni (ovvero aumentare il numero di istanze per un fattore di tre)
Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -ShardCount 3
Per altre informazioni sul ridimensionamento con PowerShell, vedere Ridimensionare una cache di Azure per Redis con PowerShell.
Aumentare e ridurre il numero di istanze 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 e usare la proprietà shard-count. Nell'esempio seguente viene illustrato come aumentare il numero di istanze di una cache denominata myCache per usare tre partizioni (ovvero aumentare il numero di istanze per un fattore di tre).
az redis update --cluster-name myCache --resource-group myGroup --set shard-count=3
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 tramite 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.
Il ridimensionamento di un cluster esegue il comando MIGRATE, che è un comando costoso. Per un impatto minimo, prendere in considerazione l'esecuzione di questa operazione durante le ore di minore attività. Durante il processo di migrazione si nota un picco di carico nel server. Il ridimensionamento di un cluster è un processo di lunga esecuzione e la quantità di tempo necessario dipende dal numero di chiavi e dalle dimensioni dei valori associati a tali chiavi.
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 o riduzione delle prestazioni .
Ridimensionare con il portale di Azure
Per ridimensionare la cache, accedere alla cache nel portale di Azure e selezionare Ridimensionare nel menu Risorse.
Per aumentare le prestazioni, scegliere un tipo di cache differente quindi scegliere Salva.
Importante
In questo caso è solo possibile aumentare le prestazioni, Non è possibile ridurre le prestazioni.
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à, Non è possibile aumentare le prestazioni.
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 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 e le chiavi della cache non cambiano 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.
- Quando si ridimensiona o si esegue la migrazione della cache a un cluster diverso, 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 configurare gruppi di sicurezza di rete o firewall che consentono il traffico verso la cache, l'applicazione potrebbe avere problemi di connessione dopo gli aggiornamenti 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 originali superano le nuove dimensioni inferiori. 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 di reti virtuali
- 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 è 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, è possibile ridimensionare una cache con alcune limitazioni. Tutte le cache in un gruppo di replica geografica devono avere le stesse dimensioni e capacità. Per ulteriori informazioni, vedere Configurare la replica geografica attiva per le istanze di cache di Azure per Redis Enterprise
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. I fattori seguenti 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 di server superiore indica che il server Redis è occupato e sono disponibili cicli di CPU limitati per completare la ridistribuzione dei dati.
Il ridimensionamento di una cache non è un'azione semplice e può richiedere molto tempo. La scalabilità di una cache con una o due partizioni può richiedere da una a due ore quando 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?
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 zero, si verifica 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. È possibile 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 potrebbero avere requisiti differenti. Per altre informazioni, 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 il provider di Stato sessione ASP.NET di Redis, è necessario usare la versione 2.0.1 o successiva. Per altre informazioni, vedere È possibile usare il clustering con i provider Redis ASP.NET per lo stato della sessione e la memorizzazione della cache di output?
Importante
Quando si usano i livelli Enterprise o Enterprise FLash, è possibile scegliere la modalità cluster OSS 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 può essere molte eccezioni di reindirizzamento SPOSTATo o interrompere semplicemente l'applicazione se si effettuano 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 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.
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.
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.
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
