Partager via


Mise à l'échelle

Mise à l’échelle sous charge

Pendant la mise à l’échelle d’un cache sous charge, configurez le paramètre maxmemory-reserved afin d’améliorer la réactivité du système. Pour plus d’informations, consultez Configurer votre paramètre maxmemory-reserved.

Mise à l’échelle de clusters

Essayez de réduire autant que possible les données dans le cache avant de mettre à l’échelle votre cache en cluster. La réduction des données permet de déplacer des volumes de données plus petits, ce qui réduit le temps nécessaire à l’opération de mise à l’échelle. Pour savoir quel est le meilleur moment pour la mise à l’échelle, consultez Quand mettre à l’échelle ?.

Mise à l’échelle avant que la charge ne soit trop élevée

Commencez la mise à l’échelle avant que la charge du serveur ou l’utilisation de la mémoire ne soit trop élevée. Si elle est trop élevée, cela signifie que le serveur Redis est occupé. Le serveur Redis occupé ne dispose pas de suffisamment de ressources pour mettre à l’échelle et redistribuer les données.

Tailles de cache

Si vous utilisez TLS et avez un grand nombre de connexions, effectuez un scale-out pour pouvoir distribuer la charge sur plus de cœurs. Certaines tailles de cache sont hébergées sur des machines virtuelles à quatre cœurs, voire plus. En répartissant les charges de travail sur plusieurs cœurs, vous aidez à diminuer l’utilisation générale du processeur sur les machines virtuelles du cache. Pour plus d’informations, consultez les informations sur les cœurs et les tailles de machines virtuelles.

Mise à l’échelle et mémoire

Vous pouvez mettre à l’échelle vos instances de cache dans le portail Azure. Vous pouvez également faire évoluer votre cache de manière programmatique à l’aide des cmdlets PowerShell, d’Azure CLI et des bibliothèques Gestion Microsoft Azure (MAML).

Quand vous faites un scale-up ou un scale-down du cache dans le portail, les paramètres maxmemory-reserved et maxfragmentationmemory-reserved sont automatiquement mis à l’échelle en fonction de la taille du cache. Par exemple, si maxmemory-reserved est défini sur 3 Go pour un cache de 6 Go et que vous passez le cache à 12 Go, les paramètres sont automatiquement mis à jour sur 6 Go pendant la mise à l’échelle. Quand vous faites un scale-down, l’inverse se produit.

Quand vous faites un scale-up ou un scale-down d’un cache programmatiquement, avec PowerShell, CLI ou l’API Rest, les paramètres maxmemory-reserved ou maxfragmentationmemory-reserved sont ignorés dans le cadre de la demande de mise à jour. Seul votre changement d’échelle est respecté. Vous pouvez mettre à jour ces paramètres de mémoire une fois l’opération de mise à l’échelle terminée.

Pour plus d’informations sur la mise à l’échelle et la mémoire, en fonction de votre niveau, consultez l’article :

Notes

Quand vous faites un scale-up ou un scale-down d’un cache programmatiquement, les paramètres maxmemory-reserved ou maxfragmentationmemory-reserved sont ignorés dans le cadre de la demande de mise à jour. Seul votre changement d’échelle est respecté. Vous pouvez mettre à jour ces paramètres de mémoire une fois l’opération de mise à l’échelle terminée.

La réduction de vos données permet de mettre à l’échelle plus rapidement

Si la conservation des données dans le cache n’est pas obligatoire, envisagez de vider les données avant la mise à l’échelle. Le vidage du cache permet à l’opération de mise à l’échelle de se terminer plus rapidement afin que la nouvelle capacité soit disponible plus tôt. Découvrez plus de détails sur la façon de lancer l’opération de vidage.

Mise à l’échelle des caches de niveau Enterprise

Étant donné que les niveaux Enterprise et Enterprise Flash sont basés sur Redis Enterprise plutôt que sur Redis open source, les bonnes pratiques en matière de mise à l’échelle présentent des différences. Pour plus d’informations, consultez les bonnes pratiques pour les niveaux Enterprise et Enterprise Flash.

Étapes suivantes