Partage via

Meilleures pratiques pour protéger les applications contre les pannes de Service Bus et les sinistres

  • Article

Les applications stratégiques doivent fonctionner en permanence, même en cas de pannes non planifiées ou de sinistres. 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. Cette rubrique décrit les techniques que vous pouvez utiliser pour protéger les applications Service Bus contre une panne de service ou un sinistre potentiel.

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.

En outre, le risque de panne est réparti sur trois installations physiquement séparées (zones de disponibilité), et le service dispose de suffisamment de réserves de capacité pour faire face instantanément à la perte complète et catastrophique 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 et de géoréplication 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.

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. L'indisponibilité d'une banque de messagerie spécifique constitue un exemple de défaillance d'un composant. Une panne d'alimentation ou un commutateur réseau défaillant constituent des exemples de panne au niveau du centre de données. Une panne peut durer de quelques minutes à plusieurs jours. 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.

Protection contre les pannes et les sinistres

Il existe deux fonctionnalités qui fournissent une géo-reprise d’activité dans Azure Service Bus pour le niveau Premium. Tout d’abord, il existe la géo-reprise d'activité après sinistre (récupération d’urgence des métadonnées) qui fournit la réplication des métadonnées (entités, configuration, propriétés). Deuxièmement, il existe la géoréplication, qui est actuellement en préversion publique, fournissant la réplication des métadonnées et des données (modifications de l’état/des propriétés des messages et des données de message). Aucune des deux fonctionnalités de géo-reprise d’activité ne doit être confondue avec les zones de disponibilité. Qu’il s’agisse de la récupération d’urgence des métadonnées ou de la géo-reprise d’activité, les deux fonctionnalités de récupération géographique offrent une résilience entre les régions Azure telles qu’USA Est et USA Ouest.

Les zones de disponibilité sont disponibles sur tous les niveaux Service Bus et la prise en charge offre une résilience au sein d’une région géographique spécifique, par exemple USA Est. Pour obtenir une présentation détaillée de la récupération d’urgence dans Microsoft Azure, consultez cet article.

Les concepts liés à la haute disponibilité et à la reprise d’activité sont intégrés directement au niveau Premium d’Azure Service Bus, aussi bien dans la même région (par le biais des zones de disponibilité) que dans des régions différentes (par le biais de la géo-reprise d’activité après sinistre et la géoréplication).

Options de géo-reprise d'activité après sinistre

Géo-reprise d’activité après sinistre

Service Bus Premium prend en charge la géo-reprise d’activité après sinistre au niveau de l’espace de noms. Pour plus d’informations, consultez Géo-reprise d'activité après sinistre avec Azure Service Bus. La fonctionnalité géo-reprise d'activité après sinistre, disponible pour le niveau Premium uniquement, implémente la récupération d’urgence des métadonnées, en s’appuyant sur les espaces de noms principaux et secondaires. Avec la géo-reprise d’activité après sinistre, seules les métadonnées des entités sont répliquées entre les espaces de noms principal et secondaire.

Utiliser la géo-réplication

Le niveau Premium Service Bus prend également en charge la géoréplication au niveau de l’espace de noms. Pour plus d’informations, consultez Géoréplication Azure Service Bus (préversion publique). La fonctionnalité de géoréplication, disponible pour le niveau Premium uniquement et actuellement en préversion publique, implémente les métadonnées et la récupération d’urgence des données et s’appuie sur les régions principale et secondaires. Avec la géoréplication, les métadonnées et les données des entités sont répliquées entre les régions principale et secondaires.

Différences de fonctionnalités de haut niveau

La fonctionnalité Géo-reprise d’activité après sinistre (récupération d'urgence des métadonnées) réplique les métadonnées d’un espace de noms principal vers un espace de noms secondaire. Il prend en charge un basculement unique vers la région secondaire. Pendant le basculement lancé par le client, le nom d’alias de l’espace de noms est repointé vers l’espace de noms secondaire, puis le jumelage est rompu. Aucune donnée n’est répliquée hormis les métadonnées ni les affectations RBAC répliquées.

La fonctionnalité de géoréplication réplique les métadonnées et toutes les données d’une région principale vers une ou plusieurs régions secondaires. Lorsque client effectue un basculement, le secondaire sélectionné devient le principal et le principal précédent devient secondaire. Les utilisateurs peuvent effectuer un basculement vers le serveur principal d’origine lorsque vous le souhaitez.

Zones de disponibilité

Tous les niveaux Service Bus prennent en charge les zones de disponibilité, en fournissant des emplacements isolés des pannes dans la 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 détectent des déconnexions temporaires de Service Bus, la logique de nouvelle tentative du Kit de développement logiciel (SDK) se reconnecte 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é.

Remarque

La prise en charge des zones de disponibilité n’est disponible que dans les régions Azure où des zones de disponibilité sont présentes.

Lorsque vous créez un espace de noms, la prise en charge des zones de disponibilité (si disponible dans la région sélectionnée) est automatiquement activée pour l’espace de noms. L’utilisation de cette fonctionnalité n’entraîne pas de frais supplémentaires. Vous ne pouvez pas désactiver ou activer cette fonctionnalité après la création d’un espace de noms.

Remarque

Auparavant, il était nécessaire de définir la propriété zoneRedundant sur true pour activer les zones de disponibilité, mais ce comportement a changé pour activer les zones de disponibilité par défaut. Les espaces de noms existants sont migrés vers des zones de disponibilité dans la mesure du possible, et la propriété zoneRedundant est déconseillée. La propriété zoneRedundant peut toujours s’afficher comme étant false, même lorsque des zones de disponibilité ont été activées. Espaces de noms existants en cours de migration :

Protection contre les sinistres – niveau standard

Pour obtenir une résilience contre les sinistres avec le niveau Standard Service Bus, vous pouvez utiliser la réplication active ou passive. Pour chaque approche, si une file d’attente ou une rubrique donnée doit rester accessible en cas de panne du centre de données, vous pouvez la créer dans les deux espaces de noms. Les deux entités peuvent avoir le même nom. Par exemple, une file d’attente principale peut être accessible sous contosoPrimary.servicebus.windows.net/myQueue, alors que son homologue secondaire peut être accessible sous contosoSecondary.servicebus.windows.net/myQueue.

Notes

La réplication active et la réplication passive sont des solutions à usage général et non des fonctionnalités propres à Service Bus. La logique de réplication (c’est-à-dire l’envoi à 2 espaces de noms différents) se trouve dans les applications de l’expéditeur. Le destinataire doit avoir une logique personnalisée pour la détection des doublons.

Si l'application ne nécessite pas une communication permanente entre l'expéditeur et le destinataire, l'application peut implémenter une file d'attente côté client durable pour empêcher la perte de messages et protéger l'expéditeur contre toute erreur Service Bus temporaire.

Réplication active

La réplication active utilise des entités dans les deux espaces de noms pour chaque opération. Tout client qui envoie un message envoie deux copies du même message. La première copie est envoyée à l’entité principale (par exemple, contosoPrimary.servicebus.windows.net/sales) et la deuxième copie du message est envoyée à l’entité secondaire (par exemple, contosoSecondary.servicebus.windows.net/sales).

Un client reçoit des messages des deux files d'attente. Le destinataire traite la première copie d'un message et la deuxième copie est supprimée. Pour supprimer les messages en double, l'expéditeur doit attribuer un identificateur unique à chaque message. Les deux copies du message doivent avoir le même identificateur. Vous pouvez utiliser les propriétés ServiceBusMessage.MessageId ou ServiceBusMessage.Subject, ou une propriété personnalisée pour baliser le message. Le destinataire doit conserver une liste des messages qu'il a déjà reçus.

Remarque

L'approche de réplication active double le nombre d'opérations ; par conséquent, cette approche peut mener à un coût plus élevé.

Réplication passive

En cas d'absence de panne, la réplication passive n'utilise qu'une seule des deux entités de messagerie. Un client envoie le message à l'entité active. Si l'opération sur l'entité active échoue avec un code d'erreur qui indique que le centre de données qui héberge l'entité active n'est pas disponible, le client envoie une copie du message à l'entité de sauvegarde. À ce stade, les entités active et de sauvegarde permutent leurs rôles. Le client à l'origine de l'envoi considère que l'ancienne entité active est la nouvelle entité de sauvegarde, et que l'ancienne entité de sauvegarde est la nouvelle entité active. Si les deux opérations d'envoi échouent, les rôles des deux entités restent inchangés et une erreur est renvoyée.

Un client reçoit des messages des deux files d'attente. Étant donné qu'il est possible que le destinataire reçoive deux copies du même message, le destinataire doit supprimer les messages en double. Vous pouvez supprimer les doublons de la même façon que celle décrite pour la réplication active.

En général, la réplication passive est moins onéreuse que la réplication active, car dans la plupart des cas, une seule opération est effectuée. La latence, le débit et le coût monétaire sont identiques au scénario de la non réplication.

Lorsque vous utilisez la réplication passive, les messages peuvent être perdus ou reçus deux fois dans les scénarios suivants :

  • Retard ou perte de message : Supposons que l’expéditeur a envoyé avec succès un message m1 à la file d’attente principale, et qu’ensuite la file d'attente devient indisponible avant que le destinataire ne reçoive m1. L'expéditeur envoie un message ultérieur m2 à la file d'attente secondaire. Si la file d'attente principale est temporairement indisponible, le destinataire reçoit m1 lorsque la file d'attente est à nouveau disponible. En cas de sinistre, le récepteur peut ne jamais recevoir m1.
  • Réception de doublons : Supposons que l'expéditeur envoie un message m à la file d'attente principale. Service Bus traite m avec succès mais ne parvient pas à envoyer une réponse. Après expiration de l'opération d'envoi, l'expéditeur envoie une copie identique de m à la file d'attente secondaire. Si le destinataire peut recevoir la première copie de m avant que la file d'attente principale ne devienne indisponible, le destinataire reçoit les deux copies de m approximativement au même moment. Si le destinataire ne peut pas recevoir la première copie de m avant que la file d'attente principale ne devienne indisponible, le destinataire ne reçoit initialement que la deuxième copie de m, mais reçoit ensuite une deuxième copie de m lorsque la file d'attente principale devient disponible.

L’exemple de tâches de réplication de messagerie Azure avec .NET Core illustre la réplication des messages entre espaces de noms.

Étapes suivantes

Pour plus d'informations sur la récupération d'urgence, consultez les articles suivants :