Fiabilité dans Azure Cosmos DB

Azure Cosmos DB pour NoSQL est un service de base de données multimodèle distribué à l’échelle mondiale qui prend en charge les modèles de données de documents avec des schémas flexibles. Azure Cosmos DB offre des fonctionnalités de fiabilité complètes, notamment plusieurs niveaux de cohérence qui vous permettent d’équilibrer les performances et la disponibilité, les déploiements redondants interzone qui protègent contre les défaillances de zone de disponibilité, la réplication multirégion avec basculement géré par le service ou géré par le client, ainsi que les options de sauvegarde continue et périodique pour la protection des 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 Cosmos DB résilient à 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 comment utiliser des sauvegardes pour récupérer à partir d’autres types de problèmes et met en évidence des informations clés sur le contrat de niveau de service (SLA) Azure Cosmos DB.

Recommandations concernant le déploiement de production

Azure Well-Architected Framework fournit des recommandations sur la fiabilité, la sécurité, le coût, les opérations et les performances. Pour comprendre comment ces domaines influencent les uns les autres et contribuent à une solution de Azure Cosmos DB fiable, consultez les meilleures pratiques Architecture pour Azure Cosmos DB.

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 compte Azure Cosmos DB account. Chaque compte peut avoir plusieurs bases de données avec plusieurs conteneurs. Les conteneurs servent d’unités logiques de distribution et d’extensibilité. Vous pouvez créer des conteneurs tels que des collections, des tables et des graphiques, en fonction de l’API que vous utilisez pour interagir avec Azure Cosmos DB. Pour plus d’informations sur le modèle de ressource, consultez Databases, conteneurs et éléments dans Azure Cosmos DB. Chaque conteneur utilise le partitionnement, qui prend en charge une mise à l’échelle élevée et des performances élevées.

Vous configurez le débit, qui représente la quantité de ressources système que vous pouvez utiliser pour interroger et utiliser vos données. Vous pouvez provisionner manuellement le débit, utiliser la mise à l’échelle automatique pour ajuster dynamiquement la capacité en fonction des besoins de votre charge de travail ou utiliser le type de compte serverless pour votre utilisation réelle.

Un compte unique peut s'étendre sur plusieurs régions Azure, ce qui augmente votre résilience aux pannes de région. Vous pouvez configurer plusieurs régions pour la lecture et, si vous utilisez le niveau Critique pour l’entreprise, vous pouvez utiliser plusieurs régions pour l’écriture. Azure Cosmos DB géoréplique automatiquement vos données. Le comportement de géoréplication est affecté par la configuration que vous utilisez, par exemple le niveau de cohérence, qui indique comment vous souhaitez faire des compromis entre la cohérence des données, la disponibilité, la latence et le débit. Différents niveaux de cohérence optimisent les différentes préoccupations, prennent en charge différentes garanties et fournissent différents types de réplication inter-régions.

Architecture physique

Azure Cosmos DB stocke plusieurs replicas de vos données pour la redondance. Le service réduit automatiquement les pannes de réplica en maintenant le quorum parmi les réplicas dans chaque région. Cette approche garantit une haute disponibilité et protège contre la perte de données pendant les défaillances de nœud individuelles, sans nécessiter de modifications ou de configuration d’application.

En interne, Azure Cosmos DB gère vos données via différentes constructions, notamment des partitions physiques, partition sets et replica sets. Pour plus d’informations sur le fonctionnement d'Azure Cosmos DB, consultez Distribution de données globale avec Azure Cosmos DB - sous le capot.

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.

Nous vous recommandons d’utiliser les sdk Azure Cosmos DB. Les kits SDK implémentent automatiquement la prise en charge d’une gamme de considérations de résilience, notamment la gestion temporaire des pannes par le biais de nouvelles tentatives automatiques et l’respect des réponses de limite de débit envoyées par le service. Pour plus d'informations, voir Concevoir des applications résilientes avec les SDK Azure Cosmos DB.

Lors de l’utilisation d’un compte multirégion, le SDK prend également en charge une stratégie de disponibilité basée sur un seuil, également appelée hedging, où elle envoie des demandes de lecture parallèles à plusieurs régions et accepte la réponse la plus rapide. Cette approche peut améliorer les performances des applications lorsqu’une région subit temporairement une latence plus élevée que d’habitude.

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.

Azure Cosmos DB prend en charge la redondance de zone. Lorsque vous activez la redondance de zone, Azure distribue les réplicas de vos données dans plusieurs zones de disponibilité, ce qui permet une résilience aux problèmes et pannes du centre de données. Microsoft sélectionne les zones de disponibilité à utiliser.

Un compte Azure Cosmos DB peut utiliser plusieurs régions (emplacements) pour la distribution globale, la mise à l’échelle et le basculement. Vous configurez la redondance de zone séparément pour chaque région de votre compte.

L’utilisation de la redondance de zone dans Azure Cosmos DB n’a aucun impact visible sur les performances ou la latence. Elle ne nécessite aucun ajustement du mode de cohérence sélectionné et ne nécessite aucune modification du code d’application.

Nous vous recommandons d’utiliser la redondance de zone dans les régions où elle est prise en charge, en particulier pour les comptes à région unique. Étant donné que les zones de disponibilité sont physiquement distinctes et fournissent une source d’alimentation, un réseau et un refroidissement distincts, les contrats SLA de disponibilité pour Azure Cosmos DB sont plus élevés pour les comptes redondants interzone que les comptes qui n’utilisent pas de zones de disponibilité.

Si vous n’activez pas la redondance de zone, le compte n’est pas zonal dans cette région. Les comptes nonzonaux peuvent localiser des réplicas dans une seule zone de disponibilité, ce qui entraîne un temps d’arrêt potentiel si cette zone spécifique rencontre un problème.

Requirements

• Region support : Vous pouvez activer la redondance de zones dans les régions Azure qui prennent en charge les zones de disponibilité. Pour voir si votre région prend en charge les zones de disponibilité, consultez la liste des régions prises en charge.

  La redondance de zone n’est pas un paramètre à l’échelle du compte. Azure Cosmos DB comptes peuvent s’étendre sur plusieurs régions, et chaque région peut être configurée indépendamment pour utiliser des zones de disponibilité. Les régions qui ne prennent pas en charge les zones de disponibilité ne vous empêchent pas d’activer la redondance de zone dans d’autres régions du même compte.

• Comptes serverless : Vous ne pouvez configurer des comptes serverless redondants interzone que lorsque vous les créez. Vous ne pouvez pas convertir les comptes serverless existants sans zones de disponibilité en configuration de zone de disponibilité. Pour les charges de travail stratégiques, nous vous recommandons d’utiliser le débit approvisionné.

Considérations

• Pannes simultanées de zones multiples : Un compte à région unique avec redondance de zone peut maintenir sa disponibilité en lecture et écriture lorsqu’une panne affecte une seule zone de disponibilité. Toutefois, si la panne affecte plusieurs zones de disponibilité ou la région entière, les comptes à région unique perdent l’accès en lecture et en écriture jusqu’à ce que le service soit restauré. Considérez de déployer un compte multirégion si vous devez garantir la résilience à la panne simultanée de plusieurs zones.

• Comptes multirégions : Si vous disposez d’un compte multirégion, vous pouvez éventuellement activer la redondance de zone sur l’une ou l’autre des régions de compte qui prennent en charge les zones de disponibilité. Nous vous recommandons vivement d’activer la redondance de zone lorsque votre compte est configuré pour utiliser une seule région ou s’il est configuré pour utiliser une seule région d’écriture avec plusieurs régions de lecture.

Coûts

Les régions où la redondance de zone est activée sont facturées à un niveau premium. Toutefois, la tarification Premium pour les zones de disponibilité est supprimée pour les comptes configurés avec des écritures multirégions et pour les collections configurées pour utiliser le mode de débit autoscale. Pour plus d’informations, consultez Azure Cosmos DB tarification.

Configurez la prise en charge des zones de disponibilité

Pour la plupart des comptes, vous activez la redondance de zone uniquement lorsque vous ajoutez une nouvelle région à un compte Azure Cosmos DB. Pour activer la prise en charge des zones de disponibilité sur un compte existant, ajoutez une région et activez la redondance de zone dessus. Vous pouvez suivre un processus pour ajouter une région temporaire afin de pouvoir configurer la redondance de zone dans votre région d’origine. Pour obtenir des instructions détaillées, consultez Activer la redondance de zone sur un compte Azure Cosmos DB.

Pour les comptes serverless, vous devez activer la redondance de zone lorsque vous créez le compte.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qu’il faut attendre lorsque vous configurez un compte Azure Cosmos DB pour la redondance de zone et que toutes les zones sont opérationnelles.

• Opération interzone : Azure Cosmos DB achemine automatiquement les requêtes vers des réplicas entre les zones de disponibilité, afin que n’importe quel réplica puisse traiter une requête.

• Réplication des données interzones : Lorsqu’un client apporte une modification à toutes les données, cette modification est appliquée à plusieurs réplicas dans différentes zones pour atteindre le quorum. Cette approche est appelée réplication synchrone. La réplication synchrone garantit un niveau élevé de cohérence des données, ce qui réduit la probabilité de perte de données lors d’une défaillance de zone. Les zones de disponibilité se trouvent relativement proches, ce qui signifie qu’il existe un effet minimal sur la latence ou le débit.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu'il faut attendre lorsque vous configurez un compte Azure Cosmos DB pour la redondance de zone, et qu'il existe une panne dans l'une des zones.

• Detection et response : La plateforme Azure Cosmos DB est chargée de détecter une défaillance 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 Resource Health pour surveiller l’intégrité d’une ressource individuelle et configurer des alertes Resource Health pour vous avertir des problèmes. Vous pouvez également 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.

• Active requests : Lorsqu’une zone de disponibilité devient indisponible, Azure Cosmos DB met fin à toutes les demandes en cours connectées aux réplicas dans la zone affectée, et l’application doit réessayer ces demandes. Assurez-vous que votre application est préparée en suivant les instructions de gestion des erreurs temporaires.

• Perte de données attendue : Il n’y a aucune perte de données attendue à partir d’une défaillance de zone.

• Temps d’arrêt attendu : Pendant les pannes de zone, les connexions peuvent rencontrer de brèves interruptions qui durent généralement quelques secondes au fur et à mesure que le trafic est redistribué. Assurez-vous que vos applications sont préparées en suivant l’Guide de gestion des erreurs temporaires.

• Redistribution : Azure Cosmos DB redirige automatiquement les requêtes entrantes vers des réplicas sains dans d’autres zones de disponibilité. Lorsqu’une zone de disponibilité a une panne, la plateforme réalloue automatiquement le débit approvisionné vers d’autres répliques.

Récupération de la zone

Lorsque la zone de disponibilité se rétablit, Azure Cosmos DB restaure automatiquement les réplicas dans la zone de disponibilité et redirige le trafic entre eux de manière normale.

Tester les pannes de zone

Le basculement et la récupération des zones de disponibilité pour Azure Cosmos DB sont entièrement gérés par Microsoft. Vous n’avez pas besoin de lancer ou de valider les processus liés aux défaillances des zones de disponibilité.

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

Lorsque vous déployez un compte Azure Cosmos DB dans une seule région, une panne à l'échelle de la région qui affecte tous les nœuds Azure Cosmos DB n'entraîne généralement pas de perte de données, mais elle empêche votre application d'accéder aux données. Azure Cosmos DB restaure l’accès aux données après la récupération du service dans la région affectée. La perte de données se produit uniquement si la région subit un sinistre irrécupérable.

Pour vous préparer aux rares cas de pannes de région, vous pouvez configurer Azure Cosmos DB pour prendre en charge différents niveaux de durabilité et de disponibilité à l’aide de l’une des approches suivantes :

• Plusieurs régions de lecture avec une seule région d’écriture. Vous pouvez éventuellement activer le basculement géré par le service ou le basculement automatique par partition (PPAF).
• Plusieurs régions d’écriture.

Le tableau suivant récapitule les options de récupération disponibles en fonction de la configuration du compte et du type de panne. Les sections ultérieures de cet article fournissent des détails détaillés sur ces options et le comportement associé.

Kits de développement logiciel (SDK) et résilience

Les kits de développement logiciel (SDK) Azure Cosmos DB constituent une partie importante de la stratégie de résilience de votre application. Lorsque vous disposez d’un compte multirégion, la configuration du Kit de développement logiciel (SDK) affecte la façon dont les requêtes sont routées entre les régions, y compris les régions préférées auxquelles se connecter et les régions qui doivent être exclues. Les kits SDK surveillent la disponibilité des régions et des partitions, et peuvent se reconfigurer dynamiquement pour utiliser des régions et des partitions saines, comme par le biais du disjoncteur au niveau de la partition.

Pour plus d’informations sur la prise en charge de la haute disponibilité par le SDK, consultez la documentation sur la haute disponibilité pour le Kit de développement logiciel (SDK) que vous utilisez :

• Azure Cosmos DB .NET SDK v3
• Azure Cosmos DB Java SDK v4
• Kit de développement logiciel Python Azure Cosmos DB

Perte de données potentielle pendant les pannes de région

Lorsque vous déployez un compte Azure Cosmos DB dans plusieurs régions, la durabilité des données dépend du niveau de cohérence que vous configurez sur le compte. Le tableau suivant détaille, pour tous les niveaux de cohérence, l'objectif de point de récupération (RPO) d'un compte Azure Cosmos DB déployé dans au moins deux régions. Le RPO représente la perte de données potentielle pendant une panne de région.

K = le nombre de versions (c’est-à-dire de mises à jour) d’un élément.

T = l’intervalle de temps depuis la dernière mise à jour.

Pour les comptes à plusieurs régions, la valeur minimale de K et T est de 100 000 opérations d’écriture ou 300 secondes. Cette valeur fixe le RPO minimal des données lorsque vous utilisez l’obsolescence limitée.

Pour plus d’informations sur les différences entre les niveaux de cohérence, voir Niveaux de cohérence dans Azure Cosmos DB.

Plusieurs régions de lecture avec une seule région d’écriture

Si votre solution nécessite une durée de fonctionnement continue pendant les pannes de région, vous pouvez configurer Azure Cosmos DB pour répliquer vos données dans plusieurs régions, avec des écritures gérées par votre région primaire. Vous pouvez éventuellement configurer vos applications pour vous connecter à des régions de lecture spécifiques, ce qui peut vous aider à améliorer leurs performances. Si une région a une panne, le compte peut continuer à fonctionner à partir de régions saines.

Basculement entre les régions

Vous pouvez configurer le Kit de développement logiciel (SDK) Azure Cosmos DB avec une liste hiérarchisée de régions de lecture. Le Kit de développement logiciel (SDK) connecte votre application à la première région disponible dans la liste. Lors d’une panne de région de lecture, le SDK détecte la panne de la région par le biais de codes de réponse back-end, le marque comme étant indisponible et achemine les opérations futures vers la région disponible suivante dans la liste des préférences. Vérifiez que la liste des régions préférées est correctement définie et s’aligne sur les exigences de votre entreprise et de la latence. Pour obtenir des instructions détaillées, consultez Résoudre les problèmes de disponibilité du Kit de développement logiciel (SDK) Azure Cosmos DB.

Le basculement est le processus consistant à rendre l’une des régions de votre compte indisponible, complètement ou en partie. L’effet d’un basculement varie selon que la région est une région d’écriture ou une région de lecture :

• Si une région d’écriture devient indisponible, une autre région devient la région d’écriture.
• Si une région de lecture devient indisponible, cette région ne peut pas traiter les demandes de lecture et d’autres régions sont utilisées pour les opérations de lecture à la place.

Azure Cosmos DB fournit plusieurs types de basculement :

• Per-partition automatic failover (PPAF) : en interne, Azure Cosmos DB répartit vos données sur plusieurs partitions physiques. Si un problème se produit avec l’infrastructure prenant en charge une partition, d’autres partitions peuvent ne pas être affectées. PPAF permet aux comptes à région d'écriture unique de basculer automatiquement des partitions individuelles vers une région secondaire tout en maintenant les partitions saines dans la région primaire. PPAF peut contribuer à réduire les temps d’arrêt et à accélérer la récupération lors d’une défaillance partielle de la région. Pour plus d’informations, consultez Comment intégrer et adopter le basculement automatique par partition (PPAF) pour Azure Cosmos DB.

  Note

  Le basculement automatique par partition est en préversion publique. Cette fonctionnalité est fournie sans contrat de niveau de service. Pour plus d’informations, consultez Conditions d'utilisation supplémentaires pour les versions préliminaires de Microsoft Azure.

• Basculement forcé : Vous pouvez mettre hors connexion l’une des régions de votre compte. Il s’agit également d’un basculement géré par le client ou d'une opération de mise hors ligne de la région. Il s’agit de l’approche recommandée pour restaurer rapidement la disponibilité pendant une panne. Vous êtes responsable de la détection de la panne et du déclenchement du basculement. Vous pouvez également utiliser des basculements forcés pour simuler des scénarios de panne régionale à des fins de test, comme lors d’un exercice de récupération après sinistre.

  Si vous placez la région d’écriture hors connexion, la région de lecture avec la priorité la plus élevée suivante devient la nouvelle région d’écriture. Si vous prenez une région de lecture hors connexion, vos applications peuvent se connecter à n’importe quelle autre région de lecture dans le compte.

  Un basculement forcé de votre région d’écriture entraîne la possibilité de perte de données pour toutes les écritures non répliquées.

  Après un basculement forcé, Microsoft doit remettre la région en ligne. Pour les régions saines, ce processus est automatisé, mais peut prendre jusqu’à plusieurs jours. Si la région ne revient pas en ligne dans un délai de un ou deux jours, ouvrez un ticket de support pour obtenir de l'assistance.

• Modifier la région d’écriture : Lorsque les régions sont saines, vous pouvez modifier la région d’écriture de votre compte. Cette modification est effectivement un basculement planifié de la région d’écriture pour votre compte.

  La modification de la région d’écriture n’entraîne aucune perte de données, car la réplication des données rattrape son retard avant que la nouvelle région d’écriture ne soit promue. Il peut y avoir une brève interruption, mais les clients qui utilisent la logique de nouvelle tentative et d’autres techniques de gestion des erreurs temporaires n’ont généralement pas d’impact significatif.

  Cette opération nécessite que les régions soient saines, de sorte qu’elles ne peuvent pas être utilisées lors d’une panne de région.

• basculement géré par le service : Lorsque votre compte utilise un basculement géré par le service, Microsoft est responsable de décider quand effectuer le basculement entre les régions. Pour activer le basculement géré par le service, vous spécifiez des priorités pour chaque région. Toutefois, le processus de déclaration d’une panne et du déclenchement d’un basculement géré par le service peut prendre beaucoup de temps , potentiellement une heure ou plus. Pour une récupération plus rapide, effectuez un basculement forcé au lieu d'attendre le déclenchement d'un basculement géré par le système.

  Si Microsoft déclenche un basculement géré par le service pour la région d'écriture associée au compte, les écritures non répliquées risquent d'être perdues.

  Après un basculement géré par le service, Microsoft doit faire revenir une région en ligne. Microsoft apporte automatiquement la région en ligne, mais ce processus peut prendre plusieurs jours.

Requirements

Region support : Vous pouvez configurer n’importe quelle région Azure en tant que région de lecture pour votre compte Azure Cosmos DB.

Coûts

L’ajout d’une région de lecture supplémentaire à un compte Azure Cosmos DB augmente vos coûts existants pour chaque région. Pour plus d’informations, consultez Azure Cosmos DB tarification.

Configurer plusieurs régions de lecture

• Ajoutez des régions de lecture à un compte : Vous pouvez configurer plusieurs régions sur votre compte lorsque vous créez le compte ou à tout moment après la création du compte. Pour plus d’informations, consultez Ajouter/supprimer des régions de votre compte de base de données.

• Activer le basculement : Certains types de basculement doivent être préconfigurés au préalable :

  • Basculement automatique par partition : pour plus d’informations, consultez Comment intégrer et adopter le basculement automatique par partition (PPAF) pour Azure Cosmos DB.

  • Basculement géré par le service : Tout d’abord, activez le basculement géré par le service. Ensuite, définissez les priorités de tolérance de panne pour chaque région de votre compte.

Planification de capacité et gestion

Si votre application répartit les requêtes entre les régions et qu’une région est hors connexion, les régions restantes rencontrent un volume de demandes plus élevé. Utilisez le débit de mise à l’échelle automatique pour ajuster dynamiquement la capacité en fonction de la demande. Si vous utilisez un débit approvisionné, planifiez la capacité adéquate pour gérer la perte d’une région sans dégradation du service et envisagez le surapprovisionnement. Pour plus d’informations, consultez Gérer la capacité avec le surapprovisionnement.

Comportement lorsque toutes les régions sont saines

Cette section décrit ce que vous devez attendre lorsque vous configurez un compte Azure Cosmos DB avec plusieurs régions de lecture, et toutes les régions sont opérationnelles.

• Opération interrégion : Votre application configure la région qui doit recevoir des opérations de lecture. Vous pouvez configurer votre application avec une liste hiérarchisée de régions ou pour exclure certaines régions. Pour plus d’informations sur le fonctionnement de la sélection de la région, consultez Diagnose et résoudre les problèmes de disponibilité des sdk Azure Cosmos DB dans des environnements multirégions.

  Toutes les opérations d’écriture sont dirigées vers la région d’écriture de votre compte.

• Réplication des données interrégions : Toutes les opérations d’écriture se produisent dans la région primaire de votre compte. Les opérations d'écriture sont répliquées dans les autres régions de lecture selon le niveau de cohérence configuré du compte. Pour plus d’informations sur le décalage de réplication maximal, consultez Perte de données potentielle pendant les pannes de région.

Comportement lors d’un échec de région de lecture

Cette section décrit ce que vous devez attendre lorsque vous configurez un compte Azure Cosmos DB avec plusieurs régions de lecture, et qu'il existe une panne dans l'une des régions de lecture du compte.

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

  • PPAF : PPAF ne s’applique généralement pas aux pannes de région de lecture. Toutefois, pour les comptes avec une cohérence forte et seulement deux régions, la perte de la région de lecture réduit le compte à une seule région, ce qui ne peut pas maintenir le quorum dynamique. Dans ce scénario, PPAF peut activer pour préserver la disponibilité en déplaçant les partitions affectées vers la région saine.

  • Basculement forcé : Vous êtes responsable de l’exécution d’un basculement forcé. Pour des étapes détaillées, consultez Effectuer le basculement forcé pour votre compte d'Azure Cosmos DB.

    Si vous n’effectuez pas de basculement, le comportement de votre compte dépend de son niveau de cohérence :

    • Cohérence forte : une cohérence forte nécessite deux régions ou plus pour maintenir le quorum dynamique. S'il y a moins de deux régions disponibles et que vous n'effectuez pas de basculement, le compte perd sa capacité d'écriture jusqu'à la restauration du service.

    • Cohérence de l’obsolescence limitée : La cohérence de l’obsolescence limitée repose sur le maintien d’un seuil d’obsolescence spécifique entre les régions. Si la durée de la panne de la région dépasse le seuil, le système ne peut pas maintenir la cohérence entre les opérations d'écriture. Si vous n’effectuez pas de basculement, le compte perd la capacité d'écriture jusqu’à la restauration du service.

  • Basculement géré par le service : Si le basculement géré par le service est activé, Microsoft détecte finalement la panne et lance un basculement de votre compte. Toutefois, ce processus peut prendre beaucoup de temps, potentiellement une heure ou plus. Pour une récupération plus rapide, effectuez un basculement forcé au lieu d’attendre le déclenchement d’un basculement géré par le service.

• Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une région est en panne. Toutefois:

  • Vous pouvez utiliser Azure Resource Health pour surveiller l’intégrité d’une ressource individuelle et configurer des alertes Resource Health pour vous avertir des problèmes.

  • 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 peuvent être arrêtées et doivent être retentées par le client une fois le basculement terminé. Si vos clients gèrent les erreurs temporaires de manière appropriée en réessayant après une courte période de temps, ils évitent généralement un impact significatif.

• Perte de données attendue : Une panne dans une région de lecture n’entraîne pas de perte de données. Azure Cosmos DB continue à respecter les garanties de cohérence de lecture.

• Temps d’arrêt attendu : Le temps d’arrêt de votre compte dépend du type de basculement utilisé par votre compte.

  • PPAF : Lorsque PPAF est activé, le système détecte et récupère automatiquement à partir de l’échec, généralement dans les 3 minutes, sans intervention manuelle.

  • Basculement forcé : Le temps d’arrêt dépend de ce qui suit :

    • Combien de temps vous faut-il pour détecter la panne et initier un basculement ?

    • Combien de temps dure le basculement, généralement quelques secondes.

      Avertissement

      N’effectuez aucune opération de configuration (plan de contrôle) sur la région affectée pendant les scénarios de panne, car elles entraînent une incohérence de compte et retardent la récupération. Voici quelques exemples d’opérations du plan de contrôle à éviter :

      • Modifier la région d’écriture ou modifier la priorité de basculement
      • Mettre à jour le compte en configuration multi-écriture
      • Mise à jour des niveaux de cohérence ou d’autres paramètres de compte
      • Mise à jour des configurations de point de terminaison privé ou des paramètres réseau
      • Mise à jour du débit du compte ou des opérations de mise à l’échelle
      • Toute autre opération qui modifie la configuration du compte ou les paramètres de région

  • Service-managed failover : Microsoft est responsable du lancement du basculement géré par le service, et le temps d'indisponibilité que votre compte rencontre est basé sur le temps nécessaire à Microsoft pour déclarer la panne et lancer le basculement. Dans certaines situations, cela peut prendre une heure ou plus. Si votre compte subit une interruption des écritures et que vous devez restaurer rapidement la disponibilité des écritures, effectuez un basculement forcé.

• Redistribution: Pour le basculement forcé ou le basculement géré par le service, la région affectée est déconnectée et marquée comme hors connexion.

  Aucune modification n’est nécessaire dans le code de votre application pour gérer les pannes de la région de lecture. Les sdk Azure Cosmos DB redirigent les opérations de lecture vers la région disponible suivante dans la liste des régions préférées. Si aucune des régions de la liste des régions préférées n’est disponible, les opérations de lecture reviennent automatiquement à la région d’écriture actuelle du compte telle qu’elle est configurée dans le service.

  Note

  Si vous utilisez des points de terminaison privés avec un compte Azure Cosmos DB, vérifiez que le DNS privé est correctement roué après l’opération de région hors connexion. Pour obtenir des instructions détaillées, consultez les "Considérations relatives au basculement pour les points de terminaison privés".

Comportement lors d’un échec de région d’écriture

Cette section décrit ce que vous devez attendre lorsque vous configurez un compte Azure Cosmos DB avec plusieurs régions de lecture et qu'il existe une panne dans la région d'écriture du compte.

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

  • PPAF : Microsoft détecte automatiquement la panne et lance un basculement de certaines partitions, le cas échéant. Votre application n’a pas besoin d’effectuer d’action.

  • Basculement forcé : Vous êtes responsable de l’exécution d’un basculement forcé. Pour obtenir des instructions détaillées, consultez Effectuer le basculement forcé pour votre compte Azure Cosmos DB.

    Si vous n’effectuez pas de basculement, le compte perd sa capacité d'écriture jusqu’à la restauration du service.

    S’il y a une panne de la région d'écriture de votre compte, évitez d’effectuer une opération de changement de région d'écriture. Les modifications apportées à la région d’écriture ne réussissent pas en cas de panne de la région source ou de destination. La raison est que la procédure de modification de la région inclut un contrôle de cohérence qui nécessite une connectivité entre les régions.

  • Basculement géré par le service : Microsoft détecte automatiquement la panne et lance un basculement de votre compte. Votre application n’a pas besoin d’effectuer d’action.

• Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une région est en panne. Toutefois:

  • Vous pouvez utiliser Azure Resource Health pour surveiller l’intégrité d’une ressource individuelle et configurer des alertes Resource Health pour vous avertir des problèmes.

  • 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 peuvent être arrêtées et doivent être retentées par le client une fois le basculement terminé. Si vos clients gèrent les erreurs temporaires de manière appropriée en réessayant après une courte période de temps, ils évitent généralement un impact significatif.

• Perte de données attendue : Si vous configurez votre compte avec une cohérence forte, aucune perte de données ne se produit. Sinon, toutes les écritures non répliquées risquent d'être perdues une fois le basculement terminé. Pour plus d’informations sur la perte de données maximale attendue lors d’une panne de région, consultez Perte de données potentielle pendant les pannes de région.

• Temps d’arrêt attendu : Le temps d’arrêt de votre compte dépend du type de basculement utilisé par votre compte.

  • PPAF : Lorsque PPAF est activé, attendez-vous à une brève interruption, qui est généralement d’environ 3 minutes.

  • Basculement forcé : La durée de l'indisponibilité dépend des facteurs suivants :

    • Combien de temps il vous faut pour découvrir la panne et initier un basculement.
    • Combien de temps dure le basculement, généralement quelques secondes.

  Avertissement

  N’effectuez aucune opération de plan de contrôle sur la région affectée pendant les scénarios de panne, car elles entraînent des incohérences de compte et retardent la récupération. Voici quelques exemples d’opérations du plan de contrôle à éviter :

  • Modifier la région d’écriture ou modifier la priorité de basculement
  • Mettre à jour le compte en configuration multi-écriture
  • Mise à jour des niveaux de cohérence ou d’autres paramètres de compte
  • Mise à jour des configurations de point de terminaison privé ou des paramètres réseau
  • Mise à jour du débit du compte ou des opérations de mise à l’échelle
  • Toute autre opération qui modifie la configuration du compte ou les paramètres de région
  • Service-managed failover : Microsoft est responsable du lancement du basculement géré par le service, et le temps d’arrêt que votre compte rencontre est basé sur le temps nécessaire à Microsoft pour déclarer la panne et lancer le basculement. Dans certaines situations, cela peut prendre une heure ou plus. Pour restaurer rapidement la disponibilité de l’écriture, effectuez un basculement forcé.

• Redistribution: La redistribution du trafic d’écriture dépend du type de basculement utilisé par votre compte.

  • PPAF : Azure Cosmos DB bascule automatiquement la partition non saine vers une région saine.

  • Basculement forcé : Lorsque vous effectuez un basculement forcé, la région d’écriture de votre compte passe à la région que vous spécifiez.

  Note

  Si vous utilisez des points de terminaison privés avec un compte Azure Cosmos DB, vérifiez que le DNS privé est correctement roué après l’opération de région hors connexion. Pour obtenir des instructions détaillées, consultez les "Considérations relatives au basculement pour les points de terminaison privés".

  • Basculement géré par le service : Azure Cosmos DB promeut automatiquement l'une des régions secondaires du compte comme nouvelle région d'écriture principale. Le basculement intervient vers une autre région selon l’ordre de priorité des régions que vous avez spécifié.

Récupération de région

Microsoft doit remettre en service une région. Lorsqu’une région récupère après une panne, Microsoft met automatiquement la région en ligne. Toutefois, ce processus peut prendre plusieurs jours.

Une fois la région en ligne, les actions que vous effectuez sont différentes selon que la panne était dans une région de lecture ou une région d’écriture.

• Après les pannes de région de lecture : Lorsque la région affectée est de nouveau en ligne, elle se synchronise avec la région d’écriture actuelle et est à nouveau disponible pour traiter les demandes de lecture une fois qu’elle a complètement rattrapé. Les lectures suivantes sont redirigées vers la région récupérée sans modification nécessaire de votre code d’application. Tant pendant le basculement que la réintégration d’une région ayant précédemment échoué, Azure Cosmos DB continue à respecter les garanties de cohérence de lecture.

• Après des interruptions de la région d'écriture : Lorsque la région affectée est de nouveau en ligne, elle apparaît comme « en ligne » dans le portail Azure et devient disponible en tant que région de lecture. À ce stade, il est sûr de rétablir la région d’écriture vers la région récupérée.

  Important

  La région récupérée ne sera pas promue en tant que région d’écriture automatiquement une fois qu’elle est récupérée. Il est de votre responsabilité de revenir à la région récupérée en tant que région d’écriture, une fois qu’il est sûr de le faire.

  Il n’y a aucune perte de données ou de disponibilité avant, pendant ou après avoir modifié la région d’écriture. Votre application continue d’être hautement disponible.

  Si aucune écriture n’a été répliquée avant la mise hors connexion de la région, vous pouvez lire les écritures non répliquées à partir du flux de conflit. Votre application peut lire le flux de conflit, résoudre les conflits en fonction de la logique spécifique à l’application et réécrire les données mises à jour dans le conteneur selon les besoins.

Tester les défaillances régionales

Votre application peut ne pas correctement gérer les basculements de région, même si votre compte Azure Cosmos DB est hautement disponible. Pour tester la haute disponibilité de bout en bout de votre application, dans le cadre de procédures de récupération d’urgence (DR) ou de test de votre application, désactivez temporairement le basculement managé par le service pour votre compte. Appelez basculement forcé à l’aide de PowerShell, du Azure CLI ou du portail Azure, puis surveillez votre application. Une fois que vous avez terminé le test, vous pouvez basculer vers la région primaire une fois que la région revient automatiquement en ligne, puis restaurer le basculement géré par le service pour le compte. Si la région ne revient pas en ligne dans un jour ou deux, ouvrez un cas de support pour demander de l’aide.

Si votre compte utilise PPAF, vous pouvez simuler un basculement de partition. Pour plus d’informations, consultez Tester la configuration PPAF (simulation d’erreur).

Régions d’écriture multiples

Vous pouvez configurer Azure Cosmos DB pour accepter les écritures dans plusieurs régions. Cette configuration peut fournir une résilience très élevée aux pannes de région. Il est également utile de réduire la latence d’écriture dans les applications distribuées géographiquement.

Lorsque vous configures un compte Azure Cosmos DB pour plusieurs régions d’écriture, une cohérence forte n’est pas prise en charge et des conflits d’écriture peuvent survenir. La région hub agit comme un arbitre dans les conflits d’écriture. Pour plus d’informations sur la résolution desdits conflits, voir Types de conflits et stratégies de résolution lors de l’utilisation de plusieurs régions d’écriture.

Il est important de prendre en compte la conception de votre application et son fonctionnement avec plusieurs régions d’écriture. Passez en revue les meilleures pratiques pour les écritures multi-régions.

Requirements

Region support : Vous pouvez configurer n’importe quelle région Azure en tant que région de lecture ou d’écriture pour votre compte Azure Cosmos DB.

Coûts

L’ajout d’une région d’écriture supplémentaire à un compte Azure Cosmos DB augmente vos coûts existants pour chaque région. Pour plus d’informations, consultez Azure Cosmos DB tarification.

Configurer plusieurs régions d’écriture

Vous pouvez configurer plusieurs régions d’écriture sur votre compte lorsque vous créez le compte ou à tout moment après la création du compte. Pour plus d’informations, consultez Configurer plusieurs régions d’écriture.

Pour utiliser efficacement plusieurs régions d’écriture, votre application doit également être configurée de manière appropriée. Consultez Configurer les écritures multirégions dans les applications qui utilisent Azure Cosmos DB.

Planification de capacité et gestion

Si votre application répartit les requêtes entre les régions et qu’une région est hors connexion, les régions restantes rencontrent un volume de demandes plus élevé. Utilisez le débit en mise à l’échelle automatique pour adapter dynamiquement la capacité en fonction de la demande. Si vous utilisez un débit approvisionné, planifiez la capacité adéquate pour gérer la perte d’une région sans dégradation du service et envisagez le surapprovisionnement. Pour plus d’informations, consultez Gérer la capacité avec le surapprovisionnement.

Comportement lorsque toutes les régions sont saines

Cette section décrit ce que vous devez attendre lorsque vous configurez un compte Azure Cosmos DB avec plusieurs régions d’écriture, et toutes les régions sont opérationnelles.

• Opération interrégion : Lorsqu’un compte est configuré avec plusieurs régions d’écriture, votre application configure la région qui doit être utilisée pour les opérations de lecture et d’écriture. Vous pouvez configurer votre application avec une liste hiérarchisée de régions ou pour exclure certaines régions. Pour plus d’informations sur le fonctionnement de la sélection de la région, consultez Diagnose et résoudre les problèmes de disponibilité des sdk Azure Cosmos DB dans des environnements multirégions. Pour savoir comment configurer votre application, consultez Configurer les écritures multirégions dans les applications qui utilisent Azure Cosmos DB.

• Réplication des données interrégions : Les données sont répliquées de manière asynchrone entre les régions. Le décalage de réplication dépend du niveau de cohérence du compte. Vous ne pouvez pas utiliser une cohérence forte pour les opérations d'écriture multirégion. Pour plus d’informations, consultez Perte de données potentielle pendant les pannes de région.

  Lorsqu’un compte est configuré pour plusieurs régions d’écriture, les applications dans différentes régions peuvent apporter des modifications qui entrent en conflit entre elles. Azure Cosmos DB fournit des fonctionnalités de résolution des conflits. Pour plus d’informations, consultez les stratégies de résolution et de types de conflit lors de l’utilisation de plusieurs régions d’écriture. Pour en savoir plus sur la configuration de votre propre stratégie de résolution des conflits, consultez Stratégies de résolution des conflits de gestion dans Azure Cosmos DB.

  Note

  La mise à jour fréquente du même ID de document ou la recréation du même ID de document fréquemment après l’expiration de sa durée de vie ou sa suppression affecte négativement les performances de réplication en raison d’un nombre accru de conflits générés dans le système.

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

Cette section décrit ce qu'il faut attendre lorsque vous configurez un compte Azure Cosmos DB avec plusieurs régions d'écriture, et qu'il existe une panne dans l'une des régions de lecture ou d'écriture du compte.

• Détection et réponse : Votre application détecte la perte de la région. Azure Cosmos DB SDKs fournissent des fonctionnalités de sélection automatique de régions qui routent les opérations de lecture et d’écriture vers des régions disponibles.

• Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une région est en panne. Toutefois:

  • Vous pouvez utiliser Azure Resource Health pour surveiller l’intégrité d’une ressource individuelle et configurer des alertes Resource Health pour vous avertir des problèmes.

  • 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 peuvent être arrêtées et doivent être retentées par le client une fois le basculement terminé. Si vos clients gèrent les erreurs temporaires de manière appropriée en réessayant après une courte période de temps, ils évitent généralement un impact significatif.

• Perte de données attendue : Les données récemment mises à jour peuvent devenir indisponibles dans d’autres régions. Pour plus d’informations sur la perte de données maximale attendue lors d’une panne de région, consultez Perte de données potentielle pendant les pannes de région. Dans le cas peu probable où la région affectée subit une perte de données permanente, vous risquez de perdre des données non répliquées.

• Temps d’arrêt attendu : Il n’existe aucun temps d’arrêt attendu dans les configurations multi-écritures, à condition que les kits SDK soient correctement configurés avec ApplicationRegions ou PreferredRegions.

  Conseil

  Pour obtenir de meilleurs résultats, les applications distribuées à l’échelle mondiale doivent être précédées d'un service d’équilibrage de charge global, tels qu'Azure Front Door ou Azure Traffic Manager. Ces services peuvent détecter la dégradation régionale et acheminer automatiquement le trafic vers des instances d’application dans une région saine.

• Redistribution : Les kits sdk Azure Cosmos DB détectent automatiquement que la région n’est pas saine et redirige les opérations de lecture et d’écriture vers la région disponible suivante dans la liste des régions préférées. Aucune modification n’est requise dans votre code d’application.

  Conseil

  Si votre application est mise en avant par Azure Front Door ou Traffic Manager, ces services détectent également la dégradation régionale et routent le trafic vers une région fonctionnelle.

Récupération de région

Lorsque la région affectée est de retour en ligne, la région s’affiche en tant que « en ligne » dans le portail Azure et devient à nouveau disponible.

Toutes les données d’écriture qui n’ont pas été répliquées lorsque la région a échoué sont rendues disponibles via le flux de conflit. Les applications peuvent lire le flux de conflits, résoudre les conflits selon la logique propre à l’application, et réécrire les données mises à jour dans le conteneur Azure Cosmos DB le cas échéant.

Tester les défaillances régionales

Pour tester des scénarios de basculement d'écriture multirégion, vous pouvez désactiver une région d'écriture à l'aide d'un basculement forcé. Ce processus simule une panne de région et vous pouvez observer la façon dont votre application répond.

Sauvegarde et restauration

Pour la plupart des solutions, vous ne devez pas vous appuyer exclusivement sur les sauvegardes. Utilisez plutôt les autres fonctionnalités décrites dans ce guide pour prendre en charge vos exigences de résilience. Toutefois, les sauvegardes protègent contre certains risques que d’autres approches ne le font pas. Pour plus d’informations, consultez Que sont la redondance, la réplication et la sauvegarde ?.

La perte de données peut se produire en raison de suppressions accidentelles ou d’autres problèmes dans votre application qui provoquent une altération des données. Lorsque vous utilisez un compte à une seule région, la perte de données peut également se produire en raison d’un sinistre irrécupérable dans la région Azure Cosmos DB. Pour vous protéger contre la perte de données, Azure Cosmos DB fournit un ensemble de fonctionnalités de sauvegarde et de restauration. Vous pouvez configurer les sauvegardes et la rétention en fonction de vos besoins en matière de récupération et de coût. Pour plus d’informations, consultez Sauvegarde en ligne et restauration de données à la demande dans Azure Cosmos DB.

Résilience à la maintenance du service

Azure Cosmos DB gère en toute transparence tous les détails des nœuds de calcul individuels et effectue automatiquement des correctifs et d’autres types de maintenance planifiée. Les contrats SLA Azure Cosmos DB pour la disponibilité et la latence s’appliquent à toutes les opérations de maintenance automatique effectuées par le système.

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.

Azure Cosmos DB fournit des contrats SLA pour une gamme de configurations et de caractéristiques de service, notamment la disponibilité, la latence, le débit et la cohérence.

Les contrats SLA de disponibilité diffèrent selon que vous utilisez l’une des fonctionnalités de produit suivantes :

• Capacité de traitement provisionnée
• Compte à région unique avec prise en charge de la zone de disponibilité (redondance de zone)
• Comptes qui utilisent plusieurs régions de lecture
• Comptes qui utilisent plusieurs régions d’écriture (niveau Critique pour l’entreprise)

Contenu connexe

• Fiabilité d'Azure
• vue d’ensemble Azure Cosmos DB
• Niveaux de cohérence dans Azure Cosmos DB
• Distribution mondiale de données avec Azure Cosmos DB
• Diagnose et résoudre les problèmes de disponibilité des sdk Azure Cosmos DB dans des environnements multirégions