Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de changer d’annuaire.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer d’annuaire.
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é.
Résilience des nœuds de calcul
Azure Cosmos DB gère en toute transparence tous les détails des nœuds de calcul individuels. 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 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. Pour plus d’informations sur le RTO et le RPO, consultez Qu’est-ce que la continuité d’activité, la haute disponibilité et la reprise d’activité ?.
Prise en charge des zones de disponibilité
Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.
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. Vous pouvez activer la redondance de zone dans les régions Azure qui prennent 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.
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.
Redondance de zone et comptes à région unique
Lorsque vous disposez d’un compte Cosmos DB mono-région, il est important d’être résilient aux problèmes liés à une zone de disponibilité. L’activation de la redondance de zone protège contre la perte de disponibilité totale en raison de l’échec d’une zone de disponibilité.
É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é.
Redondance de zone et 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é. Les comptes multirégions peuvent obtenir des contrats de niveau de service à haute disponibilité (SLA), et l’activation de la redondance de zone peut améliorer davantage les contrats SLA de disponibilité globaux que vous obtenez dans ces régions.
Pour les comptes multirégions, l’impact de la redondance de zone sur la disponibilité de votre base de données Cosmos DB pour NoSQL dépend du niveau de cohérence du compte et des régions où la redondance de zone est activée. Consultez le tableau ci-dessous pour estimer l’impact de l’utilisation de zones de disponibilité dans la configuration de votre compte multirégion :
| Niveau de cohérence du compte | Régions avec zones de disponibilité activées | Impact de l’utilisation de zones de disponibilité |
|---|---|---|
| Synchrone (fort) | Une région de lecture secondaire | Avantage élevé de la redondance de zone. 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. |
| Synchrone (fort) | Deux régions de lecture secondaires ou plus | Moins de valeur de redondance de zone. 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. |
| Asynchrone (obsolescence limitée ou plus faible) | Une ou plusieurs régions de lecture secondaires | Moins de valeur de redondance de zone. 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. |
| N'importe lequel | Toutes les régions d’écriture et n’importe quel nombre de régions secondaires | Avantage élevé de la redondance de zone. Assure une meilleure disponibilité des opérations d'écriture en cas d’échec d’une zone de disponibilité. |
Coût de l’activation de la redondance de zone
Les régions où la redondance de zone est activée sont facturées à un supplément de 25 %%. Toutefois, la tarification Premium pour les zones de disponibilité est supprimée pour les comptes configurés avec des écritures multirégions et/ou pour les regroupements configurés avec le mode de mise à l’échelle automatique.
L’ajout d’une région supplémentaire au compte Cosmos DB augmente généralement votre facture existante de 100% pour chaque région. Toutefois, il existe de petites variations des coûts entre les régions.
Si vous souhaitez en savoir plus, veuillez consulter la rubrique Tarification.
Améliorations du SLA
Pour augmenter la résilience et la disponibilité d’un compte Azure Cosmos DB, vous pouvez implémenter une approche de couche, notamment :
- Activation de la redondance de zone.
- Ajout d’une ou plusieurs régions supplémentaires.
- Activation des écritures multirégions.
L’approche de superposition protège le compte à chaque étape du processus, d’une disponibilité de 4 neuf pour une configuration à une seule région sans redondance de zone, jusqu’à 4,5 neuf pour une seule région avec redondance de zone, jusqu’à une disponibilité de 5 neuf pour une configuration multirégion avec l’option d’écriture multirégion activée.
Le tableau suivant contient un résumé des contrats 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é.
Configurer des 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 :
Activer la prise en charge des zones de disponibilité
Pour savoir comment activer la redondance de zone sur votre compte Azure Cosmos DB, consultez Migrer la prise en charge d’Azure Cosmos DB pour NoSQL vers la zone de disponibilité.
Reprise d’activité et continuité d’activité entre régions
La reprise après sinistre (DR) fait référence aux pratiques utilisées par les organisations pour se remettre d’événements à fort impact, tels que des catastrophes naturelles ou des déploiements échoués qui entraînent des temps d’arrêt et des pertes de données. Quelle que soit la cause, la meilleure solution pour une catastrophe est un plan de récupération d’urgence bien défini et testé et une conception d’application qui prend activement en charge la récupération d’urgence. Avant de commencer à créer votre plan de reprise après sinistre, consultez Recommandations pour la conception d'une stratégie de reprise après sinistre.
Pour la récupération d’urgence, Microsoft utilise le modèle de responsabilité partagée. Dans ce modèle, Microsoft garantit que l’infrastructure de base et les services de plateforme sont disponibles. Cependant, de nombreux services Azure ne répliquent pas automatiquement les données ou ne reviennent pas d’une région défaillante pour effectuer une réplication croisée vers une autre région activée. Pour ces services, vous êtes responsable de la configuration d’un plan de récupération d’urgence qui fonctionne pour votre charge de travail. La plupart des services qui s’exécutent sur des offres PaaS (Platform as a Service) Azure fournissent des fonctionnalités et des instructions pour la prise en charge de la récupération d’urgence. Vous pouvez utiliser des fonctionnalités spécifiques au service pour prendre en charge une récupération rapide afin de vous aider à développer votre plan de reprise après sinistre.
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é.
Durabilité
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 |
| Stabilité limitée | 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 la région d’écriture d’un compte multi-régions afin de préserver la continuité des activités au prix d’une perte de données, comme décrit précédemment 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.
Bonnes pratiques pour les écritures multirégionales
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.
| Paramétrage | Panne | Impact sur la disponibilité | Impact sur la durabilité | Ce que vous devez faire |
|---|---|---|---|---|
| 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. Une fois la panne terminée, réajustez les RUs provisionnées selon les besoins. |
| 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. Une fois la panne terminée, réajustez les RUs provisionnées selon les besoins. 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 de RUs provisionnées dans les régions restantes pour prendre en charge davantage de trafic. Une fois la panne terminée, vous pouvez réajuster les RUs provisionnées selon les besoins. 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 qui utilisent d'autres API, cette récupération automatique utilise la dernière écriture gagnante. |
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, il est possible de revenir en toute sécurité à la région récupérée en tant que région d’écriture à l’aide de [PowerShell, de l’interface de ligne de commande Azure ou du 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 | Ce que vous devez faire |
|---|---|---|---|
| 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. Une fois la panne terminée, réajustez les RUs provisionnées selon les besoins. |
| 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 de RUs provisionnées dans les régions restantes pour prendre en charge davantage de trafic. Une fois la panne terminée, vous pouvez réajuster les RUs provisionnées selon les besoins. 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.