Azure Event Hubs geo-noodherstel

Geo-noodherstel is een functie voor herstel na noodgevallen in Azure Event Hubs die uw naamruimteconfiguratie (event hubs, consumentengroepen en instellingen) continu repliceert van een primaire naamruimte naar een secundaire naamruimte. Met deze functie kunt u een failover van de primaire naar de secundaire naamruimte initiëren tijdens regionale storingen.

Notitie

In dit artikel wordt de functie geo-noodherstel beschreven die alleen metagegevens repliceert. Zie Geo-replicatie voor informatie over de functie voor geo-replicatie, waarmee zowel gegevens als metagegevens worden gerepliceerd.

Het all-actieve Azure Event Hubs-clustermodel met ondersteuning voor beschikbaarheidszones biedt tolerantie tegen hardware- en datacenterstoringen. Als er echter een noodgeval optreedt waarbij een hele regio en alle zones niet beschikbaar zijn, kunt u geo-noodherstel gebruiken om uw workload en toepassingsconfiguratie te herstellen.

De concepten en werkstroom die in dit artikel worden beschreven, zijn van toepassing op noodscenario's, niet op tijdelijke storingen. Zie Disaster Recovery voor Azure toepassingen voor een gedetailleerde bespreking van herstel na noodgevallen in Microsoft Azure. Met herstel na noodgevallen kunt u op elk gewenst moment een eenmalige failover van de primaire naar de secundaire failover initiëren. De failover verplaatst de gekozen aliasnaam voor de naamruimte naar de secundaire naamruimte. Na de verplaatsing wordt de koppeling verwijderd. De failover is bijna onmiddellijk nadat deze is geïnitieerd.

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 bewaard blijven in de primaire Event Hub nadat de failover is hersteld, 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.

Zie Geo-noodherstel configureren om geo-noodherstelkoppeling in te stellen en het initiëren van een failover.

Basisbegrippen en termen

De functie voor herstel na noodgevallen implementeert herstel na noodgevallen voor metagegevens en is afhankelijk van primaire en secundaire naamruimten voor herstel na noodgevallen. De functie voor geografisch herstel bij rampen is alleen beschikbaar voor de standaard-, premium- en toegewijde 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 Standaard, Toegewijd
Premium Premium
Toegewijd Toegewijd

Belangrijk

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

Failoveroverwegingen

Houd rekening met de volgende punten bij het plannen van een failover:

  • Event Hubs geo-noodherstel repliceert standaard geen gegevens. Daarom kunt u de oude offsetwaarde van uw primaire Event Hub niet opnieuw gebruiken op uw secundaire Event Hub. Start de ontvanger van de gebeurtenis opnieuw op met behulp van een van de volgende methoden:

    • EventPosition.FromStart() - Als u alle gegevens in 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.
  • Houd rekening met de tijdsfactor in uw failoverplanning. Als u bijvoorbeeld langer dan 15 tot 20 minuten geen verbinding meer hebt, kunt u besluiten om de failover te starten.

  • Omdat er geen gegevens worden gerepliceerd, worden huidige actieve sessies niet gerepliceerd. Bovendien werken dubbele detectie en geplande berichten mogelijk niet. Nieuwe sessies, geplande berichten en nieuwe duplicaatfunctie.

  • U moet ten minste één keer een failover uitvoeren voor een complexe gedistribueerde infrastructuur.

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

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

  • Het gegevensvlak van de secundaire naamruimte heeft het kenmerk Alleen-lezen terwijl geo-herstelkoppeling actief is. Het gegevensvlak van de secundaire naamruimte accepteert GET-aanvragen om validatie van clientconnectiviteit en toegangsbeheer mogelijk te maken.

Privé-eindpunten

Deze sectie bevat 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. Gebruik dezelfde configuraties voor de primaire en secundaire naamruimten en op virtuele netwerken waar u privé-eindpunten maakt.

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 zal werken 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 op primaire en secundaire naamruimten, verzendt u een leesaanvraag (bijvoorbeeld: Get Event Hub) naar de secundaire naamruimte van buiten het virtuele netwerk en controleert u of u een foutbericht van de service ontvangt.

Bestaande koppeling

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

Notitie

Hoewel u toegang hebt tot de secundaire naamruimte als alleen-lezen, kunt u de configuraties van het privé-eindpunt bijwerken.

Wanneer u een configuratie voor herstel na noodgevallen voor uw toepassing en Event Hubs-naamruimten maakt, maakt u privé-eindpunten voor zowel primaire als secundaire Event Hubs-naamruimten. Deze privé-eindpunten maken verbinding met virtuele netwerken die zowel primaire als secundaire exemplaren van uw toepassing hosten.

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

  • Maak op EventHubs-Namespace1-Primary twee privé-eindpunten aan die gebruikmaken van subnetten van VNET-1 en VNET-2
  • EventHubs-Namespace2-SecondaryMaak twee privé-eindpunten aan 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 Event Hubs-naamruimte. Bekijk de volgende scenario's:

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

Failover met alleen Event Hubs-naamruimten: In dit scenario werkt de toepassing meteen omdat beide privé-eindpunten op beide virtuele netwerken zijn geconfigureerd 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)

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.