Géoréplication dans Azure Event Hubs

Azure Event Hubs géoréplication conserve les copies des métadonnées de votre espace de noms (entités, configuration et propriétés) et des données d'événements dans plusieurs régions Azure. Si votre région principale subit une panne, vous pouvez promouvoir une région secondaire pour maintenir l’exécution de vos applications de diffusion en continu avec une perte de données minimale.

Les sections suivantes expliquent comment fonctionne la géoréplication, comparent les modes de réplication synchrone et asynchrone, et décrivent comment gérer les régions secondaires.

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

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 globale 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 ou 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 utilise un modèle de réplication secondaire principal pour répliquer les métadonnées et les données. À tout moment, il existe 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. Vous ne pouvez donc pas interagir avec la région secondaire. Toutefois, il s’exécute dans la même configuration que la région primaire, ce qui signifie qu’il peut rapidement intervenir après être promu.

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

• Modèle de réplication secondaire primaire : la géoréplication est basée sur un modèle de réplication primaire-secondaire, où à un moment donné, il n’existe qu’un seul espace de noms principal qui sert les producteurs d’événements 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 : une fois que vous avez correctement configuré un espace de noms avec géoréplication, utilisez le nom d’hôte de l’espace de noms dans votre 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.
• Lorsque vous lancez une promotion, le nom d’hôte pointe vers la région sélectionnée pour être la nouvelle région primaire. L’ancienne région primaire devient une région secondaire.
• Vous ne pouvez pas lire ou é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.
• Vous pouvez ajouter ou supprimer des régions secondaires.
• Cohérence de la réplication : deux paramètres de cohérence de réplication sont disponibles : synchrone et asynchrone.

É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

Deux configurations de cohérence de réplication sont disponibles : synchrone et asynchrone. Comprenez les différences entre ces deux configurations, car elles affectent vos applications et votre cohérence des données.

Réplication asynchrone

Lorsque vous utilisez la réplication asynchrone, le principal valide toutes les requêtes, puis envoie un accusé de réception au client. La réplication vers les régions secondaires se produit de manière asynchrone. Vous pouvez 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

Lorsque vous utilisez la réplication synchrone, le système envoie toutes les requêtes à l’emplacement secondaire. L'emplacement secondaire valide et confirme l'opération avant que l'emplacement principal ne la valide. Par conséquent, votre application publie à la vitesse nécessaire pour publier, répliquer, reconnaître et valider. Ce processus signifie que votre application dépend de la disponibilité des deux régions. Si la région secondaire retarde ou n’est pas disponible, l’emplacement principal ne reconnaît pas ou ne valide pas les messages et limite les demandes 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é dépend de 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. Avec la réplication synchrone, les validations de données dans toutes les régions que vous avez configurées pour la géoréplication fournissent la meilleure assurance des données.

Avec la réplication asynchrone :

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

Par conséquent, il n’a pas la garantie absolue que toutes les régions disposent des données avant la validation comme le fait la réplication synchrone, et il y a un risque de perte ou de duplication de données. Toutefois, étant donné que vous n’êtes plus immédiatement affecté lorsqu’une seule région est en retard ou qu’elle n’est pas disponible, la disponibilité des applications s’améliore, en plus d’avoir une latence inférieure.

Vous pouvez modifier le mode de réplication après avoir configuré la géoréplication. Vous pouvez passer de synchrone à asynchrone ou de asynchrone à synchrone. Si vous passez d’asynchrone à synchrone, la région secondaire est configurée comme synchrone une fois le décalage atteint zéro. Si vous avez un décalage continu pour une raison quelconque, vous devrez peut-être suspendre vos processus de publication pour que le décalage atteigne zéro et que votre mode puisse basculer en mode synchrone. Les raisons d’activer la réplication synchrone, au lieu de la réplication asynchrone, sont liées à l’importance des données, des besoins métier spécifiques ou des raisons de conformité, plutôt que la disponibilité de votre application.

Sélection de la région secondaire

Pour activer la fonctionnalité de géoréplication, utilisez les régions primaires et secondaires où la fonctionnalité est activée. La fonctionnalité de géoréplication dépend de la possibilité de répliquer les messages publiés du serveur principal vers les régions secondaires. Si la région secondaire se trouve sur un autre continent, ce choix 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é, choisissez des régions secondaires sur le même continent si possible. Pour mieux comprendre la latence induite par la distance géographique, consultez Azure statistiques de latence de aller-retour réseau.

Gestion de la géoréplication

La fonctionnalité de géoréplication vous permet de configurer une région secondaire vers laquelle répliquer des métadonnées et des données. Par conséquent, vous pouvez effectuer les tâches de gestion suivantes :

• Configurer la géoréplication : vous pouvez configurer des régions secondaires sur n’importe quel espace de noms nouveau ou existant dans une région en activant la fonctionnalité de géoréplication.
• Configurez la cohérence de la réplication : définissez la réplication synchrone et asynchrone lorsque vous configurez la géoréplication. Vous pouvez également changer ce paramètre 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, vous pouvez le faire. 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’une base de données secondaire vers la base de données primaire peut être déclenchée.

• Panne régionale : en cas de panne régionale affectant la région primaire, favorisez 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.

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

Supervision de la réplication des données

Vous pouvez surveiller la progression du travail de réplication en vérifiant la métrique de décalage de réplication dans les journaux des métriques d’application.

• Activez les journaux des indicateurs d’application dans votre espace de noms Event Hubs en suivant Monitoring Azure Event Hubs - Azure Event Hubs | Microsoft Learn.

• Après avoir activé les journaux des métriques d’application, produisez et consommez des données à partir de l’espace de noms pendant quelques minutes avant de commencer à voir les journaux.

• Pour afficher les journaux des métriques d’application, accédez à la section Surveillance de la page Event Hubs, puis sélectionnez Journaux dans le menu de gauche. Utilisez la requête suivante pour rechercher le décalage de réplication (en secondes) entre les espaces de noms principaux et secondaires.

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

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

Publication de données

Les applications de publication peuvent envoyer des données à 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. Vous n’avez pas besoin d’apporter de modifications aux kits SDK de plan de données ou aux applications clientes.

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 peuvent consommer des données en utilisant le nom d’hôte d’un espace de noms avec la géoréplication activée. Les opérations de consommateur ne sont pas prises en charge à partir du moment où la promotion commence jusqu’à la fin de la promotion.

Gestion des points de contrôle et des décalages

Les applications consommant des événements peuvent gérer la gestion des décalages de la même manière qu'avec un espace de noms non géorépliqué. Les espaces de noms avec géoréplication n’ont pas besoin d’une considération particulière pour la gestion des décalages.

Kafka

Les consommateurs valident les décalages directement vers Event Hubs, et le système réplique les décalages entre les régions. Par conséquent, les consommateurs peuvent commencer à consommer à partir de l’endroit où ils se sont arrêtés dans la région primaire.

Voici la liste des clients Apache Kafka pris en charge :

Pour d’autres bibliothèques, la prise en charge dépend de la version de l’API :

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

Pour AMQP, les utilisateurs gèrent le point de contrôle à l’aide d’un magasin de points de contrôle tel que Azure stockage Blob ou une solution de stockage personnalisée. En cas de basculement, la région secondaire doit avoir le magasin de points de contrôle 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 inclut des modifications de la représentation des points de contrôle pour prendre en charge les défaillances. Utilisez les dernières versions des kits SDK, mais les versions antérieures des kits SDK suivants sont également prises en charge.

Considérations

Gardez à l’esprit les considérations suivantes :

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

Tarifs

Les tarifs varient en fonction du niveau que vous choisissez, mais ont généralement deux 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.

Clusters dédiés

Lorsque vous utilisez la géoréplication avec des clusters dédiés Event Hubs, vous avez besoin d’au moins deux clusters dédiés dans des régions distinctes. Vous pouvez utiliser ces clusters pour héberger des espaces de noms autres que ceux répliqués géographiquement. Vous payez ces clusters dédiés séparément en fonction du nombre d’unités de capacité allouées à chacun d’eux.

Lorsque vous activez la géoréplication, 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, lorsque vous activez la géoréplication, vous obtenez le même nombre d’unités de traitement dans la région secondaire. 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 que vous avez approvisionné de 4 PUs, vous payez 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.

Vous payez des frais de bande passante en fonction des données transférées entre les régions primaires et secondaires.

Compteurs de tarification

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

Points de terminaison privés

Cette section fournit des considérations supplémentaires lors de l’utilisation de la géoréplication avec des espaces de noms qui utilisent des points de terminaison privés. Pour plus d’informations sur l’utilisation de points de terminaison privés avec Event Hubs, consultez Integrate Azure Event Hubs avec Azure Private Link.

Lorsque vous implémentez la géoréplication pour un espace de noms Event Hubs qui utilise des points de terminaison privés, créez des points de terminaison privés pour les régions primaires et secondaires. Configurez ces points de terminaison sur des réseaux virtuels qui hébergent 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. Configurez les réseaux virtuels avec peering inter-régions, pour permettre aux clients de communiquer avec l'un ou l'autre des points de terminaison privés. Enfin, gérez le DNS afin que tous les clients obtiennent les informations DNS qui pointent 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.

Cette approche offre l’avantage que le basculement peut se produire de manière indépendante au niveau de la couche d'application ou de l'espace de noms d'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 d’espace de noms Event Hubs uniquement : Si le basculement se produit uniquement au niveau de 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 qui utilisent des points de terminaison privés.

Contenu connexe

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