Geo-replikering i Azure SignalR

Företag som söker lokal närvaro eller som kräver ett robust redundanssystem väljer ofta att distribuera tjänster i flera Azure-regioner. Med integreringen av geo-replikering i Azure SignalR har det blivit betydligt enklare att hantera scenarier i flera regioner.

Fördelar med att använda geo-replikering

• Mer motståndskraftigt mot regionalt avbrott: Om ett regionalt avbrott inträffar kommer Azure SignalR DNS att matchas mot felfria repliker i andra regioner.
• Kommunikation mellan regioner. Olika repliker kan kommunicera med varandra som om de vore samma instans.
• Förbättrad nätverkshastighet: Geografiskt spridda klienter ansluter till närmaste replik. Dessa repliker kommunicerar via azures globala nätverksstomme, vilket säkerställer ett snabbt och stabilt nätverk.
• Delade konfigurationer. Alla repliker behåller den primära Azure SignalR Service-resursens konfiguration.

Förutsättningar

• En Azure SignalR Service på Premium-nivå.

Exempel på användningsfall

Contoso är ett socialt medieföretag med sin kundbas spridd över USA och Kanada. För att betjäna dessa kunder och låta dem kommunicera med varandra kör Contoso sina tjänster i USA, centrala. Azure SignalR Service används för att hantera användaranslutningar och underlätta kommunikationen mellan användare. Contosos slutanvändare är mestadels telefonanvändare. På grund av de långa geografiska avstånden kan slutanvändarna i Kanada uppleva hög svarstid och dålig nätverkskvalitet.

Före tillkomsten av geo-replikeringsfunktionen kunde Contoso konfigurera en annan Azure SignalR Service i Canada Central för att betjäna sina kanadensiska användare. Genom att konfigurera en geografiskt närmare Azure SignalR Service har slutanvändarna nu bättre nätverkskvalitet och kortare svarstid.

Men att hantera flera Azure SignalR Services medför vissa utmaningar:

1. En kommunikationsmekanism mellan regioner skulle krävas för att aktivera konversation mellan användare i Kanada och USA.
2. Utvecklingsteamet skulle behöva hantera två separata Azure SignalR Services, var och en med distinkt domän och niska veze.
3. Om ett regionalt avbrott inträffar måste trafiken växlas till en annan region.

Utnyttja geo-replikering

Med den nya geo-replikeringsfunktionen kan Contoso nu upprätta en replik i Canada Central, vilket effektivt övervinner ovan nämnda hinder.

Skapa en SignalR-replik

Portal

Om du vill skapa en replik navigerar du till bladet SignalR-repliker på Azure-portalen och klickar på Lägg till för att skapa en replik. Den aktiveras automatiskt när den skapas.

När du har skapat den kan du visa/redigera repliken på portalen genom att klicka på repliknamnet.

Bicep

Använd Visual Studio Code eller din favoritredigerare för att skapa en fil med följande innehåll och ge den namnet main.bicep:

@description('The name for your SignalR service')
param primaryName string = 'contoso'

@description('The region in which to create your SignalR service')
param primaryLocation string = 'eastus'

@description('Unit count of your SignalR service')
param primaryCapacity int = 1

resource primary 'Microsoft.SignalRService/signalr@2023-08-01-preview' = {
  name: primaryName
  location: primaryLocation
  sku: {
    capacity: primaryCapacity
    name: 'Premium_P1'
  }
  properties: {
  }
}

@description('The name for your SignalR replica')
param replicaName string = 'contoso-westus'

@description('The region in which to create the SignalR replica')
param replicaLocation string = 'westus'

@description('Unit count of the SignalR replica')
param replicaCapacity int = 1

@description('Whether to enable region endpoint for the replica')
param regionEndpointEnabled string = 'Enabled'

resource replica 'Microsoft.SignalRService/signalr/replicas@2023-08-01-preview' = {
  parent: primary
  name: replicaName
  location: replicaLocation
  sku: {
    capacity: replicaCapacity
    name: 'Premium_P1'
  }
  properties: {
    regionEndpointEnabled: regionEndpointEnabled
  }
}

Distribuera Bicep-filen med Azure CLI

az group create --name MyResourceGroup --location eastus
az deployment group create --resource-group MyResourceGroup --template-file main.bicep

Pris- och resursenhet

Varje replik har sin egen unit och autoscale settings.

Replik är en funktion i Premium-nivån i Azure SignalR Service. Varje replik faktureras separat enligt sin egen enhet och utgående trafik. Den kostnadsfria meddelandekvoten beräknas också separat.

I föregående exempel lade Contoso till en replik i Canada Central. Contoso skulle betala för repliken i Canada Central enligt dess enhet och meddelande i Premium Price.

Det kommer att finnas utgående avgifter för utgående trafik mellan regioner. Om ett meddelande överförs mellan repliker och skickas till en klient eller server efter överföringen debiteras det som ett utgående meddelande.

Ta bort en replik

När du har skapat en replik för Azure SignalR Service kan du ta bort den när som helst om den inte längre behövs.

Så här tar du bort en replik i Azure-portalen:

1. Gå till Azure SignalR Service och välj bladet Repliker . Klicka på den replik som du vill ta bort.
2. Klicka på knappen Ta bort på bladet repliköversikt.

Förstå hur SignalR-repliken fungerar

Diagrammet nedan visar en kort bild av SignalR Replicas funktioner:

1. Klienten förhandlar med appservern och tar emot en omdirigering till Azure SignalR-tjänsten. Den löser sedan SignalR-tjänstens fullständigt kvalificerade domännamn (FQDN) – contoso.service.signalr.net. Det här fullständiga domännamnet pekar på en Traffic Manager som returnerar det kanoniska namnet (CNAME) för den närmaste regionala SignalR-instansen.
2. Med detta CNAME upprättar klienten en anslutning till den regionala instansen (repliken).
3. De två replikerna synkroniserar data med varandra. Meddelanden som skickas till en replik överförs till andra repliker om det behövs.
4. Om en replik misslyckas med hälsokontrollen som utförs av Traffic Manager (TM) utesluter TM slutpunkten för den misslyckade instansen från dess domänmatchningsprocess. Mer information finns i nedan Återhämtning och haveriberedskap

Kommentar

• I dataplanet fungerar en primär Azure SignalR-resurs identiskt med replikerna

Återhämtning och haveriberedskap

Azure SignalR Service använder en trafikhanterare för hälsokontroller och DNS-matchning mot sina repliker. När alla repliker fungerar som de ska dirigeras klienterna under normala omständigheter till närmaste replik. Till exempel:

• Klienter nära eastus dirigeras till repliken som finns i eastus.
• På samma sätt dirigeras klienter nära westus till repliken i westus.

I händelse av ett regionalt avbrott i eastus (se nedan) identifierar trafikhanteraren hälsokontrollfelet för den regionen. Sedan undantas den här felaktiga replikens DNS från trafikhanterarens DNS-matchningsresultat. Efter en TTL-varaktighet (Time-to-Live) för DNS, som är inställd på 90 sekunder, omdirigeras klienter i eastus för att ansluta till repliken i westus.

När problemet i eastus har lösts och regionen är online igen lyckas hälsokontrollen. Klienter i eastus dirigeras sedan återigen till repliken i deras region. Den här övergången är smidig eftersom de anslutna klienterna inte påverkas förrän de befintliga anslutningarna har stängts.

Den här redundans- och återställningsprocessen är automatisk och kräver inga manuella åtgärder.

För serveranslutningar fungerar redundans och återställning på samma sätt som för klientanslutningar.

Kommentar

• Den här redundansmekanismen gäller för Azure SignalR-tjänsten. Regionala avbrott för appservern ligger utanför det här dokumentets omfång.

Inaktivera eller aktivera replikslutpunkten

När du konfigurerar en replik kan du aktivera eller inaktivera dess slutpunkt. Om den är inaktiverad innehåller den primära FQDN:ns DNS-matchning inte repliken, och därför dirigeras inte trafiken till den.

Du kan också aktivera inaktivera slutpunkten när den har skapats. På den primära resursens replikblad klickar du på ellipsknappen till höger om repliken och väljer Aktivera slutpunkt eller Inaktivera slutpunkt:

Innan du tar bort en replikering bör du överväga att inaktivera slutpunkten först. Med tiden kopplas befintliga anslutningar från. Eftersom inga nya anslutningar kommer blir replikeringen äntligen inaktiv. Detta säkerställer en sömlös borttagningsprocess.

Den här funktionen är också användbar för felsökning av regionala problem.

Kommentar

• På grund av DNS-cachen kan det ta flera minuter innan DNS-uppdateringen börjar gälla.
• Befintliga anslutningar påverkas inte förrän de kopplas från.

Påverkan på prestanda när repliker har lagts till

När repliker har aktiverats distribueras klienter naturligt baserat på deras geografiska platser. SignalR tar på sig ansvaret för att synkronisera data mellan dessa repliker, men du är glad över att veta att de associerade kostnaderna för serverbelastning är minimala för de flesta vanliga användningsfall.

Mer specifikt, om ditt program vanligtvis sänder till större grupper (storlek >10) eller en enda anslutning, är prestandapåverkan av synkronisering knappt märkbar. Om du meddelar små grupper (storlek < 10) eller enskilda användare kanske du märker lite mer omkostnader för synkronisering.

För att säkerställa effektiv redundanshantering rekommenderar vi att du anger varje repliks enhetsstorlek för att hantera all trafik. Du kan också aktivera automatisk skalning för att hantera detta.

Mer prestandautvärdering finns i Prestanda.