Azure Event Hubs - Herstel na geo-noodgeval

  • Artikel

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

Azure Event Hubs verspreidt al het risico op catastrofale fouten van afzonderlijke machines of zelfs volledige racks over clusters die meerdere foutdomeinen binnen een datacenter omvatten. Het implementeert transparante foutdetectie- en failovermechanismen, zodat de service blijft werken binnen de gegarandeerde serviceniveaus en meestal 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 storingen verder en schakelt u een hoge beschikbaarheid in. Met beschikbaarheidszones wordt het storingsrisico verder verspreid over drie fysiek gescheiden faciliteiten en heeft de service voldoende capaciteitsreserves om direct het volledige, catastrofale verlies van de hele faciliteit op te vangen.

Het volledig actieve Azure Event Hubs-clustermodel met ondersteuning voor beschikbaarheidszones biedt tolerantie tegen ernstige hardwarefouten en zelfs catastrofaal verlies van volledige datacenterfaciliteiten. Toch kunnen er ernstige situaties zijn met wijdverbreide fysieke vernietiging waartegen zelfs deze maatregelen zich niet voldoende kunnen verdedigen.

De functie geo-noodherstel van Event Hubs is ontworpen om het gemakkelijker te maken om te herstellen van een dergelijke ramp en een mislukte Azure-regio voorgoed te verlaten zonder dat u de 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 samengestelde toepassingsconfiguratie te behouden.

De Geo-Disaster herstelfunctie 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 dat u op elk gewenst moment een eenmalige failover van de primaire naar de secundaire kunt initiëren. De failoververplaatsing verwijst de gekozen aliasnaam voor de naamruimte opnieuw naar de secundaire naamruimte en breekt vervolgens de koppeling. De failover vindt vrijwel onmiddellijk plaats zodra deze is gestart.

Belangrijk

  • De functie maakt onmiddellijke continuïteit van bewerkingen met dezelfde configuratie mogelijk, maar repliceert de gebeurtenisgegevens niet. Tenzij het noodgeval het verlies van alle zones heeft veroorzaakt, kunnen de gebeurtenisgegevens die na de failover in de primaire Event Hub worden bewaard, worden hersteld en kunnen de historische gebeurtenissen van daar worden verkregen zodra de toegang is hersteld. Voor het repliceren van gebeurtenisgegevens en het uitvoeren van bijbehorende naamruimten in actieve/actieve configuraties om uitval en noodgevallen het hoofd te bieden, moet u niet leunen op deze functieset voor geo-noodherstel, maar de replicatierichtlijnen volgen.
  • RBAC-toewijzingen (Op rollen gebaseerd toegangsbeheer) van Azure Active Directory (Azure AD) aan entiteiten in de primaire naamruimte worden niet gerepliceerd naar de secundaire naamruimte. Maak roltoewijzingen handmatig in de secundaire naamruimte om de toegang tot deze te beveiligen.

Storingen en rampen

Het is belangrijk om het onderscheid te noteren tussen 'storingen' en 'rampen'. Een storing is de tijdelijke niet-beschikbaarheid 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, worden Event Hubs echter weer beschikbaar. Normaal gesproken veroorzaakt een storing geen verlies van berichten of andere gegevens. Een voorbeeld van een dergelijke storing is een stroomstoring in het datacenter. Sommige storingen zijn slechts korte verbindingsverliezen vanwege tijdelijke of netwerkproblemen.

Een noodgeval wordt gedefinieerd als het permanente of langdurige verlies van een Event Hubs-cluster, Azure-regio of datacenter. De regio of het datacentrum kan al dan niet weer beschikbaar zijn, of kan uren of dagen niet beschikbaar zijn. Voorbeelden van dergelijke rampen zijn brand, overstromingen of aardbevingen. Een noodgeval dat permanent wordt, kan leiden tot het verlies van sommige berichten, gebeurtenissen of andere gegevens. 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 herstel na geo-noodgeval 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 noodgevalscenario's en niet op tijdelijke storingen 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 herstel na geo-noodgeval is alleen beschikbaar voor de Standard-, Premium- en toegewezen SKU's . U hoeft geen connection string 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-connection string (Fully Qualified Domain Name). Toepassingen gebruiken deze alias connection string 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 (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 naadloos berichten kunnen accepteren zonder toepassingscode of connection string 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 van het activeren van de secundaire naamruimte.

Ondersteunde naamruimteparen

De volgende combinaties van primaire en secundaire naamruimten worden ondersteund:

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

Notitie

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

Installatie- en failoverstroom

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

Afbeelding met het overzicht van het failoverproces

Instellen

U maakt of gebruikt eerst een bestaande primaire naamruimte en een nieuwe secundaire naamruimte en koppelt vervolgens de twee. Door deze koppeling krijgt u een alias die u kunt gebruiken om verbinding te maken. Omdat u een alias gebruikt, hoeft u geen verbindingsreeksen 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 de Azure Portal naar uw primaire naamruimte.

  4. Selecteer Geo-herstel in het linkermenu en selecteer Koppelen starten op de werkbalk.

    Koppelen starten vanuit de primaire naamruimte

  5. Voer op de pagina Koppeling starten de volgende stappen uit:

    1. Selecteer een bestaande secundaire naamruimte of maak er een in een andere regio. In dit voorbeeld is een bestaande naamruimte geselecteerd.
    2. Voer bij Alias een alias in voor de geo-dr-koppeling.
    3. Ten slotte selecteert u Create.

    Selecteer de secundaire naamruimte

  6. U ziet nu de pagina Geo-DR Alias . U kunt ook naar deze pagina navigeren vanuit de primaire naamruimte door Geo-herstel te selecteren in het menu aan de linkerkant.

    Aliaspagina voor geo-herstel na noodgeval

  7. Selecteer op de pagina Alias voor herstel na noodgeval de optie Beleid voor gedeelde toegang in het menu links om toegang te krijgen tot de primaire connection string voor de alias. Gebruik deze connection string in plaats van de connection string 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. Handmatig een failover uitvoeren 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 voor een nieuw paar voor herstel na geo-noodgeval.

Ten slotte moet u wat 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 synchroon moeten worden uitgevoerd met het resterende subsysteem of de resterende infrastructuur.

Voorbeeld

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

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

Failoverstroom

Als u de failover start, zijn twee stappen vereist:

  1. Als er nog een storing optreedt, wilt u opnieuw een failover 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. Gebruik daarna die naamruimte voor reguliere berichten buiten uw geo-herstelconfiguratie of verwijder de oude primaire naamruimte.

Notitie

Alleen semantiek van fail forward wordt ondersteund. In dit scenario gaat u een failover uitvoeren en vervolgens opnieuw koppelen met 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 de Azure Portal naar uw primaire naamruimte.

  2. Selecteer Geo-herstel in het linkermenu.

  3. Handmatig een failover uitvoeren 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 voor een nieuw paar voor herstel na geo-noodgeval.

Beheer

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

Overwegingen

Houd rekening met de volgende overwegingen:

  1. Bij geo-noodherstel van Event Hubs worden gegevens standaard niet gerepliceerd. Daarom kunt u de oude offsetwaarde van uw primaire Event Hub niet opnieuw gebruiken op uw secundaire Event Hub. We raden u aan uw gebeurtenisontvanger 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(dateTime): 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 de verbinding bijvoorbeeld langer dan 15 tot 20 minuten verliest, kunt u besluiten om de failover te starten.

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

  4. Failover-overschakeling 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 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 in te schakelen.

Beschikbaarheidszones

Event Hubs ondersteunt Beschikbaarheidszones en biedt op fouten 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 tussen datacenters in de beschikbaarheidszone.

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

Afbeelding van de pagina Naamruimte maken met regio met beschikbaarheidszones

Notitie

Wanneer u de 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 met -ZoneRedundant=false om een naamruimte te maken waarvoor zoneredundantie is uitgeschakeld.

Privé-eindpunten

In deze sectie vindt u meer overwegingen bij het gebruik van herstel na geo-noodgeval 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 een koppeling probeert te maken tussen een primaire naamruimte met een privé-eindpunt en een secundaire naamruimte zonder privé-eindpunt, mislukt de koppeling. De koppeling slaagt alleen als zowel de primaire als de secundaire naamruimte privé-eindpunten hebben. U wordt aangeraden dezelfde configuraties te gebruiken voor de primaire en secundaire naamruimten en voor virtuele netwerken waarin privé-eindpunten worden gemaakt.

Notitie

Wanneer u de primaire naamruimte probeert te koppelen aan een privé-eindpunt en een secundaire naamruimte, wordt tijdens het validatieproces alleen gecontroleerd 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 koppelingen

Als de koppeling tussen de primaire en secundaire naamruimte al bestaat, mislukt het maken van een privé-eindpunt in de primaire naamruimte. U kunt dit oplossen door eerst een privé-eindpunt te maken in de secundaire naamruimte en vervolgens een eindpunt te maken voor de primaire naamruimte.

Notitie

Hoewel we alleen-lezentoegang tot de secundaire naamruimte toestaan, 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 zowel primaire als secundaire exemplaren van uw toepassing hosten.

Stel dat u twee virtuele netwerken hebt: VNET-1, VNET-2 en deze primaire en secundaire naamruimten: EventHubs-Naamruimte1-Primair, EventHubs-Naamruimte2-Secundair. 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 in EventHubs-Namespace2-Secondary twee privé-eindpunten die gebruikmaken van dezelfde subnetten van VNET-1 en VNET-2

Privé-eindpunten en virtuele netwerken

Het voordeel van deze benadering is dat er een failover kan plaatsvinden in de toepassingslaag, onafhankelijk van de Event Hubs-naamruimte. Denk eens na over de volgende scenario's:

Failover alleen voor toepassing: Hier bestaat de toepassing niet in VNET-1, maar wordt deze 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 alleen voor Event Hubs-naamruimten: hier geldt opnieuw dat, aangezien beide privé-eindpunten zijn geconfigureerd op beide virtuele netwerken voor zowel primaire als secundaire naamruimten, de toepassing gewoon werkt.

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 Azure Active Directory (Azure AD) aan entiteiten in de primaire naamruimte worden niet gerepliceerd naar de secundaire naamruimte. Maak roltoewijzingen handmatig in de secundaire naamruimte om de toegang tot deze te beveiligen.

Volgende stappen

Bekijk de volgende voorbeelden of referentiedocumentatie.