Delen via

Azure Event Hubs - Herstel na geo-noodgeval

  • Artikel

In dit artikel wordt de functie geo-noodherstel beschreven waarmee metagegevens worden gerepliceerd en algemeen beschikbaar is. Het beschrijft niet de openbare previewfunctie voor geo-replicatie, waarmee zowel gegevens als metagegevens worden gerepliceerd. Zie Geo-replicatie voor meer informatie.

Het all-actieve Azure Event Hubs-clustermodel met ondersteuning voor beschikbaarheidszones biedt tolerantie tegen hardware- en datacenterstoringen. Als er echter een noodgeval is waarbij een hele regio en alle zones niet beschikbaar zijn, kunt u geo-noodherstel gebruiken om uw workload en toepassingsconfiguratie te herstellen. Herstel na geo-noodgeval zorgt ervoor dat de volledige configuratie van een naamruimte (Event Hubs, Consumentengroepen en instellingen) continu wordt gerepliceerd van een primaire naamruimte naar een secundaire naamruimte wanneer deze is gekoppeld.

De functie voor geo-noodherstel van Azure Event Hubs 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 storingen. Zie dit artikel voor een gedetailleerde bespreking van herstel na noodgevallen in Microsoft Azure. Met herstel na noodgevallen kunt u op elk gewenst moment een eenmalige failover starten van de primaire naar de secundaire. De failover verplaatst de gekozen aliasnaam voor de naamruimte naar de secundaire naamruimte. Na de verplaatsing wordt de koppeling vervolgens verwijderd. De failover is bijna onmiddellijk nadat deze is gestart.

Belangrijk

  • De functie maakt onmiddellijke continuïteit van bewerkingen mogelijk met dezelfde configuratie, maar repliceert de gebeurtenisgegevens niet. Tenzij het noodgeval het verlies van alle zones heeft veroorzaakt, kunnen de gebeurtenisgegevens die na een failover in de primaire Event Hub worden bewaard, worden hersteld en kunnen de historische gebeurtenissen vanaf daar worden verkregen zodra de toegang is hersteld. Voor het repliceren van gebeurtenisgegevens en het uitvoeren van bijbehorende naamruimten in actieve/actieve configuraties om te kunnen omgaan met storingen en noodgevallen, hoeft u niet te leunen op deze functieset voor geo-noodherstel, maar volgt u de replicatierichtlijnen.
  • 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.

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 voor geo-noodherstel is alleen beschikbaar voor de standard-, premium- en toegewezen lagen . 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.
  • Primaire/secundaire naamruimte: de naamruimten die overeenkomen met de alias. De primaire naamruimte is actief en ontvangt berichten (kan een bestaande of een 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 Event Hubs en consumentengroepen en hun eigenschappen van de service die zijn gekoppeld aan de naamruimte. Alleen entiteiten en hun instellingen worden automatisch gerepliceerd. Berichten en gebeurtenissen worden niet gerepliceerd.
  • Failover: het proces voor het activeren van de secundaire naamruimte.

Ondersteunde naamruimteparen

De volgende combinaties van primaire en secundaire naamruimten worden ondersteund:

Primaire naamruimtelaag Toegestane secundaire naamruimtelaag
Standaard Standard, Dedicated
Premium Premium
Toegewezen Toegewezen

Belangrijk

U kunt geen naamruimten koppelen die zich in hetzelfde toegewezen cluster bevinden. U kunt naamruimten koppelen die zich in afzonderlijke clusters bevinden.

Installatie- en failoverstroom

In de volgende sectie vindt u een overzicht van het failoverproces en wordt uitgelegd hoe u de eerste failover instelt.

Schermopname van het overzicht van het failoverproces.

Notitie

De functie geo-noodherstel biedt geen ondersteuning voor een automatische failover.

Instellingen

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 naamruimte.

  2. Maak de secundaire 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.

    Schermopname van de pagina Geo-herstel voor een Event Hubs-naamruimte met de knop Koppelen 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 geselecteerd.
    2. Voer voor Alias een alias in voor de geo-dr-koppeling.
    3. Ten slotte selecteert u Maken.

    Schermopname van de selectie van de secundaire naamruimte voor koppelen.

  6. U ziet de pagina Geo-DR-alias . U kunt ook vanuit de primaire naamruimte naar deze pagina navigeren door Geo-herstel in het linkermenu te selecteren.

    Schermopname van de pagina Geo-DR-alias met zowel de primaire als de 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.

  8. Op deze overzichtspagina kunt u 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. Selecteer Failover op de werkbalk.

      Schermopname van de menu's Koppeling verbreken en failover op de pagina Event Hubs Geo-DR Alias.

      Waarschuwing

      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.

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 en zijn automatische failovers dus zelden mogelijk, omdat failovers vaak gesynchroniseerd moeten worden met het resterende subsysteem of de resterende infrastructuur.

Opmerking

In één voorbeeld van dit scenario kunt u een POS-oplossing (Point of Sale) overwegen die berichten of gebeurtenissen verzendt. Event Hubs geeft deze gebeurtenissen door aan een toewijzings- of hervormingsoplossing, die vervolgens toegewezen gegevens doorstuurt naar een ander systeem voor verdere verwerking. Op dat moment kunnen al deze systemen worden gehost in dezelfde Azure-regio. De beslissing over wanneer en welk deel een failover moet uitvoeren, is afhankelijk van de gegevensstroom in uw infrastructuur.

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.

Failoverstroom

Als u de failover start, zijn er twee stappen vereist:

  1. Als er een andere storing optreedt, wilt u een failover opnieuw kunnen uitvoeren. Stel daarom 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.

Afbeelding van de failoverstroom.

Handmatige failover

In deze sectie wordt beschreven hoe u handmatig een failover uitvoert met behulp van Azure Portal, CLI, PowerShell, C#, enzovoort.

  1. Navigeer in Azure Portal naar uw primaire naamruimte.

  2. Selecteer Geoherstel in het linkermenu.

  3. Voer handmatig een failover uit naar de secundaire naamruimte. Selecteer Failover op de werkbalk.

    Waarschuwing

    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.

Beheer

Als je een fout hebt gemaakt; U hebt bijvoorbeeld de verkeerde regio's gekoppeld tijdens de eerste installatie. U kunt 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.

Overwegingen

Let op de volgende overwegingen om rekening mee te houden:

  1. Event Hubs geo-noodherstel repliceert standaard geen gegevens en daarom kunt u de oude offsetwaarde van uw primaire Event Hub niet opnieuw gebruiken op uw secundaire Event Hub. Het is raadzaam de ontvanger van de gebeurtenis opnieuw op te starten met een van de volgende methoden:

    • EventPosition.FromStart() - Als u alle gegevens op uw secundaire Event Hub wilt lezen.
    • EventPosition.FromEnd() - Als u alle nieuwe gegevens wilt lezen vanaf het moment van verbinding met uw secundaire Event Hub.
    • EventPosition.FromEnqueuedTime(datum/tijd): als u alle gegevens wilt lezen die zijn ontvangen in uw secundaire Event Hub vanaf een bepaalde datum en tijd.

  2. 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.

  3. Het feit dat er geen gegevens worden gerepliceerd, betekent dat huidige actieve sessies niet worden gerepliceerd. Bovendien werken dubbele detectie en geplande berichten mogelijk niet. Nieuwe sessies, geplande berichten en nieuwe duplicaten werken.

  4. Een failover van een complexe gedistribueerde infrastructuur moet ten minste één keer worden uitgevoerd .

  5. Het synchroniseren van entiteiten kan enige tijd duren, ongeveer 50-100 entiteiten per minuut.

  6. Sommige aspecten van het beheervlak voor de secundaire naamruimte worden alleen-lezen terwijl geo-herstelkoppeling actief is.

  7. Het gegevensvlak van de secundaire naamruimte is alleen-lezen terwijl het koppelen van geo-herstel actief is. Het gegevensvlak van de secundaire naamruimte accepteert GET-aanvragen om validatie van clientconnectiviteit en toegangsbeheer mogelijk te maken.

Privé-eindpunten

In deze sectie vindt u meer overwegingen bij het gebruik van geo-noodherstel met naamruimten die gebruikmaken van privé-eindpunten. Zie Privé-eindpunten configureren voor meer informatie over het gebruik van privé-eindpunten met Event Hubs 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 een 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 in primaire en secundaire naamruimten, verzendt u een leesaanvraag (bijvoorbeeld: Event Hub 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 maakt voor uw toepassing en Event Hubs-naamruimten, moet u privé-eindpunten maken voor zowel primaire als secundaire Event Hubs-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-1en VNET-2 deze primaire en secundaire naamruimten: EventHubs-Namespace1-Primary, EventHubs-Namespace2-Secondary. U moet de volgende stappen uitvoeren:

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

Privé-eindpunten en virtuele netwerken

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

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

Failover van Event Hubs-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 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.

Gerelateerde inhoud

Raadpleeg de volgende voorbeelden of referentiedocumentatie.