Tillförlitlighet i Azure SignalR Service

Azure SignalR Service är en fullständigt hanterad tjänst som möjliggör dubbelriktad kommunikation i realtid i webb- och mobilprogram. Den abstraherar den underliggande transportmekanismen. När WebSockets är tillgängliga använder tjänsten dem. När de inte är tillgängliga återgår det till Server-sent events eller långpolling. Den här abstraktionen innebär att klient- och serverkoden kan kommunicera i realtid utan att vara kopplad till ett specifikt transportprotokoll.

När du använder Azure är tillförlitlighet ett delat ansvar. Microsoft tillhandahåller en rad funktioner för att stödja återhämtning och återställning. Du ansvarar för att förstå hur dessa funktioner fungerar inom alla tjänster som du använder och välja de funktioner du behöver för att uppfylla dina affärsmål och drifttidsmål.

Den här artikeln beskriver hur du gör Azure SignalR Service motståndskraftiga mot en mängd olika potentiella avbrott och problem, inklusive tillfälliga fel, avbrott i tillgänglighetszonen, regionstopp och serviceunderhåll. Den visar också viktig information om Azure SignalR Service serviceavtal (SLA).

Rekommendationer för produktionsdistribution för tillförlitlighet

För produktionsarbetsbelastningar rekommenderar vi att du:

  • Använd Premium-nivån. Premiumnivån är motståndskraftig mot störningar i tillgänglighetszoner i regioner som stöds och gör att du kan konfigurera geografisk replikering.
  • Utforma klientprogram och appservrar för att på ett säkert sätt återansluta automatiskt när anslutningarna tas bort. Zonfelövergångar, regionfelövergångar och tillfälliga fel avbryter alla aktiva anslutningar.
  • Aktivera geo-replikering för att skydda mot regionomfattande fel. Anpassa storleken på varje replik med tillräckligt många enheter för att hantera den fulla förväntade trafikmängden vid en failover-situation.

Översikt över tillförlitlighetsarkitektur

I det här avsnittet beskrivs några av de viktiga aspekterna av hur tjänsten fungerar som är mest relevant ur ett tillförlitlighetsperspektiv. I avsnittet beskrivs den logiska arkitekturen, som innehåller några av de resurser och funktioner som du distribuerar och använder. Den diskuterar också den fysiska arkitekturen, som innehåller information om hur tjänsten fungerar under täcket.

Logisk arkitektur

Resursen som du skapar är en SignalR Service resurs. Du konfigurerar en resurs med ett antal enheter, vilket representerar resursens kapacitet, inklusive det maximala antalet samtidiga anslutningar. Mer information finns i guiden Performance för Azure SignalR Service.

Azure SignalR Service stöder två tjänstlägen. I standardläge ansluter appservrarna till Azure SignalR Service-resursen och hanterar hubblogik. I serverlöst läge integreras tjänsten med Azure Functions och Functions fungerar som händelsedrivna meddelandehanterare så att du inte hanterar appservrar direkt. För mer information, se Tjänstläge i Azure SignalR Service.

En SignalR Service resurs har en globalt unik slutpunkt som liknar contoso.service.signalr.net. Klienter upprättar anslutningar till den här slutpunkten. Programservrar ansluter till samma slutpunkt för att skicka meddelanden och ta emot händelser från klienter.

Fysisk arkitektur

Azure SignalR Service hanterar anslutningstillstånd och meddelandedirigering över en uppsättning beräkningsresurser. Microsoft hanterar den underliggande infrastrukturen. Du ser eller interagerar inte direkt med enskilda virtuella datorer som tjänsten använder eller andra infrastrukturkomponenter.

Motståndskraft mot tillfälliga fel

Tillfälliga fel är kortvariga, intermittenta fel i komponenter. De förekommer ofta i en distribuerad miljö som molnet, och de är en normal del av åtgärderna. Tillfälliga fel korrigerar sig själva efter en kort tidsperiod. Det är viktigt att dina program kan hantera tillfälliga fel, vanligtvis genom att försöka igen.

Alla molnbaserade program bör följa vägledningen för tillfälliga felhantering i Azure när de kommunicerar med molnbaserade API:er, databaser och andra komponenter. Mer information finns i Rekommendationer för hantering av tillfälliga fel.

Azure SignalR Service använder långvariga anslutningar mellan klienter, appservrar och tjänsten. Dessa anslutningar kan tas bort på grund av tillfälliga fel som nätverksinstabilitet, omkonfigurationer av lastbalanserare eller avstängningar av webbläsarflikar. Utforma dina klientprogram och appservrar för att hantera anslutningsfall och återanslut automatiskt.

De Azure SignalR Service SDK:erna omfattar inbyggd återanslutningshantering för serveranslutningar till tjänsten. Återanslutning på klientsidan beror på vilket klientbibliotek du använder. ASP.NET Core SignalR-klienter stöder tillståndskänslig återanslutning, vilket gör att en klient kan återuppta sin tidigare anslutning utan att förlora tillståndet om den återansluter snabbt med samma anslutnings-ID. Om återanslutningen resulterar i ett nytt anslutnings-ID, till exempel efter ett längre avbrott, behandlar tjänsten klienten som en ny anslutning. I det här fallet måste klienten återansluta till alla grupper som den tidigare var i och återställa alla sessionstillstånd.

Detaljerad vägledning om hur du utformar ditt program för att hantera klientkopplingar och återanslutningar finns i Förstå klient frånkopplingar och återanslutning i Azure SignalR Service.

Motståndskraft mot fel i tillgänglighetszonen

Tillgänglighetszoner är fysiskt separata grupper av datacenter i en Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

Azure SignalR Service stöder zonredundanta distributioner på Premium-nivån. När du skapar eller uppgraderar till en Premium-nivåresurs i en region som stöder tillgänglighetszoner distribuerar Azure SignalR Service automatiskt sin beräkningskapacitet över alla tillgänglighetszoner i regionen. Om en tillgänglighetszon misslyckas dirigerar Azure SignalR Service nya anslutningar till instanser i de återstående felfria zonerna.

Diagram som visar en zonredundant Azure SignalR-tjänst, spridd över flera tillgänglighetszoner.

Requirements

  • Regionstöd: Zonredundans stöds i de flesta regioner där båda dessa villkor gäller:

    • Azure SignalR Service är tillgängligt. En lista över regioner där tjänsten är tillgänglig finns i Produkttillgänglighet per region.
    • Regionen stöder tillgänglighetszoner. En lista över regioner med tillgänglighetszoner finns i listan Azure regions.

    Japan, västra stöder dock för närvarande inte zonredundans för Azure SignalR Service.

  • Nivå: Zonredundans är tillgängligt på Premium-nivån.

Cost

Zonredundans tillkommer ingen extra kostnad, och du betalar standardsatsen för Premium-nivån. För mer information, se Azure SignalR Service prisinformation.

Konfigurera stöd för tillgänglighetszoner

Zonredundans kräver ingen konfiguration utöver att välja Premium-nivån. Den aktiveras automatiskt i båda dessa fall:

  • Skapa en ny zonredundant SignalR Service resurs. Välj en SKU på Premium-nivå när du skapar resursen. Mer information finns i snabbstarterna, till exempel Quickstart: Skapa ett chattrum med hjälp av SignalR Service.

  • Uppgradera en befintlig resurs till Premium-nivå. Zonredundans aktiveras automatiskt när du uppgraderar en befintlig resurs till en SKU på Premium-nivå. Uppgradering från Standard till Premium orsakar inte tjänstavbrott. Mer information finns i Change your Azure SignalR Service tier.

Beteende när alla zoner är felfria

I det här avsnittet beskrivs vad du kan förvänta dig när du konfigurerar en Azure SignalR Service resurs för zonredundans och alla tillgänglighetszoner används.

  • Cross-zone operation: Azure SignalR Service hanterar automatiskt hur anslutningar och åtgärder distribueras mellan tillgänglighetszoner. Infrastruktur i flera zoner bearbetar trafik i en aktiv-aktiv modell. Du behöver inte konfigurera något för att dra nytta av det här beteendet. Tjänsten dirigerar meddelanden mellan instanser mellan zoner automatiskt, så ett meddelande som skickas av en klient i en zon levereras till klienter som är anslutna i en annan zon.

  • Cross-zone data replikering: Azure SignalR Service bevarar inte kunddata, så det finns inga data att replikera mellan zoner. Anslutningstillståndet är tillfälliga och är associerat med varje aktiv anslutning.

Beteende vid ett zonfel

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar en Azure SignalR Service resurs för zonredundans och det uppstår ett avbrott i någon av tillgänglighetszonerna.

  • Detection och svar: Azure SignalR Service-plattformen ansvarar för att upptäcka ett fel i en tillgänglighetszon. Du behöver inte vidta några åtgärder för att initiera en zonredundansväxling.
  • Notification: Microsoft meddelar dig inte automatiskt när en zon är nere. Du kan dock använda Azure Resource Health för att övervaka hälsotillståndet för en enskild resurs, och du kan konfigurera Resource Health-aviseringar för att meddela dig om problem. Du kan också använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella zonfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.

  • Aktiva begäranden: Vid ett zonfel tas aktiva anslutningar till noder i den berörda zonen bort. Om dina klienter hanterar tillfälliga fel på rätt sätt, till exempel genom att återansluta efter en kort tidsperiod, undviker de vanligtvis betydande påverkan.

  • Expected data loss: Azure SignalR Service bevarar inte meddelanden, så ett zonfel förväntas inte orsaka dataförlust inom Azure SignalR service. Alla aktiva anslutningar tas dock bort under en zon-down-händelse, så alla data som överförs aktivt kan gå förlorade.

  • Förväntad stilleståndstid: Återanslutningen av borttagna aktiva anslutningar tar vanligtvis några sekunder. Klienter som implementerar återanslutningslogik upplever minimala störningar.

  • Redistribution: Azure SignalR Service identifierar förlusten av zonen och distribuerar automatiskt trafik över felfria zoner. Du behöver inte vidta några åtgärder.

Zonåterställning

När en tillgänglighetszon återställs, integreras den automatiskt tillbaka i den aktiva tjänsttopologin av Azure SignalR Service. Du behöver inte vidta några åtgärder för zonåterställning.

När en zon har återställts kan nya anslutningar dirigeras till infrastrukturen i den återställda zonen. Befintliga anslutningar flyttas inte eller balanseras om till den återställda zonen, men de balanseras gradvis om när de befintliga anslutningarna släpps och återansluts över tid. Obalans i anslutningen mellan zoner påverkar inte din arbetsbelastning.

Test för zonfel

Azure SignalR Service hanterar trafikroutning, redundans och zonåterställning automatiskt för zonredundanta Premium-nivåresurser. Du behöver inte initiera något. Eftersom zonredundansen är helt hanterad behöver du inte verifiera felprocesser i tillgänglighetszonen.

Motståndskraft mot regionomfattande fel

Azure SignalR Service är en tjänst för en region. Om regionen blir otillgänglig är din SignalR Service resurs inte heller tillgänglig.

För att skydda ditt program mot ett regionomfattande fel kan du använda geo-replikering, som är tillgänglig på Premium-nivån. Du kan också skapa en anpassad lösning för flera regioner genom att distribuera flera SignalR Service resurser i olika regioner.

Geo-replication

Med geo-replikering kan du lägga till replicas för din SignalR Service resurs i andra Azure regioner. Azure Traffic Manager använder DNS-baserad routning för att dirigera varje klient till närmaste felfria regionala replik. Om en region misslyckas identifierar Traffic Manager felet genom hälsokontroller och slutar dirigera klienter till repliken. Nya klientanslutningar dirigeras automatiskt till närmaste felfria replik.

Diagram som visar Azure SignalR Service konfigurerat för geo-replikering i två regioner.

Den region som du skapade Azure SignalR Service resursen i kallas primary-regionen och dess replik är primary-repliken. control-planet för den primära resursen hanterar konfigurationen av din Azure SignalR Service resurs.

Requirements

  • Region support: Du kan lägga till repliker i alla regioner där Azure SignalR Service är tillgängligt.
  • Nivå: Du måste använda Premium-nivån för att aktivera geo-replikering.
  • Replica limit: Varje primär SignalR Service resurs stöder upp till åtta repliker.

Överväganden

  • Konfigurationsarv: Repliker ärver de flesta konfigurationsinställningar från den primära resursen. Vissa inställningar måste konfigureras separat på varje replik. En fullständig lista över inställningar som inte ärvs finns i Geo-replikering i Azure SignalR Service.

  • Konfigurationsändringar: Det primära kontrollplanet i den primära regionen bearbetar alla konfigurationsändringar av SignalR Service resursen. Om det primära kontrollplanet inte är tillgängligt kan du inte uppdatera resurskonfigurationen, även om befintliga repliker fortsätter att bearbeta datatrafik utan avbrott.

Cost

Varje replik faktureras separat baserat på dess egna antal enheter och utgående meddelandevolym. Avgifter för utgående trafik mellan regioner tillkommer när meddelanden överförs mellan repliker och levereras till klienter eller servrar i en annan region. Mer information finns på Sidan för prissättning av Azure SignalR-tjänsten.

Konfigurera geo-replikering

Information om hur du lägger till eller tar bort en replik i en SignalR Service resurs finns i Geo-replikering i Azure SignalR Service.

Kapacitetsplanering och -hantering

Varje replik hanterar trafik oberoende av andra. Under en regional felövergång återansluter klienter från den felande regionen till närmaste felfria replika. För att säkerställa att de kvarvarande replikerna har tillräckligt med kapacitet för att absorbera den här extra belastningen konfigurerar du varje replik med enheter som kan hantera den fullständiga förväntade trafiken för arbetsbelastningen, inte bara den del som den normalt betjänar.

Du kan också aktivera automatisk skalning på varje replik så att enheter kan skalas ut automatiskt som svar på högre belastning. Autoskalning fortsätter att fungera när en sekundär replik inte är tillgänglig, men automatisk skalning fungerar inte om det primära kontrollplanet inte är tillgängligt. Mer information om automatisk skalning finns i Autoscaling i Azure SignalR Service.

Allmän vägledning om överetablering som en strategi finns i Hantera kapacitet genom överetablering.

Beteende när alla regioner är felfria

I det här avsnittet beskrivs vad du kan förvänta dig när du konfigurerar Azure SignalR Service för geo-replikering och alla repliker fungerar.

  • Cross-region operation: Azure Traffic Manager dirigerar varje klient till den närmaste hälsosamma replik av en region. Klienter i olika geografiska områden kan ansluta till olika repliker. SignalR Service synkroniserar meddelanden mellan repliker så att klienter som är anslutna till alla repliker kan kommunicera med varandra.

  • Datareplikering mellan regioner: När ett meddelande skickas till en replik överför tjänsten synkront meddelandet till andra repliker så att klienter som är anslutna någon annanstans kan ta emot det. Synkroniseringskostnaderna är minimala för de vanligaste meddelandemönstren, till exempel sändning till stora grupper eller meddelandehantering av en enda anslutning. Meddelanden till små grupper (färre än 10 medlemmar) kan ge något högre synkroniseringskostnader.

    Azure SignalR Service bevarar inte meddelanden. Endast aktiv leverans synkroniseras mellan repliker.

Beteende under ett regionfel

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar Azure SignalR Service för geo-replikering och det uppstår ett avbrott i någon av replikregionerna.

  • Detection och svar: SignalR Service ansvarar för att identifiera ett fel i en region och automatiskt omdirigera inkommande trafik till en replik i någon av de andra regioner som du konfigurerar.
  • Anmälan: Microsoft meddelar dig inte automatiskt när en region är nere. Du kan dock använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella regionfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.

  • Aktiva begäranden: Aktiva anslutningar till repliken i den misslyckade regionen tas bort. Klienter måste återansluta efter att repliken gör en failover.

  • Förväntad dataförlust: Azure SignalR Service bevarar inte meddelanden. Meddelanden som skickades till klienter i den misslyckade regionen vid tidpunkten för felet kan gå förlorade. Ingen beständig dataförlust förväntas eftersom tjänsten inte lagrar kunddata.

  • Expected downtime: Azure Traffic Manager utför hälsoundersökningar mot varje kopia. När ett regionavbrott orsakar att en replik misslyckas i dess hälsokontroll tar Traffic Manager bort replikens slutpunkt från DNS-upplösningsresultaten. När du har tagit bort slutpunkten måste DNS TTL på 90 sekunder förflutit innan klienterna ser uppdaterade DNS-poster. Totalt tar övergången vanligtvis några minuter. Väl utformade klienter som implementerar återanslutningslogik kan återuppta normal drift efter återanslutning till den hälsosamma repliken.

    Om det primära kontrollplanet inte är tillgängligt kan du inte göra några ändringar i konfigurationen av din SignalR Service resurs eller dess repliker. Anslutningar fortsätter dock att fungera i felfria repliker.

  • Redistribution: Azure Traffic Manager dirigerar inkommande begäran till felfria repliker. Men om en klient försöker återansluta innan Azure Traffic Manager har identifierat en failover-händelse för replikan och de uppdaterade DNS-posterna har spridits till klienten, kan klientens återanslutningsförsök fortsätta att rikta sig mot den otillgängliga regionen och därmed misslyckas.

    När DNS-uppdateringen har spridits dirigeras återanslutningsklienter automatiskt till närmaste felfria replik.

Regionåterställning

När den felande regionen återställs identifierar Traffic Managers hälsokontroll den återställda replikan och inkluderar dess slutpunkt i DNS-upplösningen igen. Klienter som för närvarande är anslutna till andra repliker påverkas inte och förblir anslutna förrän de kopplas från. Nya anslutningar dirigeras igen till den återställda regionens replik när det är närmaste felfria replik.

Test för regionfel

För att simulera ett felöverskridande av en region och testa klientprogrammets återanslutningsbeteende kan du inaktivera en replikas slutpunkt. Den här åtgärden gör att Traffic Manager slutar dirigera trafik till repliken, vilket gör att du kan se hur dina klienter beter sig när repliken de ansluter till blir otillgänglig. Detaljerade steg finns i Inaktivera eller aktivera replikslutpunkten.

Anpassade lösningar för flera regioner för återhämtning

Om du behöver återhämtning mellan regioner men inte använder geo-replikering kan du distribuera och hantera separata SignalR Service resurser i flera regioner och implementera din egen redundanslogik på programservern. Den här metoden är mer komplex än geo-replikering och stöder inte noll stilleståndstid vid redundans för klient-till-klient-anslutning. En detaljerad arkitekturöversikt, redundansmönster och testvägledning finns i Resiliency and disaster recovery in Azure SignalR Service.

Säkerhetskopiering och återställning

Azure SignalR Service är en tillståndslös meddelandetjänst. Den bevarar inte kundmeddelanden och har ingen säkerhetskopierings- eller återställningsfunktion.

För att skydda resurskonfigurationen definierar du dina SignalR Service resurser med hjälp av infrastruktur som kod (till exempel Bicep- eller ARM-mallar) och lagrar dessa definitioner i källkontrollen. Om du behöver återskapa en resurs distribuerar du om den från den lagrade konfigurationen.

Motståndskraft mot serviceunderhåll

Microsoft tillämpar regelbundet tjänstuppdateringar och utför annat underhåll. Den Azure plattformen hanterar dessa aktiviteter automatiskt, vilket säkerställer att underhållet är sömlöst och transparent för dig. Ingen driftstopp förväntas under underhållshändelser om du inte har blivit informerad via Azure Service Health planerat underhåll.

Under planerat underhåll använder Azure SignalR Service en graciös avstängningsstrategi för att minska påverkan på anslutna klienter. Anslutningar kopplas gradvis från under ett angivet tidsfönster, vilket gör det möjligt för klienter att återansluta progressivt i stället för alla på en gång. Mer information finns i Avbrott under serviceunderhåll.

Underhållshändelser visas för dina klienter när anslutningen avbryts. Se till att klientprogrammen implementerar återanslutningslogik så att de kan återställas från underhållsrelaterade frånkopplingar utan användar synligt avbrott.

Serviceavtal

Serviceavtal (SLA) för Azure-tjänster beskriver den förväntade tillgängligheten för varje tjänst och de villkor som din lösning måste uppfylla för att uppnå den tillgänglighetsförväntningen. Mer information finns i Serviceavtal för onlinetjänster.

Relaterat innehåll

  • Last updated on