Haute disponibilité (fiabilité) dans Azure Cosmos DB for NoSQL
Cet article décrit la prise en charge de la haute disponibilité (fiabilité) dans Azure Cosmos DB for NoSQL et couvre les zones de disponibilité ainsi que la récupération d’urgence inter-région et la continuité d’activité.
Prise en charge des zones de disponibilité
Les zones de disponibilité Azure sont au moins trois groupes physiquement distincts de centres de données dans chaque région Azure. Les centres de données de chaque zone sont équipés d’une infrastructure réseau, de refroidissement et d’alimentation indépendante. En cas de défaillance de zone locale, les zones de disponibilité sont conçues de telle sorte que si une zone est affectée, les services, la capacité et la haute disponibilité de la région sont pris en charge par les deux autres zones.
Les défaillances sont aussi bien des défaillances logicielles et matérielles que des événements de type tremblements de terre, inondations et incendies. La tolérance aux défaillances est obtenue par la redondance et l’isolation logique des services Azure. Pour obtenir des informations détaillées sur les zones de disponibilité dans Azure, consultez Régions et zones de disponibilité.
Les services Azure compatibles avec les zones de disponibilité sont conçus pour fournir le niveau approprié de fiabilité et de flexibilité. Ils peuvent être configurés de deux façons. Un service peut être redondant interzone, avec une réplication automatique entre les zones, ou zonal, avec des instances épinglées à une zone spécifique. Vous pouvez également combiner ces approches. Pour plus d’informations sur l’architecture zonale et redondante interzone, consultez Recommandations relatives à l’utilisation de zones de disponibilité et de régions.
Azure Cosmos DB est un service multilocataire qui gère de façon transparente tous les détails des différents nœuds de calcul. Vous n’avez pas à vous soucier des mises à jour correctives ou de la maintenance planifiée. Azure Cosmos DB garantit les contrats de niveau de service (SLA) pour la disponibilité et la latence P99 lors de toutes les opérations de maintenance automatique que le système effectue.
Azure Cosmos DB offre ce qui suit :
Résilience aux pannes de nœuds individuels. Azure Cosmos DB atténue automatiquement les pannes de réplicas en garantissant au moins trois réplicas de vos données dans chaque région Azure pour votre compte dans un quorum à quatre réplicas. Cette garantie induit un RTO de 0 et un RPO de 0 pour les pannes de nœud individuelles, sans nécessiter de modification ou de configuration d’application.
Résilience aux pannes de zones. Lorsque vous déployez un compte Azure Cosmos DB au moyen de zones de disponibilité, Azure Cosmos DB fournit un RTO de 0 et un RPO de 0, même en cas de panne d’une zone. Pour obtenir des informations sur le RTO, consultez Objectifs de récupération.
Une fois les zones de disponibilité activées, Azure Cosmos DB for NoSQL prend en charge une configuration redondante interzone.
Prérequis
Vos réplicas doivent être déployés dans une région Azure qui prend en charge les zones de disponibilité. Pour savoir si votre région prend en charge les zones de disponibilité, consultez la liste des régions prises en charge.
Déterminez si les zones de disponibilité apportent une valeur ajoutée suffisante à votre configuration actuelle dans Impact de l’utilisation de zones de disponibilité.
Impact de l’utilisation de zones de disponibilité
L’impact des zones de disponibilité sur la haute disponibilité de votre base de données Cosmos DB for NoSQL dépend du niveau de cohérence du compte et des régions dans lesquelles les zones de disponibilité sont activées. Dans de nombreux cas, les zones de disponibilité n’apportent aucune valeur ajoutée ou apportent une valeur ajoutée minimale si le compte prend en charge plusieurs régions (à moins qu’elles ne soient configurées avec une forte cohérence).
Consultez le tableau ci-dessous pour estimer l’impact de l’utilisation de zones de disponibilité sur la configuration de votre compte actuel :
| Niveau de cohérence du compte | Régions avec zones de disponibilité activées | Impact de l’utilisation de zones de disponibilité |
|---|---|---|
| Asynchrone (obsolescence limitée ou plus faible) | N’importe quel nombre de régions de lecture secondaires. | Apporte une valeur ajoutée minimale, car le Kit de développement logiciel (SDK) fournit déjà des redirections transparentes pour les lectures en cas de défaillance d’une région de lecture. |
| Synchrone (fort) | Deux régions de lecture secondaires ou plus | Apporte une valeur ajoutée marginale, car le système peut tirer profit du quorum dynamique si une région de lecture subit une perte de disponibilité, ce qui permet aux écritures de se poursuivre. |
| Synchrone (fort) | Une région de lecture secondaire | Apporte une plus forte valeur ajoutée, car la perte d’une région de lecture dans ce scénario peut impacter la disponibilité de l’écriture. |
| Tous | Régions d’écriture et n’importe quel nombre de régions secondaires | Garantit une meilleure disponibilité pour les opérations d’écriture en cas de défaillances zonales. |
| Tous | Région unique | Une seule région ne peut pas bénéficier de la capacité de basculement multirégion. L’utilisation de zones de disponibilité offre une protection contre la perte totale de disponibilité à la suite d’une défaillance zonale. |
Améliorations du SLA
Étant donné que les zones de disponibilité sont physiquement séparées et fournissent une source d’alimentation, un réseau et un refroidissement distincts, les Contrats de niveau de service (SLA) de disponibilité sont plus élevés (99,995 %) que ceux des comptes avec une seule région (99,99 %). Un supplément de 25 % est facturé pour les régions où les zones de disponibilité sont activées, mais aucun supplément n’est demandé pour les régions sans zones de disponibilité. Ce supplément ciblant les zones de disponibilité est également supprimé pour les comptes configurés avec des écritures multirégions et/ou les collections configurées avec le mode de mise à l’échelle automatique.
L’ajout d’une région supplémentaire au compte Cosmos DB augmente généralement la facture existante de 100 % (de manière additive et non multiplicative), bien qu’il existe de petites variations de coût entre les régions. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Tarification.
L’activation de zones de disponibilité, l’ajout de régions supplémentaires et l’activation d’écritures multirégions forment une approche en couches qui augmente la résilience et la disponibilité d’un compte Cosmos DB donné à chaque étape du processus : « quatre neufs » pour une seule région sans zone de disponibilité, « quatre neufs et demi » pour une seule région avec zones de disponibilité et jusqu’à « cinq neufs » pour une configuration multirégion avec l’option d’écriture multirégion activée. Reportez-vous au tableau suivant pour obtenir un résumé des SLA pour chaque configuration.
| Indicateur de performance clé | Écritures dans une région unique sans zones de disponibilité | Écritures dans une région unique avec zones de disponibilité | Écritures dans plusieurs régions et dans une région unique sans zone de disponibilité | Écritures dans plusieurs régions et dans une région unique avec des zones de disponibilité | Régions multiples, écritures dans plusieurs régions avec ou sans zones de disponibilité |
|---|---|---|---|---|---|
| Contrat SLA de disponibilité en écriture | 99,99 % | 99,995 % | 99,99 % | 99,995 % | 99, 999 % |
| Contrat SLA de disponibilité en lecture | 99,99 % | 99,995 % | 99, 999 % | 99, 999 % | 99, 999 % |
| Défaillances de zone : Perte de données | Perte de données | Aucune perte de données | Aucune perte de données | Aucune perte de données | Aucune perte de données |
| Défaillances de zone : Disponibilité | Perte de disponibilité | Aucune perte de disponibilité | Aucune perte de disponibilité | Aucune perte de disponibilité | Aucune perte de disponibilité |
| Panne régionale : Perte de données | Perte de données | Perte de données | Dépend du niveau de cohérence. Pour plus d’informations, consultez Compromis entre cohérence, disponibilité et performances. | Dépend du niveau de cohérence. Pour plus d’informations, consultez Compromis entre cohérence, disponibilité et performances. | Dépend du niveau de cohérence. Pour plus d’informations, consultez Compromis entre cohérence, disponibilité et performances. |
| Panne régionale : Disponibilité | Perte de disponibilité | Perte de disponibilité | Aucune perte de disponibilité pour échec dans la région de lecture, temporaire pour échec dans la région d’écriture | Aucune perte de disponibilité pour échec dans la région de lecture, temporaire pour échec dans la région d’écriture | Aucune perte de disponibilité de lecture, perte de disponibilité d’écriture temporaire dans la région affectée |
| Prix (1) | Non applicable | Unités de requête approvisionnées x taux de 1,25 | RU/s provisionnées x N régions | RU/s provisionnées x taux 1,25 x N régions (2) | Taux d’écriture à plusieurs régions x N régions |
1 Pour les comptes serverless, les RU sont multipliées par un facteur de 1,25.
2 Le taux de 1,25 s’applique uniquement aux régions pour lesquelles vous activez les zones de disponibilité.
Créer une ressource avec les zones de disponibilité activées
Vous pouvez uniquement configurer des zones de disponibilité lorsque vous ajoutez une nouvelle région à un compte Azure Cosmos DB for NoSQL.
Pour activer la prise en charge des zones de disponibilité, vous pouvez utiliser :
Migrer vers une prise en charge des zones de disponibilité
Pour savoir comment migrer votre compte Cosmos DB afin de prendre en charge les zones de disponibilité, consultez Migrer Azure Cosmos DB for NoSQL vers la prise en charge des zones de disponibilité.
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 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 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.
Les pannes régionales sont des pannes qui affectent tous les nœuds Azure Cosmos DB dans une région Azure, à travers toutes les zones de disponibilité. Pour de rares cas de pannes régionales, vous pouvez configurer Azure Cosmos DB pour prendre en charge différents résultats de durabilité et de disponibilité.
Disponibilité
Lorsqu'un compte Azure Cosmos DB est déployé dans une unique région, il n'y a généralement pas de perte de données. L’accès aux données est rétabli après la restauration des services Azure Cosmos DB dans la région affectée. La perte de données ne peut se produire qu’en cas de sinistre irrécupérable dans la région Azure Cosmos DB.
Pour vous aider à vous protéger contre toute perte totale de données résultant de catastrophes dans une région, Azure Cosmos DB propose deux modes de sauvegarde différents :
- Les sauvegardes continues sauvegardent chaque région toutes les 100 secondes. Elles vous permettent de restaurer vos données à n’importe quel point dans le temps avec une granularité de 1 seconde. Dans chaque région, la sauvegarde dépend des données validées dans cette région. Si des zones de disponibilité sont activées pour la région, la sauvegarde est stockée dans des comptes de stockage redondants interzone.
- Les sauvegardes périodiques sauvegardent entièrement toutes les partitions de tous les conteneurs sous votre compte, sans aucune synchronisation entre les partitions. L’intervalle minimum de sauvegarde est d’une heure.
Lorsqu’un compte Azure Cosmos DB est déployé 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, le RPO d’un compte Azure Cosmos DB déployé dans au moins deux régions.
| Niveau de cohérence | RPO pour une panne régionale |
|---|---|
| Session, préfixe cohérent et éventuel | Moins de 15 minutes |
| Bounded staleness (En fonction de l'obsolescence) | K et T |
| Remarque | 0 |
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.
Basculement géré par le service
Si votre solution nécessite une durée de bon fonctionnement continue pendant des pannes régionales, vous pouvez configurer Azure Cosmos DB pour répliquer vos données dans plusieurs régions et basculer de façon transparente vers des régions opérationnelles si nécessaire.
Les comptes à région unique peuvent perdre leur accessibilité après une panne régionale. Pour garantir la continuité d’activité à tout moment, nous vous recommandons de configurer votre compte Azure Cosmos DB avec une seule région d’écriture et au moins une deuxième région (de lecture) et d’activer le basculement géré par le service.
Le basculement géré par le service permet à Azure Cosmos DB de basculer vers la région d’écriture d’un compte multirégion afin de préserver la continuité d’activité au détriment d’une perte de données, comme décrit plus tôt dans la section Durabilité. Les basculements régionaux sont détectés et traités dans le client Azure Cosmos DB. Ils ne nécessitent aucune modification de l’application. Pour obtenir des instructions sur l’activation de plusieurs régions de lecture et le basculement managé par le service, consultez Gérer un compte Azure Cosmos DB en utilisant le portail Azure.
Important
Si vous avez choisi une configuration d’écriture dans une seule région avec plusieurs régions de lecture, nous vous recommandons vivement de configurer les comptes Azure Cosmos DB utilisés pour des charges de travail de production afin d’activer le basculement géré par le service. Cette configuration permet à Azure Cosmos DB de basculer les bases de données du compte vers des régions disponibles. En l’absence de cette configuration, le compte subit une perte de disponibilité en écriture pendant toute la durée de la panne régionale d’écriture. Le basculement manuel échoue en raison d’un manque de connectivité régionale.
Avertissement
Même si le basculement géré par le service est activé, une panne partielle peut nécessiter une intervention manuelle pour l’équipe de service Azure Cosmos DB. Dans ces scénarios, le basculement peut nécessiter jusqu’à 1 heure (ou plus) pour prendre effet. Pour une meilleure disponibilité en écriture pendant les pannes partielles, nous vous recommandons d’activer les zones de disponibilité en plus du basculement géré par le service.
Régions d’écriture multiples
Vous pouvez configurer Azure Cosmos DB pour accepter les écritures dans plusieurs régions. Cette configuration est utile pour 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. 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.
Important
La mise à jour fréquente du même ID de document (ou la recréation fréquente du même ID de document après la durée de vie ou la suppression) aura un effet sur les performances de réplication en raison d’un nombre accru de conflits générés dans le système.
Région de résolution des conflits
Lorsqu’un compte Azure Cosmos DB est configuré avec des écritures dans plusieurs régions, l’une des régions agit en tant qu’arbitre en cas de conflit d’écriture.
Meilleures pratiques pour les écritures multirégions
Voici quelques meilleures pratiques à prendre en compte lorsque vous écrivez dans plusieurs régions.
Conserver le trafic local
Lorsque vous utilisez des écritures à plusieurs régions, l’application doit transmettre du trafic en lecture et en écriture provenant de la région locale, strictement vers la région Cosmos DB locale. Pour des performances optimales, éviter les appels entre régions.
Il est important que l’application réduise les conflits en évitant les anti-modèles suivants :
Envoi de la même opération d’écriture vers toutes les régions pour augmenter les chances d’obtenir un temps de réponse rapide
Détermination aléatoire de la région cible pour une opération de lecture ou d’écriture en fonction de la requête
Utilisation d’une stratégie de tourniquet (round-robin) pour déterminer la région cible d’une opération de lecture ou d’écriture sur la base d’une requête.
Éviter la dépendance vis-à-vis du décalage de réplication
Vous ne pouvez pas configurer les comptes d’écriture à plusieurs régions pour une cohérence forte. La région en cours d’écriture répond immédiatement après la réplication des données localement par Azure Cosmos DB, tout en répliquant de façon globale les données de manière asynchrone.
Bien que ce soit rare, un décalage de réplication peut survenir sur une ou plusieurs partitions lorsque vous de la géo-répliquez les données. Un décalage de réplication peut survenir en raison de rares anomalies dans le trafic réseau ou d’un taux de résolution des conflits plus élevé que d’habitude.
Par exemple, une architecture dans laquelle l’application écrit dans la région A, mais lit à partir de la région B introduit une dépendance sur le décalage de réplication entre les deux régions. Toutefois, si l’application lit et écrit dans la même région, les performances restent constantes même en présence d’un décalage de réplication.
Évaluer l’utilisation de la cohérence de session pour les opérations d’écriture
Dans la Cohérence de session, le jeton de session est utilisé tant pour les opérations de lecture que d’écriture.
Pour les opérations de lecture, Azure Cosmos DB envoie le jeton de session mis en cache au serveur avec la garantie de recevoir des données correspondant au jeton de session spécifié (ou plus récent).
Pour les opérations d’écriture, Azure Cosmos DB envoie le jeton de session à la base de données avec une garantie de persistance des données uniquement si le serveur a intercepté le jeton de session fourni. Dans les comptes d’écriture à région unique, la région d’écriture est toujours garantie de rattraper le jeton de session. Toutefois, dans les comptes d’écriture à plusieurs régions, la région dans laquelle vous écrivez n’a peut-être pas intercepté les écritures émises dans une autre région. Si le client écrit dans la région A avec un jeton de session de la région B, la région A ne pourra pas conserver les données tant qu’elle n’aura pas intercepté les modifications apportées dans la région B.
Il est préférable d’utiliser des jetons de session uniquement pour les opérations de lecture, et non pour les opérations d’écriture, lorsque vous interchangez les jetons de session entre des instances clientes.
Atténuer les mises à jour rapides du même document
Les mises à jour du serveur pour résoudre ou confirmer l’absence de conflits peuvent entrer en conflit avec les écritures déclenchées par l’application lorsque le même document est mis à jour à plusieurs reprises. Les mises à jour répétées qui se succèdent rapidement dans le même document entraînent des latences plus élevées lors de la résolution des conflits.
Bien que des rafales ponctuelles de mises à jour répétées du même document soient inévitables, vous devez envisager d’explorer une architecture où de nouveaux documents sont plutôt créés si le trafic à l’état stable voit des mises à jour rapides du même document sur une période prolongée.
Pannes de lecture et d’écriture
Le client des comptes à région unique sera confronté à une perte de disponibilité en lecture et en écriture jusqu’à la restauration du service.
Les comptes à plusieurs régions rencontrent des comportements différents en fonction des configurations et des types de panne.
| Configuration | Outage | Impact sur la disponibilité | Impact sur la durabilité | Procédure à suivre |
|---|---|---|---|---|
| Région d’écriture unique | Panne dans une région de lecture | Tous les clients redirigent automatiquement les lectures vers d’autres régions. Il n’y a pas de perte de disponibilité en lecture ou en écriture pour toutes les configurations. L’exception est une configuration de deux régions avec une cohérence forte, perdant la disponibilité en écriture jusqu’à la restauration du service. Ou, si vous activez le basculement managé par le service, le service étiquette la région comme ayant échoué et un basculement se produit. | Pas de perte de données. | Pendant la panne, assurez-vous qu’il y a suffisamment d’unités de requête (RU) approvisionnées dans les régions restantes pour prendre en charge le trafic en lecture. Lorsque la panne est terminée, réajustez les unités de requête approvisionnées en conséquence. |
| Région d’écriture unique | Panne dans une région d’écriture | Les clients redirigent les lectures vers d’autres régions. Sans basculement managé par le service, les clients subissent une perte de disponibilité en écriture. La restauration de la disponibilité en écriture se produit automatiquement à la fin de la panne. Avec basculement managé par le service, les clients subissent une perte de disponibilité jusqu’à ce que le service manage un basculement vers une nouvelle région d’écriture que vous avez sélectionnée. |
Si vous ne sélectionnez pas le niveau de cohérence fort, le service risque de ne pas répliquer certaines données dans les régions actives restantes. Cette réplication repose sur le niveau de cohérence que vous sélectionnez. Si la région affectée subit une perte de données permanente, vous risquez de perdre des données non répliquées. | Pendant la panne, assurez-vous qu’il y a suffisamment d’unités de requête approvisionnées dans les régions restantes pour prendre en charge le trafic de lecture. N’effectuez pas de basculement manuel pendant la panne, car il ne va pas fonctionner. Lorsque la panne est terminée, réajustez les unités de requête approvisionnées en conséquence. Les comptes utilisant l’API pour NoSQL peuvent également récupérer les données non répliquées dans la région ayant échoué à partir de votre flux de conflit. |
| Régions d’écriture multiples | Toute panne régionale | Il existe un risque de perte temporaire de la disponibilité des écritures, lié à une seule région d’écriture avec basculement managé par le service. Le basculement de la région de résolution des conflits peut également entraîner une perte de la disponibilité des écritures si de nombreuses écritures conflictuelles se produisent au moment de la panne. | Les données récemment mises à jour dans la région défaillante peuvent être indisponibles dans les régions actives restantes, selon le niveau de cohérence sélectionné. Si la région affectée subit une perte de données permanente, vous risquez la perte des données non répliquées. | Pendant la panne, assurez-vous qu’il y a suffisamment d’unités de requête approvisionnées dans les régions restantes pour prendre en charge davantage de trafic. À la fin de la panne, vous pouvez réajuster les unités de requête approvisionnées en conséquence. Si possible, Azure Cosmos DB récupère automatiquement les données non répliquées dans la région ayant échoué. Cette récupération automatique se sert de la méthode de résolution des conflits que vous configurez pour les comptes utilisant l’API pour NoSQL. Pour les comptes utilisant les autres API, cette récupération automatique utilise La dernière écriture gagne. |
Informations supplémentaires sur les pannes de région de lecture
La région affectée est déconnectée et marquée comme étant hors connexion. Les Kits de développement logiciel (SDK) Azure Cosmos DB redirigent les appels de lecture vers la région disponible suivante dans la liste des régions préférées.
Si aucune région de la liste des régions préférées n'est disponible, les appels sont automatiquement acheminés vers la zone d’écriture active.
Aucune modification n’est nécessaire dans le code de votre application pour gérer les pannes de la région de lecture. Lorsque la région de lecture affectée est de nouveau en ligne, elle se synchronise avec la région d’écriture active et est à nouveau disponible pour le traitement des requêtes de lecture après sa complète récupération.
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.
Même dans un cas rare et malheureux où une région d’écriture Azure est définitivement irrécupérable, il n’y a aucune perte de données si votre compte Azure Cosmos DB à plusieurs régions est configuré avec une cohérence forte. Un compte Azure Cosmos DB à plusieurs régions dispose des caractéristiques de durabilité spécifiées précédemment dans la section Durabilité .
Informations supplémentaires sur les pannes de région d’écriture
En cas de panne régionale d’écriture, le compte Azure Cosmos DB promeut une région secondaire comme nouvelle région d’écriture principale lorsque le basculement managé par le service est configuré dans le compte Azure Cosmos DB. Le basculement intervient vers une autre région selon l’ordre de priorité des régions que vous avez spécifié.
Le basculement manuel ne doit pas être déclenché et il va échouer en cas de panne de la région source ou de destination. La raison étant que la procédure de basculement inclut une vérification de cohérence qui nécessite une connectivité entre les régions.
Lorsque la région précédemment affectée est de nouveau en ligne, toutes les données d'écriture qui n'étaient pas dupliquées lors de son l’échec sont mises à disposition au moyen d’un flux de conflits. 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.
Une fois la région d’écriture précédemment affectée récupérée, elle s’affiche en tant que « en ligne » dans le portail Azure et devient disponible en tant que région de lecture. À ce stade, vous pouvez revenir à la région récupérée comme région d’écriture en utilisant [PowerShell, l’interface CLI Azure ou le Portail Azure](/azure/cosmos-db/how-to-manage-database-account#perform-manual-failover-on-an-azure-cosmos-db-account). Aucune perte de données ou de disponibilité ne survient avant, pendant ou après le changement de région d'écriture. Votre application continue d’être hautement disponible.
Avertissement
En cas de panne d’une région d’écriture, où le compte Azure Cosmos DB promeut une région secondaire comme nouvelle région d’écriture principale via le basculement géré par le service, la région d’écriture d’origine ne sera pas promue automatiquement en tant que région d’écriture une fois qu’elle est récupérée. Il vous incombe de revenir à la région récupérée en tant que région d’écriture à l’aide de PowerShell, d’Azure CLI ou du portail Azure (une fois sécurisé, comme décrit ci-dessus).
Détection, notification et gestion des pannes
Pour les comptes à région unique, les clients sont confrontés à une perte de disponibilité en lecture et en écriture lors d’une panne régionale Azure Cosmos DB. Les comptes à plusieurs régions connaissent des comportements différents, tels que décrits dans le tableau suivant.
| Régions d’écriture | Basculement managé par le service | À quoi s’attendre | Procédure à suivre |
|---|---|---|---|
| Région d’écriture unique | Non activé | En cas de panne dans une région de lecture lorsque vous n’utilisez pas la cohérence forte, tous les clients redirigent vers d’autres régions. Il n’y a aucune perte de disponibilité en lecture ou en écriture et aucune perte de données. Lorsque vous utilisez une cohérence forte, une panne dans une région de lecture peut affecter la disponibilité en écriture si moins de deux régions de lecture restent actives. En cas de panne dans la région d’écriture, les clients rencontrent une perte de disponibilité en écriture. Si vous ne sélectionnez pas la cohérence forte, le service peut ne pas répliquer certaines données dans les régions actives restantes. Cette réplication repose sur le niveau de cohérence sélectionné. Si la région affectée subit une perte de données permanente, vous risquez la perte des données non répliquées. Azure Cosmos DB restaure la disponibilité en écriture à la fin de la panne. |
Pendant la panne, assurez-vous qu’il y a suffisamment d’unités de requête approvisionnées dans les régions restantes pour prendre en charge le trafic de lecture. N’effectuez pas de basculement manuel pendant la panne, car il ne va pas fonctionner. Lorsque la panne est terminée, réajustez les unités de requête approvisionnées en conséquence. |
| Région d’écriture unique | activé | En cas de panne dans une région de lecture lorsque vous n’utilisez pas la cohérence forte, tous les clients redirigent vers d’autres régions. Il n’y a aucune perte de disponibilité en lecture ou en écriture et aucune perte de données. Lorsque vous utilisez une cohérence forte, la panne d’une région de lecture peut affecter la disponibilité en écriture si moins de deux régions de lecture restent actives. En cas de panne dans la région d’écriture, les clients subissent une perte de disponibilité en écriture jusqu’à ce qu’Azure Cosmos DB choisisse une nouvelle région comme nouvelle région d’écriture selon vos préférences. Si vous ne sélectionnez pas la cohérence forte, le service peut ne pas répliquer certaines données dans les régions actives restantes. Cette réplication repose sur le niveau de cohérence sélectionné. Si la région affectée subit une perte de données permanente, vous risquez la perte des données non répliquées. |
Pendant la panne, assurez-vous qu’il y a suffisamment d’unités de requête approvisionnées dans les régions restantes pour prendre en charge le trafic de lecture. N’effectuez pas de basculement manuel pendant la panne, car il ne va pas fonctionner. À la fin de la panne, vous pouvez replacer la région d’écriture dans la région d’origine et réajuster les RU approvisionnées en conséquence. Les comptes utilisant l’API pour NoSQL peuvent aussi récupérer les données non répliquées dans la région ayant échoué à partir de votre flux de conflit. |
| Régions d’écriture multiples | Non applicable | Les données récemment mises à jour dans la région défaillante peuvent ne pas être disponibles dans les régions actives restantes. Les niveaux de cohérence de session, la garantie de préfixe et l’éventuelle garantissent une obsolescence inférieure à 15 minutes. L’obsolescence limitée garantit moins de K mises à jour ou T secondes, selon la configuration. Si la région affectée subit une perte de données permanente, vous risquez la perte des données non répliquées. | Pendant la panne, assurez-vous qu’il y a suffisamment d’unités de requête approvisionnées dans les régions restantes pour prendre en charge davantage de trafic. À la fin de la panne, vous pouvez réajuster les unités de requête approvisionnées en conséquence. Si possible, Azure Cosmos DB récupère les données non répliquées dans la région indisponible. Cette récupération se sert de la méthode de résolution des conflits que vous configurez pour les comptes utilisant l’API pour NoSQL. Pour les comptes utilisant d’autres API, cette récupération se sert de la méthode Dernière écriture prioritaire. |
Test de haute disponibilité
Même si votre compte Azure Cosmos DB est hautement disponible, votre application n’est peut-être pas correctement conçue pour rester 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 le basculement manuel au moyen de PowerShell, d’Azure CLI ou du Portail Azure, puis analyser votre application. Une fois le test achevé, vous pouvez basculer vers la région primaire et restaurer le basculement managé par le service pour le compte.
Important
N’appelez pas de basculement manuel lors d’une panne Azure Cosmos DB sur la région source ou de destination. Le basculement manuel nécessite une connectivité régionale, pour garder la cohérence des données, et va ainsi échouer.