Herstel na noodgevallen van Azure Service Bus

Tolerantie tegen rampzalige uitval van resources voor gegevensverwerking is een vereiste voor veel ondernemingen en in sommige gevallen zelfs vereist door branchevoorschriften.

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. Een Premium-naamruimte kan twee of meer berichteneenheden hebben en deze berichteneenheden worden verspreid over meerdere foutdomeinen binnen een datacenter, die ondersteuning bieden voor een volledig actief Service Bus-clustermodel.

Voor een naamruimte in de Premium-laag wordt het risico op storingen verder verdeeld 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 Service Bus Geo-disaster recovery-functie is 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. Het afbreken van een Azure-regio omvat doorgaans verschillende services en deze functie is voornamelijk bedoeld om de integriteit van de samengestelde toepassingsconfiguratie te behouden. De functie is wereldwijd beschikbaar voor de Service Bus Premium-SKU.

De functie voor herstel na noodgeval zorgt ervoor dat de volledige configuratie van een naamruimte (wachtrijen, onderwerpen, abonnementen, filters) continu wordt gerepliceerd van een primaire naamruimte naar een secundaire naamruimte wanneer deze is gekoppeld, en dat u een eenmalige failover kunt initiëren van de primaire naar de secundaire. Met de failover wordt de gekozen aliasnaam voor de naamruimte opnieuw naar de secundaire naamruimte verplaatst en wordt de koppeling verbroken. De failover is bijna onmiddellijk nadat deze is gestart.

Belangrijke punten om in overweging te nemen

• De functie maakt directe continuïteit van bewerkingen mogelijk met dezelfde configuratie, maar repliceert de berichten in wachtrijen of onderwerpabonnementen of wachtrijen met dode letters niet. Om de semantiek van de wachtrij te behouden, vereist een dergelijke replicatie niet alleen de replicatie van berichtgegevens, maar van elke statuswijziging in de broker. Voor de meeste Service Bus-naamruimten zou het vereiste replicatieverkeer veel groter zijn dan het toepassingsverkeer en met wachtrijen met hoge doorvoer, worden de meeste berichten nog steeds gerepliceerd naar de secundaire terwijl ze al van het primaire verkeer worden verwijderd, wat overmatige verspilling van verkeer veroorzaakt. Voor replicatieroutes met hoge latentie, die van toepassing zijn op veel koppelingen die u zou kiezen voor herstel na geo-noodgeval, is het mogelijk ook onmogelijk voor het replicatieverkeer om het toepassingsverkeer duurzaam bij te houden vanwege latentie-geïnduceerde beperkingseffecten.
• RBAC-toewijzingen (Op rollen gebaseerd toegangsbeheer) van Microsoft Entra voor Service Bus-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.
• De volgende configuraties worden niet gerepliceerd.
  • Configuraties van virtuele netwerken
  • Privé-eindpuntverbindingen
  • Toegang tot alle netwerken ingeschakeld
  • Toegang tot vertrouwde services ingeschakeld
  • Openbare netwerktoegang
  • Standaardnetwerkactie
  • Identiteiten en versleutelingsinstellingen (door de klant beheerde sleutelversleuteling of BYOK-versleuteling (Bring Your Own Key)
  • Automatisch schalen inschakelen
  • Lokale verificatie uitschakelen
• Het koppelen van een gepartitioneerde naamruimte met een niet-gepartitioneerde naamruimte wordt niet ondersteund.
• Als AutoDeleteOnIdle deze functie is ingeschakeld voor een entiteit, is de entiteit mogelijk niet aanwezig in de secundaire naamruimte wanneer de failover plaatsvindt. Wanneer de secundaire primaire de laatste toegangsstatus wordt, die geen deel uitmaakt van de metagegevens, is deze mogelijk niet beschikbaar voor de nieuwe primaire en entiteit als onderdeel van AutoDeleteOnIdle opschonen.

Tip

Voor het repliceren van de inhoud van wachtrijen en onderwerpabonnementen en het uitvoeren van bijbehorende naamruimten in actieve/actieve configuraties om te gaan met storingen en noodgevallen, leunt u niet op deze geo-noodherstelfunctieset, maar volgt u de replicatierichtlijnen.

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 dergelijke storing kan een stroomstoring zijn in het datacenter. 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.

De functie geo-noodherstel van Azure Service Bus is een oplossing voor herstel na noodgevallen. De concepten en werkstroom die in dit artikel worden beschreven, zijn van toepassing op noodscenario's en niet op tijdelijke of tijdelijke storingen. Zie dit artikel voor een gedetailleerde bespreking van herstel na noodgevallen in Microsoft Azure.

Basisconcepten en termen

De functie voor herstel na noodgevallen implementeert herstel na noodgevallen van metagegevens en is afhankelijk van primaire en secundaire naamruimten voor herstel na noodgevallen. De functie Geo-noodherstel is alleen beschikbaar voor de Premium-SKU . U hoeft geen verbindingsreeks wijzigingen aan te brengen, omdat de verbinding wordt gemaakt via een alias.

In dit artikel worden de volgende termen gebruikt:

• Alias: de naam voor een configuratie voor herstel na noodgevallen die u hebt ingesteld. De alias biedt één stabiele FQDN-verbindingsreeks (Fully Qualified Domain Name). Toepassingen gebruiken deze alias verbindingsreeks om verbinding te maken met een naamruimte. Als u een alias gebruikt, zorgt u ervoor dat de verbindingsreeks ongewijzigd blijft wanneer de failover wordt geactiveerd.

• Primaire/secundaire naamruimte: de naamruimten die overeenkomen met de alias. De primaire naamruimte is actief en ontvangt berichten (dit kan een bestaande of nieuwe naamruimte zijn). De secundaire naamruimte is passief en ontvangt geen berichten. De metagegevens tussen beide zijn gesynchroniseerd, zodat beide berichten naadloos kunnen accepteren zonder toepassingscode of verbindingsreeks wijzigingen. Als u ervoor wilt zorgen dat alleen de actieve naamruimte berichten ontvangt, moet u de alias gebruiken.

• Metagegevens: entiteiten zoals wachtrijen, onderwerpen en abonnementen en hun eigenschappen van de service die zijn gekoppeld aan de naamruimte. Alleen entiteiten en hun instellingen worden automatisch gerepliceerd. Berichten worden niet gerepliceerd.

• Failover: het proces voor het activeren van de secundaire naamruimte.

Instellingen

De volgende sectie is een overzicht van het instellen van koppelen tussen de naamruimten.

U maakt of gebruikt eerst een bestaande primaire naamruimte en een nieuwe secundaire naamruimte en koppelt vervolgens de twee. Met deze koppeling krijgt u een alias die u kunt gebruiken om verbinding te maken. Omdat u een alias gebruikt, hoeft u verbindingsreeks s niet te wijzigen. Alleen nieuwe naamruimten kunnen worden toegevoegd aan uw failoverkoppeling.

1. Maak de primaire premium-laag-naamruimte.

2. Maak de secundaire premium-laag-naamruimte in een andere regio. Deze stap is optioneel. U kunt de secundaire naamruimte maken tijdens het maken van de koppeling in de volgende stap.

3. Navigeer in Azure Portal naar uw primaire naamruimte.

4. Selecteer Geo-herstel in het linkermenu en selecteer Koppelen initiëren op de werkbalk.

   

5. Voer op de koppelingspagina Initiëren de volgende stappen uit:

   1. Selecteer een bestaande secundaire naamruimte of maak er een in een andere regio. In dit voorbeeld wordt een bestaande naamruimte gebruikt als secundaire naamruimte.

   2. Voer voor Alias een alias in voor de geo-dr-koppeling.

   3. Ten slotte selecteert u Maken.

      

6. U ziet nu de pagina Service Bus Geo-DR Alias, zoals wordt weergegeven in de volgende afbeelding. U kunt ook vanaf de primaire naamruimtepagina naar de pagina Geo-DR-alias navigeren door geo-herstel in het linkermenu te selecteren.

   

7. Selecteer op de pagina Geo-DR-alias beleid voor gedeelde toegang in het linkermenu om toegang te krijgen tot de primaire verbindingsreeks voor de alias. Gebruik deze verbindingsreeks in plaats van de verbindingsreeks rechtstreeks naar de primaire/secundaire naamruimte te gebruiken. In eerste instantie verwijst de alias naar de primaire naamruimte.

8. Ga naar de pagina Overzicht . U kunt de volgende acties uitvoeren:

   1. Verbreek de koppeling tussen primaire en secundaire naamruimten. Selecteer Koppeling verbreken op de werkbalk.
   2. Voer handmatig een failover uit naar de secundaire naamruimte.

      1. Selecteer Failover op de werkbalk.

      2. Bevestig dat u een failover wilt uitvoeren naar de secundaire naamruimte door uw alias te typen.

      3. Schakel de optie Veilige failover in om een failover naar de secundaire naamruimte veilig uit te voeren.

         Notitie

         • De veilige failover zorgt ervoor dat geo-DR-replicaties in behandeling zijn voordat u overschakelt naar de secundaire. Terwijl geforceerde of handmatige failover niet wacht totdat wachtende replicaties zijn voltooid voordat u overschakelt naar de secundaire.
         • De veilige failover mislukt momenteel als de primaire en secundaire naamruimten zich niet in hetzelfde Azure-abonnement bevinden.

      4. Selecteer vervolgens Failover.

         

         Belangrijk

         Als u een failover uitvoert, wordt de secundaire naamruimte geactiveerd en wordt de primaire naamruimte verwijderd uit de koppeling Geo-Disaster Recovery. Maak een andere naamruimte om een nieuw geo-noodherstelpaar te hebben.

9. Ten slotte moet u enkele bewaking toevoegen om te detecteren of een failover nodig is. In de meeste gevallen maakt de service deel uit van een groot ecosysteem, waardoor automatische failovers zelden mogelijk zijn, omdat failovers vaak gesynchroniseerd moeten worden met het resterende subsysteem of de resterende infrastructuur.

Service Bus Standard naar Premium

Als u uw Azure Service Bus Standard-naamruimte hebt gemigreerd naar Azure Service Bus Premium, moet u de bestaande alias (dat wil gezegd uw Service Bus Standard-naamruimte verbindingsreeks) gebruiken om de configuratie voor herstel na noodgevallen te maken via de PS/CLI of REST API.

Dit komt doordat tijdens de migratie uw Azure Service Bus Standard-naamruimte verbindingsreeks/DNS-naam zelf een alias wordt voor uw Azure Service Bus Premium-naamruimte.

Uw clienttoepassingen moeten gebruikmaken van deze alias (dat wil gezegd de Standaardnaamruimte van Azure Service Bus verbindingsreeks) om verbinding te maken met de Premium-naamruimte waar de koppeling voor herstel na noodgevallen is ingesteld.

Als u Azure Portal gebruikt om de configuratie voor herstel na noodgevallen in te stellen, wordt deze kanttekening van u door de portal geabstraheerd.

Failoverstroom

Een failover wordt handmatig geactiveerd door de klant (expliciet via een opdracht of via bedrijfslogica die eigendom is van de client die de opdracht activeert) en nooit door Azure. Het geeft de klant volledig eigendom en inzicht in de oplossing van storingen op de backbone van Azure.

Nadat de failover is geactiveerd -

1. De alias verbindingsreeks wordt bijgewerkt zodat deze verwijst naar de Secundaire Premium-naamruimte.

2. Clients (afzenders en ontvangers) maken automatisch verbinding met de secundaire naamruimte.

3. De bestaande koppeling tussen primaire en secundaire Premium-naamruimte is verbroken.

Zodra de failover is gestart -

1. Als er een andere storing optreedt, wilt u een failover opnieuw kunnen uitvoeren. Stel dus een andere passieve naamruimte in en werk de koppeling bij.

2. Haal berichten op uit de voormalige primaire naamruimte zodra deze weer beschikbaar is. Daarna gebruikt u die naamruimte voor normale berichten buiten uw geo-herstelinstallatie of verwijdert u de oude primaire naamruimte.

Notitie

Alleen semantiek voor fail-forwards worden ondersteund. In dit scenario voert u een failover uit en koppelt u deze vervolgens opnieuw aan een nieuwe naamruimte. Failback wordt niet ondersteund; Bijvoorbeeld in een SQL-cluster.

U kunt failover automatiseren met bewakingssystemen of met aangepaste bewakingsoplossingen. Voor dergelijke automatisering is echter extra planning en werk nodig, wat buiten het bereik van dit artikel valt.

Beheer

Als u bijvoorbeeld een fout hebt gemaakt, hebt u de verkeerde regio's tijdens de eerste installatie gekoppeld, kunt u de koppeling van de twee naamruimten op elk gewenst moment verbreken. Als u de gekoppelde naamruimten wilt gebruiken als gewone naamruimten, verwijdert u de alias.

Bestaande naamruimte als alias gebruiken

Als u een scenario hebt waarin u de verbindingen van producenten en consumenten niet kunt wijzigen, kunt u uw naamruimtenaam opnieuw gebruiken als aliasnaam. Bekijk hier de voorbeeldcode op GitHub.

Voorbeelden

In de voorbeelden op GitHub ziet u hoe u een failover instelt en initieert. Deze voorbeelden laten de volgende concepten zien:

• Een .NET-voorbeeld en -instellingen die vereist zijn in Microsoft Entra ID voor het gebruik van Azure Resource Manager met Service Bus, om geo-noodherstel in te stellen en in te schakelen.
• Stappen die nodig zijn om de voorbeeldcode uit te voeren.
• Een bestaande naamruimte gebruiken als alias.
• Stappen voor het inschakelen van geo-noodherstel via PowerShell of CLI.
• Verzenden en ontvangen van de huidige primaire of secundaire naamruimte met behulp van de alias.

Overwegingen

Houd rekening met de volgende overwegingen om rekening te houden met deze release:

• In uw failoverplanning moet u ook rekening houden met de tijdsfactor. Als u bijvoorbeeld langer dan 15 tot 20 minuten geen verbinding meer hebt, kunt u besluiten om de failover te starten.
• Het feit dat er geen gegevens worden gerepliceerd, betekent dat momenteel actieve sessies niet worden gerepliceerd. Bovendien werken dubbele detectie en geplande berichten mogelijk niet. Nieuwe sessies, nieuwe geplande berichten en nieuwe duplicaten werken.
• Een failover van een complexe gedistribueerde infrastructuur moet ten minste één keer worden uitgevoerd .
• Het synchroniseren van entiteiten kan enige tijd duren, ongeveer 50-100 entiteiten per minuut. Abonnementen en regels tellen ook als entiteiten.

Beschikbaarheidszones

De Service Bus Premium-SKU ondersteunt beschikbaarheidszones en biedt fout-geïsoleerde locaties binnen dezelfde Azure-regio. 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 de toepassingen tijdelijke verbinding 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 Beschikbaarheidszones ondersteuning voor Azure Service Bus Premium 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 premium-laagnaamruimte maakt via andere mechanismen, zoals ARM-/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.

Privé-eindpunten

In deze sectie vindt u meer overwegingen bij het gebruik van geo-noodherstel met naamruimten die gebruikmaken van privé-eindpunten. Zie Azure Service Bus integreren met Azure Private Link voor meer informatie over het gebruik van privé-eindpunten met Service Bus in het algemeen.

Nieuwe koppeling

Als u probeert een koppeling te maken tussen een primaire naamruimte met een privé-eindpunt en een secundaire naamruimte zonder een privé-eindpunt, mislukt de koppeling. De koppeling slaagt alleen als zowel primaire als secundaire naamruimten privé-eindpunten hebben. U wordt aangeraden dezelfde configuraties te gebruiken voor de primaire en secundaire naamruimten en op virtuele netwerken waarin privé-eindpunten worden gemaakt.

Notitie

Wanneer u de primaire naamruimte probeert te koppelen aan een privé-eindpunt en de secundaire naamruimte, controleert het validatieproces alleen of er een privé-eindpunt bestaat in de secundaire naamruimte. Er wordt niet gecontroleerd of het eindpunt werkt of werkt na een failover. Het is uw verantwoordelijkheid om ervoor te zorgen dat de secundaire naamruimte met een privé-eindpunt werkt zoals verwacht na een failover.

Als u wilt testen of de configuraties van het privé-eindpunt hetzelfde zijn, verzendt u een aanvraag voor wachtrijen ophalen naar de secundaire naamruimte van buiten het virtuele netwerk en controleert u of u een foutbericht van de service ontvangt.

Bestaande koppeling

Als koppelen tussen primaire en secundaire naamruimte al bestaat, mislukt het maken van privé-eindpunten in de primaire naamruimte. Als u dit wilt oplossen, maakt u eerst een privé-eindpunt op de secundaire naamruimte en maakt u er vervolgens een voor de primaire naamruimte.

Notitie

Hoewel alleen-lezentoegang tot de secundaire naamruimte is toegestaan, zijn updates voor de configuraties van het privé-eindpunt toegestaan.

Aanbevolen configuratie

Wanneer u een configuratie voor herstel na noodgevallen voor uw toepassing en Service Bus maakt, moet u privé-eindpunten maken voor zowel primaire als secundaire Service Bus-naamruimten voor virtuele netwerken die als host fungeren voor zowel primaire als secundaire exemplaren van uw toepassing.

Stel dat u twee virtuele netwerken hebt: VNET-1, VNET-2 en deze primaire en secundaire naamruimten: ServiceBus-Namespace1-Primary, ServiceBus-Namespace2-Secondary. U moet de volgende stappen uitvoeren:

• ServiceBus-Namespace1-PrimaryMaak aan twee privé-eindpunten die gebruikmaken van subnetten van VNET-1 en VNET-2
• ServiceBus-Namespace2-SecondaryMaak aan twee privé-eindpunten die gebruikmaken van dezelfde subnetten van VNET-1 en VNET-2

Het voordeel van deze aanpak is dat failover kan plaatsvinden op de toepassingslaag onafhankelijk van de Service Bus-naamruimte. Bekijk de volgende scenario's:

Failover voor alleen toepassingen: hier bestaat de toepassing niet in VNET-1, maar wordt verplaatst naar VNET-2. Omdat beide privé-eindpunten zijn geconfigureerd op zowel VNET-1 als VNET-2 voor zowel primaire als secundaire naamruimten, werkt de toepassing gewoon.

Failover van service Bus-naamruimte: hier werkt de toepassing alleen, omdat beide privé-eindpunten zijn geconfigureerd op beide virtuele netwerken voor zowel primaire als secundaire naamruimten.

Notitie

Zie Virtual Network - Bedrijfscontinuïteit voor hulp bij geo-noodherstel van een virtueel netwerk.

Op rollen gebaseerd toegangsbeheer

RBAC-toewijzingen (Op rollen gebaseerd toegangsbeheer) van Microsoft Entra voor Service Bus-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.

Volgende stappen

• Raadpleeg hier de REST API-verwijzing voor geo-noodherstel.
• Voer het voorbeeld van geo-noodherstel uit op GitHub.
• Zie het voorbeeld van geo-noodherstel waarmee berichten naar een alias worden verzonden.

Zie de volgende artikelen voor meer informatie over Service Bus-berichten:

• Service Bus-wachtrijen, -onderwerpen en -abonnementen
• Aan de slag met Service Bus-wachtrijen
• Service Bus-onderwerpen en -abonnementen gebruiken
• REST API