Exporter (0) Imprimer
Développer tout

Meilleures pratiques pour la protection des applications Service Bus contre les pannes et catastrophes de Service Bus

Mis à jour: avril 2014

Les applications stratégiques doivent fonctionner en continu, même en cas de pannes non prévues ou de catastrophes. Cette rubrique décrit les techniques que vous pouvez utiliser pour protéger les applications contre une panne ou une catastrophe potentielle avec Microsoft Azure Service Bus.

Une panne se définit comme l’indisponibilité temporaire de Microsoft Azure Service Bus. La panne peut affecter certains composants de Service Bus, par exemple la banque de messagerie, voire l'ensemble du centre de données. Une fois le problème résolu, Service Bus redevient disponible. En général, une panne n’entraîne pas de perte de messages ou d’autres données. Une défaillance de composant peut, par exemple, prendre la forme d'une indisponibilité de Microsoft Azure Active Directory Access Control (également appelé Access Control Service ou ACS), ou d'une indisponibilité d'une banque de messagerie particulière. Une panne à l'échelle du centre de données peut prendre la forme, par exemple, d’une coupure de courant au niveau du centre de données ou d’une défaillance au niveau d’un commutateur réseau du centre de données. Une panne peut durer quelques minutes, comme quelques jours.

Une catastrophe se caractérise par la perte définitive d’une unité de grandeur ou d’un centre de données Service Bus. Le centre de données peut ne pas redevenir disponible. En général, une catastrophe entraîne la perte d’une partie ou de la totalité des messages ou d’autres données. Des exemples de catastrophes sont les incendies, les inondations ou les tremblements de terre.

Service Bus utilise de multiples banques de données pour stocker des messages qui sont envoyés aux files d'attente ou aux rubriques. Une file d'attente ou une rubrique non partitionnée est affectée à une banque de messagerie. Si cette banque de données n'est pas disponible, toutes les opérations portant sur cette file d'attente ou cette rubrique échouent.

Toutes les entités de messagerie Service Bus (files d’attente, rubriques, relais) résident dans un espace de noms de service. Il en est de même pour le service de contrôle d'accès (ACS), qui fournit les jetons requis pour accéder aux entités Service Bus. Un espace de noms de service est affilié à un centre de données. Service Bus et ACS n'autorisent pas la géo-réplication automatique des données, ni le fait qu'un espace de noms de service s'étende sur plusieurs centres de données.

En cas d'indisponibilité du service de contrôle d'accès (ACS), les clients ne peuvent plus obtenir de jetons. Sans un jeton valide, ces clients ne peuvent exécuter des opérations sur aucune entité Service Bus. Les clients qui ont un jeton au moment où le service de contrôle d'accès (ACS) tombe en panne peuvent continuer à utiliser Service Bus jusqu'à l'expiration de ce jeton. La durée de vie par défaut du jeton est de 3 heures.

Pour assurer une protection contre les pannes du service de contrôle d'accès (ACS), utilisez des jetons SAP (signature d'accès partagé). Dans ce cas, le client s'authentifie directement auprès de Service Bus en signant un jeton auto-émis avec une clé secrète. Les appels au service de contrôle d'accès (ACS) ne sont plus nécessaires. Pour plus d'informations sur jetons SAP, consultez Authentification dans Service Bus.

Une file d'attente ou une rubrique non partitionnée est affectée à une banque de messagerie. Si cette banque de données n'est pas disponible, toutes les opérations portant sur cette file d'attente ou cette rubrique échouent. Une file d'attente partitionnée, d'autre part, est constituée de multiples fragments. Chaque fragment est stocké dans une banque de messagerie. Quand un message est envoyé à une file d'attente ou à une rubrique partitionnée, Service Bus affecte le message à l'un des fragments. Si la banque de messagerie correspondante n'est pas disponible, Service Bus écrit le message dans un fragment différent, le cas échéant. Pour plus d'informations sur les entités partitionnées, consultez Partitionnement des entités de messagerie.

Pour autoriser un basculement entre deux centres de données, vous pouvez créer un Service Bus et un espace de noms de service ACS dans chaque centre de données. Par exemple, l'espace de noms de service Service Bus contosoPrimary.servicebus.windows.net peut être situé dans la région Nord-Centre des États-Unis, et contosoSecondary.servicebus.windows.net dans la région Sud-Centre des États-Unis. Si une entité de messagerie Service Bus doit rester accessible en cas de panne d'un centre de données, vous pouvez créer celle-ci dans les deux espace de noms de service.

La géo-réplication des points de terminaison de relais permet à un service qui expose un point de terminaison de relais d'être accessible en cas de pannes de Service Bus. Pour que la géo-réplication soit possible, le service doit créer deux points de terminaison de relais dans différents espace de noms de service. Les deux espace de noms de service doivent résider dans différents centres de données et porter des noms distincts. Par exemple, un point de terminaison principal peut être accessible sous contosoPrimary.servicebus.windows.net/myPrimaryService, et son homologue secondaire sous contosoSecondary.servicebus.windows.net/mySecondaryService.

Le service écoute alors les deux points de terminaison, et un client peut appeler le service via l'un ou l'autre des points de terminaison. Une application cliente sélectionne au hasard l'un des relais en tant que point de terminaison principal et envoie sa demande au point de terminaison actif. Si l'opération échoue avec un code d'erreur, cet échec indique que le point de terminaison de relais n'est pas disponible. L'application ouvre un canal vers un point de terminaison de sauvegarde et émet à nouveau la demande. À ce stade, les points de terminaison actif et de sauvegarde permutent leurs rôles : l'application cliente considère que l'ancien point de terminaison actif est le nouveau point de terminaison de sauvegarde, et que l'ancien point de terminaison de sauvegarde est le nouveau point de terminaison actif. Si les deux opérations d'envoi échouent, les rôles des deux entités restent inchangés et une erreur est renvoyée.

L'exemple Geo-replication with Service Bus Relayed Messages (Géo-réplication avec messages relayés par Service Bus) montre comment répliquer les relais.

Pour bénéficier d'une tolérance aux pannes des centres de données lors de l'utilisation de la messagerie répartie, Service Bus prend en charge deux méthodes : la réplication active et la réplication passive. pour chaque méthode, si une file d'attente ou rubrique donnée doit rester accessible en cas de panne des centres de données, vous pouvez la créer dans les deux espace de noms de service. Les deux entités peuvent avoir des noms identiques. Par exemple, une file d'attente principale peut être accessible sous contosoPrimary.servicebus.windows.net/myQueue, et son homologue secondaire sous contosoSecondary.servicebus.windows.net/myQueue.

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

La réplication active utilise les entités des deux espace de noms de service pour chaque opération. Un client qui envoie un message envoie deux copies du même message. La première copie du message est envoyée à l'entité principale (par exemple, contosoPrimary.servicebus.windows.net/sales), et la deuxième copie à 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 être associées au même identificateur. Vous pouvez utiliser MessageId, Label ou une propriété personnalisée pour attribuer un identificateur au message. Le destinataire doit conserver une liste des messages déjà reçus.

L'exemple Geo-replication with Service Bus Relayed Messages (Géo-réplication avec messages répartis par Service Bus) montre la procédure de réplication active des entités de messagerie.

noteRemarque
Dans la mesure où la réplication active double le nombre d'opérations, son coût est supérieur.

En l'absence de panne, la réplication passive n'utilise qu'une des deux entités de messagerie. Un client envoie le message à l'entité active. Si l'opération sur une entité active échoue avec un code d'erreur qui indique que le centre de données qui héberge l'entité active est peut-être non 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. Comme il est probable que le destinataire reçoive deux copies du même message, il doit supprimer les messages en double. Pour supprimer les doublons, vous pouvez suivre la procédure 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 exécutée. La latence, le débit et le coût monétaire sont identiques à ceux d’un scénario dans lequel aucune réplication n’a lieu.

Dans le cadre de l'utilisation de la réplication passive, les messages peuvent être perdus ou reçus en double dans les scénarios suivants :

  • Retard ou perte de messages : supposons que l’expéditeur parvienne à envoyer un message m1 à la file d’attente principale, mais que la file d’attente devienne non disponible avant que le destinataire ne reçoive le message m1. L'expéditeur envoie un autre message m2 à la file d'attente secondaire. Si la file d’attente principale n’est pas disponible de façon temporaire, le destinataire reçoit le message m1 une fois que la file d’attente est à nouveau disponible. En cas de catastrophe, le destinataire peut ne jamais recevoir le message m1.

  • Réception de doublons : supposons que l'expéditeur envoie un message m à la file d'attente principale. Service Bus traite correctement m, mais ne parvient pas à envoyer une réponse. Après l'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 devienne non disponible, le destinataire reçoit les deux copies de m presque en même temps. Si le destinataire n'est pas en mesure de recevoir la première copie de m avant que la file d'attente principale ne devienne non disponible, le destinataire ne reçoit initialement que la deuxième copie de m, mais il reçoit par la suite une deuxième copie de m lorsque la file d'attente principale devient disponible.

L'exemple Geo-replication with Service Bus Relayed Messages (Géo-réplication avec messages répartis par Service Bus) montre la procédure de réplication passive des entités de messagerie.

Si l’application tolère qu’une entité Service Bus soit indisponible, mais ne tolère pas la perte de messages, l’expéditeur peut utiliser une file d’attente durable côté client afin de stocker en local tous les messages qui ne peuvent pas être envoyés à Service Bus. Lorsque l’entité Service Bus redevient disponible, tous les messages mis en mémoire tampon sont envoyés à cette entité. L’exemple Durable Message Sender (Expéditeur de message durable) implémente une telle file d’attente à l’aide de MSMQ. Les messages peuvent également être écrits sur le disque local.

Une file d’attente durable côté client conserve l’ordre des messages et protège l’application cliente contre les exceptions si l’entité Service Bus est indisponible. Elle peut être utilisée avec des transactions simples et distribuées.

Voir aussi

Afficher:
© 2014 Microsoft