Condividi tramite

Ridimensionare un'istanza di Managed Redis di Azure (anteprima)

  • Articolo

Managed Redis di Azure (anteprima) offre SKU e offerte di livelli diverse che garantiscono flessibilità nella scelta delle dimensioni e delle prestazioni della cache. È possibile aumentare le dimensioni della memoria o passare a un livello con prestazioni di calcolo superiori. 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.

Nota

Poiché ogni livello di Managed Redis di Azure ha praticamente le stesse funzionalità, il ridimensionamento viene in genere usato solo per modificare le caratteristiche della memoria e delle prestazioni.

Importante

Attualmente è supportato solo il ridimensionamento a dimensioni di memoria o livelli di prestazioni superiori. Il ridimensionamento a dimensioni di memoria o a livelli di prestazioni inferiori non è ancora supportato.

Tipi di scalabilità

Managed Redis 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.

  • vCPU Managed Redis 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 aumenta le prestazioni dell'istanza senza richiedere l'aumento della memoria. A differenza dell'edizione Community di Redis, che può usare solo una singola vCPU, Managed Redis di Azure usa lo stack Redis Enterprise, che è in grado di usare più vCPU. Ciò significa che il numero di vCPU usate dall'istanza di Redis è correlato direttamente alle prestazioni in termini di velocità effettiva e latenza.

Livelli di prestazioni

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

Per i dati in memoria sono disponibili tre livelli:

  • Ottimizzato 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, rendendola 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. Offre un bilanciamento integro tra le risorse di memoria e di calcolo.
  • Ottimizzato per il calcolo. Progettato per carichi di lavoro a elevato utilizzo di prestazioni che richiedono una velocità effettiva massima, con un rapporto da memoria a vCPU (2:1). È ideale per le applicazioni che richiedono prestazioni superiori.

Un livello archivia i dati sia in memoria sia su disco:

  • Ottimizzato per Flash. Consente ai cluster Redis di spostare automaticamente i dati a cui si accede con minor frequenza dalla memoria (RAM) all'archiviazione NVMe. Questo riduce le prestazioni, ma consente un ridimensionamento conveniente delle cache con set di dati di grandi dimensioni.

Livelli e SKU a colpo d'occhio

Tabella che mostra le diverse configurazioni di memoria e vCPU per ogni SKU e livello di Redis gestito di Azure.

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 Managed Redis di Azure

Quando è necessario ridimensionare la cache

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

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

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 Managed Redis di Azure

  • Non è possibile ridimensionare dai livelli Ottimizzato per la memoria, Bilanciato o Ottimizzato per il calcolo al livello Ottimizzato per Flash tier o viceversa.
  • Non è possibile ridurre le prestazioni da a uno SKU con meno vCPU. (Tra livelli o all'interno di un livello).
  • Non è possibile ridurre le dimensioni della memoria, anche se ha le stesse o più vCPU.
  • 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 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.
  • Il ridimensionamento di un'istanza in un gruppo di replica geografica presenta altre limitazioni. Per maggiori informazioni, vedere Esistono limitazioni di ridimensionamento con la replica geografica?.

Come applicare la scalabilità

Suggerimento

È possibile modificare le dimensioni della memoria e il livello di prestazioni in un'unica operazione.

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

    Se si seleziona uno SKU a cui non è possibile ridimensionare, l'opzione Salva è disabilitata. Per informazioni dettagliate sulle opzioni di ridimensionamento consentite, vedere la sezione Prerequisiti/limitazioni del ridimensionamento di Azure Managed Redis .

    Screenshot che mostra i livelli Enterprise nel riquadro di lavoro.

  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 di una cache Enterprise.

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

Ridimensionare la cache tramite PowerShell

È possibile ridimensionare le istanze di Managed Redis 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 myGroup -Name myCache -Sku ComputeOptimized_X20

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

Per ridimensionare le istanze di Managed Redis 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 "myCache" --resource-group "myGroup" --sku "ComputeOptimized_X20"

Domande frequenti relative al ridimensionamento

Nell'elenco seguente sono riportate le risposte a domande comuni sul ridimensionamento di Managed Redis 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 ridimensionare a un livello di prestazioni inferiore o a dimensioni di memoria inferiori, vedere Prerequisiti/limitazioni del ridimensionamento di Managed Redis di Azure.

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 un'istanza di Redis, uno dei nodi nel cluster Redis viene arrestato e sottoposto a nuovo provisioning alle nuove dimensioni. Successivamente, i dati vengono trasferiti e l'altro nodo esegue un failover simile prima del nuovo provisioning. È simile al processo che si verifica durante l'applicazione di patch o un errore di uno dei nodi della cache.
  • Quando si esegue il ridimensionamento a un'istanza con più vCPU, viene effettuato il provisioning di nuove partizioni che verranno 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 Managed Redis 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 sta eseguendo il ridimensionamento a un livello di memoria inferiore, i dati possono andare persi se le dimensioni dei dati superano le nuove dimensioni inferiori quando la cache viene ridimensionata a dimensioni inferiori. Se durante la riduzione i dati vengono persi, le chiavi vengono rimosse mediante il criterio di rimozione allkeys-lru .
  • Se la modalità disponibilità elevata è disabilitata, tutti i dati vanno persi e la cache non è disponibile durante l'operazione di ridimensionamento.

La cache rimarrà disponibile durante il ridimensionamento?

  • Le istanze di Managed Redis 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 Managed Redis di Azure è offline durante le operazioni di ridimensionamento.

Ci sono delle limitazioni di ridimensionamento con la replica geografica?

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.

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 più elevato 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. Quando il ridimensionamento è completo, lo stato della cache passa a In esecuzione.

Managed Redis di Azure usa il clustering?

A differenza della cache di Azure per Redis, Managed Redis di Azure usa il clustering tra tutti i livelli e le SKU. Il clustering consente ottimizzazioni significative delle prestazioni. Ogni SKU di Managed Redis 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 Managed Redis di Azure?

Poiché Managed Redis di Azure viene eseguito nel software Redis Enterprise, le partizioni possono essere usate in una configurazione più densa rispetto a Redis edizione 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 della cache di Azure per Redis.

Qual è la differenza tra i criteri cluster OSS ed Enterprise?

I criteri cluster OSS sono gli stessi dell'approccio di clustering usato in Redis edizione Community. I criteri cluster OSS sono in genere più efficienti. I criteri cluster Enterprise implementano il clustering in modo che appaiano a un client come istanza di Redis non cluster. Questo approccio può essere meno efficiente, ma può evitare i problemi di compatibilità client. Non è attualmente possibile passare tra criteri cluster in un'istanza in esecuzione. Per altre informazioni, vedere Criteri cluster.

Passaggi successivi