Delen via

Azure Service Bus Geo-Disaster Recovery

  • Artikel

De Service Bus Geo-Disaster Recovery-functie is een van de opties voor het isoleren van Azure Service Bus-toepassingen tegen storingen en noodgevallen, en is voornamelijk bedoeld om de integriteit van de samengestelde toepassingsconfiguratie te behouden.

Notitie

Deze functie is beschikbaar voor de Premium-laag van Azure Service Bus.

De functie Herstel na noodgeval zorgt ervoor dat de volledige configuratie van een naamruimte (entiteiten, configuratie, eigenschappen) continu wordt gerepliceerd van een primaire naamruimte naar een secundaire naamruimte waarmee deze is gekoppeld, en u kunt op elk gewenst moment een eenmalige failover van de primaire naar de secundaire instantie initiëren. De failover verplaatst de gekozen aliasnaam voor de naamruimte opnieuw naar de secundaire naamruimte en breekt vervolgens de koppeling af. 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. Als u de semantiek van de wachtrij wilt behouden, vereist een dergelijke replicatie niet alleen de replicatie van berichtgegevens, maar van elke statuswijziging in de broker, die wordt aangeboden in de functie Geo-replicatie (openbare preview).
  • 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
    • Azure Event Grid-abonnementen
  • 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 wordt, is de laatste toegangsstatus, die geen deel uitmaakt van de metagegevens, niet beschikbaar voor de nieuwe primaire en entiteit als onderdeel van AutoDeleteOnIdle het 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, mag u niet leunen op deze geo-noodherstelfunctie, maar gebruik de functie Geo-replicatie of volg de replicatierichtlijnen.

Basisconcepten en termen

De functie Geo-Disaster Recovery implementeert herstel na noodgevallen van metagegevens en is afhankelijk van primaire en secundaire naamruimten voor herstel na noodgevallen. De functie Geo-Disaster Recovery is alleen beschikbaar voor de Premium-laag . 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.

Schermopname van het instellen van koppelen met Geo-Disaster Recovery.

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 Geoherstel in het linkermenu en selecteer Koppelen initiëren op de werkbalk.

    Schermopname van de pagina Geo-herstel met koppeling initiëren geselecteerd.

  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 koppeling Geo-Disaster Recovery.

    3. Ten slotte selecteert u Maken.

      Schermopname van de pagina Koppelen initiëren in Azure Portal.

  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.

    Schermopname van de pagina Service Bus Geo-DR Alias met primaire en secundaire naamruimten.

  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 replicaties voor geo-noodherstel in behandeling zijn voordat u overschakelt naar de secundaire. U kunt ook geforceerde of handmatige failover niet wachten tot 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.

        Schermopname van de pagina 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.

Afbeelding van de stroom van failover van primaire naar secundaire naamruimte.

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 secundaire 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 de installatie van geo-noodherstel 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.

Afbeelding die laat zien hoe u failover kunt automatiseren.

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, voor het instellen en inschakelen van geo-herstel na noodgevallen.
  • 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.

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.

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

Privé-eindpunten en virtuele netwerken

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

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