Azure Event Hubs - Géorécupération d’urgence
La résilience contre les pannes désastreuses des ressources de traitement des données constitue une exigence pour de nombreuses entreprises. Dans certains cas, elle est même requise par les réglementations du secteur.
Azure Event Hubs diffuse déjà le risque de défaillances catastrophiques d’ordinateurs individuels ou même de racks complets sur des clusters qui s’étendent sur plusieurs domaines d’échec au sein d’un centre de données. Il implémente des mécanismes transparents de détection des défaillances et de basculement, de sorte que le service continue à fonctionner dans les limites des niveaux de service assurés et, en général, sans interruption notable lorsque de telles défaillances se produisent. Si vous créez un espace de noms Event Hubs avec des zones de disponibilité activées, vous réduisez davantage le risque de panne et activez la disponibilité élevée. Dans des zones de disponibilité, le risque de panne est diffusé davantage dans trois sites physiquement séparés et le service dispose de réserves de capacité suffisantes pour faire face instantanément à la perte complète et irrémédiable de l’ensemble du site.
Le modèle de cluster Azure Event Hubs tout actif avec prise en charge des zones de disponibilité offre une résilience face à des défaillances matérielles graves, voire à une perte catastrophique de centres de données entiers. Il peut néanmoins se produire des situations graves impliquant une destruction physique généralisée contre laquelle même ces mesures ne suffisent pas.
La fonctionnalité de géo-reprise d’activité après sinistre d’Event Hubs est conçue pour faciliter la récupération après un sinistre de cette ampleur et l’abandon définitif d’une région Azure défaillante, sans qu’il soit nécessaire de modifier la configuration de vos applications. L’abandon d’une région Azure implique généralement plusieurs services. Cette fonctionnalité vise principalement à préserver l’intégrité de la configuration des applications composites.
La fonctionnalité de géo-reprise d’activité après sinistre garantit que la totalité de la configuration d’un espace de noms (Event Hubs, groupes de consommateurs et paramètres) est répliquée en continu d’un espace de noms principal vers un espace de noms secondaire quand ils sont jumelés. Elle permet également de lancer à tout moment un basculement ponctuel vers l’espace de noms secondaire. L’action de basculement fait pointer le nom d’alias choisi pour l’espace de noms vers l’espace de noms secondaire, puis arrête le jumelage. Le basculement est presque instantané une fois lancé.
Important
- La fonctionnalité permet une continuité instantanée des opérations avec la même configuration, mais ne réplique pas les données d’événement. À moins que l’incident ne soit à l’origine de la perte de toutes les zones, les données d’événement sont conservées dans l’Event Hub principal et seront récupérables après le basculement. De là, les événements historiques peuvent être obtenus une fois l’accès restauré. Pour répliquer des données d’événement et gérer les espaces de noms correspondants dans des configurations actives/actives de façon à faire face aux pannes et aux sinistres, ne vous contentez pas d’utiliser cette fonctionnalité de géo-reprise d’activité après sinistre. Suivez les conseils de réplication.
- Les affectations 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.
Pannes et sinistres
Il est important de noter la différence entre « panne » et « sinistre ». Une panne se définit comme l’indisponibilité temporaire d’Azure Event Hubs. La panne touche certains composants du service, comme une banque de messages, ou le centre de données entier. Toutefois, une fois le problème résolu, Event Hubs redevient disponible. En règle générale, une panne ne provoque aucune perte de messages ou d’autres données. Une coupure de courant dans le centre de données est un exemple de panne. Certaines pannes sont uniquement dues à une courte perte de connexion résultant de problèmes de réseau ou d’autres perturbations temporaires.
Un sinistre se définit comme une perte définitive ou à long terme d’un cluster Event Hubs, d’une région Azure ou d’un centre de données. La région ou le centre de données peut redevenir disponible ou pas, et rester arrêté(e) pendant plusieurs heures ou jours. Les incendies, les inondations ou les tremblements de terre sont des exemples de sinistres. Un sinistre qui devient permanent peut entraîner la perte de certains messages, événements ou d’autres données. Toutefois, dans la plupart des cas, il ne doit y avoir aucune perte de données et les messages peuvent être récupérés une fois que le centre de données est sauvegardé.
La fonctionnalité de géorécupération d’urgence d’Azure Event Hubs est une solution de récupération d’urgence. Les concepts et le workflow décrits dans cet article concernent des scénarios de sinistres, pas des pannes temporaires ou transitoires. Pour obtenir une présentation détaillée de la récupération d’urgence dans Microsoft Azure, consultez cet article.
Concepts et terminologie de base
La fonctionnalité de récupération d’urgence implémente la récupération d’urgence des métadonnées, en s’appuyant sur les espaces de noms de récupération d’urgence principal et secondaire.
La fonctionnalité de géo-reprise d’activité après sinistre est disponible uniquement pour les références SKU standard, premium et dédiées. Vous n’avez pas besoin de modifier de chaîne de connexion, car la connexion est établie à l’aide d’un alias.
Cet article emploie les termes suivants :
Alias : nom d’une configuration de récupération d’urgence que vous avez configurée. L’alias fournit une chaîne de connexion de nom de domaine complet (FQDN) stable. Les applications utilisent cet alias de chaîne de connexion pour se connecter à un espace de noms.
Espace de noms principal/secondaire : espaces de noms qui correspondent à l’alias. L’espace de noms principal est « actif » et reçoit des messages (il peut s’agir d’un espace de noms existant ou nouveau). L’espace de noms secondaire est « passif » et ne reçoit pas de messages. Les métadonnées sont synchronisées entre ces deux espaces de noms, qui peuvent ainsi accepter facilement les messages sans aucune modification du code d’application ou de la chaîne de connexion. Pour vous assurer que seul l’espace de noms actif reçoit des messages, vous devez utiliser l’alias.
Métadonnées : entités telles que des concentrateurs d’événements et des groupes de consommateurs ; incluent également leurs propriétés sur le service associé à l’espace de noms. Seules les entités et leurs paramètres sont automatiquement répliqués. Les messages et les événements ne sont pas répliqués.
Basculement : processus d’activation de l’espace de noms secondaire.
Paires d’espaces de noms prises en charge
Les combinaisons suivantes d’espaces de noms principaux et secondaires sont prises en charge :
| Niveau d’espace de noms principal | Niveau d’espace de noms secondaire autorisé |
|---|---|
| standard | Standard, Dédié |
| Premium | Premium |
| Dédié | Dédié |
Notes
Vous ne pouvez pas associer des espaces de noms qui se trouvent dans le même cluster dédié. Vous pouvez associer des espaces de noms qui se trouvent dans des cluster distincts.
Flux de configuration et de basculement
La section suivante présente une vue d’ensemble du processus de basculement et explique comment configurer le basculement initial.
Paramétrage
Tout d’abord, vous créez ou utilisez un espace de noms principal existant et un espace de noms secondaire, avant d’associer les deux. Cette association crée un alias qui vous servira à vous connecter. Étant donné que vous utilisez un alias, vous n’avez pas besoin de modifier les chaînes de connexion existantes. Vous pouvez uniquement ajouter de nouveaux espaces de noms à votre association de basculement.
Créez l’espace de noms principal.
Créez l’espace de noms secondaire dans une autre région. Cette étape est facultative. Vous pouvez créer l’espace de noms secondaire lors de la création du jumelage à l’étape suivante.
Dans le portail Azure, accédez à votre espace de noms principal.
Sélectionnez Géo-récupération dans le menu de gauche, puis Lancer le jumelage dans la barre d’outils.
Sur la page Lancer le jumelage, procédez comme suit :
- Sélectionnez un espace de noms secondaire existant ou créez-en un dans une autre région. Dans cet exemple, un espace de noms existant est sélectionné.
- Dans le champ Alias, entrez un alias pour le jumelage de géo-reprise d'activité après sinistre.
- Sélectionnez ensuite Create (Créer).
La page Alias de géo-reprise d'activité après sinistre doit s'afficher. Vous pouvez également accéder à cette page à partir de l'espace de noms principal en sélectionnant Géo-reprise dans le menu de gauche.
Sur la page Alias de géo-reprise d'activité après sinistre, sélectionnez Stratégies d'accès partagé dans le menu de gauche pour accéder à la chaîne de connexion principale de l'alias. Utilisez cette chaîne de connexion au lieu d’utiliser la chaîne de connexion directe à l’espace de noms principal/secondaire.
Dans cette page Vue d’ensemble, vous pouvez effectuer les actions suivantes :
Arrêter le jumelage entre les espaces de noms principal et secondaire. Sélectionnez Arrêter le jumelage dans la barre d’outils.
Basculer manuellement sur l’espace de noms secondaire. Sélectionnez Basculement dans la barre d’outils.
Avertissement
Le basculement active l’espace de noms secondaire et supprime l’espace de noms principal du jumelage de géo-reprise d’activité après sinistre. Créer un autre espace de noms pour avoir une nouvelle paire de géo-reprise d’activité après sinistre.
Enfin, vous devez ajouter un système de surveillance afin de détecter si un basculement est nécessaire. Dans la plupart des cas, le service fait partie d’un écosystème de grande taille. C’est pourquoi des basculements automatiques sont rarement possibles, dans la mesure où, souvent, les basculements doivent être synchronisés avec le reste de l’infrastructure ou du sous-système.
Exemple
Dans un exemple de ce scénario, imaginez une solution de Point de vente (PDV) qui émet des messages ou des événements. Event Hubs transmet ces événements à une solution de mappage ou de reformatage, qui envoie ensuite les données mappées à un autre système pour traitement. À ce stade, tous ces systèmes peuvent être hébergés dans la même région Azure. Le choix du moment du basculement et des éléments à basculer varie selon le flux de données dans votre infrastructure.
Vous pouvez automatiser le basculement à l’aide de systèmes de surveillance ou à l’aide de solutions de surveillance personnalisées. Toutefois, cette automatisation nécessite des tâches de planification et du travail supplémentaires, qui ne seront pas abordés dans cet article.
Flux de basculement
Si vous lancez le basculement, deux étapes sont requises :
Vous voulez être sûr de pouvoir refaire un basculement en cas de nouvelle panne. Pour cela, configurez un autre espace de noms passif et mettez à jour l’association.
Extrayez des messages de l’ancien espace de noms principal dès qu’il est de nouveau disponible. Après cela, utilisez cet espace de noms pour les messages réguliers en dehors de votre configuration de géorécupération ou supprimez l’ancien espace de noms principal.
Notes
Seule la sémantique de transfert du basculement est prise en charge. Dans ce scénario, vous basculez puis effectuez un nouveau couplage avec un nouvel espace de noms. La restauration automatique n’est pas prise en charge ; par exemple, dans un cluster SQL.
Basculement manuel
Cette section montre comment effectuer manuellement un basculement en utilisant le portail Azure, CLI, PowerShell, C#, etc.
Dans le portail Azure, accédez à votre espace de noms principal.
Sélectionnez Géorécupération dans le menu de gauche.
Basculer manuellement sur l’espace de noms secondaire. Sélectionnez Basculement dans la barre d’outils.
Avertissement
Le basculement active l’espace de noms secondaire et supprime l’espace de noms principal du jumelage de géo-reprise d’activité après sinistre. Créer un autre espace de noms pour avoir une nouvelle paire de géo-reprise d’activité après sinistre.
Gestion
Si vous avez fait une erreur (par exemple, vous avez associé les mauvaises régions lors de la configuration initiale), vous pouvez rompre le couplage des deux espaces de noms à tout moment. Si vous souhaitez utiliser les espaces de noms couplés comme des espaces de noms standard, supprimez l’alias.
Considérations
Tenez compte des points suivants :
De par sa conception, la géo-reprise d'activité après sinistre Event Hubs ne réplique pas les données, et vous ne pouvez donc pas réutiliser l'ancienne valeur de décalage de votre hub d'événements principal sur votre hub d'événements secondaire. Nous vous recommandons de redémarrer votre récepteur d’événements avec l’une des méthodes suivantes :
- EventPosition.FromStart() : pour lire toutes les données sur votre hub d'événements secondaire.
- EventPosition.FromEnd() : pour lire toutes les nouvelles données à partir de la connexion à votre hub d'événements secondaire.
- EventPosition.FromEnqueuedTime(dateTime) : pour lire toutes les données reçues dans votre hub d'événements secondaire depuis une date et une heure précises.
Dans votre planification de basculement, 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 le basculement.
Le fait qu’aucune donnée ne soit répliquée signifie que les sessions actives actuelles ne sont pas répliquées. En outre, la détection des doublons et les messages planifiés peuvent ne pas fonctionner. Les nouvelles sessions, les messages planifiés et les nouveaux doublons fonctionneront.
Le basculement d’une infrastructure distribuée complexe doit être répétée au moins une fois.
La synchronisation des entités peut prendre un certain temps, à raison d’environ 50 à 100 entités par minute.
Certains aspects du plan de gestion de l’espace de noms secondaire deviennent en lecture seule pendant que le jumelage de géo-récupération est actif.
Le plan de données de l’espace de noms secondaire sera en lecture seule pendant que le jumelage de géo-récupération est actif. Le plan de données de l’espace de noms secondaire accepte les requêtes GET pour activer la validation de la connectivité client et des contrôles d’accès.
Zones de disponibilité
Event Hubs prend en charge les zones de disponibilité, fournissant des emplacements isolés des pannes dans une région Azure. La prise en charge des zones de disponibilité est disponible uniquement dans les régions Azure avec zones de disponibilité. Les métadonnées aussi bien que les données (événements) sont répliquées dans les centres de données se trouvant dans la zone de disponibilité.
Lors de la création d’un espace de noms, le message mis en évidence suivant s’affiche quand vous sélectionnez une région qui contient des zones de disponibilité.
Remarque
Lorsque vous utilisez le Portail Azure, la redondance des zones via la prise en charge des zones de disponibilité est automatiquement activée. Vous ne pouvez pas le désactiver sur le portail. Vous pouvez utiliser la commande Azure CLI az eventhubs namespace avec --zone-redundant=false ou utiliser la commande PowerShell New-AzEventHubNamespace avec -ZoneRedundant=false pour créer un espace de noms avec une redondance de zone désactivée.
Instances Private Endpoint
Cette section fournit des informations supplémentaires concernant l’utilisation de la géo-reprise d’activité après sinistre avec des espaces de noms qui utilisent des points de terminaison privés. Pour en savoir plus sur l’utilisation de points de terminaison privés avec Event Hubs en général, consultez Configurer des points de terminaison privés.
Nouveaux pairages
Si vous tentez de créer un pairage entre un espace de noms principal avec un point de terminaison privé et un espace de noms secondaire sans point de terminaison privé, le pairage échoue. Le pairage ne fonctionnera que si les espaces de noms principal et secondaire ont des points de terminaison privés. Nous vous recommandons d’utiliser les mêmes configurations sur les espaces de noms principal et secondaire, ainsi que sur les réseaux virtuels dans lesquels des points de terminaison privés sont créés.
Notes
Lorsque vous tentez de pairer l’espace de noms principal avec un point de terminaison privé et un espace de noms secondaire, le processus de validation vérifie uniquement s’il existe un point de terminaison privé sur l’espace de noms secondaire. Il ne vérifie pas si le point de terminaison fonctionne ou fonctionnera après le basculement. Il vous incombe de vous assurer que l’espace de noms secondaire avec un point de terminaison privé fonctionnera comme prévu après le basculement.
Pour vérifier que les configurations de point de terminaison privé sont identiques sur les espaces de noms principal et secondaire, envoyez une demande de lecture (par exemple, Get Event Hub) à l’espace de noms secondaire à partir de l’extérieur du réseau virtuel, et vérifiez que vous recevez un message d’erreur du service.
Pairages existants
Si un pairage entre les espaces de noms principal et secondaire existe déjà, la création de point de terminaison privé sur l’espace de noms principal échoue. Pour résoudre ce problème, commencez par créer un point de terminaison privé sur l’espace de noms secondaire, puis créez-en un pour l’espace de noms principal.
Notes
Bien que nous autorisions un accès en lecture seule à l’espace de noms secondaire, les mises à jour des configurations de points de terminaison privés sont autorisées.
Configuration recommandée
Lorsque vous créez une configuration de récupération d’urgence pour votre application et des espaces de noms Event Hubs, vous devez créer des points de terminaison privés pour les espaces de noms Event Hubs principal et secondaire sur les réseaux virtuels hébergeant des instances principales et secondaires de votre application.
Supposons que vous disposiez de deux réseaux virtuels (VNET-1 et VNET-2) et d’espaces de noms principal et secondaire (EventHubs-EspaceNoms1-Principal et EventHubs-EspaceNoms2-Secondaire). Vous devez procéder comme suit :
- Sur EventHubs-EspaceNoms1-Principal, créez deux points de terminaison privés qui utilisent des sous-réseaux de VNET-1 et VNET-2.
- Sur EventHubs-EspaceNoms2-Secondaire, créez deux points de terminaison privés qui utilisent les mêmes sous-réseaux de VNET-1 et VNET-2.
L’avantage de cette approche est que le basculement peut se produire au niveau de la couche Application, indépendamment de l’espace de noms Event Hubs. Examinez les scénarios suivants :
Basculement uniquement d’application : Ici, l’application n’existera pas dans le VNET-1, mais passera à VNET-2. Comme les deux points de terminaison privés sont configurés sur VNET-1 et VNET-2 pour les espaces de noms principal et secondaire, l’application fonctionnera normalement.
Basculement uniquement d’espace de noms Event Hubs : Ici encore, étant donné que les deux points de terminaison privés sont configurés sur les deux réseaux virtuels pour les espaces de noms principal et secondaire, l’application fonctionnera normalement.
Notes
Pour obtenir des conseils en matière de géo-reprise d’activité après sinistre d’un réseau virtuel, voir Réseau virtuel – Continuité des activités.
Contrôle d’accès en fonction du rôle
Les affectations 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.
Étapes suivantes
Consultez les exemples ou la documentation de référence suivants.