Événements
31 mars, 23 h - 2 avr., 23 h
Le plus grand événement d’apprentissage SQL, Fabric et Power BI. 31 mars au 2 avril. Utilisez le code FABINSIDER pour économiser 400 $.
Inscrivez-vous aujourd’huiCe navigateur n’est plus pris en charge.
Effectuez une mise à niveau vers Microsoft Edge pour tirer parti des dernières fonctionnalités, des mises à jour de sécurité et du support technique.
Azure Managed Redis (préversion) s’exécute sur la pile Redis Entreprise, ce qui offre des avantages significatifs par rapport à l’édition communautaire 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.
Important
Redis managé Azure est actuellement en PRÉVERSION. Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.
Les niveaux Essentiel, Standard et Premium d’Azure Cache pour Redis étaient basés sur l’édition communautaire de Redis. Cette version de Redis présente plusieurs limitations significatives, notamment l’utilisation d’un thread unique par conception. Cela réduit considérablement les performances et rend la mise à l’échelle moins efficace, car plus de processeurs virtuels ne sont pas entièrement utilisés par le service. Une instance Azure Cache pour Redis classique utilise une architecture semblable à celle-ci :
Notez que deux machines virtuelles sont utilisées : une principale et un réplica. 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 est capable d’exécuter un seul processus de serveur Redis en raison de la conception à thread unique de Redis communautaire.
Azure Managed Redis utilise une architecture plus avancée qui ressemble à ceci :
Il existe plusieurs différences :
Cette architecture offre des performances supérieures et des fonctionnalités avancées telles que la géoréplication active
Étant donné que Redis Entreprise est en mesure d’utiliser plusieurs partitions par nœud, chaque instance d’Azure Managed Redis est configurée en interne pour utiliser le clustering, sur tous les niveaux et références SKU. Cela inclut des instances plus petites qui sont configurées uniquement pour utiliser une seule partition. Le clustering est un moyen de diviser les données dans l’instance Redis sur plusieurs processus Redis, également appelé « partitionnement ». Azure Managed Redis offre deux stratégies de cluster qui déterminent le protocole disponible pour les clients Redis pour la connexion à l’instance de cache.
Azure Managed Redis propose deux options pour la stratégie de clustering : OSS et Entreprise. La stratégie de cluster OSS est recommandée pour la plupart des applications parce qu’elle prend en charge un débit maximal plus élevé, mais il y a des avantages et des inconvénients à chaque version.
La stratégie de clustering OSS implémente la même API Cluster Redis que l’édition communautaire de Redis. L’API Cluster Redis permet au client Redis de se connecter directement aux partitions sur chaque nœud Redis, de réduire la latence et d’optimiser le débit du réseau, ce qui permet au débit de s’adapter quasiment linéairement au fur et à mesure que le nombre de partitions et de processeurs virtuels augmente. La stratégie de clustering OSS offre généralement les meilleures performances de latence et de débit. Toutefois, la stratégie de cluster OSS nécessite que votre bibliothèque cliente prenne en charge l’API 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. La stratégie de clustering OSS ne peut pas non plus être utilisée avec le module RediSearch.
La stratégie de clustering Enterprise est une configuration plus simple qui utilise un seul point de terminaison pour toutes les connexions clientes. L’utilisation de la stratégie de clustering Enterprise achemine toutes les demandes vers un seul nœud Redis qui est ensuite utilisé comme proxy, acheminant en interne les demandes vers le nœud approprié dans le cluster. L’avantage de cette approche est qu’Azure Managed Redis ne semble pas utiliser de clusters pour les utilisateurs. Cela signifie que les bibliothèques clientes Redis n’ont pas besoin de prendre en charge le clustering Redis pour obtenir certains des avantages en matière de performances de Redis Entreprise, ce qui améliore la compatibilité descendante et simplifie la connexion. L’inconvénient est que le proxy mono-nœud peut être un goulot d’étranglement, que ce soit dans l’utilisation du calcul ou le débit réseau. La stratégie de clustering Enterprise est la seule qui peut être utilisée avec le module RediSearch. Bien que la stratégie de cluster d’entreprise fait passer une instance Azure Managed Redis pour non clusterisée auprès des utilisateurs, elle présente toujours certaines limitations avec les commandes à plusieurs clés.
Le logiciel Redis Entreprise de base est capable d’effectuer un scale-up (à l’aide de machines virtuelles plus volumineuses) ou d’effectuer un scale-out (en ajoutant davantage de nœuds/machines virtuelles). En fin de compte, l’une ou l’autre action de mise à l’échelle accomplit la même chose, c’est-à-dire ajouter plus de mémoire, plus de processeurs virtuels et plus de partitions. En raison de cette redondance, Azure Managed Redis n’offre pas la possibilité de contrôler le nombre spécifique de nœuds utilisés dans chaque configuration. Ce détail d’implémentation est caché à l’utilisateur afin d’é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 pour optimiser les processeurs virtuels et la mémoire. Certaines références SKU d’Azure Managed Redis utilisent seulement deux nœuds, tandis que d’autres en utilisent davantage.
Étant donné que les instances Azure Managed Redis sont conçues avec une configuration clusterisée, vous risquez de voir des exceptions CROSSSLOT
sur les commandes qui fonctionnent 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, les commandes multi-clés ont besoin que toutes les clés soient 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 multi-clés suivantes sont autorisées sur les emplacements avec clustering Enterprise : DEL
, MSET
, MGET
, EXISTS
, UNLINK
et TOUCH
.
Dans les bases de données en mode Actif-Actif, les commandes d’écriture multi-clés (DEL
, MSET
, UNLINK
) ne peuvent être exécutées que sur les clés situées dans le même emplacement. Les commandes multi-clés suivantes sont toutefois autorisées sur les emplacements des bases de données en mode Actif-Actif : MGET
, EXISTS
et TOUCH
. Pour plus d’informations, consultez Clustering de bases de données.
Chaque référence SKU d’Azure Managed Redis est configurée pour exécuter un nombre spécifique de processus serveur Redis, partitions en parallèle. La relation entre les performances de débit, le nombre de partitions et le nombre de processeurs virtuels disponibles sur chaque instance est compliquée. L’ajout de partitions augmente généralement les performances, car les opérations Redis peuvent être exécutées en parallèle. Toutefois, si les partitions ne sont pas en mesure d’exécuter des commandes car aucun processeur virtuel n’est disponible pour exécuter des commandes, les performances peuvent réellement chuter. Le tableau suivant présente la configuration de partitionnement pour chaque référence SKU d’Azure Managed Redis. Ces partitions sont mappées pour optimiser l’utilisation de chaque processeur virtuel tout en réservant des cycles de processeurs virtuels pour le proxy Redis Entreprise, l’agent de gestion et les tâches système du système d’exploitation qui affectent également les performances.
Notes
Le nombre de partitions et de processeurs virtuels utilisés sur chaque référence SKU peut changer au fil du temps, car les performances sont optimisées par l’équipe Azure Managed Redis.
Niveaux | Flash optimisé | Mémoire optimisée | Équilibrée | Optimisé pour le calcul |
---|---|---|---|---|
Taille (Go) | processeurs virtuels/partitions principales | processeurs virtuels/partitions principales | processeurs virtuels/partitions principales | processeurs virtuels/partitions principales |
0,5 | - | - | 2/2 | - |
1 | - | - | 2/2 | - |
3 | - | - | 2/2 | 4/2 |
6 | - | - | 2/2 | 4/2 |
12 | - | 2/2 | 4/2 | 8/6 |
24 | - | 4/2 | 8/6 | 16/12 |
60 | - | 8/6 | 16/12 | 32/24 |
120 | - | 16/12 | 32/24 | 64/48 |
180 | - | 24/24 | 48/48 | 96/96 |
240 | 8/6 | 32/24 | 64/48 | 128/96 |
360 | - | 48/48 | 96/96 | 192/192 |
480 | 16/12 | 64/48 | 128/96 | 256/192 |
720 | 24/24 | 96/96 | 192/192 | 384/384 |
960 | 32/24 | 128/192 | 256/192 | - |
1440 | 48/48 | 192/192 | - | - |
1920 | 64/48 | 256/192 | - | - |
4500 | 144/96 | - | - | - |
L’exécution est possible sans le mode haute disponibilité activé. Cela signifie que votre instance Redis n’a pas de réplication activée et n’a pas accès au contrat SLA de disponibilité. Nous vous déconseillons d’exécuter sans le mode haute disponibilité en dehors des scénarios de développement/test. Vous ne pouvez pas désactiver la haute disponibilité dans une instance qui a déjà été créée. Toutefois, 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/nœuds, les processeurs virtuels ne peuvent pas être utilisés aussi efficacement, de sorte que les performances peuvent être inférieures.
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.
Le scale-down n’est actuellement pas pris en charge sur Azure Managed Redis. Pour plus d’informations, consultez Conditions préalables/limitations de la mise à l’échelle d’Azure Managed Redis.
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 :
Les charges de travail susceptibles de bien fonctionner avec le niveau Flash optimisé présentent souvent les caractéristiques suivantes :
Certaines charges de travail présentent des caractéristiques d’accès moins optimisées pour la conception du niveau Flash optimisé :
Événements
31 mars, 23 h - 2 avr., 23 h
Le plus grand événement d’apprentissage SQL, Fabric et Power BI. 31 mars au 2 avril. Utilisez le code FABINSIDER pour économiser 400 $.
Inscrivez-vous aujourd’hui