Fiabilité dans Azure Service Bus

Azure Service Bus est un service de répartiteur de messages d’entreprise entièrement géré qui fournit des fonctionnalités de messagerie asynchrone fiables pour découpler les applications et les services. Service Bus prend en charge les files d’attente pour la communication point à point et les rubriques avec abonnements pour les modèles de messagerie de type publication-abonnement. Le service fournit des fonctionnalités de fiabilité intégrées, notamment la durabilité des messages, des garanties de livraison au moins une fois et des files d’attente de lettres mortes pour gérer l’échec de traitement des messages.

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 rendre Service Bus résilient à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité et les pannes de région. Il met également en évidence certaines informations clés sur le contrat de niveau de service Service Bus (SLA).

Recommandations concernant le déploiement de production

Azure Well-Architected Framework fournit des recommandations sur la fiabilité, les performances, la sécurité, le coût et les opérations. Pour comprendre comment ces domaines influencent les uns les autres et contribuent à une solution App Service fiable, consultez les meilleures pratiques d’architecture pour Azure Service Bus dans Azure Well-Architected Framework.

Vue d’ensemble de l’architecture de fiabilité

Cette section décrit certains des aspects importants du fonctionnement du service qui sont les plus pertinents du point de vue de la fiabilité. La section présente l’architecture logique, qui inclut certaines des ressources et fonctionnalités que vous déployez et utilisez. Il traite également de l’architecture physique, qui fournit des détails sur le fonctionnement du service sous les couvertures.

Architecture logique

Un espace de noms sert de conteneur de gestion pour Service Bus et peut être configuré pour utiliser le niveau De base, Standard ou Premium. Vous configurez le service au niveau de l’espace de noms en allouant la capacité, en configurant la sécurité réseau et en activant Geo-Replication et Geo-Disaster Recovery.

Dans un espace de noms, vous déployez des files d’attente et des rubriques, qui sont des entités de messagerie avec une sémantique différente. Pour plus d’informations, consultez files d’attente, rubriques et abonnements Service Bus.

Vous pouvez éventuellement configurer des partitions sur votre espace de noms, qui répartit les files d’attente et les rubriques sur plusieurs répartiteurs de messages et magasins de messagerie. Un espace de noms peut utiliser plusieurs partitions pour effectuer un traitement parallèle et une mise à l’échelle horizontale. Service Bus ne garantit le classement que 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 le niveau Premium, vous activez le partitionnement sur l’espace de noms. Pour les espaces de noms de niveau Essentiel et Standard, vous configurez les partitions sur l’entité et, facultativement, lorsque vous envoyez des messages.

Vous pouvez utiliser Service Bus et ses approches de conception asynchrone pour augmenter la disponibilité de vos applications. Pour plus d’informations, consultez Les modèles de messagerie asynchrone et la haute disponibilité.

Architecture physique

Service Bus fournit les ressources de calcul et de stockage sous-jacentes. Pour chaque espace de noms, plusieurs répartiteurs de messages traitent les messages, et plusieurs magasins de messagerie stockent les messages. Il existe trois copies du magasin de messagerie : un serveur principal et deux 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.

Pour les espaces de noms qui utilisent le niveau De base ou Standard, Service Bus fournit une redondance via une infrastructure partagée et mutualisée qui réplique automatiquement les messages entre les zones de disponibilité lorsque celles-ci sont disponibles. Le service gère plusieurs stockages de messagerie et conserve toutes les copies synchronisées pour les opérations de données et de gestion.

Pour les espaces de noms de niveau Premium, Service Bus fournit des unités de messagerie dédiées, chacune avec des ressources de processeur et de mémoire dédiées. Les espaces de noms de niveau Premium peuvent automatiquement être mis à l’échelle en fonction des demandes de charge de travail. Pour plus d’informations, consultez Mettre à jour automatiquement les unités de messagerie d’un espace de noms Azure Service Bus.

L'infrastructure Service Bus s'étend sur plusieurs machines physiques et racks répartis entre les domaines de pannes, ce qui réduit le risque de défaillances catastrophiques affectant votre espace de noms. Dans les régions qui ont des zones de disponibilité, l’infrastructure s’étend sur des centres de données physiques distincts. Le service implémente des mécanismes transparents de détection des défaillances et de basculement, de sorte qu’il continue à fonctionner au sein des niveaux de service assurés et généralement sans interruptions notables lorsque de telles défaillances se produisent.

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.

Le Kit de développement logiciel (SDK) Azure Service Bus inclut une logique de nouvelle tentative automatique avec interruption exponentielle pour les opérations qui échouent en raison de conditions temporaires telles que les délais d’expiration du réseau ou l’indisponibilité temporaire du service. Lorsque les applications rencontrent des déconnexions temporaires de Service Bus, le SDK tente automatiquement de se reconnecter à l’aide de la stratégie de nouvelle tentative configurée.

Pour optimiser la gestion des erreurs temporaires dans vos applications, utilisez le dernier Kit de développement logiciel (SDK) Service Bus, qui inclut les fonctionnalités de logique de nouvelle tentative et de gestion des connexions les plus récentes. Pour plus d’informations, consultez la bibliothèque de client Azure Service Bus pour .NET.

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.

Service Bus prend en charge les déploiements redondants interzones dans tous les niveaux de service. Lorsque vous créez un espace de noms Service Bus dans une région prise en charge, la redondance de zone est automatiquement activée sans frais supplémentaires. Le modèle de déploiement redondant interzone s’applique à toutes les fonctionnalités Service Bus, notamment le partitionnement et les sessions.

Service Bus réplique en toute transparence vos données de configuration, de métadonnées et de messages dans plusieurs zones de disponibilité de la région. La redondance de zone fournit un basculement automatique sans votre intervention. Tous les composants Service Bus, notamment le calcul, la mise en réseau et le stockage, sont répliqués entre les zones. Service Bus 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, Service Bus continue de fonctionner sans perte de données ni interruption des applications de messagerie.

Spécifications

• Prise en charge des régions : les espaces de noms Service Bus redondants par zone peuvent être déployés dans des régions Azure prenant en charge les zones de disponibilité. Service Bus active automatiquement la prise en charge des zones de disponibilité lorsque vous créez un espace de noms dans une région prise en charge, sans configuration supplémentaire requise.

• Niveaux : Tous les niveaux de Service Bus (De base, Standard et Premium) prennent en charge les zones de disponibilité sans exigences supplémentaires.

Considérations

Les espaces de noms Service Bus incluent une zoneRedundant propriété. Auparavant, cette propriété était nécessaire pour activer les zones de disponibilité, mais ce comportement a changé et la zoneRedundant propriété est déconseillée. Cette propriété peut encore s’afficher comme false même lorsque la redondance de zone est activée. Tous les espaces de noms dans les régions avec zones de disponibilité présentent une redondance interzone.

Coûts

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

Configurez la prise en charge des zones de disponibilité

Les espaces de noms Service Bus 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

Cette section décrit ce qu’il faut attendre lorsque les espaces de noms Service Bus sont configurés pour la redondance de zone et que toutes les zones de disponibilité sont opérationnelles.

• Routage du trafic entre les zones. Service Bus utilise un modèle actif-actif où les messages sont distribués entre plusieurs zones de disponibilité. Les connexions clientes sont automatiquement réparties entre les zones, et le service achemine les opérations vers l'infrastructure de messagerie disponible, quelle que soit la zone.

• Réplication des données entre les zones. Service Bus utilise la réplication synchrone entre les zones de disponibilité, notamment pour les métadonnées et les données de message. Plusieurs copies du magasin de messagerie doivent reconnaître les opérations d’écriture avant qu’elles ne soient considérées comme terminées, ce qui garantit la cohérence des données entre les zones pendant les opérations normales.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu’il faut attendre lorsque les espaces de noms Service Bus sont configurés pour la redondance de zone et qu’il existe une panne de zone de disponibilité.

• Détection et réponse : Microsoft détecte automatiquement les défaillances de zone et lance le basculement vers des zones saines. Aucune intervention du client n’est nécessaire pour le basculement au niveau de la 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, Service Bus peut supprimer les requêtes 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 Service Bus réplique les messages de façon synchrone entre les zones avant l’accusé de 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.

• Reroutage du trafic : Service Bus détecte la perte de la zone et redirige automatiquement les nouvelles requêtes vers une autre réplique dans l’une des zones de disponibilité opérationnelles.

  Le Kit de développement logiciel (SDK) Service Bus gère 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é est récupérée, Service Bus réinscrit automatiquement la zone dans la topologie de service active. La zone récupérée commence à accepter de nouvelles connexions et à traiter les messages 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

Service Bus gère le routage du trafic, le basculement et la récupération de zone lors des défaillances de zone, de sorte que vous n’avez pas besoin de valider les processus de défaillance de zone ni de fournir d’autres entrées.

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

Service Bus fournit deux types de prise en charge multirégion, dont les deux nécessitent des espaces de noms de niveau Premium :

• La géoréplication fournit une réplication passive active des métadonnées et des données de message entre une région primaire et une région secondaire. Utilisez Geo-Replication 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 de message.

• Géo-reprise d’activité après sinistre des métadonnées fournit une réplication active-passive de la configuration et des métadonnées entre une région primaire et secondaire, mais elle ne réplique pas les données de messages. Envisagez d’utiliser Geo-Disaster Recovery pour les applications qui gèrent leur propre réplication de données ou qui n’ont pas besoin de réplication de données.

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.

Les espaces de noms des niveaux De base et Standard n’incluent pas de fonctionnalités multirégions natives, mais vous pouvez implémenter des modèles de réplication au niveau de l’application à l’aide de plusieurs espaces de noms entre régions. Pour plus d'informations, consultez la section Solutions multirégions personnalisées pour la résilience ci-dessous.

Geo-Replication

Le niveau Premium prend 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 messages dans vos files d’attente et rubriques, ainsi que les propriétés et l’état des messages) de l’espace de noms. Vous configurez l’approche de réplication pour la configuration et les données de votre espace de noms. Cette fonctionnalité garantit que vos messages restent disponibles dans une autre région et vous permettent de basculer vers la région secondaire si nécessaire.

Utilisez Geo-Replication 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 de message.

L’espace de noms s’étend essentiellement à travers les régions. Une région sert de région primaire, et les autres régions servent de régions secondaires. Votre abonnement Azure affiche un espace de noms unique.

À tout moment, vous pouvez promouvoir la région secondaire vers une région primaire. Lorsque vous promouvez la région secondaire, Service Bus 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

Service Bus Geo-Replication utilise le terme promotion car cela représente le processus de changement d’une région secondaire vers une région primaire (et de rétrogradation ultérieure d’une région primaire vers 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 Géoréplication de Service Bus.

Spécifications

• Prise en charge de la région : Vous pouvez choisir n’importe quelle région Azure qui prend en charge Service Bus comme région principale ou région 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.

• Niveau: Pour activer la géoréplication, votre espace de noms doit utiliser le niveau Premium.

• Géo-reprise d'activité après sinistre des métadonnées : Vous ne pouvez pas configurer d’espace de noms pour utiliser à la fois Géoréplication et Géo-reprise d'activité après sinistre.

Considérations

• Limitations des fonctionnalités : Lorsque vous activez la géoréplication, il existe certaines restrictions. Pour plus d’informations, consultez Géoréplication de Service Bus.

• 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 les points de terminaison privés dans la documentation Azure Event Hubs.

Coûts

Pour comprendre comment la tarification fonctionne pour la géoréplication, consultez Tarification.

Configurer la prise en charge multirégion

• Activez Geo-Replication sur un nouvel espace de noms. Pour activer Geo-Replication sur un espace de noms lors de la création, consultez Switch replication mode.

• Migrez de la Géo-reprise d'activité après sinistre vers la Géoréplication.Vous pouvez passer de l'utilisation de la Géo-reprise d'activité après sinistre à la Géoréplication..

• 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ésactivez la géoréplication. Pour désactiver Geo-Replication à une région secondaire, consultez Supprimer la 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 Service Bus 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 messages des clients pendant les opérations normales. La région secondaire reçoit des messages répliqués, mais reste passive en mode de secours.

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

  • Synchrone: Les messages 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 de message 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 messages entrants. Il exige également que la région secondaire soit disponible pour accepter l’opération d’écriture. Par conséquent, une panne dans la région secondaire entraîne l’échec de l’opération d’écriture.

    • Asynchrone: Les messages sont écrits dans la région primaire, puis l’opération d’écriture se termine. Un peu plus tard, il réplique les messages 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 de la 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.

    Certains types de métadonnées sont répliqués de manière synchrone même si vous sélectionnez le mode de réplication asynchrone.

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

Comportement lors d’une panne de région

Cette section décrit ce qu’il faut attendre lorsqu’un espace de noms Service Bus est configuré pour Geo-Replication 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 des critères suggérés à prendre en compte lorsque vous décidez s'il faut basculer, veuillez consulter la section Scénarios recommandés pour déclencher la promotion.

  Pour plus d’informations sur la promotion d’une région secondaire vers la nouvelle région primaire, consultez Flux de promotion.

  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.

• Demandes actives : Le comportement dépend de la panne de la région dans la région primaire ou dans la 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 messages 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 Geo-Replication.

• 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 messages récents qui ne sont pas répliqués dans la région secondaire et pour les modifications d’état qui n’ont pas encore été répliquées. 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, Service Bus 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.

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 principale 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 Geo-Replication dans un environnement hors production qui reflète la configuration de votre espace de noms de production.

Récupération des métadonnées après sinistre géographique

Le niveau Premium prend en charge les métadonnées Geo-Disaster Recovery. Cette fonctionnalité améliore la récupération à partir de scénarios d’urgence, notamment la perte catastrophique d’une région. Geo-Disaster Recovery réplique uniquement la configuration et les métadonnées de votre espace de noms. Toutefois, elle ne réplique pas les données de message. 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 messages des clients. La récupération des sinistres géographiques sert de solution de récupération unidirectionnelle et ne prend pas en charge le retour en arrière vers la région primaire précédente.

Les métadonnées Geo-Disaster Recovery fonctionnent mieux pour les applications qui n’ont pas strictement besoin de gérer chaque message et peuvent tolérer une perte de données pendant un scénario de sinistre. Les métadonnées Geo-Disaster Recovery peuvent également être appropriées pour les applications qui répliquent elles-mêmes des données, ou qui n’ont pas besoin de réplication de données du tout. Par exemple, si vos messages représentent des images volumineuses que vous convertissez ultérieurement en miniatures, vous pouvez décider de perdre certains messages d’une région ayant échoué si vous pouvez reprendre rapidement le traitement de nouveaux messages dans une autre région, et vous pouvez reconstruire les messages ultérieurement pour rattraper le retard.

Important

Geo-Disaster Recovery permet la continuité des opérations qui ont la même configuration, mais qui ne répliquent pas les données de message. Si vous devez répliquer des données de message, envisagez d’utiliser la géoréplication.

Lorsque vous configurez les métadonnées Geo-Disaster Recovery, 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. Vous pouvez choisir d’effectuer un basculement sécurisé, qui attend que les réplications soient terminées avant de basculer vers la secondaire, bien que cette option ne soit peut-être pas disponible lors d’une panne régionale. Une fois le basculement commencé, il s'achève 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 l'appariement est supprimé.

Cette section récapitule les aspects importants de la reprise après sinistre géographique. Passez en revue la documentation complète pour comprendre exactement son fonctionnement. Pour plus d’informations, consultez Service Bus Geo-Disaster Recovery.

Spécifications

• Prise en charge de la région : Vous pouvez sélectionner n’importe quelle région Azure qui prend en charge Service Bus 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.

• Niveau : Pour activer la récupération après sinistre géographique des métadonnées, les deux espaces de noms doivent utiliser le niveau Premium.

• Partitionnement: Il n’est pas possible d'associer un espace de noms partitionné à un espace de noms non partitionné.

• Géo-reprise d'activité après sinistre des métadonnées : Vous ne pouvez pas configurer d’espace de noms pour utiliser à la fois Géoréplication et Géo-reprise d'activité après sinistre.

Considérations

• Limitations des fonctionnalités : Lorsque vous activez Geo-Disaster récupération, il existe certaines restrictions. Pour plus d’informations, consultez Points importants à prendre en compte et 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.

• Conception d’application : Geo-Disaster Recovery nécessite des considérations spécifiques lorsque vous concevez 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.

• Espaces de noms migrés de standard vers Premium : Si votre espace de noms était précédemment au niveau Standard et que vous l’avez migré vers le niveau Premium, vous devez gérer l’alias différemment. Pour plus d’informations, consultez Service Bus Standard vers Premium.

Coûts

Lorsque vous activez la récupération après sinistre géographique pour les 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 appariement 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 récupération 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 Service Bus est configuré pour Geo-Disaster Recovery et que la région primaire est opérationnelle.

• Routage du trafic entre les régions : Les applications clientes se connectent via l’alias Geo-Disaster Recovery pour 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 messages 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 de message 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 panne de région

Cette section décrit ce qu’il faut attendre lorsqu’un espace de noms Service Bus est configuré pour Geo-Disaster Recovery et qu’il existe une panne 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.

  Pour plus d'informations sur la façon de lancer le basculement, consultez Processus de basculement.

  Lorsque vous lancez un basculement, choisissez s’il faut effectuer un basculement sécurisé ou une norme (basculement forcé ou manuel). Un basculement sécurisé attend que la réplication se termine dans la région secondaire avant le démarrage du basculement. Cette approche réduit la perte de métadonnées, mais introduit des temps d’arrêt. Le basculement sécurisé nécessite que les espaces de noms se trouvent dans le même abonnement Azure.

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

  Le basculement est une opération unidirectionnelle. Vous devrez donc rétablir l'appariement de la Géo-reprise d’activité après sinistre ultérieurement. 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.

• 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 de message : Les données de message ne sont pas répliquées entre les régions. Si la région primaire tombe en panne, les messages de votre espace de noms principal deviennent indisponibles.

    Les messages 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 messages à 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 Geo-Disaster Recovery 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 nouvel appariement de Géo-reprise d'activité après sinistre avec la région secondaire comme région récupérée, puis effectuez un autre basculement si vous souhaitez retourner à la région d’origine. Ce processus implique une perte de données potentielle des messages envoyés au serveur 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 de message restent dans l’espace de noms principal avant que le basculement ne soit récupérable. Vous pouvez obtenir des messages 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 messages. 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 messages à 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 les métadonnées Geo-Disaster Recovery 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

Geo-Replication et les métadonnées Geo-Disaster Recovery offrent une résilience aux pannes de région et à d’autres problèmes, et conviennent à la plupart des charges de travail. Toutefois, ils peuvent ne pas correspondre à vos besoins dans les situations suivantes :

• Vous avez des exigences pour la réplication personnalisée ou pour la maintenance simultanée de plusieurs régions actives.
• Vous utilisez un niveau Service Bus qui ne prend pas en charge ces fonctionnalités.

Il existe un éventail de modèles de conception pour obtenir différents types de prise en charge multirégion dans Service Bus. De nombreux modèles nécessitent le déploiement de plusieurs espaces de noms et la configuration de votre application pour utiliser les espaces de noms de manière appropriée. Pour en savoir plus, reportez-vous aux articles suivants :

• Utiliser plusieurs espaces de noms pour isoler les applications contre les pannes et les sinistres du Service Bus
• Réplication des messages et fédération inter-régions.

Résilience à la maintenance du service

Service Bus effectue une maintenance régulière. Pendant la maintenance planifiée, les espaces de noms sont déplacés vers un nœud redondant qui contient les dernières mises à jour. À mesure que ce déplacement se produit, le SDK client se déconnecte et se reconnecte automatiquement sur l’espace de noms. En règle générale, les mises à niveau se produisent dans les 30 secondes. Il est important que vos applications soient préparées pour toutes les déconnexions réseau temporaires qui se produisent pendant les périodes de maintenance.

Pour plus d’informations, consultez Conseils sur les événements de maintenance Azure pour Azure Service Bus.

Sauvegarde et restauration

Service Bus n’est pas conçu comme un emplacement de stockage à long terme pour vos données. En règle générale, les données sont stockées dans une rubrique ou une file d’attente pendant une courte période, puis sont traitées ou conservées dans un autre système de stockage de données, à quel moment elle est supprimée. Avec cette conception, Service Bus gère automatiquement les répliques des données des messages, mais ne fournit pas de fonctionnalités de sauvegarde et de restauration pour ces données.

Pour les scénarios nécessitant une rétention de messages à long terme, envisagez d’implémenter l’archivage au niveau de l’application sur stockage Azure ou d’autres services de stockage durables.

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.

Service Bus fournit un contrat SLA pour tous les espaces de noms. Le contrat SLA de disponibilité est plus élevé lorsque votre espace de noms répond à tous les critères suivants :

• Il utilise le niveau Premium.
• Il se trouve dans une région avec des zones de disponibilité.
• Il utilise le partitionnement.

Contenu connexe

• Documentation de Service Bus
• Géo-reprise d’activité après sinistre Azure Service Bus.
• Azure Service Bus Géoréplication