Géo réplication dans Azure Service Bus

Le 10 et 11 juin 2024, j’ai assisté à l’événement « Integrate 2024 » de l’entreprise Kovai. Microsoft annonce alors une nouvelle fonctionnalité : la géo réplication pour Azure Service Bus.

La préversion publique est initialement prévue pour le 17 juin 2024. C’est finalement le 25 juin 2024 qu’Eldert Grootenboer, Senior Product Manager de Microsoft, annonce sa sortie dans un article paru dans le blog tech de Microsoft.

Vous allez comprendre dans cet article les apports de cette nouveauté.

 

Principe de géo réplication

 

Prérequis

 

Tout d’abord, notez que cette fonctionnalité est uniquement disponible sur le niveau Premium de Service Bus. De plus, la géo réplication prend en charge actuellement une seule région secondaire, nous reviendrons sur ce principe de régions.

Microsoft indique également qu’il s’agit d’une préversion publique et qu’elle ne doit donc pas être utilisée en environnement de production. Aussi, elle est pour le moment disponible uniquement dans certaines régions. La disponibilité de la fonctionnalité s’étendra au fur et à mesure, vous pouvez suivre cela sur la documentation officielle de Microsoft.

Avant : la « Geo-disaster recovery »

 

Avant la géo réplication, Azure propose pour Service Bus la « Geo-disaster recovery » (Géo reprise d’activité après sinistre). Elle permet de garantir l’intégrité des métadonnées (entités, configuration, propriétés). Pour ce faire, un espace de nom secondaire est couplé à l’espace de nom primaire utilisé actuellement dans le flux. En cas de panne ou de sinistre, ces métadonnées sont basculées de l’espace de nom primaire vers le secondaire. La réplication est continue et le basculement presque instantané.

Pour connaitre plus précisément le fonctionnement de cette méthode, vous pouvez consulter la documentation de Microsoft.

 

Maintenant : la géo réplication

 

Principe

Comme évoqué lors du paragraphe précédent, la « Geo-disaster recovery » protège uniquement les métadonnées. C’est pourquoi Microsoft, à travers la géo réplication, étend son offre aux données.

Ainsi, sont protégés :

• Files d’attente, rubriques, abonnements, filtres
• Données des entités.
• Modifications d’état et de propriétés exécutées sur les messages dans un espace de noms.
• Configuration de l’espace de noms.

Pour ce faire, on conserve les mêmes logiques :

• 1 région primaire (utilisée) et 1 région secondaire (sauvegarde). Les deux régions partagent la même configuration, permettant une promotion rapide.
• Réplication continue des données et métadonnées entre les 2 régions
• Basculement quasi instantané pour minimiser l’interruption de service

Voici un schéma illustrant le fonctionnement de la géo réplication :

 

 

En état de marche, les producteurs et les consommateurs des messages du Service Bus Namespace utilisent un seul espace de nom pour se connecter à la région primaire. Cela permet aux utilisateurs de configurer leur flux en utilisant cet espace de nom et de ne pas avoir à le changer lors du basculement. Il pointe toujours vers la région primaire. En cas de panne ou de sinistre, on promeut une région secondaire. L’espace de nom bascule alors pour pointer vers la région secondaire, qui devient la région primaire. L’ancienne région primaire est rétrogradée en région secondaire. Une fois cette nouvelle région secondaire réinitialisée, on peut promouvoir de nouveau cette région au rang de primaire.

Le client gère la promotion de région primaire en région secondaire, via une propriété. Ainsi, il dispose d’une visibilité complète pour la résolution du problème à l’origine du basculement. L’automatisation de la promotion est également possible via les métriques associés. A noter qu’il n’est pas possible de lire ou écrire dans les régions secondaires.

Modes de réplication

Il existe deux modes de réplication :

• Synchrone : toutes les requêtes sont répliquées vers la région secondaire. Cette dernière doit valider et confirmer l’opération avant la validation dans la région primaire. Par conséquent, votre application publie au rythme nécessaire pour publier, répliquer, accuser réception et valider. Cela requiert également que les deux régions doivent être disponibles pour votre application. Si la région secondaire est en retard ou n’est pas disponible, les messages ne sont pas acceptés et validés, et la région primaire limite les requêtes entrantes. Ce mode permet de sécuriser vos données puisque la validation est effective dans les deux régions. En revanche, cela augmente la latence de la réplication.
• Asynchrone : toutes les requêtes sont immédiatement validées dans la région primaire. C’est seulement après qu’un accusé de réception est envoyé au client. La réplication vers la région secondaire est donc asynchrone, les utilisateurs peuvent configurer la durée maximale de décalage entre la dernière action de la région primaire et secondaire. Si cela dépasse la valeur configurée, la région primaire commence à limiter les requêtes entrantes. Ceci permet une latence plus faible. De plus, la perte d’une région secondaire n’a pas d’impact immédiat sur la disponibilité tant que la durée maximale de décalage n’est pas atteinte. En revanche, cela n’élimine pas le risque de perte de données, car toutes les régions ne disposent pas forcément de l’ensemble des données avant validation. Cependant, étant donné que vous n’êtes plus immédiatement impacté lorsqu’une seule région est en retard ou n’est pas disponible, la disponibilité des applications augmente et la latence diminue.

 

Cas d’utilisation

 

Scénarios

 

Réplication choisie

Sans quelconque événement extérieur que vous subissez, vous pouvez choisir de migrer votre Service Bus Namespace vers une autre région. Voici une liste non exhaustive des raisons pouvant amener à cette utilisation de la géo réplication :

• Azure ouvre une nouvelle région géographiquement plus proche de la localisation de votre entreprise ou de vos utilisateurs. Pour des raisons d’optimisation de performance et de contrôle, vous pouvez privilégier une migration vers cette nouvelle région à proximité.
• Vos autre ressources Azure sont déplacées pour une raison tierce, comme par exemple une nouvelle fonctionnalité que vous souhaitez implémenter et qui n’est pas encore disponible dans la région actuelle de votre Service Bus. Par souci d’harmonisation et de performance, vous pouvez désormais faire suivre votre Service Bus vers cette nouvelle localisation.

Pour ce faire, il faut configurer la géo réplication sur l’espace de nom existant avec la nouvelle région souhaitée en tant que région secondaire. A la fin de la synchronisation, la promotion planifiée de la région démarre. Les messages déjà publiés sont alors répliqués. A la fin de la promotion, vous pouvez supprimer l’ancienne région, elle devient secondaire. Vos flux s’exécutent désormais sur la nouvelle région primaire souhaitée.

Réplication subie

Là où la géo réplication prend tout son sens, c’est lorsqu’un événement imprévu survient et affecte l’utilisation de votre Service Bus. Cela peut être :

• Panne subie dans la région
• Sinistre, par exemple une attaque informatique ou même au niveau de la région physique
• Dégradation des performances du Service Bus dans la région

Il est alors important que votre région secondaire puisse couvrir la région primaire que vous utilisez. De plus, la géo réplication assure une synchronisation continue pour que votre Service Bus soit toujours disponible et ainsi éviter toute interruption de service. Ceci s’effectue via la promotion de la région secondaire. Selon la gravité des services affectés, deux promotions sont possibles :

• Promotion planifiée : les messages déjà publiés sont répliqués avant la finalisation de la promotion
• Promotion forcée : le basculement de région est quasi instantané, il convient juste d’attendre la fin de la promotion

 

Mise en place dans Azure

 

Après la théorie, l’objectif est de vous montrer en pratique comment fonctionne la géo réplication. Etant donné qu’il s’agit d’une fonctionnalité encore en préversion publique, il convient de consulter la documentation de Microsoft pour bénéficier des dernières avancées de Microsoft.

Promotion

Les étapes de la promotion sont:

• Lancement de la promotion : le client la déclenche manuellement. L’espace de noms est placé en mode lecture seule à partir du moment où une promotion est demandée, jusqu’à la fin de la promotion. Concernant les deux types de promotion :
  • Promotion planifiée : le service attend la fin du décalage de réplication avant de lancer la promotion.
  • Promotion forcée : le service lance la promotion immédiatement. Attention, cela signifie que vous pouvez perdre toutes les données qui n’ont pas été répliquées.
  • Vous pouvez effectuer une promotion forcée à tout moment après le lancement d’une promotion planifiée. Cela permet à l’utilisateur d’accélérer la promotion, lorsqu’un basculement planifié prend plus de temps que souhaité.

• Le nom d’hôte est mis à jour de façon à pointer vers la région secondaire (cela peut prendre quelques minutes). Il est possible de vérifier le fonctionnement de la région primaire en lançant un ping vers le nom de domaine complet de votre espace de noms.
• Les clients se reconnectent automatiquement à la région secondaire. Il est possible d’automatiser la promotion à l’aide de systèmes de surveillance ou de solutions de surveillance personnalisées. Toutefois, cette automatisation nécessite des tâches de planification et du travail supplémentaire.

 

Surveillance de la réplication des données

Les utilisateurs peuvent suivre l’avancée de la réplication grâce aux métriques. Pour cela, il faut activer les journaux de métriques dans votre Service Bus Namespace (en rouge) :

 

 

Les données sont ensuite disponibles via les Journaux d’activité (en bleu).

Vous pouvez utiliser la requête suivante pour rechercher le décalage de réplication (en secondes) entre les régions primaires et secondaires :

 

AzureMetrics
| where TimeGenerated > ago(1h)
| where MetricName == "ReplicationLagDuration"

 

Conclusion

 

Comme vous l’avez vu, la nouvelle fonctionnalité de géo réplication de Microsoft permet d’aller encore plus loin que la « Geo-disaster recovery » déjà existante. En effet, le fait de pouvoir répliquer les données en plus des métadonnées est crucial pour conserver l’ensembles des données qui transitent via Azure Service Bus.

Pour utiliser efficacement la géo réplication, vous devez maitriser ses principes et déterminer quel est le mode le plus adapté à votre projet : synchrone pour sécuriser vos données ou asynchrone pour un traitement plus efficace. Vous devez aussi corréler votre choix selon le scénario dans lequel vous opérez la géo réplication : exécuter une action voulue ou pour éviter de subir un problème tiers qui affecte votre Service Bus.

Maintenant que vous connaissez la théorie, il reste à mettre la géo réplication en pratique. Pour cela, il ne faut pas oublier que la géo réplication est une fonctionnalité en préversion publique. Cela signifie que Microsoft n’a pas encore totalement abouti sa mise en place et que vous devez surveiller ses avancées ainsi que les régions dans lesquelles elle est disponible.

Enfin, une petite note concernant la tarification : Microsoft facture le niveau Premium pour Service Bus par unité de messagerie. Avec la fonctionnalité de géo réplication, les régions secondaires s’exécutent sur le même nombre d’unités de messagerie que la région primaire, et vous devez calculer la tarification sur le nombre total d’unités de messagerie. En outre, vous encourrez des frais, calculés d’après la bande passante multipliée par le nombre de régions secondaires. Au cours de la préversion publique anticipée, Microsoft annule ces frais.

A vos marques, prêts, géo répliquez !