Tolerantie en herstel na noodgevallen in Azure SignalR Service

Tolerantie en herstel na noodgevallen is een algemene behoefte voor online systemen. Azure SignalR Service biedt al een beschikbaarheid van 99,9%, maar het is nog steeds een regionale service. Wanneer er sprake is van een storing in de hele regio, voert uw service-exemplaar geen failover uit naar een andere regio, omdat deze altijd wordt uitgevoerd in de ene regio.

Voor regionaal herstel na noodgevallen raden we de volgende twee benaderingen aan:

• Geo-replicatie inschakelen (eenvoudige manier). Met deze functie wordt automatisch regionale failover voor u afgehandeld. Wanneer deze optie is ingeschakeld, is er slechts één Azure SignalR-exemplaar en worden er geen codewijzigingen geïntroduceerd. Controleer geo-replicatie op details.
• Gebruik meerdere eindpunten in de Service-SDK. Onze service-SDK ondersteunt meerdere SignalR-service-exemplaren en schakelt automatisch over naar andere exemplaren wanneer sommige exemplaren niet beschikbaar zijn. Met deze functie kunt u herstellen wanneer er een noodgeval plaatsvindt, maar u moet zelf de juiste systeemtopologie instellen. In dit document leert u hoe u dit doet.

Architectuur met hoge beschikbaarheid voor SignalR-service

Om tolerantie tussen regio's voor SignalR-service te garanderen, moet u meerdere service-exemplaren in verschillende regio's instellen. Dus wanneer één regio niet actief is, kunnen de andere worden gebruikt als back-up. Wanneer app-servers verbinding maken met meerdere service-exemplaren, zijn er twee rollen, primair en secundair. Primair is een instantie die verantwoordelijk is voor het ontvangen van onlineverkeer, terwijl secundaire instantie fungeert als een terugvalinstantie die volledig functioneel is. In onze SDK-implementatie worden alleen primaire eindpunten geretourneerd, zodat clients alleen verbinding maken met primaire eindpunten in normale gevallen. Maar wanneer het primaire exemplaar niet beschikbaar is, retourneert onderhandelen secundaire eindpunten, zodat de client nog steeds verbindingen kan maken. Primaire instantie en app-server zijn verbonden via normale serververbindingen, maar secundaire instantie en app-server zijn verbonden via een speciaal type verbinding genaamd zwakke verbinding. Een onderscheidend kenmerk van een zwakke verbinding is dat het geen clientverbindingsroutering kan accepteren vanwege de locatie van het secundaire exemplaar in een andere regio. Het routeren van een client naar een andere regio is geen optimale keuze (verhoogt de latentie).

Een service-exemplaar kan verschillende rollen hebben bij het verbinden met meerdere app-servers. Een typische installatie voor scenario's tussen regio's is het hebben van twee of meer paren SignalR-service-exemplaren en app-servers. Binnen elke combinatie bevinden de app-server en SignalR-service zich in dezelfde regio en is SignalR-service verbonden met de app-server als een primaire rol. Tussen alle paren zijn de app-server en SignalR-service ook verbonden, maar SignalR verandert in secundair bij het verbinden met de server in een andere regio.

Berichten van de ene server kunnen nog steeds worden afgeleverd bij alle clients als alle appservers en SignalR service-exemplaren onderling verbonden zijn met deze topologie. Maar wanneer een client is verbonden, wordt deze gerouteerd naar de app-server in dezelfde regio om een optimale netwerklatentie te bereiken.

In het volgende diagram ziet u een dergelijke topologie:

Meerdere SignalR-service-exemplaren configureren

Meerdere SignalR-service-exemplaren worden ondersteund op zowel app-servers als Azure Functions.

Zodra u SignalR-service- en app-servers/Azure Functions in elke regio hebt gemaakt, kunt u uw app-servers/Azure Functions configureren om verbinding te maken met alle SignalR-service-exemplaren.

Configureren op app-servers

Er zijn twee manieren waarop u dit kunt doen:

Via config

U moet al weten hoe u SignalR-service verbindingsreeks instelt via omgevingsvariabelen/app-instellingen/web.cofig, in een configuratievermelding met de naam Azure:SignalR:ConnectionString. Als u meerdere eindpunten hebt, kunt u ze instellen in meerdere configuratie-items, elk in de volgende indeling:

Azure:SignalR:ConnectionString:<name>:<role>

In de Verbinding maken ionString <name> is dit de naam van het eindpunt en <role> de rol (primair of secundair). De naam is optioneel, maar het is handig als u het routeringsgedrag tussen meerdere eindpunten verder wilt aanpassen.

Via code

Als u de verbindingsreeks s liever ergens anders opslaat, kunt u ze ook in uw code lezen en gebruiken als parameters bij het aanroepen AddAzureSignalR() (in ASP.NET Core) of MapAzureSignalR() (in ASP.NET).

Dit is de voorbeeldcode:

ASP.NET Core:

services.AddSignalR()
        .AddAzureSignalR(options => options.Endpoints = new ServiceEndpoint[]
        {
            new ServiceEndpoint("<connection_string1>", EndpointType.Primary, "region1"),
            new ServiceEndpoint("<connection_string2>", EndpointType.Secondary, "region2"),
        });

ASP.NET:

app.MapAzureSignalR(GetType().FullName, hub,  options => options.Endpoints = new ServiceEndpoint[]
    {
        new ServiceEndpoint("<connection_string1>", EndpointType.Primary, "region1"),
        new ServiceEndpoint("<connection_string2>", EndpointType.Secondary, "region2"),
    };

U kunt meerdere primaire of secundaire exemplaren configureren. Als er meerdere primaire en/of secundaire exemplaren zijn, retourneert u een eindpunt in de volgende volgorde:

1. Als er ten minste één primair exemplaar online is, retourneert u een willekeurig primair online exemplaar.
2. Als alle primaire exemplaren niet beschikbaar zijn, retourneert u een willekeurige secundaire online-instantie.

Configureren in Azure Functions

Zie dit artikel.

Failover-volgorde en best practice

U hebt nu de instelling van de juiste systeem-topologie. Wanneer één SignalR-service-exemplaar uitvalt, wordt onlineverkeer doorgestuurd naar andere exemplaren. Dit gebeurt wanneer een primair exemplaar uitvalt (en na enige tijd herstelt):

1. Het primaire service-exemplaar is niet beschikbaar, alle serververbindingen op dit exemplaar worden verwijderd.
2. Alle servers die met dit exemplaar zijn verbonden, markeren het als offline en onderhandelen stopt met het retourneren van dit eindpunt en beginnen met het retourneren van het secundaire eindpunt.
3. Alle clientverbindingen op dit exemplaar zijn ook gesloten, clients vervolgens opnieuw verbinding maken. Omdat app-servers nu een secundair eindpunt retourneren, maken clients verbinding met het secundaire exemplaar.
4. Het secundaire exemplaar neemt nu alle online verkeer over. Alle berichten van de server aan clients kunnen nog steeds worden afgeleverd als de secundaire is verbonden met alle app-servers. Maar de client naar server-berichten worden alleen naar de app-server in dezelfde regio gerouteerd.
5. Nadat de primaire instantie is hersteld en weer online is, brengt de app-server opnieuw verbindingen tot stand en markeert deze als online. Onderhandelen retourneert nu opnieuw het primaire eindpunt, zodat nieuwe clients weer zijn verbonden met de primaire. Bestaande clients worden echter niet weggezet en worden nog steeds doorgestuurd naar secundaire clients totdat ze zichzelf loskoppelen.

In de diagrammen hieronder ziet u hoe failover wordt uitgevoerd in de SignalR-service:

Fig.1 Vóór failover

Fig.2 Na failover

Fig.3 Korte tijd na primaire herstelbewerkingen

In normale gevallen ziet u dat alleen de primaire app-server en SignalR-service online verkeer hebben (in het blauw). Na een failover zijn de secundaire app-server en SignalR-service ook van kracht. Nadat de primaire SignalR-service weer online is, worden nieuwe clients verbonden met de primaire SignalR. Maar bestaande clients hebben nog steeds verbinding naar secundair, waardoor beide exemplaren verkeer hebben. Nadat alle bestaande clients de verbinding verbreken, is uw systeem weer normaal (figuur 1).

Er zijn twee belangrijke patronen voor het implementeren van een regio-overkoepelende architectuur voor hoge beschikbaarheid:

1. Het eerste is een combinatie van een app-server en SignalR-service-exemplaar die al het online verkeer aannemen, en een ander paar als back-up (actief/passief genoemd, weergegeven in de figuur 1).
2. Het andere is om twee (of meer) paren van app-servers en SignalR service-exemplaren te hebben, die elk deelnemen aan het online-verkeer en fungeren als back-up voor andere paren (actief/actief genoemd, vergelijkbaar met Fig.3).

De SignalR-service kan beide patronen ondersteunen, het belangrijkste verschil is hoe u app-servers implementeert. Als app-servers actief/passief zijn, is SignalR-service ook actief/passief (omdat de primaire app-server alleen het primaire SignalR-service-exemplaar retourneert). Als app-servers actief/actief zijn, is SignalR-service ook actief/actief (omdat alle app-servers hun eigen primaire SignalR-exemplaren retourneren, zodat ze allemaal verkeer kunnen krijgen).

Let op, ongeacht welke patronen u kiest, u moet elk SignalR-service-exemplaar als primair verbinden met een app-server.

Vanwege de aard van SignalR-verbinding (het is een lange verbinding), ondervinden clients ook een storing in de verbinding wanneer zich een noodgeval en failover voordoet. U moet dergelijke zaken aan de clientzijde afhandelen om deze transparant te maken voor uw eindklanten. Bijvoorbeeld, opnieuw verbinden nadat een verbinding is gesloten.

Een failover testen

Volg de stappen om de failover te activeren:

1. Schakel openbare netwerktoegang uit op het tabblad Netwerken voor de primaire resource in de portal. Als voor de resource een privénetwerk is ingeschakeld, gebruikt u regels voor toegangsbeheer om al het verkeer te weigeren.
2. Start de primaire resource opnieuw op.

Volgende stappen

In dit artikel hebt u geleerd hoe u uw toepassing configureert om tolerantie voor SignalR-service te bereiken. Voor meer informatie over server/client-verbindingen en verbindingsroutering in SignalR-service, kunt u dit artikel voor SignalR-service-inhoud lezen.

Voor schaalscenario's zoals sharding die meerdere exemplaren samen gebruikt om een groot aantal verbindingen af te handelen, leest u hoe u meerdere exemplaren kunt schalen.

Lees voor meer informatie over het configureren van Azure Functions met meerdere SignalR-service-exemplaren meerdere ondersteuning voor Azure SignalR Service-exemplaren in Azure Functions.