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

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.

Diagram van het gebruik van één Azure SignalR-exemplaar om verkeer van twee landen te verwerken.

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.

Diagram van het gebruik van twee Azure SignalR-exemplaren om verkeer van twee landen te verwerken.

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.

Diagram van het gebruik van één Azure SignalR-exemplaar met replica om verkeer van twee landen te verwerken.

Een SignalR-replica maken

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.

Schermopname van het maken van een replica voor Azure SignalR in de portal.

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

Schermopname van de overzichtsblade van de Azure SignalR-replicaresource.

Prijzen en resource-eenheid

Elke replica heeft een eigenunit 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:

Diagram van de boog van Azure SignalR-replica.

  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.

Diagram van failover van Azure SignalR-replica.

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.

Diagram van herstel van azure SignalR-replicafailover.

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.

Diagram van azure SignalR-replica-eindpuntinstelling.

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:

Diagram van het wijzigen van het azure SignalR-replicaeindpunt.

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.