Tillförlitlighet i Azure Web PubSub-tjänsten

Azure Web PubSub Service är en fullständigt hanterad meddelandetjänst i realtid som möjliggör dubbelriktad kommunikation mellan servrar och klienter med hjälp av WebSocket-protokollet. En enskild Web PubSub-resurs kan skalas till en miljon samtidiga WebSocket-anslutningar. Tjänsten stöder flera meddelandemönster, inklusive server-till-klient-sändning, meddelanden till namngivna grupper, pub/sub för klient-till-klient och strömning av AI-token.

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 Web PubSub Service motståndskraftig mot en mängd olika potentiella avbrott och problem, inklusive tillfälliga fel, fel i tillgänglighetszonen och regionomfattande fel. Den beskriver också hur tjänsten hanterar underhåll och visar viktig information om Azure Web PubSub serviceavtal (SLA).

Rekommendationer för produktionsdistribution för tillförlitlighet

Följ dessa rekommendationer för produktionsarbetsbelastningar:

  • 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.
  • Använd Azure Web PubSub Client SDK när du skapar klientprogram eller följ tillfälliga riktlinjer för felhantering genom att återansluta på ett säkert sätt. 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 du skapar är en Web PubSub-resurs. Du konfigurerar en resurs med ett antal enheter, vilket representerar resursens kapacitet, inklusive det maximala antalet samtidiga anslutningar. Se Prestandaguide för Azure Web PubSub Service för mer information.

En Web PubSub-resurs har en globalt unik slutpunkt som liknar contoso.webpubsub.azure.com. Klienter upprättar WebSocket-anslutningar till den här slutpunkten. Programservrar ansluter till samma slutpunkt för att skicka meddelanden och ta emot händelser från klienter.

Mer information finns i Azure Web PubSub service internals.

Fysisk arkitektur

Azure Web PubSub Service hanterar WebSocket-anslutningstillstånd och meddelanderoutning ö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.

WebSocket är ett långvarigt anslutningsprotokoll. Tillfälliga nätverkshändelser, omstarter av bakgrundsinfrastruktur och serviceunderhåll kan bryta en aktiv anslutning. En grundläggande återanslutning återställer anslutningen, men utan ytterligare logik förlorar klienten meddelanden som fanns under flygning eller köade under driftstoppet.

Azure Web PubSub Service löser problemet via reliable subprotocols som ligger ovanpå den råa WebSocket-anslutningen. Subprotokolerna spårar meddelandesekvensen och anslutningstillståndet så att klienten omförhandlar med tjänsten och återupptar från den platsen där den slutade när en anslutning avbryts.

Vanligtvis sker ingen meddelandeförlust när en anslutning släpps och återansluts. Det finns dock vissa situationer där meddelandeförlust kan uppstå. Om klienten till exempel kopplar från i mer än en minut och sedan återansluter med samma anslutnings-ID, visar återanslutningsåtgärden en felstatus för att indikera att meddelandeförlust kan inträffa.

Följ dessa rekommendationer för att dra nytta av de tillförlitliga subprotokolerna:

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 Web PubSub Service stöder zonredundanta distributioner när du använder Premium-nivån. När du skapar eller uppgraderar en Web PubSub-resurs på Premium-nivå i en region som stöder tillgänglighetszoner aktiveras zonredundans automatiskt. Tjänsten distribuerar sin infrastruktur över flera tillgänglighetszoner i regionen. Om en zon misslyckas dirigerar tjänsten trafik till infrastruktur i en felfri zon.

Diagram som visar en zonredundant Azure Web PubSub 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 Web PubSub Service är tillgänglig. 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 Web PubSub.

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

Cost

Zonredundans tillkommer ingen extra kostnad, och du betalar standardsatsen för Premium-nivån. Mer information finns i Azure Web PubSub servicepriser.

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 Web PubSub-resurs. Välj en SKU på Premium-nivå när du skapar resursen. Mer information finns i Skapa en Azure Web PubSub resurs.

  • 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 Skala en instans av Azure Web PubSub-tjänsten.

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 Web PubSub resurs för zonredundans och alla tillgänglighetszoner används.

  • Cross-zone operation: Azure Web PubSub 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.

  • Zonöverskridande datareplikering: Azure Web PubSub Service lagrar inte kunddata. Tjänsten underhåller sessionsmetadata, till exempel anslutningstillstånd och meddelandesekvensinformation för aktiva anslutningar. Dessa metadata replikeras synkront mellan tillgänglighetszoner.

Beteende vid ett zonfel

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

  • Detektion och svar: Azure Web PubSub-tjänstplattformen 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 WebSocket-anslutningar till infrastrukturen 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 Web PubSub Service bevarar inte meddelanden, så ett zonfel förväntas inte orsaka dataförlust i Azure Web PubSub-tjänsten. Alla aktiva anslutningar tas dock bort under en zon-down-händelse, så alla data som överförs aktivt kan gå förlorade.

    Om utgivare använder en Azure Web PubSub Client SDK eller implementerar tillförlitliga underprotokoler bekräftas deras meddelanden av tjänsten när tjänsten har fått dem. När ett meddelande bekräftas replikeras det i alla tillgänglighetszoner, så att utgivarens zon misslyckas leder inte till att meddelandet går förlorat. Men om en prenumerant inte får meddelandet innan det tas bort kanske det inte får meddelandet.

  • 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 Web PubSub Service identifierar förlusten av nätverkszonen och omfördelar automatiskt trafik till fullt fungerande zoner. Du behöver inte vidta några åtgärder.

Zonåterställning

När en tillgänglighetszon återställs, integreras den automatiskt åter in i Azure Web PubSub Service:s aktiva tjänsttopologi. 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 Web PubSub 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 Web PubSub Service är en tjänst för en region. Om regionen blir otillgänglig är din Web PubSub-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 Web PubSub-resurser i olika regioner.

Geo-replication

Med geo-replikering kan du lägga till repliker för din Web PubSub-resurs i andra Azure-regioner. Alla repliker delar en enskild slutpunkt (contoso.webpubsub.azure.com). Bakom den här slutpunkten använder Azure Traffic Manager 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 Web PubSub konfigurerat för geo-replikering i två regioner.

Den region som du skapade Web PubSub-resursen i kallas den primära regionen och dess replik är den primära repliken. Kontrollplanet för den primära resursen hanterar konfigurationen av din Web PubSub-resurs.

Requirements

  • Region support: Du kan lägga till repliker i valfri region där Azure Web PubSub Service är tillgänglig.
  • Nivå: Du måste använda Premium-nivån för att aktivera geo-replikering.
  • Gräns för repliker: Varje primär Web PubSub-resurs stöder upp till åtta repliker.

Att tänka på

  • 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-replication i Azure Web PubSub.

  • Konfigurationsändringar: Det primära kontrollplanet i den primära regionen bearbetar eventuella konfigurationsändringar av Web PubSub-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. Om ett meddelande överförs mellan repliker och sedan levereras till en klient eller server i en annan region faktureras det som ett utgående meddelande. Mer information finns i Azure Web PubSub servicepriser.

Konfigurera geo-replikering

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

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 skalning finns i Automatisk skalning av en Azure Web PubSub-tjänst.

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

Beteende när alla regioner är felfria

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar Azure Web PubSub Service för geo-replikering och alla regioner är i drift.

  • 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. Web PubSub 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 Web PubSub 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 Web PubSub Service för geo-replikering och det uppstår ett avbrott i någon av replikregionerna.

  • Identifiering och svar: Web PubSub 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 regionerna som du konfigurerar.

  • Notification: Microsoft meddelar dig inte automatiskt när en region är nere. Observera följande:

  • Aktiva begäranden: Aktiva WebSocket-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 Web PubSub 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 Web PubSub-resurs eller dess repliker. WebSocket-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 Web PubSub-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 Web PubSub Service.

Säkerhetskopiering och återställning

Azure Web PubSub 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 Web PubSub-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.

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