Vanliga frågor och svar om Azure Relay

Azure Relay-tjänsten underlättar dina hybridprogram genom att hjälpa dig att på ett säkrare sätt exponera tjänster som finns i ett företagsnätverk för det offentliga molnet. Du kan exponera tjänsterna utan att öppna en brandväggsanslutning och utan att kräva påträngande ändringar i företagets nätverksinfrastruktur.

Ett namnområde är en omfångscontainer som du kan använda för att hantera Relay-resurser i ditt program. Du måste skapa ett namnområde för att kunna använda Relay. Det här är ett av de första stegen för att komma igång.

Den tidigare namngivna Service Bus Relay-tjänsten kallas nu Azure Relay. Du kan fortsätta att använda den här tjänsten som vanligt. Funktionen Hybridanslutningar är en uppdaterad version av en tjänst som har transplanterats från Azure BizTalk Services. Både WCF Relay- och Hybridanslutningar stöds fortfarande.

Prissättning

Det här avsnittet besvarar några vanliga frågor om prisstrukturen för Relay. Du kan också se vanliga frågor och svar om Azure-support för allmän prisinformation för Azure. Fullständig information om Relay-priser finns i Prisinformation för Service Bus.

Fullständig information om Relay-priser finns i tabellen Hybridanslutningar och WCF Relays på sidan med prisinformation för Service Bus. Utöver de priser som anges på den sidan debiteras du för associerade dataöverföringar för utgående trafik utanför det datacenter där programmet etableras.

WCF Relay är endast tillgängligt i standardnivånamnområden. Priser och anslutningskvoter för reläer har annars inte ändrats. Det innebär att reläer fortsätter att debiteras baserat på antalet meddelanden (inte åtgärder) och relätimmar. Mer information finns i tabellen "Hybridanslutningar och WCF Relays" på sidan med prisinformation.

I vissa fall har ett enda relä många anslutna lyssnare. Ett relä anses vara öppet när minst en relälyssnare är ansluten till den. Att lägga till lyssnare i ett öppet relä resulterar i ytterligare relätimmar. Antalet reläavsändare (klienter som anropar eller skickar meddelanden till reläer) som är anslutna till ett relä påverkar inte beräkningen av relätimmar.

(Detta gäller endast för WCF-reläer. Meddelanden kostar inte hybridanslutningar.)

I allmänhet beräknas fakturerbara meddelanden för reläer med samma metod som används för asynkrona entiteter (köer, ämnen och prenumerationer), som beskrevs tidigare. Det finns dock några anmärkningsvärda skillnader.

Att skicka ett meddelande till Azure Relay behandlas som en "fullständig genom"-sändning till den relälyssnare som tar emot meddelandet. Den behandlas inte som en sändningsåtgärd till Azure Relay, följt av en leverans till relälyssningsverktyget. Ett tjänstanrop av typen request-reply (upp till 64 KB) mot en vidarebefordranlyssnare resulterar i två fakturerbara meddelanden: ett fakturerbart meddelande för begäran och ett fakturerbart meddelande för svaret (förutsatt att svaret också är 64 KB eller mindre). Detta skiljer sig från att använda en kö för att förmedla mellan en klient och en tjänst. Om du använder en kö för att förmedla mellan en klient och en tjänst kräver samma mönster för begäran-svar en begäran som skickas till kön, följt av en dequeue/leverans från kön till tjänsten. Detta följs av ett svar som skickas till en annan kö och en dequeue/leverans från kön till klienten. Med samma storleksantaganden i hela (upp till 64 kB) resulterar det medierade kömönstret i 4 fakturerbara meddelanden. Du debiteras för dubbelt så många meddelanden för att implementera samma mönster som du utför med hjälp av relay. Naturligtvis finns det fördelar med att använda köer för att uppnå det här mönstret, till exempel hållbarhet och belastningsutjämning. Dessa fördelar kan motivera den extra kostnaden.

Reläer som öppnas med hjälp av netTCPRelay WCF-bindningen behandlar inte meddelanden som enskilda meddelanden, utan som en dataström som flödar genom systemet. När du använder den här bindningen är det bara avsändaren och lyssnaren som har insyn i inramningen av de enskilda meddelanden som skickas och tas emot. För reläer som använder netTCPRelay-bindningen behandlas alla data som en ström för beräkning av fakturerbara meddelanden. I det här fallet beräknar Service Bus den totala mängden data som skickas eller tas emot via varje enskilt relä på 5 minuter. Sedan delas den totala mängden data med 64 KB för att fastställa antalet fakturerbara meddelanden för det reläet under den tidsperioden.

Säljbudgetar

För alla molntjänster anger Microsoft som standard en aggregerad månatlig användningskvot som beräknas för alla en kunds prenumerationer. Vi förstår att dina behov ibland kan överskrida dessa gränser. Du kan kontakta kundtjänst när som helst, så att vi kan förstå dina behov och justera dessa gränser på rätt sätt. För Service Bus är de aggregerade användningskvoterna följande:

• 5 miljarder meddelanden
• 2 miljoner relätimmar

Även om vi förbehåller oss rätten att inaktivera ett konto som överskrider sina månatliga användningskvoter, tillhandahåller vi ett e-postmeddelande och vi gör flera försök att kontakta kunden innan vi vidtar några åtgärder. Kunder som överskrider dessa kvoter ansvarar fortfarande för överskjutande avgifter.

Namnet på relänamnområdet måste vara mellan 6 och 50 tecken långt.

Om du vill flytta ett namnområde från en Azure-prenumeration till en annan prenumeration kan du antingen använda Azure-portalen eller använda PowerShell-kommandon. Om du vill flytta ett namnområde till en annan prenumeration måste namnområdet redan vara aktivt. Användaren som kör kommandona måste vara administratörsanvändare för både käll- och målprenumerationerna.

Azure-portalen

Information om hur du använder Azure-portalen för att migrera Azure Relay-namnområden från en prenumeration till en annan prenumeration finns i Flytta resurser till en ny resursgrupp eller prenumeration.

PowerShell

Om du vill använda PowerShell för att flytta ett namnområde från en Azure-prenumeration till en annan prenumeration använder du följande sekvens med kommandon. Om du vill köra den här åtgärden måste namnområdet redan vara aktivt och användaren som kör PowerShell-kommandona måste vara administratörsanvändare för både käll- och målprenumerationerna.

# 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

En beskrivning av vanliga undantag och föreslagna åtgärder som du kan vidta finns i Relay-undantag.

Signaturer för delad åtkomst (SAS) är en autentiseringsmekanism som baseras på SHA-256-säkra hashar eller URI:er. Information om hur du genererar egna signaturer i Node.js, PHP, Python, Java, C och C# finns i Service Bus-autentisering med signaturer för delad åtkomst.

Ja. Relay-klienten ansluter till Azure Relay-tjänsten med hjälp av fullständigt kvalificerade domännamn. Kunder kan lägga till en post för *.servicebus.windows.net brandväggar som stöder DNS-godkännande. Det är också möjligt att tillåtalistning av ett specifikt namnområde med hjälp your-namespace-name.servicebus.windows.netav . I det här fallet måste du också tillåtalistning av gatewayerna för ditt namnområde, som du hittar med hjälp av det här PowerShell-skriptet.

Nästa steg

• Skapa ett namnområde
• Kom igång med .NET
• Kom igång med Node