FAQ Azure Relay

Le service Azure Relay facilite le déploiement de vos applications hybrides en vous aidant à exposer les services qui résident au sein d’un réseau d’entreprise au cloud public de façon plus sécurisée. Vous pouvez exposer les services sans ouvrir de connexion de pare-feu et sans devoir apporter de modifications intrusives à une infrastructure réseau d’entreprise.

A espace de noms est un conteneur d’étendue que vous pouvez utiliser pour adresser des ressources Relay au sein de votre application. Vous devez créer un espace de noms pour utiliser Relay. C’est l’une des premières étapes de la prise en main.

Le service anciennement nommé Service Bus Relay s’appelle désormais Azure Relay. Vous pouvez continuer à utiliser ce service comme vous en avez l’habitude. La fonctionnalité Connexions hybrides est une version mise à jour d’un service transplanté à partir Azure BizTalk Services. Les services Windows Communication Foundation (WCF) et Connexions hybrides continuent d’être prises en charge.

Tarification

Cette section contient les réponses à certaines questions fréquemment posées sur la structure de tarification de Relay. Pour des informations générales sur la tarification d’Azure, vous pouvez également consulter le Forum aux questions sur le support technique Azure. Pour des informations complètes sur la tarification de Relay, voir Détails de la tarification de Service Bus.

Pour obtenir toutes les informations sur la tarification Relay, consultez le tableau Connexions hybrides et relais WCF dans la page de détails de la tarification Service Bus. Outre les prix mentionnés sur cette page, vous êtes facturé pour les transferts de données associés aux sorties à l’extérieur du centre de données dans lequel votre application est déployée.

Relais WCF est disponible uniquement dans les espaces de noms de niveau Standard. Autrement, les tarifs et les quotas de connexion applicables aux relais restent inchangés. Cela signifie que les relais continueront d’être facturés sur la base du nombre de messages (pas d’opérations) et d’heures de relais. Pour plus d’informations, consultez le tableau Connexions hybrides et relais WCF dans la page de détails de tarification.

Dans certains cas, un même relais a de nombreux écouteurs connectés. Un relais est considéré comme ouvert quand au moins un écouteur y est connecté. L’ajout d’écouteurs à un relais ouvert entraîne des heures de relais supplémentaires. Le nombre d’expéditeurs de relais (clients qui appellent ou envoient des messages aux relais) connectés à un relais n’a aucune incidence sur le calcul des heures de relais.

(Cela s’applique uniquement aux relais WCF. Les messages sont gratuits pour des Connexions hybrides. )

Dans l’ensemble, les messages facturables pour les relais sont calculés conformément à la méthode décrite plus haut pour les entités réparties (files d’attente, rubriques et abonnements). Toutefois, il existe des différences importantes.

L’envoi d’un message à Azure Relay est traité comme un envoi « complet » à l’écouteur de relais qui reçoit le message. Cela n’est pas traité comme une opération d’envoi à Azure Relay, suivie d’une remise à l’écouteur de relais. Un appel de service de type demande-réponse (jusqu’à 64 Ko) à un écouteur de relais entraîne deux messages facturables : l’un pour la demande et l’autre pour la réponse (en supposant que la taille de réponse est également inférieure ou égale à 64 Ko). Cela diffère de l’utilisation d’une file d’attente servant d’intermédiaire entre un client et un service. Si vous utilisez une file d’attente servant d’intermédiaire entre un client et un service, le même modèle de demande-réponse nécessite l’envoi d’une demande à la file d’attente, suivi d’une remise (ou retrait de file d’attente) au service à partir de la file d’attente. Ce processus est suivi de l’envoi d’une réponse à une autre file d’attente, et d’une remise ou d’un retrait de file d’attente au client à partir de cette file d’attente. Sur la base des mêmes hypothèses de taille (jusqu’à 64 Ko), le modèle de file d’attente servant d’intermédiaire entraîne 4 messages facturables. Pour implémenter le même modèle que celui que vous exécutez en utilisant un relais, vous êtes facturé pour deux fois le nombre de messages. Il existe des avantages à utiliser les files d’attente pour obtenir ce modèle, par exemple, la durabilité et le nivellement de charge. Ces avantages peuvent justifier les coûts supplémentaires.

Les relais ouverts à l’aide de la liaison WCF netTCPRelay traitent les messages non pas en tant que messages individuels, mais en tant que flux de données transitant par le système. Lorsque vous utilisez cette liaison, seuls l’expéditeur et l’écouteur peuvent voir la trame des messages envoyés et reçus. Pour les relais qui utilisent la liaison netTCPRelay, toutes les données sont traitées comme un flux pour le calcul des messages facturables. Dans ce cas, Service Bus calcule la quantité totale de données envoyées ou reçues via chaque relais sur une base de 5 minutes. Ensuite, il divise cette quantité totale de données par 64 Ko pour déterminer le nombre de messages facturables pour ce relais pendant cette période.

Quotas

Par défaut, pour n’importe quel service cloud, Microsoft définit un quota d’utilisation agrégée mensuel qui est calculé avec tous les abonnements d’un client. Nous sommes conscients que vos besoins peuvent parfois dépasser ces limites. Vous pouvez contacter le service clientèle à tout moment pour nous faire part de vos besoins afin que nous puissions ajuster ces limites de manière appropriée. Pour Service Bus, les quotas d’utilisation d’agrégation sont les suivants :

• 5 milliards de messages
• 2 millions d’heures de relais

Si nous nous réservons le droit de désactiver un compte dépassant son quota mensuel d’utilisation, notre politique consiste à envoyer une notification par e-mail, et à tenter à plusieurs reprises de contacter le client avant toute action. Les clients qui dépassent ces quotas restent responsables de frais de dépassement occasionnés.

Le nom de l’espace de noms du relais doit compter de 6 à 50 caractères.

Pour déplacer un espace de noms d’un abonnement Azure vers un autre, vous pouvez utiliser le portail ou des commandes PowerShell. Pour pouvoir déplacer un espace de noms vers un autre abonnement, il faut que l’espace de noms soit déjà actif. Il est également impératif que l’utilisateur qui exécute les commandes soit un administrateur des abonnements source et cible.

Azure portal

Pour utiliser le portail Azure afin de migrer des espaces de noms Azure Relay d’un abonnement vers un autre, voir Déplacer des ressources vers un nouveau groupe de ressources ou un nouvel abonnement.

PowerShell

Pour utiliser PowerShell afin de déplacer un espace de noms d’un abonnement Azure vers un autre, utilisez la séquence de commandes suivante. Pour exécuter cette opération, l’espace de noms doit être déjà actif, et l’utilisateur qui exécute les commandes PowerShell doit être administrateur des abonnements source et cible.

# Create a new resource group in the target subscription.
Select-AzSubscription -SubscriptionId 'ffffffff-ffff-ffff-ffff-ffffffffffff'
New-AzResourceGroup -Name 'targetRG' -Location 'East US'

# Move the namespace from the source subscription to the target subscription.
Select-AzSubscription -SubscriptionId 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa'
$res = Find-AzResource -ResourceNameContains <NAMESPACE NAME> -ResourceType 'Microsoft.ServiceBus/namespaces'
Move-AzResource -DestinationResourceGroupName 'targetRG' -DestinationSubscriptionId 'ffffffff-ffff-ffff-ffff-ffffffffffff' -ResourceId $res.ResourceId

Pour obtenir une description des exceptions courantes et des actions suggérées, consultez Exceptions Relay.

Les signatures d’accès partagé (SAP) sont des mécanismes d’authentification basés sur des hachages sécurisés SHA-256 ou des URI. Pour plus d’informations sur la génération de vos propres signatures en Node.js, PHP, Python, Java, C et C#, consultez Authentification de Service Bus avec les signatures d’accès partagé.

Oui. Le client de relais établit des connexions au service Azure Relay en utilisant des noms de domaine complets (FQDN). Cela permet aux clients d’ajouter une entrée pour *.servicebus.windows.net sur les pare-feu qui prennent en charge les listes d’approbation de DNS. Il est également possible d’établir une liste d'autorisation d’un espace de noms spécifique à l’aide de your-namespace-name.servicebus.windows.net. Dans ce cas, vous devez également établir une liste d’autorisation des passerelles de votre espace de noms, accessibles par ce script PowerShell.

Étapes suivantes

• Créer un espace de noms
• Prise en main de .NET
• Prise en main de Node