Mettre à l'échelle une instance Cache Redis Azure

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 :

• Mise hors service d’Azure Cache pour Redis : ce qu’il faut savoir et comment s’y préparer
• Faq sur la mise hors service d’Azure Cache pour Redis

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 avec 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.

   

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

   

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

   

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.

Scale-out et scale-in – Premium uniquement

Créer un cache qui est mis à l’échelle à l’aide du clustering

Le clustering est activé lors de la création du cache à partir du volet de travail, lorsque vous créez un Azure Cache pour Redis.

1. Utilisez le Guide de démarrage rapide Créer un cache Redis open source pour commencer à créer un cache à l’aide du portail Azure.

2. Sous l’onglet Avancé d’une instance de cache Premium, configurez les paramètres pour le port non TLS, le clustering et la persistance des données. Pour activer le clustering, sélectionnez Activer.

   

   Vous pouvez avoir jusqu’à 30 partitions dans le cluster. Après avoir sélectionné Activer, faites glisser le curseur ou saisissez un nombre compris entre 1 et 30 pour Nombre de partitions, puis sélectionnez OK.

   Chaque partition est une paire de cache principal/réplica gérée par Azure. La taille totale du cache est calculée en multipliant le nombre de partitions par la taille de cache sélectionnée dans le niveau tarifaire.

   

   Une fois le cache créé, vous vous y connectez et l’utilisez tout comme un cache hors cluster. Redis distribue les données parmi les partitions de Cache. Si les diagnostics sont activés, les métriques sont capturées séparément pour chaque partition et peuvent être consultées dans Azure Cache pour Redis à l’aide du menu Ressource.

3. Terminez la création du cache à l’aide du guide de démarrage rapide.

La création du cache prend un certain temps. Vous pouvez surveiller la progression dans la page Vue d’ensemble du Azure Cache pour Redis. Lorsque État indique En cours d’exécution, le cache est prêt pour utilisation.

Remarque

Il doit exister quelques différences mineures dans votre application cliente lorsque le clustering est configuré. Pour en savoir plus, voir, Dois-je apporter des modifications à mon application cliente pour utiliser le clustering ?

Pour accéder à un exemple de code relatif à l’utilisation du clustering avec le client StackExchange.Redis, consultez la partie clustering.cs de l’exemple Hello World.

Effectuer un scale-in ou un scale-out d’un cache Premium en cours d’exécution

Pour modifier la taille du cluster sur un cache Premium que vous avez créé précédemment et qui est déjà en cours d’exécution avec le clustering activé, sélectionnez Taille du cluster dans le menu Ressource.

Pour modifier la taille du cluster, utilisez le curseur ou entrez un nombre compris entre 1 et 30 dans la zone de texte Nombre de partitions. Cliquez ensuite sur OK pour enregistrer.

L’augmentation de la taille du cluster a pour effet d’augmenter le débit maximal et la taille du cache. L’augmentation de la taille du cluster n’augmente pas le nombre maximal de connexions disponibles pour les clients.

Effectuer un scale-out et un scale-in à l’aide de PowerShell

Vous pouvez effectuer un scale-out de vos instances d’Azure Cache pour Redis avec PowerShell à l’aide de la cmdlet Set-AzRedisCache lorsque la propriété ShardCount est modifiée. L’exemple suivant montre comment effectuer un scale-out d’un cache nommé myCache pour utiliser trois partitions (c’est-à-dire un scale-out d’un facteur de trois)

   Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -ShardCount 3

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-out et un scale-in à 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 et utilisez la propriété shard-count. L’exemple suivant montre comment effectuer un scale-out d’un cache nommé myCache pour utiliser trois partitions (c’est-à-dire un scale-out d’un facteur de trois).

az redis update --cluster-name myCache --resource-group myGroup --set shard-count=3

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.

Remarque

La mise à l'échelle d’un cluster exécute la commande MIGRATE qui est coûteuse en ressources. Pour un impact minimal, envisagez d’exécuter cette opération pendant les heures creuses. Pendant le processus de migration, vous observez un pic de charge du serveur. La mise à l’échelle d’un cluster est un processus long et le temps nécessaire dépend du nombre de clés et de la taille des valeurs associées à celles-ci.

Guide pratique pour effectuer un scale-up et un scale-out – Niveaux Enterprise et Enterprise Flash

Les niveaux Enterprise et Enterprise Flash peuvent effectuer un scale-up et un scale-out en une seule opération. Les autres niveaux nécessitent des opérations distinctes pour chaque action.

Attention

Les niveaux Enterprise et Enterprise Flash ne prennent pas encore en charge les opérations de scale-down ou scale-in.

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.

   

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

   Important

   Vous pouvez uniquement effectuer un scale-up à ce stade. Vous ne pouvez pas effectuer un scale-down.

   

3. Pour effectuer un scale-out, augmentez le curseur Capacité. La capacité augmente par incréments de deux. Ce nombre reflète le nombre de nœuds Redis Enterprise sous-jacents qui sont ajoutés. Ce nombre est toujours un multiple de deux pour refléter l’ajout de nœuds pour les partitions primaires et réplicas.

   Important

   Vous pouvez uniquement effectuer un scale-out, ce qui augmente la capacité, pour l’instant. Vous ne pouvez pas effectuer un scale-in.

   

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

   

5. 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 Cache pour Redis avec PowerShell à l’aide de la cmdlet Update-AzRedisEnterpriseCache. Vous pouvez modifier la propriété Sku pour mettre à l’échelle l’instance. Vous pouvez modifier la propriété Capacity pour effectuer un scale-out de l’instance. L’exemple suivant montre comment mettre à l’échelle un cache nommé myCache vers une instance Enterprise E20 (25 Go) avec une capacité de 4.

   Update-AzRedisEnterpriseCache -ResourceGroupName myGroup -Name myCache -Sku Enterprise_E20 -Capacity 4

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

Pour mettre à l’échelle vos instances Azure Cache pour Redis à l’aide d’Azure CLI, appelez la commande az redisenterprise update. Vous pouvez modifier la propriété sku pour mettre à l’échelle l’instance. Vous pouvez modifier la propriété capacity pour effectuer un scale-out de l’instance. L’exemple suivant montre comment mettre à l’échelle un cache nommé myCache vers une instance Enterprise E20 (25 Go) avec une capacité de 4.

az redisenterprise update --cluster-name "myCache" --resource-group "myGroup" --sku "Enterprise_E20" --capacity 4

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 du cache Azure pour Redis.

• Puis-je mettre à l’échelle vers, depuis ou au sein d’un cache Premium ?
• 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 ?
• Puis-je utiliser toutes les fonctionnalités du niveau Premium après la mise à l’échelle ?
• Les paramètres personnalisés de mes bases de données sont-ils affectés au cours de 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 ?
• Opérations qui ne sont pas prises en charge
• Quelle est la durée d’une mise à l’échelle ?
• Comment savoir quand la mise à l’échelle est terminée ?
• Dois-je apporter des modifications à mon application cliente pour utiliser le clustering ?
• 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 ?
• Tous les clients Redis prennent-ils en charge le clustering ?
• Comment puis-je me connecter à mon cache quand le clustering est activé ?
• Puis-je me connecter directement aux différentes partitions de mon cache ?
• Puis-je configurer le clustering pour un cache créé précédemment ?
• Puis-je configurer le clustering pour un cache De base ou Standard ?
• Puis-je utiliser le clustering avec les fournisseurs d’état de session ASP.NET Redis et de mise en cache de la sortie ?
• J’obtiens des exceptions MOVE lorsque j’utilise StackExchange.Redis et le clustering. Que dois-je faire ?
• Quelle est la différence entre le clustering OSS et le clustering Enterprise sur les caches de niveau Enterprise ?
• Combien de partitions les caches de niveau Enterprise utilisent-ils ?

Puis-je mettre à l’échelle vers, depuis ou au sein d’un cache Premium ?

• Vous ne pouvez pas passer d’un niveau tarifaire de cache Premium à un niveau tarifaire De base ou Standard.
• Vous pouvez passer d’un niveau tarifaire de cache Premium à un autre.
• 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 une opération de mise à l’échelle ultérieure.
• Vous ne pouvez pas effectuer une mise à l’échelle d’un cache Premium vers un cache Enterprise ou Enterprise Flash.
• Si vous avez activé le clustering à la création de votre cache Premium, vous pouvez modifier la taille du cluster. Si votre cache a été créé sans que le clustering soit activé, vous pourrez configurer le clustering par la suite.

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 de votre cache ne changent pas lors d’une opération de mise à l’échelle.

Comment fonctionne la mise à l’échelle ?

• Quand vous mettez à l’échelle un cache de base vers une taille différente, celui-ci est arrêté et un nouveau cache est provisionné avec la nouvelle taille. Pendant ce temps, le cache n’est pas disponible et toutes les données qu’il contenait sont perdues.
• Quand vous mettez à l’échelle un cache De base vers un cache Standard, un cache de réplica est provisionné et les données sont copiées du cache principal vers le cache de réplica. Le cache reste disponible pendant le processus de mise à l'échelle.
• Quand vous mettez à l’échelle un cache Standard, Premium, Enterprise ou Enterprise Flash vers une taille différente, l’un des réplicas est arrêté et réapprovisionné avec la nouvelle taille et les données sont transférées. L’autre réplica effectue ensuite un basculement avant d’être réapprovisionné, selon un processus similaire à celui intervenant lors d’une défaillance d’un des nœuds du cache.
• Quand vous effectuez un scale-out d’un cache en cluster, de nouvelles partitions sont provisionnées et ajoutées au cluster de serveurs Redis. Les données sont ensuite repartitionnées entre toutes les partitions.
• Quand vous effectuez un scale-in d’un cache en cluster, les données sont d’abord repartitionnées, puis la taille du cluster est réduite au nombre de partitions requis.
• Lors de la mise à l’échelle ou de la migration de votre cache vers un autre cluster, l’adresse IP sous-jacente du cache peut changer. L’enregistrement DNS pour le cache change et est transparent pour la plupart des applications. Toutefois, si vous utilisez une adresse IP pour configurer la connexion à votre cache ou configurer des groupes de sécurité réseau ou des pare-feu qui autorisent le trafic vers le cache, votre application peut avoir des difficultés à se connecter après les mises à jour des enregistrements DNS.

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

• Quand vous mettez à l’échelle un cache De base vers une nouvelle taille, toutes les données sont perdues et le cache n’est plus disponible pendant l’opération de mise à l’échelle.
• Quand vous mettez à l’échelle un cache De base vers un cache Standard, les données qui se trouvent dans le cache sont généralement conservées.
• Lorsque vous mettez à l’échelle un cache Standard, Premium, Enterprise ou Enterprise Flash vers une plus grande taille, toutes les données sont généralement conservées. Lorsque vous mettez à l’échelle un cache Standard ou Premium à une taille plus petite, les données peuvent être perdues si la taille des données d’origine dépasse la nouvelle taille plus petite. 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 .

Puis-je utiliser toutes les fonctionnalités du niveau Premium après la mise à l’échelle ?

Non, certaines fonctionnalités peuvent être définies uniquement lorsque vous créez un cache au niveau Premium et elles ne sont pas disponibles après la mise à l’échelle.

Les fonctionnalités suivantes ne peuvent pas être ajoutées après avoir créé le cache Premium :

• Injection de réseaux virtuels
• Ajout de la redondance de zone
• Utilisation de plusieurs réplicas par principal

Pour utiliser l’une de ces fonctionnalités, vous devez créer une instance de cache dans le niveau Premium.

Les paramètres personnalisés de mes bases de données sont-ils affectés au cours de la mise à l’échelle ?

Si vous avez configuré une valeur personnalisée pour le paramètre databases lors de la création du cache, n’oubliez pas que certains niveaux de tarification appliquent des limites des bases de données différentes. Voici quelques considérations relatives à la mise à l’échelle dans le cadre de ce scénario :

• Lors d’une mise à l’échelle vers un niveau de tarification présentant une limite databases inférieure à celle du niveau de tarification actuel :
  • Si vous utilisez le nombre par défaut de databases, soit 16 pour tous les niveaux tarifaires, aucune donnée n’est perdue.
  • Si vous utilisez un nombre personnalisé de databases qui s’inscrit dans les limites du niveau vers lequel vous effectuez la mise à l’échelle, ce paramètre databases est conservé et aucune donnée n’est perdue.
  • Si vous utilisez un nombre de databases personnalisé qui dépasse les limites du nouveau niveau, le paramètre databases est réduit aux limites de celui-ci, et toutes les données contenues dans les bases de données supprimées sont perdues.
• Lors d’une mise à l’échelle vers un niveau tarifaire présentant une limite databases identique ou supérieure à celle du niveau actuel, votre paramètre databases est conservé et aucune donnée n’est perdue.

Si les caches Standard, Premium, Enterprise et Enterprise Flash bénéficient d’une garantie de disponibilité à 99,9 % adossée à un contrat de niveau de service, aucun contrat de ce type ne couvre la perte de données.

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

• Les caches Standard, Premium, Enterprise et Enterprise Flash restent disponibles pendant l’opération de mise à l’échelle. Toutefois, de petites anomalies de connexion peuvent se produire lors de la mise à l’échelle de ces caches, ainsi que lors de la mise à l'échelle des caches De base vers Standard. Ces sauts de connexion sont censés être brefs et des clients Redis peuvent généralement rétablir leur connexion instantanément.
• Pour les caches Enterprise et Enterprise Flash utilisant la géo-réplication active, la mise à l’échelle d’uniquement un sous-ensemble de caches liés peut introduire des problèmes au fil du temps dans certains cas. Nous vous recommandons la mise à l’échelle tous les caches du groupe de géo-réplication ensemble.
• Les caches de base sont hors connexion pendant les opérations de mise à l’échelle vers une taille différente. Les caches De base restent disponibles lors de la mise à l’échelle du niveau De base au niveau Standard, mais peuvent subir une légère interruption de connexion. Si une interruption de connexion se produit, les clients Redis peuvent généralement rétablir leur connexion instantanément.

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

Quand la géoréplication passive est configurée, vous pouvez remarquer que vous ne pouvez pas mettre à l’échelle un cache ni modifier le nombre de partitions dans un cluster. Un lien de géoréplication entre deux caches vous empêche de mettre à l’échelle le fonctionnement et de changer le nombre de partitions dans un cluster. Il vous faudra supprimer le lien du cache pour pouvoir émettre ces commandes. Pour plus d’informations, consultez la page Configurer la géoréplication.

Avec la géoréplication active configurée, vous pouvez mettre à l’échelle un cache avec certaines limitations. Tous les caches d’un groupe de géoréplication doivent être de la même taille et de la même capacité. Pour plus d’informations, consultez Configurer la géoréplication active pour les instances Azure Cache pour Redis Enterprise.

Opérations qui ne sont pas prises en charge

• Vous ne pouvez pas passer d’un niveau de tarification supérieur à un niveau de tarification inférieur.
  • 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 une opération de mise à l’échelle vers la taille voulue par la suite.
• Vous ne pouvez pas passer directement d’un cache De base à un cache Premium. Passez d’abord du niveau De base au niveau Standard en une opération de mise à l’échelle, puis du niveau Standard au niveau Premium en une opération ultérieure.
• Vous ne pouvez pas effectuer une mise à l’échelle d’un cache Premium vers un cache Enterprise ou Enterprise Flash.
• Vous ne pouvez pas mettre à l’échelle depuis une taille supérieure vers la taille C0 (250 Mo) .

En cas d’échec d’une opération de mise à l’échelle, le service essaie d’annuler l’opération et le cache revient à sa taille d’origine.

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

Le temps de mise à l’échelle dépend de plusieurs facteurs. Les facteurs suivants peuvent affecter la durée de mise à l’échelle :

• Quantité de données : de plus grandes quantités de données prennent plus de temps à répliquer.
• Demandes d’écriture élevées : un nombre plus élevé d’écritures se traduit par une augmentation du nombre de données répliquées sur des nœuds ou des fragments.
• Charge élevée du serveur : une charge de serveur supérieure signifie que le serveur Redis est occupé et que des cycles de processeur limités sont disponibles pour effectuer la redistribution des données.

La mise à l’échelle d’un cache n’est pas une action triviale et peut prendre beaucoup de temps. La mise à l’échelle d’un cache avec une à deux partitions peut prendre une à deux heures quand elle n’est pas sous de lourdes charges. Si vous avez plus de fragments, le temps de mise à l’échelle n’augmente pas de manière linéaire.

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.

Dois-je apporter des modifications à mon application cliente pour utiliser le clustering ?

• Lorsque le clustering est activé, seule la base de données 0 est disponible. Si votre application cliente utilise plusieurs bases de données et tente de lire ou d’écrire dans une base de données autre que zéro, l’exception suivante se produit : Unhandled Exception: StackExchange.Redis.RedisConnectionException: ProtocolFailure on GET --->StackExchange.Redis.RedisCommandException: Multiple databases are not supported on this server; cannot switch to database: 6

  Pour plus d’informations, consultez Redis Cluster Specification - Implemented subset(Spécification de cluster Redis - Implémentation de jeu de données).

• Si vous utilisez StackExchange.Redis, vous devez utiliser la version 1.0.481 ou une version ultérieure. Vous vous connectez au cache à l’aide des mêmes points de terminaison, ports et clés que vous utilisez pour vous connecter à un cache où le clustering est désactivé. La seule différence est que toutes les lectures et les écritures doivent être effectuées sur la base de données 0.

  D’autres clients peuvent avoir des exigences différentes. Pour plus d’informations, consultez Tous les clients Redis qui prennent en charge le clustering.

• Si votre application utilise plusieurs opérations sur les clés traitées par lot dans une seule commande, toutes les clés doivent se trouver dans la même partition. Pour localiser les clés dans la même partition, consultez Comment les clés sont-elles distribuées dans un cluster ?.

• Si vous utilisez un fournisseur d’état de session ASP.NET Redis, vous devez utiliser la version 2.0.1 ou une version ultérieure. Pour plus d’informations, voir Puis-je utiliser le clustering avec les fournisseurs Redis ASP.NET pour l’état de session et la mise en cache de sortie ?

Important

Lorsque vous utilisez les niveaux Enterprise ou Enterprise FLash, vous avez le choix entre Mode Cluster OSS ou Mode Cluster Enterprise. Le mode Cluster OSS est identique au clustering sur le niveau Premium et suit la spécification de clustering open source. Le mode Cluster Enterprise peut être moins performant, mais utilise le clustering Redis Enterprise qui ne nécessite aucune modification du client. Pour plus d’informations, consultez Clustering.

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.

Pour accéder à un exemple de code relatif à l’utilisation du clustering et à la localisation des clés dans une même partition avec le client StackExchange.Redis, consultez la partie clustering.cs de l’exemple Hello World.

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

La plus grande taille de cache possible est de 4,5 To. Ce résultat est un cache F1500 en cluster avec une capacité de 9. Pour plus d’informations, consultez Tarification du Cache Azure pour Redis.

Tous les clients Redis prennent-ils en charge le clustering ?

De nombreuses bibliothèques de client prennent en charge le clustering Redis, mais pas toutes. Consultez la documentation de la bibliothèque que vous utilisez pour vérifier que vous utilisez une bibliothèque et une version qui prennent en charge le clustering. StackExchange.Redis est une bibliothèque dont les récentes versions prennent en charge le clustering. Pour plus d’informations sur d’autres clients, consultez la section Playing with the cluster (Manipulation du cluster) du didacticiel sur le cluster Redis.

Le protocole de clustering Redis nécessite que chaque client se connecte directement à chaque partition en mode clustering et qu’il définisse de nouvelles réponses d’erreur telles que MOVED na CROSSSLOTS. Lorsque vous tentez d’utiliser une bibliothèque de client qui ne prend pas en charge le clustering, avec un cache en mode cluster, cela peut générer un grand nombre d’exceptions de redirection MOVED ou simplement entraîner l’arrêt de votre application si vous effectuez des requêtes à plusieurs clés entre emplacements.

Remarque

Si vous utilisez StackExchange.Redis comme client, vérifiez que vous utilisez la dernière version de StackExchange.Redis 1.0.481 ou ultérieure pour que le clustering fonctionne correctement. Pour plus d’informations sur les problèmes avec les exceptions MOVE, reportez-vous aux exceptions MOVE.

Comment puis-je me connecter à mon cache quand le clustering est activé ?

Vous pouvez vous connecter à votre cache à l’aide des mêmes points de terminaison, ports et clés que vous utilisez pour vous connecter à un cache pour lequel le clustering n’est pas activé. Redis gère le clustering sur le serveur principal pour que vous n’ayez pas à le gérer à partir de votre client.

Puis-je me connecter directement aux différentes partitions de mon cache ?

Le protocole de clustering requiert que le client établisse les connexions de partition correctes, de sorte que le client doit établir des connexions de partage pour vous. Ceci étant dit, chaque partition composée d’une paire de caches principal/réplica désignés collectivement sous le nom d’« instance de cache ». Vous pouvez vous connecter à ces instances de cache à l'aide de l'utilitaire Redis-CLI dans la branche instable du référentiel Redis sur GitHub. Cette version implémente la prise en charge de base lorsqu’elle est démarrée avec le commutateur -c . Pour plus d’informations, consultez Manipulation du cluster dans https://redis.io dans le didacticiel concernant les clusters Redis.

Vous devez utiliser le commutateur -p pour spécifier le port approprié auquel vous connecter. Utilisez la commande CLUSTER NODES pour déterminer les ports exacts utilisés pour les nœuds principaux et réplicas. Les plages de ports suivantes sont utilisées :

• Pour les caches de niveau Premium non TLS, les ports sont disponibles dans la plage 130XX
• Pour les caches de niveau Premium avec TLS, les ports sont disponibles dans la plage 150XX
• Pour les caches Enterprise et Enterprise Flash utilisant le clustering OSS, la connexion initiale se fait via le port 10000. La connexion à des nœuds individuels peut être effectuée à l’aide de ports de la plage 85XX. Les ports 85xx changent au fil du temps et ne doivent pas être codés en dur dans votre application.

Puis-je configurer le clustering pour un cache créé précédemment ?

Oui. Tout d’abord, veillez à ce que votre cache soit de niveau Premium en effectuant une mise à l’échelle. Ensuite, vous pouvez voir les options de configuration du cluster, y compris une option pour activer le cluster. Modifiez la taille du cluster une fois que le cache a été créé ou après que vous avez activé le clustering pour la première fois.

Important

Vous ne pouvez pas annuler l’activation du clustering. Un cache avec clustering activé et une seule partition se comporte différemment d’un cache de la même taille mais sans clustering.

Tous les caches de niveau Enterprise et Enterprise Flash sont toujours en cluster.

Puis-je configurer le clustering pour un cache De base ou Standard ?

Le clustering est disponible uniquement pour les caches Premium, Enterprise et Enterprise Flash.

Puis-je utiliser le clustering avec les fournisseurs d’état de session ASP.NET Redis et de mise en cache de la sortie ?

• Fournisseur de caches de sortie Redis : aucune modification requise.
• Fournisseur d’état de session Redis : pour utiliser le clustering, vous devez utiliser RedisSessionStateProvider 2.0.1 ou version ultérieure, sans quoi une exception est levée, ce qui constitue un changement cassant. Pour plus d’informations, consultez Détails du changement cassant pour v2.0.0.

J’obtiens des exceptions MOVE lorsque j’utilise StackExchange.Redis et le clustering. Que dois-je faire ?

Si vous utilisez StackExchange.Redis et recevez des exceptions MOVE lorsque vous utilisez le clustering, veillez à utiliser StackExchange.Redis 1.1.603 ou version ultérieure.

Quelle est la différence entre le clustering OSS et le clustering Enterprise sur les caches de niveau Enterprise ?

Le mode Cluster OSS est identique au clustering sur le niveau Premium et suit la spécification de clustering open source. Le mode Cluster Enterprise peut être moins performant, mais utilise le clustering Redis Enterprise, qui ne nécessite aucune modification du client. Pour plus d’informations, consultez Clustering.

Combien de partitions les caches de niveau Enterprise utilisent-ils ?

Contrairement aux caches de niveau De base, Standard et Premium, les caches Enterprise et Enterprise Flash peuvent tirer parti de plusieurs partitions sur un seul nœud. Pour plus d’informations, consultez Configuration du partitionnement.

Étapes suivantes

• Configurer le paramètre maxmemory-reserved
• Meilleures pratiques relatives à la mise à l’échelle