Géoréplication d'Azure Event Hubs

La fonctionnalité de géoréplication Event Hubs fournit la réplication des métadonnées (entités, configuration et propriétés) et des données (charges utiles d’événement) pour l’espace de noms, ce qui permet la continuité d’activité et la récupération d’urgence.

Remarque

La fonctionnalité de géoréplication Event Hubs est disponible uniquement sur le niveau Premium et Dédié.

Cette fonctionnalité 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 la région secondaire. L’espace de noms peut être considéré comme étant étendu à plusieurs régions, avec une région étant le principal et l’autre étant la région secondaire.

À tout moment, la région secondaire peut être promue pour devenir une région primaire. La promotion d’une région secondaire pointe à nouveau le nom de domaine complet (FQDN) de l’espace de noms vers la région secondaire sélectionnée, et la région principale précédente est rétrogradée en région secondaire.

Scénarios

La géoréplication Event Hubs peut être utilisée dans plusieurs scénarios différents, comme décrit ici.

Garantir la continuité d’activité et la reprise d’activité

La géoréplication garantit la continuité d’activité et la reprise d’activité pour toutes les données de streaming sur votre espace de noms. En répliquant des données entre les régions, les organisations peuvent se protéger contre la perte de données et s’assurer que leurs applications restent opérationnelles même en cas de panne régionale. Cette fonctionnalité est cruciale pour les applications stratégiques qui nécessitent une haute disponibilité et un temps d’arrêt minimal.

Distribution mondiale des données

La géoréplication peut être utilisée pour distribuer des données mondialement, ce qui permet aux applications d’accéder aux données à partir de la région la plus proche. Cela réduit la latence et améliore les performances des charges de travail situées dans différentes régions du monde.

Souveraineté et conformité des données

Les organisations qui opèrent dans plusieurs pays/régions doivent souvent se conformer aux lois de souveraineté des données qui exigent que les données soient stockées dans des limites géographiques spécifiques. La géoréplication permet à ces organisations de répliquer des données dans des régions conformes aux réglementations locales, en s’assurant qu’elles répondent aux exigences légales tout en conservant une plateforme de données unifiée.

Migration et mises à niveau

La géoréplication peut également être utilisée pour faciliter la migration des données, la maintenance et les mises à niveau du système. Les organisations peuvent migrer leur espace de noms de manière proactive d’une région principale vers une région secondaire pour permettre toute maintenance et mise à niveau sur la région principale.

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. La région secondaire agit comme une région de secours à chaud, ce qui signifie qu’il n’est pas possible d’interagir avec cette région secondaire. Toutefois, ils s’exécutent dans la même configuration que la région primaire, ce qui permet une promotion rapide, et sont prêts à intervenir immédiatement une fois la promotion effectuée.

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

• Modèle de réplication principal-secondaire : la géoréplication est basée sur le modèle de réplication principal-secondaire, où à un moment donné, il n’existe qu’un seul espace de noms principal qui sert les producteurs et les consommateurs d’événements.
• Event Hubs effectue une réplication complètement managée octet par octet des métadonnées, des données d’événement et du décalage consommateur des espaces de noms secondaires avec les niveaux de cohérence configurés.
• Nom d’hôte d’un espace de noms unique : lors de la configuration réussie d’un espace de noms Geo-Replication activé, 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.
• 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.
• Cohérence de la réplication : il existe deux paramètres de cohérence de réplication, synchrones et asynchrones.

État	Diagramme
Avant le basculement (promotion de la région secondaire)
Après le basculement (promotion de la région secondaire)

Modes de réplication

Il existe deux configurations de cohérence de réplication, synchrones et asynchrones. Il est important de connaître les différences entre les deux configurations, car elles ont un impact sur vos applications et la cohérence de vos données.

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 : décalage côté service entre la dernière action sur le serveur principal et les régions secondaires. Le service réplique en permanence les données et les métadonnées, ce qui garantit que le décalage reste aussi petit que possible. Si le décalage d’une base de données secondaire active dépasse le décalage de réplication maximal configuré par l’utilisateur, le serveur principal 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 de la cohérence 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. Si une région tombe en panne, votre espace de noms n’est pas disponible.

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.

Capacité	Réplication synchrone	Réplication asynchrone
Latence	Plus longue en raison des opérations de validation distribuées	Impacté de manière minimale
Disponibilité	Liée à la disponibilité des régions secondaires	La perte d’une région secondaire n’a pas d’impact immédiat sur la disponibilité
Cohérence des données	Données toujours validées dans les deux régions avant accusé de réception	Données validées dans la région primaire uniquement avant accusé de réception
RPO (objectif de point de récupération)	RPO 0, aucune perte de données lors de la promotion	RPO > 0, perte de données possible lors de la promotion

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.

Remarque

Si une région secondaire est en retard ou devient indisponible, l’application ne pourra plus répliquer les données vers cette région, et déclenchera la limitation une fois le décalage de réplication atteint. Pour continuer à utiliser l’espace de noms dans la région primaire, vous pouvez supprimer la région secondaire affectée. Si aucune autre région secondaire n’est configurée, l’espace de noms se poursuit sans Geo-Replication activé. Il est possible d’ajouter d’autres régions secondaires à tout moment. Les entités de niveau supérieur, qui sont des hubs d’événements, sont répliquées de manière synchrone, quel que soit le mode de réplication configuré.

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 en savoir plus sur les statistiques de latence du réseau Azure.

Remarque

La géoréplication nécessite que les copies primaires et secondaires des Hubs d’événements soient au même niveau. La configuration ne peut pas être effectuée entre les niveaux.

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 avec la fonctionnalité Geo-Replication activée.
• Configurer la cohérence de la réplication : la réplication synchrone et asynchrone est définie lorsque Geo-Replication est configuré, mais peut également être modifiée ultérieurement.
• Déclencher la promotion/le basculement : toutes les promotions sont lancées par le client.
• Supprimer un secondaire : si vous souhaitez supprimer une région secondaire à tout moment, vous pouvez le faire après quoi les données de la région secondaire sont supprimées.

Critères pour déclencher la promotion

Voici quelques cas où une promotion d'un serveur secondaire vers un serveur primaire peut être déclenchée.

• Panne régionale : en cas de panne régionale affectant la région primaire, vous devez promouvoir la région secondaire pour garantir la continuité de l’activité et réduire les temps d’arrêt.

• Activités de maintenance : pendant les activités de maintenance planifiées dans la région primaire, la promotion de la région secondaire peut aider à maintenir la haute disponibilité pour les applications stratégiques.

• Récupération d’urgence : en cas de sinistre affectant la région primaire, la promotion de la région secondaire garantit que vos données restent accessibles et que vos applications continuent de fonctionner.

• Problèmes de performances : si la région primaire rencontre des problèmes de performances qui affectent la disponibilité ou la fiabilité de vos hubs d’événements, la promotion de la région secondaire peut aider à atténuer ces problèmes.

Il est recommandé de tester occasionnellement les mécanismes de basculement pour garantir que le plan de continuité d’activité est efficace, et vos applications peuvent basculer en toute transparence vers la région secondaire si nécessaire.

Supervision de la réplication des données

Les utilisateurs peuvent superviser la progression du travail de réplication en surveillant la métrique de décalage de réplication dans les journaux Métriques d’application.

• Activez les journaux Métriques d’application dans votre espace de noms Event Hubs en suivant Supervision d’Azure Event Hubs – Azure Event Hubs | Microsoft Learn.

• Une fois les journaux Métriques d’application 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 Métriques d’application, accédez à la section Supervision de la page Event Hubs et sélectionnez Journaux dans le menu de gauche. Vous pouvez utiliser la requête suivante pour rechercher le décalage de réplication (en secondes) entre les espaces de noms principal et secondaires.

  AzureDiagnostics
    | where TimeGenerated > ago(1h)
    | where Category == "ApplicationMetricsLogs"
    | where ActivityName_s == "ReplicationLag
  

• La colonne count_d indique le décalage de réplication en secondes entre la région principale et secondaire.

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 d’événements risque de ne pas être disponible dans les circonstances suivantes :

• Après avoir demandé la promotion d’une région secondaire, la région primaire existante rejette les nouveaux événements publiés sur le hub d’événements.
• Lorsque le décalage de réplication entre les régions principale et secondaires atteint la durée maximale, la charge de travail d’entrée du serveur de publication risque d’ê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 utilisatrices peuvent consommer des données en se servant du nom d'hôte 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.

Gestion des points de contrôle/décalage

Les applications consommatrices d’événements peuvent continuer à gérer les décalages comme elles le feraient avec un espace de noms non géorépliqué. Aucune considération particulière n’est nécessaire pour la gestion des décalages pour les espaces de noms compatibles avec la géoréplication.

Avertissement

En cas de basculement forcé (autrement dit, basculement non normal), certaines données qui ne sont pas encore copiées peuvent être perdues. Cela peut entraîner la différence entre les décalages de ces données spécifiques entre les régions primaires et secondaires de l’espace de noms. Toutefois, il se trouve toujours dans les limites du décalage de réplication maximal configuré pour l’espace de noms. Dans ce cas, il est préférable de commencer à consommer à partir du dernier décalage validé. Certaines données peuvent avoir un traitement en double et doivent être gérées côté client.

Kafka

Les décalages sont validés directement dans Event Hubs et sont répliqués entre les régions. Par conséquent, les consommateurs peuvent commencer à consommer à partir de l’endroit où il s’est arrêté dans la région principale.

Voici la liste des clients Apache Kafka pris en charge :

Nom du client	Version
Apache Kafka	2.1.0 ou version ultérieure
Bibliothèques Librdkafka et dérivées	2.1.0 ou version ultérieure

Dans le cas d’autres bibliothèques, celles qui utilisent les versions d’API ci-dessous sont prises en charge :

Nom de l’API	Version prise en charge
API de métadonnées	7 ou ultérieure
API Fetch	9 ou ultérieure
API ListOffset	4 ou ultérieure
API OffsetFetch	5 ou ultérieure
API OffsetForLeaderEpoch	0 ou version ultérieure

Kit de développement logiciel (SDK) Event Hubs/AMQP

Pour AMQP, le point de contrôle est géré par les utilisateurs disposant d’un magasin de points de contrôle tel que le stockage Blob Azure ou une solution de stockage personnalisée. S’il existe un basculement, le magasin de points de contrôle doit être disponible à partir de la région secondaire afin que les clients puissent récupérer les données de point de contrôle et éviter la perte de messages.

La dernière version du Kit de développement logiciel (SDK) Event Hubs a apporté des modifications à la représentation des points de contrôle pour prendre en charge les basculements. Nous vous recommandons d’utiliser les dernières versions des kits SDK, mais les versions antérieures des kits SDK ci-dessous sont également prises en charge.

Langue	Nom du package
C#	Azure.Messaging.EventHubs
C#	Microsoft.Azure.EventHubs

Avertissement

Dans le cadre de l’implémentation, le format de point de contrôle est adapté lorsque la géoréplication est activée sur un espace de noms. Les points de contrôle suivants une fois la géoréplication terminée seront écrits avec un nouveau format. Si vous forcez la promotion d'une région secondaire en région primaire juste après la réalisation du jumelage de géoréplication, mais avant qu'un nouveau point de contrôle ne soit stocké (ce qui peut se produire dans le cas d'une promotion ou d'un basculement forcé), alors les nouvelles données publiées après la promotion peuvent être perdues.

Dans ce cas, il est préférable de commencer à consommer à partir du dernier décalage validé. Certaines données peuvent avoir un traitement en double et doivent être gérées côté client.

Il est également recommandé d’effectuer une mise à niveau vers les dernières versions des kits SDK.

Considérations

Notez les considérations suivantes à prendre en compte avec cette fonctionnalité :

• 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.

Tarifs

La tarification varie en fonction du niveau que vous choisissez, mais a généralement 2 paramètres :

• Frais de calcul pour le cluster ou l’espace de noms.
• Frais de bande passante pour les données répliquées entre les régions primaires et secondaires.

Remarque

Reportez-vous aux détails de tarification répertoriés dans Azure Event Hubs pour déterminer les frais. Les frais de géoréplication dépendent de l’emplacement de la région primaire.

Clusters dédiés

L’utilisation de la géoréplication avec Event Hubs dédié vous oblige à disposer d’au moins deux clusters dédiés dans des régions distinctes, qui peuvent être utilisés pour héberger des espaces de noms autres que ceux qui sont géorépliqués. Ces clusters dédiés sont facturés séparément en fonction du nombre d’unités de capacité allouées à chacun d’eux.

Lorsque la géoréplication est activée, la seule charge supplémentaire est la charge de bande passante pour les données répliquées du serveur principal vers la base de données secondaire. Cette charge dépend de l’emplacement de la région primaire.

Espaces de noms premium

Pour les espaces de noms Premium, l'activation de la géo-réplication met en service le même nombre d'unités de traitement (UT) dans la région secondaire. Par conséquent, vous payez le nombre de processeurs que vous utilisez et la bande passante pour les données transférées entre la région primaire et secondaire.

Par exemple, si vous activez la géoréplication sur un espace de noms Premium qui a été approvisionné avec 4 PU, vous serez facturé pour

• 4 PUs dans la région primaire,
• 4 unités de traitement dans la région secondaire,
• Frais de géoréplication par Go de données répliquées.

La bande passante est facturée en fonction des données transférées entre les régions primaires et secondaires.

Compteurs tarifaires

Les compteurs tarifaires pour les frais de bande passante de transfert de données de géoréplication s’affichent avec les détails ci-dessous :

Nom du produit	Description du compteur
Service Bus	Service Bus - Géoréplication Zone 1 Go transfert de données - NOM DE LA RÉGION
Service Bus	Service Bus - Géoréplication Zone 2 Go transfert de données - NOM DE LA RÉGION
Service Bus	Service Bus - Zone de géoréplication - Transfert de données de 3 Go - NOM DE LA RÉGION

Points de terminaison privés

Cette section fournit des considérations supplémentaires lors de l’utilisation de Geo-Replication avec des espaces de noms qui utilisent des points de terminaison privés. Pour obtenir des informations générales sur l’utilisation de points de terminaison privés avec Event Hubs, consultez Intégrer Azure Event Hubs à Azure Private Link.

Lors de l’implémentation de Geo-Replication pour un espace de noms Event Hubs qui utilise des points de terminaison privés, il est important de créer des points de terminaison privés pour les régions primaires et secondaires. Ces points de terminaison doivent être configurés sur des réseaux virtuels hébergeant des instances primaires et secondaires de votre application. Par exemple, si vous avez deux réseaux virtuels, VNET-1 et VNET-2, vous devez créer deux points de terminaison privés sur l’espace de noms Event Hubs, à l’aide de sous-réseaux de VNET-1 et VNET-2 respectivement. De plus, les réseaux virtuels doivent être configurés avec le peering interrégion, afin que les clients puissent communiquer avec l’un ou l’autre point de terminaison privé. Enfin, le DNS doit être géré de telle sorte que tous les clients obtiennent les informations DNS, qui doivent pointer le point de terminaison d’espace de noms (namespacename.servicebus.windows.net) vers l’adresse IP du point de terminaison privé dans la région primaire actuelle.

Important

Lors de la promotion d’une région secondaire pour Event Hubs, l’entrée DNS doit également être mise à jour pour pointer vers le point de terminaison correspondant.

L’avantage de cette approche est que le basculement peut se produire de manière indépendante au niveau de la couche applicative ou sur l’espace de noms Event Hubs :

• Basculement d’application uniquement : dans ce scénario, l’application passe de VNET-1 à VNET-2. Étant donné que les points de terminaison privés sont configurés sur VNET-1 et VNET-2 pour les espaces de noms principaux et secondaires, l’application continue de fonctionner en toute transparence.
• Basculement de l’espace de noms Event Hubs uniquement : de même, si le basculement se limite à l’espace de noms Event Hubs, l’application reste opérationnelle, car les points de terminaison privés sont configurés sur les deux réseaux virtuels.

En suivant ces instructions, vous pouvez garantir des mécanismes de basculement robustes et fiables pour vos espaces de noms Event Hubs à l’aide de points de terminaison privés.

Contenu connexe

Pour savoir comment utiliser la fonctionnalité de géoréplication, consultez Utiliser la géoréplication.