Partager via

Fiabilité dans Azure Cosmos DB for MongoDB vCore

  • Article

S’APPLIQUE À : MongoDB vCore

Cet article contient des informations précises sur la résilience régionale avec des zones de disponibilité et sur la récupération d'urgence et la continuité des activités entre régions pour Azure Cosmos DB for MongoDB vCore.

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 de centres de données physiquement séparés au sein de chaque région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Pour plus d’informations sur les zones de disponibilité dans Azure, consultez Que sont les zones de disponibilité ?.

Pour obtenir la prise en charge de la zone de disponibilité, vous devez activer la haute disponibilité (HA).

La haute disponibilité évite les temps d'arrêt de la base de données en conservant des réplicas de secours de chaque partition d'un cluster. Si une partition devient inactive, le cœur virtuel Azure Cosmos DB for MongoDB bascule les connexions entrantes de la partition défaillante vers son réplica de secours.

Lorsque la HA est activée dans une région qui prend en charge les zones de disponibilité, les partitions de réplica de HA sont approvisionnées dans une zone de disponibilité différente de leurs partitions principales. Les réplicas à haute disponibilité ne reçoivent pas de demandes de clients, sauf si leur partition principale échoue.

Si la HA est désactivée, chaque groupe dispose de son propre stockage localement redondant (LRS) avec trois réplicas synchrones gérés par le service Stockage Azure. 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 connaître la durabilité du stockage LRS, consultez Résumé des options de redondance. Toutefois, en cas de défaillance d'une région, vous courez le risque d'un temps d'arrêt important et d'une éventuelle perte de données.

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 dans la section Mise à l'échelle d'un cluster existant dans le Portail Azure.

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

La récupération d’urgence (DR) consiste à récupérer après des évènements à fort impact, comme des catastrophes naturelles ou des échecs de déploiements, qui entraînent un temps d’arrêt et une perte 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 à réfléchir à la création de votre plan de récupération d’urgence, consultez Suggestions pour la conception d’une stratégie de récupération d’urgence.

En ce qui concerne la récupération d’urgence (DR), Microsoft utilise le modèle de responsabilité partagée. Dans un modèle de responsabilité partagée, Microsoft garantit que l’infrastructure de référence et les services de plateforme sont disponibles. En même temps, de nombreux services Azure ne répliquent pas automatiquement les données ou reviennent 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 en charge 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 conseils pour prendre en charge la récupération d’urgence et vous pouvez utiliser fonctionnalités spécifiques au service pour prendre en charge la récupération rapide pour vous aider à développer votre plan de récupération d’urgence.

Azure Cosmos DB for MongoDB vCore ne fournit pas de basculement automatique intégré ou de reprise après sinistre. La planification de la haute disponibilité est une étape essentielle à mesure que votre solution est mise à l’échelle.

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

Pour maximiser votre temps de fonctionnement, planifiez à l'avance la continuité de vos activités et préparez-vous à la reprise après sinistre avec Azure Cosmos DB for MongoDB vCore.

Bien que les services Azure soient conçus pour optimiser le temps d’activité, les pannes de service non planifiées peuvent se produire. Un plan de reprise après sinistre garantit que vous disposez d'une stratégie pour faire face aux interruptions de service régionales.

Azure Cosmos DB for MongoDB vCore 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 effectuées automatiquement en arrière-plan et stockées séparément des données sources dans un service de stockage. Ces sauvegardes automatiques sont utiles dans les scénarios où vous supprimez ou modifiez accidentellement des ressources et que vous avez besoin ultérieurement des versions d’origine.

Les sauvegardes automatiques sont conservées à différents intervalles selon que le cluster est actuellement actif ou récemment supprimé.

Période de rétention
clusters actifs 35 jours
clusters supprimés 7 jours

Concevoir pour la haute disponibilité

La haute disponibilité (HA) doit être activée pour les clusters critiques Azure Cosmos DB for MongoDB vCore qui exécutent des charges de travail de production. Dans un cluster à haute disponibilité, chaque partition sert de principal, ainsi qu’une partition de secours à chaud approvisionnée dans une autre zone de disponibilité. La réplication entre le nœud principal et la partition secondaire est synchrone par défaut. Toute modification apportée à la base de données est conservée sur les partitions principales et secondaires (de secours à chaud) avant la réception d’une réponse de la base de données.

Le service gère les vérifications d’intégrité et les pulsations sur chaque partition principale et secondaire du cluster. Si une partition principale devient indisponible en raison d’une panne régionale ou d’une zone, la partition secondaire est automatiquement promue pour devenir la nouvelle partition principale et une partition secondaire ultérieure est créée pour le nouveau principal. En outre, si une partition secondaire devient indisponible, le service crée automatiquement une nouvelle partition secondaire avec une copie complète des données du serveur principal.

Si le service déclenche un basculement du nœud principal vers la partition secondaire, les connexions sont routées en toute transparence sous les couvertures vers la nouvelle partition principale.

La réplication synchrone entre les partitions principales et secondaires ne garantit aucune perte de données en cas de basculement.

Étapes suivantes