Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure Managed Redis est un service Azure entièrement managé basé sur Redis Enterprise. Il fournit un stockage de données en mémoire hautes performances pour les applications et est conçu pour les charges de travail d’entreprise qui nécessitent une latence ultra-faible, un débit élevé et des structures de données avancées.
Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.
Cet article explique comment rendre Azure Managed Redis résilient à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité et les pannes de région. Il décrit également les stratégies de sauvegarde et le contrat de niveau de service (SLA).
Recommandations concernant le déploiement de production
Pour garantir une fiabilité élevée pour vos instances Redis managées Azure de production, nous vous recommandons de :
Utilisez la haute disponibilité, qui déploie plusieurs nœuds pour votre cache.
Utilisez la redondance de zone en déployant un cache hautement disponible dans une région qui possède des zones de disponibilité.
Envisagez d’implémenter la géoréplication active pour les charges de travail essentielles nécessitant un basculement entre régions.
Vue d’ensemble de l’architecture de fiabilité
Cette section décrit certains des aspects importants du fonctionnement du service qui sont les plus pertinents du point de vue de la fiabilité. La section présente l’architecture logique, qui inclut certaines des ressources et fonctionnalités que vous déployez et utilisez. Il traite également de l’architecture physique, qui fournit des détails sur le fonctionnement du service sous les couvertures.
Architecture logique
Azure Managed Redis repose sur Redis Enterprise et offre une fiabilité grâce à des configurations de haute disponibilité et des fonctionnalités de réplication.
Vous déployez une instance d’Azure Managed Redis, également appelée instance de cache ou cache. Vos applications clientes stockent et interagissent avec les données dans le cache à l’aide des API Redis.
Architecture physique
Lorsque vous planifiez la résilience dans Azure Managed Redis, il est crucial de bien comprendre les concepts clés des nœuds et des shards.
Nœuds: Chaque instance de cache se compose de nœuds, qui sont des machines virtuelles. Chaque machine virtuelle sert d’unité de calcul indépendante dans le cluster. Vous ne voyez pas et ne gérez pas directement les VMs. La plateforme crée automatiquement des instances, surveille l’intégrité de l’instance et remplace toutes les instances qui deviennent défectueuses. Cet ensemble de machines virtuelles forme un cluster.
Vous pouvez configurer votre instance pour la haute disponibilité. Lorsque vous utilisez la haute disponibilité, Azure Managed Redis garantit que l’instance a au moins deux nœuds et réplique automatiquement les données entre elles. Dans les régions qui ont des zones de disponibilité, le service place les nœuds dans différentes zones de disponibilité. Pour plus d’informations, consultez Résilience aux échecs de zone de disponibilité.
Le service extrait le nombre spécifique de nœuds de chaque configuration pour éviter toute complexité et garantir des configurations optimales.
Éclats: Chaque nœud exécute plusieurs processus de serveur Redis appelés partitions. Chaque partition gère un sous-ensemble des données de votre cache. Lorsque vous configurez votre cache pour une haute disponibilité, les fragments se distribuent et se répliquent automatiquement sur les nœuds. Vous spécifiez une stratégie de regroupement, qui détermine la façon dont les shards se répartissent entre les nœuds.
Pour plus d’informations, consultez l’architecture Azure Managed Redis et le basculement et la mise à jour corrective pour Azure Managed Redis.
Résilience aux erreurs temporaires
Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.
Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.
Suivez ces recommandations pour gérer les erreurs temporaires lorsque vous utilisez Azure Managed Redis :
Utilisez des configurations sdk qui réessayent automatiquement lorsque des erreurs temporaires se produisent et appliquent les périodes d’interruption et de délai d’attente appropriées. Pensez à utiliser le modèle de réessai et le modèle de disjoncteur dans vos applications.
Conception pour les modèles de cache-aside, où votre application peut continuer à fonctionner avec des performances détériorées en revenant au magasin de données principal lorsque Redis devient temporairement indisponible.
Résilience aux échecs de zone de disponibilité
Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.
Vous pouvez rendre les instances de cache Redis gérées par Azure redondantes par zone, ce qui distribue automatiquement les nœuds de cache sur plusieurs zones de disponibilité au sein d'une région. La redondance de zone réduit le risque qu’un centre de données ou une panne de zone de disponibilité rend votre cache indisponible.
Pour rendre une zone de cache redondante, vous devez la déployer dans une région prise en charge et la définir pour utiliser la configuration de haute disponibilité. Dans les régions sans zones de disponibilité, la configuration de haute disponibilité crée toujours au moins deux nœuds, mais elles ne sont pas placées dans des zones distinctes.
Le diagramme suivant montre un cache redondant interzone avec deux nœuds, chacun dans une zone distincte.
Spécifications
Prise en charge de la région : Vous pouvez déployer des caches Azure Managed Redis avec redondance entre zones dans n’importe quelle région qui prend en charge les zones de disponibilité et où le service est disponible. Pour obtenir la liste des régions qui prennent en charge les zones de disponibilité, consultez les régions Azure avec des zones de disponibilité. Pour obtenir la liste des régions qui prennent en charge Azure Managed Redis, consultez la disponibilité des produits par région.
Configuration de haute disponibilité : Vous devez utiliser la configuration de haute disponibilité sur votre cache pour qu’il soit redondant interzone.
Niveaux : Tous les niveaux Redis gérés Azure prennent en charge les zones de disponibilité.
Coûts
La redondance de zone vous oblige à configurer votre cache pour la haute disponibilité, qui déploie un minimum de deux nœuds pour votre cache. La configuration de haute disponibilité coûte plus cher qu’une configuration non haute disponibilité. Pour plus d’informations, consultez la tarification d’Azure Managed Redis.
Configurez la prise en charge des zones de disponibilité
Créez une instance redondante interzone. Lorsque vous créez une instance Redis managée Azure, utilisez la configuration de haute disponibilité et déployez-la dans une région qui prend en charge les zones de disponibilité. L’instance inclut la redondance de zone par défaut, sans configuration supplémentaire requise.
Pour plus d’informations, consultez Créer une instance Redis managée Azure.
Rendez redondante une zone d'instance existante. Pour rendre redondante une instance Redis managée Azure existante, déployez-la dans une région qui prend en charge les zones de disponibilité et configurez la haute disponibilité sur le cache.
Désactivez la redondance de zone. Vous ne pouvez pas désactiver la redondance de zone sur les instances existantes, car vous ne pouvez pas inverser la haute disponibilité après l’appliquer à un cache.
Planification de capacité et gestion
Pendant un événement interzone, votre instance peut avoir moins de ressources disponibles pour servir votre charge de travail. Si votre instance subit souvent une pression sur les ressources et que vous devez vous préparer à un échec de zone de disponibilité, envisagez l’une des approches suivantes :
Surprovisionnez votre instance. Sélectionnez un niveau de performances supérieur à celui dont vous avez besoin pour que votre instance puisse tolérer une perte de capacité et continuer à fonctionner sans dégrader les performances. Pour plus d’informations, consultez Gérer la capacité en surprovisionnant et en mettant à l’échelle une instance Redis managée Azure.
Utilisez la géoréplication active. Vous pouvez déployer plusieurs instances dans différentes régions et configurer la géoréplication active pour répartir votre charge entre ces instances distinctes.
Comportement lorsque toutes les zones sont saines
Cette section décrit ce qu’il faut attendre lorsqu’un cache Redis managé est redondant interzone et que toutes les zones de disponibilité fonctionnent normalement :
Routage du trafic entre les zones : Azure Managed Redis distribue les partitions entre les nœuds en fonction de votre stratégie de cluster. Votre stratégie de cluster détermine également la façon dont le trafic est acheminé vers chaque nœud. La redondance de zone ne change pas la façon dont le service achemine le trafic.
Réplication des données entre les zones : Azure Managed Redis réplique automatiquement les partitions entre les nœuds à l’aide de la réplication asynchrone. Vous mesurez généralement le décalage de réplication entre les partitions en secondes, mais la durée exacte dépend de la charge de travail de votre cache. Les scénarios lourds en écriture et lourds sur le réseau rencontrent généralement un décalage de réplication plus élevé.
Comportement lors d’une défaillance de zone
Cette section décrit ce qu’il faut attendre lorsqu’un cache Redis managé est redondant interzone et qu’une ou plusieurs zones de disponibilité deviennent indisponibles :
- Détection et réponse : Azure Managed Redis est responsable de la détection d’un échec dans une zone de disponibilité. Vous n’avez rien à faire pour initier un failover de zone.
- Notification: Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.
Demandes actives : Le service peut supprimer les demandes en cours et les applications doivent les réessayer. Les applications doivent implémenter une logique de nouvelle tentative pour gérer ces interruptions temporaires.
Perte de données attendue : Toutes les données qui n'ont pas été répliquées sur des éclats dans une autre zone sont susceptibles d'être perdues lors de la défaillance d'une zone. Vous mesurez généralement la quantité de perte de données en secondes, mais elle dépend du décalage de réplication.
Temps d’arrêt attendu : Une brève période de temps d’arrêt, généralement de 10 à 15 secondes, peut se produire pendant que les fragments basculent vers des nœuds dans des zones actives. Pour plus d’informations sur le processus de basculement non planifié, consultez Explication d’un basculement. Lorsque vous concevez des applications, suivez les pratiques de gestion des erreurs temporaires.
Réacheminement du trafic : Azure Managed Redis redirige automatiquement le trafic vers des nœuds dans des zones saines.
Récupération de la zone
Lorsque la zone de disponibilité affectée récupère, Azure Managed Redis restaure automatiquement les opérations dans cette zone. La plateforme Azure gère entièrement ce processus et ne nécessite aucune intervention du client.
Tester les pannes de zone
Azure Managed Redis gère entièrement le routage du trafic, le basculement et la restauration après basculement pour les défaillances de zone, vous n'avez donc pas besoin de vérifier les processus de défaillance des zones de disponibilité ni de fournir d'autres entrées.
Résilience aux défaillances à l’échelle de la région
Azure Managed Redis fournit une prise en charge multirégion native par le biais de la géoréplication active, ce qui vous permet de lier plusieurs instances Redis managées Azure dans différentes régions Azure en un seul groupe de réplication. Vous pouvez ensuite configurer votre propre approche de basculement entre les instances.
La géoréplication active
Lorsque vous utilisez la géoréplication active, les applications peuvent lire et écrire dans n’importe quelle instance de cache du groupe, avec des modifications automatiquement synchronisées dans toutes les régions. Le service prend en charge les modèles de réplication actif-actif dans lesquels chaque région peut gérer simultanément les opérations de lecture et d’écriture. Lorsque des conflits se produisent en raison d’écritures simultanées dans différentes régions, le service les résout automatiquement à l’aide d’algorithmes de résolution de conflit prédéterminés sans nécessiter d’intervention manuelle. Cette approche offre une résilience aux défaillances de région tout en conservant un accès à faible latence pour les applications distribuées à l’échelle mondiale.
Le diagramme suivant montre deux instances de cache dans différentes régions au sein du même groupe de géoréplication actif, ainsi que les applications clientes qui se connectent à chaque instance de cache.
Vous êtes responsable de la configuration de vos applications clientes pour rediriger les demandes vers une instance saine si une instance régionale échoue. Le diagramme suivant montre comment une application peut rediriger ses demandes vers une instance de cache saine lorsque l’instance qu’elle utilise généralement échoue.
Spécifications
Prise en charge de la région : Vous pouvez configurer la géoréplication active Redis managée Azure entre toutes les régions Azure où le service est disponible.
Configuration de l’instance : La géoréplication active nécessite des instances Redis managées Azure qui utilisent le même niveau et la même taille dans chaque région participante. Toutes les instances de cache d’un groupe de réplication doivent utiliser des paramètres identiques, notamment les options de persistance, les modules et les stratégies de clustering.
Autres exigences : Vos instances de cache doivent répondre à d’autres exigences, y compris les modules que vous utilisez. Ces exigences affectent la façon dont vous pouvez mettre à l’échelle vos instances de cache. Pour plus d’informations, consultez conditions préalables à la géoréplication active.
Considérations
Responsabilité du basculement : Lorsque vous utilisez la géoréplication active, vous êtes responsable du basculement entre les instances de cache. Préparez votre application pour gérer le basculement. Le basculement implique la préparation et peut vous obliger à suivre plusieurs étapes. Pour plus d’informations, consultez Force-unlink lors d’une panne de région.
Cohérence éventuelle : Concevoir des applications pour gérer des scénarios de cohérence éventuels, car les modifications peuvent prendre du temps pour se propager dans toutes les régions, en fonction des conditions réseau et de la distance géographique. Pendant les pannes de région, vous pouvez rencontrer davantage d’incohérences de données jusqu’à ce que la connectivité soit restaurée et que la synchronisation se termine.
Coûts
Lorsque vous configurez la géoréplication active, vous payez pour chaque instance Redis managée Azure dans chaque région du groupe de réplication. Vous pourriez également engager des frais de transfert de données pour le trafic de réplication entre les régions. Pour plus d’informations, consultez la tarification d’Azure Managed Redis et les détails de la tarification de la bande passante.
Configurer la prise en charge multirégion
Créez une instance de cache géorépliquée. Configurez la géoréplication active lorsque vous approvisionnez le cache en spécifiant un groupe de réplication et en liant plusieurs instances. Pour plus d’informations, consultez Créer ou joindre un groupe de géoréplication actif.
Ajoutez une instance de cache existante à un groupe de géoréplication. Vous pouvez ajouter une instance de cache existante à un groupe de géoréplication actif.
Lorsque vous ajoutez une instance existante à un groupe de géoréplication actif, la plateforme doit effacer les données de l’instance et vous rencontrez un petit temps d’arrêt. Si possible, envisagez de configurer la géoréplication active lorsque vous créez des instances de cache.
Pour plus d’informations, consultez Ajouter une instance existante à un groupe de géoréplication actif.
Désactivez la géoréplication sur une instance de cache. Supprimez une instance d’un groupe de géoréplication en supprimant l’instance de cache. Les instances restantes ajustent automatiquement leurs paramètres.
Planification de capacité et gestion
Pendant un événement de panne régionale, les autres instances peuvent rencontrer une charge plus élevée. Si une instance s’exécute souvent près de ses limites de ressources et que vous devez préparer les exigences de capacité accrues lors d’une défaillance de région, envisagez de surprovisionner l’instance. Pour plus d’informations, consultez Mettre à l’échelle une instance Redis managée Azure.
Comportement lorsque toutes les régions sont saines
Cette section décrit ce qu’il faut attendre lorsque vous configurez des instances pour utiliser la géoréplication active et toutes les régions fonctionnent normalement.
Routage du trafic entre les régions : Vous êtes responsable de la configuration de vos applications pour vous connecter à une instance de cache spécifique. Les applications peuvent se connecter à n’importe quelle instance de cache dans le groupe de réplication et effectuer des opérations de lecture et d’écriture. L’application gère le routage du trafic, ce qui vous permet de diriger les clients vers la région la plus proche pour une latence minimale. Azure Managed Redis ne route pas automatiquement le trafic entre les régions.
Réplication des données entre les régions : Le service utilise la réplication asynchrone entre les régions pour maintenir la cohérence éventuelle. Il valide immédiatement les opérations d’écriture dans la région locale, puis les propage à d’autres régions en arrière-plan. Les types de données répliqués sans conflit (CRDT) garantissent que le service fusionne automatiquement les écritures simultanées dans différentes régions.
Comportement lors d’une défaillance de région
Cette section décrit ce qu’il faut attendre lorsque vous configurez des instances pour utiliser la géoréplication active et qu’une panne se produit dans une région.
Détection et réponse : Vous êtes responsable de la détection de l’échec d’une instance de cache et de la décision de déclencher un basculement. Vous pouvez surveiller l'état d'un cluster géorépliqué, afin de vous aider à décider quand commencer le basculement. Pour plus d’informations, consultez la métrique de géoréplication.
Le basculement vous oblige à effectuer plusieurs étapes. Pour plus d’informations, consultez Force-unlink lors d’une panne régionale.
Notification: Microsoft ne vous avertit pas automatiquement lorsqu’une région est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de région, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.
Vous pouvez également surveiller l’état de chaque instance.
Pour surveiller l’intégrité de la relation de géoréplication, utilisez la métrique saine de géoréplication . La métrique a toujours une valeur (
1saine) ou0(non saine). Configurez des alertes Azure Monitor sur cette métrique pour identifier quand les instances peuvent être hors synchronisation.Demandes actives : Le service met fin aux demandes adressées à la région ayant échoué, et la logique de basculement de votre application doit les gérer. Les applications doivent implémenter des stratégies de nouvelle tentative qui peuvent rediriger le trafic vers des caches sains.
Perte de données attendue : La réplication asynchrone entre les régions peut entraîner la perte d’écritures récentes dans la région ayant échoué si ces écritures n’ont pas été répliquées dans d’autres régions. La quantité de perte de données potentielle dépend du décalage de réplication au moment de l’échec. Pour plus d’informations, consultez Redis géo-distribué actif et Considérations relatives à la cohérence et à la perte de données dans une défaillance régionale de base de données répliquée sans conflit (CRDB).
Temps d’arrêt attendu : Les applications subissent un temps d’arrêt uniquement pendant la durée nécessaire pour détecter l’échec et rediriger le trafic vers des régions saines. Ce temps d’arrêt varie généralement de quelques secondes à quelques minutes et dépend de la façon dont vous configurez la configuration du contrôle d’intégrité et de la configuration du basculement de votre application.
Réacheminement du trafic : Vous êtes responsable de l’implémentation de la logique dans vos applications pour détecter les défaillances de région et router le trafic vers des régions saines. Vous pouvez implémenter cette logique via des contrôles d’intégrité, des modèles disjoncteur ou des solutions d’équilibrage de charge externe.
Récupération de région
Lorsqu’une région échouée se rétablit, Azure Managed Redis réintègre automatiquement les instances de cette région dans le groupe de géoréplication actif sans votre intervention. Le service synchronise automatiquement les données à partir d’instances saines. Pendant ce processus, les instances récupérées synchronisent progressivement les modifications qui se sont produites pendant la panne. Une fois la synchronisation terminée, les instances récupérées deviennent entièrement actives et peuvent gérer les opérations de lecture et d’écriture.
Vous êtes responsable de la reconfiguration de votre application pour router le trafic vers l’instance de région récupérée.
Tester les défaillances régionales
Testez régulièrement les procédures de basculement de votre application. Votre application doit être en mesure de basculer entre les instances et de répondre aux besoins de votre entreprise pour les temps d’arrêt pendant la transition. Testez également vos processus de réponse globaux, y compris toute reconfiguration des pare-feu et d’autres infrastructures, ainsi que votre processus de récupération.
Résilience à la maintenance du service
Azure Managed Redis gère les mises à niveau de service régulières et d’autres tâches de maintenance.
Pendant la maintenance, Azure Managed Redis crée automatiquement de nouveaux nœuds et bascule. Les applications clientes peuvent rencontrer des interruptions de connexion et d’autres erreurs temporaires. Les applications doivent implémenter une logique de nouvelle tentative pour gérer ces interruptions temporaires.
Pour plus d’informations sur les processus de maintenance Azure Managed Redis, consultez Basculement et mise à jour corrective pour Azure Managed Redis.
Sauvegarde et restauration
Azure Managed Redis fournit à la fois des fonctionnalités de persistance des données et de sauvegarde pour vous protéger contre les scénarios de perte de données que d’autres fonctionnalités de fiabilité peuvent ne pas traiter. Les sauvegardes protègent contre les scénarios tels que l’altération des données, la suppression accidentelle ou les erreurs de configuration.
Persistance des données : Par défaut, Azure Managed Redis stocke toutes les données de cache en mémoire. Le service peut éventuellement écrire des instantanés de vos données sur disque à l’aide de la persistance des données. Si une défaillance matérielle affecte le nœud, Azure Managed Redis restaure automatiquement les données. Vous pouvez choisir parmi différents types de persistance des données, qui fournissent différents compromis entre la fréquence d’instantané et les effets de performances sur votre cache.
Vous ne pouvez pas restaurer de fichiers de données vers une autre instance et vous ne pouvez pas accéder aux fichiers. La persistance des données ne vous protège pas contre la corruption ou la suppression accidentelle des données.
Importer et exporter : Azure Managed Redis prend en charge la sauvegarde de vos données lorsque vous utilisez la fonctionnalité d’importation et d’exportation, qui enregistre les fichiers de sauvegarde dans stockage Blob Azure. Vous pouvez configurer le stockage géoredondant (GRS) sur votre compte stockage Azure dans les régions prises en charge, ou vous pouvez copier ou déplacer les objets blob de sauvegarde vers d’autres emplacements pour une protection supplémentaire.
Vous pouvez restaurer des fichiers exportés vers la même instance de cache ou une autre instance de cache.
Le service n’inclut pas de planificateur intégré d’importation ou d’exportation, mais vous pouvez développer vos propres processus d’automatisation qui utilisent Azure CLI ou Azure PowerShell pour démarrer des opérations d’exportation.
Contrat de niveau de service
Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les contrats SLA pour les services en ligne.
Le contrat SLA pour Azure Managed Redis couvre la connectivité aux points de terminaison de cache. Elle ne couvre pas la protection contre la perte de données.
Pour être éligible aux contrats SLA de disponibilité pour Azure Managed Redis, vous devez répondre aux exigences suivantes :
Vous devez utiliser une configuration à haute disponibilité.
Vous ne devez pas lancer de fonctionnalités de produit ou d’actions de gestion documentées pour produire une indisponibilité temporaire.
Les contrats SLA à haute disponibilité s’appliquent lorsque votre instance est redondante interzone. Dans certains niveaux, vous pouvez devenir éligible à un contrat SLA de disponibilité plus élevé lorsque vous déployez des instances redondantes interzone dans au moins trois régions à l’aide de la géoréplication active.