Återhämtning och haveriberedskap i Azure Web PubSub Service
Återhämtning och haveriberedskap är ett vanligt behov för onlinesystem. Azure Web PubSub Service garanterar redan 99,9 % tillgänglighet, men det är fortfarande en regional tjänst. När det uppstår ett regionomfattande avbrott är det viktigt att tjänsten fortsätter att bearbeta realtidsmeddelanden i en annan region.
För regional haveriberedskap rekommenderar vi följande två metoder:
- Aktivera geo-replikering (enkelt sätt). Den här funktionen hanterar regional redundans 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. Du lär dig hur du gör det i det här dokumentet
Arkitektur med hög tillgänglighet för Web PubSub-tjänsten
Det finns två typiska mönster med web pubsub-tjänsten:
- Det ena är klient-server-mönster som klienter skickar händelser till servern och servern skickar meddelanden till klienterna.
- En annan är klient-klient-mönster som klienter pub/sub meddelanden via Web PubSub-tjänsten till andra klienter.
I avsnitten nedan beskrivs olika sätt för dessa två mönster att utföra haveriberedskap
Arkitektur med hög tillgänglighet för klientservermönster
Om du vill ha återhämtning mellan regioner för Web PubSub-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.
En typisk konfiguration för scenario mellan regioner är att ha två (eller flera) par med Web PubSub-tjänstinstanser och appservrar.
I varje par finns appservern och Web PubSub-tjänsten i samma region och Web PubSub-tjänsten ställer in händelsehanteraren uppströms till appservern i samma region.
För att bättre illustrera arkitekturen anropar vi Web PubSub-tjänsten som primär tjänst till appservern i samma par. Och vi anropar Web PubSub-tjänster i andra par som sekundära tjänster till appservern.
Programservern kan använda API :et för tjänsthälsokontroll för att identifiera om dess primära och sekundära tjänster är felfria eller inte. För en Web PubSub-tjänst med namnet demoreturnerar slutpunkten https://demo.webpubsub.azure.com/api/health till exempel 200 när tjänsten är felfri. Appservern kan regelbundet anropa slutpunkterna eller anropa slutpunkterna på begäran för att kontrollera om slutpunkterna är felfria. WebSocket-klienter förhandlar vanligtvis med sin programserver först för att hämta URL:en som ansluter till Web PubSub-tjänsten, och programmet använder det här förhandlingssteget för att redundansväxla klienterna till andra felfria sekundära tjänster. Detaljerade steg enligt nedan:
- När en klient förhandlar med appservern ska appservern endast returnera primära Web PubSub-tjänstslutpunkter, så i normala fall ansluter klienter endast till primära slutpunkter.
- När den primära instansen är nere ska förhandla om ATT returnera en felfri sekundär slutpunkt så att klienten fortfarande kan upprätta anslutningar och klienten ansluter till den sekundära slutpunkten.
- När den primära instansen är igång ska förhandla OM returnera den felfria primära slutpunkten så att klienter nu kan ansluta till den primära slutpunkten
- När appservern sänder meddelanden ska den sända meddelanden till alla felfria slutpunkter, inklusive både primära och sekundära.
- Appservern kan stänga anslutningar som är anslutna till sekundära slutpunkter för att tvinga klienterna att återansluta till den felfria primära slutpunkten.
Med den här topologin kan meddelanden från en server fortfarande levereras till alla klienter eftersom alla appservrar och Web PubSub-tjänstinstanser är sammankopplade.
Vi har inte integrerat strategin i SDK ännu, så för tillfället måste programmet implementera den här strategin på egen hand.
Sammanfattningsvis behöver programsidan implementera:
- Hälsokontroll. Programmet kan antingen kontrollera om tjänsten är felfri med hjälp av API :et för tjänsthälsokontroll regelbundet i bakgrunden eller på begäran för varje förhandlingsanrop .
- Förhandla om logik. Programmet returnerar felfri primär slutpunkt som standard. När den primära slutpunkten är nere returnerar programmet en felfri sekundär slutpunkt.
- Sändningslogik. När meddelanden skickas till flera klienter måste programmet se till att det sänder meddelanden till alla felfria slutpunkter.
Nedan visas ett diagram som illustrerar en sådan topologi:
Redundanssekvens och bästa praxis
Nu har du rätt konfiguration av systemtopologi. När en Web PubSub-tjänstinstans är nere dirigeras onlinetrafiken till andra instanser. Det här är vad som händer när en primär instans är nere (och återställs efter ett tag):
- Den primära tjänstinstansen är nere, alla klienter som är anslutna till den här instansen tas bort.
- Nya klienter eller återansluta klienten förhandlar med appservern
- Appservern identifierar att den primära tjänstinstansen är nere och förhandlar slutar returnera den här slutpunkten och börjar returnera en felfri sekundär slutpunkt.
- Klienter ansluter till den sekundära instansen.
- 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. Men klient-till-server-händelsemeddelanden skickas bara till den överordnade appservern i samma region.
- När den primära instansen har återställts och online igen upptäcker appservern att den primära instansen är tillbaka till felfri. Förhandling returnerar nu den primära slutpunkten igen, så nya klienter återansluts till den primära. Men befintliga klienter tas inte bort och fortsätter att vara anslutna till sekundära tills de kopplar från sig själva.
Diagram nedan illustrerar hur redundansväxling sker:
Fig.1 Före redundansväxling 
Fig.2 Efter redundansväxling 
Fig.3 Kort tid efter primär återställning 
I normala fall kan du se att endast den primära appservern och Web PubSub-tjänsten har onlinetrafik (i blått).
Efter redundansväxlingen blir även den sekundära appservern och Web PubSub-tjänsten aktiv. När den primära PubSub-tjänsten är online igen ansluter nya klienter till den primära webbpubenSub. 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:
- Den första är att ha ett par appserver- och Web PubSub-tjänstinstanser som tar all onlinetrafik och har ett annat par som en säkerhetskopia (kallas aktiv/passiv, illustrerad i Fig.1).
- Den andra är att ha två (eller flera) par av appservrar och Web PubSub-tjänstinstanser, var och en som deltar i onlinetrafiken och fungerar som säkerhetskopia för andra par (kallas aktiv/aktiv, liknande Fig.3).
Web PubSub-tjänsten har stöd för båda mönstren, den största skillnaden är hur du implementerar appservrar. Om appservrarna är aktiva/passiva är Web PubSub-tjänsten också aktiv/passiv (eftersom den primära appservern endast returnerar sin primära Web PubSub-tjänstinstans). Om appservrarna är aktiva/aktiva är Web PubSub-tjänsten också aktiv/aktiv (eftersom alla appservrar returnerar sina egna primära Web PubSub-instanser, så att alla kan få trafik).
Observera att oavsett vilka mönster du väljer att använda måste du ansluta varje Web PubSub-tjänstinstans till en appserver som en primär roll.
På grund av WebSocket-anslutningens natur (det är en lång anslutning) kommer klienterna också att uppleva att anslutningen avbryts när det uppstår en katastrof och redundansväxling sker. Du behöver 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.
Arkitektur med hög tillgänglighet för klient-klientmönster
För klientklientmönster är det för närvarande inte möjligt att stödja en haveriberedskap utan nedtid med flera instanser. Om du har höga tillgänglighetskrav bör du överväga att använda geo-replikering.
Så här testar du en redundansväxling
Följ stegen för att utlösa redundansväxlingen:
- 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.
- Starta om den primära resursen.
Nästa steg
I den här artikeln har du lärt dig hur du konfigurerar ditt program för att uppnå återhämtning för Web PubSub-tjänsten.
Använd dessa resurser för att börja skapa ett eget program: