Delen via

Betrouwbaarheid in Azure Event Hubs

Azure Event Hubs is een systeemeigen cloudservice die miljoenen gebeurtenissen per seconde kan streamen met lage latentie, van elke bron naar elke bestemming. Gebruik Event Hubs om streaminggegevens op te nemen en op te slaan en te integreren met clienttoepassingen die zijn gebouwd voor Apache Kafka of toepassingen die gebruikmaken van de Event Hubs-client-SDK's.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe Event Hubs bestand is tegen verschillende mogelijke storingen en problemen en hoe u deze kunt configureren om bestand te zijn tegen anderen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone en regio-storingen. Ook worden back-up- en herstelopties beschreven en worden enkele belangrijke stukjes informatie over de Service Level Agreement (SLA) van Azure Event Hubs belicht.

Aanbevelingen voor productie-implementatie

Zie Architectuurrichtlijnen voor Event Hubs in het Azure Well-Architected Framework om te leren hoe u Event Hubs kunt implementeren om te voldoen aan de betrouwbaarheidsvereisten van uw oplossing en inzicht te krijgen in hoe betrouwbaarheid invloed heeft op andere aspecten van uw architectuur.

Overzicht van betrouwbaarheidsarchitectuur

In deze sectie worden belangrijke aspecten beschreven van de werking van Event Hubs vanuit het perspectief van betrouwbaarheid. Het introduceert de logische architectuur, die resources en functies bevat die u implementeert en gebruikt. Ook wordt de fysieke architectuur uitgelegd, die details biedt over hoe de service bewerkingen intern beheert.

Logische architectuur

Een Event Hubs-naamruimte fungeert als de beheercontainer voor een of meer Event Hubs. U configureert de service, zoals het toewijzen van streamingcapaciteit, het configureren van netwerkbeveiliging en het inschakelen van geotolerantie en herstel na noodgevallen op naamruimteniveau.

Binnen een naamruimte kunt u gebeurtenissen organiseren in een Event Hub. Het Apache® Kafka-ecosysteem verwijst naar dit type entiteit als onderwerp. De Event Hub of het onderwerp is een gedistribueerd logboek met alleen toevoeggegevens van uw gebeurtenissen.

Elke Event Hub bevat een of meer partities, die logboeken van sequentiële gebeurtenissen zijn. Een Event Hub kan meerdere partities gebruiken om parallelle verwerking en horizontaal schalen uit te voeren. Event Hubs garandeert alleen bestellen binnen één partitie. Partitionering speelt een belangrijke rol in het betrouwbaarheidsontwerp van uw toepassing. Wanneer u uw toepassing ontwerpt, moet u een afweging maken tussen het maximaliseren van beschikbaarheid en consistentie. Om de uptime voor de meeste toepassingen te maximaliseren, vermijdt u het rechtstreeks adresseren van partities vanuit uw clienttoepassingen. Zie Beschikbaarheid en consistentie in Event Hubs voor meer informatie.

Consumenten die uit de Event Hub lezen, kunnen hun gebeurtenissen sequentieel lezen door hun eigen controlepunt te onderhouden, waarmee de laatste gebeurtenis wordt geïdentificeerd die ze ontvangen.

Zie Functies en terminologie in Event Hubs voor meer informatie over partities en andere fundamentele concepten in Event Hubs.

Fysieke architectuur

In de fysieke architectuur wordt een Event Hubs-naamruimte uitgevoerd binnen een cluster. Een cluster biedt de onderliggende reken- en opslagresources. De meeste naamruimten worden uitgevoerd op clusters die andere Azure-klanten delen. Wanneer u de Premium-laag gebruikt, krijgt de naamruimte toegewijde resources binnen een gedeeld cluster. Wanneer u de dedicated-laag gebruikt, is een cluster toegewezen aan uw naamruimten. Zie het overzicht van de Event Hubs Dedicated-laag voor meer informatie over toegewezen clusters. Ongeacht laag en clustertype beheert Microsoft de clusters en de onderliggende virtuele machines en opslag.

Om redundantie te bereiken, heeft elk cluster meerdere replica's die lees- en schrijfaanvragen verwerken. Voor optimalisatie van hoge beschikbaarheid en prestaties worden alle gegevens opgeslagen op drie opslagreplica's. Als u de rekenresources van uw naamruimte wilt schalen, implementeert u doorvoereenheden (RU's), verwerkingseenheden (RU's) of capaciteitseenheden (CA's), afhankelijk van de laag. Zie Schalen met Event Hubs voor meer informatie.

Clusters omvatten meerdere fysieke machines en racks, waardoor het risico op onherstelbare fouten die van invloed zijn op uw naamruimte, wordt verminderd. In regio's met beschikbaarheidszones breiden clusters zich uit over afzonderlijke fysieke datacenters. Zie Tolerantie voor fouten in beschikbaarheidszones voor meer informatie.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle in de cloud gehoste toepassingen moeten de richtlijnen voor tijdelijke foutafhandeling van Azure volgen wanneer ze communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

Event Hubs implementeert transparante mechanismen voor foutdetectie en failover, zodat de service blijft werken binnen de verzekerde serviceniveaus, meestal zonder merkbare onderbrekingen wanneer er fouten optreden.

Wanneer u clienttoepassingen ontwerpt voor gebruik met Event Hubs, volgt u deze richtlijnen:

  • Gebruik ingebouwd beleid voor opnieuw proberen. De SDK's voor Event Hubs en Apache Kafka proberen automatisch bewerkingen opnieuw uit te voeren bij fouten die opnieuw geprobeerd kunnen worden, zoals netwerk-time-outs, throttlingreacties of wanneer de server bezet is. Om onnodig overbelasting van de service te voorkomen, implementeren ze standaard exponentieel uitstel.

  • Configureer de juiste time-outwaarden op basis van uw toepassingsvereisten. De standaardtime-out is doorgaans 60 seconden, maar u kunt deze aanpassen op basis van uw scenario.

  • Implementeer controlepunten in uw gebeurtenisprocessor om de voortgang bij te houden en herstel vanaf de laatst verwerkte positie in te schakelen na tijdelijke fouten.

  • Gebruik batchverwerking voor verzendbewerkingen om de doorvoer te verbeteren en de impact van tijdelijke netwerkproblemen op afzonderlijke berichten te verminderen.

  • Gebruik Apache Kafka-SDK's als u met het Kafka-protocol werkt. De Kafka SDK's implementeren ook beleid voor opnieuw proberen en andere aanbevolen procedures die helpen bij het afhandelen van tijdelijke fouten.

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Event Hubs ondersteunt zone-redundante implementaties in alle servicelagen. Wanneer u een Event Hubs-naamruimte in een ondersteunde regio maakt, wordt zoneredundantie automatisch ingeschakeld zonder extra kosten. Maar bij de Dedicated-niveau worden beschikbaarheidszones alleen ondersteund met een minimum van drie CUs. Het zone-redundante implementatiemodel is van toepassing op alle Event Hubs-functies, waaronder vastleggen, schemaregister en kafka-protocolondersteuning.

Event Hubs repliceert uw configuratie-, metagegevens- en gebeurtenisgegevens transparant in drie beschikbaarheidszones in de regio. Zoneredundantie biedt automatische failover zonder tussenkomst van u. Alle Event Hubs-onderdelen, waaronder compute, netwerken en opslag, worden gerepliceerd in meerdere zones. Event Hubs heeft voldoende capaciteitsreserves om direct het volledige verlies van een zone af te handelen. Zelfs als een volledige beschikbaarheidszone niet beschikbaar is, blijven Event Hubs werken zonder gegevensverlies of onderbreking van streamingtoepassingen.

Diagram met een zoneredundante Event Hubs-naamruimte.

Ondersteuning voor regio

Zone-redundante Event Hubs-naamruimten kunnen worden geïmplementeerd in elke Azure-regio die beschikbaarheidszones ondersteunt.

Requirements

  • Standard- en Premium-lagen bieden ondersteuning voor beschikbaarheidszones zonder extra configuratie vereist.

  • Voor de Dedicated-laag zijn minimaal drie CUs vereist in beschikbaarheidszones.

Kosten

Zoneredundantie in Event Hubs voegt geen extra kosten toe.

Ondersteuning voor beschikbaarheidszones configureren

Event Hubs-naamruimten ondersteunen automatisch zoneredundantie wanneer ze worden geïmplementeerd in ondersteunde regio's. Er is geen verdere configuratie vereist.

Gedrag wanneer alle zones in orde zijn

Wanneer Event Hubs-naamruimten zoneredundantie gebruiken en alle beschikbaarheidszones normaal werken, verwacht u het volgende gedrag:

  • Verkeersroutering tussen zones: Event Hubs werkt in een actief-actief model waarbij infrastructuur in drie beschikbaarheidszones gelijktijdig binnenkomende gebeurtenissen verwerkt.

  • Gegevensreplicatie tussen zones: Event Hubs maakt gebruik van synchrone replicatie tussen beschikbaarheidszones. Wanneer een event producer een gebeurtenis verzendt, schrijft Event Hubs deze naar replica's in meerdere zones voordat de schrijfbewerking aan de client wordt bevestigd als voltooid. Deze benadering zorgt voor nul gegevensverlies, zelfs als een hele zone niet beschikbaar is. De synchrone replicatiebenadering biedt sterke consistentiegaranties, terwijl lage latentie behouden blijft via geoptimaliseerde replicatieprotocollen.

Gedrag tijdens een zonefout

Wanneer Event Hubs-naamruimten zoneredundantie gebruiken en er een storing in de beschikbaarheidszone optreedt, verwacht u het volgende gedrag:

  • Detectie en reactie: Event Hubs is verantwoordelijk voor het automatisch detecteren van een fout in een beschikbaarheidszone. U hoeft geen zonefailover te starten.
  • Melding: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

  • Actieve aanvragen: Tijdens een zonefout kunnen Actieve aanvragen worden verwijderd door Event Hubs. Als uw clients tijdelijke fouten op de juiste wijze afhandelen door het opnieuw te proberen na een korte periode, worden meestal aanzienlijke gevolgen vermeden.

  • Verwachte gegevensverlies: Er treden geen gegevensverlies op tijdens een zonefout, omdat Event Hubs gebeurtenissen synchroon repliceert tussen zones vóór bevestiging.

  • Verwachte downtime: Een zonefout kan enkele seconden downtime veroorzaken. Als uw clients tijdelijke fouten op de juiste wijze afhandelen door het opnieuw te proberen na een korte periode, worden meestal aanzienlijke gevolgen vermeden.

  • Verkeer omleiden: Event Hubs detecteert het verlies van de zone en stuurt nieuwe aanvragen automatisch om naar een andere replica in een van de gezonde beschikbaarheidszones.

    Event Hubs-client-SDK's verwerken doorgaans verbindingsbeheer en logica voor opnieuw proberen transparant.

Zoneherstel

Wanneer een beschikbaarheidszone wordt hersteld, wordt de zone automatisch opnieuw geïntegreerd in de actieve servicetopologie. De herstelde zone begint met het accepteren van nieuwe verbindingen en het verwerken van gebeurtenissen naast de andere zones. Gegevens die zijn gerepliceerd naar overlevende zones tijdens de storing blijven intact en normale synchrone replicatie wordt hervat in alle zones. U hoeft geen actie te ondernemen voor zoneherstel en re-integratie.

Testen op zonefouten

Event Hubs beheert verkeersroutering, failover en zoneherstel voor zonefouten, zodat u geen processen voor fouten in de beschikbaarheidszone hoeft te valideren of verdere invoer hoeft op te geven.

Tolerantie voor storingen in de hele regio

Event Hubs biedt twee soorten ondersteuning voor meerdere regio's:

  • Geo-replicatie (Premium- en Dedicated-lagen) biedt actief-actieve replicatie van metagegevens en gebeurtenisgegevens tussen een primaire regio en een of meer secundaire regio's. Gebruik geo-replicatie voor de meeste toepassingen die bestand moeten blijven tegen storingen in regio's en een lage tolerantie hebben voor gebeurtenisgegevensverlies.

  • Geo-noodherstel van metagegevens (Standard-laag en hoger) biedt actief-passieve replicatie van configuratie en metagegevens tussen een primaire en secundaire regio, maar er worden geen gebeurtenisgegevens gerepliceerd. Gebruik geo-noodherstel voor toepassingen die gegevensverlies van gebeurtenissen tijdens een noodgeval kunnen verdragen en die snel bewerkingen in een andere regio moeten hervatten.

Voor zowel geo-replicatie als rampherstel van metagegevens moet u handmatig een failover of promotie van een secundaire regio initiëren om een nieuwe primaire regio te worden. Microsoft voert geen failover of promotie automatisch uit, ook al valt uw primaire regio uit.

Geo-replicatie

De Premium- en Dedicated-lagen bieden ondersteuning voor geo-replicatie. Deze functie repliceert zowel metagegevens (zoals entiteiten, configuratie en eigenschappen) als gegevens (zoals nettoladingen van gebeurtenissen) voor de naamruimte. U configureert de replicatiebenadering voor de configuratie- en gebeurtenisgegevens van uw naamruimte. Deze functie zorgt ervoor dat uw gebeurtenissen beschikbaar blijven in een andere regio en u kunt zo nodig overschakelen naar de secundaire regio. Ook worden metagegevens en gegevens van het schemaregister gerepliceerd.

Gebruik geo-replicatie voor scenario's die tolerantie vereisen voor regiostoringen en een lage tolerantie hebben voor gebeurtenisgegevensverlies.

De naamruimte strekt zich in wezen uit over regio's. De ene regio fungeert als de primaire regio en de andere regio's fungeren als secundaire regio's. Uw Azure-abonnement toont één naamruimte, ongeacht hoeveel secundaire regio's u configureert voor geo-replicatie.

Diagram met een Event Hubs-naamruimte die is geconfigureerd voor geo-replicatie.

U kunt op elk gewenst moment een secundaire regio promoveren naar een primaire regio. Wanneer u een secundaire regio promoveert, verwijst Event Hubs de FQDN (Fully Qualified Domain Name) van de naamruimte naar de geselecteerde secundaire regio en wordt de vorige primaire regio gedegradeerd naar een secundaire regio. U bepaalt of u een geplande promotie wilt uitvoeren, wat betekent dat u wacht totdat de gegevensreplicatie is voltooid, of een geforceerde promotie, wat kan leiden tot gegevensverlies.

Opmerking

Geo-replicatie van Event Hubs maakt gebruik van de term promotie omdat deze het beste het proces vertegenwoordigt van het promoten van een secundaire regio naar een primaire regio (en later een primaire regio degraderen naar een secundaire regio). Mogelijk ziet u ook de term failover die wordt gebruikt om het algemene proces te beschrijven.

In deze sectie vindt u een overzicht van belangrijke aspecten van geo-replicatie. Raadpleeg de volledige documentatie om precies te begrijpen hoe het werkt. Zie Geo-replicatie van Event Hubs voor meer informatie.

Ondersteuning voor regio

U kunt elke Azure-regio kiezen die Event Hubs ondersteunt als uw primaire regio of secundaire regio's. U hoeft geen gekoppelde Azure-regio's te gebruiken, zodat u secundaire regio's kunt kiezen op basis van uw vereisten voor latentie, naleving of gegevenslocatie.

Requirements

Als u geo-replicatie wilt inschakelen, moet uw naamruimte de Premium- of Dedicated-laag gebruiken.

Overwegingen

Houd rekening met de volgende factoren wanneer u geo-replicatie inschakelt:

  • Controlepuntindeling: De indeling van controlepunten wordt gewijzigd. Voor meer informatie, zie Geo-replicatie: Gegevens gebruiken.

  • Privé-eindpunten: Als u privé-eindpunten gebruikt om verbinding te maken met uw naamruimte, moet u ook netwerken configureren in uw primaire en secundaire regio's. Zie Privé-eindpunten voor meer informatie.

Kosten

Zie Prijzen voor meer informatie over de werking van prijzen voor geo-replicatie.

Ondersteuning voor meerdere regio's configureren

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer een Event Hubs-naamruimte is geconfigureerd voor geo-replicatie en de primaire regio operationeel is.

  • Verkeersroutering tussen regio's: Clienttoepassingen maken verbinding via de FQDN voor uw naamruimte en hun verkeer wordt gerouteerd naar de primaire regio.

    Alleen de primaire regio verwerkt actief gebeurtenissen van clients tijdens normale bewerkingen. De secundaire regio ontvangt gerepliceerde gebeurtenissen, maar blijft anders passief in de stand-bymodus.

  • Gegevensreplicatie tussen regio's: Het gedrag van gegevensreplicatie tussen de primaire en secundaire regio's is afhankelijk van of u uw replicatiekoppeling configureert voor het gebruik van synchrone of asynchrone replicatie.

    • Synchroon: Gebeurtenissen worden gerepliceerd naar de secundaire regio voordat de schrijfbewerking is voltooid.

      Deze modus biedt de grootste zekerheid dat uw gebeurtenisgegevens veilig zijn omdat deze moeten worden doorgevoerd in de primaire en secundaire regio. Synchrone replicatie verhoogt echter de schrijflatentie voor binnenkomende gebeurtenissen aanzienlijk. Het vereist ook dat de secundaire regio beschikbaar is om de schrijfbewerking te accepteren, zodat een storing in een secundaire regio ervoor zorgt dat de schrijfbewerking mislukt.

      • Asynchroon: Gebeurtenissen worden naar de primaire regio geschreven en vervolgens wordt de schrijfbewerking voltooid. Een korte tijd later worden de gebeurtenissen gerepliceerd naar de secundaire regio.

      Deze modus biedt een hogere schrijfdoorvoer dan synchrone replicatie, omdat er geen latentie tussen regio's is tijdens schrijfbewerkingen. Bovendien kan de asynchrone replicatiemodus het verlies van een secundaire regio tolereren terwijl schrijfbewerkingen in de primaire regio nog steeds worden toegestaan. Als de primaire regio echter een storing heeft, zijn gegevens die nog niet zijn gerepliceerd naar de secundaire regio mogelijk niet beschikbaar of verloren gegaan.

      Wanneer u asynchrone replicatie configureert, configureert u de maximale acceptabele vertragingstijd voor replicatie. U kunt de huidige replicatievertraging op elk gewenst moment controleren met behulp van metrische gegevens van Azure Monitor.

      Als de asynchrone replicatievertraging toeneemt boven het maximum dat u opgeeft, begint de primaire regio binnenkomende aanvragen te beperken, zodat de replicatie kan inhalen. Om deze situatie te voorkomen, is het belangrijk om secundaire regio's te selecteren die niet te ver van elkaar liggen en ervoor te zorgen dat uw capaciteit voldoende is voor de doorvoer.

      Zie Replicatiemodi voor meer informatie.

Gedrag tijdens een regiofout

In deze sectie wordt beschreven wat u kunt verwachten wanneer een Event Hubs-naamruimte is geconfigureerd voor geo-replicatie en er een storing is in de primaire of secundaire regio.

  • Detectie en reactie: U bent verantwoordelijk voor het bepalen wanneer u de secundaire regio van uw naamruimte wilt promoten om de nieuwe primaire regio te worden. Microsoft neemt deze beslissing niet of initieert het proces voor u, zelfs niet als er sprake is van een storing in de regio. Zie Secundaire regio promoveren voor meer informatie over het promoveren van een secundaire regio naar de nieuwe primaire regio.

    Wanneer u een secundaire regio promovt, kiest u of u een geplande promotie of een geforceerde promotie wilt uitvoeren. Een geplande promotie wacht totdat de secundaire regio is bijgewerkt voordat nieuw verkeer wordt geaccepteerd. Deze aanpak elimineert gegevensverlies, maar introduceert downtime.

    Tijdens een storing in de primaire regio moet u doorgaans een geforceerde promotie uitvoeren. Als de primaire regio beschikbaar is en u om een andere reden een promotie activeert, kunt u een geplande promotie kiezen.

  • Kennisgeving: Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele regiofouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

    Gebruik deze informatie en andere metrische gegevens om te bepalen wanneer een secundaire regio moet worden gepromoot naar een primaire regio.

  • Actieve aanvragen: Het gedrag is afhankelijk van of de regio-storing plaatsvindt in de primaire regio of een secundaire regio:

    • Storing in primaire regio: Als de primaire regio niet beschikbaar is, worden alle actieve aanvragen beëindigd. Clienttoepassingen moeten bewerkingen opnieuw proberen nadat de promotie is voltooid.

    • Storing in secundaire regio: Een storing in de secundaire regio kan in de volgende situaties problemen veroorzaken voor actieve aanvragen:

      • Als u de synchrone replicatiemodus gebruikt, kan de primaire regio schrijfbewerkingen niet voltooien als er een secundaire regio niet beschikbaar is.

      • Als je de asynchrone replicatiemodus gebruikt, vertraagt je naamruimte en accepteert deze geen nieuwe gebeurtenissen meer wanneer de replicatievertraging het door jou geconfigureerde maximum bereikt.

      Als u de naamruimte in de primaire regio wilt blijven gebruiken, verwijdert u de secundaire naamruimte uit de configuratie van de geo-replicatie.

  • Verwachte gegevensverlies: De hoeveelheid gegevensverlies is afhankelijk van het type promotie dat u uitvoert (gepland of geforceerd) en de replicatiemodus (synchroon of asynchroon):

    • Geplande promotie: Er wordt geen gegevensverlies verwacht. Tijdens een storing in een regio is een geplande promotie echter mogelijk niet mogelijk omdat alle primaire en secundaire regio's beschikbaar moeten zijn.

    • Geforceerde promotie, synchrone replicatie: Er wordt geen gegevensverlies verwacht.

    • Geforceerde promotie, asynchrone replicatie: Mogelijk ondervindt u gegevensverlies voor recente gebeurtenissen die niet naar de secundaire regio worden gerepliceerd. De hoeveelheid is afhankelijk van de replicatievertraging. Gebruik metrische gegevens van Azure Monitor om de huidige replicatievertraging te controleren.

    Als u een geforceerde promotie uitvoert, kunt u verloren gegevens niet herstellen, zelfs niet nadat de primaire regio beschikbaar is.

  • Verwachte downtime: De hoeveelheid verwachte downtime is afhankelijk van of u een geplande of geforceerde promotie uitvoert:

    • Geplande promotie: De eerste stap in een geplande promotie repliceert gegevens naar de secundaire regio. Dit proces wordt meestal snel voltooid, maar in sommige situaties kan het tot de lengte van de replicatievertraging duren. Nadat de replicatie is voltooid, duurt het promotieproces doorgaans ongeveer 5 tot 10 minuten. Het kan soms langer duren voordat DNS-servers (Domain Name System) vermeldingen bijwerken en hun records volledig repliceren naar clients.

      De primaire regio accepteert geen schrijfbewerkingen tijdens het hele promotieproces.

      Deze optie is mogelijk niet mogelijk tijdens een storing in een regio, omdat hiervoor alle primaire en secundaire regio's beschikbaar moeten zijn.

    • Geforceerde promotie: Tijdens een geforceerde promotie wacht Event Hubs niet totdat de gegevensreplicatie is voltooid en wordt de promotie onmiddellijk gestart. Het promotieproces duurt doorgaans ongeveer 5 tot 10 minuten. Het kan soms langer duren voordat DNS-vermeldingen volledig worden gerepliceerd en bijgewerkt tussen clients.

      De primaire regio accepteert geen schrijfbewerkingen tijdens het hele promotieproces.

  • Verkeer omleiden: Nadat de promotie is voltooid, verwijst de FQDN van de naamruimte naar de nieuwe primaire regio. Maar deze omleiding is afhankelijk van hoe snel de DNS-records van clients worden bijgewerkt, inclusief dat hun DNS-servers de time-to-live (TTL) van de DNS-records van de naamruimte respecteren.

    In sommige situaties moet u consumententoepassingen zo configureren dat ze zich consistent gedragen nadat regiopromotie plaatsvindt. Voor meer informatie, zie Geo-replicatie: Gegevens gebruiken.

Herstel van de regio

Nadat de oorspronkelijke primaire regio is hersteld, volgt u hetzelfde promotieproces als u de naamruimte wilt terugzetten naar de oorspronkelijke primaire regio.

Als u tijdens de onderbreking van de regio een geforceerde promotie hebt uitgevoerd, kunt u geen verloren gegevens herstellen, zelfs niet nadat de primaire regio beschikbaar is.

Test voor regiofouten

Als u geo-replicatie wilt testen, promoveert u tijdelijk de secundaire regio naar de primaire regio en controleert u of uw clienttoepassingen kunnen schakelen tussen regio's met minimale onderbrekingen.

Controleer de duur van de promotie en controleer of uw runbooks en automatisering correct werken. Na het testen kunt u een failback uitvoeren naar de oorspronkelijke configuratie.

Krijg inzicht in de mogelijke downtime en gegevensverlies die u mogelijk ondervindt tijdens en na het promotieproces. Test geo-replicatie in een niet-productieomgeving die de configuratie van uw productienaamruimte weerspiegelt.

Geo-herstel na noodgevallen van metagegevens

De Standard-laag en hogere lagen ondersteunen het herstel van metagegevens bij geografische rampen. Deze functie verbetert het herstel van noodscenario's, waaronder het catastrofale verlies van een regio. Met geo-noodherstel worden alleen de configuratie en metagegevens van uw naamruimte gerepliceerd. Er worden echter geen gebeurtenisgegevens gerepliceerd. Ter ondersteuning van herstel na noodgevallen zorgt deze functie ervoor dat een naamruimte in een andere regio vooraf is geconfigureerd en gereed is om gebeurtenissen van clients onmiddellijk te accepteren. Geo-rampenherstel fungeert als een eenrichtingshersteloplossing en biedt geen ondersteuning voor failback naar de vorige primaire regio.

Geo-herstel bij noodgevallen van metadata werkt het beste voor toepassingen die niet strikt elke gebeurtenis hoeven bij te houden en die enig gegevensverlies tijdens een noodscenario kunnen tolereren. Als uw gebeurtenissen bijvoorbeeld sensormetingen vertegenwoordigen die u later samenvoegt, kunt u besluiten dat u bepaalde gebeurtenissen uit een mislukte regio kunt verliezen als u de verwerking van nieuwe gebeurtenissen in een andere regio snel kunt hervatten.

Belangrijk

Herstel na geo-noodgeval maakt continuïteit mogelijk van bewerkingen met dezelfde configuratie, maar repliceert geen gebeurtenisgegevens. Als u gebeurtenisgegevens wilt repliceren, kunt u overwegen geo-replicatie te gebruiken.

Wanneer u georampenherstel voor metagegevens configureert, maakt u een alias waarmee clienttoepassingen verbinding maken. De alias is een FQDN waarmee al het verkeer standaard naar de primaire naamruimte wordt doorgestuurd.

Diagram dat twee Event Hubs-naamruimten toont die zijn geconfigureerd voor geo-rampenherstel van metagegevens.

Als de primaire regio mislukt of een ander type noodgeval optreedt, kunt u handmatig een eenmalige failover initiëren van de primaire regio naar de secundaire regio op elk gewenst moment. De failover wordt bijna onmiddellijk voltooid. Tijdens het failoverproces verwijst de alias voor geo-rampenherstel naar de secundaire naamruimte en wordt de koppeling verwijderd.

In deze sectie vindt u een overzicht van belangrijke aspecten van geo-noodherstel. Raadpleeg de volledige documentatie om precies te begrijpen hoe het werkt. Zie Event Hubs geo-noodherstel voor meer informatie.

Ondersteuning voor regio

U kunt elke Azure-regio selecteren die Event Hubs ondersteunt als uw primaire of secundaire naamruimte. U hoeft geen gekoppelde Azure-regio's te gebruiken, zodat u secundaire regio's kunt kiezen op basis van uw vereisten voor latentie, naleving of gegevenslocatie.

Requirements

  • Primaire naamruimte-laag: Uw primaire naamruimte moet in de Standard-laag of hoger zijn om geo-rampenherstel van metagegevens te kunnen gebruiken.

  • Secundaire naamruimtelaag: Geo-noodherstel van metagegevens ondersteunt specifieke combinaties van lagen voor de primaire en secundaire naamruimten. Zie Ondersteunde naamruimteparen voor meer informatie.

Overwegingen

  • Roltoewijzingen: 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.

  • Schemaregister: Metagegevens van schemaregisters worden gerepliceerd wanneer u geo-herstel na noodgevallen voor metagegevens gebruikt, maar schema's die zijn geregistreerd bij het schemaregister, worden niet gerepliceerd.

  • Toepassingsontwerp: Herstel na geo-noodgeval vereist specifieke overwegingen bij het ontwerpen van uw clienttoepassingen. Zie Overwegingenvoor meer informatie.

  • Privé-eindpunten: Als u privé-eindpunten gebruikt om verbinding te maken met uw naamruimte, configureert u netwerken in zowel uw primaire als secundaire regio. Zie Privé-eindpunten voor meer informatie.

Kosten

Wanneer u herstel na een geografische ramp voor metagegevens inschakelt, betaalt u voor zowel de primaire als de secundaire naamruimten.

Ondersteuning voor meerdere regio's configureren

  • Maak een metagegevens geo-rampenherstel koppeling. Als u herstel na noodgevallen tussen primaire en secundaire naamruimten wilt configureren, raadpleegt u Instellen en failover-proces.

  • Schakel geografische noodherstel van metagegevens uit. Zie Setup en failoverstroom om de koppeling tussen naamruimten te verbreken.

Capaciteitsplanning en -beheer

Wanneer u van plan bent voor implementaties in meerdere regio's, moet u ervoor zorgen dat beide regio's voldoende capaciteit hebben om de volledige belasting af te handelen als één regio uitvalt. De secundaire regio blijft passief tijdens normale bewerkingen, maar moet het verkeer onmiddellijk verwerken na een failover. Plan hoe u de capaciteit van de secundaire naamruimte kunt schalen, zodat het productieverkeer zonder vertraging kan ontvangen. Als u extra downtime tijdens het failoverproces kunt tolereren, kunt u ervoor kiezen om de capaciteit van de secundaire naamruimte tijdens of na een failover te schalen. Als u de downtime wilt verminderen, richt u vooraf capaciteit in de secundaire naamruimte in, zodat deze gereed blijft om productiebelasting te ontvangen.

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer een Event Hubs-naamruimte is geconfigureerd voor herstel na geo-noodgeval en de primaire regio operationeel is.

  • Verkeersroutering tussen regio's: Clienttoepassingen maken verbinding via de alias voor geo-noodherstel voor uw naamruimte en hun verkeer wordt gerouteerd naar de primaire naamruimte in de primaire regio.

    Alleen de primaire naamruimte verwerkt actief gebeurtenissen van clients tijdens normale bewerkingen. De secundaire naamruimte blijft passief in de stand-bymodus en eventuele aanvragen voor toegang tot gegevens mislukken.

  • Gegevensreplicatie tussen regio's: Alleen configuratiemetagegevens worden gerepliceerd tussen de naamruimten. Replicatie van configuratie vindt continu en asynchroon plaats.

    Alle gebeurtenisgegevens blijven alleen in de primaire naamruimte en worden niet gerepliceerd naar de secundaire naamruimte.

Gedrag tijdens een regiofout

In deze sectie wordt beschreven wat u kunt verwachten wanneer een Event Hubs-naamruimte is geconfigureerd voor herstel na geo-noodgeval en er een storing is in de primaire regio.

  • Detectie en reactie: U bent verantwoordelijk voor het bewaken van de regiostatus en het handmatig initiëren van failover. Microsoft voert geen failover uit of promoveert een secundaire regio niet automatisch, zelfs niet als uw primaire regio uitvalt.

    Zie Handmatige failover voor meer informatie over het initiëren van failover.

    Failover is een eenrichtingsbewerking, dus u moet de koppeling met geografische noodherstel later opnieuw instellen. Zie Regioherstel voor meer informatie.

  • Kennisgeving: Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele regiofouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

    Gebruik deze informatie en andere metrische gegevens om te bepalen wanneer een failover naar de secundaire regio moet worden uitgevoerd.

  • Actieve aanvragen: Actieve aanvragen die worden uitgevoerd, worden beëindigd wanneer de failover wordt gestart. Clienttoepassingen moeten bewerkingen opnieuw proberen nadat de failover is voltooid.

  • Verwachte gegevensverlies:

    • Metagegevens: Configuratie en metagegevens worden doorgaans gerepliceerd naar de secundaire naamruimte. Maar replicatie van metagegevens vindt asynchroon plaats, dus recente wijzigingen worden mogelijk niet gerepliceerd, met name complexe wijzigingen. Controleer de configuratie van uw secundaire naamruimte voordat clients deze openen.

    • Gebeurtenisgegevens: Gebeurtenisgegevens worden niet gerepliceerd tussen regio's. Als de primaire regio uitvalt, zijn gebeurtenissen in uw primaire naamruimte niet meer beschikbaar.

      De gebeurtenissen gaan niet permanent verloren, tenzij een catastrofale ramp het totale verlies van de primaire regio veroorzaakt. Als de regio wordt hersteld, kunt u later gebeurtenissen ophalen uit de primaire naamruimte.

  • Verwachte downtime: Failover vindt doorgaans binnen 5 tot 10 minuten plaats. Het kan langer duren voordat clients DNS-vermeldingen volledig repliceren en bijwerken.

  • Verkeer omleiden: Clients die gebruikmaken van de alias voor geo-noodherstel om verbinding te maken met de naamruimte, worden na een failover automatisch omgeleid naar de secundaire naamruimte. Deze omleiding is echter afhankelijk van DNS-servers die de TTL van de DNS-records van de naamruimte respecteren en clients die deze bijgewerkte DNS-records ontvangen.

Herstel van de regio

Nadat de oorspronkelijke primaire regio is hersteld, moet u de koppeling handmatig herstellen en eventueel een failback uitvoeren. Maak een nieuwe geo-noodherstelkoppeling met de herstelde regio als secundair en voer vervolgens een andere failover uit als u wilt terugkeren naar de oorspronkelijke regio. Dit proces omvat mogelijk gegevensverlies van gebeurtenissen die naar de tijdelijke primaire worden verzonden.

Als het noodgeval het verlies van alle zones in de primaire regio veroorzaakt, zijn uw gegevens mogelijk onherstelbaar. In andere scenario's blijven uw gebeurtenisgegevens in de primaire naamruimte van voordat de failover kan worden hersteld. U kunt historische gebeurtenissen verkrijgen uit de oude primaire naamruimte nadat u de toegang hebt hersteld. U bent verantwoordelijk voor het configureren van uw toepassingen voor het ontvangen en verwerken van deze gebeurtenissen. Microsoft herstelt ze niet automatisch in uw secundaire regio.

Test voor regiofouten

Als u uw reactie- en herstelprocessen wilt testen, voert u een geplande failover uit tijdens een onderhoudsvenster. Start een failover van uw primaire naamruimte naar uw secundaire naamruimte en controleer of uw toepassingen verbinding kunnen maken met en gebeurtenissen van de nieuwe primaire kunnen verwerken.

Controleer de failoverduur en verifieer of je runbooks en automatisering correct werken. Na het testen kunt u een failback uitvoeren naar de oorspronkelijke configuratie.

Krijg inzicht in de mogelijke downtime en gegevensverlies die u mogelijk ondervindt tijdens en na het failoverproces. Test geo-replicatie in een niet-productieomgeving die de configuratie van uw productienaamruimte weerspiegelt.

Aangepaste oplossingen voor meerdere regio's voor veerkracht

Geo-replicatie en herstel na noodgevallen van metagegevens bieden tolerantie voor regiostoringen en andere problemen, en ze ondersteunen de meeste workloads. Sommige Event Hubs-lagen bieden geen ondersteuning voor deze functies, of u hebt mogelijk aangepaste replicatie nodig of u moet meerdere actieve regio's tegelijk onderhouden.

Verschillende ontwerppatronen kunnen verschillende soorten ondersteuning voor meerdere regio's bereiken in Event Hubs. Veel van de patronen vereisen het implementeren van meerdere naamruimten en het gebruik van services zoals Azure Functions om ertussen gebeurtenissen te repliceren. Zie Federatie voor meerdere sites en meerdere regio's voor meer informatie.

Backups en herstel

Event Hubs is niet ontworpen als een langetermijnopslaglocatie voor uw gegevens. Normaal gesproken slaat u gegevens gedurende een korte periode op in een Event Hub en verwerkt u deze of bewaart u deze in een ander systeem voor gegevensopslag. U kunt de gegevensretentieperiode voor uw Event Hub configureren op basis van uw vereisten en de laag die uw naamruimte gebruikt. Zie Gebeurtenisretentie voor meer informatie.

Als u een kopie van uw gebeurtenissen wilt bewaren, kunt u overwegen Event Hubs Capture te gebruiken, waarmee kopieën van gebeurtenissen worden opgeslagen in een Azure Blob Storage-account.

Diensteniveauovereenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

De SLA voor beschikbaarheid van uw naamruimte is hoger wanneer deze gebruikmaakt van de Premium- of Dedicated-lagen.

Verwante inhoud

  • Last updated on