Best practice. Dimensionamento 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. Per questo motivo, consigliamo di mantenere l'utilizzo della CPU al di sotto dell'80% sulle istanze multicore e meno del 50% sulle istanze single core durante il resharding. Monitora le metriche di MemoryDB e avvia il resharding prima che l'applicazione inizi a rilevare problemi di scalabilità. Parametri utili da considerare sono CPUUtilization, NetworkBytesIn, NetworkBytesOut, CurrConnections, NewConnections, FreeableMemory, SwapUsage e BytesUsedForMemoryDB.

• 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.

Durante il resharding, ti consigliamo di effettuare quanto segue:

• Evita comandi che richiedono un elevato utilizzo delle risorse - Evita di eseguire operazioni di I/O e calcolo intensive, come i comandi KEYS e SMEMBERS. Suggeriamo l'utilizzo di questo approccio perché queste operazioni aumentano il carico sul cluster e hanno impatto sulle prestazioni del cluster. Utilizza i comandi SCAN e SSCAN.

• Segui le best practice Lua - Evita script Lua di lunga durata e dichiara sempre in anticipo le chiavi utilizzate degli script Lua. Consigliamo questo approccio per determinare che lo script Lua non utilizza comandi tra slot. Assicurati che le chiavi utilizzate negli script Lua appartengano allo stesso slot.

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.

• 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.