Partager via

Bonnes pratiques de réplication interrégion et de même région dans Azure DocumentDB

Cet article traite de la récupération d’urgence inter-régions pour Azure DocumentDB. Il aborde également les capacités de lecture des clusters réplica dans la même, ou d’autres, région Azure, pour assurer la scalabilité des opérations de lecture.

La fonctionnalité de réplication vous permet de répliquer des données d’un cluster vers un cluster en lecture seule dans une autre ou la même région Azure. Les réplicas sont mis à jour avec la technologie de réplication asynchrone. Vous pouvez avoir un réplica de cluster dans une autre région de choix pour le cluster Azure DocumentDB principal. Dans un cas rare de panne de région, vous pouvez promouvoir le réplica de cluster dans une autre région pour devenir le nouveau cluster en lecture-écriture pour le fonctionnement continu de votre base de données MongoDB. Les applications peuvent continuer à utiliser les mêmes chaînes de connexion après que le réplica de cluster est promu dans une autre région comme nouveau cluster principal.

Les réplicas sont de nouveaux clusters que vous gérez comme des clusters ordinaires. Pour chaque réplica en lecture, vous êtes facturé en fonction de la capacité de calcul provisionnée dans les vCores et du stockage provisionné en Gio/mois. Les coûts de calcul et de stockage des clusters réplicas ont la même structure que les clusters standard et les prix de la région Azure où ils sont créés.

Reprise après sinistre avec des clusters répliques

La réplication inter-région constitue l’un des piliers importants de la stratégie de continuité d’activité et de reprise d’activité d’Azure (BCDR). Elle réplique de façon asynchrone ces applications et données dans d’autres régions Azure pour la protection de la récupération d’urgence. Tous les services Azure ne répliquent pas automatiquement les données. Tous ne se retirent pas non plus automatiquement d’une région défaillante pour effectuer une réplication croisée vers une autre région compatible. Azure DocumentDB offre une option permettant de créer un réplica de cluster dans une autre région, et d'avoir les données écrites sur le cluster principal répliquées automatiquement sur ce réplica. La secours au réplica du cluster s’il existe une panne dans la région primaire doit être lancée manuellement.

Lorsque la réplication interrégion est activée sur un cluster Azure DocumentDB, chaque partition est répliquée en continu dans une autre région. Cette réplication gère un réplica de données dans la région sélectionnée. Un tel réplica est prêt à être utilisé dans le cadre du plan de récupération d’urgence dans un cas rare de panne de la région primaire. La réplication est asynchrone. Les opérations d’écriture sur la partition du cluster principal n’attendent pas la réplication terminée vers la partition du réplica correspondant avant d’envoyer la confirmation d’une écriture réussie. La réplication asynchrone permet d’éviter des latences accrues pour les opérations d’écriture sur le cluster principal.

Opérations d’écriture et de lecture continues sur des réplicas de cluster et des chaînes de connexion

La chaîne de connexion globale en lecture-écriture dans Azure DocumentDB dirige de manière cohérente les écritures vers le cluster actif activé pour l'écriture. Lorsque vous lancez une promotion de cluster réplique, le cluster réplique dans la région B est basculé en mode écriture, tandis que le cluster principal dans la région A passe en lecture seule. Avant la promotion, la chaîne de connexion lecture-écriture globale cible le cluster principal de la Région A, puis se met à jour pour pointer vers la Région B, car elle endosse des responsabilités en lecture. Pour les applications utilisant la chaîne de connexion lecture-écriture globale, les opérations en écriture continuent de fonctionner de façon transparente via le processus de promotion, ce qui maintient un flux de données sans interruption.

Les clusters de réplicas sont également disponibles pour les lectures. Il permet de décharger des opérations de lecture intensives à partir du cluster principal ou de fournir une latence réduite pour les opérations de lecture aux clients situés plus près de la région de réplication. Lorsque la réplication interrégionale est activée, les applications peuvent utiliser la chaîne de connexion automatique de cluster de réplica pour effectuer des lectures à partir du réplica de cluster. Le cluster principal est disponible pour les opérations de lecture et d’écriture au moyen de sa propre chaîne de connexion automatique.

Capture d’écran des chaînes de connexion de cluster dans Azure DocumentDB, notamment la chaîne de connexion en lecture-écriture globale et la chaîne de connexion automatique.

Lorsque vous créez un réplica en activant la réplication interrégion ou la même région, il n’hérite pas des paramètres réseau tels que les règles de pare-feu du cluster principal. Ces paramètres doivent être configurés indépendamment pour le réplica. Le réplica hérite du compte Administrateur du cluster principal. Les comptes d’utilisateur doivent être gérés sur le cluster principal. Vous pouvez vous connecter au cluster principal et à son cluster réplica à l’aide des mêmes comptes d’utilisateur.

Promotion du cluster de réplica

Si une panne de région se produit, vous pouvez effectuer une opération de récupération d’urgence en favorisant votre réplica de cluster dans une autre région pour devenir disponible pour les écritures. Pendant l’opération de promotion du réplica, ces étapes se produisent :

  1. Les écritures sur le réplica dans la région B sont activées en plus des lectures. L’ancien réplica devient un nouveau cluster en lecture-écriture.
  2. Le cluster de réplica promu de la région B accepte les écritures en utilisant sa chaîne de connexion et la chaîne de connexion lecture-écriture globale.
  3. Le cluster de la région A est défini en lecture seule et conserve sa chaîne de connexion.

Important

Étant donné que la réplication est asynchrone, certaines données du cluster dans la région A peuvent ne pas être répliquées dans la région B lorsque le réplica de cluster dans la région B est promu. Si c’est le cas, la promotion entraînerait l'absence des données non répliquées sur les deux clusters.

Méthodes d’authentification sur les clusters répliqués

Les méthodes d’authentification sont gérées indépendamment sur les clusters principaux et réplicas. Les utilisateurs et d’autres principaux de sécurité, tels que les identités managées, sont toujours gérés sur le cluster principal et synchronisés avec le cluster réplica.

Si le cluster principal a une méthode d’authentification DocumentDB native désactivée au moment de la création du cluster de réplicas, l’activation de l’authentification DocumentDB native sur le réplica n’est pas autorisée. Pour activer l’authentification DocumentDB native sur un tel réplica, elle doit d’abord être promue.

Contenu connexe

  • Last updated on