Azure Cache pour Redis et excellence opérationnelle
Azure Cache pour Redis fournit un magasin de données en mémoire basé sur le logiciel Redis (Remote Dictionary Server). Il s’agit d’un cache de données sécurisé et d’un répartiteur de messagerie qui permet aux applications d’accéder aux données via un débit élevé et une faible latence.
Les meilleures pratiques qui prennent en charge l’excellence opérationnelle sont les suivantes :
Les sections suivantes incluent des considérations relatives à la conception, une check-list de configuration et des options de configuration recommandées spécifiques à Azure Cache pour Redis.
Remarques relatives à la conception
Le Contrat de niveau de service d’Azure Cache pour Redis concerne uniquement les caches de niveau Standard et Premium. Le niveau de base n’est pas concerné.
Redis est un cache en mémoire pour les paires clé/valeur. Il bénéficie d’une haute disponibilité par défaut, sauf pour le niveau de base. Il existe trois niveaux pour Azure Cache pour Redis :
De base : Non recommandé pour les charges de travail de production. Le niveau de base est idéal pour :
- Nœud unique
- Tailles multiples
- Développement
- Test
- Charges de travail non critiques
Standard : cache répliqué dans une configuration avec un cache à deux nœuds (primaire et secondaire), géré par Microsoft et assorti d’un contrat SLA garantissant une haute disponibilité.
Premium : comprend toutes les fonctionnalités de niveau Standard et comprend les autres fonctionnalités suivantes :
- Un matériel plus rapide et de meilleures performances par rapport au niveau De base ou Standard.
- Un plus grand cache, jusqu’à
120GB. - Persistance des données, qui comprend un fichier RDB et un fichier AOF.
- Prise en charge du réseau virtuel.
- Clustering
- Géoréplication : un cache secondaire se trouve dans une autre région et réplique les données du cache principal pour la récupération d’urgence. Pour basculer vers le cache secondaire, vous devez d’abord détacher les caches manuellement. Le cache secondaire deviendra alors disponible pour les écritures. L’application qui écrit dans Redis doit être mise à jour avec la chaîne de connexion du cache secondaire.
- Zones de disponibilité : déployez le cache et les réplicas entre les zones de disponibilité.
Notes
Par défaut, chaque déploiement comportera un réplica par partition. La persistance, le clustering et la géoréplication sont tous désactivés à ce stade pour les déploiements qui ont plusieurs réplicas. Vos nœuds seront répartis uniformément entre toutes les zones. Le nombre de réplicas doit être
>=nombre de zones. - Importation et exportation.
Microsoft garantit que les clients disposeront d’une connectivité entre les points de terminaison du cache et la passerelle Internet de Microsoft pendant au moins 99.9% du temps.
Liste de contrôle
Avez-vous configuré Azure Cache pour Redis en pensant à l’excellence opérationnelle ?
- planifier les mises à jour ;
- Monitorer le cache et définir des alertes.
- Déployer le cache sur un réseau virtuel.
- Utilisez le type de mise en cache approprié (locale, dans un rôle, managéz, Redis) au sein de votre solution.
- Configurer la persistance des données pour enregistrer une copie du cache dans le Stockage Azure ou utiliser la géoréplication, selon les besoins de l’entreprise.
- Utiliser une implémentation statique ou singleton du multiplexeur de connexion à Redis et suivre le guide des bonnes pratiques.
- Lire le Guide pratique pour administrer Azure Cache pour Redis.
Recommandations relatives à la configuration
Explorez le tableau de recommandations suivant dans le but d’optimiser votre configuration Azure Cache pour Redis et d’accroître l’excellence opérationnelle :
| Recommandation | Description |
|---|---|
| planifier les mises à jour ; | Planifiez les jours et les heures auxquels les mises à jour du serveur Redis doivent être appliquées au cache (cela n’inclut pas les mises à jour Azure ni les mises à jour du système d’exploitation de la machine virtuelle). |
| Monitorer le cache et définir des alertes. | Définissez des alertes pour les exceptions, l’utilisation élevée du processeur ou de la mémoire, la charge serveur et les clés supprimées afin de savoir quand mettre à l’échelle le cache. Si le cache doit être mis à l’échelle, il est important de savoir à quel moment vous pouvez le faire, car la mise à l’échelle entraîne l’augmentation de l’utilisation du processeur pour la migration des données. |
| Déployer le cache sur un réseau virtuel. | Cela donne au client davantage de contrôle sur le trafic qui peut se connecter au cache. Vérifiez que le sous-réseau dispose de suffisamment d’espace d’adressage pour déployer les nœuds de cache et les partitions (cluster). |
| Utilisez le type de mise en cache approprié (locale, dans un rôle, managéz, Redis) au sein de votre solution. | Les applications distribuées implémentent généralement une des deux stratégies suivantes ou les deux lors de la mise en cache des données : - Utilisation d’un cache privé, où les données sont stockées localement sur la machine exécutant une instance d’une application ou d’un service. - Utilisation d’un cache partagé, agissant comme une source commune accessible par plusieurs machines et processus. Dans les deux cas, la mise en cache peut être effectuée côté client et côté serveur. La mise en cache côté client est effectuée par le processus qui fournit l’interface utilisateur pour un système, tel qu’un navigateur web ou une application de bureau. La mise en cache côté serveur est effectuée par le processus qui fournit les services professionnels exécutés à distance. |
| Configurer la persistance des données pour enregistrer une copie du cache dans le Stockage Azure ou utiliser la géoréplication, selon les besoins de l’entreprise. | Persistance des données : si l’instance maître et le réplica redémarrent, les données seront chargées automatiquement à partir du compte de stockage. Géoréplication : le cache secondaire doit être détaché du cache principal. Le cache secondaire devient alors le cache principal et peut recevoir des écritures. |
| Lire le Guide pratique pour administrer Azure Cache pour Redis. | Découvrez comment les redémarrages du cache peuvent provoquer une perte de données et comment tester l’application à des fins de résilience. |
Artefacts sources
Pour identifier les instances Redis qui n’ont pas le niveau Premium, utilisez la requête suivante :
Resources
| where type == 'microsoft.cache/redis'
| where properties.sku.name != 'Premium'