Bonnes pratiques : redimensionnement des clusters en ligne

Avant de lancer le repartitionnement, procédez comme suit :

• Testez votre application – Testez le comportement de votre application lors du repartitionnement dans un environnement intermédiaire si possible.

• Obtenez une notification anticipée pour les problèmes de mise à l'échelle – Le repartitionnement est une opération gourmande en calculs. C'est pourquoi nous recommandons de maintenir le CPU taux d'utilisation à moins de 80 % sur les instances multicœurs et à moins de 50 % sur les instances monocœurs lors du repartage. Surveillez les métriques de MemoryDB et initiez le repartage avant que votre application ne commence à détecter des problèmes de dimensionnement. Les métriques qu'il est utile de suivre sont CPUUtilization, NetworkBytesIn, NetworkBytesOut, CurrConnections, NewConnections, FreeableMemory, SwapUsage et BytesUsedForMemoryDB.

• Assurez-vous qu'une mémoire suffisante est disponible avant de procéder à une diminution d'échelle – Si vous procédez à une diminution d'échelle, assurez-vous que cette mémoire disponible sur les partitions à conserver est au moins égale à une fois et demi la mémoire utilisée sur les partitions que vous prévoyez de supprimer.

• Initiez le repartitionnement pendant les heures creuses – Cette pratique permet de réduire l'impact de la latence et du débit sur le client pendant l'opération de repartitionnement. Elle permet aussi d'exécuter le repartitionnement plus rapidement, car un plus grand nombre de ressources peut être utilisé pour la redistribution des emplacements.

• Vérifiez le comportement hors délai du client – Certains clients peuvent observer une latence plus élevée lors d'un redimensionnement des clusters en ligne. La configuration de votre bibliothèque client avec un délai d'expiration supérieur peut être une aide en offrant au système le temps de se connecter même en cas de conditions de charge plus importantes sur le serveur. Dans certains cas, vous pouvez ouvrir un grand nombre de connexions sur le serveur. Dans ces cas, pensez à ajouter un backoff exponentiel à la logique de reconnexion. Cela peut empêcher qu'une rafale de nouvelles connexions atteignent le serveur simultanément.

Pendant le repartitionnement, appliquez les recommandations suivantes :

• Évitez les commandes onéreuses – Évitez d'exécuter des opérations gourmandes en calcul et en I/O, telles que les commandes KEYS et SMEMBERS. Nous suggérons cette approche, car ces opérations augmentent la charge sur le cluster et ont un impact sur ses performances. Utilisez à la place les commandes SCAN et SSCAN.

• Suivez les bonnes pratiques Lua – Évitez les longues exécutions de scripts Lua et déclarez toujours les clés utilisées dans les scripts Lua en amont. Nous recommandons cette approche pour déterminer que le script Lua n'utilise pas de commandes inter-emplacements. Veillez à ce que les clés utilisées dans les scripts Lua appartiennent au même emplacement.

Après le repartitionnement, notez ce qui suit :

• La diminution d'échelle peut être partiellement réussie si la mémoire sur les partitions cibles est insuffisante. Si un tel résultat se produit, vérifiez la mémoire disponible et réessayez l'opération, si nécessaire.

• Il n'est pas procédé à la migration des emplacements ayant des éléments volumineux. En particulier, les emplacements avec des éléments supérieurs à une post-sérialisation de 256 Mo ne font pas l'objet d'une migration.

• Les commandes FLUSHALL et FLUSHDB ne sont pas prises en charge dans les scripts Lua lors d’une opération de repartitionnement.