Partager via

Mettre à l'échelle une instance Cache Redis Azure

  • Article

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 Premium 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. Pour en savoir plus, consultez Meilleures pratiques pour les niveaux Enterprise et Enterprise Flash d’Azure Cache pour Redis.
  • 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 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 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.

Notes

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.

Notes

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. Lorsque vous réduisez l’échelle, 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.capcity 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.

Notes

Quand vous faites 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.

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

    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

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

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

  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.

    Capture d’écran montrant la capacité dans le volet de travail dans un cadre rouge.

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

  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 ?

  • 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 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 ?

  • 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.
  • Dans certains cas, tels que la mise à l’échelle ou 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 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.

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 réduisez la taille d’un cache Standard ou Premium, 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 .

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 sur le réseau virtuel
  • 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 reste-t-il disponible durant 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.

Une fois la géoréplication active configurée, vous ne pouvez pas mettre à l’échelle un cache. Tous les caches d’un groupe de géoréplication doivent avoir la même taille et la même capacité.

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. 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.
  • Charge de serveur élevée : Une charge de serveur élevée signifie que le serveur Redis est occupé et que les cycles de l’unité centrale sont limités pour effectuer la redistribution des données

La mise à l’échelle d’un cache est une action non triviale et peut prendre beaucoup de temps.

D’après des exemples réels, le temps de mise à l’échelle du cache avec une à deux partitions peut être de 1 à 2 heures quand le cache n’est pas soumis à des charges lourdes. Si vous avez plus de partitions, le temps de mise à l’échelle n’augmente pas de façon 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 ?

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 sur Enterprise.

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 tout simplement entraîner l’arrêt de votre application si vous effectuez des demandes à plusieurs clés entre emplacements.

Notes

Si vous utilisez StackExchange.Redis comme client, assurez-vous d'utiliser la dernière version de StackExchange.Redis 1.0.481 ou une version 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 Playing with the cluster sur https://redis.io dans le tutoriel 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. Pour obtenir des instructions sur la configuration de vos applications .NET afin d’utiliser StackExchange.Redis, consultez Configuration des clients de cache.

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 sur Enterprise.

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 Partitionnement et utilisation du processeur.

Étapes suivantes