Cette page vous a-t-elle été utile ?
Votre avis sur ce contenu est important. N'hésitez pas à nous faire part de vos commentaires.
Vous avez d'autres commentaires ?
1500 caractères restants
Exporter (0) Imprimer
Développer tout

FAQ sur la tarification de Service Bus

Mis à jour: mai 2015

Si vous avez des questions concernant la structure de prix de Microsoft Azure Service Bus, voir le Forum Aux Questions (FAQ) dans la section suivante. Vous pouvez aussi consulter le FAQ sur la tarification de la plateforme Azure pour obtenir des informations générales sur la tarification de Microsoft Azure. Pour obtenir des informations complètes sur la tarification Service Bus, consultez Tarification – Service Bus.

noteRemarque
Les tarifs applicables aux hubs d'événements Service Bus sont décrits dans Forum aux questions sur la disponibilité et le support du service Event Hubs.

Pour obtenir des informations complètes sur la tarification Service Bus, consultez les pages Tarification et facturation de Service Bus et Détails de la tarification de Service Bus. En plus des prix indiqués, les transferts de données associés sont facturés pour les sorties à l'extérieur du centre de données dans lequel votre application est approvisionnée. Vous trouverez plus de détails dans la section Quelle utilisation de Service bus est soumise au transfert de données ? Laquelle ne l'est pas ? ci-dessous.

Les transferts de données dans une région Azure donnée sont fournis gratuitement. Les transferts de données à l'extérieur d'une région sont soumis à des frais de sortie au tarif de 0,15 USD par Go à partir des régions Amérique du Nord et Europe, et de 0,20 USD par Go à partir de la région Asie/Pacifique. Les transferts de données entrants sont fournis gratuitement.

Un relais est une entité Service Bus qui relaie les messages entre les clients et les services web. Le relais fournit au service une adresse Service Bus persistante et détectable, une connectivité fiable avec des fonctionnalités de traversée de pare-feu/parcours NAT et des fonctionnalités supplémentaires, telles que l'équilibrage de charge automatique. Un relais est implicitement instancié et ouvert à une adresse Service Bus donnée (URL d'espace de noms) chaque fois qu'un service WCF prenant en charge les relais, ou un « écouteur relais », se connecte pour la première fois à cette adresse. Les applications créent des écouteurs de relais à l'aide de l'API managée .NET Service Bus, qui fournit des versions spéciales des liaisons WCF standard qui prennent en charge les relais.

Les heures de relais sont facturées par rapport au temps cumulé durant lequel chaque relais Service Bus est « ouvert » au cours d'une période de facturation donnée. Un relais est implicitement instancié et ouvert à une adresse Service Bus donnée (URL d'espace de noms de service) quand un service WCF prenant en charge les relais, ou un « écouteur relais », se connecte pour la première fois à cette adresse. Le relais n'est fermé qu'à partir du moment où le dernier écouteur se déconnecte de son adresse. Par conséquent, à des fins de facturation, un relais est considéré comme « ouvert » à partir du moment où le premier écouteur de relais se connecte, jusqu'au moment où le dernier écouteur de relais se déconnecte de l'adresse Service Bus de ce relais. Autrement dit, un relais est considéré comme « ouvert » du moment où un ou plusieurs écouteurs de relais sont connectés à son adresse Service Bus.

Dans certains cas, plusieurs écouteurs sont connectés à un seul relais dans Service Bus. Cela peut se produire avec des services à charge équilibrée qui utilisent les liaisons netTCPRelay ou *HttpRelay WCF, ou avec des écouteurs d'évènements de diffusion qui utilisent la liaison netEventRelay WCF. Un relais dans Service Bus est considéré comme « ouvert » lorsqu'au moins un écouteur de relais y est connecté. L'ajout d'écouteurs supplémentaires à un relais ouvert ne modifie pas l'état de ce relais à des fins de facturation. De même, le nombre de relais expéditeurs (clients qui appellent ou envoient des messages aux relais) connectés à un relais n'a aucun effet sur le calcul des heures de relais.

En général, les messages facturables sont calculés pour les relais à l'aide de la même méthode que celle décrite ci-dessus pour les entités réparties (files d'attente, rubriques/abonnements). Cependant, il existe plusieurs différences notables :

  1. L'envoi d'un message à un relais Service Bus est traité en tant qu'envoi « intégral » à l'écouteur de relais qui reçoit le message, plutôt qu'en tant qu'envoi au relais Service Bus suivi d'une remise à l'écouteur de relais. Par conséquent, un appel de service de type demande-réponse (jusqu'à 64 Ko) sur un écouteur de relais engendrera deux messages facturables : un message facturable pour la demande et un message facturable pour la réponse (en partant du principe que la réponse est aussi inférieure ou égale à 64 Ko). Ceci diffère de l'utilisation d'une file d'attente servant d'intermédiaire entre un client et un service. Dans ce dernier cas, le même modèle de demande-réponse nécessiterait l'envoi d'une demande à la file d'attente, l'enlèvement de la file d'attente/la remise de la file d'attente vers le service, l'envoi d'une réponse à une autre file d'attente, puis l'enlèvement de la file d'attente/la remise de la file d'attente vers le client. En partant du même principe concernant la taille (inférieure ou égale à 64 Ko), le modèle de file d'attente intermédiaire entraînerait la facturation de quatre messages, soit deux fois le nombre facturé pour implémenter le même modèle à l'aide d'un relais. Il y a évidemment des avantages à utiliser des files d'attente pour exécuter ce modèle, tels que la durabilité et le nivellement de charge. Ces avantages peuvent justifier les coûts supplémentaires.

  2. Les relais ouverts à l'aide de la liaison NetTCPRelay WCF traitent les messages non pas en tant que messages individuels, mais en tant que flux de données transitant via le système. Autrement dit, seuls l'expéditeur et l'écouteur ont une réelle visibilité de la structure des messages individuels envoyés/reçus à l'aide de cette liaison. Ainsi, pour les relais utilisant la liaison netTCPRelay, toutes les données sont traitées en tant que flux à des fins de calcul des messages facturables. Dans ce cas, Service Bus calculera la quantité totale de données envoyées ou reçues via chaque relais individuel sur une base de 5 minutes et divisera le total par 64 Ko de façon à déterminer le nombre de messages facturables pour le relais en question durant cette période.

Non, Service Bus ne facture pas le stockage. Cependant, un quota limite la quantité maximale de données qui peut être conservée par file d'attente/rubrique. Voir la section Service Bus a-t-il des quotas d'utilisation ? ci-dessous.

Par défaut, pour tout service de cloud, Microsoft définit un quota d'utilisation mensuelle totale qui est calculé pour tous les abonnements d'un client. Nous concevons parfaitement que vous puissiez avoir des besoins plus importants. N'hésitez donc pas à contacter le service clientèle à tout moment pour nous faire part de vos besoins afin que nous ajustions les limites en fonction. Pour Service Bus, les quotas d'utilisation totale sont les suivants :

  • 5 milliards de messages

  • 2 millions d'heures de relais

Bien que nous nous réservions le droit de désactiver un compte client ayant dépassé son quota d'utilisation au cours d'un mois donné, nous enverrons une notification par courrier électronique et tenterons plusieurs fois de contacter le client avant de prendre des mesures. Les clients qui dépassent ces quotas seront néanmoins responsables des frais qui dépassent les quotas.

Comme pour les autres services de Azure, Service Bus met en œuvre un ensemble de quotas spécifiques pour assurer une utilisation juste des ressources. Les quotas d'utilisation mis en œuvre par le service sont les suivants :

  • Taille de file d'attente/rubrique : vous spécifiez la taille maximale de la file d'attente ou de la rubrique au moment de sa création. Ce quota peut avoir pour valeur 1, 2, 3, 4 ou 5 Go. Si la taille maximale est atteinte, les messages entrants supplémentaires sont rejetés et une exception est reçue par le code appelant.

  • Nombre de connexions simultanées

    • File d'attente/rubrique/abonnement : le nombre de connexions TCP simultanées sur une file d'attente/une rubrique/un abonnement est limité à 100. Si ce quota est atteint, les demandes de connexion supplémentaires qui suivent sont rejetées et une exception est reçue par le code appelant. Pour chaque fabrique de messagerie, Service Bus maintient une connexion TCP unique si un des clients créés par cette fabrique de messagerie a une opération active en attente ou a une opération terminée depuis moins de 60 secondes. Les opérations REST ne sont pas prises en compte comme connexions TCP simultanées.

  • Nombre d'écouteurs simultanés sur un relais : le nombre d'écouteurs NetTcpRelay et NetHttpRelay simultanés sur un relais est limité à 25 (1 pour un relais NetOneway).

  • Nombre d'écouteurs de relais simultanés par espace de noms de service : Service Busapplique une limite de 2 000 écouteurs de relais simultanés par espace de noms de service. Si ce quota est atteint, les demandes d'ouverture d'écouteurs de relais supplémentaires qui suivent sont rejetées et une exception est reçue par le code appelant.

  • Nombre de rubriques/files d'attente par espace de noms de service : le nombre maximal de rubriques/files d'attente (entités s'appuyant sur un stockage durable) dans un espace de noms de service est limité à 10 000. Si ce quota est atteint, les demandes de création de rubriques/files d'attente dans l'espace de noms de service qui suivent sont rejetées. Dans ce cas, le portail de gestion affiche un message d'erreur ou le code client appelant reçoit une exception, selon que la tentative de création est effectuée via le portail ou dans le code client.

  • Quotas de taille des messages

    • File d'attente/rubrique/abonnement

      • Taille de message : chaque message est limité à une taille totale de 256 Ko, en-tête de message compris.

      • Taille d'en-tête de message : chaque en-tête de message est limité à 64 KB.

    • Relais NetOneway et NetEvent : chaque message est limité à une taille totale de 64 Ko, en-tête de message compris.

    • Relais Http et NetTcp  : Service Bus n'applique pas de limite maximale pour la taille de ces messages.

    Les messages qui dépassent ces quotas de taille sont rejetés et une exception est reçue par le code appelant.

  • Nombre d'abonnements par rubrique : le nombre maximal d'abonnements par rubrique est limité à 2 000. Si ce quota est atteint, les demandes de création d'abonnements supplémentaires qui suivent sont rejetées. Dans ce cas, le portail de gestion affiche un message d'erreur ou le code client appelant reçoit une exception, selon que la tentative de création est effectuée via le portail ou dans le code client.

  • Nombre de filtres SQL par rubrique : le nombre maximal de filtres SQL par rubrique est limité à 2 000. Si ce quota est atteint, les demandes de création de filtres supplémentaires sur la rubrique qui suivent sont rejetées et une exception est reçue par le code appelant.

  • Nombre de filtres de corrélation par rubrique : le nombre maximal de filtres de corrélation par rubrique est limité à 100 000. Si ce quota est atteint, les demandes de création de filtres supplémentaires sur la rubrique qui suivent sont rejetées et une exception est reçue par le code appelant.

Pour plus d'informations sur les quotas, voir Quotas de Service Bus.

Afficher:
© 2015 Microsoft