Mettre à l’échelle une instance Azure Managed Redis

Azure Managed Redis propose différentes offres de référence et de niveau qui offrent une flexibilité dans le choix de la taille et des performances du cache. Vous pouvez effectuer une mise à l’échelle vers une plus grande taille de mémoire ou passer à un niveau avec davantage de performances de calcul. Vous pouvez également effectuer un scale-down vers un niveau plus petit ou plus approprié. Cet article montre comment mettre à l’échelle votre cache à l’aide du portail Azure et d’outils tels qu’Azure PowerShell et Azure CLI.

Remarque

Étant donné que chaque niveau d’Azure Managed Redis a presque les mêmes fonctionnalités, la mise à l’échelle est généralement utilisée uniquement pour modifier les caractéristiques de mémoire et de performances. La mise à l’échelle des caches Azure Managed Redis géorépliqués reste en Préversion publique.

Types de mise à l’échelle

Azure Managed Redis prend en charge la mise à l’échelle en deux dimensions :

• Mémoire : l’augmentation de la mémoire augmente la taille de l’instance Redis, ce qui vous permet de stocker davantage de données. Lorsque vous réduisez la mémoire, vous devez vous assurer que votre utilisation actuelle de la mémoire est inférieure à la nouvelle taille de mémoire que vous souhaitez utiliser.

• Processeurs virtuels : Azure Managed Redis offrent trois niveaux (À mémoire optimisée, Équilibréet Optimisé pour le calcul) qui ont un nombre croissant de processeurs virtuels pour chaque niveau de mémoire. La mise à l’échelle vers un niveau avec davantage de processeurs virtuels augmente les performances de votre instance sans vous obliger à augmenter la mémoire. Contrairement aux niveaux De base, Standard et Premium d’Azure Cache pour Redis qui utilisent uniquement un seul processeur virtuel, Azure Managed Redis utilise la pile Redis Entreprise. La pile Redis Enterprise est en mesure d’utiliser plusieurs processeurs virtuels, ce qui signifie que le nombre de processeurs virtuels utilisés par votre instance Redis correspond directement aux performances de débit et de latence.

Niveaux de performances

Quatre niveaux Azure Managed Redis sont disponibles, chacun présentant des caractéristiques de performances et des niveaux de prix différents.

Important

Tous les niveaux en mémoire qui utilisent plus de 235 Go de stockage sont en préversion publique, y compris mémoire optimisée M350 et versions ultérieures ; B350 équilibré et supérieur ; et optimisé pour le calcul X350 et versions ultérieures. Tous ces niveaux et versions ultérieures sont en préversion publique.

Tous les niveaux flash optimisés sont en préversion publique.

Niveaux et références SKU en un clin d’œil

Voici trois niveaux de stockage qui stockent les données en mémoire :

• Mémoire optimisée est idéal pour les cas d’utilisation nécessitant beaucoup de mémoire et un ratio mémoire/processeur virtuel élevé (8:1), mais qui n’ont pas besoin des performances de débit les plus élevées. Il fournit un niveau de prix inférieur pour les scénarios où moins de puissance de traitement ou de débit est nécessaire, ce qui en fait un excellent choix pour les environnements de développement et de test.

• Équilibré (mémoire et calcul) offre un ratio mémoire/processeur virtuel équilibré (4:1), ce qui le rend idéal pour les charges de travail standard. Ce niveau fournit un équilibre sain de ressources de mémoire et de calcul.

• Optimisé pour le calcul est conçu pour des charges de travail nécessitant un débit maximal en mémoire, avec un ratio mémoire/processeur virtuel faible (2:1). Ce niveau est idéal pour les applications qui demandent les performances les plus élevées.

  

Voici le niveau qui stocke les données en mémoire et sur disque :

• Flash Optimized (préversion) Permet aux clusters Redis de déplacer automatiquement les données moins fréquemment sollicitées de la mémoire (RAM) vers le stockage NVMe. Cela réduit les performances, mais permet une mise à l’échelle rentable des caches avec des jeux de données volumineux.

  

Performances (débit et latence)

Pour obtenir des benchmarks de performances et plus d’informations sur la façon de mesurer les performances de chaque référence SKU et niveau, consultez Tests de performances avec Azure Managed Redis.

Quand mettre à l’échelle ?

Vous pouvez utiliser les fonctionnalités de surveillance d’Azure Managed Redis afin de surveiller l’intégrité et les performances de votre cache. Utilisez ces informations pour déterminer quand mettre à l’échelle ce cache.

Vous pouvez surveiller les mesures suivantes pour déterminer si vous avez besoin d’effectuer une mise à l’échelle.

• UC
  • Une utilisation élevée du processeur signifie que le serveur Redis n’est pas en mesure de suivre le rythme des requêtes provenant de tous les clients. La mise à l’échelle vers d’autres processeurs virtuels permet de répartir les requêtes entre plusieurs processus Redis. La mise à l’échelle permet également de distribuer le chiffrement/déchiffrement TLS et la connexion/déconnexion, ce qui accélère les instances de cache utilisant TLS.
• Utilisation de la mémoire
  • Une utilisation élevée de mémoire indique que la taille de vos données est trop importante pour la taille actuelle du cache. Envisagez une mise à l’échelle vers une taille de cache avec plus de mémoire. Lorsque vous réduisez la mémoire, vous devez vous assurer que votre utilisation de la mémoire de votre cache actuel est inférieure à la nouvelle taille de mémoire que vous souhaitez utiliser. Vous ne pouvez pas placer un jeu de données volumineux dans une taille de cache plus petite.
• Connexions clientes
  • Chaque taille de cache est limitée à un nombre de connexions clientes pouvant être prises en charge. Si vos connexions clientes sont proches de la limite de la taille du cache, envisagez d’effectuer une mise à l’échelle vers une plus grande taille de mémoire ou un niveau de performances supérieur.
  • Pour plus d’informations sur les limites de connexion par taille de cache, consultez Tests de performances avec Azure Managed Redis.
• Bande passante réseau
  • Si le serveur Redis dépasse la bande passante disponible, les demandes client peuvent expirer parce que le serveur ne peut pas envoyer (push) les données au client suffisamment vite. Pour voir la bande passante utilisée côté serveur, vérifiez les métriques « Lecture du cache » et « Écriture dans le cache ». Si votre serveur Redis dépasse la bande passante réseau disponible, envisagez d’effectuer une mise à l’échelle vers un niveau de performance supérieur ou une plus grande taille de cache.
  • Le choix de la stratégie de cluster affecte la bande passante réseau disponible. En règle générale, la stratégie de cluster OSS a une bande passante réseau plus élevée que la stratégie de cluster Entreprise. Pour plus d’informations, consultez Stratégie de cluster.
  • Pour plus d’informations sur la bande passante réseau disponible par taille de cache, consultez Tests de performances avec Azure Managed Redis.

Pour plus d’informations sur la détermination des niveaux tarifaires de cache à utiliser, consultez Choix du niveau approprié.

Pour plus d’informations sur l’optimisation du processus de mise à l’échelle, consultez les meilleures pratiques pour le guide de mise à l’échelle.

Limitations de la mise à l’échelle d’Azure Managed Redis

• Vous ne pouvez pas effectuer une mise à l’échelle des niveaux À mémoire optimisée, Équilibréou Optimisé pour le calcul vers le niveau Flash optimisé, ou inversement.
• Lorsque vous réduisez la mémoire de votre instance Redis, l’utilisation actuelle de la mémoire de votre instance Redis doit être inférieure à la nouvelle taille de mémoire prévue. Pour plus d’informations, consultez Qu’arrive-t-il à mes données si j’effectue une mise à l’échelle vers une plus petite taille de mémoire ?.
• Lorsque vous réduisez la mémoire ou le processeur virtuel de votre instance Redis, vous pouvez effectuer une mise à l’échelle uniquement vers des références SKU, qui ont une configuration de processeur virtuel et de partition compatible avec la configuration sur votre instance actuelle.
• Dans certains cas, lors de la mise à l’échelle, l’adresse IP sous-jacente de l’instance Redis peut changer. L’enregistrement DNS pour l’instance change et est transparent pour la plupart des applications. Toutefois, si vous utilisez une adresse IP pour configurer la connexion à votre instance Redis, ou pour configurer des groupes de sécurité réseau ou des pare-feu autorisant le trafic vers l’instance Redis, votre application peut avoir des difficultés à se connecter parfois après les mises à jour des enregistrements DNS.
• La mise à l’échelle d’une instance dans un groupe de géoréplication présente des limitations supplémentaires. Pour plus d’informations, consultez Existe-t-il des limitations de mise à l’échelle liées à la géoréplication ?.
• Lorsque vous effectuez un scale-down, vous ne pouvez effectuer une mise à l’échelle qu’à certains niveaux. Pour plus d’informations, consultez Pourquoi puis-je effectuer un scale-down vers un sous-ensemble de références SKU plus petites ?.

Procédure de mise à l’échelle

Dans cette section, nous décrivons comment mettre à l’échelle un cache Redis managé Azure.

Mettre à l'échelle à l’aide du portail Azure

Remarque

La mise à l’échelle des caches Azure Managed Redis géorépliqués reste en Préversion publique.

1. Pour mettre à l’échelle votre cache, accédez à celui-ci dans le portail Azure, puis, dans le menu Ressource, sélectionnez Mise à l’échelle.

2. Pour mettre à l’échelle vos processeurs virtuels, choisissez un autre type de cache , puis sélectionnez Enregistrer.

   Important

   Si vous sélectionnez une référence SKU qui ne peut pas être mise à l’échelle, l’option Enregistrer est désactivée. Consultez la section Limitations de la mise à l’échelle d’Azure Managed Redis pour plus d’informations sur les options de mise à l’échelle autorisées.

3. Une fois la mise à l'échelle terminée, l'état passe de Scaling à Running lors de l'affichage de la section Vue d’ensemble du menu Ressources.

Mise à l’échelle à l’aide de PowerShell

Vous pouvez mettre à l’échelle vos instances d’Azure Managed Redis avec PowerShell à l’aide de la cmdlet Update-AzRedisEnterpriseCache. Vous pouvez modifier la propriété Sku pour sélectionner le niveau et la référence SKU dont vous avez besoin. L’exemple suivant montre comment mettre à l’échelle un cache nommé myCache vers une instance Optimisé pour le calcul X20 (24 Go).

   Update-AzRedisEnterpriseCache -ResourceGroupName <your-group> -Name <your-cache-name> -Sku <sku-name>

Mise à l’échelle à l’aide de l’interface de ligne de commande Azure

Pour mettre à l’échelle vos instances d’Azure Managed Redis à l’aide d’Azure CLI, appelez la commande az redisenterprise update. Vous pouvez modifier la propriété sku pour sélectionner le niveau et la référence SKU dont vous avez besoin. L’exemple suivant montre comment mettre à l’échelle un cache nommé myCache vers une instance Optimisé pour le calcul X20 (24 Go).

az redisenterprise update --cluster-name <your-cache-name> --resource-group <your-resource-group> --sku <name-of-sku>

FAQ sur la mise à l’échelle

La liste suivante présente différentes réponses aux questions les plus fréquemment posées sur la mise à l’échelle d’Azure Managed Redis.

• Puis-je effectuer une mise à l’échelle au sein d’un même niveau ou entre niveaux ?
• Que se passe-t-il pour mes données si j’effectue une mise à l’échelle vers une plus petite taille de mémoire ?
• Après la mise à l’échelle, dois-je modifier le nom ou les clés d’accès de mon cache ?
• Comment fonctionne la mise à l’échelle ?
• Vais-je perdre mes données de cache durant la mise à l’échelle ?
• Mon cache est-il disponible pendant la mise à l’échelle ?
• Existe-t-il des limitations de mise à l’échelle liées à la géoréplication ?
• Quelle est la durée d’une mise à l’échelle ?
• Comment savoir quand la mise à l’échelle est terminée ?
• Azure Managed Redis utilise-t-il le clustering ?Combien de partitions chaque référence SKU Azure Managed Redis utilise-t-elle ?
• Comment les clés sont-elles distribuées dans un cluster ?
• Quelle est la taille de cache la plus grande que je peux créer ?
• Pourquoi puis-je effectuer un scale-down vers un sous-ensemble de références SKU plus petites ?
• La stratégie de clustering peut-elle être modifiée après avoir sélectionné OSS ou Enterprise Cluster ?

Puis-je effectuer une mise à l’échelle au sein d’un même niveau ou entre niveaux ?

Vous pouvez toujours effectuer une mise à l’échelle vers un niveau de performance supérieur à la même taille de mémoire ou à une plus grande taille de mémoire au sein du même niveau de performance. Pour effectuer une mise à l’échelle vers un niveau de performances inférieur ou une taille de mémoire inférieure, nous vous recommandons d’exécuter l’API REST « listskusforscaling » pour obtenir la liste des références SKU auxquelles vous pouvez effectuer une mise à l’échelle.

az redisenterprise list-skus-for-scaling --cluster-name <your-redis-instance> --resource-group <your-resource-group>

Que se passe-t-il pour mes données si j’effectue une mise à l’échelle vers une plus petite taille de mémoire ?

Vous pouvez effectuer une mise à l’échelle vers une taille de mémoire inférieure uniquement si l’utilisation actuelle de la mémoire est inférieure à la taille de mémoire prévue. Si l’utilisation actuelle de la mémoire est supérieure à la taille inférieure prévue, votre demande de mise à l’échelle échoue. Vous pouvez réduire l’utilisation actuelle de la mémoire en supprimant des paires de valeurs de clé indésirables ou en exécutant l’opération de vidage.

az redisenterprise database flush --cluster-name <your-redis-instance> --resource-group <your-resource-group>

Après la mise à l’échelle, dois-je modifier le nom ou les clés d’accès de mon cache ?

Non, votre nom de cache et vos clés d’accès ne sont pas modifiés lors d’une opération de mise à l’échelle.

Comment fonctionne la mise à l’échelle ?

• Lorsque vous mettez à l’échelle une instance Redis, l’un des nœuds du cluster Redis est arrêté et réapprovisionné à la nouvelle taille. Ensuite, les données sont transférées, puis l’autre nœud effectue un basculement similaire à la suite, avant d’être réapprovisionné. L’arrêt et le reprovisionnement sont similaires au processus qui se produit pendant la mise à jour corrective ou une défaillance de l’un des nœuds d’un cache.
• Lorsque vous effectuez une mise à l’échelle vers une instance avec plus de processeurs virtuels, de nouvelles partitions sont provisionnées et ajoutées au cluster de serveur Redis. Les données sont ensuite repartitionnées entre toutes les partitions.

Pour plus d’informations sur la façon dont Azure Managed Redis gère le partitionnement, consultez Configuration du partitionnement.

Vais-je perdre mes données de cache durant la mise à l’échelle ?

• Si le mode haute disponibilité est activé, toutes les données doivent être conservées pendant les opérations de mise à l’échelle.
• Si vous effectuez une mise à l’échelle vers un niveau de mémoire plus petit, vous devez vous assurer que l’utilisation actuelle de la mémoire est inférieure à la nouvelle taille de mémoire prévue. Si l’utilisation actuelle de la mémoire est supérieure à la taille de mémoire de référence SKU prévue, vous pouvez vider vos données à l’aide de l’opération de vidage ou choisir manuellement les valeurs de clé à supprimer.
• Si le mode haute disponibilité est désactivé, toutes les données sont perdues et le cache n’est pas disponible pendant l’opération de mise à l’échelle.

Mon cache est-il disponible pendant la mise à l’échelle ?

• Les instances Azure Managed Redis avec le mode haute disponibilité activé restent disponibles pendant l’opération de mise à l’échelle. Toutefois, les connexions peuvent être perturbées lors de la mise à l’échelle de ces caches. Ces sauts de connexion sont le plus souvent brefs, et les clients Redis peuvent généralement rétablir leur connexion instantanément.
• Si le mode haute disponibilité est désactivé, l’instance Azure Managed Redis est hors connexion pendant les opérations de mise à l’échelle.

Existe-t-il des limitations de mise à l’échelle liées à la géoréplication ?

La mise à l’échelle des caches géorépliqués est en aperçu public. Avec la géoréplication active configurée, vous ne pouvez pas combiner des tailles de cache dans un groupe de géoréplication. Par conséquent, la mise à l’échelle des caches dans un groupe géo nécessite quelques étapes supplémentaires. Pour obtenir des instructions, consultez Mise à l’échelle des instances dans un groupe de géoréplication.

Le scale-down vers une plus petite taille de mémoire ou un nombre de partitions inférieur n’est pas pris en charge pour les mises en cache géorépliquées. Pour plus d’informations, consultez combien de fragments utilise chaque SKU Redis managé Azure pour connaître les fragments de votre cluster.

Quelle est la durée d’une mise à l’échelle ?

Le temps de mise à l’échelle dépend de plusieurs facteurs. Voici quelques facteurs qui peuvent affecter le temps nécessaire à une mise à l’échelle.

• Quantité de données : plus la quantité de données est importante et plus leur réplication est longue.
• Nombre élevé de demandes d’écriture : un nombre plus élevé d’écritures signifie que plus de données sont répliquées entre les nœuds et les partitions.
• Utilisation élevée du processeur : une utilisation élevée du processeur signifie que le serveur Redis est occupé, et que le nombre de cycles de processeur disponibles pour effectuer la redistribution des données est limité.

En règle générale, lorsque vous mettez à l’échelle une instance sans données, l’opération prend environ dix minutes.

Comment savoir quand la mise à l’échelle est terminée ?

Le déroulement de l’opération de mise à l’échelle est affiché dans le portail Azure. Une fois la mise à l’échelle terminée, l’état du cache est en cours d’exécution lors de l’affichage vue d’ensemble dans le menu Ressources.

Azure Managed Redis utilise-t-il le clustering ?

Contrairement au Cache Azure pour Redis, Azure Managed Redis utilise le clustering sur tous les niveaux et références SKU. Le clustering permet des optimisations significatives des performances. Chaque référence SKU d’Azure Managed Redis est configurée pour un nombre optimisé de partitions pour le nombre de processeurs virtuels disponibles. Le nombre de partitions n’est pas configurable par l’utilisateur.

Combien de partitions chaque référence SKU Azure Managed Redis utilise-t-elle ?

Étant donné qu’Azure Managed Redis s’exécute sur le logiciel Redis Enterprise, les partitions peuvent être utilisées dans une configuration plus dense que dans l’édition communautaire de Redis. Pour en savoir plus sur le nombre spécifique de partitions utilisées dans chaque référence SKU, consultez Configuration du partitionnement.

Comment les clés sont-elles distribuées dans un cluster ?

Selon la documentation Redis concernant le modèle de distribution de clés, l’espace de clé est fractionné en 16 384 emplacements. Chaque clé est hachée et affectée à l’un de ces emplacements, qui sont répartis entre les nœuds du cluster. Vous pouvez configurer la partie de la clé qui est hachée pour vous assurer que plusieurs clés se trouvent dans la même partition à l’aide de balises de hachage.

• Clés avec une balise de hachage : si une partie de la clé est placée entre { et }, seule cette partie de la clé est hachée aux fins de détermination de l'emplacement de hachage d'une clé. Par exemple, les trois clés suivantes se trouvent dans la même partition : {key}1, {key}2 et {key}3, étant donné que seule la partie key du nom est hachée. Pour obtenir une liste complète des spécifications de balises de hachage de clés, consultez Balises de hachage de clés.
• Clés sans balise de hachage : le nom de clé entier est utilisé pour le hachage, ce qui aboutit à une distribution statistiquement égale entre les partitions du cache.

Pour optimiser les performances et le débit, nous vous recommandons de distribuer les clés uniformément. Si vous utilisez des clés avec une balise de hachage, il incombe à l’application de vérifier que les clés sont distribuées de façon égale.

Pour plus d’informations, consultez Modèle de distribution de clés, Partitionnement de données de cluster Redis et Balises de hachage de clés.

Quelle est la taille de cache la plus grande que je peux créer ?

La plus grande taille de cache que vous pouvez avoir est 4,5 To, appelée instance Flash optimisé A4500. Tarification d’Azure Cache pour Redis

Pourquoi puis-je seulement réduire à un sous-ensemble de références SKU plus petites ?

Pour maintenir la compatibilité avec le nombre de partitions et de processeurs virtuels, vous êtes autorisé à effectuer un scale-down uniquement à certaines références SKU. Vous pouvez voir à quels SKUs votre instance Redis peut réduire sa taille en vérifiant les options disponibles dans la section Mise à l’échelle du portail Azure. Vous pouvez également exécuter la commande CLI suivante.

Vous pouvez voir à quels SKUs votre instance Redis peut réduire sa taille en vérifiant les options disponibles dans la section Mise à l’échelle du portail Azure.

az redisenterprise list-skus-for-scaling --cluster-name <your-redis-instance> --resource-group <your-resource-group>

La stratégie de clustering peut-elle être modifiée après avoir sélectionné OSS ou Enterprise Cluster ?

Une fois que vous avez défini une stratégie de clustering sur OSSCluster ou EnterpriseCluster lorsque vous créez un cache, vous ne pouvez pas le modifier. Pour basculer vers une autre stratégie de clustering, vous devez supprimer le cache Redis et le recréer avec la configuration souhaitée. Seuls les caches avec la stratégie non cluster peuvent être mis à jour vers une configuration en cluster après le déploiement.

Contenu connexe

• Meilleures pratiques relatives à la mise à l’échelle