Géorécupération d’urgence Azure Service Bus

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

Azure Service Bus répartit déjà le risque de défaillances catastrophiques de machines individuelles ou même de racks complets sur des clusters qui couvrent plusieurs domaines de défaillance au sein d’un centre de données. Le service implémente des mécanismes transparents de détection des défaillances et de basculement. Ainsi, le service continue de fonctionner selon les niveaux de service garantis et, en général, sans que les interruptions soient perceptibles quand de telles défaillances se produisent. Un espace de noms Premium peut disposer d’au moins deux unités de messagerie et ces unités de messagerie sont réparties sur plusieurs domaines de défaillance au sein d’un centre de données, prenant en charge un modèle de cluster Service Bus actif.

Pour un espace de noms de niveau Premium, le risque de panne est davantage réparti dans trois sites physiquement séparés (zones de disponibilité). Le service dispose par ailleurs de réserves de capacité suffisantes pour faire face instantanément à la perte complète et irrémédiable d’un centre de données. Le modèle de cluster Azure Service Bus tout actif au sein d’un domaine de défaillance avec prise en charge des zones de disponibilité est supérieur à tous les produits de type répartiteurs de messages locaux en termes de résilience face à des défaillances matérielles graves, voire à une perte catastrophique de sites 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 de Service Bus 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 des 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 de l’application composite. La fonctionnalité est disponible de manière globale pour la référence SKU Premium Service Bus.

La fonctionnalité de géo-reprise d’activité après sinistre garantit que la totalité de la configuration d’un espace de noms (files d’attente, rubriques, abonnements et filtres) est répliquée en continu d’un espace de noms principal vers un espace de noms secondaire quand ils sont couplés. Elle permet également de lancer à tout moment un basculement ponctuel vers l’espace de noms secondaire. Le basculement refait pointer le nom d’alias choisi pour l’espace de noms vers l’espace de noms secondaire, puis arrête l’association. Le basculement est presque instantané une fois lancé.

Points importants à prendre en compte

  • La fonctionnalité permet une continuité instantanée des opérations avec la même configuration, mais ne réplique pas les messages conservés dans les files d’attente, les abonnements aux rubriques ni les files d’attente de lettres mortes. Pour conserver la sémantique des files d’attente, une telle réplication nécessite non seulement la réplication des données de message, mais également chaque changement d’état dans le répartiteur. Pour la plupart des espaces de noms Service Bus, le trafic de réplication requis dépasserait de beaucoup le trafic d’application. Par ailleurs, avec des files d’attente à débit élevé, la plupart des messages seraient toujours répliqués sur l’espace de noms secondaire alors qu’ils seraient déjà en cours de suppression de l’espace de noms principal. En résulterait un trafic inutile excessif. Dans le cas des itinéraires de réplication à latence élevée, qui s’appliquent à de nombreux couplages possibles pour la géo-reprise d’activité après sinistre, il peut également se révéler impossible que le trafic de réplication suive le trafic d’application en raison des effets de limitation induits par la latence.
  • Les attributions de contrôle d’accès en fonction du rôle (RBAC) Microsoft Entra à des entités Service Bus dans l’espace de noms principal ne sont pas répliquées dans 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.
  • Les configurations suivantes ne sont pas répliquées.
    • Configurations de réseau virtuel
    • Connexions des points de terminaison privés
    • Accès à tous les réseaux activé
    • Accès au service approuvé activé
    • Accès au réseau public
    • Action réseau par défaut
    • Identités et paramètres de chiffrement (chiffrement à clé gérée par le client ou BYOK)
    • Activer la mise à l’échelle automatique
    • Désactiver l’authentification locale
  • L’association d’un espace de noms partitionné à un espace de noms non partitionné n’est pas prise en charge.
  • Si AutoDeleteOnIdle est activé pour une entité, l’entité peut ne pas être présente dans l’espace de noms secondaire lorsque le basculement se produit. Lorsque l’espace de noms secondaire devient l’espace de noms principal, le dernier état d’accès, qui ne fait pas partie des métadonnées, n’est pas mis à disposition du nouvel espace de noms principal et l’entité peut être supprimée dans le cadre du nettoyage AutoDeleteOnIdle.

Conseil

Pour répliquer le contenu des files d’attente et des abonnements aux rubriques 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.

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 Service Bus. La panne impacte certains composants du service, comme une banque de messages, ou le centre de données entier. Toutefois, une fois le problème résolu, Service Bus 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 Service Bus, d’une région Azure ou d’un centre de données. La région ou le centre de données peut être à nouveau disponible ou non, ou être indisponible pendant des heures ou des 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 se produire aucune perte de données, et les messages peuvent être récupérés une fois le centre de données de nouveau disponible.

La fonctionnalité de géorécupération d’urgence d’Azure Service Bus 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 le niveau tarifaire Premium. 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. L’utilisation d’un alias garantit que la chaîne de connexion restera inchangée après le déclenchement du basculement.

  • Espace de noms principal/secondaire : espaces de noms qui correspondent à l’alias. L’espace de noms principal est « actif » et reçoit les 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 les files d'attentes, les rubriques et les abonnements ; 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 ne sont pas répliqués.

  • Basculement : processus d’activation de l’espace de noms secondaire.

Programme d’installation

La section suivante est une présentation de l’association de deux espaces de noms.

Image montrant le fonctionnement de la géo-reprise d’activité après sinistre.

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.

  1. Créez l’espace de noms principal de niveau Premium.

  2. Créez l’espace de noms secondaire de niveau Premium 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.

  3. Dans le portail Azure, accédez à votre espace de noms principal.

  4. Sélectionnez Géo-récupération dans le menu de gauche, puis Lancer le jumelage dans la barre d’outils.

    Capture d’écran montrant la page Géo-reprise avec le lien Lancer le jumelage sélectionné.

  5. Sur la page Lancer le jumelage, procédez comme suit :

    1. 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 utilisé comme espace de noms secondaire.

    2. Dans le champ Alias, entrez un alias pour le jumelage de géo-reprise d’activité après sinistre.

    3. Sélectionnez ensuite Create (Créer).

      Capture d’écran montrant la page Lancer le jumelage dans le Portail Azure.

  6. Vous devez voir la page Alias de géo-reprise d’activité après sinistre Service Bus, comme indiqué dans l’image suivante. Vous pouvez également accéder à la page Alias de géo-reprise d’activité après sinistre à partir de la page de l’espace de noms principal en sélectionnant Géo-reprise dans le menu de gauche.

    Capture d’écran montrant la page Alias de géo-reprise d’activité Service Bus avec des espaces de noms principaux et secondaires.

  7. 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. Initialement, l’alias pointe vers l’espace de noms principal.

  8. Basculez vers la page Vue d’ensemble. Vous pouvez effectuer les actions suivantes :

    1. Arrêter le jumelage entre les espaces de noms principal et secondaire. Sélectionnez Arrêter le jumelage dans la barre d’outils.
    2. Basculer manuellement sur l’espace de noms secondaire.
      1. Sélectionnez Basculement dans la barre d’outils.

      2. Confirmez que vous souhaitez basculer sur l’espace de noms secondaire en saisissant votre alias.

      3. Activez l’option de basculement sécurisé pour basculer en toute sécurité sur l’espace de noms secondaire.

        Notes

        • Le basculement sécurisé permet de s’assurer que les réplications de géo-reprise d’activité après sinistre sont terminées avant de basculer vers le secondaire. Alors que le basculement forcé ou manuel n’attend pas que les réplications en attente soient terminées avant de basculer vers le secondaire.
        • Actuellement, le basculement sécurisé échoue si les espaces de noms principaux et secondaires ne se trouvent pas dans le même abonnement Azure.
      4. Sélectionnez ensuite Basculement.

        Capture d’écran montrant la page Basculement.

        Important

        Le basculement active l’espace de noms secondaire, et supprime l’espace de noms principal de l’association 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.

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

De Service Bus Standard à Premium

Si vous avez migré votre espace de noms Azure Service Bus Standard vers Azure Service Bus Premium, vous devez utiliser l’alias préexistant (c’est-à-dire la chaîne de connexion de l’espace de noms Service Bus Standard) pour créer la configuration de récupération d’urgence avec PS/CLI ou l’API REST.

Cela tient au fait que, lors de la migration, le nom DNS/la chaîne de connexion de l’espace de noms Azure Service Bus Standard devient un alias pour l’espace de noms Azure Service Bus Premium.

Vos applications clientes doivent utiliser cet alias (c’est-à-dire la chaîne de connexion de l’espace de noms Azure Service Bus Standard) pour se connecter à l’espace de noms Premium là où le jumelage de récupération d’urgence a été configuré.

Si vous utilisez le portail Azure pour mettre en place la configuration de la reprise d’activité après sinistre, le portail vous évite cet avertissement.

Flux de basculement

Le basculement est déclenché manuellement par le client (soit explicitement à l’aide d’une commande, soit via une logique métier appartenant au client qui déclenche cette commande) et jamais par Azure. Ainsi, le client dispose d’une pleine propriété et d’une visibilité complète pour la résolution des pannes sur le segment principal d’Azure.

Image montrant le flux de basculement de l’espace de noms principal vers l’espace de noms secondaire.

Après le déclenchement du basculement :

  1. La chaîne de connexion alias est mise à jour de façon à pointer vers l’espace de noms secondaire Premium.

  2. Les clients (expéditeurs et destinataires) se connectent automatiquement à l’espace de noms secondaire.

  3. L’association existante entre les espaces de noms Premium principal et secondaire est rompue.

Après le lancement du basculement :

  1. 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 le jumelage.

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

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.

Image montrant comment automatiser le basculement.

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.

Utiliser l’espace de noms existant en tant qu’alias

Si vous avez un scénario dans lequel vous ne pouvez pas modifier les connexions des producteurs et des consommateurs, vous pouvez réutiliser le nom de votre espace de noms comme nom d’alias. Voir l’exemple de code sur GitHub ici.

Exemples

Les exemples sur GitHub montrent comment configurer et lancer un basculement. Ces exemples illustrent les concepts suivants :

  • Un exemple .NET et les paramètres requis dans Microsoft Entra pour utiliser Azure Resource Manager avec Service Bus afin de configurer et d’activer la géo-reprise d’activité après sinistre.
  • Étapes requises pour exécuter l’exemple de code.
  • Comment utiliser un espace de noms existant en tant qu’alias.
  • Exécuter pas à pas pour activer de façon alternative la géorécupération d’urgence via PowerShell ou CLI.
  • Envoyer et recevoir à partir de l’espace de noms principal ou secondaire actuel à l’aide de l’alias.

Considérations

Notez les points suivants pour cette version :

  • 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 actuellement actives ne sont pas répliquées. De plus, la détection des doublons et les messages planifiés peuvent ne pas fonctionner. Les nouvelles sessions, les nouveaux 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. Les abonnements et les règles comptent également comme des entités.

Zones de disponibilité

La référence SKU de Service Bus Premium prend en charge les zones de disponibilité, en fournissant des emplacements isolés des pannes au sein d’une même région Azure. Service Bus gère trois copies de la banque de messagerie (1 copie principale et 2 secondaires). Service Bus synchronise les opérations relatives aux données et à la gestion sur les trois copies. Si la copie principale échoue, l’une des copies secondaires devient la copie principale, sans temps d’arrêt ressenti. Si les applications voient des déconnexions temporaires de Service Bus, la logique de nouvelle tentative du kit SDK se reconnectera automatiquement à Service Bus.

Lorsque vous utilisez des zones de disponibilité, les métadonnées et les données (messages) sont répliquées dans les centres de données de la zone de disponibilité.

Notes

Dans Azure Service Bus Premium, la prise en charge des zones de disponibilité est fournie uniquement pour les régions Azure qui comprennent déjà des zones de disponibilité.

Lorsque vous créez un espace de noms de niveau Premium par le biais du portail, la prise en charge des zones de disponibilité (si elles sont disponibles dans la région sélectionnée) est automatiquement activée pour l’espace de noms. Lors de la création d’un espace de noms de niveau Premium par le biais d’autres mécanismes, notamment des modèles ARM/Bicep, CLI ou PowerShell, la propriété zoneRedundant doit être explicitement définie sur true pour activer les zones de disponibilité (si elles sont disponibles dans la région sélectionnée). L’utilisation de cette fonctionnalité n’entraîne aucun frais supplémentaire. Vous ne pouvez pas désactiver ou activer cette fonctionnalité après la création d’un espace de noms.

Points de terminaison privés

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 des points de terminaison privés avec Service Bus en général, consultez Intégrer Azure Service Bus à Azure Private Link.

Nouveaux pairages

Si vous tentez de créer une association entre un espace de noms principal avec un point de terminaison privé et un espace de noms secondaire sans point de terminaison privé, l’association échoue. L’association réussit uniquement 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 d’appairer l’espace de noms principal avec un point de terminaison privé et l’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, y compris après le basculement. Il est de votre responsabilité de vérifier que l’espace de noms secondaire avec un point de terminaison privé fonctionne comme prévu après le basculement.

Pour vérifier que les configurations de point de terminaison privé sont identiques, envoyez une requête Get queues à l’espace de noms secondaire depuis l’extérieur du réseau virtuel et vérifiez que vous recevez un message d’erreur de la part du service.

Pairages existants

Si l’association entre l’espace de noms principal et l’espace de noms secondaire existe déjà, la création d’un 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.

Lorsque vous créez une configuration de récupération d’urgence pour votre application et Service Bus, vous devez créer des points de terminaison privés pour les espaces de noms Service Bus principal et secondaire sur les réseaux virtuels hébergeant des instances principales et secondaires de votre application.

Supposons que vous disposez de deux réseaux virtuels : VNET-1, VNET-2 et ces espaces de noms principaux et secondaires : ServiceBus-Namespace1-Primary, ServiceBus-Namespace2-Secondary. Vous devez procéder comme suit :

  • Sur ServiceBus-Namespace1-Primary, créez deux points de terminaison privés qui utilisent des sous-réseaux provenant de VNET-1 et VNET-2
  • Sur ServiceBus-Namespace2-Secondary, créez deux points de terminaison privés qui utilisent les mêmes sous-réseaux provenant de VNET-1 et VNET-2

Points de terminaison privés et réseaux virtuels

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 Service Bus. Examinez les scénarios suivants :

Basculement de l’application uniquement : ici, l’application n’existe pas dans VNET-1 mais est déplacée vers VNET-2. Dans la mesure où 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 fonctionne normalement.

Basculement de l’espace de noms Service Bus uniquement : ici encore, dans la mesure où 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 fonctionne normalement.

Remarque

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 attributions de contrôle d’accès en fonction du rôle (RBAC) Microsoft Entra à des entités Service Bus dans l’espace de noms principal ne sont pas répliquées dans 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

Pour en savoir plus sur la messagerie Service Bus, consultez les articles suivants :