Betrouwbaarheid in Azure SignalR Service

Azure SignalR Service is een volledig beheerde service waarmee realtime bidirectionele communicatie in web- en mobiele toepassingen mogelijk is. Het abstraheert het onderliggende transportmechanisme. Wanneer WebSockets beschikbaar zijn, gebruikt de service deze. Als ze dat niet zijn, valt het terug op Server-Sent gebeurtenissen of lange polling. Deze abstractie betekent dat uw client- en servercode in realtime kunnen communiceren zonder gekoppeld te zijn aan een specifiek transportprotocol.

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 SignalR Service bestand maakt tegen verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone, regiostoringen en serviceonderhoud. Ook wordt essentiële informatie over de service level agreement (SLA) van de Azure SignalR Service benadrukt.

Aanbevelingen voor productie-implementatie voor betrouwbaarheid

Voor productiewerkzaamheden raden we u aan het volgende te doen:

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 SignalR Service-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 SignalR Service voor meer informatie.

Azure SignalR Service ondersteunt twee servicemodi. In de standaardmodus maken uw app-servers verbinding met de Azure SignalR Service resource en bevatten ze de hublogica. In de serverloze modus kan de service worden geïntegreerd met Azure Functions en fungeert Functions als gebeurtenisgestuurde berichthandlers, zodat u geen app-servers rechtstreeks beheert. Zie de servicemodus in Azure SignalR Service voor meer informatie.

Een SignalR Service-resource heeft een globaal uniek eindpunt dat vergelijkbaar is met contoso.service.signalr.net. Clients maken verbindingen met dit eindpunt. Toepassingsservers maken verbinding met hetzelfde eindpunt om berichten te verzenden en gebeurtenissen van clients te ontvangen.

Fysieke architectuur

Azure SignalR Service beheert de verbindingsstatus en berichtroutering over 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.

Azure SignalR Service maakt gebruik van langdurige verbindingen tussen clients, app-servers en de service. Deze verbindingen kunnen worden verbroken vanwege tijdelijke fouten, zoals netwerkinstabiliteit, herconfiguraties van load balancer of ophanging van browsertabbladen. Ontwerp uw clienttoepassingen en applicatieservers om verbindingsproblemen op te vangen en automatisch opnieuw verbinding te maken.

De Azure SignalR Service SDK's bevatten ingebouwd herverbindingsbeheer voor serververbindingen met de service. Opnieuw verbinding maken aan de clientzijde is afhankelijk van de clientbibliotheek die u gebruikt. ASP.NET Core SignalR-clients ondersteunen het opnieuw verbinden met behoud van status, waarmee een client de vorige verbinding kan hervatten zonder de status te verliezen als deze snel opnieuw verbinding maakt met dezelfde verbinding-ID. Als het opnieuw verbinden resulteert in een nieuwe verbindings-id, bijvoorbeeld na een langere storing, behandelt de service de client als een nieuwe verbinding. In dit geval moet de client opnieuw deelnemen aan groepen waarin deze zich eerder bevond en elke sessiestatus herstellen.

Zie Inzicht in clientverbindingen verbreken en opnieuw te verbinden binnen Azure SignalR Service voor gedetailleerde richtlijnen over het ontwerpen van uw applicatie om klant verwijderingen en herverbindingen af te handelen.

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 SignalR Service ondersteunt zone-redundante implementaties in de Premium-laag. Wanneer u een Premium-laagresource maakt of upgradet in een regio die beschikbaarheidszones ondersteunt, distribueert Azure SignalR Service de computeercapaciteit automatisch over alle beschikbaarheidszones in de regio. Als een beschikbaarheidszone mislukt, Azure SignalR Service nieuwe verbindingen naar exemplaren in de resterende gezonde zones doorstuurt.

Requirements

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

  • Azure SignalR 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 SignalR Service.

• 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 SignalR Service prijzen 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 zone-redundante SignalR Service resource. Selecteer een SKU van het Premium-niveau wanneer u de bron maakt. Zie de quickstarts, zoals Quickstart: Een chatruimte maken met behulp van SignalR Service 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 Change your Azure SignalR Service tier voor meer informatie.

Gedrag wanneer alle zones in orde zijn

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

• Cross-zone bewerking: Azure SignalR Service beheert automatisch hoe verbindingen en operaties over beschikbaarheidszones worden verdeeld. 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 SignalR Service bewaart geen klantgegevens, dus er zijn geen gegevens om te repliceren tussen zones. Verbindingsstatus is kortstondig en is gekoppeld aan elke actieve verbinding.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een Azure SignalR Service resource configureert voor zoneredundantie en er een storing is in een van de beschikbaarheidszones.

• Detection en response: Het Azure SignalR 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 verbindingen met knooppunten in de betrokken 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.

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

• 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 SignalR Service detecteert het verlies van de zone en verdeelt automatisch verkeer over de gezonde zones. U hoeft geen actie te ondernemen.

Zoneherstel

Wanneer een beschikbaarheidszone wordt hersteld, integreert Azure SignalR Service deze automatisch opnieuw in de actieve servicetopologie. 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 SignalR Service beheert verkeersroutering, failover en zoneherstel automatisch voor zone-redundante Premium-niveau resources. 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 SignalR Service is een service met één regio. Als de regio niet beschikbaar is, is uw SignalR Service 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 SignalR Service resources in verschillende regio's te implementeren.

Geo-replicatie

Met geo-replicatie kunt u replicas van uw SignalR Service-resource toevoegen in andere Azure regio's. Azure Traffic Manager maakt gebruik van 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 Azure SignalR Service resource hebt gemaakt, wordt de primaire regio genoemd en de replica is de primaire replica. Het controlvlak van de primaire resource beheert de configuratie van uw Azure SignalR Service resource.

Requirements

• Regio-ondersteuning: U kunt replica's toevoegen in elke regio waar Azure SignalR Service beschikbaar is.
• Tier: U moet de Premium-laag gebruiken om geo-replicatie in te schakelen.
• Replica limit: Elke primaire SignalR Service 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 SignalR Service voor de volledige lijst met instellingen die niet zijn overgenomen.

• Configuratiewijzigingen: Het primaire besturingsvlak, in de primaire regio, verwerkt eventuele configuratiewijzigingen in de SignalR Service 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. Kosten voor uitgaand verkeer tussen regio's zijn van toepassing wanneer berichten worden overgedragen tussen replica's en worden geleverd aan clients of servers in een andere regio. Zie Azure SignalR Service prijzen voor meer informatie.

Geo-replicatie configureren

Zie Geo-replicatie in Azure SignalR Service0 als u een replica wilt toevoegen aan of verwijderen uit een SignalR Service 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 Autoscaling in Azure SignalR 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 SignalR Service configureert voor geo-replicatie en alle replica'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. SignalR 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 SignalR 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 SignalR Service configureert voor geo-replicatie en er een storing is in een van de replicaregio's.

• Detection and response: SignalR Service is verantwoordelijk voor het detecteren van een fout in een regio en het automatisch omleiden van binnenkomend verkeer naar een replica in een van de andere regio's die u configureert.

• Notification: Microsoft geeft u niet automatisch een melding wanneer een regio uitvalt. U kunt Azure Service Health echter 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 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 SignalR 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 SignalR Service resource of de bijbehorende replica's. Verbindingen blijven echter werken in gezonde replica's.

• 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 oplossingen voor meerdere regio's voor veerkracht

Als u tolerantie tussen regio's nodig hebt, maar geen geo-replicatie gebruikt, kunt u afzonderlijke SignalR Service 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 Resiliency en disaster recovery in Azure SignalR Service voor een gedetailleerd architectuuroverzicht, failoverpatronen en testrichtlijnen.

Back-up maken en terugzetten

Azure SignalR 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 SignalR Service 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.

Tijdens gepland onderhoud gebruikt Azure SignalR Service een respijtende afsluitstrategie om de impact op verbonden clients te verminderen. Verbindingen worden geleidelijk verbroken via een vast tijdvenster, zodat clients geleidelijk opnieuw verbinding kunnen maken in plaats van allemaal tegelijk. Zie Verbinding verbreken tijdens serviceonderhoud voor meer informatie.

Onderhoudsgebeurtenissen worden aan uw clients weergegeven wanneer de verbinding afneemt. Zorg ervoor dat uw clienttoepassingen herverbindingslogica implementeren, zodat ze kunnen herstellen van onderhoudsgerelateerde verbroken verbindingen zonder zichtbare onderbreking van de gebruiker.

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

• Betrouwbaarheid in Azure
• overzicht van Azure SignalR Service
• Geo-replicatie in Azure SignalR Service
• Tolerantie en herstel na noodgevallen in Azure SignalR Service
• Begrijpen van clientverbindingen en herverbinding in Azure SignalR Service