Fiabilité dans Azure Event Hubs

Azure Event Hubs est un service cloud natif qui peut diffuser des millions d’événements par seconde avec une faible latence, de n’importe quelle source à n’importe quelle destination. Utilisez Event Hubs pour ingérer et stocker des données de diffusion en continu et les intégrer aux applications clientes conçues pour Apache Kafka ou les applications qui utilisent les kits SDK clients Event Hubs.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment Event Hubs est résilient à une variété de pannes et de problèmes potentiels, et comment vous pouvez le configurer pour qu’il soit résilient à d’autres, notamment les pannes temporaires, les pannes de zone de disponibilité et les pannes de région. Il décrit également les options de sauvegarde et de récupération, et met en évidence certaines informations clés sur le contrat de niveau de service Azure Event Hubs (SLA).

Recommandations concernant le déploiement de production

Pour savoir comment déployer Event Hubs pour prendre en charge les exigences de fiabilité de votre solution et comprendre comment la fiabilité affecte d’autres aspects de votre architecture, consultez les meilleures pratiques d’architecture pour Event Hubs dans Azure Well-Architected Framework.

Vue d’ensemble de l’architecture de fiabilité

Cette section décrit des aspects importants sur le fonctionnement d’Event Hubs du point de vue de la fiabilité. Il introduit l’architecture logique, qui inclut les ressources et les fonctionnalités que vous déployez et utilisez. Il explique également l’architecture physique, qui fournit des détails sur la façon dont le service gère les opérations en interne.

Architecture logique

Un espace de noms Event Hubs sert de conteneur de gestion pour un ou plusieurs hubs d’événements. Vous configurez le service, comme l’allocation de la capacité de diffusion en continu, la configuration de la sécurité réseau et l’activation de la géoréplication et de la récupération d’urgence au niveau de l’espace de noms.

Dans un espace de noms, vous pouvez organiser des événements dans un hub d’événements. L’écosystème Apache® Kafka fait référence à ce type d’entité en tant que rubrique. Le hub d’événements ou la rubrique est un journal distribué d’ajout uniquement de vos événements.

Chaque hub d’événements contient une ou plusieurs partitions, qui sont des journaux d’événements séquentiels. Un hub d’événements peut utiliser plusieurs partitions pour effectuer un traitement parallèle et une mise à l’échelle horizontale. Event Hubs garantit uniquement l’ordre dans une seule partition. Le partitionnement joue un rôle clé dans la conception de fiabilité de votre application. Lorsque vous concevez votre application, faites un compromis entre optimiser la disponibilité et la cohérence. Pour optimiser le temps de fonctionnement de la plupart des applications, évitez d’adresser des partitions directement à partir de vos applications clientes. Pour plus d’informations, consultez Disponibilité et cohérence dans Event Hubs.

Les consommateurs qui lisent à partir du hub d’événements peuvent lire leurs événements de manière séquentielle en conservant leur propre point de contrôle, qui identifie le dernier événement qu’ils reçoivent.

Pour plus d’informations sur les partitions et d’autres concepts fondamentaux dans Event Hubs, consultez Fonctionnalités et terminologie dans Event Hubs.

Architecture physique

Dans l’architecture physique, un espace de noms Event Hubs s’exécute dans un cluster. Un cluster fournit les ressources de calcul et de stockage sous-jacentes. La plupart des espaces de noms s’exécutent sur des clusters que les autres clients Azure partagent. Lorsque vous utilisez le niveau Premium, l’espace de noms est alloué aux ressources dédiées au sein d’un cluster partagé. Lorsque vous utilisez le niveau Dédié, un cluster est dédié à vos espaces de noms. Pour plus d’informations sur les clusters dédiés, consultez la vue d’ensemble du niveau Dédié Event Hubs. Quel que soit le type de niveau et de cluster, Microsoft gère les clusters et leurs machines virtuelles et leur stockage sous-jacents.

Pour obtenir une redondance, chaque cluster a plusieurs réplicas qui traitent les demandes de lecture et d’écriture. Pour optimiser la haute disponibilité et les performances, toutes les données sont stockées sur trois réplicas de stockage. Pour mettre à l’échelle les ressources de calcul de votre espace de noms, déployez des unités de débit (TU), des unités de traitement (UNITÉS) ou des unités de capacité (UC), en fonction du niveau. Pour plus d’informations, consultez Mise à l’échelle avec Event Hubs.

Les clusters s’étendent sur plusieurs machines physiques et racks, ce qui réduit le risque de défaillances irrécupérables affectant votre espace de noms. Dans les régions qui ont des zones de disponibilité, les clusters s’étendent sur des centres de données physiques distincts. Pour plus d’informations, consultez Résilience aux échecs de zone de disponibilité.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

Event Hubs implémente des mécanismes transparents de détection des défaillances et de basculement afin que le service continue à fonctionner au sein des niveaux de service assurés, généralement sans interruptions notables lorsque des défaillances se produisent.

Lorsque vous concevez des applications clientes pour qu’elles fonctionnent avec Event Hubs, suivez ces instructions :

• Utilisez des stratégies de nouvelle tentative intégrées. Les SDK Event Hubs et Apache Kafka réessaient automatiquement les opérations pour les erreurs qui peuvent être réessayées, comme les délais d’expiration du réseau, les réponses de limitation ou lorsque le serveur est occupé. Pour éviter de surcharger inutilement le service, ils implémentent l’interruption exponentielle par défaut.

• Configurez les valeurs de délai d’expiration appropriées en fonction des exigences de votre application. Le délai d’expiration par défaut est généralement de 60 secondes, mais vous pouvez l’ajuster en fonction de votre scénario.

• Implémentez des points de contrôle dans votre processeur d’événements pour suivre la progression et activer la récupération à partir de la dernière position traitée après des échecs temporaires.

• Utilisez le traitement par lots pour les opérations d’envoi afin d’améliorer le débit et de réduire l’impact des problèmes réseau temporaires sur des messages individuels.

• Utilisez des kits SDK Apache Kafka si vous utilisez le protocole Kafka. Les sdk Kafka implémentent également des stratégies de nouvelle tentative et d’autres bonnes pratiques qui aident à gérer les erreurs temporaires.

Résilience aux échecs de zone de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Event Hubs prend en charge les déploiements redondants interzones dans tous les niveaux de service. Lorsque vous créez un espace de noms Event Hubs dans une région prise en charge, la redondance de zone est automatiquement activée sans frais supplémentaires. Toutefois, avec le niveau Dédié, les zones de disponibilité ne sont prises en charge qu’avec trois unités de calcul au minimum. Le modèle de déploiement redondant interzone s’applique à toutes les fonctionnalités Event Hubs, notamment capture, Registre de schémas et prise en charge du protocole Kafka.

Event Hubs réplique en toute transparence vos données de configuration, de métadonnées et d’événements dans trois zones de disponibilité de la région. La redondance de zone fournit un basculement automatique sans votre intervention. Tous les composants Event Hubs, y compris le calcul, la mise en réseau et le stockage, sont répliqués entre les zones. Event Hubs dispose de réserves de capacité suffisantes pour gérer instantanément la perte complète d’une zone. Même si une zone de disponibilité entière devient indisponible, Event Hubs continue de fonctionner sans perte de données ni interruption des applications de diffusion en continu.

Le diagramme montre un cluster Event Hubs distribué sur trois zones de disponibilité. Chaque zone contient un espace de noms partagé, et le cluster s’étend sur toutes les zones pour fournir une haute disponibilité.

Soutien régional

Les espaces de noms Event Hubs redondants interzone peuvent être déployés dans n’importe quelle région Azure qui prend en charge les zones de disponibilité.

Spécifications

• Les niveaux Standard et Premium prennent en charge les zones de disponibilité sans configuration supplémentaire requise.

• Pour le niveau Dédié, les zones de disponibilité nécessitent trois unités de calcul au minimum.

Coûts

La redondance de zone dans Event Hubs n’ajoute pas de coût supplémentaire.

Configurez la prise en charge des zones de disponibilité

Les espaces de noms Event Hubs prennent automatiquement en charge la redondance de zone lors du déploiement dans les régions prises en charge. Aucune configuration supplémentaire n'est nécessaire.

Comportement lorsque toutes les zones sont saines

Lorsque les espaces de noms Event Hubs utilisent la redondance de zone et que toutes les zones de disponibilité fonctionnent normalement, attendez-vous au comportement suivant :

• Routage du trafic entre les zones : Event Hubs fonctionne dans un modèle actif-actif où l’infrastructure dans trois zones de disponibilité traite simultanément les événements entrants.

• Réplication des données entre les zones : Event Hubs utilise la réplication synchrone entre les zones de disponibilité. Lorsqu’un producteur d’événements envoie un événement, Event Hubs l’écrit sur des réplicas situés dans plusieurs zones avant de confirmer au client que l’opération d’écriture est terminée. Cette approche garantit une perte de données nulle, même si une zone entière devient indisponible. L’approche de réplication synchrone offre des garanties de cohérence fortes tout en conservant une faible latence via des protocoles de réplication optimisés.

Comportement lors d’une défaillance de zone

Lorsque les espaces de noms Event Hubs utilisent la redondance de zone et qu’une panne de zone de disponibilité se produit, attendez-vous au comportement suivant :

• Détection et réponse : Event Hubs est responsable de la détection automatique d’un échec dans une zone de disponibilité. Vous n’avez pas besoin de lancer un basculement de zone.

• Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

• Demandes actives : Lors d’une défaillance de zone, Event Hubs peut supprimer des demandes actives. Si vos clients gèrent les erreurs temporaires de manière appropriée en réessayant après une courte période de temps, ils évitent généralement un impact significatif.

• Perte de données attendue : Aucune perte de données ne se produit lors d’une défaillance de zone, car Event Hubs réplique les événements entre les zones de façon synchrone avant de confirmer leur réception.

• Temps d’arrêt attendu : Une défaillance de zone peut entraîner quelques secondes de temps d’arrêt. Si vos clients gèrent les erreurs temporaires de manière appropriée en réessayant après une courte période de temps, ils évitent généralement un impact significatif.

• Réacheminement du trafic : Event Hubs détecte la perte de la zone et redirige automatiquement les nouvelles demandes vers un autre réplica dans l’une des zones de disponibilité saines.

  Les kits SDK clients Event Hubs gèrent généralement la gestion des connexions et la logique de nouvelle tentative de manière transparente.

Récupération de la zone

Lorsqu’une zone de disponibilité récupère, Event Hubs réinscrit automatiquement la zone dans la topologie de service active. La zone récupérée commence à accepter de nouvelles connexions et à traiter des événements en même temps que les autres zones. Les données qui avaient été répliquées dans des zones survivantes pendant la panne restent intactes et la réplication synchrone normale reprend dans toutes les zones. Vous n’avez pas besoin de prendre des mesures pour la récupération et la réintégration des zones.

Tester les pannes de zone

Event Hubs gère le routage du trafic, le basculement et la récupération en cas de défaillance de zone, vous n’avez donc pas besoin de valider les processus liés aux défaillances des zones de disponibilité ni de fournir d’autres informations.

Résilience aux défaillances à l’échelle de la région

Event Hubs fournit deux types de prise en charge multirégion :

• La géoréplication (niveaux Premium et Dédié) fournit une réplication active des métadonnées et des données d’événement entre une région primaire et une ou plusieurs régions secondaires. Utilisez la géoréplication pour la plupart des applications qui doivent rester résilientes aux pannes de région et qui ont une faible tolérance pour la perte de données d’événement.

• La géorécupération d’urgence des métadonnées (niveau Standard et supérieur) fournit une réplication passive active de la configuration et des métadonnées entre une région primaire et secondaire, mais elle ne réplique pas les données d’événement. Utilisez la géorécupération d’urgence pour les applications qui peuvent tolérer une perte de données d’événement pendant un scénario de sinistre et qui doivent reprendre rapidement les opérations dans une autre région.

La géoréplication et la géo-reprise d’activité après sinistre des métadonnées vous obligent à lancer manuellement le basculement ou la promotion d’une région secondaire pour qu’elle devienne la nouvelle région principale. Microsoft n’effectue pas automatiquement de basculement ou de promotion à votre place, même si votre région principale est en panne.

Géoréplication

Les niveaux Premium et Dédié prennent en charge la géoréplication. Cette fonctionnalité réplique les métadonnées (telles que les entités, la configuration et les propriétés) et les données (telles que les charges utiles d’événement) de l’espace de noms. Vous configurez l’approche de réplication pour les données de configuration et d’événement de votre espace de noms. Cette fonctionnalité garantit que vos événements restent disponibles dans une autre région et vous permettent de basculer vers la région secondaire si nécessaire. Il réplique également les métadonnées et les données du registre de schémas.

Utilisez la géoréplication pour les scénarios qui nécessitent une résilience aux pannes de région et qui ont une faible tolérance pour la perte de données d’événement.

L’espace de noms s’étend essentiellement à travers les régions. Une région sert de serveur principal, et les autres régions servent de secondaires. Votre abonnement Azure affiche un espace de noms unique, quel que soit le nombre de régions secondaires que vous configurez pour la géoréplication.

À tout moment, vous pouvez promouvoir une région secondaire vers une région primaire. Lorsque vous promouvez une région secondaire, Event Hubs repointe le nom de domaine complet de l’espace de noms (FQDN) vers la région secondaire sélectionnée et rétrograde la région primaire précédente vers une région secondaire. Vous décidez d’effectuer une promotion planifiée, ce qui signifie que vous attendez la fin de la réplication des données ou une promotion forcée, ce qui peut entraîner une perte de données.

Note

La géoréplication Event Hubs utilise le terme promotion, car il représente au mieux le processus de promotion d’une région secondaire à une région primaire (et de rétrogradation ultérieure d’une région primaire à une région secondaire). Vous pouvez également voir le terme basculement utilisé pour décrire le processus global.

Cette section récapitule les aspects importants de la géoréplication. Passez en revue la documentation complète pour comprendre exactement son fonctionnement. Pour plus d’informations, consultez Event Hubs géoréplication.

Soutien régional

Vous pouvez choisir n’importe quelle région Azure qui prend en charge Event Hubs comme région principale ou régions secondaires. Vous n’avez pas besoin d’utiliser des régions jumelées Azure. Vous pouvez donc choisir des régions secondaires en fonction de vos exigences de latence, de conformité ou de résidence des données.

Spécifications

Pour activer la géoréplication, votre espace de noms doit utiliser le niveau Premium ou Dédié.

Considérations

Lorsque vous activez la géoréplication, tenez compte des facteurs suivants :

• Format de point de contrôle : Le format des points de contrôle change. Pour plus d’informations, consultez Géoréplication : Consommation de données.

• Points de terminaison privés : Si vous utilisez des points de terminaison privés pour vous connecter à votre espace de noms, vous devez également configurer la mise en réseau dans vos régions primaires et secondaires. Pour plus d’informations, consultez Points de terminaison privés.

Coûts

Pour comprendre le fonctionnement des tarifs pour la géoréplication, consultez Tarification.

Configurer la prise en charge multirégion

• Activez la géoréplication sur un espace de noms nouveau ou existant. Pour configurer la réplication active-active pour un espace de noms nouvellement créé, consultez Activer la géoréplication sur un nouvel espace de noms. Pour configurer la réplication active active sur un espace de noms existant, consultez Activer la géoréplication sur un espace de noms existant.

• Modifiez l’approche de réplication. Pour changer entre les modes de réplication synchrone et asynchrone, consultez Modification du mode de réplication.

• Désactiver la géo-réplication. Pour désactiver la géoréplication vers une région secondaire, consultez Supprimer une région secondaire.

Comportement lorsque toutes les régions sont saines

Cette section décrit ce qu’il faut attendre lorsqu’un espace de noms Event Hubs est configuré pour la géoréplication et que la région primaire est opérationnelle.

• Routage du trafic entre les régions : Les applications clientes se connectent via le nom de domaine complet de votre espace de noms et leurs itinéraires de trafic vers la région primaire.

  Seule la région primaire traite activement les événements des clients pendant les opérations normales. La région secondaire reçoit des événements répliqués, mais reste autrement passive en mode veille.

• Réplication des données entre les régions : Le comportement de réplication des données entre les régions primaires et secondaires dépend de la configuration de votre jumelage de réplication pour utiliser la réplication synchrone ou asynchrone.

  • Synchrone: Les événements sont répliqués dans la région secondaire avant la fin de l’opération d’écriture.

    Ce mode offre la plus grande assurance que vos données d’événement sont sécurisées, car elles doivent être validées dans la région primaire et secondaire. Toutefois, la réplication synchrone augmente considérablement la latence d’écriture pour les événements entrants. Il exige également que la région secondaire soit disponible pour accepter l’opération d’écriture. Par conséquent, une panne dans n’importe quelle région secondaire entraîne l’échec de l’opération d’écriture.

    • Asynchrone: Les événements sont écrits dans la région primaire, puis l’opération d’écriture se termine. Un peu plus tard, il réplique les événements dans la région secondaire.

    Ce mode fournit un débit d’écriture plus élevé que la réplication synchrone, car il n’y a pas de latence de réplication interrégion pendant les opérations d’écriture. En outre, le mode de réplication asynchrone peut tolérer la perte d’une région secondaire tout en autorisant les opérations d’écriture dans la région primaire. Toutefois, si la région primaire a une panne, toutes les données qui n’ont pas encore été répliquées dans la région secondaire peuvent être indisponibles ou perdues.

    Lorsque vous configurez une réplication asynchrone, vous définissez le délai maximal acceptable pour la réplication. À tout moment, vous pouvez vérifier le décalage de réplication actuel à l’aide des métriques Azure Monitor.

    Si le décalage de réplication asynchrone augmente au-delà du maximum que vous spécifiez, la région primaire commence à limiter les requêtes entrantes afin que la réplication puisse rattraper le retard. Pour éviter cette situation, il est important de sélectionner des régions secondaires qui ne sont pas trop éloignées géographiquement et de s’assurer que votre capacité est suffisante pour le débit.

    Pour plus d’informations, consultez les modes de réplication.

Comportement lors d’une défaillance de région

Cette section décrit ce qu’il faut attendre lorsqu’un espace de noms Event Hubs est configuré pour la géoréplication et qu’il existe une panne dans la région primaire ou secondaire.

• Détection et réponse : Vous êtes chargé de décider quand promouvoir la région secondaire de votre espace de noms pour devenir la nouvelle région primaire. Microsoft ne prend pas cette décision et ne lance pas le processus pour vous, même en cas de panne régionale. Pour plus d’informations sur la promotion d'une région secondaire au statut de région primaire, consultez Promouvoir une région secondaire.

  Lorsque vous promouvez une région secondaire, choisissez s’il faut effectuer une promotion planifiée ou une promotion forcée. Une promotion planifiée attend que la région secondaire ait rattrapé son retard avant d’accepter du nouveau trafic. Cette approche élimine la perte de données, mais introduit des temps d’arrêt.

  Lors d’une panne dans la région primaire, vous devez généralement effectuer une promotion forcée. Si la région primaire est disponible et que vous déclenchez une promotion pour une autre raison, vous pouvez choisir une promotion planifiée.

• Notification: Microsoft ne vous avertit pas automatiquement lorsqu’une région est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de région, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

  Utilisez ces informations et d’autres métriques pour décider quand promouvoir une région secondaire vers une région primaire.

• Demandes actives : Le comportement dépend de la panne de la région dans la région primaire ou dans une région secondaire :

  • Panne de région primaire : Si la région primaire n’est pas disponible, toutes les demandes actives sont arrêtées. Les applications clientes doivent réessayer une fois la promotion terminée.

  • Panne de région secondaire : Une panne dans la région secondaire peut entraîner des problèmes pour les requêtes actives dans les situations suivantes :

    • Si vous utilisez le mode de réplication synchrone, la région primaire ne peut pas effectuer d’opérations d’écriture si une région secondaire n’est pas disponible.

    • Si vous utilisez le mode de réplication asynchrone, votre espace de noms limite et n’accepte pas de nouveaux événements une fois que le décalage de réplication atteint le maximum que vous configurez.

    Pour continuer à utiliser l’espace de noms dans la région primaire, supprimez l’espace de noms secondaire de votre configuration de géoréplication.

• Perte de données attendue : La quantité de perte de données dépend du type de promotion que vous effectuez (planifiée ou forcée) et du mode de réplication (synchrone ou asynchrone) :

  • Promotion planifiée : Aucune perte de données n’est attendue. Toutefois, lors d’une panne de région, une promotion planifiée peut ne pas être possible, car toutes les régions primaires et secondaires doivent être disponibles.

  • Promotion forcée, réplication synchrone : Aucune perte de données n’est attendue.

  • Promotion forcée, réplication asynchrone : Vous pouvez rencontrer une perte de données pour les événements récents qui ne sont pas répliqués dans la région secondaire. La quantité dépend du décalage de réplication. Pour vérifier le décalage de réplication actuel, utilisez les métriques Azure Monitor.

  Si vous effectuez une promotion forcée, vous ne pouvez pas récupérer les données perdues, même après la mise à disposition de la région primaire.

• Temps d’arrêt attendu : Le temps d’arrêt attendu dépend de l’exécution d’une promotion planifiée ou forcée :

  • Promotion planifiée : La première étape d’une promotion planifiée réplique les données dans la région secondaire. Ce processus se termine généralement rapidement, mais dans certaines situations, il peut prendre jusqu'à la durée de la latence de réplication. Une fois la réplication terminée, le processus de promotion prend généralement environ 5 à 10 minutes. Il peut parfois prendre plus de temps pour que les serveurs DNS (Domain Name System) mettent à jour les entrées et répliquent entièrement leurs enregistrements sur les clients.

    La région primaire n’accepte pas les opérations d’écriture pendant l’ensemble du processus de promotion.

    Cette option peut ne pas être possible lors d’une panne de région, car elle nécessite que toutes les régions primaires et secondaires soient disponibles.

  • Promotion forcée : Pendant une promotion forcée, Event Hubs n’attend pas la fin de la réplication des données et lance immédiatement la promotion. Le processus de promotion prend généralement environ 5 à 10 minutes. Il peut parfois être plus long que les entrées DNS soient entièrement répliquées et mises à jour sur les clients.

    La région primaire n’accepte pas les opérations d’écriture pendant l’ensemble du processus de promotion.

• Réacheminement du trafic : Lorsque la promotion est terminée, le FQDN de l’espace de noms pointe vers la nouvelle région primaire. Toutefois, cette redirection dépend de la rapidité avec laquelle les enregistrements DNS des clients sont mis à jour, notamment pour que leurs serveurs DNS respectent la durée de vie des enregistrements DNS de l’espace de noms.

  Dans certains cas, vous devez configurer des applications grand public pour qu’elles se comportent de manière cohérente après la promotion de région. Pour plus d’informations, consultez Géoréplication : Consommation de données.

Récupération de région

Une fois la région primaire d’origine récupérée, si vous souhaitez renvoyer l’espace de noms à sa région primaire d’origine, suivez le même processus de promotion de région.

Si vous avez effectué une promotion forcée pendant la panne de la région, vous ne pouvez pas récupérer les données perdues, même après la disponibilité de la région primaire.

Tester les défaillances régionales

Pour tester la géoréplication, promouvez temporairement la région secondaire en région primaire et vérifiez que vos applications clientes peuvent basculer entre les régions avec une interruption minimale.

Surveillez la durée de la promotion et vérifiez que vos runbooks et l'automatisation fonctionnent de manière optimale. Après le test, vous pouvez revenir à la configuration d'origine.

Comprendre le temps d’arrêt potentiel et la perte de données que vous pouvez rencontrer pendant et après le processus de promotion. Testez la géoréplication dans un environnement hors production qui reflète la configuration de votre espace de noms de production.

Géo-reprise d’activité après sinistre des métadonnées

Le niveau Standard et les versions ultérieures prennent en charge la géo-sauvegarde d'urgence des métadonnées. Cette fonctionnalité améliore la récupération à partir de scénarios d’urgence, notamment la perte catastrophique d’une région. La géorécupération d’urgence réplique uniquement la configuration et les métadonnées de votre espace de noms. Toutefois, elle ne réplique pas les données d’événement. Pour prendre en charge la récupération d’urgence, cette fonctionnalité garantit qu’un espace de noms dans une autre région est préconfiguré et prêt à accepter immédiatement les événements des clients. La géo-reprise d’activité après sinistre sert de solution de récupération unidirectionnelle et ne prend pas en charge la restauration automatique vers la région principale précédente.

La géo-récupération d’urgence des métadonnées fonctionne mieux pour les applications qui n’ont pas strictement besoin de maintenir chaque événement et peuvent tolérer une perte de données pendant un scénario de sinistre. Par exemple, si vos événements représentent des lectures de capteur que vous agrégez ultérieurement, vous pouvez décider de perdre certains événements d’une région ayant échoué si vous pouvez reprendre rapidement le traitement de nouveaux événements dans une autre région.

Important

La géorécupération d’urgence permet la continuité des opérations qui ont la même configuration, mais qui ne répliquent pas les données d’événement. Si vous devez répliquer des données d’événement, envisagez d’utiliser la géoréplication.

Lorsque vous configurez la géo-récupération d’urgence des métadonnées, vous créez un alias auquel les applications clientes se connectent. Par défaut, l'alias est un nom de domaine pleinement qualifié qui redirige tout le trafic vers l'espace de noms principal.

Si la région primaire échoue ou si un autre type de sinistre se produit, vous pouvez lancer manuellement un basculement unidirectionnel de la région primaire vers la région secondaire à tout moment. Le basculement se termine presque instantanément. Pendant le processus de basculement, l’alias de géo-reprise d’activité après sinistre pointe à nouveau vers l’espace de noms secondaire et le jumelage est supprimé.

Cette section récapitule les aspects importants de la géo-reprise d’activité après sinistre. Passez en revue la documentation complète pour comprendre exactement son fonctionnement. Pour découvrir plus d’informations, consultez Géo-reprise d’activité après sinistre Event Hubs.

Soutien régional

Vous pouvez sélectionner n’importe quelle région Azure qui prend en charge Event Hubs comme espace de noms principal ou secondaire. Vous n’avez pas besoin d’utiliser des régions jumelées Azure. Vous pouvez donc choisir des régions secondaires en fonction de vos exigences de latence, de conformité ou de résidence des données.

Spécifications

• Niveau d’espace de noms principal : Votre espace de noms principal doit se trouver dans le niveau Standard ou supérieur pour utiliser la géo-récupération d’urgence des métadonnées.

• Niveau d’espace de noms secondaire : La géorécupération d’urgence des métadonnées prend en charge des combinaisons spécifiques de niveaux pour les espaces de noms principaux et secondaires. Pour plus d’informations, consultez Paires d’espaces de noms prises en charge.

Considérations

• Attributions de rôles : Les attributions de contrôle d’accès en fonction du rôle (RBAC) Microsoft Entra aux entités de l’espace de noms principal ne sont pas répliquées vers l’espace de noms secondaire. Créez manuellement des attributions de rôles dans l’espace de noms secondaire pour sécuriser leur accès.

• Registre de schémas : Les métadonnées du Registre de schémas sont répliquées lorsque vous utilisez la géo-récupération d’urgence des métadonnées, mais les schémas inscrits auprès du registre de schémas ne sont pas répliqués.

• Conception d'applications : La récupération après sinistre géographique nécessite des considérations spécifiques lors de la conception de vos applications clientes. Pour plus d’informations, consultez Considérations.

• Points de terminaison privés : Si vous utilisez des points de terminaison privés pour vous connecter à votre espace de noms, configurez la mise en réseau dans votre région primaire et secondaire. Pour plus d’informations, consultez Points de terminaison privés.

Coûts

Lorsque vous activez la géo-récupération d’urgence des métadonnées, vous payez à la fois pour les espaces de noms principaux et secondaires.

Configurer la prise en charge multirégion

• Créez un jumelage de géo-reprise d’activité après sinistre des métadonnées. Pour configurer la récupération d’urgence entre les espaces de noms principal et secondaire, consultez Flux de configuration et de basculement.

• Désactivez la reprise après sinistre géographique des métadonnées. Pour interrompre le jumelage entre les espaces de noms, consultez Flux de configuration et de basculement.

Planification de capacité et gestion

Lorsque vous planifiez des déploiements multirégions, assurez-vous que les deux régions disposent d’une capacité suffisante pour gérer la charge complète en cas d’échec d’une région. Lors d’opérations normales, la région secondaire reste passive, mais elle doit immédiatement gérer le trafic après le basculement. Planifiez la mise à l’échelle de la capacité d’espace de noms secondaire afin qu’elle puisse recevoir le trafic de production sans délai. Si vous pouvez tolérer un temps d’arrêt supplémentaire pendant le processus de basculement, vous pouvez choisir d’ajuster la capacité de l’espace de noms secondaire pendant ou après le basculement. Pour réduire les temps d’arrêt, provisionnez la capacité dans l’espace de noms secondaire à l’avance afin qu’elle reste prête à recevoir la charge de production.

Comportement lorsque toutes les régions sont saines

Cette section décrit ce qu’il faut attendre lorsqu’un espace de noms Event Hubs est configuré pour la géo-reprise d’activité après sinistre et que la région primaire est opérationnelle.

• Routage du trafic entre les régions : Les applications clientes se connectent via l’alias de récupération d’urgence géographique de votre espace de noms et leurs itinéraires de trafic vers l’espace de noms principal dans la région primaire.

  Seul l’espace de noms principal traite activement les événements des clients pendant les opérations normales. L’espace de noms secondaire reste passif en mode de secours et toutes les demandes d’accès aux données échouent.

• Réplication des données entre les régions : Seules les métadonnées de configuration sont répliquées entre les espaces de noms. La réplication de la configuration se produit en continu et de manière asynchrone.

  Toutes les données d’événement restent dans l’espace de noms principal uniquement et ne sont pas répliquées vers l’espace de noms secondaire.

Comportement lors d’une défaillance de région

Cette section décrit à quoi s'attendre lorsqu'un espace de noms Event Hubs est configuré pour la récupération en cas de catastrophe géographique et qu'il y a une interruption dans la région primaire.

• Détection et réponse : vous êtes responsable du monitoring de l’intégrité de la région et du lancement manuel du basculement. Microsoft n’effectue pas de basculement ni ne promeut automatiquement une région secondaire, même si votre région primaire est en panne.

  Si vous souhaitez découvrir plus d’informations sur le lancement du basculement, consultez Basculement manuel.

  Le basculement est une opération unidirectionnelle. Vous devrez donc rétablir le jumelage de géo-reprise d’activité après sinistre par la suite. Pour plus d’informations, consultez Récupération de région.

• Notification: Microsoft ne vous avertit pas automatiquement lorsqu’une région est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de région, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

  Utilisez ces informations et d’autres métriques pour décider du moment où basculer vers la région secondaire.

• Demandes actives : Les demandes actives en cours se terminent lorsque le failover démarre. Les applications clientes doivent réessayer les opérations une fois le basculement terminé.

• Perte de données attendue :

  • Métadonnées: La configuration et les métadonnées sont généralement répliquées vers l’espace de noms secondaire. Toutefois, la réplication des métadonnées se produit de manière asynchrone, de sorte que les modifications récentes peuvent ne pas être répliquées, en particulier les modifications complexes. Vérifiez la configuration de votre espace de noms secondaire avant que les clients y accèdent.

  • Données d’événement : Les données d’événement ne sont pas répliquées entre les régions. Si la région primaire tombe en panne, les événements de votre espace de noms principal deviennent indisponibles.

    Les événements ne sont pas définitivement perdus, sauf si une catastrophe catastrophique provoque une perte totale de la région primaire. Si la région récupère, vous pouvez récupérer des événements à partir de l’espace de noms principal ultérieurement.

• Temps d’arrêt attendu : le basculement se produit généralement dans les 5 à 10 minutes. Il peut falloir plus de temps pour que les clients répliquent et mettent à jour entièrement les entrées DNS.

• Réacheminement du trafic : les clients qui utilisent l’alias de géo-reprise d'activité après sinistre pour se connecter à l’espace de noms sont automatiquement redirigés vers l’espace de noms secondaire après le basculement. Toutefois, cette redirection dépend des serveurs DNS respectant la durée de vie des enregistrements DNS d’espace de noms et des clients recevant ces enregistrements DNS mis à jour.

Récupération de région

Une fois la région primaire d’origine rétablie, vous devez rétablir manuellement le jumelage et, éventuellement, effectuer un retour. Créez un appairage de récupération d’urgence géographique avec la région récupérée en tant que région secondaire, puis effectuez un autre basculement si vous souhaitez revenir à la région d’origine. Ce processus implique une potentielle perte de données des événements envoyés au principal temporaire.

Si le sinistre entraîne la perte de toutes les zones dans la région primaire, vos données peuvent ne pas être récupérables. Dans d’autres scénarios, vos données d’événement restent dans l’espace de noms principal avant que le basculement ne soit récupérable. Vous pouvez obtenir des événements historiques à partir de l’ancien espace de noms principal après avoir restauré l’accès. Vous êtes responsable de la configuration de vos applications pour recevoir et traiter ces événements. Microsoft ne les restaure pas automatiquement dans votre région secondaire.

Tester les défaillances régionales

Pour tester vos processus de réponse et de récupération d’urgence, effectuez un basculement planifié pendant une fenêtre de maintenance. Lancez le basculement de votre espace de noms principal vers votre espace de noms secondaire et vérifiez que vos applications peuvent se connecter et traiter des événements à partir du nouveau serveur principal.

Surveillez la durée du basculement et vérifiez que vos runbooks et vos automatisations fonctionnent correctement. Après le test, vous pouvez revenir à la configuration d'origine.

Comprendre le temps d’arrêt potentiel et la perte de données que vous pouvez rencontrer pendant et après le processus de basculement. Testez la géoréplication dans un environnement hors production qui reflète la configuration de votre espace de noms de production.

Solutions multirégions personnalisées pour la résilience

La géoréplication et la récupération d’urgence des métadonnées offrent une résilience aux pannes de région et d’autres problèmes, et prennent en charge la plupart des charges de travail. Certains niveaux Event Hubs ne prennent pas en charge ces fonctionnalités, ou vous pouvez nécessiter une réplication personnalisée ou avoir besoin de gérer simultanément plusieurs régions actives.

Différents modèles de conception peuvent obtenir différents types de prise en charge multirégion dans Event Hubs. De nombreux modèles nécessitent le déploiement de plusieurs espaces de noms et l’utilisation de services comme Azure Functions pour répliquer des événements entre eux. Pour plus d’informations, consultez La fédération multis sites et multirégions.

Sauvegarde et restauration

Event Hubs n’est pas conçu comme un emplacement de stockage à long terme pour vos données. En règle générale, vous stockez des données dans un hub d’événements pendant une courte période, puis traitez-la ou conservez-les dans un autre système de stockage de données. Vous pouvez configurer la période de rétention des données pour votre event Hub en fonction de vos besoins et du niveau que votre espace de noms utilise. Pour plus d’informations, consultez Rétention des événements.

Si vous devez conserver une copie de vos événements, envisagez d’utiliser Event Hubs Capture, qui enregistre des copies d’événements dans un compte stockage Blob Azure.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les contrats SLA pour les services en ligne.

Le niveau de service (SLA) de disponibilité de votre espace de noms est plus élevé lorsque vous utilisez les catégories Premium ou Dédiée.

Contenu connexe

• Documentation sur Event Hubs
• Présentation de la fiabilité d'Azure