Condividi tramite

Ridimensionare un'istanza di Redis Gestito di Azure

  • Si applica a: ✅ Azure Managed Redis

Redis gestito di Azure offre diverse offerte di SKU e livelli che offrono flessibilità nella scelta delle dimensioni e delle prestazioni della cache. È possibile passare a una dimensione di memoria maggiore o a un livello con prestazioni di calcolo maggiori. È anche possibile ridurre le prestazioni a un livello più piccolo o più appropriato. 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.

Annotazioni

Poiché ogni livello di Redis gestito di Azure ha quasi le stesse funzionalità, la scalabilità viene in genere usata solo per modificare le caratteristiche di memoria e prestazioni. Il ridimensionamento delle cache di Redis Gestito di Azure con replica geografica rimane in anteprima pubblica.

Tipi di scalabilità

Redis Gestito di Azure supporta il ridimensionamento in due dimensioni:

  • Memoria L'aumento della memoria aumenta le dimensioni dell'istanza di Redis, consentendo l'archiviazione di più dati. Quando si riduce la memoria, è necessario assicurarsi che l'utilizzo della memoria corrente sia inferiore alle nuove dimensioni di memoria che si vuole usare.

  • vCPU Redis Gestito di Azure offre tre livelli (Ottimizzato per la memoria, Bilanciato e Ottimizzato per il calcolo) con un numero crescente di vCPU per ogni livello di memoria. Il ridimensionamento a un livello con più vCPU incrementa le prestazioni dell'istanza senza richiedere l'aumento della memoria. A differenza dei livelli Basic, Standard e Premium di Cache Redis di Azure che usano solo una singola vCPU, Azure Managed Redis usa lo stack Redis Enterprise di Redis. Lo stack Redis Enterprise è in grado di usare più vCPU, il che significa che il numero di vCPU usate dall'istanza di Redis è direttamente correlato alle prestazioni di velocità effettiva e latenza.

Livelli di prestazioni

Sono disponibili quattro livelli di Redis Gestito di Azure, ognuno con caratteristiche di prestazioni e livelli di prezzo diversi.

Importante

Tutti i livelli in memoria che usano più di 235 GB di spazio di archiviazione sono disponibili in anteprima pubblica, inclusi M350 ottimizzati per la memoria e versioni successive; B350 bilanciato e superiore; e Compute Optimized X350 e versioni successive. Tutti questi livelli e versioni successive sono disponibili in anteprima pubblica.

Tutti i livelli con ottimizzazione flash sono disponibili in anteprima pubblica.

Livelli e SKU a colpo d'occhio

Ecco tre livelli di archiviazione che archiviano i dati in memoria:

  • Ottimizzazione per la memoria Ideale per i casi d'uso a elevato utilizzo di memoria che richiedono un rapporto elevato tra memoria e vCPU (8:1), ma non richiede le prestazioni di velocità effettiva più elevate. Offre un prezzo inferiore per gli scenari in cui è necessaria una minore potenza di elaborazione o velocità effettiva, rendendolo una scelta eccellente per gli ambienti di sviluppo e test.

  • Bilanciato (memoria e calcolo) Offre un rapporto di memoria-vCPU bilanciato (4:1), rendendolo ideale per i carichi di lavoro standard. Questo livello offre un bilanciamento integro della memoria e delle risorse di calcolo.

  • Ottimizzato per il Calcolo Progettato per carichi di lavoro ad alte prestazioni che richiedono una massima larghezza di banda, con un rapporto ridotto da memoria a vCPU di 2:1. È ideale per le applicazioni che richiedono prestazioni elevate.

    Immagine di una tabella che mostra un confronto tra SKU e livelli.

Ecco il livello che archivia i dati sia in memoria che su disco:

  • Flash Optimized (anteprima) Consente ai cluster Redis di spostare automaticamente i dati a cui si accede meno frequentemente dalla memoria (RAM) all'archiviazione NVMe. Ciò riduce le prestazioni, ma consente un ridimensionamento conveniente delle cache con set di dati di grandi dimensioni.

    Immagine di una tabella che mostra i livelli con ottimizzazione flash in una tabella che mostra l'utilizzo dell'archiviazione.

Prestazioni (velocità effettiva e latenza)

Per i benchmark delle prestazioni e altre informazioni su come misurare le prestazioni di ogni SKU e livello, vedere Test delle prestazioni con Redis Gestito di Azure

Quando è necessario ridimensionare la cache

È possibile usare le funzionalità di monitoraggio di Redis Gestito di Azure 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.

  • CPU
    • Un uso elevato della CPU implica che il server Redis non è in grado di tenere il passo con le richieste di tutti i client. Il ridimensionamento a più vCPU consente di distribuire le richieste tra più processi Redis. Il ridimensionamento aiuta anche a distribuire la crittografia/decrittografia TLS e la connessione/disconnessione, velocizzando le istanze della cache che usano TLS.
  • 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. Quando si riduce la memoria, è necessario assicurarsi che l'utilizzo della memoria della cache corrente sia inferiore a quello della nuova dimensione di memoria da usare. Non è possibile inserire un set di dati di grandi dimensioni in dimensioni inferiori della cache.
  • 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 il ridimensionamento a dimensioni della memoria maggiori o a un livello di prestazioni superiore.
    • Per altre informazioni sui limiti di connessione in base alle dimensioni della cache, vedere Test delle prestazioni con Redis Gestito di Azure.
  • 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, valutare il ridimensionamento a un livello di prestazioni superiore o a dimensioni della cache maggiori.
    • La scelta dei criteri cluster influisce sulla larghezza di banda di rete disponibile. In genere, i criteri cluster OSS presentano una larghezza di banda di rete superiore rispetto ai criteri cluster Enterprise. Per altre informazioni, vedere Criteri cluster
    • Per altre informazioni sulla larghezza di banda di rete disponibile in base alle dimensioni della cache, vedere Test delle prestazioni con Redis Gestito di Azure.

Per altre informazioni sulla determinazione del piano tariffario della cache da usare, vedere Scelta del livello corretto.

Per altre informazioni su come ottimizzare il processo di ridimensionamento, vedere la guida alle procedure consigliate per il ridimensionamento.

Limitazioni del ridimensionamento di Redis gestito di Azure

  • Non è possibile ridimensionare dai livelli Ottimizzato per la memoria, Bilanciato o Ottimizzato per il calcolo al livello Ottimizzato per Flash o viceversa.
  • Quando si riduce la memoria per l'istanza di Redis, l'utilizzo corrente della memoria dell'istanza di Redis deve essere inferiore a quello previsto per le nuove dimensioni della memoria. Per altre informazioni, vedere Cosa accade ai dati se si ridimensionano a dimensioni di memoria inferiori?.
  • Quando si riduce la memoria o la vCPU per l'istanza di Redis, è possibile ridimensionare solo gli SKU, che dispongono di una configurazione vCPU e di partizione compatibile con la configurazione nell'istanza corrente.
  • In alcuni casi durante il ridimensionamento, l'indirizzo IP sottostante dell'istanza di Redis può cambiare. Il record DNS per l'istanza cambia ed è trasparente per la maggior parte delle applicazioni. Tuttavia, se si usa un indirizzo IP per configurare la connessione all'istanza di Redis o per configurare gruppi di sicurezza di rete o firewall che consentono il traffico verso l'istanza di Redis, l'applicazione potrebbe avere problemi di connessione qualche volta dopo l'aggiornamento del record DNS.
  • Il ridimensionamento di un'istanza in un gruppo di replica geografica presenta altre limitazioni. Per maggiori informazioni, vedere Ci sono delle limitazioni di ridimensionamento con la replica geografica?
  • Quando si ridimensiona, è possibile ridurre solo fino a determinati livelli. Per ulteriori informazioni, consulta Perché solo io posso ridurre a un sottoinsieme di SKU più piccoli?.

Come ridimensionare

In questa sezione viene descritto come ridimensionare una cache Redis gestita di Azure.

Ridimensionare con il portale di Azure

Annotazioni

Il ridimensionamento delle cache di Redis Gestito di Azure con replica geografica rimane in anteprima pubblica.

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

  2. Per ridimensionare le vCPU, scegliere un tipo di cache diverso e quindi scegliere Salva.

    Importante

    Se si seleziona uno SKU che non può essere ridimensionato, l'opzione Salva è disabilitata. Per informazioni dettagliate sulle opzioni di ridimensionamento consentite, vedere la sezione Limitazioni del ridimensionamento di Azure Managed Redis .

  3. Al termine del ridimensionamento, lo stato passa da Ridimensionamento a In esecuzione quando si visualizza la sezione Panoramica del menu Risorsa.

Ridimensionare la cache tramite PowerShell

È possibile ridimensionare le istanze di Redis Gestito di Azure con PowerShell usando il cmdlet Update-AzRedisEnterpriseCache. È possibile modificare la proprietà Sku per selezionare il livello e la SKU necessari. L'esempio seguente illustra come ridimensionare una cache denominata myCache in un'istanza Ottimizzata per il calcolo X20 (24 GB).

   Update-AzRedisEnterpriseCache -ResourceGroupName <your-group> -Name <your-cache-name> -Sku <sku-name>

Ridimensionare la cache tramite l'interfaccia della riga di comando di Azure

Per ridimensionare le istanze di Redis Gestito di Azure usando l'interfaccia della riga di comando di Azure, chiamare il comando az redisenterprise update. È possibile modificare la proprietà sku per selezionare il livello e la SKU necessari. L'esempio seguente illustra come ridimensionare una cache denominata myCache in un'istanza Ottimizzata per il calcolo X20 (24 GB).

az redisenterprise update --cluster-name <your-cache-name> --resource-group <your-resource-group> --sku <name-of-sku>

Domande frequenti relative al ridimensionamento

Nell'elenco seguente sono riportate le risposte a domande comuni sul ridimensionamento di Redis Gestito di Azure.

È possibile ridimensionare all'interno di un livello o tra livelli?

È sempre possibile ridimensionare a un livello di prestazioni superiore alle stesse dimensioni di memoria o a dimensioni di memoria maggiori all'interno dello stesso livello di prestazioni. Per il ridimensionamento a un livello di prestazioni inferiore o dimensioni di memoria inferiori, è consigliabile eseguire l'API REST "listskusforscaling" per ottenere l'elenco di SKU su cui è possibile ridimensionare.

az redisenterprise list-skus-for-scaling --cluster-name <your-redis-instance> --resource-group <your-resource-group>

Cosa accade ai dati se si ridimensionano a dimensioni di memoria inferiori?

È possibile ridimensionare a una dimensione di memoria inferiore solo se l'utilizzo della memoria corrente è minore delle dimensioni di memoria minori previste. Se l'utilizzo della memoria corrente è superiore a quello previsto, la richiesta di ridimensionamento ha esito negativo. È possibile ridurre l'utilizzo corrente della memoria eliminando coppie di valori di chiave indesiderate o eseguendo l'operazione di scaricamento.

az redisenterprise database flush --cluster-name <your-redis-instance> --resource-group <your-resource-group>

Dopo il ridimensionamento, è necessario modificare il nome della cache o le chiavi di accesso?

No, il nome della cache e le chiavi di accesso non vengono modificati durante un'operazione di ridimensionamento.

Come funziona il ridimensionamento?

  • Quando si ridimensiona un'istanza di Redis, uno dei nodi nel cluster Redis viene arrestato e sottoposto a nuovo provisioning con le nuove dimensioni. Quindi i dati vengono trasferiti e, successivamente, anche l'altro nodo dopo esegue un failover analogo prima del nuovo provisioning. L'arresto e la riconfigurazione sono simili al processo che avviene durante il patching o un guasto di uno dei nodi della cache.
  • Quando si esegue il ridimensionamento verso un'istanza con più vCPU, nuove shard vengono create e aggiunte al cluster del server Redis. I dati vengono quindi ripartizionati in tutte le partizioni.

Per altre informazioni sulla gestione del partizionamento orizzontale da parte di Redis Gestito di Azure, vedere Configurazione del partizionamento orizzontale.

Durante il ridimensionamento i dati nella cache andranno persi?

  • Se la modalità disponibilità elevata è abilitata, tutti i dati devono essere mantenuti durante le operazioni di ridimensionamento.
  • Se si esegue il ridimensionamento a un livello di memoria inferiore, è necessario assicurarsi che l'utilizzo della memoria corrente sia inferiore rispetto alle nuove dimensioni di memoria previste. Se l'utilizzo corrente della memoria è maggiore delle dimensioni di memoria dello SKU desiderate, è possibile scaricare i dati usando l'operazione scaricamento o scegliere manualmente i valori chiave da eliminare.
  • Se la modalità disponibilità elevata è disabilitata, tutti i dati vanno persi e la cache non è disponibile durante l'operazione di ridimensionamento.

La cache è disponibile durante il ridimensionamento?

  • Le istanze di Redis Gestito di Azure con la modalità disponibilità elevata abilitata rimangono disponibili durante l'operazione di ridimensionamento. Tuttavia, i problemi di connessione possono verificarsi durante il ridimensionamento di queste cache. Questi problemi di connessione sono in genere brevi e i client Redis possono in genere ristabilire la connessione all'istante.
  • Se la modalità disponibilità elevata è disabilitata, l'istanza di Redis Gestito di Azure è offline durante le operazioni di ridimensionamento.

Ci sono delle limitazioni di ridimensionamento con la replica geografica?

Il ridimensionamento delle cache con replica geografica è disponibile in anteprima pubblica. Con la replica geografica attiva configurata, non è possibile combinare e abbinare dimensioni di cache in un gruppo di replica geografica. Di conseguenza, il ridimensionamento delle cache in un gruppo di replica geografica richiede alcuni passaggi aggiuntivi. Per istruzioni, vedere Ridimensionamento delle istanze in un gruppo di replica geografica.

La riduzione delle dimensioni della memoria o del numero di partizioni inferiore non è supportata per le cache con replica geografica. Per altre informazioni, vedere Quante partizioni usa ogni SKU redis gestito di Azure per individuare le partizioni nel cluster.

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
  • Utilizzo elevato della CPU: un utilizzo maggiore della CPU implica che il server Redis è occupato e che sono disponibili cicli della CPU limitati per completare la ridistribuzione dei dati

In genere, quando si ridimensiona un'istanza senza dati, sono necessari circa 10 minuti.

Come è possibile stabilire quando il ridimensionamento è completato?

Nel portale di Azure è possibile visualizzare l'operazione di ridimensionamento in corso. Al termine del ridimensionamento, lo stato della cache diventa In esecuzione quando si visualizza Panoramica nel menu Risorsa.

Redis Gestito di Azure utilizza il clustering?

A differenza della Cache di Azure per Redis, Redis Gestito di Azure usa il clustering tra tutti i livelli e le SKU. Il clustering consente ottimizzazioni significative delle prestazioni. Ogni SKU di Redis Gestito di Azure è configurata per un numero ottimizzato di partizioni per il numero di vCPU disponibili. Il numero di partizioni non è configurabile dall'utente.

Quante partizioni vengono usate da ogni SKU di Redis Gestito di Azure?

Poiché Redis Gestito di Azure viene eseguito nel software Redis Enterprise, le partizioni possono essere utilizzate in una configurazione più densa rispetto a Redis community. Per informazioni sul numero specifico di partizioni usate in ogni SKU, vedere Configurazione del partizionamento orizzontale.

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.

Quali sono le dimensioni massime della cache che è possibile creare?

Le dimensioni massime della cache che è possibile avere è di 4,5 TB, denominata istanza A4500 ottimizzata per Flash. Prezzi di Cache di Azure per Redis.

Perché posso ridurre solo a un sottoinsieme di SKU più piccoli?

Per mantenere la compatibilità con il numero di partizioni e vCPU, è possibile ridurre le prestazioni solo a determinati SKU. È possibile visualizzare gli SKU a cui l'istanza di Redis può essere ridotta controllando le opzioni disponibili nella sezione Ridimensiona del portale di Azure. È possibile eseguire anche il seguente comando della riga di comando.

È possibile visualizzare gli SKU a cui l'istanza di Redis può essere ridotta controllando le opzioni disponibili nella sezione Ridimensiona del portale di Azure.

az redisenterprise list-skus-for-scaling --cluster-name <your-redis-instance> --resource-group <your-resource-group>

È possibile modificare i criteri di clustering dopo aver selezionato OSS o Cluster aziendale?

Dopo aver impostato un criterio di clustering su OSSCluster o EnterpriseCluster quando si crea una cache, non è possibile modificarlo. Per passare a un criterio di clustering diverso, è necessario eliminare la cache Redis e ricrearla con la configurazione desiderata. Solo le cache con i criteri non cluster possono essere aggiornate a una configurazione cluster dopo la distribuzione.

Contenuti correlati

  • Last updated on