Delen via

Tolerantie en herstel na noodgevallen in Azure SignalR Service

  • Artikel

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:

Diagram toont twee regio's elk met een app-server en een SignalR-service, waarbij elke server is gekoppeld aan de SignalR-service in de regio als primair en met de service in de andere regio als secundair.

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.

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 ConnectionString <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.

Voor Azure Functions SignalR-bindingen

Als u meerdere SignalR Service-exemplaren wilt inschakelen, moet u het volgende doen:

  1. Gebruik Persistent transporttype.

    Het standaardtransporttype is Transient de modus. Voeg de volgende vermelding toe aan uw local.settings.json bestand of de toepassingsinstelling in Azure.

    {
    "AzureSignalRServiceTransportType":"Persistent"
}

    Notitie

    Wanneer u overschakelt van Transient de modus naar Persistent de modus, kan het gedrag van JSON-serialisatie worden gewijzigd, omdat onder Transient de modus bibliotheek Newtonsoft.Json wordt gebruikt om argumenten van hubmethoden te serialiseren, maar onder Persistent de modus wordt System.Text.Json bibliotheek als standaard gebruikt. System.Text.Json heeft enkele belangrijke verschillen in standaardgedrag met Newtonsoft.Json. Als u de modus wilt Persistent gebruikenNewtonsoft.Json, kunt u een configuratie-item toevoegen: "Azure:SignalR:HubProtocol":"NewtonsoftJson" in local.settings.json bestand of Azure__SignalR__HubProtocol=NewtonsoftJson in Azure Portal.

  2. Configureer meerdere vermeldingen voor SignalR Service-eindpunten in uw configuratie.

    We gebruiken een ServiceEndpoint object om een SignalR Service-exemplaar weer te geven. U kunt een service-eindpunt definiëren met <EndpointName> <EndpointType> de vermeldingssleutel en de verbindingsreeks in de invoerwaarde. De sleutels hebben de volgende indeling:

    Azure:SignalR:Endpoints:<EndpointName>:<EndpointType>

    <EndpointType> is optioneel en wordt standaard ingesteld op primary. Zie de voorbeelden hieronder:

    {
    "Azure:SignalR:Endpoints:EastUs":"<ConnectionString>",

    "Azure:SignalR:Endpoints:EastUs2:Secondary":"<ConnectionString>",

    "Azure:SignalR:Endpoints:WestUs:Primary":"<ConnectionString>"
}

    Notitie

    • Wanneer u Azure SignalR-eindpunten configureert in de App Service in Azure Portal, vergeet dan niet om het dubbele onderstrepingsteken in de sleutels te vervangen ":" "__". Zie omgevingsvariabelen om redenen.

    • De verbindingsreeks die is geconfigureerd met de sleutel {ConnectionStringSetting} (standaard ingesteld op 'AzureSignalRConnectionString') wordt ook herkend als een primair service-eindpunt met een lege naam. Deze configuratiestijl wordt echter niet aanbevolen voor meerdere eindpunten.

Voor beheer-SDK

Meerdere eindpunten toevoegen vanuit de configuratie

Configureer met sleutel Azure:SignalR:Endpoints voor SignalR Service verbindingsreeks. De sleutel moet de indeling Azure:SignalR:Endpoints:{Name}:{EndpointType}hebben, waar Name en EndpointType zijn eigenschappen van het ServiceEndpoint object en zijn toegankelijk vanuit code.

U kunt meerdere exemplaren verbindingsreeks toevoegen met behulp van de volgende dotnet opdrachten:

dotnet user-secrets set Azure:SignalR:Endpoints:east-region-a <ConnectionString1>
dotnet user-secrets set Azure:SignalR:Endpoints:east-region-b:primary <ConnectionString2>
dotnet user-secrets set Azure:SignalR:Endpoints:backup:secondary <ConnectionString3>

Meerdere eindpunten toevoegen vanuit code

Een ServiceEndpoint klasse beschrijft de eigenschappen van een Azure SignalR Service-eindpunt. U kunt meerdere exemplaareindpunten configureren wanneer u de Azure SignalR Management SDK gebruikt via:

var serviceManager = new ServiceManagerBuilder()
                    .WithOptions(option =>
                    {
                        options.Endpoints = new ServiceEndpoint[]
                        {
                            // Note: this is just a demonstration of how to set options.Endpoints
                            // Having ConnectionStrings explicitly set inside the code is not encouraged
                            // You can fetch it from a safe place such as Azure KeyVault
                            new ServiceEndpoint("<ConnectionString0>"),
                            new ServiceEndpoint("<ConnectionString1>", type: EndpointType.Primary, name: "east-region-a"),
                            new ServiceEndpoint("<ConnectionString2>", type: EndpointType.Primary, name: "east-region-b"),
                            new ServiceEndpoint("<ConnectionString3>", type: EndpointType.Secondary, name: "backup"),
                        };
                    })
                    .BuildServiceManager();

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 Vóór failover

Fig.2 Na failover Na failover

Fig.3 Korte tijd na primaire herstelbewerkingen 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.