Géoréplication Azure Service Bus (préversion)

La fonctionnalité de géoréplication Service Bus est l’une des options permettant d’isoler les applications Azure Service Bus contre les pannes et les sinistres, grâce à la réplication des métadonnées (entités, configuration, propriétés) et des données (données de message et modifications d’état / propriétés de message).

La fonctionnalité de géoréplication garantit que les métadonnées et les données d’un espace de noms sont répliquées en continu d’une région primaire vers une ou plusieurs régions secondaires.

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

Cette fonctionnalité permet de promouvoir n’importe quelle région secondaire en région primaire, à tout moment. La promotion d’une région secondaire repointe le nom de l’espace de noms vers la région secondaire sélectionnée, et bascule les rôles entre la région primaire et la région secondaire. La promotion est presque instantanée une fois lancée.

Scénarios

La fonctionnalité de géoréplication peut être utilisée pour implémenter différents scénarios, comme décrit ici.

Récupération d’urgence

Les données et les métadonnées sont synchronisées en continu entre les régions primaires et secondaires. Si une région est en retard ou n’est pas disponible, il est possible de promouvoir une région secondaire en région primaire. Cette promotion permet le fonctionnement ininterrompu des charges de travail dans la région nouvellement promue. Une telle promotion peut être nécessaire en cas de dégradation de Service Bus ou d’autres services au sein de votre charge de travail, en particulier si vous souhaitez exécuter les différents composants ensemble. En fonction de» la gravité et des services affectés, la promotion peut être planifiée ou forcée. En cas de promotion planifiée, les messages en vol sont répliqués avant la finalisation de la promotion, tandis qu’avec la promotion forcée, celle-ci est exécutée immédiatement.

Migration de région

Il arrive que vous souhaitiez migrer vos charges de travail Service Bus pour les exécuter dans une autre région. Par exemple, quand Azure ajoute une nouvelle région géographiquement plus proche de votre localisation, des utilisateurs ou d’autres services. Vous souhaiterez peut-être également procéder à une migration lorsque l’exécution de la plupart de vos charges de travail est déplacée. La fonctionnalité de géoréplication constitue également une bonne solution dans ces cas-là. Dans ce cas, vous devez configurer la géoréplication sur votre espace de noms existant avec la nouvelle région souhaitée en tant que région secondaire, et attendre la fin de la synchronisation. À ce stade, vous démarreriez une promotion planifiée, permettant aux messages en vol d’être répliqués. Une fois la promotion terminée, vous pouvez désormais supprimer l’ancienne région, qui est maintenant la région secondaire, et continuer à exécuter vos charges de travail dans la région souhaitée.

Concepts de base

La fonctionnalité de géoréplication implémente les métadonnées et la réplication des données dans un modèle de réplication primaire-secondaire. À tout moment, il n’existe qu’une seule région primaire, qui sert à la fois les producteurs et les consommateurs. Les régions secondaires agissent comme des régions de secours à chaud, ce qui signifie qu’il n’est pas possible d’interagir avec elles. Toutefois, elles s’exécutent dans la même configuration que la région primaire, ce qui autorise une promotion rapide et signifie que vos charges de travail peuvent immédiatement continuer à s’exécuter une fois la promotion terminée. La fonctionnalité de géoréplication est disponible pour le niveau Premium.

Voici quelques-uns des aspects clés de la fonctionnalité de géoréplication :

• Les services Service Bus effectuent une réplication complètement managée des métadonnées, des données de message, et des modifications de l’état des messages et des propriétés entre les régions, adhérant à la cohérence de réplication configurée au niveau de l’espace de noms.
• Nom d’hôte d’espace de noms unique. Une fois la configuration d’un espace de noms activé pour la géoréplication réussie, les utilisateurs peuvent utiliser le nom d’hôte de l’espace de noms dans leur application cliente. Le comportement du nom d’hôte est indépendant des régions primaires et secondaires configurées, et pointe toujours vers la région primaire.
• Lorsqu’un client lance une promotion, le nom d’hôte pointe vers la région sélectionnée comme devant être la nouvelle région primaire. L’ancienne région primaire devient une région secondaire.
• Il n’est pas possible de lire ou d’écrire dans les régions secondaires.
• Modes de réplication synchrone et asynchrone, décrits ici.
• Promotion de région primaire en région secondaire gérée par le client, offrant une propriété et une visibilité complètes pour la résolution des pannes. Des métriques sont disponibles, et peuvent vous aider à automatiser la promotion du côté client.
• Les régions secondaires peuvent être ajoutées ou supprimées à la discrétion du client.

Modes de réplication

Il existe deux modes de réplication : synchrone et asynchrone. Il est important de connaître les différences entre les deux modes.

Réplication asynchrone

Avec la réplication asynchrone, toutes les requêtes sont validées dans la région primaire, après quoi un accusé de réception est envoyé au client. La réplication vers les régions secondaires se produit de manière asynchrone. Les utilisateurs peuvent configurer la durée maximale acceptable du décalage. Ce décalage correspond au décalage côté service entre l’action la plus récente dans la région primaire et dans les régions secondaires. Si le décalage d’une région secondaire active dépasse la valeur configurée par l’utilisateur, la région primaire commence à limiter les requêtes entrantes.

Réplication synchrone

Avec la réplication synchrone, toutes les requêtes sont répliquées vers la région secondaire, qui doit valider et confirmer l’opération avant la validation dans la région primaire. Par conséquent, votre application publie à la vitesse nécessaire pour publier, répliquer, reconnaître et valider. De plus, cela signifie également que votre application est liée à la disponibilité des deux régions. 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.

Comparaison des modes de réplication

Avec la réplication synchrone :

• La latence est plus longue en raison des opérations de validation distribuées.
• La disponibilité est liée à la disponibilité de deux régions.

En revanche, la réplication synchrone offre la plus grande assurance que vos données sont sécurisées. Si vous avez une réplication synchrone, la validation s’effectue dans toutes les régions que vous avez configurées pour la géoréplication, ce qui offre la meilleure assurance des données.

Avec la réplication asynchrone :

• La latence est affectée minimalement.
• La perte d’une région secondaire n’a pas d’impact immédiat sur la disponibilité. Toutefois, la disponibilité est affectée une fois que le décalage de réplication maximal configuré est atteint.

Par conséquent, il n’est pas absolument garanti que toutes les régions ont les données avant que nous les validions, comme c’est le cas avec la réplication synchrone, et une perte de données ou une duplication peut se produire. Toutefois, é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.

Le mode de réplication peut être changé après la configuration de la géoréplication. Vous pouvez passer de synchrone à asynchrone, ou d’asynchrone à synchrone. Si vous passez d’asynchrone à synchrone, votre région secondaire est configurée comme synchrone une fois que le décalage atteint zéro. Si vous observez un décalage continu pour quelque raison que ce soit, vous devrez peut-être suspendre vos serveurs de publication afin que le décalage atteigne zéro et que le mode puisse basculer vers synchrone. La préférence accordée à la réplication synchrone plutôt qu’à la réplication asynchrone est liée à l’importance des données, aux besoins métier spécifiques ou à des raisons de conformité, plutôt qu’à la disponibilité de votre application.

Sélection de la région secondaire

Pour activer la fonctionnalité de géoréplication, vous devez utiliser des régions primaires et secondaires là où la fonctionnalité est activée. La fonctionnalité de géoréplication dépend de la capacité à répliquer les messages publiés de la région primaire vers les régions secondaires. Si la région secondaire se trouve sur un autre continent, cela a un impact majeur sur le décalage de réplication de la région primaire vers la région secondaire. Si vous utilisez la géoréplication pour des raisons de disponibilité, il est préférable que les régions secondaires se trouvent au moins sur le même continent, dans la mesure du possible. Pour mieux comprendre la latence induite par la distance géographique, vous pouvez consulter les statistiques de latence aller-retour du réseau Azure.

Gestion de la géoréplication

La fonctionnalité de géoréplication permet aux clients de configurer une région secondaire vers laquelle répliquer des métadonnées et des données. Les clients peuvent effectuer les tâches de gestion suivantes :

• Configurer la géoréplication. Les régions secondaires peuvent être configurées sur n’importe quel espace de noms nouveau ou existant dans une région où la fonctionnalité de géoréplication est activée.

  Remarque

  Actuellement, dans la préversion publique, seuls les nouveaux espaces de noms sont pris en charge.

• Configurer la cohérence de la réplication. Vous pouvez définir la réplication synchrone ou asynchrone lorsque la géoréplication est configurée, mais vous basculer de l’une à l’autre par la suite.
• Déclencher la promotion. Toutes les promotions sont lancées par le client.
• Supprimer une région secondaire. Si vous souhaitez supprimer une région secondaire, vous pouvez le faire à tout moment, après quoi les données de la région secondaire sont supprimées.

Programme d’installation

En passant par le portail Azure

La section suivante est une vue d’ensemble de la configuration de la fonctionnalité de géo-réplication sur un nouvel espace de noms via le portail Azure.

1. Créez un espace de noms de niveau Premium.
2. Cochez la case Activer la géoréplication sous la section Réplication (préversion).
3. Cliquez sur le bouton Ajouter une région secondaire, puis choisissez une région.
4. Cochez la case Réplication synchrone ou spécifiez une valeur pour Réplication asynchrone – Décalage de réplication maximal en secondes.

Utilisation du modèle Bicep

Pour créer un espace de noms avec la fonctionnalité géo-réplication activée, ajoutez la section propriétés geoDataReplication.

param serviceBusName string
param primaryLocation string
param secondaryLocation string
param maxReplicationLagInSeconds int

resource sb 'Microsoft.ServiceBus/namespaces@2023-01-01-preview' = {
  name: serviceBusName
  location: primaryLocation
  sku: {
    name: 'Premium'
    tier: 'Premium'
    capacity: 1
  }
  properties: {
    geoDataReplication: {
      maxReplicationLagDurationInSeconds: maxReplicationLagInSeconds
      locations: [
        {
          locationName: primaryLocation
          roleType: 'Primary'
        }
        {
          locationName: secondaryLocation
          roleType: 'Secondary'
        }
      ]
    }
  }
}

Gestion

Une fois que vous avez créé un espace de noms avec la fonctionnalité de géoréplication activée, vous pouvez gérer la fonctionnalité à partir du panneau Réplication (préversion).

Changer de mode de réplication

Pour basculer entre les modes de réplication ou mettre à jour le décalage de réplication maximal, cliquez sur le lien sous Cohérence de la réplication, puis cochez la case pour activer/désactiver la réplication synchrone, ou mettez à jour la valeur dans la zone de texte afin de modifier le décalage maximal de réplication asynchrone.

Supprimer une région secondaire

Pour supprimer une région secondaire, cliquez sur les points de suspension (...) en regard de la région, puis sur Supprimer. Pour supprimer la région, suivez les instructions du panneau contextuel.

Flux de promotion

Une promotion est déclenchée manuellement par le client (soit explicitement à l’aide d’une commande, soit via une logique métier appartenant au client qui déclenche cette commande), et jamais par Azure. Ainsi, le client dispose d’une pleine propriété et d’une visibilité complète pour la résolution des pannes sur le segment principal d’Azure. Lorsque vous choisissez la promotion Planifiée, le service attend que le décalage de réplication devienne nul avant de lancer la promotion. En revanche, lors du choix de la promotion Forcée, le service lance la promotion immédiatement. 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. Il est possible d’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é.

Une fois la promotion lancée :

1. Le nom d’hôte est mis à jour de façon à pointer vers la région secondaire, ce qui peut prendre quelques minutes.

   Remarque

   Vous pouvez vérifier la région primaire actuelle en lançant une commande ping : ping nom_de_domaine_complet_de_votre_espace_de_noms

2. Les clients se reconnectent automatiquement à la région secondaire.

Vous pouvez 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émentaires, qui ne seront pas abordés dans cet article.

En passant par le portail Azure

Dans le portail, cliquez sur l’icône Promouvoir et suivez les instructions du panneau contextuel pour supprimer la région.

Utilisation de l’interface de ligne de commande Azure

Exécutez la commande Azure CLI pour lancer la promotion. La propriété Force est facultative et la valeur par défaut est false.

az rest --method post --url https://management.azure.com/subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>/providers/Microsoft.ServiceBus/namespaces/<namespaceName>/failover?api-version=2023-01-01-preview --body "{'properties': {'PrimaryLocation': '<newPrimaryocation>', 'api-version':'2023-01-01-preview', 'Force':'false'}}"

Surveillance de la réplication des données

Les utilisateurs peuvent surveiller la progression du travail de réplication en surveillant la métrique de décalage de réplication dans Log Analytics.

• Activez les journaux de métriques dans votre espace de noms Service Bus, comme décrit dans Surveiller Azure Service Bus.
• Une fois les journaux de métriques activés, vous devez produire et consommer des données à partir de l’espace de noms pendant quelques minutes pour que les journaux commencent à apparaître.
• Pour afficher les journaux de métriques, accédez à la section Surveillance de Service Bus et cliquez sur le panneau Journaux. 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"

Publication de données

Les applications de publication peuvent publier des données sur des espaces de noms géorépliqués via le nom d’hôte de l’espace de noms activé pour la géoréplication. L’approche de publication est identique au cas de non-géoréplication, et aucune modification des kits SDK de plan de données ou applications clientes n’est nécessaire. La publication peut ne pas être disponible dans les circonstances suivantes :

• Après que vous avez demandé la promotion d’une région secondaire, la région primaire existante rejette les nouveaux messages publiés dans Service Bus jusqu’à ce que la promotion soit terminée.
• Lorsque le décalage de réplication entre les régions primaires et secondaires atteint la durée maximale du décalage de réplication, la charge de travail d’entrée du serveur de publication peut être limitée.

Les applications de serveur de publication ne peuvent pas accéder directement aux espaces de noms dans les régions secondaires.

Consommation de données

Les applications consommatrices peuvent consommer des données à l’aide du nom d’hôte d’espace de noms d’un espace de noms avec la fonctionnalité de géoréplication activée. Les opérations de consommateur ne sont pas prises en charge entre le moment où la promotion est lancée et celui où elle est terminée.

À propos de l’installation

Notez les points suivants pour cette version :

• Dans votre planification de promotion, vous devez également tenir compte du facteur temps. Par exemple, si vous perdez la connectivité pendant plus de 15 à 20 minutes, vous pouvez décider de lancer la promotion.
• La promotion d’une infrastructure distribuée complexe doit être répétée au moins une fois.

Tarification

Le niveau Premium pour Service Bus est facturé par unité de messagerie. Avec la fonctionnalité de géoréplication, les régions secondaires s’exécutent sur le même nombre d’unités de messagerie que la région primaire, et la tarification est calculée sur le nombre total d’unités de messagerie. En outre, des frais sont encourus, calculés d’après la bande passante publiée multipliée par le nombre de régions secondaires. Au cours de la préversion publique anticipée, ces frais sont annulés.

Étapes suivantes

• Consultez les informations de référence sur l’API REST de géoréplication.
• Exécutez l’exemple de géoréplication sur GitHub.
• Consultez l’exemple de géoréplication qui envoie des messages à un alias.

Pour en savoir plus sur la messagerie Service Bus, consultez les articles suivants :

• Files d’attente, rubriques et abonnements Service Bus
• Prise en main des files d’attente Service Bus
• Utilisation des rubriques et abonnements Service Bus
• REST API