Ridimensionamento di cluster online

Il resharding implica l'aggiunta e la rimozione di partizioni o nodi nel cluster e la ridistribuzione di spazi chiave. Diversi fattori hanno pertanto impatto sull'operazione di resharding, come il carico sul cluster, l'utilizzo della memoria e la dimensione complessiva dei dati. Per un'esperienza ottimale, ti consigliamo di attenerti a tutte le best practice relative al cluster per una distribuzione uniforme dei modelli di carico di lavoro. È inoltre consigliabile completare i passaggi indicati di seguito.

Prima di avviare il resharding, ti consigliamo di effettuare quanto segue:

• Testa la tua applicazione - Testa il comportamento della tua applicazione durante il resharding in un ambiente di gestione temporanea, se possibile.

• Ottieni una notifica immediata dei problemi di dimensionamento - Il resharding è un'operazione che richiede notevoli risorse di calcolo. È dunque consigliabile mantenere l'utilizzo della CPU sotto l'80% sulle istanze multicore e sotto il 50% sulle istanze a core singolo durante il resharding. Monitora le metriche ElastiCache (Redis OSS) e avvia il resharding prima che l'applicazione inizi a osservare problemi di scalabilità. Parametri utili da considerare sono CPUUtilization, NetworkBytesIn, NetworkBytesOut, CurrConnections, NewConnections, FreeableMemory, SwapUsage e BytesUsedForCacheItems.

• Verifica che sia disponibile memoria sufficiente per il dimensionamento - Se esegui il dimensionamento, assicurati che la memoria libera disponibile sule partizioni da conservare sia almeno 1,5 volte quella utilizzata sule partizioni che desideri rimuovere.

• Avvia il resharding durante orari non di punta Ciò consente di ridurre la latenza e l'impatto sulla velocità effettiva per il client durante l'operazione di resharding. In questo modo, il resharding viene inoltre completato più rapidamente, in quanto è possibile utilizzare più risorse per la ridistribuzione degli slot.

• Analizza il comportamento di timeout del client - Alcuni client potrebbero presentare una latenza più elevata durante il dimensionamento del cluster online. Può essere utile configurare la libreria client con un timeout maggiore, in quanto aumenta il tempo a disposizione del sistema per eseguire la connessione, anche in caso di condizioni di carico più elevato sul server. In alcuni casi è possibile che si desideri aprire un numero elevato di connessioni al server. I questi casi considera la necessità di aggiungere backoff esponenziale alla logica di riconnessione. In questo modo è possibile evitare l'aumento di nuove connessioni eseguite contemporaneamente sul server.

• Carica le tue funzioni su ogni shard: durante la scalabilità orizzontale del cluster, ElastiCache replicherà automaticamente le funzioni caricate in uno dei nodi esistenti (selezionati a caso) sui nuovi nodi. Se il cluster utilizza Redis OSS 7.0 o versioni successive e l'applicazione utilizza Redis OSS Functions, consigliamo di caricare tutte le funzioni su tutti gli shard prima della scalabilità orizzontale, in modo che il cluster non finisca con funzioni diverse su shard diversi.

Dopo il resharding, tieni presente quanto segue:

• Il dimensionamento potrebbe riuscire parzialmente se la memoria disponibile nele partizioni di destinazione non è sufficiente. In tal caso, controlla la memoria disponibile e prova di nuovo a eseguire l'operazione, se necessario. I dati sulle partizioni di destinazione non verranno eliminati.

• Per gli slot con elementi di grandi dimensioni non viene eseguita la migrazione. In particolare, la migrazione non viene eseguita per gli slot con elementi di dimensioni maggiori di 256 MB dopo la serializzazione.

• I comandi FLUSHALL e FLUSHDB non sono supportati negli script Lua durante un'operazione di riassegnazione delle partizioni. Nelle versioni precedenti a Redis OSS 6, il BRPOPLPUSH comando non era supportato se opera sullo slot da migrare.