Delen via

Betrouwbaarheid in Azure Service Bus

Azure Service Bus is een volledig beheerde berichtenbrokerservice voor ondernemingen die betrouwbare asynchrone berichtenmogelijkheden biedt voor het loskoppelen van toepassingen en services. Service Bus ondersteunt wachtrijen voor punt-naar-punt-communicatie en onderwerpen met abonnementen voor berichtpatronen voor publiceren-abonneren. De service biedt ingebouwde betrouwbaarheidsfuncties, waaronder duurzaamheid van berichten, ten minste eenmaal bezorgingsgaranties en dead-letter queues voor het verwerken van mislukte berichten.

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 Service Bus tolerant maakt voor verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone en regio-storingen. Ook worden enkele belangrijke stukken informatie over de Service Bus SLA uitgelicht.

Aanbevelingen voor productie-implementatie

Het Azure Well-Architected Framework biedt aanbevelingen voor betrouwbaarheid, prestaties, beveiliging, kosten en bewerkingen. Als u wilt begrijpen hoe deze gebieden elkaar beïnvloeden en bijdragen aan een betrouwbare App Service-oplossing, raadpleegt u Architectuur Best Practices voor Azure Service Bus in het Azure Well-Architected Framework.

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

Een naamruimte fungeert als de beheercontainer voor Service Bus en kan worden geconfigureerd voor het gebruik van de Basic-, Standard- of Premium-laag. U configureert de service op naamruimteniveau door capaciteit toe te wijzen, netwerkbeveiliging te configureren en Geo-Replication en Geo-Disaster Recovery in te schakelen.

Binnen een naamruimte implementeert u wachtrijen en onderwerpen, die berichtenentiteiten met verschillende semantiek zijn. Zie Service Bus-wachtrijen, -onderwerpen en -abonnementen voor meer informatie.

U kunt eventueel partities in uw naamruimte configureren, waarmee wachtrijen en onderwerpen worden verspreid over meerdere berichtenbrokers en berichtenarchieven. Een naamruimte kan meerdere partities gebruiken om parallelle verwerking en horizontaal schalen uit te voeren. Service Bus garandeert alleen bestellen binnen één partitie. Partitionering speelt een belangrijke rol in het betrouwbaarheidsontwerp van uw toepassing. Wanneer u uw toepassing ontwerpt, moet u een afweging maken tussen het maximaliseren van beschikbaarheid en consistentie. Voor de Premium-laag schakelt u partitionering in op de naamruimte. Voor Basic- en Standard-laagnaamruimten configureert u partities op de entiteit en optioneel wanneer u berichten verzendt.

U kunt Service Bus en de asynchrone ontwerpmethoden gebruiken om de beschikbaarheid van uw toepassingen te vergroten. Zie Asynchrone berichtpatronen en hoge beschikbaarheid voor meer informatie.

Fysieke architectuur

Service Bus biedt de onderliggende reken- en opslagresources. Voor elke naamruimte verwerken meerdere berichtbrokers de berichten en meerdere berichtenarchieven slaan de berichten op. Er zijn drie kopieën van het berichtenarchief: één primaire en twee 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.

Voor naamruimten die gebruikmaken van de Basic- of Standard-laag biedt Service Bus redundantie via een gedeelde multitenant-infrastructuur waarmee berichten automatisch worden gerepliceerd in beschikbaarheidszones waar beschikbaar. De service onderhoudt meerdere berichtenarchieven en houdt alle kopieën gesynchroniseerd voor zowel gegevens- als beheerbewerkingen.

Voor naamruimten in de Premium-laag biedt Service Bus toegewezen berichteneenheden, elk met toegewezen CPU- en geheugenresources. Naamruimten in de Premium-laag kunnen automatisch worden geschaald op basis van de workloadvereisten. Zie Berichteneenheden van een Azure Service Bus-naamruimte automatisch bijwerken voor meer informatie.

De Service Bus-infrastructuur omvat meerdere fysieke machines en racks die verspreid zijn over foutdomeinen, waardoor het risico op onherstelbare fouten die van invloed zijn op uw naamruimte, wordt verminderd. In regio's met beschikbaarheidszones wordt de infrastructuur uitgebreid tussen afzonderlijke fysieke datacenters. De service implementeert transparante foutdetectie en failovermechanismen, zodat deze blijft werken binnen de verzekerde serviceniveaus en doorgaans zonder merkbare onderbrekingen wanneer dergelijke fouten optreden.

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 in de cloud gehoste toepassingen moeten de richtlijnen voor tijdelijke foutafhandeling van Azure volgen wanneer ze communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

De Azure Service Bus SDK bevat automatische herprobeerlogica met exponentiële terugval voor bewerkingen die mislukken vanwege tijdelijke omstandigheden zoals netwerktime-outs of tijdelijke onbeschikbaarheid van de service. Wanneer toepassingen tijdelijk de verbinding met Service Bus verbreken, probeert de SDK automatisch opnieuw verbinding te maken met behulp van het geconfigureerde beleid voor opnieuw proberen.

Als u de tijdelijke foutafhandeling in uw toepassingen wilt optimaliseren, gebruikt u de nieuwste Service Bus SDK, die de meest recente functies voor opnieuw proberen en verbindingsbeheer bevat. Zie de Azure Service Bus-clientbibliotheek voor .NET voor meer informatie.

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.

Service Bus ondersteunt zone-redundante implementaties in alle servicelagen. Wanneer u een Service Bus-naamruimte in een ondersteunde regio maakt, wordt zoneredundantie automatisch ingeschakeld zonder extra kosten. Het zone-redundante implementatiemodel is van toepassing op alle Service Bus-functies, waaronder partitionering en sessies.

Service Bus repliceert uw configuratie-, metagegevens- en berichtgegevens transparant over meerdere beschikbaarheidszones in de regio. Zoneredundantie biedt automatische failover zonder tussenkomst van u. Alle Service Bus-onderdelen, waaronder compute, netwerken en opslag, worden gerepliceerd in verschillende zones. Service Bus heeft voldoende capaciteitsreserves om direct het volledige verlies van een zone af te handelen. Zelfs als een volledige beschikbaarheidszone niet beschikbaar is, blijft Service Bus werken zonder gegevensverlies of onderbreking van berichtentoepassingen.

Diagram met een zoneredundante Service Bus-naamruimte.

Requirements

  • Regioondersteuning: Zone-redundante Service Bus-naamruimten kunnen worden geïmplementeerd in Azure-regio's met ondersteuning voor beschikbaarheidszones. Service Bus schakelt automatisch ondersteuning voor beschikbaarheidszones in wanneer u een naamruimte in een ondersteunde regio maakt, zonder dat er aanvullende configuratie is vereist.

  • Lagen: Alle Service Bus-lagen (Basic, Standard en Premium) ondersteunen beschikbaarheidszones zonder aanvullende vereisten.

Overwegingen

Service Bus-naamruimten bevatten een zoneRedundant eigenschap. Voorheen was deze eigenschap vereist om beschikbaarheidszones in te schakelen, maar dit gedrag is gewijzigd en de zoneRedundant eigenschap wordt afgeschaft. Deze eigenschap kan nog steeds worden weergegeven als false zelfs wanneer zoneredundantie is ingeschakeld. Alle naamruimten in regio's met beschikbaarheidszones zijn zone-redundant.

Kosten

Zoneredundantie in Service Bus voegt geen extra kosten toe.

Ondersteuning voor beschikbaarheidszones configureren

Service Bus-naamruimten bieden automatisch ondersteuning voor zoneredundantie wanneer ze worden geïmplementeerd in ondersteunde regio's. Er is geen verdere configuratie vereist.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer Service Bus-naamruimten zijn geconfigureerd voor zoneredundantie en alle beschikbaarheidszones operationeel zijn.

  • Verkeersroutering tussen zones. Service Bus maakt gebruik van een actief-actief model waarbij berichten worden verdeeld over meerdere beschikbaarheidszones. Clientverbindingen worden automatisch verdeeld over zones en de service routeert bewerkingen naar de beschikbare berichteninfrastructuur, ongeacht de zone.

  • Gegevensreplicatie tussen zones. Service Bus maakt gebruik van synchrone replicatie in beschikbaarheidszones, waaronder voor metagegevens en berichtgegevens. Meerdere kopieën van het berichtenarchief moeten schrijfbewerkingen bevestigen voordat ze als voltooid worden beschouwd, waardoor de consistentie van gegevens tussen zones tijdens normale bewerkingen wordt gegarandeerd.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer Service Bus-naamruimten zijn geconfigureerd voor zoneredundantie en er een storing in de beschikbaarheidszone is.

  • Detectie en reactie: Microsoft detecteert automatisch zonefouten en initieert failover naar gezonde zones. Er is geen actie van de klant vereist voor failover op zoneniveau.
  • Melding: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Service Health echter 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 kan Service Bus actieve aanvragen verwijderen. Als uw clients tijdelijke fouten op de juiste wijze afhandelen door het opnieuw te proberen na een korte periode, worden meestal aanzienlijke gevolgen vermeden.

  • Verwacht gegevensverlies: er treden geen gegevensverlies op tijdens een zonefout, omdat Service Bus berichten synchroon repliceert tussen zones vóór bevestiging.

  • Verwachte downtime: een zonefout kan enkele seconden downtime veroorzaken. Als uw clients tijdelijke fouten op de juiste wijze afhandelen door het opnieuw te proberen na een korte periode, worden meestal aanzienlijke gevolgen vermeden.

  • Verkeer omleiden: Service Bus detecteert het verlies van de zone en stuurt nieuwe aanvragen automatisch om naar een andere replica in een van de gezonde beschikbaarheidszones.

    De Service Bus SDK verwerkt doorgaans verbindingsbeheer en logica voor opnieuw proberen op transparante wijze.

Zoneherstel

Wanneer een beschikbaarheidszone herstelt, integreert Service Bus de zone automatisch opnieuw in de actieve servicetopologie. De herstelde zone begint met het accepteren van nieuwe verbindingen en het verwerken van berichten naast de andere zones. Gegevens die zijn gerepliceerd naar overlevende zones tijdens de storing blijven intact en normale synchrone replicatie wordt hervat in alle zones. U hoeft geen actie te ondernemen voor zoneherstel en re-integratie.

Testen op zonefouten

Service Bus beheert verkeersroutering, failover en zoneherstel voor zonefouten, zodat u geen processen voor fouten in de beschikbaarheidszone hoeft te valideren of verdere invoer hoeft op te geven.

Tolerantie voor storingen in de hele regio

Service Bus biedt twee typen ondersteuning voor meerdere regio's, waarvoor beide naamruimten van de Premium-laag zijn vereist:

  • Geo-replicatie biedt actief-passieve replicatie van metagegevens en berichtgegevens tussen een primaire regio en een secundaire regio. Gebruik Geo-Replication voor de meeste toepassingen die bestand moeten blijven tegen storingen in regio's en een lage tolerantie hebben voor berichtgegevensverlies.

  • Metagegevens Geo-Disaster Recovery biedt actief-passieve replicatie van configuratie en metagegevens tussen een primaire en secundaire regio, maar repliceert geen berichtgegevens. Overweeg het gebruik van Geo-Disaster Recovery voor toepassingen die hun eigen gegevensreplicatie verwerken of die geen gegevensreplicatie nodig hebben.

Voor zowel Geo-Replication als metagegevens Geo-Disaster Herstel moet u handmatig een failover (overstappen naar een andere regio) of promotie van een secundaire regio naar primaire initiëren, waardoor deze de nieuwe primaire regio wordt. Microsoft voert geen failover of promotie automatisch uit, ook al valt uw primaire regio uit.

Naamruimten in de lagen Basic en Standard bevatten geen systeemeigen functies voor meerdere regio's, maar u kunt replicatiepatronen op toepassingsniveau implementeren met behulp van meerdere naamruimten in verschillende regio's. Zie de sectie Aangepaste oplossingen voor meerdere regio's voor tolerantie hieronder voor meer informatie.

Geo-Replication

De Premium-laag biedt ondersteuning voor geo-replicatie. Deze functie repliceert zowel metagegevens (zoals entiteiten, configuratie en eigenschappen) als gegevens (zoals berichten in uw wachtrijen en onderwerpen, en berichteigenschappen en status) voor de naamruimte. U configureert de replicatiebenadering voor de configuratie en gegevens van uw naamruimte. Deze functie zorgt ervoor dat uw berichten beschikbaar blijven in een andere regio en u kunt zo nodig overschakelen naar de secundaire regio.

Gebruik Geo-Replication voor scenario's die tolerantie vereisen voor regiostoringen en een lage tolerantie hebben voor berichtgegevensverlies.

De naamruimte strekt zich in wezen uit over regio's. De ene regio fungeert als de primaire regio en de andere regio's dienen als secundaire regio. Uw Azure-abonnement toont één naamruimte.

Diagram met een Service Bus-naamruimte die is geconfigureerd voor geo-replicatie.

U kunt de secundaire regio op elk gewenst moment promoveren naar een primaire regio. Wanneer u de secundaire regio promoveert, verwijst Service Bus de FQDN (Fully Qualified Domain Name) van de naamruimte opnieuw naar de geselecteerde secundaire regio en wordt de vorige primaire regio gedegradeerd naar een secundaire regio. U bepaalt of u een geplande promotie wilt uitvoeren, wat betekent dat u wacht totdat de gegevensreplicatie is voltooid, of een geforceerde promotie, wat kan leiden tot gegevensverlies.

Opmerking

Service Bus Geo-Replication maakt gebruik van de term promotie omdat deze het beste het proces van het promoten van een secundaire regio naar een primaire regio vertegenwoordigt (en later een primaire regio degradeert naar een secundaire regio). Mogelijk ziet u ook de term failover die wordt gebruikt om het algemene proces te beschrijven.

In deze sectie vindt u een overzicht van belangrijke aspecten van geo-replicatie. Raadpleeg de volledige documentatie om precies te begrijpen hoe het werkt. Zie Service Bus Geo-Replication voor meer informatie.

Requirements

  • Regioondersteuning: U kunt elke Azure-regio kiezen die Service Bus ondersteunt als uw primaire regio of secundaire regio. U hoeft geen gekoppelde Azure-regio's te gebruiken, zodat u secundaire regio's kunt kiezen op basis van uw vereisten voor latentie, naleving of gegevenslocatie.

  • Rang: Als u Geo-replicatie wilt inschakelen, moet uw naamruimte de Premium-laag gebruiken.

  • Metadata Geo-Disaster Recovery: U kunt een naamruimte niet configureren om zowel Geo-Replication als Geo-Disaster Recovery te gebruiken.

Overwegingen

  • Functiebeperkingen: Wanneer u Geo-replicatie inschakelt, zijn er enkele beperkingen. Zie Service Bus Geo-Replication voor meer informatie.

  • Privé-eindpunten: Als u privé-eindpunten gebruikt om verbinding te maken met uw naamruimte, moet u ook netwerken configureren in uw primaire en secundaire regio's. Zie privé-eindpunten in de documentatie van Azure Event Hubs voor meer informatie.

Kosten

Zie Prijzen voor meer informatie over de werking van prijzen voor Geo-replicatie.

Ondersteuning voor meerdere regio's configureren

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer een Service Bus-naamruimte is geconfigureerd voor geo-replicatie en de primaire regio operationeel is.

  • Verkeersroutering tussen regio's: Clienttoepassingen maken verbinding via de FQDN voor uw naamruimte en hun verkeer wordt gerouteerd naar de primaire regio.

    Alleen de primaire regio verwerkt berichten van clients actief tijdens normale bewerkingen. De secundaire regio ontvangt gerepliceerde berichten, maar blijft anders passief in de stand-bymodus.

  • Gegevensreplicatie tussen regio's: Het gedrag van gegevensreplicatie tussen de primaire en secundaire regio is afhankelijk van of u de replicatiekoppeling configureert voor het gebruik van synchrone of asynchrone replicatie.

    • Synchroon: Berichten worden gerepliceerd naar de secundaire regio voordat de schrijfbewerking is voltooid.

      Deze modus biedt de grootste zekerheid dat uw berichtgegevens veilig zijn omdat deze moeten worden doorgevoerd in de primaire en secundaire regio. Synchrone replicatie verhoogt echter de schrijflatentie voor binnenkomende berichten aanzienlijk. Het vereist ook dat de secundaire regio beschikbaar is om de schrijfbewerking te accepteren, zodat een storing in de secundaire regio ervoor zorgt dat de schrijfbewerking mislukt.

      • Asynchroon: Berichten worden naar de primaire regio geschreven en vervolgens wordt de schrijfbewerking voltooid. Kort later worden de berichten gerepliceerd naar de secundaire regio.

      Deze modus biedt een hogere schrijfdoorvoer dan synchrone replicatie, omdat er geen latentie tussen regio's is tijdens schrijfbewerkingen. Bovendien kan de asynchrone replicatiemodus het verlies van de secundaire regio tolereren terwijl schrijfbewerkingen in de primaire regio nog steeds worden toegestaan. Als de primaire regio echter een storing heeft, zijn gegevens die nog niet zijn gerepliceerd naar de secundaire regio mogelijk niet beschikbaar of verloren gegaan.

      Wanneer u asynchrone replicatie configureert, configureert u de maximale acceptabele vertragingstijd voor replicatie. U kunt de huidige replicatievertraging op elk gewenst moment controleren met behulp van metrische gegevens van Azure Monitor.

      Als de asynchrone replicatievertraging toeneemt boven het maximum dat u opgeeft, begint de primaire regio binnenkomende aanvragen te beperken, zodat de replicatie kan inhalen. Om deze situatie te voorkomen, is het belangrijk om secundaire regio's te selecteren die niet te ver van elkaar liggen en ervoor te zorgen dat uw capaciteit voldoende is voor de doorvoer.

      Sommige metagegevenstypen worden synchroon gerepliceerd, zelfs als u de asynchrone replicatiemodus selecteert.

      Zie Replicatiemodi voor meer informatie.

Gedrag tijdens een regiostoring

In deze sectie wordt beschreven wat u kunt verwachten wanneer een Service Bus-naamruimte is geconfigureerd voor Geo-Replication en er een storing optreedt in de primaire of secundaire regio.

  • Detectie en reactie: U bent verantwoordelijk voor het bepalen wanneer u de secundaire regio van uw naamruimte wilt promoten om de nieuwe primaire regio te worden. Microsoft neemt deze beslissing niet of initieert het proces voor u, zelfs niet als er sprake is van een storing in de regio. Zie Aanbevolen scenario's voor het activeren van promotie voor voorgestelde criteria om te bepalen of er een failover moet worden uitgevoerd.

    Zie Promotiestroom voor meer informatie over het promoveren van een secundaire regio naar de nieuwe primaire regio.

    Wanneer u een secundaire regio promovt, kiest u of u een geplande promotie of een geforceerde promotie wilt uitvoeren. Een geplande promotie wacht totdat de secundaire regio is bijgewerkt voordat nieuw verkeer wordt geaccepteerd. Deze aanpak elimineert gegevensverlies, maar introduceert downtime.

    Tijdens een storing in de primaire regio moet u doorgaans een geforceerde promotie uitvoeren. Als de primaire regio beschikbaar is en u om een andere reden een promotie activeert, kunt u een geplande promotie kiezen.

  • Melding: Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. 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: Het gedrag is afhankelijk van of de regio-storing plaatsvindt in de primaire regio of de secundaire regio:

    • Storing in primaire regio: Als de primaire regio niet beschikbaar is, worden alle actieve aanvragen beëindigd. Clienttoepassingen moeten bewerkingen opnieuw proberen nadat de promotie is voltooid.

    • Storing in secundaire regio: Een storing in de secundaire regio kan in de volgende situaties problemen veroorzaken voor actieve aanvragen:

      • Als u de synchrone replicatiemodus gebruikt, kan de primaire regio schrijfbewerkingen niet voltooien als er een secundaire regio niet beschikbaar is.

      • Als je de asynchrone replicatiemodus gebruikt, beperkt je naamruimte en accepteert geen nieuwe berichten nadat de replicatievertraging het maximum bereikt dat je hebt geconfigureerd.

      Als u de naamruimte in de primaire regio wilt blijven gebruiken, verwijdert u de secundaire naamruimte uit uw Geo-Replication-configuratie.

  • Verwachte gegevensverlies: De hoeveelheid gegevensverlies is afhankelijk van het type promotie dat u uitvoert (gepland of geforceerd) en de replicatiemodus (synchroon of asynchroon):

    • Geplande promotie: Er wordt geen gegevensverlies verwacht. Tijdens een storing in een regio is een geplande promotie echter mogelijk niet mogelijk omdat alle primaire en secundaire regio's beschikbaar moeten zijn.

    • Geforceerde promotie, synchrone replicatie: Er wordt geen gegevensverlies verwacht.

    • Geforceerde promotie, asynchrone replicatie: Mogelijk ondervindt u gegevensverlies voor recente berichten die niet naar de secundaire regio worden gerepliceerd en voor statuswijzigingen die nog niet zijn gerepliceerd. De hoeveelheid is afhankelijk van de replicatievertraging. Gebruik metrische gegevens van Azure Monitor om de huidige replicatievertraging te controleren.

    Als u een geforceerde promotie uitvoert, kunt u verloren gegevens niet herstellen, zelfs niet nadat de primaire regio beschikbaar is.

  • Verwachte downtime: De hoeveelheid verwachte downtime is afhankelijk van of u een geplande of geforceerde promotie uitvoert:

    • Geplande promotie: De eerste stap in een geplande promotie repliceert gegevens naar de secundaire regio. Dit proces wordt meestal snel voltooid, maar in sommige situaties kan het tot de lengte van de replicatievertraging duren. Nadat de replicatie is voltooid, duurt het promotieproces doorgaans ongeveer 5 tot 10 minuten. Het kan soms langer duren voordat DNS-servers (Domain Name System) vermeldingen bijwerken en hun records volledig repliceren naar clients.

      De primaire regio accepteert geen schrijfbewerkingen tijdens het hele promotieproces.

      Deze optie is mogelijk niet mogelijk tijdens een storing in een regio, omdat hiervoor alle primaire en secundaire regio's beschikbaar moeten zijn.

    • Geforceerde promotie: Tijdens een geforceerde promotie wacht Service Bus niet totdat de gegevensreplicatie is voltooid en wordt de promotie onmiddellijk gestart. Het promotieproces duurt doorgaans ongeveer 5 tot 10 minuten. Het kan soms langer duren voordat DNS-vermeldingen volledig worden gerepliceerd en bijgewerkt tussen clients.

      De primaire regio accepteert geen schrijfbewerkingen tijdens het hele promotieproces.

  • Verkeer omleiden: Nadat de promotie is voltooid, verwijst de FQDN van de naamruimte naar de nieuwe primaire regio. Maar deze omleiding is afhankelijk van hoe snel de DNS-records van clients worden bijgewerkt, inclusief dat hun DNS-servers de time-to-live (TTL) van de DNS-records van de naamruimte respecteren.

Herstel van de regio

Nadat de oorspronkelijke primaire regio is hersteld, volgt u hetzelfde promotieproces als u de naamruimte wilt terugzetten naar de oorspronkelijke primaire regio.

Als u tijdens de onderbreking van de regio een geforceerde promotie hebt uitgevoerd, kunt u geen verloren gegevens herstellen, zelfs niet nadat de primaire regio beschikbaar is.

Test voor regiofouten

Als u geo-replicatie wilt testen, promoveert u tijdelijk de secundaire regio naar de primaire regio en controleert u of uw clienttoepassingen kunnen schakelen tussen regio's met minimale onderbrekingen.

Controleer de duur van de promotie en controleer of uw runbooks en automatisering correct werken. Na het testen kunt u een failback uitvoeren naar de oorspronkelijke configuratie.

Krijg inzicht in de mogelijke downtime en gegevensverlies die u mogelijk ondervindt tijdens en na het promotieproces. Test Geo-Replication in een niet-productieomgeving die de configuratie van uw productienaamruimte weerspiegelt.

Metagegevens Geo-Disaster herstellen

De Premium-laag biedt ondersteuning voor metagegevens Geo-Disaster Recovery. Deze functie verbetert het herstel van noodscenario's, waaronder het catastrofale verlies van een regio. Geo-Disaster Herstel repliceert alleen de configuratie en metagegevens van uw naamruimte. Er worden echter geen berichtgegevens gerepliceerd. Ter ondersteuning van herstel na noodgevallen zorgt deze functie ervoor dat een naamruimte in een andere regio vooraf is geconfigureerd en gereed is om berichten van clients onmiddellijk te accepteren. Geo-Disaster Recovery fungeert als een oplossing voor herstel in één richting en biedt geen ondersteuning voor failback naar de vorige primaire regio.

Metadata Geo-Rampenherstel werkt het beste voor toepassingen die niet strikt elk bericht hoeven te bewaren en die enige mate van gegevensverlies tijdens een noodscenario kunnen verdragen. Metagegevens Geo-Disaster Herstel zijn mogelijk ook geschikt voor toepassingen die gegevens zelf repliceren of die helemaal geen gegevensreplicatie nodig hebben. Als uw berichten bijvoorbeeld grote afbeeldingen vertegenwoordigen die u later converteert naar miniaturen, kunt u besluiten dat u bepaalde berichten uit een mislukte regio kunt verliezen als u snel de verwerking van nieuwe berichten in een andere regio kunt hervatten en u de berichten later kunt reconstrueren om in te halen.

Belangrijk

Geo-Disaster Recovery maakt continuïteit mogelijk van bewerkingen met dezelfde configuratie, maar geen berichtgegevens repliceert. Als u berichtgegevens wilt repliceren, kunt u geo-replicatie gebruiken.

Wanneer u metagegevens configureert Geo-Disaster Recovery, maakt u een alias waarmee clienttoepassingen verbinding maken. De alias is een FQDN waarmee al het verkeer standaard naar de primaire naamruimte wordt doorgestuurd.

Diagram met twee Service Bus-naamruimten die zijn geconfigureerd voor metagegevens Geo-Disaster Recovery.

Als de primaire regio mislukt of een ander type noodgeval optreedt, kunt u handmatig een eenmalige failover initiëren van de primaire regio naar de secundaire regio op elk gewenst moment. U kunt ervoor kiezen om een veilige failover uit te voeren, die wacht tot replicaties zijn voltooid voordat u overschakelt naar de secundaire, hoewel deze optie mogelijk niet beschikbaar is tijdens een regiostoring. Zodra een failover is gestart, wordt deze bijna onmiddellijk voltooid. Tijdens het failoverproces verwijst de Geo-Disaster Recovery-alias opnieuw naar de secundaire naamruimte en wordt de koppeling verwijderd.

In deze sectie vindt u een overzicht van belangrijke aspecten van Geo-Disaster Recovery. Raadpleeg de volledige documentatie om precies te begrijpen hoe het werkt. Zie Service Bus Geo-Disaster Recovery voor meer informatie.

Requirements

  • Regioondersteuning: U kunt elke Azure-regio selecteren die Service Bus ondersteunt als uw primaire of secundaire naamruimte. U hoeft geen gekoppelde Azure-regio's te gebruiken, zodat u secundaire regio's kunt kiezen op basis van uw vereisten voor latentie, naleving of gegevenslocatie.

  • Rang: Als u metagegevens Geo-Disaster Recovery wilt inschakelen, moeten beide naamruimten de Premium-laag gebruiken.

  • Partitioneren: Het is niet mogelijk om een gepartitioneerde naamruimte te koppelen aan een niet-gepartitioneerde naamruimte.

  • Metadata Geo-Disaster Recovery: U kunt een naamruimte niet configureren om zowel Geo-Replication als Geo-Disaster Recovery te gebruiken.

Overwegingen

  • Functiebeperkingen: Wanneer u Geo-Disaster Herstel inschakelt, zijn er enkele beperkingen. Zie Belangrijke punten om rekening mee te houden en overwegingen voor meer informatie.

  • Roltoewijzingen: RBAC-toewijzingen (Op rollen gebaseerd toegangsbeheer) van Microsoft Entra voor entiteiten in de primaire naamruimte worden niet gerepliceerd naar de secundaire naamruimte. Maak handmatig roltoewijzingen in de secundaire naamruimte om de toegang tot deze toewijzingen te beveiligen.

  • Toepassingsontwerp: Geo-Disaster Recovery vereist specifieke overwegingen bij het ontwerpen van uw clienttoepassingen. Zie Overwegingenvoor meer informatie.

  • Privé-eindpunten: Als u privé-eindpunten gebruikt om verbinding te maken met uw naamruimte, configureert u netwerken in zowel uw primaire als secundaire regio. Zie Privé-eindpunten voor meer informatie.

  • Naamruimten die van Standard naar Premium zijn gemigreerd: Als uw naamruimte zich eerder in de Standard-laag bevond en u deze hebt gemigreerd naar de Premium-laag, moet u de alias anders afhandelen. Zie Service Bus Standard naar Premium voor meer informatie.

Kosten

Wanneer u metagegevens Geo-Disaster Recovery inschakelt, betaalt u voor zowel de primaire als de secundaire naamruimten.

Ondersteuning voor meerdere regio's configureren

  • Metagegevens voor Geo-Disaster Recovery-koppeling creëren. Als u herstel na noodgevallen tussen primaire en secundaire naamruimten wilt configureren, raadpleegt u Instellen en failover-proces.

  • Schakel metagegevens Geo-Disaster Herstel uit. Zie Setup en failoverstroom om de koppeling tussen naamruimten te verbreken.

Capaciteitsplanning en -beheer

Wanneer u van plan bent voor implementaties in meerdere regio's, moet u ervoor zorgen dat beide regio's voldoende capaciteit hebben om de volledige belasting af te handelen als één regio uitvalt. De secundaire regio blijft passief tijdens normale bewerkingen, maar moet het verkeer onmiddellijk verwerken na een failover. Plan hoe u de capaciteit van de secundaire naamruimte kunt schalen, zodat het productieverkeer zonder vertraging kan ontvangen. Als u extra downtime tijdens het failoverproces kunt tolereren, kunt u ervoor kiezen om de capaciteit van de secundaire naamruimte tijdens of na een failover te schalen. Als u de downtime wilt verminderen, richt u vooraf capaciteit in de secundaire naamruimte in, zodat deze gereed blijft om productiebelasting te ontvangen.

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer een Service Bus-naamruimte is geconfigureerd voor Geo-Disaster Recovery en de primaire regio operationeel is.

  • Verkeersroutering tussen regio's: Clienttoepassingen maken verbinding via de Geo-Disaster Recovery-alias voor uw naamruimte en hun verkeer wordt gerouteerd naar de primaire naamruimte in de primaire regio.

    Alleen de primaire naamruimte verwerkt berichten van clients actief tijdens normale bewerkingen. De secundaire naamruimte blijft passief in de stand-bymodus en eventuele aanvragen voor toegang tot gegevens mislukken.

  • Gegevensreplicatie tussen regio's: Alleen configuratiemetagegevens worden gerepliceerd tussen de naamruimten. Replicatie van configuratie vindt continu en asynchroon plaats.

    Alle berichtgegevens blijven alleen in de primaire naamruimte en worden niet gerepliceerd naar de secundaire naamruimte.

Gedrag tijdens een regiostoring

In deze sectie wordt beschreven wat u kunt verwachten wanneer een Service Bus-naamruimte is geconfigureerd voor Geo-Disaster Recovery en er een storing is in de primaire regio.

  • Detectie en reactie: U bent verantwoordelijk voor het bewaken van de regiostatus en het handmatig initiëren van failover. Microsoft voert geen failover uit of promoveert een secundaire regio niet automatisch, zelfs niet als uw primaire regio uitvalt.

    Zie Failover-proces voor meer informatie over het initiëren van failover.

    Wanneer u een failover start, kiest u of u een veilige failover of een standaard (geforceerde of handmatige failover) wilt uitvoeren. Een veilige failover wacht tot de replicatie naar de secundaire regio is voltooid voordat de failover wordt gestart. Deze aanpak vermindert het verlies van metagegevens, maar introduceert downtime. Voor een veilige failover moeten de naamruimten zich in hetzelfde Azure-abonnement bevinden.

    Tijdens een storing in de primaire regio moet u doorgaans een geforceerde failover uitvoeren. Als de primaire regio beschikbaar is en u om een andere reden een failover activeert, kunt u een geplande failover kiezen.

    Failover is een eenrichtingsbewerking, dus u moet later de Geo-Disaster Recovery-koppeling opnieuw instellen. Zie Regioherstel voor meer informatie.

  • Melding: Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. 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 aanvragen die worden uitgevoerd, worden beëindigd wanneer de failover wordt gestart. Clienttoepassingen moeten bewerkingen opnieuw proberen nadat de failover is voltooid.

  • Verwachte gegevensverlies:

    • Metagegevens: Configuratie en metagegevens worden doorgaans gerepliceerd naar de secundaire naamruimte. Maar replicatie van metagegevens vindt asynchroon plaats, dus recente wijzigingen worden mogelijk niet gerepliceerd, met name complexe wijzigingen. Controleer de configuratie van uw secundaire naamruimte voordat clients deze openen.

    • Berichtgegevens: Berichtgegevens worden niet gerepliceerd tussen regio's. Als de primaire regio uitvalt, zijn berichten in uw primaire naamruimte niet meer beschikbaar.

      De berichten gaan niet permanent verloren, tenzij een catastrofale ramp het totale verlies van de primaire regio veroorzaakt. Als de regio wordt hersteld, kunt u later berichten ophalen uit de primaire naamruimte.

  • Verwachte downtime: Failover vindt doorgaans binnen 5 tot 10 minuten plaats. Het kan langer duren voordat clients DNS-vermeldingen volledig repliceren en bijwerken.

  • Verkeer omleiden: Clients die de Geo-Disaster Recovery-alias gebruiken om verbinding te maken met de naamruimte, worden na een failover automatisch omgeleid naar de secundaire naamruimte. Deze omleiding is echter afhankelijk van DNS-servers die de TTL van de DNS-records van de naamruimte respecteren en clients die deze bijgewerkte DNS-records ontvangen.

Herstel van de regio

Nadat de oorspronkelijke primaire regio is hersteld, moet u de koppeling handmatig herstellen en eventueel een failback uitvoeren. Maak een nieuwe Geo-Disaster Recovery-paring met deze herstelde regio als secundair en voer vervolgens een nieuw failover uit als u terug wilt keren naar de oorspronkelijke regio. Dit proces omvat mogelijk gegevensverlies van berichten die naar de tijdelijke primaire e-mail worden verzonden.

Als het noodgeval het verlies van alle zones in de primaire regio veroorzaakt, zijn uw gegevens mogelijk onherstelbaar. In andere scenario's blijven uw berichtgegevens in de primaire naamruimte van voordat de failover kan worden hersteld. U kunt historische berichten verkrijgen uit de oude primaire naamruimte nadat u de toegang hebt hersteld. U bent verantwoordelijk voor het configureren van uw toepassingen voor het ontvangen en verwerken van deze berichten. Microsoft herstelt ze niet automatisch in uw secundaire regio.

Test voor regiofouten

Als u uw reactie- en herstelprocessen wilt testen, voert u een geplande failover uit tijdens een onderhoudsvenster. Start een failover van uw primaire naamruimte naar uw secundaire naamruimte en controleer of uw toepassingen verbinding kunnen maken met en berichten van de nieuwe primaire kunnen verwerken.

Controleer de failoverduur en verifieer of je runbooks en automatisering correct werken. Na het testen kunt u een failback uitvoeren naar de oorspronkelijke configuratie.

Krijg inzicht in de mogelijke downtime en gegevensverlies die u mogelijk ondervindt tijdens en na het failoverproces. Test metagegevens Geo-Disaster Herstel in een niet-productieomgeving die de configuratie van uw productienaamruimte weerspiegelt.

Aangepaste oplossingen voor meerdere regio's voor veerkracht

Geo-Replication en metagegevens Geo-Disaster Recovery bieden tolerantie voor regiostoringen en andere problemen en zijn geschikt voor de meeste workloads. In de volgende situaties kunnen ze echter niet aan uw behoeften voldoen:

  • U hebt vereisten voor aangepaste replicatie of voor het gelijktijdig onderhouden van meerdere actieve regio's.
  • U gebruikt een Service Bus-laag die deze functies niet ondersteunt.

Er zijn verschillende ontwerppatronen voor verschillende typen ondersteuning voor meerdere regio's in Service Bus. Veel van de patronen vereisen het implementeren van meerdere naamruimten en het configureren van uw toepassing om de naamruimten op de juiste manier te kunnen gebruiken. Zie de volgende artikelen voor meer informatie:

Tolerantie voor serviceonderhoud

Service Bus voert regelmatig onderhoud uit. Tijdens gepland onderhoud worden naamruimten verplaatst naar een redundant knooppunt dat de meest recente updates bevat. Wanneer deze verplaatsing plaatsvindt, wordt de verbinding met de client-SDK verbroken en wordt deze automatisch opnieuw verbonden in de naamruimte. Meestal worden de upgrades binnen 30 seconden uitgevoerd. Het is belangrijk dat uw toepassingen zijn voorbereid op tijdelijke netwerkafbreken die optreden tijdens de onderhoudsperioden.

Zie Richtlijnen voor Azure-onderhoudsevenementen voor Azure Service Bus voor meer informatie.

Backups en herstel

Service Bus is niet ontworpen als een langetermijnopslaglocatie voor uw gegevens. Gegevens worden doorgaans gedurende een korte periode opgeslagen in een onderwerp of wachtrij en worden vervolgens verwerkt of bewaard in een ander systeem voor gegevensopslag, waarna deze worden verwijderd. Vanwege dit ontwerp onderhoudt Service Bus automatisch replica's van berichtgegevens, maar biedt geen back-up- en herstelmogelijkheden voor berichtgegevens.

Voor scenario's waarvoor langetermijnretentie van berichten is vereist, kunt u overwegen archivering op toepassingsniveau te implementeren in Azure Storage of andere duurzame opslagservices.

Diensteniveauovereenkomst

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.

Service Bus biedt een SLA voor alle naamruimten. De SLA voor beschikbaarheid is hoger wanneer uw naamruimte voldoet aan alle volgende criteria:

  • Hierbij wordt gebruikgemaakt van de Premium-laag.
  • Het bevindt zich in een regio met beschikbaarheidszones.
  • Er wordt gebruikgemaakt van partitionering.

Verwante inhoud

  • Last updated on