Architecture de Redis managé Azure

Azure Managed Redis s’exécute sur la pile Redis Enterprise , qui offre des avantages significatifs par rapport à l’édition community de Redis. Les informations suivantes fournissent plus de détails sur l’architecture d’Azure Managed Redis, y compris des informations qui peuvent être utiles aux utilisateurs avec pouvoir.

Comparaison avec Azure Cache pour Redis

Les niveaux De base, Standard et Premium du Cache Azure pour Redis s’exécutent sur l’édition community de Redis. Cette édition community de Redis présente plusieurs limitations significatives, notamment l’utilisation d’un thread unique. Cette limitation réduit considérablement les performances et rend la mise à l’échelle moins efficace, car le service n’utilise pas entièrement plus de processeurs virtuels. Une instance Azure Cache pour Redis classique utilise une architecture semblable à celle-ci :

Notez que deux machines virtuelles sont utilisées : une principale et une réplique. Ces machines virtuelles sont également appelées nœuds. Le nœud principal contient le processus Redis principal et accepte toutes les écritures. La réplication est effectuée de manière asynchrone sur le nœud réplica pour fournir une copie de sauvegarde pendant la maintenance, la mise à l’échelle ou une défaillance inattendue. Chaque nœud ne peut exécuter qu’un seul processus de serveur Redis en raison de la conception monothread de Redis communauté.

Améliorations architecturales d’Azure Managed Redis

Azure Managed Redis utilise une architecture plus avancée qui ressemble à ceci :

Il existe plusieurs différences :

• Chaque machine virtuelle (ou nœud) exécute plusieurs processus de serveur Redis (appelés partitions) en parallèle. Plusieurs partitions permettent une utilisation plus efficace des processeurs virtuels sur chaque machine virtuelle et des performances plus élevées.
• Toutes les partitions Redis principales ne se trouvent pas sur la même machine virtuelle ou sur le même nœud. Au lieu de cela, les partitions principales et de réplica sont réparties entre les deux nœuds. Étant donné que les partitions principales utilisent plus de ressources d’UC que de partitions de réplica, cette approche permet d’exécuter plus de partitions primaires en parallèle.
• Chaque nœud dispose d’un processus de proxy hautes performances pour gérer les partitions, gérer la gestion des connexions et déclencher la réparation automatique.

Cette architecture permet à la fois des performances plus élevées et des fonctionnalités avancées telles que la géoréplication active.

Regroupement

Chaque instance Redis managée Azure est configurée en interne pour utiliser le clustering, sur tous les niveaux et références SKU. Azure Managed Redis est basé sur Redis Enterprise, lequel peut utiliser plusieurs shards par nœud. Cette fonctionnalité inclut des instances plus petites qui ne sont configurées que pour utiliser un seul fragment. Le clustering est un moyen de diviser les données dans l’instance Redis sur plusieurs processus Redis, également appelés partitionnements. Azure Managed Redis propose trois stratégies de cluster qui déterminent le protocole disponible pour les clients Redis pour la connexion à l’instance de cache.

Stratégies de cluster

Azure Managed Redis propose trois stratégies de clustering : OSS, Enterprise et Non-Clustered. La stratégie de cluster OSS est adaptée à la plupart des applications, car elle prend en charge un débit maximal plus élevé, mais chaque version présente ses propres avantages et inconvénients.

• Si vous passez d’une topologie de niveau Essentiel, Standard ou Premium non-cluster, prévoyez d’utiliser le clustering OSS pour améliorer les performances. Utilisez des configurations non cluster uniquement si votre application ne peut pas prendre en charge les topologies OSS ou Enterprise. La stratégie de clustering OSS implémente la même API que le logiciel open source Redis. L’API de cluster Redis permet au client Redis de se connecter directement aux partitions sur chaque nœud Redis, ce qui réduit la latence et optimise le débit réseau. Le débit se met à l'échelle de manière presque linéaire à mesure que le nombre de partitions et de processeurs virtuels augmente. La stratégie de clustering OSS offre généralement la latence la plus faible et les meilleures performances de débit. Toutefois, la stratégie de cluster OSS nécessite que votre bibliothèque cliente prend en charge l’API de cluster Redis. Aujourd’hui, presque tous les clients Redis prennent en charge l’API Cluster Redis, mais la compatibilité peut être un problème pour les anciennes versions clientes ou les bibliothèques spécialisées.

Vous ne pouvez pas utiliser la stratégie de clustering OSS avec le module RediSearch.

Le protocole de clustering OSS nécessite que le client effectue les connexions de partition correctes. La connexion initiale est via le port 10000. La connexion à des nœuds individuels utilise des ports dans la plage 85XX. Les ports 85xx peuvent changer au fil du temps et vous ne devez pas les encoder en dur dans votre application. Les clients Redis qui prennent en charge le clustering utilisent la commande CLUSTER NODES pour déterminer les ports exacts utilisés pour les partitions principales et réplicas et établir les connexions de partitions pour vous.

La stratégie de clustering Entreprise est une configuration plus simple qui utilise un point de terminaison unique pour toutes les connexions clientes. Lorsque vous utilisez la stratégie de clustering Entreprise, elle achemine toutes les requêtes vers un seul nœud Redis qui agit en tant que proxy. Ce nœud achemine en interne les demandes vers le nœud approprié dans le cluster. L'avantage de cette approche est qu'elle donne à Azure Managed Redis l'apparence d'une solution non-clusterisée pour les utilisateurs. Cela signifie que les bibliothèques clientes Redis n’ont pas besoin de prendre en charge le clustering Redis pour bénéficier de certains des avantages en matière de performances de Redis Enterprise. L’utilisation d’un point de terminaison unique améliore la compatibilité descendante et simplifie la connexion. L’inconvénient est que le proxy à nœud unique peut être un goulot d’étranglement dans l’utilisation du calcul ou le débit réseau.

La stratégie de clustering Entreprise est la seule que vous pouvez utiliser avec le module RediSearch. Bien que la stratégie de cluster d’entreprise rende une instance Redis managée Azure non clusterisée aux yeux des utilisateurs, elle présente toujours certaines limitations avec les commandes multi-clés.

La politique de clustering non-clusterisé stocke les données sur chaque nœud sans partitionnement. Il s’applique uniquement aux caches de 25 Go et plus petits. Les scénarios d’utilisation de la stratégie de clustering non cadrée incluent :

• Lors de la migration à partir d’un environnement Redis non partitionné. Par exemple, les topologies non partitionnées des SKU de niveau Essentiel, Standard et Premium du Cache Azure pour Redis.
• Lors de l’exécution de commandes entre emplacements, et la division des données en partitions entraîne des défaillances. Par exemple, les commandes MULTI.
• Lorsque vous utilisez Redis comme broker de messages et que vous n’avez pas besoin de partitionnement.

Les considérations relatives à l’utilisation de la stratégie non cluster sont les suivantes :

• Cette stratégie s’applique uniquement aux niveaux Redis managés Azure qui sont inférieurs ou égaux à 25 Go.
• Il n’est pas aussi performant que d’autres stratégies de clustering, car les processeurs peuvent uniquement multithread avec les logiciels Redis Enterprise lorsque le cache est partitionné.
• Si vous souhaitez effectuer un scale-up de votre cache Redis managé Azure, vous devez d’abord modifier la stratégie de cluster.
• Si vous passez d'une topologie de base, Standard ou Premium non-clusterisée, envisagez d'utiliser des clusters OSS pour améliorer les performances. Utilisez des configurations non cluster uniquement si votre application ne peut pas prendre en charge les topologies OSS ou Enterprise.

Scale-out ou ajout de nœuds

Le logiciel de base Redis Enterprise se met à l’échelle à l’aide de machines virtuelles plus grandes ou effectue un scale-out en ajoutant plus de nœuds ou de machines virtuelles. Les deux options de mise à l’échelle ajoutent davantage de mémoire, plus de processeurs virtuels et plus de partitions. En raison de cette redondance, Azure Managed Redis ne permet pas de contrôler le nombre spécifique de nœuds utilisés dans chaque configuration. Ce détail d’implémentation est abstrait pour éviter toute confusion, complexité et configurations non optimales. Au lieu de cela, chaque référence SKU est conçue avec une configuration de nœud qui optimise les processeurs virtuels et la mémoire. Certaines références SKU d’Azure Managed Redis utilisent deux nœuds, tandis que d’autres utilisent plus.

Commandes multi-clés

Étant donné que les instances Redis managées Azure utilisent une configuration en cluster, vous pouvez voir CROSSSLOT des exceptions lors de l'exécution des commandes qui opèrent sur plusieurs clés. Le comportement varie en fonction de la stratégie de clustering utilisée. Si vous utilisez la stratégie de clustering OSS, toutes les clés des commandes multikey doivent être mappées au même emplacement de hachage.

Vous risquez aussi de voir des erreurs CROSSSLOT avec la stratégie de clustering Enterprise. Seules les commandes multikey suivantes sont autorisées entre les emplacements avec le clustering Entreprise : DEL, , MSET, MGET, EXISTS, UNLINKet TOUCH.

Dans Active-Active bases de données, les commandes d’écriture multikey (DEL, MSET, UNLINK) peuvent uniquement s’exécuter sur les clés qui se trouvent dans le même emplacement. Toutefois, les commandes multikey suivantes sont autorisées entre les emplacements des bases de données Active-Active : MGET, EXISTSet TOUCH. Pour plus d’informations, consultez Clustering de bases de données.

Configuration du partitionnement

Chaque référence SKU d’Azure Managed Redis exécute un nombre spécifique de processus de serveur Redis, appelés partitions, en parallèle. La relation entre les performances du débit, le nombre de partitions et le nombre de processeurs virtuels disponibles sur chaque instance est complexe. Vous ne pouvez pas modifier manuellement le nombre de fragments.

Pour une taille de mémoire donnée, la version optimisée en mémoire a le moins de processeurs virtuels et de partitions, tandis que la version optimisée pour le calcul est la plus élevée.

Augmenter le nombre de fragments améliore généralement les performances, car les opérations Redis peuvent s'exécuter en parallèle. Toutefois, si aucun processeur virtuel n’est disponible pour exécuter des commandes, les performances peuvent diminuer.

Les partitions sont mappées pour optimiser l’utilisation de chaque processeur virtuel tout en réservant des cycles de processeur virtuel pour le processus de serveur Redis, l’agent de gestion et les tâches système d’exploitation qui affectent également les performances. Les applications clientes que vous créez interagissent avec Azure Managed Redis comme s’il s’agit d’une base de données logique unique. Le service gère le routage entre les processeurs virtuels et les partitions.

Pour augmenter le nombre de fragments d'une SKU, utilisez un niveau supérieur de cette SKU. Vous pouvez également modifier les références SKU pour qu’elles correspondent à vos besoins en matière de performances.

Le tableau suivant montre le rapport entre les processeurs virtuels et les partitions principales selon une taille de niveau donnée. Les données des colonnes ne garantissent pas qu’il s’agisse du nombre de processeurs virtuels ou de partitions. Les tableaux sont à titre d’illustration uniquement.

Remarque

Azure Managed Redis optimise les performances au fil du temps en modifiant le nombre de partitions et de processeurs virtuels utilisés sur chaque référence SKU.

Versions optimisées en mémoire, équilibrées et optimisées pour le calcul

Ce tableau présente un exemple général du rapport de taille aux vCPUs/shards principaux.

Niveaux	Mémoire optimisée	Équilibré	Optimisé pour le calcul
Taille (Go)	processeurs virtuels/partitions principales	processeurs virtuels/partitions principales	processeurs virtuels/partitions principales
24 ¹	4/2	8 juin	16/12
60 ¹	8 juin	16/12	32/24

¹ Le rapport entre les processeurs virtuels et les partitions principales pour une taille de niveau donnée ne représente pas une garantie pour le SKU ou le niveau.

Version optimisée flash

Ce tableau présente un exemple général de la relation entre la taille et les vCPUs/les morceaux primaires.

Niveaux	Flash Optimized (préversion)
Taille (Go)	processeurs virtuels/partitions principales
480 ¹ ²	16/12
720 ¹ ²	24 heures sur 24

¹ Ces niveaux sont en aperçu public.

² Le rapport entre les processeurs virtuels et les partitions principales pour une taille de niveau donnée ne représente pas une garantie pour le SKU ou le niveau.

Important

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

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

Exécution sans le mode haute disponibilité activé

Vous pouvez exécuter sans mode haute disponibilité activé. Cette configuration signifie que votre instance Redis n’a pas de réplication activée et n’a pas accès au contrat SLA de disponibilité. Ne pas exécuter si la haute disponibilité n’est pas activée en dehors des scénarios de développement et de test. Vous ne pouvez pas désactiver la haute disponibilité dans une instance que vous avez déjà créée. Vous pouvez activer la haute disponibilité dans une instance qui ne l’a pas. Étant donné qu’une instance s’exécutant sans haute disponibilité utilise moins de machines virtuelles et de nœuds, les processeurs virtuels ne sont pas utilisés aussi efficacement. Les performances peuvent donc être inférieures.

Mémoire réservée

Sur chaque instance Azure Managed Redis, environ 20 % de la mémoire disponible est réservée en tant que mémoire tampon pour les opérations non mises en cache, telles que la réplication pendant le basculement et la mémoire tampon de géoréplication active. Cette mémoire tampon permet d’améliorer les performances du cache et d’empêcher le manque de mémoire.

Effectuer un scale-down

Le scale-down n’est actuellement pas pris en charge sur Azure Managed Redis. Pour plus d’informations, consultez Limitations de la mise à l’échelle d’Azure Managed Redis.

Niveau Flash optimisé

Le niveau Flash optimisé utilise à la fois un stockage Flash NVMe et de la RAM. Le stockage Flash étant moins coûteux, l’utilisation du niveau Flash optimisé vous permet de compenser la relative perte de performances par un prix compétitif.

Sur les instances Flash optimisé, 20 % de l’espace du cache se trouve sur la RAM, tandis que les autres 80 % utilisent le stockage Flash. Toutes les clés sont stockées sur la RAM, tandis que les valeurs peuvent être stockées dans le stockage Flash ou sur la RAM. Le logiciel Redis détermine intelligemment l’emplacement des valeurs. Les valeurs chaudes auxquelles les utilisateurs accèdent fréquemment sont stockées dans la RAM, tandis que les valeurs froides, moins utilisées, sont conservées dans la mémoire Flash. Avant d’être lues ou écrites, les données doivent être déplacées vers la RAM, devenant ainsi des données chaudes.

En raison du fait que Redis optimise le niveau de performance, l’instance remplit initialement la RAM disponible avant d’ajouter des éléments au stockage Flash. Le fait de remplir initialement la RAM entraîne des conséquences en termes de niveau de performance :

• Un niveau de performance plus élevé et une latence plus faible peuvent être observés lors de tests impliquant une faible utilisation de la mémoire. Les tests avec une instance de cache complète peuvent produire des performances inférieures, car seule la RAM est utilisée dans la phase de test d’utilisation de la mémoire faible.
• En écrivant davantage de données dans le cache, la proportion de données dans la RAM diminue comparativement au stockage Flash, ce qui entraîne généralement une diminution de la latence et des niveaux de performances liés au débit.

Charges de travail adaptées au niveau Flash optimisé

Les charges de travail qui s’exécutent correctement sur le niveau flash optimisé ont souvent les caractéristiques suivantes :

• Lecture intensive, avec un ratio élevé de commandes de lecture par rapport aux commandes d’écriture.
• Access se concentre sur un sous-ensemble de clés que vous utilisez beaucoup plus fréquemment que le reste du jeu de données.
• Valeurs relativement grandes par rapport aux noms de clés. (Les noms de clés étant toujours stockés dans la RAM, les valeurs de grande taille peuvent constituer un goulot d’étranglement pour la croissance de la mémoire.)

Charges de travail non adaptées au niveau Flash optimisé

Certaines charges de travail présentent des caractéristiques d’accès moins optimisées pour la conception du niveau Flash optimisé :

• Charges de travail nécessitant de nombreuses écritures.
• Motifs d’accès aux données aléatoires ou uniformes sur une grande partie du jeu de données.
• Noms de clés longs avec des valeurs de taille relativement petite.

Contenu connexe

• Mettre à l’échelle une instance Azure Managed Redis