Fiabilité dans Azure DocumentDB

Cet article contient des informations détaillées sur la résilience régionale avec les zones de disponibilité et la reprise d’activité inter-régions et la continuité d’activité pour Azure DocumentDB.

Pour obtenir une vue d’ensemble architecturale de la fiabilité dans Azure, consultez Fiabilité Azure.

Prise en charge des zones 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 accéder à la prise en charge des zones de disponibilité, il est nécessaire d’activer la haute disponibilité (HA).

La HA prévient les interruptions de la base de données en maintenant des réplicas de secours pour chaque fragment au sein d’un cluster. Si un fragment rencontre une défaillance, Azure DocumentDB redirige les connexions entrantes de ce fragment vers son réplica de secours.

Lorsque la HA est active dans une région compatible avec les zones de disponibilité, les fragments de réplica HA sont créés dans une zone distincte de celle de leurs fragments principaux. Les réplicas HA ne traitent pas de requêtes clientes, sauf lorsqu’une défaillance touche leur fragment principal.

Si la HA est désactivée, chaque fragment utilise un stockage localement redondant (LRS) doté de trois réplicas synchrones administrés par Azure Storage. En cas de défaillance d’un réplica unique, le service Stockage Azure détecte l’échec et recrée en toute transparence les données pertinentes. Pour davantage de précisions sur la résilience du stockage LRS, référez-vous à la section Résumé des options de redondance. Toutefois, si une région échoue, vous courez le risque de temps d’arrêt étendu et de perte de données possible.

Créer une ressource avec les zones de disponibilité activées

Pour activer les zones de disponibilité, vous devez activer la HA lors de la création d’un cluster ou depuis la section Échelle d’un cluster existant dans le portail Azure.

Récupération d’urgence et continuité d’activité inter-région

La reprise après sinistre (DR) fait référence aux pratiques utilisées par les organisations pour se remettre d’événements à fort impact, tels que des catastrophes naturelles ou des déploiements échoués qui entraînent des temps d’arrêt et des pertes de données. Quelle qu’en soit la cause, la meilleure solution en cas de sinistre est d’avoir un plan de DR bien défini et testé, et une conception d’application qui prend activement en charge la DR. Avant de commencer à créer votre plan de reprise après sinistre, consultez Recommandations pour la conception d'une stratégie de reprise après sinistre.

Pour la récupération d’urgence, Microsoft utilise le modèle de responsabilité partagée. Dans ce modèle, Microsoft garantit que l’infrastructure de base et les services de plateforme sont disponibles. Cependant, de nombreux services Azure ne répliquent pas automatiquement les données ou ne reviennent pas d’une région défaillante pour effectuer une réplication croisée vers une autre région activée. Pour ces services, vous êtes responsable de la configuration d’un plan de récupération d’urgence qui fonctionne pour votre charge de travail. La plupart des services qui s’exécutent sur des offres PaaS (Platform as a Service) Azure fournissent des fonctionnalités et des instructions pour la prise en charge de la récupération d’urgence. Vous pouvez utiliser des fonctionnalités spécifiques au service pour prendre en charge une récupération rapide afin de vous aider à développer votre plan de reprise après sinistre.

Azure DocumentDB ne propose pas de mécanisme intégré de basculement automatique ni de reprise après sinistre. La préparation en matière de haute disponibilité constitue une démarche essentielle au fur et à mesure que votre solution se développe.

Récupération d’urgence dans une zone géographique à région unique

Pour optimiser votre temps de fonctionnement, prévoyez de maintenir la continuité de l’activité et de préparer la reprise d’activité avec Azure DocumentDB.

Les services Azure sont conçus pour optimiser la continuité, et des interruptions imprévues peuvent apparaître. Un plan de reprise après sinistre vous permet de disposer d’une stratégie pour faire face aux interruptions de service régionales.

Azure DocumentDB effectue automatiquement des sauvegardes de vos données à intervalles réguliers. Les sauvegardes automatiques sont effectuées sans affecter les performances ou la disponibilité des opérations de base de données. Toutes les sauvegardes sont générées automatiquement en arrière-plan et stockées séparément des données sources dans un service de stockage. Ces sauvegardes automatiques apportent une solution en cas de suppression ou de modification accidentelle de ressources lorsqu’il est nécessaire de récupérer les versions initiales.

Les sauvegardes automatiques sont conservées selon différents intervalles, en fonction de l’activité du cluster ou de sa suppression récente.

	Durée de conservation
Clusters actifs	35 jours
Clusters supprimés	7 jours

Concevoir pour la haute disponibilité

La haute disponibilité doit être activée pour les clusters Azure DocumentDB critiques exécutant des charges de travail de production. Dans un cluster compatible HA, chaque fragment joue le rôle de fragment principal avec un fragment de secours créé dans une autre zone de disponibilité. La réplication entre le fragment principal et le fragment secondaire s’effectue de manière synchrone par défaut. Toute mise à jour de la base de données est enregistrée simultanément sur le fragment principal et le fragment secondaire en veille active avant l’envoi de la réponse.

Le service réalise des contrôles d’intégrité et des pulsations vers chaque fragment principal et secondaire du cluster. Si un fragment principal devient indisponible à la suite d’une panne de zone ou régionale, le fragment secondaire est automatiquement promu principal et un nouveau fragment de secours est créé pour ce dernier. De plus, si un fragment secondaire devient indisponible, le service génère automatiquement un nouveau fragment de secours contenant une copie complète des données du fragment principal.

Si le service initie un basculement du fragment principal vers le fragment secondaire, les connexions sont redirigées de manière transparente vers le nouveau fragment principal.

La réplication synchrone entre les fragments principal et secondaire assure l’absence totale de perte de données lors d’un basculement.

Étapes suivantes

• En savoir plus sur la compatibilité des fonctionnalités avec MongoDB.
• Passer en revue les options de migration de MongoDB vers Azure DocumentDB
• Commencez par créer un compte.