Géoréplication (préversion publique)

Il existe deux fonctionnalités qui fournissent la géo-reprise d’activité après sinistre dans Azure Event Hubs.

• Géo-reprise d’activité après sinistre (récupération d’urgence des métadonnées), qui fournit simplement la réplication des métadonnées uniquement.
• Géoréplication (préversion publique), qui fournit la réplication à la fois des métadonnées et des données.

Ces fonctionnalités ne doivent pas être confondues avec les Zones de disponibilité. Les deux fonctionnalités de récupération géographique offrent une résilience entre les régions Azure telles que USA Est et USA Ouest. La prise en charge des zones de disponibilité offre une résilience au sein d’une région géographique spécifique, par exemple USA Est. Pour plus d’informations sur les Zones de disponibilité, consultez Prise en charge des Zones de disponibilité Event Hubs.

Important

• Cette fonctionnalité est actuellement en préversion publique, et ne doit pas être utilisée dans les scénarios de production.
• Les régions suivantes sont actuellement prises en charge dans la préversion publique.

États-Unis	Europe
EUAP USA Centre	Italie Nord
	Espagne Centre
	Norvège Est

Récupération d’urgence des métadonnées ou géoréplication des métadonnées et des données

La fonctionnalité de récupération d’urgence des métadonnées réplique les informations de configuration d’un espace de noms d’un espace de noms principal vers un espace de noms secondaire. Il prend en charge un basculement unique vers la région secondaire. Pendant le basculement lancé par le client, le nom d’alias de l’espace de noms est repointé vers l’espace de noms secondaire, puis le jumelage est rompu. Aucune donnée n’est répliquée hormis les informations de configuration et les attributions d’autorisations ne sont pas répliquées.

La fonctionnalité plus récente de géoréplication réplique les informations de configuration et toutes les données d’un espace de noms principal vers un ou plusieurs espaces de noms secondaires. Lorsqu’un basculement est effectué, le secondaire sélectionné devient le principal et le serveur principal précédent devient secondaire. Les utilisateurs peuvent effectuer un basculement vers le serveur principal d’origine lorsque vous le souhaitez.

Le reste de cet article est axé sur la fonctionnalité de géoréplication. Pour plus d’informations sur la fonctionnalité de récupération d’urgence des métadonnées, consultez Géo-reprise d’activité après sinistre Event Hubs pour les métadonnées.

Géoréplication

La préversion publique de la fonctionnalité de géoréplication est prise en charge pour les espaces de noms dans les clusters dédiés à la mise à l’échelle en libre-service Event Hubs. Vous pouvez utiliser la fonctionnalité avec des espaces de noms nouveaux ou existants dans des clusters libre-service dédiés. Les fonctionnalités suivantes ne sont pas prises en charge avec la géoréplication :

• Clés gérées par le client (CMK)
• Identité managée pour capture
• Fonctionnalités de réseau virtuel (points de terminaison de service ou privés)
• Prise en charge des messages volumineux (désormais en préversion publique)
• Transactions Kafka (désormais en préversion publique)

Voici quelques-uns des principaux aspects de la préversion publique de la 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 de domaine complet (FQDN) stable de l’espace de noms : le nom de domaine complet n’a pas besoin de changer lors d’une promotion.
• Cohérence de la réplication : il existe deux paramètres de cohérence de réplication, synchrones et asynchrones.
• Promotion gérée par l’utilisateur d’un secondaire pour qu’il soit le nouveau principal.

La modification d’une base de données secondaire en une nouvelle base de données principale est effectuée de deux façons :

• Planifié : promotion de la base de données secondaire qui devient la principale où le trafic n’est pas traité tant que la nouvelle base de données principale n’a pas rattrapé toutes les données détenues par l’ancienne instance principale.
• Forcé : basculement où la base de données secondaire devient principale aussi rapidement que possible. La fonctionnalité de géoréplication réplique toutes les données et métadonnées de la région principale vers les régions secondaires sélectionnées. Le nom de domaine complet de l’espace de noms pointe toujours vers la région principale.

Lorsque vous initiez une promotion d’une région secondaire, le nom de domaine complet pointe vers la région sélectionnée comme devant être la nouvelle principale. L’ancien principal devient alors secondaire. Vous pouvez promouvoir votre secondaire comme nouveau principal pour des raisons autres qu’un basculement. Ces raisons peuvent inclure des mises à niveau d’application, des tests de basculement ou un certain nombre d’autres actions. Dans ces situations, il est courant de revenir en arrière lorsque ces activités sont terminées.

Les régions secondaires sont ajoutées ou supprimées à la discrétion du client. Il existe certaines limitations actuelles à noter :

• Il n’est pas possible de prendre en charge les vues en lecture seule sur les régions secondaires.
• Il n’existe aucune fonctionnalité de promotion/basculement automatique. Toutes les promotions sont initiées par le client.
• Les régions secondaires doivent être différentes de la région principale. Vous ne pouvez pas sélectionner un autre cluster dédié dans la même région.
• Un seul secondaire est pris en charge pour la préversion publique.

Cohérence de la 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

Une fois la réplication asynchrone activée, tous les messages sont validés dans le principal, puis envoyés au secondaire. Les utilisateurs peuvent configurer une durée acceptable de décalage pour permettre le rattrapage du secondaire. Lorsque le décalage d’une base de données secondaire active est supérieur à la configuration du décalage utilisateur, la région principale limite les demandes de publication entrantes.

Réplication synchrone

Lorsque la réplication synchrone est activée, les événements publiés sont répliqués vers la base de données secondaire, ce qui doit confirmer le message avant qu’il ne soit validé dans le principal. Avec la réplication synchrone, votre application publie à la vitesse nécessaire pour publier, répliquer, reconnaître et valider. Cela signifie également que votre application est liée à la disponibilité des deux régions. Si la région secondaire tombe en panne, les messages ne peuvent pas être reconnus ou validés.

Comparaison de la cohérence de réplication

Avec la réplication synchrone :

• La latence est plus longue en raison de la validation distribuée.
• 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.
• Les données reçues résident toujours dans au moins deux régions (seules deux régions prises en charge dans la préversion publique initiale).

La réplication synchrone offre la plus grande assurance que vos données sont sécurisées. Si vous disposez d’une réplication synchrone, quand elles sont validées, elles le sont dans toutes les régions configurées pour la géoréplication. Lorsque la réplication synchrone est activée, la disponibilité de votre application peut être réduite en fonction de la disponibilité des deux régions.

L’activation de la réplication asynchrone n’affecte pas beaucoup la latence, et la disponibilité du service n’est pas affectée par la perte d’une région secondaire. La réplication asynchrone n’a pas la garantie absolue que toutes les régions ont les données avant leur validation comme la réplication synchrone. Vous pouvez également définir la durée pendant laquelle votre secondaire peut être désynchronisé avant la limitation du trafic entrant. Le paramètre peut être de 5 minutes à 1 440 minutes, soit un jour. Si vous envisagez d’utiliser des régions avec une grande distance entre elles, la réplication asynchrone est probablement la meilleure option pour vous.

La configuration de cohérence de la réplication peut changer après la configuration de la géoréplication. Vous pouvez passer de synchrone à asynchrone, ou d’asynchrone à synchrone. Si vous passez de synchrone à asynchrone, votre latence et la disponibilité de l’application s’améliore. Si vous passez d’asynchrone à synchrone, votre région secondaire devient 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 probablement suspendre vos serveurs de publication afin que le décalage atteigne zéro et que le mode puisse basculer en mode synchrone.

Les raisons générales pour lesquelles la réplication synchrone est activée sont liées à l’importance des données, des besoins métier spécifiques ou des raisons de conformité. Si votre objectif principal est la disponibilité des applications plutôt que l’assurance des données, la cohérence asynchrone est probablement la meilleure solution.

Sélection de la région secondaire

Pour activer la fonctionnalité de géoréplication, vous devez utiliser une région principale et secondaire dans laquelle la fonctionnalité de géoréplication est activée. Vous devez également disposer d’un cluster Event Hubs existant dans les régions principale et secondaires.

La fonctionnalité de géoréplication dépend de la capacité à répliquer les événements publiés de la région principale 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 principale vers la région secondaire. Si vous utilisez la géoréplication pour des raisons de disponibilité et de fiabilité, 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 Statistiques de latence aller-retour du réseau Azure | Microsoft Learn.

Gestion de la géoréplication

La fonctionnalité de géoréplication vous permet de configurer une région secondaire pour y répliquer la configuration et les données. Vous pouvez :

• Configurer la géoréplication : Les régions secondaires peuvent être configurées sur n’importe quel espace de noms existant dans un cluster dédié libre-service dans une région avec le jeu de fonctionnalités de géoréplication activé. Il peut également être configuré lors de la création de l’espace de noms sur les mêmes clusters dédiés. Pour sélectionner une région secondaire, vous devez disposer d’un cluster dédié disponible dans cette région secondaire et la région secondaire doit également avoir le jeu de fonctionnalités de géoréplication activé pour cette région.
• 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, et passer de l’une à l’autre par la suite. Avec une cohérence asynchrone, vous pouvez configurer la durée pendant laquelle une région secondaire est autorisée à présenter un décalage.
• Déclencher la promotion/le basculement : Toutes les promotions ou tous les basculements sont initiés par le client. Pendant la promotion, vous pouvez choisir de la forcer dès le début, ou même changer d’avis et définir une promotion comme forcée une fois qu’elle a commencé.
• Supprimer une base de données secondaire : Si vous souhaitez supprimer le géo-jumelage entre les régions principale et secondaires, vous pouvez le faire et les données de la région secondaire seront supprimées.

Surveillance 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 d’événements peuvent publier des données dans des espaces de noms géorépliqués via un nom de domaine complet d’espace de noms stable de l’espace de noms géorépliqué. L’approche de publication d’événements est identique au cas de récupération d’urgence non géographique et aucune modification des applications clientes n’est requise.

La publication d’événements risque de ne pas être disponible dans les circonstances suivantes :

• Pendant la période de grâce du basculement, la région principale existante rejette les nouveaux événements publiés dans l’Event Hub.
• 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 consommatrices d’événements peuvent consommer des données en utilisant le nom de domaine complet stable d’un espace de noms géorépliqué. Les opérations consommatrices ne sont pas prises en charge, à partir du moment où le basculement est lancé tant qu’il n’est pas terminé.

Gestion des points de contrôle/décalage

Les applications consommatrices d’événements peuvent continuer à gérer les décalages, car elles le feraient avec un espace de noms unique.

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.

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

Les clients qui utilisent le Kit de développement logiciel (SDK) Event Hubs doivent effectuer une mise à niveau vers la version d’avril 2024 du SDK. La dernière version du Kit de développement logiciel (SDK) Event Hubs prend en charge le basculement avec une mise à jour du point de contrôle. 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.

Tarification

Les clusters Event Hubs dédiés sont facturés indépendamment de la géoréplication. 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. Les clusters dédiés utilisés comme instances secondaires pour la géoréplication peuvent être utilisés pour d’autres charges de travail. La géoréplication est facturée sur la base de la bande passante publiée x le nombre de régions secondaires. Les frais de géoréplication sont annulés en préversion publique anticipée.

Contenu connexe

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