Geo-replicatie in Azure SignalR

Bedrijven die lokale aanwezigheid zoeken of een robuust failoversysteem vereisen, kiezen er vaak voor om services in meerdere Azure-regio's te implementeren. Dankzij de integratie van geo-replicatie in Azure SignalR is het beheren van scenario's met meerdere regio's aanzienlijk eenvoudiger geworden.

Voordelen van het gebruik van geo-replicatie

• Toleranter voor regionale storingen: als er een regionale storing optreedt, wordt azure SignalR DNS omgezet in gezonde replica's in andere regio's.
• Communicatie tussen regio's. Verschillende replica's kunnen met elkaar communiceren alsof ze hetzelfde exemplaar zijn.
• Verbeterde netwerksnelheid: geografisch verspreide clients maken verbinding met de dichtstbijzijnde replica. Deze replica's communiceren via de backbone van het wereldwijde Azure-netwerk en zorgen voor snelle en stabiele netwerken.
• Gedeelde configuraties. Alle replica's behouden de configuratie van de primaire Azure SignalR Service-resource.

Vereisten

• Een Azure SignalR-service in de Premium-laag.

Voorbeeld van een toepassing

Contoso is een sociaal mediabedrijf met zijn klantenbestand verspreid over de VS en Canada. Om deze klanten te bedienen en ze met elkaar te laten communiceren, voert Contoso de services uit in VS - centraal. Azure SignalR Service wordt gebruikt om gebruikersverbindingen te verwerken en communicatie tussen gebruikers te vergemakkelijken. Eindgebruikers van Contoso zijn meestal telefoongebruikers. Vanwege de lange geografische afstanden kunnen eindgebruikers in Canada te maken hebben met een hoge latentie en een slechte netwerkkwaliteit.

Vóór de komst van de functie voor geo-replicatie kon Contoso een andere Azure SignalR-service in Canada Central instellen om de Canadese gebruikers te bedienen. Door een geografisch dichtere Azure SignalR-service in te stellen, hebben eindgebruikers nu betere netwerkkwaliteit en lagere latentie.

Het beheren van meerdere Azure SignalR-services brengt echter enkele uitdagingen met zich mee:

1. Er is een communicatiemechanisme tussen regio's vereist om gesprekken tussen Canada en Amerikaanse gebruikers mogelijk te maken.
2. Het ontwikkelteam moet twee afzonderlijke Azure SignalR Services beheren, elk met een afzonderlijk domein en verbindingsreeks.
3. Als er een regionale storing optreedt, moet het verkeer worden overgeschakeld naar een andere regio.

Geo-replicatie benutten

Met de nieuwe functie voor geo-replicatie kan Contoso nu een replica maken in Canada - centraal, waarmee de bovenstaande horden effectief worden overschreden.

Een SignalR-replica maken

Portal

Als u een replica wilt maken, gaat u naar de blade SignalR Replicas in Azure Portal en klikt u op Toevoegen om een replica te maken. Deze wordt automatisch ingeschakeld bij het maken.

Nadat u de replica hebt gemaakt, kunt u de replica in de portal weergeven/bewerken door op de naam van de replica te klikken.

Bicep

Gebruik Visual Studio Code of uw favoriete editor om een bestand te maken met de volgende inhoud en geef het main.bicep een naam:

@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
  }
}

Het Bicep-bestand implementeren met behulp van Azure CLI

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

Notitie

• Het aantal replica's is momenteel beperkt tot maximaal 8 per primaire resource.

Prijzen en resource-eenheid

Elke replica heeft een eigen unit en autoscale settings.

Replica is een functie van de Premium-laag van Azure SignalR Service. Elke replica wordt afzonderlijk gefactureerd op basis van een eigen eenheid en uitgaand verkeer. Het quotum voor gratis berichten wordt ook afzonderlijk berekend.

In het voorgaande voorbeeld heeft Contoso één replica toegevoegd in Canada Central. Contoso betaalt voor de replica in Canada Central op basis van de eenheid en het bericht in Premium Price.

Er worden uitgaande kosten in rekening gebracht voor uitgaand verkeer tussen regio's. Als een bericht wordt overgebracht over replica's en na de overdracht naar een client of server is verzonden, wordt dit gefactureerd als een uitgaand bericht.

Een replica verwijderen

Nadat u een replica voor uw Azure SignalR-service hebt gemaakt, kunt u deze op elk gewenst moment verwijderen als deze niet meer nodig is.

Ga als volgt te werk om een replica te verwijderen in Azure Portal:

1. Navigeer naar uw Azure SignalR-service en selecteer de blade Replica's . Klik op de replica die u wilt verwijderen.
2. Klik op de knop Verwijderen op de blade Overzicht van replica's.

Begrijpen hoe de SignalR-replica werkt

In het onderstaande diagram ziet u een korte illustratie van de functionaliteit van SignalR Replica's:

1. De client onderhandelt met de app-server en ontvangt een omleiding naar de Azure SignalR-service. Vervolgens wordt de FQDN (Fully Qualified Domain Name) van de SignalR-service omgezet. contoso.service.signalr.net Deze FQDN verwijst naar een Traffic Manager, die de Canonical Name (CNAME) van het dichtstbijzijnde regionale SignalR-exemplaar retourneert.
2. Met deze CNAME brengt de client een verbinding tot stand met het regionale exemplaar (Replica).
3. De twee replica's synchroniseren gegevens met elkaar. Berichten die naar de ene replica worden verzonden, worden indien nodig overgebracht naar andere replica's.
4. Als een replica de statuscontrole mislukt die wordt uitgevoerd door Traffic Manager (TM), sluit de TM het eindpunt van het mislukte exemplaar uit van het domeinomzettingsproces. Raadpleeg de onderstaande tolerantie en herstel na noodgevallen voor meer informatie

Notitie

• In het gegevensvlak werkt een primaire Azure SignalR-resource identiek aan de replica's ervan

Tolerantie en herstel na noodgevallen

Azure SignalR Service maakt gebruik van traffic manager voor statuscontroles en DNS-omzetting naar de replica's. Onder normale omstandigheden, wanneer alle replica's goed functioneren, worden clients omgeleid naar de dichtstbijzijnde replica. Bijvoorbeeld:

• Clients in de buurt eastus worden omgeleid naar de replica in eastus.
• Op dezelfde manier worden clients in de buurt westus omgeleid naar de replica in westus.

In het geval van een regionale storing in eastus (hieronder geïllustreerd), detecteert traffic manager de statuscontrolefout voor die regio. Vervolgens wordt de DNS van deze defecte replica uitgesloten van de DNS-omzettingsresultaten van traffic manager. Na een TTL-duur (Time-to-Live) van DNS, die is ingesteld op 90 seconden, worden clients eastus omgeleid om verbinding te maken met de replica in westus.

Zodra het probleem eastus is opgelost en de regio weer online is, slaagt de statuscontrole. Clients in eastus worden vervolgens opnieuw omgeleid naar de replica in hun regio. Deze overgang verloopt soepel omdat de verbonden clients pas worden beïnvloed nadat deze bestaande verbindingen zijn gesloten.

Dit failover- en herstelproces is automatisch en vereist geen handmatige tussenkomst.

Voor serververbindingen werkt de failover en het herstel op dezelfde manier als voor clientverbindingen.

Notitie

• Dit failovermechanisme is bedoeld voor de Azure SignalR-service. Regionale storingen van de app-server vallen buiten het bereik van dit document.

Het replica-eindpunt uitschakelen of inschakelen

Bij het instellen van een replica hebt u de mogelijkheid om het eindpunt ervan in of uit te schakelen. Als deze optie is uitgeschakeld, bevat de DNS-resolutie van de primaire FQDN de replica niet en wordt er daarom geen verkeer naar omgeleid.

U kunt het eindpunt ook uitschakelen nadat het is gemaakt. Klik op de blade replica's van de primaire resource op de knop met het beletselteken aan de rechterkant van de replica en kies Eindpunt inschakelen of Eindpunt uitschakelen:

Voordat u een replicatie verwijdert, kunt u overwegen eerst het eindpunt ervan uit te schakelen. Na verloop van tijd worden bestaande verbindingen verbroken. Omdat er geen nieuwe verbindingen komen, wordt de replicatie definitief inactief. Dit zorgt voor een naadloos verwijderingsproces.

Deze functie is ook handig voor het oplossen van regionale problemen.

Notitie

• Vanwege de DNS-cache kan het enkele minuten duren voordat de DNS-update van kracht wordt.
• Bestaande verbindingen blijven ongewijzigd totdat de verbinding wordt verbroken.

Invloed op prestaties na het toevoegen van replica's

Nadat replica's zijn ingeschakeld, distribueren clients op natuurlijke wijze op basis van hun geografische locaties. Hoewel SignalR de verantwoordelijkheid neemt om gegevens over deze replica's te synchroniseren, zult u blij zijn dat de bijbehorende overhead bij serverbelasting minimaal is voor de meest voorkomende gebruiksscenario's.

Als uw toepassing doorgaans uitzendt naar grotere groepen (grootte >10) of één verbinding, is de invloed van de prestaties van synchronisatie nauwelijks zichtbaar. Als u kleine groepen (grootte < 10) of afzonderlijke gebruikers wilt sturen, merkt u mogelijk wat meer synchronisatieoverhead.

Om effectief failoverbeheer te garanderen, is het raadzaam om de eenheidsgrootte van elke replica in te stellen om al het verkeer te verwerken. U kunt ook automatisch schalen inschakelen om dit te beheren.

Raadpleeg Prestaties voor meer prestatie-evaluatie.

Niet-overgenomen en overgenomen configuraties

Replica's nemen de meeste configuraties over van de primaire resource; Sommige instellingen moeten echter rechtstreeks op de replica's worden geconfigureerd. Hieronder ziet u de lijst met deze configuraties:

1. SKU: Elke replica heeft een eigen SKU-naam en eenheidsgrootte. De regels voor automatisch schalen voor replica's moeten afzonderlijk worden geconfigureerd op basis van hun afzonderlijke metrische gegevens.
2. Gedeelde privé-eindpunten: hoewel gedeelde privé-eindpunten automatisch worden gerepliceerd naar replica's, zijn afzonderlijke goedkeuringen vereist voor privékoppelingsresources. Als u gedeelde privé-eindpunten wilt toevoegen of verwijderen, beheert u deze op de primaire resource. Schakel de replica pas in nadat het gedeelde privé-eindpunt is goedgekeurd.
3. Doelinstellingen voor logboeken. Als deze niet is geconfigureerd op de replica's, worden alleen logboeken van de primaire resource overgedragen.
4. Waarschuwingen.

Alle andere configuraties worden overgenomen van de primaire resource. Bijvoorbeeld toegangssleutels, identiteit, toepassingsfirewall, aangepaste domeinen, privé-eindpunten en toegangsbeheer.