Quelles sont les bonnes pratiques pour les niveaux Enterprise et Enterprise Flash ?
Voici les bonnes pratiques lors de l’utilisation des niveaux hautes performances Entreprise et Flash Entreprise d’Azure Cache pour Redis.
Redondance de zone
Nous vous recommandons vivement de déployer de nouveaux caches dans une configuration redondante interzone. La redondance de zone garantit que les nœuds Redis Enterprise sont répartis entre trois zones de disponibilité, ce qui améliore la redondance lors de pannes au niveau du centre de données. L’utilisation de la redondance de zone augmente la disponibilité. Pour plus d’informations, consultez Contrats de niveau de service pour les services en ligne.
La redondance de zone est importante dans le niveau Enterprise parce que votre instance de cache utilise toujours au moins trois nœuds. Deux nœuds sont des nœuds de données, qui contiennent vos données, et un nœud de quorum. L’augmentation de la capacité adapte le nombre de nœuds de données par incréments de nombre pair.
Il existe également un autre nœud appelé nœud de quorum. Ce nœud surveille les nœuds de données et sélectionne automatiquement le nouveau nœud principal en cas de basculement. La redondance de zone garantit que les nœuds sont répartis uniformément entre trois zones de disponibilité, ce qui réduit le risque de perte de quorum. Les clients ne sont pas facturés pour le nœud de quorum et aucun autre coût d’utilisation de la redondance de zone ne s’ajoute aux frais de bande passante intrazonale.
Mise à l'échelle
Dans les niveaux Enterprise et Enterprise Flash d’Azure Cache pour Redis, nous vous recommandons de donner la priorité au scale-up par rapport au scale-out. Donnez la priorité au scale-up, car les niveaux Enterprise sont basés sur Redis Enterprise, qui peut utiliser davantage de cœurs de processeur sur des machines virtuelles plus grandes.
À l’inverse, la recommandation opposée est vraie pour les niveaux De base, Standard et Premium, qui reposent sur Redis open source. Dans ces niveaux, donner la priorité au scale-out par rapport au scale-up est recommandé dans la plupart des cas.
Partitionnement et utilisation de processeurs
Dans les niveaux De base, Standard et Premium d’Azure Cache pour Redis, il est très simple de déterminer le nombre de processeurs virtuels (vCPU) utilisés. Chaque nœud Redis s’exécute sur une machine virtuelle dédiée. Le processus du serveur Redis est mono-thread, il utilise un processeur virtuel sur chaque nœud principal et chaque nœud de réplica. Les autres processeurs virtuels sur la machine virtuelle sont quand même utilisés pour d’autres activités, telles que la coordination de workflows pour différentes tâches, le monitoring de l’intégrité et la charge TLS, entre autres.
Lorsque vous utilisez le clustering, l’effet est de répartir les données sur davantage de nœuds avec une partition par nœud. En augmentant le nombre de partitions, vous augmentez de façon linéaire le nombre de processeurs virtuels que vous utilisez, en fonction du nombre de partitions dans le cluster.
Redis Enterprise, en revanche, peut utiliser plusieurs processeurs virtuels pour l’instance Redis elle-même. En d’autres termes, tous les niveaux d’Azure Cache pour Redis peuvent utiliser plusieurs processeurs virtuels pour les tâches d’arrière-plan et de monitoring, mais seuls les niveaux Enterprise et Enterprise Flash peuvent utiliser plusieurs processeurs virtuels par machine virtuelle pour les partitions Redis. Le tableau indique le nombre de processeurs virtuels effectifs utilisés pour chaque référence SKU et la configuration (c’est-à-dire, le scale-out) des capacités.
Les tableaux indiquent le nombre de processeurs virtuels utilisés pour les partitions primaires, et non les partitions de réplica. Les partitions ne mappent pas un à un au nombre de processeurs virtuels. Les tableaux illustrent uniquement les processeurs virtuels, pas les partitions. Certaines configurations utilisent plus de partitions que de processeurs virtuels disponibles pour booster les performances dans certains scénarios d’usage.
E1
| Capacité | Processeurs virtuels effectifs |
|---|---|
| 2 | 1 (Burstable) |
E5
| Capacité | Processeurs virtuels effectifs |
|---|---|
| 2 | 1 |
| 4 | 2 |
| 6 | 6 |
E10
| Capacité | Processeurs virtuels effectifs |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E20
| Capacité | Processeurs virtuels effectifs |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E50
| Capacité | Processeurs virtuels effectifs |
|---|---|
| 2 | 6 |
| 4 | 6 |
| 6 | 6 |
| 8 | 30 |
| 10 | 30 |
E100
| Capacité | Processeurs virtuels effectifs |
|---|---|
| 2 | 6 |
| 4 | 30 |
| 6 | 30 |
| 8 | 30 |
| 10 | 30 |
E200
| Capacité | Processeurs virtuels effectifs |
|---|---|
| 2 | 30 |
| 4 | 60 |
| 6 | 60 |
| 8 | 120 |
| 10 | 120 |
E400
| Capacité | Processeurs virtuels effectifs |
|---|---|
| 2 | 60 |
| 4 | 120 |
| 6 | 120 |
| 8 | 240 |
| 10 | 240 |
F300
| Capacité | Processeurs virtuels effectifs |
|---|---|
| 3 | 6 |
| 9 | 30 |
F700
| Capacité | Processeurs virtuels effectifs |
|---|---|
| 3 | 30 |
| 9 | 30 |
F1500
| Capacité | Processeurs virtuels effectifs |
|---|---|
| 3 | 30 |
| 9 | 90 |
Clustering sur Enterprise
Les niveaux Enterprise et Enterprise Flash sont intrinsèquement clusterisés, contrairement aux niveaux De base, Standard et Premium. L’implémentation dépend de la stratégie de clustering sélectionnée. Les niveaux Enterprise offrent deux options pour la stratégie de clustering : OSS et Enterprise. 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 Redis open source. L’API Cluster Redis permet au client Redis de se connecter directement à chaque nœud Redis, ce qui réduit la latence et optimise le débit réseau. Par conséquent, une scalabilité quasi linéaire est obtenue lors du scale-out du cluster avec plus de nœuds. La stratégie de clustering OSS fournit généralement les meilleures performances de latence et de débit, mais il faut que votre bibliothèque de client prenne en charge le clustering Redis. 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 que les bibliothèques de client Redis n’ont pas besoin de prendre en charge le clustering Redis pour tirer parti de plusieurs nœuds. 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.
Commandes multi-clés
Étant donné que les niveaux Enterprise utilisent 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.
Meilleures pratiques pour Enterprise Flash
Le niveau Enterprise Flash utilise à la fois un stockage Flash NVMe et de la RAM. Le stockage Flash étant moins coûteux, l’utilisation du niveau Enterprise Flash vous permet de compenser la relative perte de performances par un prix compétitif.
Sur les instances Enterprise Flash, 20 % de l’espace du cache se trouve sur la RAM, tandis que les autre 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 effectués avec une instance de cache complète peuvent entraîner un niveau de performance inférieur, car seule la RAM est utilisée dans la phase de test impliquant une faible utilisation de la mémoire.
- 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 Enterprise Flash
Les charges de travail susceptibles de bien fonctionner avec le niveau Enterprise Flash présentent souvent les caractéristiques suivantes :
- Lecture intensive, avec un ratio élevé de commandes de lecture par rapport aux commandes d’écriture.
- L’accès est axé sur un sous-ensemble de clés qui sont utilisées 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 ne convenant pas au niveau Enterprise Flash
Certaines charges de travail présentent des caractéristiques d’accès moins optimisées par rapport à la conception du niveau Flash :
- Charges de travail nécessitant beaucoup d’é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.
Gestion des scénarios de panne régionale avec la géoréplication active
La géoréplication active est une fonctionnalité puissante qui booste considérablement la disponibilité lors de l’utilisation des niveaux Enterprise d’Azure Cache pour Redis. Toutefois, mieux vaut prendre des mesures pour préparer vos caches en cas de panne régionale.
Par exemple, tenez compte des conseils suivants :
- Identifiez à l’avance vers quel autre cache du groupe de géoréplication basculer si une région connaît une panne.
- Vérifiez que les pare-feu sont définis de sorte que l’ensemble des applications et des clients puissent accéder au cache de sauvegarde identifié.
- Chaque cache du groupe de géoréplication a sa propre clé d’accès. Déterminez comment l’application passe à des clés d’accès différentes lors du ciblage d’un cache de sauvegarde.
- Si un cache du groupe de géoréplication tombe en panne, une accumulation de métadonnées commence à arriver dans tous les caches du groupe de géoréplication. Les métadonnées ne peuvent pas être ignorées tant que les écritures ne peuvent pas être resynchronisées dans tous les caches. Vous pouvez empêcher l’accumulation de métadonnées en forçant la dissociation du cache qui est en panne. Pensez à surveiller la mémoire disponible dans le cache et à le dissocier en cas de sollicitation de la mémoire, en particulier pour les charges de travail lourdes en écriture.
Il est également possible d’utiliser un modèle de disjoncteur. Utilisez le modèle pour rediriger automatiquement le trafic loin d’un cache qui connaît une panne régionale et en direction d’un cache de sauvegarde dans le même groupe de géoréplication. Utilisez des services Azure comme Azure Traffic Manager ou Azure Load Balancer pour activer la redirection.
Persistance des données ou sauvegarde de données
La fonctionnalité de persistance des données dans les niveaux Enterprise et Enterprise Flash est conçue pour fournir automatiquement un point de récupération rapide pour les données lorsqu’un cache tombe en panne. La récupération rapide est rendue possible en stockant le fichier RDB ou AOF sur un disque managé monté sur l’instance de cache. Les fichiers de persistance sur le disque ne sont pas accessibles aux utilisateurs.
De nombreux clients souhaitent utiliser la persistance pour effectuer des sauvegardes périodiques des données dans leur cache. Nous vous déconseillons d’utiliser la persistance des données de cette façon. Utilisez plutôt la fonctionnalité d’importation/exportation. Vous pouvez exporter des copies des données de cache au format RDB directement dans le compte de stockage de votre choix et déclencher l’exportation des données aussi souvent que nécessaire. L’exportation peut être déclenchée à partir du portail ou à l’aide de l’interface CLI, de PowerShell ou des outils de SDK.
Limitations de la SKU E1
La référence SKU E1 est destinée aux scénarios dev/test principalement. E1 s’exécute sur des machines virtuelles burstables plus petites. Les machines virtuelles burstables offrent un niveau performance variable en fonction de la quantité de processeur consommée. Contrairement à d’autres offres de référence SKU Enterprise, il n’est pas possible d’effectuer un scale-out vers la référence SKU E1, bien qu’il soit toujours possible d’effectuer un scale-up vers une référence SKU plus grande. La référence SKU E1 ne prend pas en charge la géoréplication active.