Share via

Best practices voor de isolatie van toepassingen tegen Service Bus-uitval en -noodgevallen

  • Artikel

Bedrijfskritieke toepassingen moeten continu werken, zelfs in aanwezigheid van ongeplande storingen of rampen. Tolerantie tegen rampzalige uitval van resources voor gegevensverwerking is een vereiste voor veel ondernemingen en in sommige gevallen zelfs vereist door branchevoorschriften. In dit artikel worden technieken beschreven die u kunt gebruiken om Service Bus-toepassingen te beschermen tegen een mogelijke servicestoring of noodgeval.

Azure Service Bus verspreidt al het risico op catastrofale fouten van afzonderlijke machines of zelfs complete racks tussen clusters die meerdere foutdomeinen binnen een datacenter omvatten en implementeert transparante foutdetectie- en failovermechanismen, zodat de service blijft werken binnen de verzekerde serviceniveaus en doorgaans zonder merkbare onderbrekingen wanneer dergelijke fouten optreden.

Bovendien is het storingsrisico verder verspreid over drie fysiek gescheiden faciliteiten (beschikbaarheidszones) en heeft de service voldoende capaciteitsreserves om direct te kunnen omgaan met het volledige, catastrofale verlies van een datacenter. Het volledig actieve Azure Service Bus-clustermodel binnen een foutdomein, samen met de ondersteuning van de beschikbaarheidszone, is beter dan elk on-premises message broker-product in termen van tolerantie tegen ernstige hardwarefouten en zelfs onherstelbaar verlies van volledige datacenterfaciliteiten. Toch kunnen er ernstige situaties zijn met wijdverspreide fysieke vernietiging die zelfs die maatregelen niet voldoende kunnen verdedigen.

De functies voor Geo-Disaster Recovery en Geo-Replicatie van Service Bus zijn ontworpen om het gemakkelijker te maken om te herstellen van een noodgeval van deze omvang en om een mislukte Azure-regio te verlaten voorgoed en zonder dat u uw toepassingsconfiguraties hoeft te wijzigen.

Storingen en rampen

Het is belangrijk om het onderscheid tussen 'storingen' en 'rampen' op te merken.

Een storing is de tijdelijke onbeschikbaarheid van Azure Service Bus en kan van invloed zijn op sommige onderdelen van de service, zoals een berichtenarchief of zelfs het hele datacenter. Nadat het probleem is opgelost, is Service Bus echter 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. Sommige storingen zijn slechts korte verbindingsverlies vanwege tijdelijke of netwerkproblemen.

Een noodgeval wordt gedefinieerd als het permanente of langdurige verlies van een Service Bus-cluster, Azure-regio of datacenter. De regio of het datacenter is mogelijk al dan niet weer beschikbaar of is uren of dagen niet beschikbaar. Voorbeelden van dergelijke rampen zijn brand, overstroming of aardbeving. Een noodgeval dat permanent wordt, kan het verlies van bepaalde berichten, gebeurtenissen of andere gegevens veroorzaken. In de meeste gevallen mag er echter geen gegevensverlies zijn en kunnen berichten worden hersteld zodra het datacentrum weer terugkomt.

Bescherming tegen storingen en rampen

Er zijn twee functies die Geo-Disaster Recovery bieden in Azure Service Bus voor de Premium-laag. Ten eerste is er geo-noodherstel (herstel na noodgevallen van metagegevens) die replicatie van metagegevens (entiteiten, configuratie, eigenschappen) biedt. Ten tweede is er geo-replicatie, die momenteel in openbare preview is, waardoor zowel metagegevens als gegevens (berichtgegevens en berichteigenschap/statuswijzigingen) zelf worden replicatie geboden. De functie Geo-Disaster Recovery moet niet worden verward met Beschikbaarheidszones. Ongeacht of het gaat om herstel na noodgeval of geo-replicatie van metagegevens, bieden beide functies voor geo-grafische herstelmogelijkheden tussen Azure-regio's zoals VS - oost en VS - west.

Beschikbaarheidszones zijn beschikbaar voor alle Service Bus-lagen en ondersteuning biedt tolerantie binnen een specifieke geografische regio, zoals VS - oost. Zie dit artikel voor een gedetailleerde bespreking van herstel na noodgevallen in Microsoft Azure.

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-Disaster Recovery en Geo-Replication).

Opties voor geo-herstel na noodgevallen

Herstel na noodgevallen

De Service Bus Premium-laag ondersteunt Geo-Disaster Recovery op naamruimteniveau. Zie Azure Service Bus Geo-Disaster Recovery voor meer informatie. De functie Geo-disaster recovery, alleen beschikbaar voor de Premium-laag , implementeert herstel na noodgevallen van metagegevens en is afhankelijk van primaire en secundaire naamruimten. Met Geo-Disaster Recovery worden alleen metagegevens voor entiteiten gerepliceerd tussen primaire en secundaire naamruimten.

Geo-replicatie

De Service Bus Premium-laag biedt ook ondersteuning voor geo-replicatie op naamruimteniveau. Zie Azure Service Bus Geo-Replicatie (openbare preview) voor meer informatie. De functie Geo-replicatie, alleen beschikbaar voor de Premium-laag en momenteel in openbare preview, implementeert metagegevens en herstel na noodgevallen van gegevens en is afhankelijk van primaire en secundaire regio's. Met geo-replicatie worden zowel metagegevens als gegevens voor entiteiten gerepliceerd tussen primaire en secundaire regio's.

Functieverschillen op hoog niveau

Met de functie Geo-Disaster Recovery (Metadata DR) worden metagegevens voor een naamruimte van een primaire naamruimte naar een secundaire naamruimte gerepliceerd. Het ondersteunt een eenmalige failover naar de secundaire regio. Tijdens de door de klant geïnitieerde failover wordt de aliasnaam voor de naamruimte opnieuw aan de secundaire naamruimte toegewezen en wordt de koppeling verbroken. Er worden geen andere gegevens dan metagegevens gerepliceerd en RBAC-toewijzingen worden ook niet gerepliceerd.

De functie Geo-replicatie repliceert metagegevens en alle gegevens van een primaire regio naar een of meer secundaire regio's. Wanneer een failover door de klant wordt uitgevoerd, wordt de geselecteerde secundaire de primaire en de vorige primaire wordt een secundaire. Gebruikers kunnen desgewenst een failover uitvoeren naar de oorspronkelijke primaire server.

Beschikbaarheidszones

Alle Service Bus-lagen ondersteunen 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 is alleen beschikbaar in Azure-regio's waar beschikbaarheidszones aanwezig zijn.

Wanneer u een naamruimte maakt, wordt de ondersteuning voor beschikbaarheidszones (indien beschikbaar in de geselecteerde regio) automatisch ingeschakeld voor de naamruimte. 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.

Notitie

Voorheen moest de eigenschap zoneRedundant worden ingesteld om true beschikbaarheidszones in te schakelen, maar dit gedrag is gewijzigd om standaard beschikbaarheidszones in te schakelen. Bestaande naamruimten worden ook gemigreerd naar beschikbaarheidszones en de eigenschap zoneRedundant wordt afgeschaft. De eigenschap zoneRedundant kan nog steeds worden weergegeven als false, zelfs wanneer beschikbaarheidszones zijn ingeschakeld.

Bescherming tegen rampen - Standard-laag

Als u tolerantie wilt bereiken tegen noodgevallen met de Service Bus Standard-laag, 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.

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: