Azure Event Hubs- Herstel na geo-nood

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

Azure Event Hubs verspreidt al het risico op onherstelbare storingen van afzonderlijke machines of zelfs volledige rekken over clusters die meerdere foutdomeinen in een datacenter omvatten. Er worden transparante foutdetectie- en failovermechanismen geïmplementeerd, zodat de service blijft werken binnen de gegarandeerde serviceniveaus en doorgaans zonder merkbare onderbrekingen in het geval van dergelijke fouten. Als een Event Hubs-naamruimte is gemaakt met de ingeschakelde optie voor 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, onherstelbare verlies van de hele faciliteit.

Het volledig actieve Azure Event Hubs met ondersteuning voor beschikbaarheidszone biedt tolerantie tegen ernstige hardwarestoringen en zelfs onherstelbaar verlies van volledige datacenterfaciliteiten. Toch kunnen er ernstige situaties zijn met wijdverbreide fysieke vernietigende maatregelen die zelfs met deze maatregelen niet voldoende kunnen worden beschermd.

De functie Event Hubs Geo-herstel na noodgevallen is ontworpen om het gemakkelijker te maken om te herstellen van een noodgevallen van deze omvang en om een mislukte Azure-regio te verlaten voor een goede en zonder dat u de configuraties van uw toepassing moet 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 moment een eensgevolgde failover kunt initiëren van de primaire naar de secundaire. De failover verplaatst de gekozen aliasnaam voor de naamruimte opnieuw naar de secundaire naamruimte en verbreekt vervolgens de koppeling. De failover wordt vrijwel onmiddellijk gestart.

Uitval en noodscenario's

Het is belangrijk om te weten wat het verschil is tussen 'uitval' en 'noodscenario's'. Een storing is de tijdelijke onbeschikbaarheid van Azure Event Hubs en kan van invloed zijn op bepaalde onderdelen van de service, zoals een berichtenopslag of zelfs het hele datacenter. Nadat het probleem is opgelost, Event Hubs weer beschikbaar. Normaal gesproken veroorzaakt een storing niet het verlies van berichten of andere gegevens. Een voorbeeld van een dergelijke storing kan een stroomstoring in het datacenter zijn. Sommige uitval is slechts een korte verbindingsverlies vanwege tijdelijke problemen of netwerkproblemen.

Een noodlot wordt gedefinieerd als het permanente of langere verlies van een Event Hubs cluster, Azure-regio of datacenter. De regio of het datacenter wordt mogelijk wel of niet weer beschikbaar, of is mogelijk uren of dagen niet beschikbaar. Voorbeelden van dergelijke rampen zijn brand, overstromingen of aardbevingen. Een noodlot dat permanent wordt, kan leiden tot het verlies van bepaalde berichten, gebeurtenissen of andere gegevens. In de meeste gevallen mag er echter geen gegevens verloren gaan en kunnen berichten worden hersteld zodra er een back-up van het datacenter is.

De functie geo-noodherstel van Azure Event Hubs is een noodhersteloplossing. De concepten en werkstroom die in dit artikel worden beschreven, zijn van toepassing op noodscenario's en niet op tijdelijke of tijdelijke uitval. Zie dit artikel voor een gedetailleerde Microsoft Azure over herstel na noodherstel.

Basisconcepten en -termen

De functie voor herstel na noodherstel implementeert metagegevens voor noodherstel en is afhankelijk van primaire en secundaire naamruimten voor herstel na noodherstel.

De functie Geo-herstel na noodherstel is alleen beschikbaar voor de Standard-, Premium- en Dedicated-SKU's. U hoeft geen wijzigingen aan te connection string, 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 noodherstel die u hebt ingesteld. De alias biedt één stabiele FQDN-naam (Fully Qualified Domain Name) connection string. Toepassingen gebruiken deze alias connection string 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 naadloos berichten kunnen accepteren zonder toepassingscode of connection string wijzigingen. Om ervoor te zorgen dat alleen de actieve naamruimte berichten ontvangt, moet u de alias gebruiken.

• Metagegevens: entiteiten zoals Event Hubs en consumentengroepen; en de eigenschappen van de service die aan de naamruimte zijn gekoppeld. 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:

Installatie- en failoverstroom

In de volgende sectie wordt een overzicht gegeven van het failoverproces en wordt uitgelegd hoe u de eerste failover in kunt stellen.

Instellen

Eerst maakt of gebruikt u een bestaande primaire naamruimte en een nieuwe secundaire naamruimte en vervolgens koppelt u de twee. Deze koppeling biedt u een alias die u kunt gebruiken om verbinding te maken. Omdat u een alias gebruikt, hoeft u de verbindingsreeksen niet te wijzigen. Alleen nieuwe naamruimten kunnen worden toegevoegd aan uw failover-koppeling.

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 menu links en selecteer Koppelen initiëren op de werkbalk.

   

5. Volg deze stappen op de pagina Koppelen initiëren:

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

   

6. De pagina Geo-DR Alias wordt weergegeven. U kunt ook naar deze pagina navigeren vanuit de primaire naamruimte door Geo-herstel te selecteren in het menu links.

   

7. Selecteer op de pagina Geo-DR Alias de optie Beleid voor gedeelde toegang in het menu links voor toegang 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 pagina Overzicht kunt u de volgende acties uitvoeren:

   1. Verbreed de koppeling tussen primaire en secundaire naamruimten. Selecteer Koppeling met onderbrekingen op de werkbalk.

   2. Handmatige failover naar de secundaire naamruimte. Selecteer Failover op de werkbalk.

      Waarschuwing

      Als u een andere fout maakt, wordt de secundaire naamruimte geactiveerd en wordt de primaire naamruimte verwijderd uit Geo-Disaster Recovery-koppeling. Maak een andere naamruimte om een nieuw geo-noodherstelpaar te hebben.

Ten slotte moet u 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 om berichten of gebeurtenissen te verzenden. Event Hubs gebeurtenissen worden doorgestuurd naar een oplossing voor toewijzing of herformattering, 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 wanneer en welk onderdeel van de fail over moet worden genomen, 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 twee stappen vereist:

1. Als er een andere storing optreedt, wilt u een fail over kunnen doen. 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 reguliere berichten buiten de installatie van geo-herstel of verwijdert u de oude primaire naamruimte.

Beheer

Als u 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 moment breken. Als u de gekoppelde naamruimten als reguliere naamruimten wilt gebruiken, verwijdert u de alias.

Overwegingen

Houd rekening met de volgende overwegingen om rekening mee te houden:

1. Met geo-noodherstel Event Hubs geen gegevens gerepliceerd. Daarom kunt u de oude offsetwaarde van uw primaire Event Hub niet opnieuw gebruiken op uw secundaire Event Hub. U wordt aangeraden de 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 tijdstip van de verbinding met uw secundaire Event Hub.
   • EventPosition.FromEnqueuedTime(dateTime) : als u alle gegevens wilt lezen die in uw secundaire Event Hub zijn ontvangen vanaf een bepaalde datum en tijd.

2. In uw failover-planning moet u ook rekening houden met de tijdsfactor. Als u bijvoorbeeld de verbinding 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 detectie van duplicaten en geplande berichten mogelijk niet. Nieuwe sessies, geplande berichten en nieuwe duplicaten werken.

4. Als u een complexe gedistribueerde infrastructuur niet goed doorstaat, moet deze ten minste één keer worden geseed.

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

Beschikbaarheidszones

Event Hubs ondersteunt Beschikbaarheidszonesen biedt niet-geïsoleerde locaties binnen een Azure-regio. De Beschikbaarheidszones 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.

Privé-eindpunten

Deze sectie bevat meer overwegingen bij het gebruik van herstel na geo-nood met naamruimten die gebruikmaken van privé-eindpunten. Zie Privé-eindpunten configureren voor meer Event Hubs het gebruik van privé-eindpunten met Event Hubs in het algemeen.

Nieuwe koppelen

Als u een koppeling probeert te maken tussen een primaire naamruimte met een privé-eindpunt en een secundaire naamruimte zonder een privé-eindpunt, mislukt het koppelen. Het koppelen slaagt alleen als zowel primaire als secundaire naamruimten privé-eindpunten hebben. U wordt aangeraden dezelfde configuraties te gebruiken in de primaire en secundaire naamruimten en in virtuele netwerken waarin privé-eindpunten worden gemaakt.

Bestaande koppelen

Als er al een koppeling tussen de primaire en secundaire naamruimte bestaat, mislukt het maken van een privé-eindpunt op 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.

Aanbevolen configuratie

Wanneer u een configuratie voor herstel na noodherstel 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 dienen 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 volgen:

• 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

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

Failover alleen voor toepassingen: 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.

Event Hubs alleen-naamruimte failover: hier opnieuw, omdat beide privé-eindpunten zijn geconfigureerd op beide virtuele netwerken voor zowel primaire als secundaire naamruimten, werkt de toepassing gewoon.

Op rollen gebaseerd toegangsbeheer

Azure Active Directory (Azure AD) op rollen gebaseerd toegangsbeheer (RBAC) aan entiteiten in de primaire naamruimte worden niet gerepliceerd naar de secundaire naamruimte. Maak handmatig roltoewijzingen in de secundaire naamruimte om de toegang tot de toewijzingen te beveiligen.

Volgende stappen

Bekijk de volgende voorbeelden of referentiedocumentatie.

• .NET GeoDR-voorbeeld
• Java GeoDR-voorbeeld
• .NET- Voorbeelden van Azure.Messaging.EventHubs
• .NET- Voorbeelden van Microsoft.Azure.EventHubs
• Java - voorbeelden van azure-messaging-eventhubs
• Java - azure-eventhubs-voorbeelden
• Python-voorbeelden
• JavaScript-voorbeelden
• TypeScript-voorbeelden
• Naslaginformatie over REST API