Partager via

Mettre à l'échelle une instance d’Azure Managed Redis (préversion)

  • Article

Azure Managed Redis (préversion) propose différentes offres de références SKU et de niveaux qui procurent une flexibilité dans le choix de la taille et des performances de cache. Vous pouvez effectuer un scale-up à une plus grande taille de mémoire, ou passer à un niveau avec plus de performances de calcul. 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 pratiquement 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.

Important

Actuellement, seul un scale-up à une plus grande taille de mémoire ou un niveau de performances supérieur est pris en charge. Le scale-down à des tailles de mémoire inférieures ou un niveau moins performant n’est pas encore pris en charge.

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.

  • 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 à l’édition communautaire de Redis, qui ne peut utiliser qu’un seul processeur virtuel, Azure Managed Redis utilise la pile Redis Enterprise, qui est capable d’utiliser plusieurs processeurs virtuels. Cela signifie que le nombre de processeurs virtuels utilisés par votre instance Redis est directement en rapport avec le débit et les performances 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.

Trois niveaux sont destinés aux données en mémoire :

  • À mémoire optimisée. 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 + calcul). Offre un ratio mémoire/processeur virtuel équilibré (4:1), ce qui le rend idéal pour les charges de travail standard. Il fournit un équilibre sain de ressources de mémoire et de calcul.
  • Optimisé pour le calcul. Conçu pour des charges de travail nécessitant un débit maximal, avec un faible ratio mémoire/processeur virtuel (2:1). Ce niveau est idéal pour les applications qui exigent les performances les plus élevées.

Un niveau stocke les données en mémoire et sur disque :

  • Flash optimisé. 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.

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

Tableau montrant les différentes configurations de mémoire et de processeurs virtuels pour chaque référence SKU et niveau Azure Managed Redis.

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. Un scale-up vers une quantité plus élevée de processeurs virtuels permet de distribuer les requêtes parmi 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.
  • 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é.

Remarque

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

Prérequis/limitations de la mise à l’échelle 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.
  • Vous ne pouvez pas effectuer un scale-down vers une référence SKU avec moins de processeurs virtuels. (Entre les niveaux ou au sein d’un niveau.)
  • Vous ne pouvez pas effectuer un scale-down vers une plus petite taille de mémoire, même si elle a une quantité égale ou supérieure de processeurs virtuels.
  • 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 cache ou pour configurer des groupes de sécurité réseau ou des pare-feu autorisant le trafic vers le cache, votre application peut avoir des difficultés à se connecter une fois que l’enregistrement DNS a été mis à jour.
  • 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 ?.

Mise à l’échelle

Conseil

Vous pouvez modifier la taille de mémoire et le niveau de performance en une seule opération.

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

  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.

    Capture d’écran montrant l’option Mettre à l’échelle sélectionnée dans le menu Ressource d’un cache Enterprise.

  2. Pour effectuer un scale-up, choisissez un autre type de cache, puis Enregistrer.

    Important

    Si vous sélectionnez une référence SKU vers laquelle une mise à l’échelle est impossible, l’option Enregistrer est désactivée. Pour plus d’informations sur les options de mise à l’échelle autorisées, consultez la section Prérequis/limitations de la mise à l’échelle Azure Managed Redis.

    Capture d’écran montrant les niveaux Enterprise dans le volet de travail.

  3. Lorsque le cache est mis à l’échelle vers le nouveau niveau, une notification Mise à l’échelle du Cache Redis s’affiche.

    Capture d’écran montrant une notification de mise à l’échelle d’un cache Enterprise.

  4. Une fois la mise à l’échelle terminée, le statut passe de Mise à l’échelle à En cours d’exécution.

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 myGroup -Name myCache -Sku ComputeOptimized_X20

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 "myCache" --resource-group "myGroup" --sku "ComputeOptimized_X20"

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 ?

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 performance inférieur ou une taille de mémoire plus petite, consultez la section Prérequis/limitations de la mise à l’échelle Azure Managed Redis.

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

Non, le nom et les clés d’accès de votre cache n’ont pas à être modifiés durant 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 avant d’être réapprovisionné. Cela est similaire au processus qui se produit lors d’une mise à jour corrective ou d’une défaillance de l’un des nœuds de cache.
  • Lors de la mise à l’échelle vers une instance avec davantage de processeurs virtuels, de nouvelles partitions sont approvisionnées et ajoutées au cluster de serveurs 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 un scale-down vers un niveau de mémoire inférieur, des données peuvent être perdues si la taille des données dépasse la nouvelle taille réduite lorsque le cache est réduit. En cas de pertes de données lors de la descente en puissante, les clés sont supprimées à l'aide de la stratégie d’éviction allkeys-lru .
  • 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 reste-t-il disponible durant 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 ?

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.

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, le statut passe à En cours d’exécution.

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

Quelle est la différence entre les stratégies de cluster OSS et Entreprise ?

La stratégie de cluster OSS est identique à l’approche de clustering utilisée dans l’édition communautaire de Redis. En règle générale, la stratégie de cluster OSS est plus performante. La stratégie de cluster Entreprise implémente le clustering de sorte que l’instance apparaisse aux yeux d’un client en tant qu’instance Redis non cluster. Cette approche peut être moins performante, mais peut prévenir les problèmes de compatibilité du client. Il n’est actuellement pas possible de basculer entre les stratégies de cluster sur une instance en cours d’exécution. Pour plus d’informations, consultez Stratégie de cluster.

Étapes suivantes