Fiabilité dans Azure Managed Redis

Azure Managed Redis propose Redis Enterprise entièrement intégré et géré sur Azure, offrant un stockage de données en mémoire haute performance pour les applications. Ce service est conçu pour les charges de travail d’entreprise nécessitant 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 décrit la fiabilité dans Azure Managed Redis, notamment la résilience aux erreurs temporaires, aux défaillances de zone de disponibilité et aux défaillances à l’échelle de la région. L’article 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 :

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

Il existe deux concepts clés que vous devez comprendre lors de la planification de la résilience pour Azure Managed Redis : les nœuds et les 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 gère automatiquement la création d'instances, la surveillance de l'état de santé et le remplacement des instances défectueuses. L’ensemble de machines virtuelles, regroupées, est également appelée cluster.

  Vous pouvez configurer votre instance pour la haute disponibilité. Dans ce cas, Azure Managed Redis garantit qu’il y a au moins deux nœuds et qu’il réplique automatiquement les données entre les nœuds. Dans les régions avec des zones de disponibilité, les nœuds sont placés 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 utilisés dans chaque configuration pour éviter toute complexité et garantir des configurations optimales.

• Partitions : chaque nœud exécute plusieurs processus de serveur Redis appelés partitions, qui gèrent un sous-ensemble des données de votre cache. Lorsque votre cache est configuré pour la haute disponibilité, les partitions sont automatiquement distribuées et répliquées entre les nœuds. Vous spécifiez une stratégie de cluster, qui détermine la façon dont les shards sont distribués au sein des 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 lors de l’utilisation d’Azure Managed Redis :

• Utilisez des configurations du KIT de développement logiciel (SDK) qui réessayent automatiquement lorsque des erreurs temporaires se produisent, et qui utilisent 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égradées lorsque Redis est temporairement indisponible en revenant au magasin de données principal.

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.

Les instances de cache Azure Managed Redis peuvent être converties en instances redondantes interzones, distribuant 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 de pannes de centre de données ou de zone de disponibilité entraînant l’indisponibilité de votre cache.

Pour rendre une zone de cache redondante, vous devez la déployer dans une région prise en charge et activer 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 se trouvent pas 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 : Les caches Azure Redis managés redondants entre zones peuvent être déployés dans n’importe quelle région qui prend en charge les zones de disponibilité et où le service est disponible. Pour obtenir la liste la plus actuelle 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 activer la configuration de haute disponibilité sur votre cache pour qu’elle soit redondante interzone.

• Niveaux : tous les niveaux Azure Managed Redis prennent en charge les zones de disponibilité.

Coûts

La redondance de zone nécessite que votre cache soit configuré pour la haute disponibilité, qui déploie au minimum deux nœuds pour votre cache. La configuration de haute disponibilité est facturée à un taux plus élevé que la 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, activez la configuration de haute disponibilité et déployez-la dans une région avec des zones de disponibilité. Ensuite, il inclut automatiquement la redondance de zone par défaut. Il n’est pas nécessaire d’effectuer une configuration supplémentaire.

  Pour obtenir des instructions détaillées, consultez Démarrage rapide : Créer une instance Redis managée Azure.

• Activez la redondance de zone sur une instance existante : Pour configurer une instance Redis managée Azure existante pour qu’elle soit redondante interzone, assurez-vous qu’elle est déployée dans une région qui prend en charge les zones de disponibilité et active la haute disponibilité sur le cache.

• Désactivez la redondance de zone : La redondance de zone ne peut pas être désactivée sur les instances existantes, car vous ne pouvez pas désactiver la haute disponibilité une fois qu’elle est activée sur une instance de 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 est souvent sous 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 : Le surprovisionnement implique la sélection d’un niveau de performances supérieur à celui dont vous avez besoin. Elle permet à votre instance de tolérer une perte de capacité et de continuer à fonctionner sans dégradation des performances. Pour plus d’informations sur le principe de surprovisionnement, consultez Gérer la capacité en surprovisionnant. Pour savoir comment mettre à l’échelle votre instance, consultez Mettre à 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é sont opérationnelles :

• Routage du trafic entre les zones : Les partitions sont réparties 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 trafic est routé.

• Réplication des données entre les zones : Les fragments sont répliqués automatiquement entre les nœuds et utilisent la réplication asynchrone. En règle générale, le décalage de réplication entre les partitions est mesuré en secondes, mais cela peut varier en fonction de la charge de travail du cache, avec des scénarios lourds en écriture et lourds sur le réseau qui voient 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é ne sont pas disponibles :

• 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 : les demandes en cours peuvent être abandonnées et devront être retentées. 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. En règle générale, la quantité de perte de données est mesurée en secondes, mais dépend du décalage de réplication.

• Temps d’arrêt attendu : une petite quantité de temps d’arrêt, généralement de 10 à 15 secondes, peut se produire pendant que les partitions basculent sur des nœuds situés dans des zones saines. 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

Étant donné qu’Azure Managed Redis gère entièrement le routage du trafic, le basculement et le retour à la normale pour les défaillances de zone de disponibilité, vous n’avez pas besoin de vérifier les processus de défaillance de zone de disponibilité ou de fournir d’autres informations.

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 synchronisées automatiquement entre 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, avec des applications clientes qui se connectent à chaque instance de cache :

Vous êtes responsable de la configuration de vos applications clientes afin que, si une instance régionale échoue, elle puisse rediriger ses demandes vers une instance saine. 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 des régions La géoréplication active Redis managée Azure peut être configurée 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 de même niveau et de même taille dans toutes les régions participantes. Toutes les instances de cache d’un groupe de réplication doivent être configurées avec 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, notamment les modules que vous utilisez, et cela affecte la façon dont vos instances de cache peuvent être mises à l’échelle. 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. Vous devez préparer et configurer votre application pour gérer le basculement. Le basculement implique la préparation et peut nécessiter que vous complétiez plusieurs étapes. Pour plus d’informations, consultez Force-unlink s’il existe une panne de région.

• Cohérence éventuelle : Les applications doivent être conçues pour gérer les 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 soit terminée.

Coûts

Lorsque vous activez la géoréplication active, vous êtes facturé pour chaque instance Redis managée Azure dans chaque région du groupe de réplication. En outre, vous risquez d’entraîner des frais de transfert de données pour le trafic de réplication inter-régions entre les régions. Pour plus d’informations sur la tarification, consultez la tarification 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 pendant l’approvisionnement du 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.

• Activez une instance de cache existante pour la géoréplication : vous pouvez ajouter une instance de cache existante à un groupe de géoréplication actif.

  Toutefois, lorsqu’une instance existante est ajoutée à un groupe de géoréplication actif, les données de l’instance doivent être vidées et il y a une petite quantité de temps d’arrêt. Si possible, envisagez d’activer 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ésactiver 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 se reconfigurent automatiquement.

Planification de capacité et gestion

Pendant un événement d'indisponibilité de région, les autres instances pourraient être sous une pression accrue. Si une instance est souvent sous pression sur les 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 savoir comment mettre à l’échelle une instance, 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 des instances sont configurées pour utiliser la géoréplication active et toutes les régions sont opérationnelles.

• Routage du trafic entre 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. Le routage du trafic est géré par l’application, ce qui vous permet de diriger les clients vers la région la plus proche pour une latence minimale. Azure Managed Redis ne fournit pas de routage automatique du trafic entre les régions.

• Réplication des données entre régions : le service utilise la réplication asynchrone entre les régions pour maintenir la cohérence éventuelle. Les opérations d’écriture sont immédiatement validées dans la région locale, puis propagées vers d’autres régions en arrière-plan. Les types de données répliqués sans conflit (CRDT) garantissent que les écritures simultanées dans différentes régions sont automatiquement fusionnées.

Comportement lors d’une défaillance de région

Cette section décrit ce qu’il faut attendre lorsque des instances sont configurées pour utiliser la géoréplication active et qu’il existe une panne 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 quand basculer. Vous pouvez surveiller l’intégrité d’un cluster géorépliqué, ce qui peut vous aider à décider quand commencer le basculement. Pour plus d’informations, consultez la métrique de géoréplication.

  Le basculement nécessite l’exécution de plusieurs étapes. Pour plus d’informations, consultez Force-unlink s’il existe une panne de région.

• 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’état de santé de la relation de géoréplication, vous pouvez utiliser la métrique de géoréplication saine. La métrique a toujours une valeur ( 1 saine) ou 0 (non saine). Vous pouvez configurer des alertes Azure Monitor sur cette métrique pour comprendre quand les instances peuvent être désynchronisées.

• Demandes actives : les demandes adressées à la région ayant échoué sont arrêtées et doivent être gérées par la logique de basculement de votre application. 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 : en raison d’une réplication asynchrone entre les régions, certaines écritures récentes dans la région ayant échoué peuvent être perdues si elles n’avaient pas encore é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 Active-Active Redis géodistribué et considérations relatives à la cohérence et à la perte de données dans une défaillance régionale 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. Cela varie généralement de quelques secondes à quelques minutes, selon la façon dont vous avez configuré 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 acheminer le trafic vers des régions saines. Pour ce faire, vous pouvez effectuer des vérifications d’intégrité, des modèles de disjoncteurs ou des solutions d’équilibrage de charge externe.

Récupération de la région

Lorsqu’une région ayant échoué se récupère, Azure Managed Redis réinscrire automatiquement les instances de cette région dans le groupe de géoréplication actif sans nécessiter votre intervention. Le service synchronise automatiquement les données à partir d’instances saines. Pendant ce processus, l’instance récupérée rattrape 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

Vous devez tester régulièrement les procédures de basculement de votre application. Il est important que votre application puisse basculer entre les instances et qu'elle respecte vos exigences professionnelles pour les temps d’arrêt lors de cette opération. Il est également important de tester 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 effectue des mises à niveau de service régulières et d’autres tâches de maintenance.

Lorsque la maintenance est en cours, Azure Managed Redis effectue automatiquement des créations de nœuds et effectue automatiquement le basculement. Les applications clientes peuvent voir 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 en savoir plus sur les processus de maintenance pour 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 se protéger contre les scénarios de perte de données que d’autres fonctionnalités de fiabilité peuvent ne pas traiter. Les sauvegardes peuvent fournir une protection 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. Il peut éventuellement écrire des instantanés de vos données sur disque à l’aide de la persistance des données. En cas de défaillance matérielle qui affecte le nœud, Azure Managed Redis restaure automatiquement les données. Il existe différents types de persistance des données à partir desquels vous pouvez effectuer une sélection, qui fournissent différents compromis entre la fréquence d’instantané et les effets de performances sur votre cache.

  Toutefois, les fichiers de données ne peuvent pas être restaurés sur une autre instance et vous ne pouvez pas accéder aux fichiers. La persistance des données ne vous protège pas contre l’altération des données ou la suppression accidentelle.

• Importer et exporter : Azure Managed Redis prend en charge la sauvegarde de vos données à l’aide de la fonctionnalité d’importation et d’exportation, qui enregistre les fichiers de sauvegarde dans Stockage Blob Azure. Vous pouvez configurer le stockage géoredondant sur votre compte stockage Azure, ou vous pouvez copier ou déplacer les objets blob de sauvegarde vers d’autres emplacements pour une protection supplémentaire.

  Les fichiers exportés peuvent être restaurés dans la même instance de cache ou dans une autre instance de cache.

  Il n’existe aucun planificateur d’importation ou d’exportation intégré, mais vous pouvez développer vos propres processus d’automatisation qui utilisent Azure CLI ou Azure PowerShell pour lancer 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. Le contrat SLA 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 activer la configuration de la 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 être éligible à un contrat SLA de disponibilité plus élevé lorsque vous avez déployé des instances redondantes interzone dans au moins trois régions à l’aide de la géoréplication active.