Betrouwbaarheid in Azure Web PubSub Service

Azure Web PubSub Service is een volledig beheerde, realtime berichtenservice waarmee bidirectionele communicatie tussen servers en clients mogelijk is met behulp van het WebSocket-protocol. Eén Web PubSub-resource kan worden geschaald tot één miljoen gelijktijdige WebSocket-verbindingen. De service ondersteunt verschillende berichtpatronen, waaronder server-naar-client-uitzending, berichten naar benoemde groepen, client-naar-client pub/sub en AI-tokenstreaming.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe u Azure Web PubSub Service bestand maakt tegen verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone en regiobrede fouten. Er wordt ook beschreven hoe de service onderhoud afhandelt en worden belangrijke details over de dienstenniveauovereenkomst (SLA) van de Azure Web PubSub-service belicht.

Aanbevelingen voor productie-implementatie voor betrouwbaarheid

Volg deze aanbevelingen voor productieworkloads:

Overzicht van betrouwbaarheidsarchitectuur

In deze sectie worden enkele belangrijke aspecten beschreven van de werking van de service die het meest relevant is vanuit het perspectief van betrouwbaarheid. In de sectie wordt de logische architectuur geïntroduceerd, die enkele van de resources en functies bevat die u implementeert en gebruikt. Ook wordt de fysieke architectuur besproken, die details biedt over hoe de service achter de schermen werkt.

Logische architectuur

De resource die u maakt, is een Web PubSub-resource. U configureert een resource met een aantal eenheden, die de capaciteit van de resource vertegenwoordigt, inclusief het maximum aantal gelijktijdige verbindingen. Zie de handleiding Performance voor Azure Web PubSub Service voor meer informatie.

Een Web PubSub-resource heeft een globaal uniek eindpunt dat vergelijkbaar is met contoso.webpubsub.azure.com. Clients maken WebSocket-verbindingen met dit eindpunt. Toepassingsservers maken verbinding met hetzelfde eindpunt om berichten te verzenden en gebeurtenissen van clients te ontvangen.

Zie Azure Web PubSub service internals voor meer informatie.

Fysieke architectuur

Azure Web PubSub Service beheert de verbindingsstatus en berichtroutering van WebSocket in een set rekenresources. Microsoft beheert de onderliggende infrastructuur. U ziet of communiceert niet rechtstreeks met afzonderlijke VM's die door de service worden gebruikt of andere infrastructuuronderdelen.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle cloudtoepassingen moeten de Azure richtlijnen voor tijdelijke foutafhandeling volgen wanneer ze communiceren met api's, databases en andere onderdelen die in de cloud worden gehost. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

WebSocket is een langlevend verbindingsprotocol. Tijdelijke netwerkgebeurtenissen, het opnieuw opstarten van de back-endinfrastructuur en onderhoudsbewerkingen voor services kunnen een actieve verbinding verwijderen. Met een eenvoudige herverbinding wordt de verbinding hersteld, maar zonder extra logica verliest de client berichten die tijdens de storing onderweg waren of in de wachtrij waren geplaatst.

Azure Web PubSub Service lost dit probleem op via betrouwbare subprotocollen die boven op de onbewerkte WebSocket-verbinding zitten. De subprotocollen volgen de berichtenreeks en de verbindingsstatus, zodat de client, wanneer een verbinding wegvalt, opnieuw met de service onderhandelt en hervat vanaf waar hij was gebleven.

Meestal is er geen berichtverlies nadat een verbinding is verbroken en opnieuw verbinding is gemaakt. Er zijn echter enkele situaties waarin berichtverlies kan optreden. Als de client bijvoorbeeld langer dan één minuut de verbinding verbreekt en vervolgens opnieuw verbinding maakt met dezelfde verbindings-id, geeft de bewerking voor opnieuw verbinden een foutstatus weer om aan te geven dat er berichtverlies kan optreden.

Volg deze aanbevelingen om te profiteren van de betrouwbare subprotocollen:

• Gebruik waar mogelijk een Azure Web PubSub client-SDK. De SDK implementeert automatisch het betrouwbare subprotocol. Er is geen aanvullende configuratie vereist. Voor meer informatie, zie:

  • Web PubSub client-side SDK voor JavaScript
  • Azure Web PubSub-clientbibliotheek voor .NET
  • Azure Web PubSub-clientbibliotheek voor Python
  • Azure WebPubSub-clientbibliotheek voor Java

• Als u de SDK niet kunt gebruiken, implementeert u een van de betrouwbare subprotocollen rechtstreeks in uw WebSocket-clientcode. Zie Betrouwbare WebSocket-clients maken voor de volledige specificatie en implementatierichtlijnen.

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Azure Web PubSub Service ondersteunt zone-redundante implementaties wanneer u de Premium-laag gebruikt. Wanneer u een Web PubSub-resource van de Premium-laag maakt of upgradet in een regio die beschikbaarheidszones ondersteunt, wordt zoneredundantie automatisch ingeschakeld. De service distribueert de infrastructuur over meerdere beschikbaarheidszones in de regio. Als één zone uitvalt, stuurt de service verkeer naar infrastructuur in een goede zone.

Requirements

• Regioondersteuning: Zoneredundantie wordt ondersteund in de meeste regio's waar beide voorwaarden van toepassing zijn:

  • De Azure Web PubSub Service is beschikbaar. Zie Product beschikbaarheid per regio voor een lijst met regio's waar de service beschikbaar is.
  • De regio ondersteunt beschikbaarheidszones. Zie Azure regiolijst voor een lijst met regio's met beschikbaarheidszones.

  Japan - west biedt momenteel echter geen ondersteuning voor zoneredundantie voor Azure Web PubSub.

• Tier: Zoneredundantie is beschikbaar in de Premium-laag.

Cost

Zoneredundantie voegt geen kosten toe en u betaalt het standaardtarief van de Premium-laag. Zie Azure Web PubSub serviceprijzen voor meer informatie.

Ondersteuning voor beschikbaarheidszones configureren

Zoneredundantie vereist geen configuratie buiten het selecteren van de Premium-laag. In beide gevallen wordt deze functie automatisch ingeschakeld:

• Maak een nieuwe zoneredundante Web PubSub-resource. Selecteer een SKU van het Premium-niveau wanneer u de bron maakt. Zie Create an Azure Web PubSub resource voor meer informatie.

• Een bestaande resource upgraden naar de Premium-laag. Zoneredundantie wordt automatisch ingeschakeld wanneer u een bestaande resource bijwerkt naar een SKU van het Premium-niveau. Een upgrade van Standard naar Premium veroorzaakt geen service-downtime. Zie Scale an Azure Web PubSub Service instance voor meer informatie.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een Azure Web PubSub resource configureert voor zoneredundantie en alle beschikbaarheidszones operationeel zijn.

• Cross-zone bewerking: Azure Web PubSub Service beheert automatisch de verdeling van verbindingen en bewerkingen over beschikbaarheidszones. Infrastructuur in meerdere zones verwerkt verkeer in een actief-actief model. U hoeft niets te configureren om te profiteren van dit gedrag. De service routeert berichten automatisch tussen exemplaren in meerdere zones, zodat een bericht dat door een client in één zone wordt verzonden, wordt bezorgd aan clients die zijn verbonden in een andere zone.

• Cross-zone gegevensreplicatie: Azure Web PubSub Service bewaart geen klantgegevens. De service onderhoudt sessiemetagegevens, zoals verbindingsstatus en berichtreeksinformatie voor actieve verbindingen. Deze metagegevens worden synchroon gerepliceerd in beschikbaarheidszones.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een Azure Web PubSub-resource voor zoneredundantie configureert en er een storing optreedt in een van de beschikbaarheidszones.

• Detection and response: Het Azure Web PubSub Service-platform is verantwoordelijk voor het detecteren van een fout in een beschikbaarheidszone. U hoeft geen actie te ondernemen om een zonefailover te starten.

• Melding: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt echter Azure Resource Health gebruiken om de status van een afzonderlijke resource te controleren en u kunt Resource Health-waarschuwingen instellen om u op de hoogte te stellen van problemen. U kunt Azure Service Health ook gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

• Actieve aanvragen: Tijdens een zonefout worden actieve WebSocket-verbindingen met infrastructuur in de getroffen zone verwijderd. Als uw clients tijdelijke fouten op de juiste manier afhandelen, zoals door na korte tijd opnieuw verbinding te maken, voorkomen ze meestal aanzienlijke gevolgen.

• Verwacht gegevensverlies: Azure Web PubSub Service bewaart geen berichten, waardoor een zonefout naar verwachting geen gegevensverlies binnen de Azure Web PubSub-service veroorzaakt. Actieve verbindingen worden echter verwijderd tijdens een zone-downgebeurtenis en dus kunnen alle gegevens die actief worden verzonden verloren gaan.

  Als uitgevers een Azure Web PubSub Client SDK gebruiken of de betrouwbare subprotocollen implementeren, worden hun berichten door de service bevestigd nadat de service ze heeft ontvangen. Wanneer een bericht wordt bevestigd, wordt het gerepliceerd in alle beschikbaarheidszones, zodat verlies van de zone van de uitgever er niet toe leidt dat het bericht verloren gaat. Als een abonnee het bericht echter niet ontvangt voordat het wordt verwijderd, wordt het bericht mogelijk niet weergegeven.

• Verwachte downtime: Het opnieuw verbinden van verbroken actieve verbindingen duurt doorgaans een paar seconden. Clients die logica voor opnieuw verbinden implementeren, ondervinden minimale onderbrekingen.

• Redistribution: Azure Web PubSub Service detecteert het verlies van de zone en herdistribueert verkeer automatisch over de gezonde zones. U hoeft geen actie te ondernemen.

Zoneherstel

Wanneer een beschikbaarheidszone wordt hersteld, wordt deze automatisch opnieuw geïntegreerd in de actieve servicetopologie Azure Web PubSub Service. U hoeft geen actie te ondernemen voor zoneherstel.

Nadat een zone is hersteld, kunnen nieuwe verbindingen worden omgeleid naar infrastructuur in de herstelde zone. Bestaande verbindingen worden niet verplaatst of geherbalanceerd naar de herstelde zone, maar ze worden geleidelijk herverdeeld naarmate de bestaande verbindingen na verloop van tijd verbreken en opnieuw herverbinden. Onevenwichtige verbindingen tussen zones hebben geen invloed op uw workload.

Testen op zonefouten

Azure Web PubSub Service beheert automatisch verkeersroutering, failover en zoneherstel voor zone-redundante Premium-laagresources. U hoeft niets te initiëren. Omdat zoneredundantie volledig wordt beheerd, hoeft u de foutprocessen van de beschikbaarheidszone niet te valideren.

Tolerantie voor storingen in de hele regio

Azure Web PubSub Service is een service met één regio. Als de regio niet meer beschikbaar is, is uw Web PubSub-resource ook niet beschikbaar.

Als u uw toepassing wilt beschermen tegen een regiobrede fout, kunt u geo-replicatie gebruiken, die beschikbaar is in de Premium-laag. U kunt ook een aangepaste oplossing voor meerdere regio's bouwen door meerdere Web PubSub-resources in verschillende regio's te implementeren.

Geo-replicatie

Met geo-replicatie kunt u replicas van uw Web PubSub-resource toevoegen in andere Azure regio's. Alle replica's delen één eindpunt (contoso.webpubsub.azure.com). Achter dit eindpunt gebruikt Azure Traffic Manager op DNS gebaseerde routering om elke client naar de dichtstbijzijnde gezonde regionale replica te leiden. Als een regio uitvalt, detecteert Traffic Manager de fout via statuscontroles en stopt het met het doorsturen van clients naar die replica. Nieuwe clientverbindingen worden automatisch doorgestuurd naar de dichtstbijzijnde goede replica.

De regio waarin u de Web PubSub-resource hebt gemaakt, wordt de primaire regio genoemd en de replica is de primaire replica. Het besturingsvlak van de primaire resource beheert de configuratie van uw Web PubSub-resource.

Requirements

• Regio-ondersteuning: U kunt replica's toevoegen in elke regio waar Azure Web PubSub Service beschikbaar is.
• Tier: U moet de Premium-laag gebruiken om geo-replicatie in te schakelen.
• Replicalimiet: Elke primaire Web PubSub-resource ondersteunt maximaal acht replica's.

Overwegingen

• Overname van configuratie: Replica's nemen de meeste configuratie-instellingen over van de primaire resource. Bepaalde instellingen moeten afzonderlijk worden geconfigureerd op elke replica. Zie Geo-replicatie in Azure Web PubSub voor de volledige lijst met instellingen die niet zijn overgenomen.

• Configuratiewijzigingen: Het primaire besturingsvlak, in de primaire regio, verwerkt eventuele configuratiewijzigingen in de Web PubSub-resource. Als het primaire besturingsvlak niet beschikbaar is, kunt u de resourceconfiguratie niet bijwerken, hoewel bestaande replica's zonder onderbreking gegevensverkeer blijven verwerken.

Cost

Elke replica wordt afzonderlijk gefactureerd op basis van het eigen aantal eenheden en het uitgaande berichtvolume. Als een bericht wordt overgebracht tussen replica's en vervolgens wordt bezorgd bij een client of server in een andere regio, wordt dit gefactureerd als een uitgaand bericht. Zie Azure Web PubSub serviceprijzen voor meer informatie.

Geo-replicatie configureren

Zie Geo-replicatie in Azure Web PubSub als u een replica wilt toevoegen aan of verwijderen uit een Web PubSub-resource.

Capaciteitsplanning en -beheer

Elke replica verwerkt verkeer onafhankelijk. Tijdens een regionale failover maken clients uit de mislukte regio opnieuw verbinding met de dichtstbijzijnde replica die in orde is. Zorg ervoor dat de overlevende replica's voldoende capaciteit hebben om deze extra belasting te absorberen door elke replica te configureren met eenheden die het volledige verwachte verkeer van de werklading kunnen verwerken, niet alleen het gedeelte dat het gewoonlijk bedient.

U kunt ook automatisch schalen op elke replica inschakelen, zodat eenheden automatisch kunnen worden uitgeschaald als reactie op hogere belasting. Automatisch schalen blijft werken wanneer een secundaire replica niet beschikbaar is, maar automatisch schalen werkt niet als het primaire besturingsvlak niet beschikbaar is. Zie Automatische schaaleenheden van een Azure Web PubSub-service voor meer informatie over automatisch schalen.

Zie Capaciteit beheren door overprovisioning voor algemene richtlijnen over overprovisioning als een strategie.

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer u Azure Web PubSub Service configureert voor geo-replicatie en alle regio's operationeel zijn.

• Regio-overschrijdende bewerking: Azure Traffic Manager leidt elke client naar de dichtstbijzijnde gezonde regionale replica. Clients in verschillende geografische gebieden kunnen verbinding maken met verschillende replica's. Web PubSub Service synchroniseert berichten tussen replica's, zodat clients die zijn verbonden met elke replica met elkaar kunnen communiceren.

• Replicatie van gegevens in meerdere regio's: Wanneer een bericht naar een replica wordt verzonden, wordt dat bericht synchroon door de service overgedragen naar andere replica's, zodat clients die elders zijn verbonden het bericht kunnen ontvangen. De overhead voor synchronisatie is minimaal voor de meest voorkomende berichtenpatronen, zoals uitzenden naar grote groepen of berichten via één verbinding. Berichten naar kleine groepen (minder dan 10 leden) kunnen een iets hogere synchronisatie-overhead opleveren.

  Azure Web PubSub Service bewaart geen berichten; alleen actieve bezorging wordt gesynchroniseerd tussen replica's.

Gedrag tijdens een regiofout

In deze sectie wordt beschreven wat u kunt verwachten wanneer u Azure Web PubSub Service configureert voor geo-replicatie en er een storing optreedt in een van de replicaregio's.

• Detectie en reactie: Web PubSub Service is verantwoordelijk voor het detecteren van een fout in een regio en het automatisch opnieuw omleiden van binnenkomend verkeer naar een replica in een van de andere regio's die u configureert.

• Melding: Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. Aan de andere kant:

  • U kunt Azure Resource Health gebruiken om te controleren op de status van een afzonderlijke resource en u kunt Resource Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

  • U kunt Azure Service Health gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele regiofouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

• Actieve aanvragen: Actieve WebSocket-verbindingen met de replica in de mislukte regio worden verwijderd. Clients moeten opnieuw verbinding maken nadat de replica een failover heeft uitgevoerd.

• Vermoed gegevensverlies: Azure Web PubSub Service bewaart geen berichten. Berichten die onderweg waren naar clients in de mislukte regio op het moment van de fout, gaan mogelijk verloren. Er wordt geen permanent gegevensverlies verwacht omdat de service geen klantgegevens opslaat.

• Vermoede downtime: Azure Traffic Manager voert statuscontroles uit op elke replica. Wanneer een regiostoring ertoe leidt dat een replica de statuscontrole mislukt, verwijdert Traffic Manager het eindpunt van die replica uit de resultaten van de DNS-omzetting. Nadat het eindpunt is verwijderd, moet de DNS-TTL van 90 seconden verstreken zijn voordat clients bijgewerkte DNS-records zien. In totaal duurt de overgang doorgaans een paar minuten. Goed ontworpen clients die logica voor opnieuw verbinden implementeren, kunnen de normale werking hervatten nadat ze opnieuw verbinding hebben gemaakt met de goede replica.

  Als het primaire besturingsvlak niet beschikbaar is, kunt u geen wijzigingen aanbrengen in de configuratie van uw Web PubSub-resource of de bijbehorende replica's. WebSocket-verbindingen blijven echter in goede replica's werken.

• Redistribution: Azure Traffic Manager stuurt binnenkomende aanvragen door naar goede replica's. Als een client echter opnieuw verbinding probeert te maken voordat Azure Traffic Manager de failover van de replica heeft gedetecteerd en de bijgewerkte DNS-vermeldingen zijn doorgegeven aan de client, kan de poging om opnieuw verbinding te maken mogelijk blijven gericht op de niet-beschikbare regio en kan mislukken.

  Nadat de DNS-update is doorgegeven, wordt het opnieuw verbinden van clients automatisch doorgestuurd naar de dichtstbijzijnde goede replica.

Herstel van de regio

Wanneer de uitgevallen regio is hersteld, detecteert de Traffic Manager-statuscontrole de herstelde replica en neemt het eindpunt weer op in de DNS-omzetting. Clients die momenteel zijn verbonden met andere replica's, worden niet beïnvloed en blijven verbonden totdat ze de verbinding verbreken. Nieuwe verbindingen worden opnieuw gerouteerd naar de replica van de herstelde regio wanneer dit de dichtstbijzijnde goede replica is.

Test voor regiofouten

Als u een failover van een regio wilt simuleren en het gedrag voor opnieuw verbinden van uw clienttoepassing wilt testen, kunt u het eindpunt van een replica uitschakelen. Deze actie zorgt ervoor dat Traffic Manager het routeren van verkeer naar die replica stopt, zodat u kunt zien hoe uw clients zich gedragen wanneer de replica waarmee ze verbinding maken, niet meer beschikbaar zijn. Zie Het replica-eindpunt uitschakelen of inschakelen voor gedetailleerde stappen.

Aangepaste multiregionale oplossingen voor veerkracht

Als u tolerantie tussen regio's nodig hebt, maar geen geo-replicatie gebruikt, kunt u afzonderlijke Web PubSub-resources in meerdere regio's implementeren en beheren en uw eigen failoverlogica implementeren op uw toepassingsserver. Deze benadering is complexer dan geo-replicatie en biedt geen ondersteuning voor failover zonder downtime voor client-naar-client-connectiviteit. Zie Veerkracht en rampenherstel in Azure Web PubSub Service voor een gedetailleerd architectuuroverzicht, failoverpatronen en testrichtlijnen.

Back-up maken en terugzetten

Azure Web PubSub Service is een staatloze berichtenservice. Er worden geen klantberichten bewaard en er is geen back-up- of herstelmogelijkheid.

Als u uw resourceconfiguratie wilt beveiligen, definieert u uw Web PubSub-resources met infrastructuur als code (zoals Bicep of ARM-sjablonen) en slaat u deze definities op in broncodebeheer. Als u een resource opnieuw wilt maken, implementeert u deze opnieuw vanuit de opgeslagen configuratie.

Tolerantie voor serviceonderhoud

Microsoft past regelmatig service-updates toe en voert ander onderhoud uit. Het Azure platform verwerkt deze activiteiten automatisch en zorgt ervoor dat onderhoud naadloos en transparant voor u is. Er wordt geen downtime verwacht tijdens onderhoudsgebeurtenissen, tenzij u op de hoogte bent gesteld via Azure Service Health gepland onderhoud.

Diensteniveau-overeenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

Verwante inhoud

• Wat is de Azure Web PubSub service?
• Georeplicatie in Azure Web PubSub
• Resiliency en herstel na noodgevallen in Azure Web PubSub Service
• Een Azure Web PubSub-dienstinstantie schalen
• Automatische schaaleenheden van een Azure Web PubSub-service
• Betrouwbaarheid in Azure