Azure Event Hubs - Herstel na geo-noodgeval

  • Artikel

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

Azure Event Hubs verspreidt al het risico op onherstelbare fouten van afzonderlijke machines of zelfs complete racks in clusters die meerdere foutdomeinen binnen een datacenter omvatten. Het implementeert transparante foutdetectie en failovermechanismen, zodat de service blijft werken binnen de verzekerde serviceniveaus en doorgaans zonder merkbare onderbrekingen in het geval van dergelijke fouten. Als u een Event Hubs-naamruimte maakt waarvoor beschikbaarheidszones zijn ingeschakeld, vermindert u het risico op uitval verder en schakelt u hoge beschikbaarheid in. Met beschikbaarheidszones wordt het storingsrisico verder verdeeld over drie fysiek gescheiden faciliteiten en heeft de service voldoende capaciteitsreserves om direct te kunnen omgaan met het volledige, catastrofale verlies van de hele faciliteit.

Het all-actieve Azure Event Hubs-clustermodel met ondersteuning voor beschikbaarheidszones biedt 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 Event Hubs Geo-noodherstelfunctie 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 verlaten van een Azure-regio omvat doorgaans verschillende services en deze functie is voornamelijk bedoeld om de integriteit van de configuratie van de samengestelde toepassing te behouden.

De functie voor herstel na 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, en u kunt een eenmalige failover op elk gewenst moment van de primaire naar de secundaire initiëren. Tijdens de failoververplaatsing 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.

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.

Storingen en rampen

Het is belangrijk om het onderscheid tussen 'storingen' en 'rampen' op te merken. Een storing is de tijdelijke onbeschikbaarheid van Azure Event Hubs 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 Event Hubs 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.

Er wordt een noodgeval gedefinieerd als permanent of langdurig verlies van een Event Hubs-cluster, Azure-regio of datacenter. De regio of het datacenter is mogelijk al dan niet weer beschikbaar of is mogelijk 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 een back-up heeft.

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 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 voor geo-noodherstel is alleen beschikbaar voor de standard-, premium- en toegewezen SKU's . 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 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

Notitie

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.

Image showing the overview of failover process

Instellen

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.

    Initiate pairing from the primary namespace

  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.

    Select the secondary namespace

  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.

    Geo-DR alias page

  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.

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

voorbeeld

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.

Image showing the failover flow

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.

Beschikbaarheidszones

Event Hubs ondersteunt Beschikbaarheidszones en biedt fout-geïsoleerde locaties binnen een Azure-regio. De Beschikbaarheidszones-ondersteuning is alleen beschikbaar in Azure-regio's met beschikbaarheidszones. Zowel metagegevens als gegevens (gebeurtenissen) worden gerepliceerd in datacenters in de beschikbaarheidszone.

Wanneer u een naamruimte maakt, ziet u het volgende gemarkeerde bericht wanneer u een regio met beschikbaarheidszones selecteert.

Image showing the Create Namespace page with region that has availability zones

Notitie

Wanneer u Azure Portal gebruikt, wordt zoneredundantie via ondersteuning voor beschikbaarheidszones automatisch ingeschakeld. U kunt deze niet uitschakelen in de portal. U kunt de Azure CLI-opdracht az eventhubs namespace gebruiken met --zone-redundant=false of de PowerShell-opdracht New-AzEventHubNamespace gebruiken om -ZoneRedundant=false een naamruimte te maken waarvoor zoneredundantie is uitgeschakeld.

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-1, VNET-2 en deze primaire en secundaire naamruimten: EventHubs-Namespace1-Primary, EventHubs-Namespace2-Secondary. U moet de volgende stappen uitvoeren:

  • Maak op EventHubs-Namespace1-Primary twee privé-eindpunten die gebruikmaken van subnetten van VNET-1 en VNET-2
  • Maak op EventHubs-Namespace2-Secondary twee privé-eindpunten die gebruikmaken van dezelfde subnetten van VNET-1 en VNET-2

Private endpoints and virtual networks

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 voor alleen toepassingen: de toepassing bestaat hier 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 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.

Volgende stappen

Raadpleeg de volgende voorbeelden of referentiedocumentatie.