Azure Relay – häufig gestellte Fragen

Der Azure Relay-Dienst vereinfacht Ihre Hybridanwendungen, indem er Sie dabei unterstützt, Dienste, die sich in einem Unternehmensnetzwerk befinden, auf sichere Weise für die öffentliche Cloud verfügbar zu machen. Sie können die Dienste verfügbar machen, ohne eine Firewallverbindung zu öffnen und ohne grundlegende Änderungen an der Infrastruktur des Unternehmensnetzwerks vornehmen zu müssen.

Ein Namespace ist ein Bereichscontainer für die Adressierung von Relay-Ressourcen innerhalb Ihrer Anwendung. Um Relay verwenden zu können, müssen Sie einen Namespace erstellen. Dies ist einer der ersten Schritte.

Der früher „Service Bus Relay“ genannte Dienst heißt jetzt Azure Relay. Sie können den Dienst weiter wie gewohnt verwenden. Der Hybrid Connections-Dienst ist die aktualisierte Version eines Diensts, der aus Azure BizTalk Services übernommen wurde. WCF-Relay und Hybrid Connections werden weiterhin unterstützt.

Preiskalkulation

In diesem Abschnitt werden einige häufig gestellte Fragen zur Relay-Preisstruktur beantwortet. Allgemeine Informationen zu Azure-Preisen finden Sie unter Häufig gestellte Fragen zum Azure-Support. Vollständige Informationen zu Relay-Preisen finden Sie unter Service Bus-Preise.

Alle Informationen zu den Preisen für Relay finden Sie in der Tabelle Hybrid Connections und WCF Relays auf der Seite mit den Preisdetails zu Service Bus. Zusätzlich zu den preisen, die auf dieser Seite angegeben sind, werden Sie für die zugehörigen Datenübertragungen für den Ausgang außerhalb des Rechenzentrums berechnet, in dem Ihre Anwendung bereitgestellt wird.

WCF-Relay ist nur in den Namespaces des Tarifs „Standard“ verfügbar. Preise und Verbindungskontingente für Relays wurden andernfalls nicht geändert. Dies bedeutet, dass Relays auch weiterhin anhand der Anzahl der Nachrichten (nicht der Vorgänge) und der Relaystunden abgerechnet werden. Weitere Informationen finden Sie in der Tabelle Hybridverbindungen und WCF-Relays auf der Seite mit den Preisdetails.

In einigen Fällen verfügt ein einzelnes Relay über mehrere verbundene Listener. Ein Relay wird als „geöffnet“ betrachtet, wenn mindestens ein Relaylistener mit ihm verbunden ist. Das Hinzufügen von Listenern zu einem offenen Relay führt zu zusätzlichen Relaystunden. Die Anzahl der Relay-Absender (Clients, die Nachrichten an Relays aufrufen oder senden), die mit einem Relay verbunden sind, wirkt sich nicht auf die Berechnung der Relaystunden aus.

(Dies gilt nur für WCF-Relays. Nachrichten sind keine Kosten für hybride Verbinden ionen.)

Im Allgemeinen werden abrechenbare Nachrichten für Relays mit derselben Methode berechnet, die weiter oben für Brokerentitäten (Warteschlangen, Themen und Abonnements) beschrieben wird. Es gibt jedoch einige wichtige Ausnahmen.

Das Senden einer Nachricht an Azure Relay wird als vollständiger Sendevorgang an den Relaylistener behandelt, der die Nachricht empfängt, Es wird nicht als Sendevorgang an das Azure Relay behandelt, gefolgt von einer Übermittlung an den Relaylistener. Ein Dienstaufruf vom Typ Anforderung-Antwort (von bis zu 64 KB) für einen Relaylistener führt zu zwei abrechenbaren Nachrichten: eine für die Anforderung und eine für die Antwort (unter der Voraussetzung, dass die Antwort ebenfalls 64 KB oder kleiner ist). Dies unterscheidet sich vom Einsatz einer Warteschlange für die Vermittlung zwischen einem Client und einem Dienst. Wenn Sie eine Warteschlange für die Vermittlung zwischen einem Client und einem Dienst verwenden, erfordert das gleiche Anforderung-Antwort-Muster das Senden einer Anforderungsnachricht an die Warteschlange, gefolgt von einer Nachricht zur Entfernung/Übermittlung von der Warteschlange an den Dienst. Darauf folgt eine Antwortnachricht an eine andere Warteschlange und eine Nachricht zur Entfernung/Übermittlung von dieser Warteschlange an den Client. Unter Annahme der gleichen Nachrichtengrößen (bis zu 64 KB) würde das Muster der Vermittlung per Warteschlange zu vier abrechenbaren Nachrichten führen. Damit würden Ihnen zum Implementieren des gleichen Musters doppelt so viele Nachrichten berechnet wie bei Verwendung von Relays. Natürlich gibt es Vorteile beim Einsatz von Warteschlangen, wenn man dieses Muster verwenden möchte, wie etwa Dauerhaftigkeit und Lastenausgleich. Diese Vorteile könnten die zusätzlichen Kosten rechtfertigen.

Relays, die anhand der WCF-Bindung netTCPRelay geöffnet werden, behandeln Nachrichten nicht als einzelne Nachrichten, sondern als Datenstrom, der durch das System fließt. Wenn Sie diese Bindung verwenden, erhalten nur der Sender und der Listener Einblick in das Framing der einzelnen Nachrichten, die gesendet/empfangen werden. Bei Relays, die die netTCPRelay-Bindung verwenden, werden zur Ermittlung abrechenbarer Nachrichten alle Daten als Datenstrom behandelt. In diesen Fall berechnet Service Bus die Gesamtmenge der über jedes einzelne Relay gesendeten oder empfangenen Daten für einen Zeitraum von 5 Minuten. Dann wird diese Gesamtmenge durch 64 KB dividiert, um die Anzahl von abrechenbaren Nachrichten für dieses Relay in diesem Zeitraum zu ermitteln.

Kontingente

Microsoft legt für jeden Clouddienst standardmäßig ein aggregiertes monatliches Nutzungskontingent fest, das abonnementübergreifend für einen Kunden berechnet wird. Wir wissen, dass Ihre Anforderungen diese Limits zuweilen überschreiten können. Wenden Sie sich an unseren Kundendienst, und teilen Sie uns Ihre Anforderungen mit, damit wir diese Werte entsprechend anpassen können. Für Service Bus gelten die folgenden aggregierten Nutzungskontingente:

• 5 Milliarden Nachrichten
• 2 Millionen Relaystunden

Wir behalten uns vor, ein Konto zu deaktivieren, das die monatlichen Nutzungskontingente überschritten hat. Wir informieren allerdings per E-Mail darüber und unternehmen mehrere Versuche, den Kunden zu kontaktieren, ehe wir Maßnahmen ergreifen. Kunden, die diese Kontingente überschreiten, haben die Kosten für die Überschreitung zu tragen.

Ein Relaynamespace-Name muss zwischen 6 und 50 Zeichen lang sein.

Um einen Namespace aus einem Azure-Abonnement in ein anderes zu verschieben, können Sie entweder das Azure-Portal oder PowerShell-Befehle verwenden. Bevor Sie den Namespace in ein anderes Abonnement verschieben können, muss der Namespace bereits aktiv sein. Der Benutzer, der die Befehle ausführt, muss sowohl im Quellabonnement als auch im Zielabonnement Administratorbenutzer sein.

Azure portal

Informationen zum Migrieren von Azure Relay-Namespaces aus einem Abonnement in ein anderes finden Sie unter Verschieben von Ressourcen in eine neue Ressourcengruppe oder ein neues Abonnement.

PowerShell

Verwenden Sie die folgende Befehlssequenz, wenn Sie einen Namespace mithilfe von PowerShell aus einem Azure-Abonnement in ein anderes verschieben möchten. Um diesen Vorgang auszuführen, muss der Namespace bereits aktiv sein, und der Benutzer, der die PowerShell-Befehle ausführt, muss sowohl im Quell- als auch im Zielabonnement Administratorbenutzer sein.

# 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

Eine Beschreibung häufig auftretender Ausnahmen und der vorgeschlagenen Aktionen, die Sie ausführen können, finden Sie unter Relay-Ausnahmen.

Bei Shared Access Signatures handelt es sich um einen Authentifizierungsmechanismus, der auf sicheren Hashes (SHA-256) oder URIs basiert. Informationen zum Generieren eigener Signaturen in Node.js, PHP, Python, Java, C und C# finden Sie im Artikel Service Bus-Authentifizierung mit Shared Access Signatures.

Ja. Der Relayclient stellt mithilfe vollqualifizierter Domänennamen Verbindungen mit dem Azure Relay-Dienst her. Kunden können in Firewalls, die DNS-Genehmigungseinträge unterstützen, einen Eintrag für *.servicebus.windows.net hinzufügen. Es ist auch möglich, einen bestimmten Namespace mithilfe your-namespace-name.servicebus.windows.netvon "Allowlist" zuzulassen. In diesem Fall müssen Sie auch die Gateways für Ihren Namespace zulassen, die mithilfe dieses PowerShell-Skripts gefunden werden können.

Nächste Schritte

• Erstellen eines Namespaces
• Erste Schritte mit .NET
• Erste Schritte mit Node