Configurer une géoréplication passive pour des instances Azure Cache pour Redis Premium

Dans cet article, vous découvrez comment configurer une géoréplication passive sur une paire d’instances Azure Cache pour Redis à l’aide du portail Azure.

Une géoréplication passive relie deux instances Azure Cache pour Redis de niveau Premium afin de créer une relation de réplication des données active-passive. Active-passive signifie qu’il existe une paire de caches, principal et secondaire, dont les données sont synchronisées. Mais vous pouvez écrire uniquement sur un côté de la paire, à savoir le cache principal. L’autre côté de la paire, le cache secondaire, est en lecture seule.

Si vous comparez une relation active-passive à une relation active-active, cette dernière vous permet d’écrire d’un côté ou de l’autre de la paire, les deux côtés étant synchronisés.

Avec une géoréplication passive, les instances de cache se trouvent généralement dans des régions Azure différentes, même si cela n’est pas nécessaire. Une instance joue le rôle d’instance principale et l’autre d’instance secondaire. L’instance principale gère les demandes de lecture et d’écriture et propage les modifications à l’instance secondaire.

Le basculement n’est pas automatique. Pour plus d’informations sur l’utilisation du basculement, consultez Lancer un basculement du cache géo-principal vers le cache géo-secondaire.

Notes

La géoréplication passive a été conçue comme une solution de récupération d’urgence.

Étendue de la disponibilité

Niveau	De base, Standard	Premium	Enterprise, Enterprise Flash
Disponible	Non	Oui	Oui

La géoréplication passive est uniquement disponible dans le niveau Premium d’Azure Cache pour Redis. Les niveaux Entreprise et Enterprise Flash proposent également la géoréplication, mais ils utilisent une version plus avancée appelée géoréplication active.

Conditions préalables à la géoréplication

Pour configurer la géoréplication entre deux caches, les conditions préalables suivantes doivent être remplies :

• Les deux caches sont de niveau Premium.
• Les deux caches figurent dans le même abonnement Azure.
• La taille du cache lié secondaire est supérieure ou égale à celle du cache lié principal. Pour utiliser un géo-basculement, les deux caches doivent avoir la même taille.
• Les deux caches sont créés et en cours d'exécution.
• Les deux caches exécutent la même version du serveur Redis.

Notes

Le transfert de données entre régions Azure est facturé aux tarifs de bande passante standard.

Certaines fonctionnalités ne sont pas prises en charge par la géoréplication :

• La redondance de zone n’est pas prise en charge avec la géoréplication.
• La persistance n'est pas prise en charge par la géoréplication.
• Les caches avec plusieurs réplicas ne peuvent pas être géorépliqués.
• Le clustering est pris en charge s'il est activé pour les deux caches et si ceux-ci possèdent le même nombre de partitions.
• Les caches dans le même réseau virtuel (VNet) sont pris en charge.
• Les caches situés dans des réseaux virtuels différents sont pris en charge avec des mises en garde. Pour plus d’informations, consultez Puis-je utiliser la géoréplication avec mes caches dans un réseau virtuel ?

Une fois la géoréplication configurée, les restrictions suivantes s’appliquent à votre paire de caches liés :

• Le cache lié secondaire est en lecture seule. Vous pouvez y lire des données, mais vous ne pouvez pas y écrire de données. Si vous choisissez de lire à partir de l’instance géographique secondaire, à chaque fois qu’une synchronisation complète des données se produit entre les instances principale et secondaire, l’instance géographique secondaire lève des erreurs sur toute opération Redis, jusqu’à la fin de la synchronisation complète des données. Les erreurs indiquent qu’une synchronisation complète des données est en cours. En outre, les erreurs sont levées lorsque l’instance géographique principale ou secondaire est mise à jour et dans certains scénarios de redémarrage. Les applications qui lisent depuis une instance géographique secondaire doivent être générées pour revenir à l’instance géographique principale chaque fois que l’instance géographique secondaire génère de telles erreurs.

• Toutes les données présentes dans le cache lié secondaire avant l’ajout du lien sont supprimées. Toutefois, en cas de suppression ultérieure de la géoréplication, les données répliquées restent dans le cache lié secondaire.

• Vous ne pouvez pas procéder à la mise à l'échelle d'un seul des deux caches lorsque ceux-ci sont liés.

• Vous ne pouvez pas modifier le nombre de partitions si le clustering est activé pour le cache.

• Vous ne pouvez activer la persistance sur aucun des caches.

• Vous pouvez exporter à partir de l'un ou l'autre des caches.

• Vous ne pouvez pas importer dans le cache lié secondaire.

• Vous ne pouvez pas supprimer les caches liés ou le groupe de ressources qui les contient tant qu'ils n'ont pas été dissociés. Pour plus d’informations, consultez Pourquoi ma tentative de suppression de mon cache lié a-t-elle échoué ?

• Si les caches se trouvent dans des régions différentes, des frais de sortie de réseau s'appliquent aux données déplacées d'une région à l'autre. Pour plus d’informations, consultez Combien coûte la réplication de mes données entre des régions Azure ?

• Le basculement n’est pas automatique. Vous devez démarrer le basculement depuis le cache lié principal vers le cache lié secondaire. Pour plus d’informations sur l’utilisation du basculement, consultez Lancer un basculement du cache géo-principal vers le cache géo-secondaire.

• Des liaisons privées peuvent pas être ajoutés aux caches déjà géorépliqués. Pour ajouter une liaison privée à un cache géorépliqué : 1. Dissociez la géoréplication. 2. Ajoutez une liaison privée. 3. Enfin, rétablissez la liaison de la géoréplication.

Ajouter un lien de géoréplication

1. Pour relier deux caches à des fins de géoréplication, sélectionnez d’abord Géoréplication dans le menu Ressource du cache que vous souhaitez utiliser comme cache lié principal. Ensuite, sélectionnez Ajouter une liaison de réplication de cache à partir du volet de travail.

   

2. Dans la liste Caches compatibles, cliquez sur le nom du cache secondaire souhaité. Si le cache secondaire ne figure pas dans la liste, vérifiez que les conditions préalables à la géoréplication du cache secondaire sont remplies. Pour filtrer les caches par région, sélectionnez la région dans la carte afin de n’afficher que les caches figurant dans la liste Caches compatibles.

   

   Vous pouvez également lancer le processus de liaison ou afficher des détails sur le cache secondaire à l'aide du menu contextuel.

   

3. Sélectionnez Lier pour lier les deux caches et commencer le processus de réplication.

   

4. Vous pouvez voir la progression du processus de réplication en utilisant Géoréplication dans le menu Ressource.

   

   Vous pouvez également voir l’état de la liaison en utilisant la Vue d’ensemble du menu Ressource pour les caches principal et secondaire.

   

   Une fois le processus de réplication terminé, l’État d’approvisionnement du lien devient Réussi.

   

   Le cache lié principal reste disponible pour une utilisation pendant le processus de liaison. Le cache lié secondaire n'est pas disponible tant que le processus de liaison n'est pas terminé.

URL d’instance géographique principale

Une fois les caches liés, une URL est générée pour chaque cache qui pointe toujours vers le cache géo-principal. Si un basculement est lancé à partir du cache géo-principal vers le cache géo-secondaire, l’URL reste la même et l’enregistrement DNS sous-jacent est automatiquement mis à jour pour pointer vers le nouveau cache géo-principal.

Trois URL sont présentées :

• L’URL géo-principale est une URL proxy au format <cachename>.geo.redis.cache.windows.net. L’URL pointe toujours vers le cache de la paire de géoréplication qui est l’instance géographique principale actuelle.
• Le cache géo-principal actuel correspond à l’adresse directe du cache qui est actuellement le cache géo-principal. Cette adresse est redis.cache.windows.net, et non geo.redis.cache.windows.net. L’adresse listée dans ce champ change si un basculement est lancé.
• Le cache géo-secondaire actuel correspond à l’adresse directe du cache qui est actuellement le cache géo-secondaire. Cette adresse est redis.cache.windows.net, et non geo.redis.cache.windows.net. L’adresse listée dans ce champ change si un basculement est lancé.

Lancer un basculement du cache géo-principal vers le cache géo-secondaire

En un seul clic, vous pouvez déclencher un basculement de l’instance géo principale vers l’instance géo secondaire.

Les étapes suivantes sont alors effectuées :

1. Le cache géo-secondaire est promu cache géo-principal.
2. Les enregistrements DNS sont mis à jour pour rediriger les URL géo-principales vers le nouveau cache géo-principal.
3. L’ancien cache géo-principal est rétrogradé en cache secondaire, puis tente de former un lien vers le nouveau cache géo-principal.

Le processus de géo-basculement prend quelques minutes.

Paramètres à vérifier avant de lancer le géo-basculement

Quand le basculement est lancé, le cache géoprincipal et le cache géosecondaire permutent. Si le cache géo-principal est configuré différemment du cache géo-secondaire, cela peut créer des problèmes pour votre application.

Veillez donc à vérifier les points suivants :

• Si vous utilisez un pare-feu dans l’un ou l’autre des caches, veillez à ce que les paramètres de ce pare-feu soient similaires afin d’éviter tout problème de connexion.
• Vérifiez que les deux caches utilisent le même port et les mêmes paramètres TLS/SSL.
• Les caches géo-principal et géo-secondaire ont des clés d’accès différentes. Si un basculement est déclenché, veillez à ce que votre application puisse mettre à jour la clé d’accès qu’elle utilise pour correspondre à la nouvelle instance géo principale. Vous pouvez également utiliser des jetons Microsoft Entra pour l’authentification du cache, ce qui vous permet d’utiliser les mêmes informations d’identification d’authentification pour le cache géo-principal et le cache géo-secondaire.

Basculement avec perte de données minimale

Les événements de géo-basculement peuvent introduire des incohérences des données pendant la transition, notamment si le client maintient une connexion à l’ancien cache géo-principal pendant le processus de basculement. Il est possible de réduire la perte de données lors d’un événement de géo-basculement planifié en suivant ces conseils :

• Vérifiez la métrique du décalage de la synchronisation des données de géoréplication. Cette métrique est émise par le cache géo-principal actuel. Elle indique la quantité de données restant à répliquer sur le cache géo-principal. Dans la mesure du possible, lancez le basculement uniquement si la métrique indique qu’il reste moins de 14 octets à écrire.
• Exécutez la commande CLIENT PAUSE dans le cache géo-principal actuel avant de lancer le basculement. L’exécution de CLIENT PAUSE bloque toutes les nouvelles requêtes d’écriture et retourne les échecs au terme du délai d’expiration au client Azure Cache pour Redis. La commande CLIENT PAUSE nécessite de fournir un délai d’expiration en millisecondes. Veillez à indiquer un délai d’expiration suffisamment long pour permettre au basculement de se produire. Définir la valeur de pause à environ 30 minutes (1 800 000 millisecondes) est un bon point de départ. Vous pouvez toujours réduire ce nombre selon vos besoins.

Il n’est pas nécessaire d’exécuter la commande CLIENT UNPAUSE, car le nouveau cache géo-principal conserve CLIENT PAUSE.

Remarque

L’utilisation de l’authentification basée sur Microsoft Entra ID pour votre cache est recommandée dans des scénarios de géo-basculement, car elle supprime la difficulté de gérer différentes clés d’accès pour le cache géo-principal et le cache géo-secondaire.

Supprimer un lien de géoréplication

1. Pour supprimer la liaison entre deux caches et arrêter la géoréplication, dans le panneau Géoréplication sur la gauche, sélectionnez Dissocier les caches.

   

   Une fois le processus de dissociation terminé, le cache secondaire est disponible tant en lecture qu’en écriture.

Notes

En cas de suppression du lien de géoréplication, les données répliquées à partir du cache lié principal restent dans le cache secondaire.

FAQ concernant la géoréplication

• Puis-je utiliser la géoréplication avec un cache de niveau Standard ou De base ?
• Mon cache est-il disponible pendant le processus de liaison ou de dissociation ?
• Quand puis-je écrire dans la nouvelle instance géo principale après avoir lancé le basculement ?
• Puis-je suivre l’intégrité du lien de géoréplication ?
• Puis-je lier plus de deux caches ?
• Puis-je lier deux caches d’abonnements Azure différents ?
• Puis-je lier deux caches de tailles différentes ?
• Puis-je utiliser la géoréplication quand le clustering est activé ?
• Puis-je utiliser la géoréplication avec mes caches dans un réseau virtuel ?
• Quelle est la planification de réplication pour la géoréplication Redis ?
• Quelle est la durée de réplication pour la géoréplication ?
• Y a-t-il un point de récupération de la réplication garanti ?
• Puis-je utiliser PowerShell ou Azure CLI pour gérer la géoréplication ?
• Combien coûte la réplication de mes données entre des régions Azure ?
• Pourquoi ma tentative de suppression de mon cache lié a-t-elle échoué ?
• Quelle région dois-je utiliser pour mon cache lié secondaire ?
• Puis-je configurer un pare-feu avec la géoréplication ?

Puis-je utiliser la géoréplication avec un cache de niveau Standard ou De base ?

Non, la géoréplication passive est disponible uniquement dans le niveau Premium. Une version plus avancée de la géoréplication, appelée géoréplication active, est disponible dans les niveaux Entreprise et Enterprise Flash.

Mon cache est-il disponible pendant le processus de liaison ou de dissociation ?

• Le cache lié principal reste disponible jusqu'à la fin du processus.
• Le cache lié secondaire n'est pas disponible tant que le processus de liaison n'est pas terminé.
• Les deux caches restent disponibles jusqu’à ce que le processus de dissociation soit terminé.

Quand puis-je écrire dans la nouvelle instance géo principale après avoir lancé le basculement ?

Quand le processus de basculement est lancé, l’état de provisionnement des liens passe à Suppression, ce qui indique que le lien précédent est en cours de nettoyage. Une fois cette opération terminée, l’état de provisionnement du lien passe à Création. Cela indique que la nouvelle instance géo principale est opérationnelle et tente de rétablir un lien de géoréplication vers l’ancien cache géo-principal. À ce stade, vous pouvez vous connecter immédiatement à la nouvelle instance du cache géoprincipal pour les lectures et les écritures.

Puis-je suivre l’intégrité de la liaison de géoréplication ?

Oui, plusieurs métriques sont disponibles pour faciliter le suivi de l’état de la géoréplication. Ces métriques sont disponibles dans le portail Azure.

• Géoréplication saine indique l’état de la liaison de géoréplication. Le lien apparaît comme non sain si le cache géoprincipal ou géosecondaire est en échec. Cet état est généralement dû à des opérations de mise à jour corrective standard, mais il peut également indiquer une situation de défaillance.
• Décalage de la connectivité de géoréplication indique le temps écoulé depuis la dernière synchronisation des données réussie entre le cache géo-principal et le cache géo-secondaire.
• Décalage de la synchronisation des données de géoréplication indique la quantité de données qui n’a pas encore été synchronisée avec le cache géo-secondaire.
• Événement de synchronisation de géoréplication complète démarré indique qu’une action de synchronisation complète a été lancée entre les caches géo-principal et géo-secondaire. Cet état se produit si la réplication standard ne parvient pas à suivre le nombre des nouvelles écritures.
• Événement de synchronisation de géoréplication complète terminé indique qu’une action de synchronisation complète a été effectuée.

Il existe également un workbook prédéfini appelé Tableau de bord de géoréplication, qui inclut toutes les métriques d’intégrité de la géoréplication dans une même vue. L’utilisation de cette vue est recommandée, car elle agrège les informations qui sont émises uniquement à partir des instances de cache géo-principal ou géo-secondaire.

Puis-je lier plus de deux caches ?

Non, vous ne pouvez pas lier plus de deux caches lors de l’utilisation de la géoréplication passive. La géoréplication active prend en charge jusqu’à cinq caches liés.

Puis-je lier deux caches d’abonnements Azure différents ?

Non, les deux caches doivent figurer dans le même abonnement Azure.

Puis-je lier deux caches de tailles différentes ?

Oui, pour autant que le cache lié secondaire soit plus grand que le cache lié principal. En revanche, vous ne pouvez pas utiliser la fonctionnalité de basculement si les caches ont des tailles différentes.

Puis-je utiliser la géoréplication quand le clustering est activé ?

Oui, pour autant que les deux caches aient le même nombre de partitions.

Puis-je utiliser la géoréplication avec mes caches dans un réseau virtuel ?

Nous vous recommandons d’utiliser Azure Private Link sur l’injection de réseau virtuel dans la plupart des cas. Pour plus d’informations, consultez Migrer des caches d’injection VNet vers des caches Private Link.

Bien qu’il soit toujours techniquement possible d’utiliser l’injection de réseau virtuel lors de la géoréplication de vos caches, nous vous recommandons d’utiliser Azure Private Link.

Important

Azure Cache pour Redis recommande d’utiliser Azure Private Link, qui simplifie l’architecture réseau et sécurise la connexion entre les points de terminaison dans Azure. Vous pouvez vous connecter à une instance Azure Cache depuis votre réseau virtuel via un point de terminaison privé, auquel est attribuée une adresse IP privée dans un sous-réseau au sein du réseau virtuel. Azure Private Link est proposé sur tous nos niveaux et comprend la prise en charge d’Azure Policy et la gestion simplifiée des règles NSG. Pour en savoir plus, consultez Documentation de Private Link. Pour migrer vos caches injectés dans un réseau virtuel vers Private Link, consultez Migrer des caches d’injection VNet vers des caches Private Link.

Pour plus d’informations sur la prise en charge de la géoréplication avec des réseaux virtuels, consultez Géoréplication en utilisant l’injection de réseaux virtuels avec des caches Premium.

Quelle est la planification de réplication pour la géoréplication Redis ?

La réplication est continue et asynchrone. Elle ne se produit pas selon une planification spécifique. Toutes les écritures effectuées sur le cache principal sont instantanément répliquées de façon asynchrone dans le cache secondaire.

Quelle est la durée de réplication pour la géoréplication ?

La réplication s'effectue en continu de manière incrémentielle et asynchrone. Sa durée est proche de la latence interrégion. Dans certaines circonstances, le cache secondaire peut avoir besoin d'une synchronisation complète des données à partir du cache principal. Dans ce cas, la durée de la réplication dépend de nombreux facteurs, tels que la charge sur le cache principal, la bande passante réseau disponible et la latence interrégion. Nous avons relevé que la durée de réplication d'une paire géorépliquée complète de 53 Go peut être comprise entre 5 et 10 minutes. Vous pouvez suivre la quantité de données qu’il reste à répliquer à l’aide de la métrique Geo Replication Data Sync Offset dans Azure Monitor.

Y a-t-il un point de récupération de la réplication garanti ?

Pour les caches en mode géorépliqué, la persistance est désactivée. Si une paire géorépliquée est dissociée, comme dans le cas d'un basculement initié par le client, les données du cache lié secondaire restent synchronisées jusqu'à ce moment-là. Aucun point de récupération n'est garanti dans de telles situations.

Pour obtenir un point de récupération, exportez à partir de l'un ou l'autre des caches. Vous pourrez ensuite importer dans le cache lié principal.

Puis-je utiliser PowerShell ou Azure CLI pour gérer la géoréplication ?

Oui, la géoréplication peut être gérée à l'aide du portail Azure, de PowerShell ou d'Azure CLI. Pour plus d'informations, consultez la documentation de PowerShell ou d'Azure CLI.

Combien coûte la réplication de mes données entre régions Azure ?

Lorsque vous utilisez la géoréplication, les données du cache lié principal sont répliquées vers le cache lié secondaire. Le transfert de données est gratuit si les deux caches liés se trouvent dans la même région. Si les deux caches liés se trouvent dans des régions différentes, les frais de transfert de données correspondent aux frais de sortie de réseau des données transférées dans l'une ou l'autre des régions. Pour plus d'informations, consultez Détails de la tarification de la bande passante.

Pourquoi ma tentative de suppression de mon cache lié a-t-elle échoué ?

Les caches géorépliqués et leurs groupes de ressources ne peuvent pas être supprimés tant qu'ils sont liés. Vous devez d'abord supprimer le lien de géoréplication. Si vous tentez de supprimer le groupe de ressources contenant l’un des caches liés ou les deux, les autres ressources du groupe sont supprimées, mais le groupe de ressources reste dans l’état deleting et les caches liés dans le groupe de ressources restent dans l’état running. Pour supprimer complètement le groupe de ressources et les caches liés qu’il contient, dissociez les caches comme décrit dans Supprimer un lien de géoréplication.

Quelle région dois-je utiliser pour mon cache lié secondaire ?

D’une façon générale, nous recommandons de placer votre cache dans la même région Azure que l’application qui y accède. Pour les applications disposant d’une région principale et d’une région de secours distinctes, il est recommandé de placer votre cache principal et votre cache secondaire dans ces mêmes régions. Pour plus d’informations sur les régions liées, consultez Meilleures pratiques : régions Azure liées.

Puis-je configurer un pare-feu avec la géoréplication ?

Oui, vous pouvez configurer un pare-feu avec la géoréplication. Pour que la géoréplication fonctionne avec le pare-feu, assurez-vous que l’adresse IP du cache secondaire est ajoutée aux règles de pare-feu du cache principal. Cependant, si l’accès au réseau public est désactivé sur le cache et que seul le point de terminaison privé est activé, l’utilisation du pare-feu sur le cache n’est pas prise en charge.

Étapes suivantes

En savoir plus sur les fonctionnalités d’Azure Cache pour Redis.

• Niveaux de service Azure Cache pour Redis
• Haute disponibilité pour Azure Cache pour Redis