Fiabilité dans Azure DocumentDB

Azure DocumentDB est un service de base de données NoSQL entièrement managé pour le développement d’applications modernes avec la compatibilité MongoDB. Azure DocumentDB prend en charge une configuration de haute disponibilité (HA) avec des réplicas de secours à chaud répliqués de manière synchrone et une redondance de zone. Il fournit également un réplica en lecture facultatif dans une autre région Azure et des sauvegardes automatiques avec une rétention à un point dans le temps pour vous protéger contre la perte accidentelle de données.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft offre une gamme de fonctionnalités permettant de 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 DocumentDB résiliente à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité, les pannes de région et la maintenance du service. Il décrit également le comportement de sauvegarde et fournit des informations clés sur la haute disponibilité et la réplication inter-régions.

Recommandations de déploiement de production pour la fiabilité

Pour obtenir une liste de recommandations pour améliorer la fiabilité de votre cluster, consultez les meilleures pratiques pour la haute disponibilité (HA) et la réplication multirégion dans Azure DocumentDB.

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

La ressource principale que vous déployez est un cluster DocumentDB Azure. Pour chaque cluster, vous choisissez un niveau de calcul et configurez le stockage. Votre niveau sélectionné détermine les fonctionnalités disponibles pour les fonctionnalités de fiabilité telles que la haute disponibilité et affecte également la façon dont vous planifiez la capacité pour les scénarios de résilience.

Les applications se connectent à un cluster à l’aide de chaînes de connexion et de points de terminaison. Azure DocumentDB fournit des points de terminaison pour les opérations en lecture-écriture et, si c'est configuré, des points de terminaison pour les clusters de réplica en lecture. Ces points de terminaison permettent à votre application de continuer à utiliser des modèles de connexion stables tandis que le service gère le comportement de basculement en arrière-plan.

Au sein de chaque cluster, vos données sont organisées en tant que bases de données, collections et documents. Ce modèle de données compatible MongoDB est la base des décisions de conception au niveau de la charge de travail, telles que la stratégie de partitionnement, les modèles de lecture et d’écriture, ainsi que l’étendue de sauvegarde et de restauration.

Architecture physique

Azure DocumentDB exécute votre cluster sur des partitions, qui représentent des nœuds (machines virtuelles) qui exécutent le service. Vous pouvez déployer une partition unique ou passer à plusieurs partitions. Le déploiement de plusieurs partitions améliore la capacité de mise à l'échelle, mais n'apporte pas de haute disponibilité (HA) en soi.

Lorsque vous activez la haute disponibilité, Azure DocumentDB crée un ensemble équivalent de partitions de secours. Chaque partition principale a une partition de secours. Le service réplique les données de manière synchrone entre chaque paire partition principale/partition de secours, et promeut la partition de secours en cas de défaillance de la partition principale. Pour plus d’informations sur la haute disponibilité, consultez Haute disponibilité dans Azure DocumentDB.

Azure DocumentDB utilise stockage Azure pour la durabilité des partitions. Si la haute disponibilité est désactivée, chaque partition utilise un stockage localement redondant (LRS). LRS conserve trois copies des données, mais elle n’est pas résiliente à la perte d’une zone de disponibilité. Pour plus d’informations sur la durabilité LRS, consultez Résumé des options de redondance.

Pour plus d’informations, consultez Disponibilité et récupération d’urgence dans Azure DocumentDB : en arrière-plan.

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, voir Recommandations concernant le traitement des pannes transitoires.

Azure DocumentDB est compatible avec le protocole MongoDB. Par conséquent, les applications se connectent généralement à l’aide de pilotes MongoDB. Vous êtes responsable de la configuration des paramètres de nouvelle tentative du pilote de votre application pour gérer les défaillances temporaires, en particulier les interruptions de connexion et les interruptions d’écriture courtes pendant les événements de basculement. Suivez ces instructions :

  • Utilisez les pilotes MongoDB qui prennent en charge la gestion automatique des nouvelles tentatives pour les défaillances de connectivité temporaires.

  • Configurez les réessais avec une temporisation exponentielle et limitez le nombre de tentatives.

  • Dans la mesure du possible, concevez des opérations d’écriture pour qu’elles soient idempotentes afin que les nouvelles tentatives soient sécurisées. Pour obtenir des conseils généraux de mise en œuvre sur l’idempotence, consultez le modèle de consommateur idempotent.

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.

Pour utiliser la prise en charge des zones de disponibilité dans Azure DocumentDB, activez la haute disponibilité(HA). Lorsque vous activez la haute disponibilité dans une région prenant en charge les zones de disponibilité, votre cluster devient redondant entre zones, car Azure DocumentDB place les fragments de secours dans une zone de disponibilité différente de celle de leurs fragments principaux. Les partitions de secours ne reçoivent pas de demandes clientes, sauf si leur partition principale échoue.

Si vous désactivez la haute disponibilité, Azure DocumentDB ne place pas de partitions de secours dans une autre zone de disponibilité. Par conséquent, une défaillance de zone de disponibilité peut rendre votre cluster indisponible.

Diagramme d’un cluster documentDB Azure redondant interzone avec des partitions principales et de secours dans des zones de disponibilité distinctes.

Spécifications

  • Prise en charge de la région : Pour utiliser des zones de disponibilité avec Azure DocumentDB, choisissez une région qui prend en charge les deux Azure DocumentDB et les zones de disponibilité. Vérifiez les produits disponibles par région et comparez-les aux régions qui prennent en charge les zones de disponibilité.

  • Haute disponibilité : Vous devez activer la haute disponibilité sur le cluster. La HA exige que le cluster utilise le niveau de service de calcul M30 (ou supérieur).

Considerations

Bien que certaines API DocumentDB Azure incluent des références aux modes de déploiement de même zone, Azure DocumentDB ne prend pas en charge les déploiements haute disponibilité de même zone. Le service prend en charge les déploiements HA avec redondance de zone.

Distribution d’instances entre zones

Microsoft sélectionne deux zones de disponibilité pour le cluster. Dans les déploiements haute disponibilité redondant interzone, Azure DocumentDB place toutes les partitions principales dans une zone et toutes les partitions de secours dans l’autre zone.

Cost

Lorsque la haute disponibilité est activée, Azure DocumentDB provisionne une partition de secours pour chaque partition principale, ce qui augmente le coût de calcul et de stockage de votre cluster. Dans les régions qui prennent en charge les zones de disponibilité, la haute disponibilité rend également redondante la zone de cluster. Dans certains modes de déploiement, Azure DocumentDB active la haute disponibilité par défaut. Pour les charges de travail de production, laissez HA activé. Pour les charges de travail de développement et de test, vous pouvez désactiver la haute disponibilité pour réduire les coûts. Pour plus d’informations sur la tarification, consultez Azure tarification DocumentDB.

Configurez la prise en charge des zones de disponibilité

  • Créez un cluster Azure DocumentDB redondant entre zones : lorsque vous créez un cluster dans une région qui prend en charge les zones de disponibilité, activez la haute disponibilité pour rendre le cluster redondant entre zones. Pour obtenir des instructions détaillées, consultez Démarrage rapide : Créer un cluster DocumentDB Azure à l’aide du portail Azure.

  • Activez la redondance de zone sur un cluster Azure DocumentDB existant : Vous pouvez activer la haute disponibilité sur un cluster existant. Il n’existe aucun temps d’arrêt de base de données lorsque la haute disponibilité est activée ou désactivée sur un cluster Azure DocumentDB. Pour obtenir des instructions détaillées, consultez Mettre à l’échelle un cluster DocumentDB Azure.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce que vous devez attendre lorsque vous configurez un cluster DocumentDB Azure pour la haute disponibilité dans une région qui prend en charge les zones de disponibilité, et toutes les zones sont opérationnelles.

  • Fonctionnement interzone : Les shards primaires traitent toutes les requêtes des clients. Les partitions de secours dans une autre zone de disponibilité ne reçoivent pas de demandes clientes, sauf si le serveur principal échoue.

  • Réplication des données interzones : La réplication entre les partitions principales et de secours est synchrone. Les écritures sont conservées sur les partitions principales et de secours avant que le service ne renvoie une réponse.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu'il faut attendre lorsque vous configurez un cluster DocumentDB Azure pour la haute disponibilité dans une région qui prend en charge les zones de disponibilité, et qu'il existe une panne dans l'une des zones.

  • Détection et réponse : Microsoft surveille l’intégrité des partitions et gère les opérations de détection et de basculement pour vous. Si une partition principale devient indisponible en raison d’une panne de zone, Azure DocumentDB promeut automatiquement la partition de secours, puis reconstruit la redondance en créant une partition de secours.

  • 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.

  • Requêtes actives : les requêtes en cours qui n’ont pas été confirmées avant le basculement peuvent échouer et doivent être renvoyées par le client. Si votre application gère les erreurs temporaires, ces nouvelles tentatives se terminent généralement automatiquement.

  • Perte de données attendue : Azure DocumentDB réplique les données de manière synchrone entre les partitions primaires et de secours. Par conséquent, aucune perte de données n’est attendue.

  • Temps d’arrêt attendu : Aucun temps d’arrêt n’est attendu pour les opérations de lecture. Pour les opérations d’écriture, une brève interruption peut se produire le temps que le basculement s’achève. Si votre application retente correctement les erreurs temporaires , cela apparaît généralement comme un ralentissement court.

  • Redistribution : Le chaîne de connexion ne change pas, de sorte que les clients continuent à utiliser le même point de terminaison. Le service redirige automatiquement le trafic vers les partitions de secours promues et reconstruit de nouvelles partitions de secours.

Récupération de la zone

Lorsque la zone de disponibilité récupère, Azure DocumentDB restaure automatiquement les opérations normales sur toutes les zones utilisées par le cluster.

Tester les pannes de zone

La plateforme Azure DocumentDB gère le routage du trafic, le basculement et la récupération de zone pour les clusters redondants interzone. Vous n’avez pas besoin de lancer ou de valider les processus de défaillance de zone de disponibilité.

Résilience aux défaillances à l’échelle de la région

Vous déployez chaque cluster DocumentDB Azure dans une seule région Azure. Pour assurer la résilience en cas de défaillance d’une région, configurez la réplication interrégion en ajoutant un cluster réplica dans une autre région.

Réplication entre régions

Azure DocumentDB prend en charge la réplication inter-régions via un cluster de réplica. Le cluster réplica apparaît comme un cluster distinct dans votre groupe de ressources. Vous pouvez utiliser ce cluster réplica pour la reprise après sinistre et la montée en charge en lecture. Azure DocumentDB réplique automatiquement et de manière asynchrone les modifications de données du cluster principal vers le cluster réplica.

Schéma de la réplication asynchrone d’un cluster principal Azure DocumentDB vers un cluster réplique en lecture situé dans une autre région.

Si votre région primaire tombe en panne, le cluster répliqué peut être promu au rang de cluster en lecture/écriture. La chaîne de connexion globale en lecture-écriture est automatiquement mise à jour afin de pointer vers le cluster promu.

Schéma d’un réplica Azure DocumentDB promu qui gère le trafic après la défaillance de la région primaire.

Cette section récapitule les considérations de fiabilité pour la réplication inter-régions. Pour plus d’informations, consultez Gérer la réplication interrégion et la même région sur votre Azure cluster DocumentDB et les meilleures pratiques de réplication interrégion et de même région dans Azure DocumentDB.

Basculement entre les régions

Azure DocumentDB prend en charge trois modes de promotion :

  • Promotion forcée : Promeut immédiatement le cluster de réplication afin qu’il accepte les opérations d’écriture et redirige le trafic d’écriture entrant via la chaîne de connexion globale en lecture-écriture. Ce mode réduit les temps d’arrêt, mais peut entraîner une perte de données, car il perd les écritures non répliquées.

  • Basculement géré par le service : Vous pouvez configurer votre cluster pour utiliser le basculement géré par le service. Microsoft surveille votre cluster principal et déclenche automatiquement une promotion forcée si le cluster principal n’est pas sain.

  • Promotion appropriée : empêche la perte de données, mais nécessite un temps d’arrêt pendant que les écritures non répliquées sont répliquées. La promotion appropriée nécessite que les deux clusters soient sains. Vous ne pouvez donc pas l’effectuer lors d’une panne de région.

Pour plus d’informations, consultez les modes de basculement entre régions dans Azure DocumentDB.

Spécifications

  • Prise en charge de la région : Vous pouvez utiliser la réplication interrégion dans toutes les régions Azure qui prennent en charge Azure DocumentDB.

  • Niveau de calcul : La réplication interrégion nécessite le niveau de calcul M30 ou supérieur.

Considerations

  • Accès réseau : Les clusters réplicas n’héritent pas des paramètres réseau du cluster principal. Configurez séparément des règles de pare-feu ou des points de terminaison privés sur le cluster répliqué, et testez la connectivité avant un basculement. Pour plus d’informations, consultez Écritures continues, opérations de lecture sur les réplicas de cluster et chaînes de connexion.

  • Prise en charge des fonctionnalités : Les clusters de réplication ne prennent pas en charge la restauration à un instant donné (PITR) ni la haute disponibilité au sein de la région.

    Si la haute disponibilité est activée sur le cluster principal, vous êtes responsable de la réactivation de la haute disponibilité sur le cluster promu.

    Pour plus d’informations, consultez Azure limites et quotas de service DocumentDB.

Cost

La réplication interrégion ajoute des coûts pour les ressources de calcul et de stockage du cluster de réplication. Les frais de transfert de données inter-régions s’appliquent également. Pour plus d’informations sur la tarification, consultez Azure tarification documentDB et tarification de la bande passante.

Configurer la prise en charge de la multirégion

  • Créez un cluster de réplica : Pour activer la réplication interrégion, créez un cluster de réplica à partir de votre cluster principal. Vous pouvez créer un cluster de réplication au moment de créer le cluster principal ou ultérieurement. Pour connaître les étapes à suivre, consultez Gérer la réplication interrégion et la même région sur votre cluster DocumentDB Azure.

  • Configurer le basculement automatique : Si vous souhaitez qu’Azure promeuve automatiquement la réplique en cas de panne de la région primaire, activez le basculement géré par le service. Pour plus d’informations, consultez Activer le basculement géré par le service.

    Note

    Microsoft ne déclenche généralement un basculement géré par le service qu’en cas d’événements extrêmes, tels qu’une panne touchant toute une région ou un grand nombre de clients affectés. Il peut y avoir un délai avant que le basculement ne se déclenche. Si vous devez rétablir rapidement la disponibilité, nous vous recommandons de gérer le processus de basculement à l’aide de la promotion forcée à l'initiative du client.

Comportement lorsque toutes les régions sont saines

Cette section décrit ce qu’il faut attendre lorsque vous configurez un cluster DocumentDB Azure pour la réplication inter-régions et que toutes les régions sont opérationnelles.

  • Opération interrégion : Le cluster principal sert tout le trafic en lecture-écriture. Le cluster de réplicas gère le trafic en lecture seule, que vous pouvez utiliser afin de faire monter en charge les charges de travail en lecture ou de maintenir le trafic de lecture local dans une région spécifique. La chaîne de connexion globale en lecture-écriture pointe toujours vers le cluster actuellement accessible en écriture, de sorte que les clients n’ont pas besoin de savoir quelle région est primaire.

  • Réplication des données interrégions : La réplication entre le cluster principal et le cluster réplica est asynchrone. Les écritures sont validées dans le cluster principal et leur réception est confirmée au client avant d’être répliquées vers le cluster de réplication. Cette approche empêche la latence réseau inter-régions d’affecter les performances d’écriture. Étant donné que la réplication est asynchrone, un certain décalage de réplication est à prévoir entre les clusters principal et réplica, et toute écriture non répliquée peut être perdue lors d’un basculement forcé.

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

Cette section décrit ce qu'il faut attendre lorsque vous configurez un cluster DocumentDB Azure pour la réplication inter-régions et qu'il existe une panne dans la région du cluster principal.

  • Détection et réponse : La responsabilité de détecter la panne et de répondre dépend du type de basculement utilisé par votre cluster.

    • Si le basculement géré par le service est activé, Azure DocumentDB détecte la panne et effectue automatiquement une promotion forcée du cluster réplica.
    • Si le basculement géré par le service n’est pas activé, il vous incombe de détecter la panne et de déclencher une promotion forcée.

    Pour plus d’informations, consultez les modes de basculement entre régions dans Azure DocumentDB.

  • 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.

  • Demandes actives : Toutes les demandes actives adressées à la région primaire ayant échoué peuvent échouer. Une fois le basculement terminé, les applications doivent se reconnecter et relancer leurs tentatives de connexion vers le cluster promu.

  • Perte de données attendue : Les basculements en cas de panne régionale ne sont pas planifiés, de sorte que les écritures non répliquées peuvent être perdues, car la réplication est asynchrone.

  • Temps d’arrêt attendu : Le temps d’arrêt global dépend du temps de détection, du mode de basculement et du comportement de reconnexion du client.

    Pour la promotion forcée initiée par le client, le temps d’arrêt total inclut le temps nécessaire pour détecter la panne et lancer vos processus de réponse, ainsi que le temps d’exécution de la promotion.

    Une fois qu’une promotion est lancée, elle se termine généralement en quelques minutes.

  • Redirection : La chaîne de connexion globale en lecture-écriture pointe automatiquement vers le cluster promu après la promotion. Les applications qui utilisent des chaînes de connexion spécifiques au cluster peuvent nécessiter des mises à jour de configuration afin qu’elles dirigent le trafic vers le cluster sain.

Récupération de région

Azure DocumentDB ne revient pas automatiquement à la région d'origine après sa récupération. Pour retourner des opérations d’écriture dans la région d’origine, effectuez une autre promotion après avoir rétabli votre topologie préférée. Utilisez une promotion appropriée pour éviter toute perte de données pendant la restauration automatique. Une promotion appropriée nécessite une petite quantité de temps d’arrêt et vous pouvez l’effectuer à la fois que vous choisissez, comme pendant une fenêtre de maintenance. Pour plus d’informations, consultez Déclencher une promotion en douceur.

Tester les défaillances régionales

Testez régulièrement votre processus de récupération après sinistre en promouvant le cluster réplica dans un environnement contrôlé.

  • Utilisez la promotion forcée pour simuler le comportement en cas de panne. Ce test peut entraîner une perte de données. Envisagez donc d’exécuter ce test dans un environnement hors production. Pour plus d’informations, consultez Déclencher une promotion forcée.

  • Utilisez la promotion appropriée pour les exercices de basculement planifiés lorsque vous souhaitez éviter toute perte de données. Pour plus d’informations, consultez Déclencher une promotion en douceur.

Sauvegarde et restauration

La réplication et la prise en charge des zones de disponibilité aident à maintenir un cluster disponible pendant les défaillances de l’infrastructure. Azure DocumentDB prend automatiquement des sauvegardes continues, qui répondent à un autre risque en activant la récupération à un point dans le temps (PITR) après avoir supprimé ou modifié accidentellement des données. Azure DocumentDB effectue des sauvegardes sans affecter les performances ou la disponibilité des opérations de base de données. Pour plus d’informations sur la façon dont la réplication et la sauvegarde répondent à différents risques, consultez Redondance, réplication et sauvegarde.

Azure DocumentDB stocke les sauvegardes séparément des données sources. Dans les régions qui prennent en charge les zones de disponibilité, le service stocke les instantanés de sauvegarde dans trois zones de disponibilité. Azure DocumentDB gère ces sauvegardes et vous ne pouvez pas les exporter. Le service conserve les sauvegardes pendant 35 jours pour les clusters actifs, 7 jours pour les clusters de niveau burstable actif (M10, M20, M25) et 7 jours pour les clusters supprimés.

Vous pouvez restaurer une sauvegarde sur un nouveau cluster. Après cela, vous devez effectuer un ensemble de tâches postérieures à la restauration.

Pour plus d’informations, consultez Restaurer un cluster dans Azure DocumentDB.

Résilience à la maintenance du service

Microsoft applique régulièrement des mises à jour de service et effectue d’autres maintenances. La plateforme Azure gère automatiquement ces activités, ce qui garantit que la maintenance est fluide et transparente pour vous. Aucun temps d'arrêt n'est prévu pendant les événements de maintenance, sauf si vous avez été informé via la maintenance planifiée d'Azure Service Health.

Les événements de maintenance planifiée peuvent toujours entraîner de brefs échecs temporaires pour les opérations du client. Votre application doit gérer ces événements en suivant les recommandations relatives aux nouvelles tentatives décrites dans Résilience face aux erreurs temporaires.

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 SLA pour les services en ligne.

Pour Azure DocumentDB, les contrats SLA de disponibilité s’appliquent uniquement lorsque votre cluster dispose d’une haute disponibilité activée. Différentes contrats SLA de disponibilité s’appliquent aux configurations suivantes :

  • Clusters haute disponibilité (HA) répartis sur plusieurs régions Azure grâce à la réplication interrégion.

  • Clusters compatibles HA dans une seule région.

Contenu connexe

  • Last updated on