Återhämtning och haveriberedskap i Azure SignalR Service

Återhämtning och haveriberedskap är ett vanligt behov för onlinesystem. Azure SignalR Service tillhandahåller redan 99,9 % tillgänglighet, men det är fortfarande en regional tjänst. När det uppstår ett regionomfattande avbrott redundansväxlar inte tjänstinstansen till en annan region eftersom den alltid körs i en region.

För regional haveriberedskap rekommenderar vi följande två metoder:

• Aktivera geo-replikering (enkelt sätt). Den här funktionen hanterar regional redundans åt dig automatiskt. När det är aktiverat finns det bara en Azure SignalR-instans och inga kodändringar introduceras. Mer information finns i geo-replikering .
• Använd flera slutpunkter i Service SDK. Vår tjänst-SDK stöder flera SignalR-tjänstinstanser och växlar automatiskt till andra instanser när vissa av dem inte är tillgängliga. Med den här funktionen kan du återställa när en katastrof inträffar, men du måste konfigurera rätt systemtopologi själv. Du lär dig hur du gör det i det här dokumentet.

Arkitektur med hög tillgänglighet för SignalR Service

För att säkerställa återhämtning mellan regioner för SignalR-tjänsten måste du konfigurera flera tjänstinstanser i olika regioner. När en region är nere kan de andra därmed användas som reserver. När appservrar ansluter till flera tjänstinstanser finns det två roller, primära och sekundära. Primär är en instans som ansvarar för att ta emot onlinetrafik, medan sekundär fungerar som en reservinstans som är fullt fungerande. I vår SDK-implementering förhandlar du bara returnerar primära slutpunkter, så klienter ansluter endast till primära slutpunkter i normala fall. Men när den primära instansen är nere returnerar negotiate sekundära slutpunkter så att klienten fortfarande kan upprätta anslutningar. Den primära instansen och appservern är anslutna via normala serveranslutningar, men den sekundära instansen och appservern är anslutna via en särskild typ av anslutning som kallas svag anslutning. En särskiljande egenskap hos en svag anslutning är att den inte kan acceptera klientanslutningsroutning på grund av platsen för den sekundära instansen i en annan region. Att dirigera en klient till en annan region är inte ett optimalt val (ökar svarstiden).

En tjänstinstans kan ha olika roller vid anslutning till flera appservrar. En typisk konfiguration för scenario mellan regioner är att ha två eller flera par SignalR-tjänstinstanser och appservrar. I varje par finns appservern och SignalR Service i samma region, och SignalR Service är ansluten till appservern som en primär roll. Appservern och SignalR Service är även anslutna mellan varje par app, men SignalR blir en sekundär vid anslutning till en server i en annan region.

Med den här topologin kan meddelanden från en server fortfarande levereras till alla klienter eftersom alla appservrar och SignalR Service-instanser är sammankopplade. Men när en klient är ansluten dirigeras den till appservern i samma region för att uppnå optimal nätverksfördröjning.

Följande diagram illustrerar en sådan topologi:

Konfigurera flera SignalR-tjänstinstanser

Flera SignalR-tjänstinstanser stöds på både appservrar och Azure Functions.

När du har skapat SignalR-tjänsten och appservrar/Azure Functions i varje region kan du konfigurera dina appservrar/Azure Functions för att ansluta till alla SignalR-tjänstinstanser.

Konfigurera på appservrar

Det finns två sätt att göra det:

Med config

Du bör redan veta hur du ställer in SignalR-tjänsten anslutningssträng via miljövariabler/appinställningar/web.cofig i en konfigurationspost med namnet Azure:SignalR:ConnectionString. Om du har flera slutpunkter kan du ange dem i flera config-poster, var och en i följande format:

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

I Anslut ionString <name> är namnet på slutpunkten och <role> dess roll (primär eller sekundär). Namnet är valfritt, men det är användbart om du vill anpassa routningsbeteendet ytterligare mellan flera slutpunkter.

Med kod

Om du föredrar att lagra anslutningssträng någon annanstans kan du också läsa dem i koden och använda dem som parametrar när du anropar AddAzureSignalR() (i ASP.NET Core) eller MapAzureSignalR() (i ASP.NET).

Här är exempelkoden:

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"),
    };

Du kan konfigurera flera primära eller sekundära instanser. Om det finns flera primära och/eller sekundära instanser returnerar negotiate en slutpunkt i följande ordning:

1. Om det finns minst en primär instans online returnerar du en slumpmässig primär onlineinstans.
2. Om alla primära instanser är nere returnerar du en slumpmässig sekundär onlineinstans.

Konfigurera på Azure Functions

Se den här artikeln.

Redundanssekvens och bästa praxis

Nu har du rätt konfiguration av systemtopologi. När en SignalR-tjänstinstans är nere dirigeras onlinetrafik till andra instanser. Här är vad som händer när en primär instans är nere (och återställs efter en tid):

1. Den primära tjänstinstansen är nere. Alla serveranslutningar på den här instansen tas bort.
2. Alla servrar som är anslutna till den här instansen markerar den som offline och förhandlar slutar returnera den här slutpunkten och börjar returnera den sekundära slutpunkten.
3. Alla klientanslutningar på den här instansen stängs också, klienterna återansluts sedan. Eftersom appservrar nu returnerar en sekundär slutpunkt ansluter klienterna till den sekundära instansen.
4. Nu tar den sekundära instansen all onlinetrafik. Alla meddelanden från servern till klienter kan fortfarande levereras eftersom den sekundära är ansluten till alla appservrar. Däremot dirigeras klient-till-server-meddelanden endast till appservern i samma region.
5. När den primära instansen har återställts och är online igen återupprättar appservern anslutningarna till den och markerar den som online. Negotiate returnerar nu den primära slutpunkten igen så att nya klienter är anslutna tillbaka till den primära. Men befintliga klienter släpper inte och dirigeras fortfarande till sekundära förrän de kopplar från sig själva.

Nedanstående diagram illustrerar hur redundansväxling sker i SignalR Service:

Fig.1 Före redundansväxling

Fig.2 Efter redundansväxling

Fig.3 Kort tid efter primär återställning

I det normala fallet har bara den primära appservern och SignalR Service onlinetrafik (i blått). Efter redundansväxling blir den sekundära appservern och SignalR Service också aktiva. När den primära SignalR Service är online igen ansluter nya klienter till den primära SignalR. Men befintliga klienter ansluter fortfarande till den sekundära så att båda instanserna har trafik. När alla befintliga klienter har kopplats från återgår systemet till det normala (fig.1).

Det finns två huvudsakliga mönster för att implementera en arkitektur med hög tillgänglighet mellan regioner:

1. Det första mönstret är att ha ett par med en appserver och en SignalR Service-instans som tar all onlinetrafik samt ett annat par som reserv (detta kallas aktiv/passiv och illustreras i Fig.1).
2. Det andra mönstret är att ha två (eller fler) par med appservrar och SignalR Service-instanser som var och en tar en del av onlinetrafiken och fungerar som reserv för andra par (detta kallas aktiv/aktiv och liknar fig.3).

SignalR Service har stöd för både mönstren. Den största skillnaden är hur du implementerar appservrar. Om appservrarna är aktiva/passiva är SignalR-tjänsten också aktiv/passiv (eftersom den primära appservern endast returnerar sin primära SignalR-tjänstinstans). Om appservrar är aktiva/aktiva är SignalR-tjänsten också aktiv/aktiv (eftersom alla appservrar returnerar sina egna primära SignalR-instanser, så att alla kan få trafik).

Observera att oavsett vilka mönster du väljer att använda måste du ansluta varje SignalR-tjänstinstans till en appserver som primär.

Även på grund av signalR-anslutningens karaktär (det är en lång anslutning) uppstår anslutningsfel för klienter när det uppstår en katastrof och redundansväxling sker. Du måste hantera sådana fall på klientsidan för att göra det transparent för dina slutkunder. Till exempel bör du återansluta när en anslutning har kopplats från.

Så här testar du en redundansväxling

Följ stegen för att utlösa redundansväxlingen:

1. Inaktivera åtkomst till offentligt nätverk på fliken Nätverk för den primära resursen i portalen. Om resursen har aktiverat privat nätverk använder du åtkomstkontrollregler för att neka all trafik.
2. Starta om den primära resursen.

Nästa steg

I den här artikeln har du lärt dig hur du konfigurerar programmet för att uppnå återhämtning för SignalR-tjänsten. Om du vill få mer information om server/klient-anslutning och anslutningsroutning i SignalR Service kan du läsa den här artikeln om hur SignalR Service fungerar på insidan.

För skalningsscenarier som horisontell partitionering som använder flera instanser tillsammans för att hantera ett stort antal anslutningar läser du hur du skalar flera instanser.

Mer information om hur du konfigurerar Azure Functions med flera SignalR-tjänstinstanser finns i flera Azure SignalR Service-instanser i Azure Functions.