Best practices voor de isolatie van toepassingen tegen Service Bus-uitval en -noodgevallen
Bedrijfskritieke toepassingen moeten continu werken, zelfs in aanwezigheid van ongeplande storingen of rampen. In dit artikel worden technieken beschreven die u kunt gebruiken om Service Bus-toepassingen te beschermen tegen een mogelijke servicestoring of noodgeval.
Er wordt een storing gedefinieerd als de tijdelijke onbeschikbaarheid van Azure Service Bus. De storing kan van invloed zijn op sommige onderdelen van Service Bus, zoals een berichtenarchief of zelfs het hele datacenter. Nadat het probleem is opgelost, wordt Service Bus weer beschikbaar. Normaal gesproken veroorzaakt een storing geen verlies van berichten of andere gegevens. Een voorbeeld van een onderdeelfout is de onbeschikbaarheid van een bepaald berichtenarchief. Een voorbeeld van een storing in het hele datacenter is een stroomstoring van het datacenter of een defecte datacenternetwerkswitch. Een storing kan een paar minuten tot een paar dagen duren.
Een noodgeval wordt gedefinieerd als permanent verlies van een Service Bus-schaaleenheid of -datacenter. Het datacenter is mogelijk of niet opnieuw beschikbaar. Meestal veroorzaakt een noodgeval verlies van sommige of alle berichten of andere gegevens. Voorbeelden van rampen zijn brand, overstroming of aardbeving.
Bescherming tegen storingen en rampen - Premium-laag
Concepten voor hoge beschikbaarheid en herstel na noodgevallen zijn rechtstreeks ingebouwd in de Azure Service Bus Premium-laag , zowel binnen dezelfde regio (via beschikbaarheidszones) als in verschillende regio's (via geo-noodherstel).
Herstel na noodgevallen
De Service Bus Premium-laag biedt ondersteuning voor herstel na noodgevallen op het niveau van de naamruimte. Zie Azure Service Bus geo-noodherstel voor meer informatie. De functie voor herstel na noodgevallen, die alleen beschikbaar is voor de Premium-SKU , implementeert herstel na noodgevallen van metagegevens en is afhankelijk van primaire en secundaire naamruimten. Bij herstel na noodgevallen worden alleen metagegevens voor entiteiten gerepliceerd tussen primaire en secundaire naamruimten.
Beschikbaarheidszones
De Service Bus Premium-laag ondersteunt beschikbaarheidszones, waardoor fout-geïsoleerde locaties binnen dezelfde Azure-regio worden geboden. Service Bus beheert drie kopieën van het berichtenarchief (1 primaire en 2 secundaire). Service Bus houdt alle drie de kopieën gesynchroniseerd voor gegevens- en beheerbewerkingen. Als de primaire kopie mislukt, wordt een van de secundaire kopieën gepromoveerd naar primair zonder waargenomen downtime. Als toepassingen tijdelijke verbindingen met Service Bus zien, wordt de logica voor opnieuw proberen in de SDK automatisch opnieuw verbonden met Service Bus.
Wanneer u beschikbaarheidszones gebruikt, worden zowel metagegevens als gegevens (berichten) gerepliceerd in datacenters in de beschikbaarheidszone.
Notitie
De ondersteuning voor beschikbaarheidszones voor de Premium-laag is alleen beschikbaar in Azure-regio's waar beschikbaarheidszones aanwezig zijn.
Wanneer u een naamruimte voor de Premium-laag maakt via de portal, wordt de ondersteuning voor beschikbaarheidszones (indien beschikbaar in de geselecteerde regio) automatisch ingeschakeld voor de naamruimte. Wanneer u een naamruimte voor een Premium-laag maakt via andere mechanismen, zoals Azure Resource Manager/Bicep-sjablonen, CLI of PowerShell, moet de eigenschap zoneRedundant expliciet worden ingesteld om beschikbaarheidszones in te true schakelen (indien beschikbaar in de geselecteerde regio). Er zijn geen extra kosten verbonden aan het gebruik van deze functie en u kunt deze functie niet uitschakelen of inschakelen na het maken van de naamruimte.
Bescherming tegen storingen en noodgevallen - Standard-laag
Als u tolerantie wilt bereiken tegen datacentrumstoringen met de prijscategorie Standard Messaging, kunt u actieve of passieve replicatie gebruiken. Als voor elke benadering een bepaalde wachtrij of een bepaald onderwerp toegankelijk moet blijven in aanwezigheid van een storing in een datacenter, kunt u deze maken in beide naamruimten. Beide entiteiten kunnen dezelfde naam hebben. Een primaire wachtrij kan bijvoorbeeld worden bereikt onder contosoPrimary.servicebus.windows.net/myQueue, terwijl de secundaire tegenhanger onder contosoSecondary.servicebus.windows.net/myQueue kan worden bereikt.
Notitie
De actieve replicatie en passieve replicatie-installatie zijn oplossingen voor algemeen gebruik en niet specifieke functies van Service Bus. De replicatielogica (verzenden naar 2 verschillende naamruimten) bevindt zich in de afzendertoepassingen en de ontvanger moet aangepaste logica hebben voor dubbele detectie.
Als de toepassing geen permanente communicatie van afzender naar ontvanger vereist, kan de toepassing een duurzame wachtrij aan de clientzijde implementeren om berichtenverlies te voorkomen en de afzender te beschermen tegen tijdelijke Service Bus-fouten.
Actieve replicatie
Actieve replicatie maakt gebruik van entiteiten in beide naamruimten voor elke bewerking. Elke client die een bericht verzendt, verzendt twee kopieën van hetzelfde bericht. De eerste kopie wordt verzonden naar de primaire entiteit (bijvoorbeeld contosoPrimary.servicebus.windows.net/sales) en de tweede kopie van het bericht wordt verzonden naar de secundaire entiteit (bijvoorbeeld contosoSecondary.servicebus.windows.net/sales).
Een client ontvangt berichten van beide wachtrijen. De ontvanger verwerkt de eerste kopie van een bericht en de tweede kopie wordt onderdrukt. Als u dubbele berichten wilt onderdrukken, moet de afzender elk bericht taggen met een unieke id. Beide kopieën van het bericht moeten worden gelabeld met dezelfde id. U kunt de eigenschappen ServiceBusMessage.MessageId of ServiceBusMessage.Subject of een aangepaste eigenschap gebruiken om het bericht te taggen. De ontvanger moet een lijst onderhouden met berichten die al zijn ontvangen.
Het voorbeeld [geo-replicatie met Service Bus Standard-laag][Geo-replicatie met Service Bus Standard-laag] demonstreert actieve replicatie van berichtentiteiten.
Notitie
De actieve replicatiebenadering verdubbelt het aantal bewerkingen, waardoor deze benadering tot hogere kosten kan leiden.
Passieve replicatie
In het probleemloze geval gebruikt passieve replicatie slechts één van de twee berichtenentiteiten. Een client verzendt het bericht naar de actieve entiteit. Als de bewerking op de actieve entiteit mislukt met een foutcode die aangeeft dat het datacenter dat als host fungeert voor de actieve entiteit mogelijk niet beschikbaar is, verzendt de client een kopie van het bericht naar de back-upentiteit. Op dat moment schakelen de actieve en de back-upentiteiten tussen rollen. De verzendende client beschouwt de oude actieve entiteit als de nieuwe back-upentiteit en de oude back-upentiteit is de nieuwe actieve entiteit. Als beide verzendbewerkingen mislukken, blijven de rollen van de twee entiteiten ongewijzigd en wordt er een fout geretourneerd.
Een client ontvangt berichten van beide wachtrijen. Omdat er een kans is dat de ontvanger twee kopieën van hetzelfde bericht ontvangt, moet de ontvanger dubbele berichten onderdrukken. U kunt duplicaten op dezelfde manier onderdrukken als beschreven voor actieve replicatie.
In het algemeen is passieve replicatie voordeliger dan actieve replicatie, omdat in de meeste gevallen slechts één bewerking wordt uitgevoerd. Latentie, doorvoer en monetaire kosten zijn identiek aan het niet-gerepliceerde scenario.
Wanneer u passieve replicatie gebruikt, kunnen berichten in de volgende scenario's twee keer verloren gaan of ontvangen:
- Berichtvertraging of -verlies: Stel dat de afzender een bericht m1 naar de primaire wachtrij heeft verzonden en de wachtrij vervolgens niet meer beschikbaar is voordat de ontvanger m1 ontvangt. De afzender verzendt een volgend bericht m2 naar de secundaire wachtrij. Als de primaire wachtrij tijdelijk niet beschikbaar is, ontvangt de ontvanger m1 nadat de wachtrij weer beschikbaar is. Wanneer zich een noodgeval voordoet, ontvangt de ontvanger mogelijk nooit m1.
- Dubbele ontvangst: Stel dat de afzender een bericht naar de primaire wachtrij verzendt. Service Bus verwerkt m, maar kan geen antwoord verzenden. Nadat er een time-out optreedt voor de verzendbewerking, verzendt de afzender een identieke kopie van m naar de secundaire wachtrij. Als de ontvanger de eerste kopie van m kan ontvangen voordat de primaire wachtrij niet meer beschikbaar is, ontvangt de ontvanger beide exemplaren van m op ongeveer hetzelfde moment. Als de ontvanger de eerste kopie van m niet kan ontvangen voordat de primaire wachtrij niet meer beschikbaar is, ontvangt de ontvanger aanvankelijk alleen de tweede kopie van m, maar ontvangt vervolgens een tweede kopie van m wanneer de primaire wachtrij beschikbaar is.
De Azure Messaging-replicatietaken met het .NET Core-voorbeeld laat de replicatie van berichten tussen naamruimten zien.
Volgende stappen
Zie de volgende artikelen voor meer informatie over herstel na noodgevallen: