Partager via

Mettre à l'échelle une instance Cache Redis Azure

  • S’applique à: ✅ Azure Cache for Redis

Important

Azure Cache pour Redis a annoncé sa chronologie de mise hors service pour toutes les références SKU. Nous vous recommandons de déplacer vos instances Azure Cache pour Redis existantes vers Azure Managed Redis dès que vous le pouvez.

Pour plus d’informations sur la mise hors service :

Azure Cache pour Redis est proposé sous différents niveaux, permettant de choisir parmi plusieurs tailles et fonctionnalités de cache en toute flexibilité. Grâce à la mise à l’échelle, vous pouvez modifier la taille, le niveau et le nombre de nœuds après avoir créé un instance de cache pour répondre aux besoins de votre application. Cet article montre comment mettre à l’échelle votre cache à l’aide du portail Azure et d’outils tels qu’Azure PowerShell et Azure CLI.

Types de mise à l’échelle

Il existe fondamentalement deux façons de mettre à l’échelle une instance Azure Cache pour Redis :

  • Le scale-up augmente la taille de la machine virtuelle exécutant le serveur Redis, en ajoutant davantage de mémoire, de processeurs virtuels et de bande passante réseau. Le scale-up est également appelé mise à l’échelle verticale. Le contraire du scale-up est le scale-down.

  • Le scale-out divise l’instance de cache en plusieurs nœuds de même taille, ce qui augmente la mémoire, les processeurs virtuels et la bande passante réseau via la parallélisation. Le scale-out est également appelé mise à l’échelle horizontale ou partitionnement. Le contraire du scale-out est le scale-in. Dans la communauté Redis, le scale-out est fréquemment appelé clustering.

Étendue de la disponibilité

Niveau De base et Standard Haute qualité Entreprise et Enterprise Flash
Mise à l'échelle Oui Oui Oui
Effectuer un scale-down Oui Oui Non
Scale Out Non Oui Oui
Scale-in Non Oui Non

Quand mettre à l’échelle ?

Les fonctionnalités de surveillance d’Azure Cache pour Redis permettent 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.

  • Charge du serveur Redis
    • Une charge élevée du serveur Redis signifie que le serveur n’est pas en mesure de suivre le rythme des demandes provenant de tous les clients. Étant donné qu’un serveur Redis est un processus thread unique, il est généralement plus utile d’effectuer un scale-out que d’effectuer un scale-up. Le scale-out, en activant le clustering, permet de répartir les fonctions de surcharge entre plusieurs processus Redis. Le scale-out permet également de distribuer le chiffrement/déchiffrement TLS et la connexion/déconnexion, ce qui accélère les instances de cache à l’aide de TLS.
    • Le scale-up peut toujours être utile pour réduire la charge du serveur, car les tâches en arrière-plan peuvent tirer parti des processeurs virtuels plus nombreux et libérer le thread pour le processus de serveur Redis principal.
    • Les niveaux Enterprise et Enterprise Flash utilisent Redis Enterprise plutôt que Redis open source. L’un des avantages de ces niveaux est que le processus serveur Redis peut tirer parti de plusieurs processeurs virtuels. Avec plusieurs processeurs virtuels, le scale-up et le scale-out dans ces niveaux peuvent être utiles pour réduire la charge du serveur.
  • 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. Le scale-up ou le scale-out sont efficaces ici.
  • Connexions client
    • 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 un scale-up jusqu’à un niveau plus élevé. L’exécution d’un scale-out à l’aide du clustering n’augmente pas le nombre de connexions clientes prises en charge.
    • Pour plus d’informations sur les limites de connexions par taille de cache, consultez Tarification Azure Cache pour 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, vous devez envisager un scale-out ou un scale-up vers une plus grande taille de cache avec une bande passante réseau plus large.
    • Pour les caches de niveau Enterprise utilisant la stratégie de cluster Enterprise, le scale-out n’augmente pas la bande passante réseau.
    • Pour plus d’informations sur la bande passante réseau disponible par taille de cache, consultez FAQ sur la planification d’Azure Cache pour Redis.
  • Analyses internes de Defender
    • Sur les caches standard C0 et C1, lorsque l’analyse interne de Defender est en cours sur les machines virtuelles, vous pouvez observer de courtes pointes de la charge du serveur qui ne sont pas dues à une augmentation des demandes de cache. Vous constatez une latence plus élevée pour les demandes lorsque des analyses internes de Defender sont exécutées sur ces niveaux plusieurs fois par jour. Les caches sur les niveaux C0 et C1 n’ont qu’un seul cœur pour le multitâche, divisant le travail pour servir l’analyse antivirus interne et les requêtes Redis. Vous pouvez réduire l’effet en effectuant une mise à l’échelle vers une offre de niveau supérieur avec plusieurs cœurs d’UC, tels que C2.
    • La taille accrue du cache sur les niveaux supérieurs permet de résoudre les problèmes de latence. En outre, au niveau C2, vous pouvez prendre en charge autant de 2 000 connexions clientes.

Pour plus d’informations sur la façon de déterminer le niveau tarifaire de cache à utiliser, consultez Choix du niveau approprié et FAQ sur la planification d’Azure Cache pour Redis.

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 Cache pour Redis

Vous pouvez effectuer un scale-up/scale-down selon un niveau tarifaire différent avec les restrictions suivantes :

  • Vous ne pouvez pas passer d’un niveau de tarification supérieur à un niveau de tarification inférieur.
    • Vous ne pouvez pas effectuer un scale-down d’un cache Enterprise ou Enterprise Flash vers un autre niveau.
    • Vous ne pouvez pas passer d’un cache Premium à un cache Standard ou De base.
    • Vous ne pouvez pas passer d’un cache Standard à un cache De base.
  • Vous pouvez passer d’un cache De base à un cache Standard, mais vous ne pouvez pas modifier la taille en même temps. Si vous avez besoin d’une autre taille, vous pouvez effectuer par la suite une opération de mise à l’échelle vers la taille voulue.
  • Vous ne pouvez pas passer directement d’un cache De base à un cache Premium. Tout d’abord, passez du niveau De base au niveau Standard dans une opération de mise à l’échelle, puis du niveau Standard au niveau Premium dans l’opération de mise à l’échelle suivante.
  • Vous ne pouvez pas mettre à l’échelle depuis une taille supérieure vers la taille C0 (250 Mo). Cependant, vous pouvez effectuer un scale-in vers n’importe quelle autre taille du même niveau tarifaire. Par exemple, vous pouvez effectuer un scale-in de C5 Standard à C1 Standard.
  • Vous ne pouvez pas effectuer un scale-up d’un cache Premium, Standard ou De base à un cache Enterprise ou Enterprise Flash.
  • Vous ne pouvez pas effectuer une mise à l’échelle entre Enterprise et Enterprise Flash.

Vous pouvez effectuer un scale-out/scale-in avec les restrictions suivantes :

  • Le scale out est uniquement pris en charge dans les niveaux Premium, Enterprise et Enterprise Flash.
  • Le scale-in n’est pris en charge que sur le niveau Premium.
  • Sur le niveau Premium, le clustering doit d’abord être activé avant d’effectuer un scale-in ou un scale-out.
  • Pour le niveau Premium, la prise en charge de la mise à l’échelle jusqu’à 10 fragments est généralement disponible. La prise en charge de jusqu’à 30 partitions est en préversion. (Pour les caches avec deux réplicas, la limite de partitions est de 20. Avec trois réplicas, la limite de partitions est de 15.)
  • Seuls les niveaux Enterprise et Enterprise Flash peuvent effectuer un scale-up et un scale-out simultanément.

Guide de mise à l’échelle – De base, Standard et Premium

Effectuer un scale-up et un scale-down à 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 la mise à l’échelle dans le menu des ressources.

  2. Choisissez un niveau tarifaire dans le volet de travail, puis choisissez Sélectionner.

    Capture d’écran montrant les niveaux Azure Cache pour Redis.

  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 la notification de mise à l'échelle.

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

Remarque

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 le paramètre maxmemory-reserved a la valeur 3 Go sur un cache de 6 Go et que vous augmentez à 12 Go l’échelle du cache, le paramètre est automatiquement mis à jour à 6 Go pendant la mise à l’échelle. Quand vous faites un scale-down, l’inverse se produit.

Effectuer un scale-up et un scale-down à l’aide de PowerShell

Vous pouvez mettre à l’échelle vos instances d’Azure Cache pour Redis avec PowerShell à l’aide de la cmdlet Set-AzRedisCache lorsque les propriétés Sizeou Sku sont modifiées. L’exemple suivant montre comment mettre à l’échelle un cache nommé myCache vers un cache de 6 Go du même niveau.

   Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -Size 6GB

Pour plus d’informations sur la mise à l’échelle avec PowerShell, consultez Pour mettre à l’échelle un cache Azure pour Redis à l’aide de PowerShell.

Effectuer un scale-up et un scale-down à l’aide d’Azure CLI

Pour mettre à l’échelle vos instances Azure Cache pour Redis à l’aide d’Azure CLI, appelez la commande az redis update. Utilisez la propriété sku.capacity pour effectuer une mise à l’échelle au sein d’un niveau, par exemple d’un cache C0 Standard vers un cache C1 Standard :

az redis update --cluster-name myCache --resource-group myGroup --set "sku.capacity"="2"

Utilisez les propriétés « sku.name » et « sku.family » pour effectuer un scale-up vers un autre niveau, par exemple d’un cache C1 Standard vers un cache P1 Premium :

az redis update --cluster-name myCache --resource-group myGroup --set "sku.name"="Premium" "sku.capacity"="1" "sku.family"="P"

Pour plus d’informations sur la mise à l’échelle avec l’interface de ligne de commande Azure, consultez Modification des paramètres d’un cache Azure pour Redis existant.

Remarque

Quand vous effectuez un scale-up ou un scale-down d’un cache programmatiquement (par exemple avec PowerShell ou Azure CLI), 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.

  • Last updated on