Meilleures pratiques pour protéger les applications contre les pannes de Service Bus et les sinistres
Les applications stratégiques doivent fonctionner en permanence, même en cas de pannes non planifiées ou de sinistres. 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.
Une panne est définie comme l'indisponibilité temporaire d'Azure Service Bus. La panne peut affecter certains composants de Service Bus, comme une banque de messagerie ou même le centre de données entier. 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.
Un sinistre est défini comme la perte définitive d'une unité d'échelle ou d'un centre de données Service Bus. Le centre de données peut redevenir disponible ou pas. En général, un sinistre provoque la perte d'une partie ou de l'ensemble des messages ou autres données. Les incendies, les inondations ou les tremblements de terre sont des exemples de sinistres.
Protection contre les pannes et les sinistres - niveau Premium
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).
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é de récupération d’urgence, disponible pour la référence SKU 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.
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 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é.
Notes
La prise en charge des zones de disponibilité pour le niveau Premium 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 de niveau Premium via le portail, 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. Lorsque vous créez un espace de noms de niveau Premium par le biais d’autres mécanismes, notamment des modèles Azure Resource Manager/Bicep, CLI ou PowerShell, vous devez explicitement définir la propriété zoneRedundant 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 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.
Protection contre les pannes et les sinistres - niveau standard
Pour assurer la résilience face aux pannes du centre de données lors de l’utilisation du niveau tarifaire de messagerie standard, 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.
L’exemple de [géo-réplication avec un niveau standard de Service Bus][Géo-réplication avec un Niveau Standard de Service Bus] illustre la réplication active des entités de messagerie.
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 :