Geo-replicatie in Azure Event Hubs

Azure Event Hubs geo-replicatie kopieën bewaart van de metagegevens van uw naamruimte (entiteiten, configuratie en eigenschappen) en gebeurtenisgegevens in meerdere Azure regio's. Als uw primaire regio een storing ondervindt, kunt u een secundaire regio promoveren om uw streamingtoepassingen met minimale gegevensverlies te laten werken.

In de volgende secties wordt uitgelegd hoe geo-replicatie werkt, synchrone en asynchrone replicatiemodi worden vergeleken en wordt beschreven hoe u secundaire regio's beheert.

Geo-replicatie zorgt ervoor dat metagegevens en gegevens van een naamruimte continu worden gerepliceerd van een primaire regio naar de secundaire regio. De naamruimte kan worden beschouwd als uitgebreid naar meer dan één regio, waarbij de ene regio de primaire en de andere de secundaire regio is.

Op elk gewenst moment kan de secundaire regio worden gepromoveerd tot een primaire regio. Als u een secundaire regio promoveert, wordt de FQDN-naam van de naamruimte (fully qualified domain name) naar de geselecteerde secundaire regio verplaatst en wordt de vorige primaire regio gedegradeerd naar een secundaire regio.

Scenariën

Geo-replicatie van Event Hubs kan in meerdere scenario's worden gebruikt.

Bedrijfscontinuïteit en herstel na noodgevallen garanderen

Geo-replicatie zorgt voor herstel na noodgevallen en bedrijfscontinuïteit voor alle streaminggegevens in uw naamruimte. Door gegevens in verschillende regio's te repliceren, kunnen organisaties beschermen tegen gegevensverlies en ervoor zorgen dat hun toepassingen operationeel blijven, zelfs in geval van een regionale storing. Deze functie is van cruciaal belang voor bedrijfskritieke toepassingen die hoge beschikbaarheid en minimale downtime vereisen.

Wereldwijde gegevensdistributie

Geo-replicatie kan worden gebruikt om gegevens wereldwijd te distribueren, zodat toepassingen toegang hebben tot gegevens uit de dichtstbijzijnde regio. Dit vermindert de latentie en verbetert de prestaties voor workloads die zich in verschillende delen van de wereld bevinden.

Gegevenssoevereiniteit en naleving

Organisaties die in meerdere landen of regio's werken, moeten vaak voldoen aan de wetten voor gegevenssoevereine die vereisen dat gegevens worden opgeslagen binnen specifieke geografische grenzen. Met geo-replicatie kunnen deze organisaties gegevens repliceren naar regio's die voldoen aan lokale regelgeving, zodat ze voldoen aan wettelijke vereisten terwijl ze nog steeds een geïntegreerd gegevensplatform onderhouden.

Migratie en upgrades

Geo-replicatie kan ook worden gebruikt om gegevensmigratie, onderhoud en systeemupgrades te vergemakkelijken. Organisaties kunnen hun naamruimte proactief migreren van een primaire naar een secundaire regio om onderhoud en upgrades op de primaire regio mogelijk te maken.

Basisbegrippen

De functie geo-replicatie maakt gebruik van een primair secundair replicatiemodel om metagegevens en gegevens te repliceren. Op elk gewenst moment is er één primaire regio die zowel producenten als consumenten bedient. De secundaire regio fungeert als een hot standby-regio, waardoor u niet kunt communiceren met de secundaire regio. Het wordt echter uitgevoerd in dezelfde configuratie als de primaire regio, wat betekent dat het snel kan instappen na promotie.

Enkele van de belangrijkste aspecten van de functie voor geo-replicatie zijn:

• Primair-secundair replicatiemodel: geo-replicatie is gebaseerd op een primair-secundair replicatiemodel, waarbij er op een bepaald moment slechts één primaire naamruimte is die gebeurtenisproducenten en gebeurtenisgebruikers dient.
• Event Hubs voert volledig beheerde byte-naar-byte-replicatie van metagegevens, gebeurtenisgegevens en consumentenverschil tussen secundaire databases uit met de geconfigureerde consistentieniveaus.
• Hostnaam voor enkele naamruimte: nadat u een naamruimte met geo-replicatie hebt geconfigureerd, gebruikt u de hostnaam van de naamruimte in uw clienttoepassing. De hostnaam gedraagt zich agnostisch van de geconfigureerde primaire en secundaire regio's en verwijst altijd naar de primaire regio.
• Wanneer u een promotie start, verwijst de hostnaam naar de regio die is geselecteerd als de nieuwe primaire regio. De oude primaire wordt een secundaire regio.
• U kunt de secundaire regio's niet lezen of schrijven.
• Promotie beheerd door de klant vanuit de primaire naar de secundaire regio, zorgt voor volledig eigendom en zichtbaarheid bij de oplossing van storingen. Er zijn metrische gegevens beschikbaar, die u kunnen helpen bij het automatiseren van de promotie aan de kant van de klant.
• U kunt secundaire regio's toevoegen of verwijderen.
• Replicatieconsistentie: er zijn twee instellingen voor replicatieconsistentie beschikbaar: synchroon en asynchroon.

Staat	Schema
Vóór failover (promotie van secundaire)
Na failover (promotie van secundair)

Replicatiemodi

Er zijn twee configuraties voor replicatieconsistentie beschikbaar: synchroon en asynchroon. De verschillen tussen deze twee configuraties begrijpen omdat ze van invloed zijn op uw toepassingen en uw gegevensconsistentie.

Asynchrone replicatie

Wanneer u asynchrone replicatie gebruikt, voert de primaire server alle verzoeken uit en wordt vervolgens een bevestiging naar de client verzonden. Replicatie naar de secundaire regio's vindt asynchroon plaats. U kunt de maximaal acceptabele hoeveelheid vertragingstijd configureren: de verschuiving aan de servicezijde tussen de meest recente actie op de primaire en de secundaire regio's. De service repliceert continu de gegevens en metagegevens, zodat de vertraging zo klein mogelijk blijft. Als de vertraging voor een actieve secundaire replica groter wordt dan de door de gebruiker ingestelde maximale replicatievertraging, gaat de primaire server binnenkomende aanvragen beperken.

Synchrone replicatie

Wanneer u synchrone replicatie gebruikt, verzendt het systeem alle aanvragen naar de secundaire locatie. De secundaire locatie voert de bewerking uit en bevestigt deze voordat de primaire locatie dat doet. Als gevolg hiervan publiceert uw toepassing met de snelheid die nodig is voor het publiceren, repliceren, bevestigen en doorvoeren. Dit proces betekent dat uw toepassing afhankelijk is van de beschikbaarheid van beide regio's. Als de secundaire regio achterloopt of niet beschikbaar is, worden berichten door de primaire locatie niet bevestigd of doorgevoerd en worden binnenkomende aanvragen beperkt.

Vergelijking van replicatieconsistentie

Met synchrone replicatie:

• Latentie is langer vanwege de gedistribueerde doorvoerbewerkingen.
• Beschikbaarheid is afhankelijk van de beschikbaarheid van twee regio's. Als er één regio uitvalt, is uw naamruimte niet beschikbaar.

Aan de andere kant biedt synchrone replicatie de grootste zekerheid dat uw gegevens veilig zijn. Met synchrone replicatie worden gegevenscommits uitgevoerd in alle regio's die u hebt geconfigureerd voor geo-replicatie, wat de beste datagarantie biedt.

Met asynchrone replicatie:

• Latentie wordt minimaal beïnvloed.
• Het verlies van een secundaire regio heeft niet onmiddellijk invloed op de beschikbaarheid. De beschikbaarheid wordt echter beïnvloed zodra de geconfigureerde maximale replicatievertraging is bereikt.

Als zodanig heeft het niet de absolute garantie dat alle regio's de gegevens hebben voordat de doorvoer plaatsvindt, zoals synchrone replicatie, en gegevensverlies of duplicatie kunnen optreden. Omdat u echter niet meer onmiddellijk last hebt van een vertraging in één regio of niet beschikbaar is, verbetert de beschikbaarheid van toepassingen, naast een lagere latentie.

U kunt de replicatiemodus wijzigen nadat u geo-replicatie hebt geconfigureerd. U kunt overschakelen van synchroon naar asynchroon of van asynchroon naar synchroon. Als u overschakelt van asynchroon naar synchroon, wordt de secundaire regio geconfigureerd als synchroon nadat de vertraging nul bereikt. Als u om welke reden dan ook last heeft van een aanhoudende vertraging, moet u mogelijk uw uitgevers pauzeren, zodat de vertraging nul bereikt en de modus kan overschakelen naar synchroon. De redenen om synchrone replicatie in te schakelen, in plaats van asynchrone replicatie, zijn gekoppeld aan het belang van de gegevens, specifieke bedrijfsbehoeften of nalevingsredenen, in plaats van de beschikbaarheid van uw toepassing.

Selectie secundaire regio

Als u de functie voor geo-replicatie wilt inschakelen, gebruikt u primaire en secundaire regio's waarvoor de functie is ingeschakeld. De functie voor geo-replicatie is afhankelijk van het kunnen repliceren van gepubliceerde berichten van de primaire naar de secundaire regio's. Als de secundaire regio zich op een ander continent bevindt, heeft deze keuze een grote invloed op replicatievertraging van de primaire naar de secundaire regio. Als u geo-replicatie gebruikt om beschikbaarheidsredenen, kiest u waar mogelijk secundaire regio's op hetzelfde continent. Zie Azure rondreislatentiestatistieken van het netwerk voor een beter inzicht in de latentie die wordt veroorzaakt door geografische afstand.

Geo-replicatiebeheer

Met de functie voor geo-replicatie kunt u een secundaire regio configureren waarmee metagegevens en gegevens kunnen worden gerepliceerd. Als zodanig kunt u de volgende beheertaken uitvoeren:

• Geo-replicatie configureren : u kunt secundaire regio's configureren voor een nieuwe of bestaande naamruimte in een regio door de functie geo-replicatie in te schakelen.
• Configureer de replicatieconsistentie : stel synchrone en asynchrone replicatie in wanneer u geo-replicatie configureert. U kunt deze instelling ook later wijzigen.
• Trigger voor promotie/failover - alle promoties worden door de klant gestart.
• Een secundaire verwijderen : als u een secundaire regio wilt verwijderen, kunt u dit doen. De gegevens in de secundaire regio worden verwijderd.

Criteria voor het activeren van promotie

Hier volgen enkele gevallen waarin een promotie van secundair naar primair kan plaatsvinden.

• Regionale storing: Als er sprake is van een regionale storing die van invloed is op de primaire regio, promoviseert u de secundaire regio om bedrijfscontinuïteit te garanderen en downtime te minimaliseren.

• Onderhoudsactiviteiten: Tijdens geplande onderhoudsactiviteiten in de primaire regio kan het promoten van de secundaire regio helpen bij het handhaven van hoge beschikbaarheid voor bedrijfskritieke toepassingen.

• Herstel na noodgevallen: in het geval van een noodgeval dat van invloed is op de primaire regio, zorgt het promoten van de secundaire regio ervoor dat uw gegevens toegankelijk blijven en uw toepassingen blijven functioneren.

• Prestatieproblemen: als de primaire regio prestatieproblemen ondervindt die van invloed zijn op de beschikbaarheid of betrouwbaarheid van uw Event Hubs, kan het promoten van de secundaire regio helpen deze problemen te verhelpen.

Test af en toe failovermechanismen om ervoor te zorgen dat het bedrijfscontinuïteitsplan effectief is en uw toepassingen naadloos kunnen overschakelen naar de secundaire regio wanneer dat nodig is.

Gegevensreplicatie bewaken

U kunt de voortgang van de replicatietaak controleren door de metrische replicatievertragingsgegevens te controleren in de logboeken met metrische gegevens van de toepassing.

• Schakel toepassingsmetrieklogboeken in in uw Event Hubs-naamruimte door Monitoring Azure Event Hubs - Azure Event Hubs | Microsoft Learn te volgen.

• Nadat je toepassingsmetrische logboeken hebt ingeschakeld, kun je enkele minuten data uit de naamruimte produceren en consumeren voordat je de logboeken begint te zien.

• Als u metrische logboeken voor toepassingsgegevens wilt weergeven, gaat u naar de sectie Bewaking van de pagina Event Hubs en selecteert u Logboeken in het linkermenu. Gebruik de volgende query om de replicatievertraging (in seconden) tussen de primaire en secundaire naamruimten te vinden.

  AzureDiagnostics
    | where TimeGenerated > ago(1h)
    | where Category == "ApplicationMetricsLogs"
    | where ActivityName_s == "ReplicationLag
  

• De kolom count_d toont de replicatievertraging in seconden tussen de primaire en secundaire regio.

Gegevens publiceren

Publicerende applicaties kunnen gegevens verzenden naar geo-gerepliceerde naamruimten via de hostnaam van de geo-replicatie ingeschakelde naamruimte. De publicatiebenadering is hetzelfde als in het geval zonder geo-replicatie. U hoeft geen wijzigingen aan te brengen in SDK's voor gegevensvlakken of clienttoepassingen.

Het publiceren van gebeurtenissen is mogelijk niet beschikbaar in de volgende omstandigheden:

• Nadat de promotie van een secundaire regio is aangevraagd, weigert de bestaande primaire regio eventuele nieuwe gebeurtenissen die naar de Event Hub worden gepubliceerd.
• Wanneer de vertraging in replicatie tussen primaire en secundaire regio's de maximaal toegestane replicatievertraging bereikt, kan het inkomende verkeer van de uitgever mogelijk beperkt worden.

Publisher-toepassingen hebben geen rechtstreeks toegang tot naamruimten in de secundaire regio's.

Gegevens gebruiken

Toepassingen kunnen gegevens verbruiken door het gebruik van de hostnaam van een naamruimte waarmee geo-replicatie is ingeschakeld. Consumentenactiviteiten worden niet ondersteund vanaf het moment dat de promotie begint totdat de promotie eindigt.

Controlepunten en offsetbeheer

Toepassingen die gebeurtenissen verbruiken, kunnen offsetbeheer op dezelfde manier behouden als met een niet-geo-gerepliceerde naamruimte. Naamruimten waarvoor geo-replicatie is ingeschakeld, hebben geen speciale aandacht nodig voor offsetbeheer.

Kafka

Consumenten voeren offsets rechtstreeks door naar Event Hubs en het systeem repliceert offsets tussen regio's. Daarom kunnen consumenten gaan verbruiken vanaf waar ze waren gebleven in de primaire regio.

Hier volgt een lijst met ondersteunde Apache Kafka-clients:

Voor andere bibliotheken is ondersteuning afhankelijk van de API-versie:

Event Hubs SDK en AMQP

Voor AMQP beheren gebruikers het controlepunt met behulp van een controlepuntarchief zoals Azure Blob Storage of een aangepaste opslagoplossing. Als er een failover is, moet de secundaire regio het controlepuntarchief hebben, zodat clients controlepuntgegevens kunnen ophalen en verlies van berichten kunnen voorkomen.

De nieuwste versie van de Event Hubs SDK bevat wijzigingen in controlepuntweergave ter ondersteuning van failovers. Gebruik de nieuwste versies van de SDK's, maar eerdere versies van de volgende SDK's worden ook ondersteund.

Overwegingen

Houd rekening met de volgende overwegingen:

• Houd rekening met de tijdsfactor in uw promotieplanning. Als u bijvoorbeeld langer dan 15 tot 20 minuten geen verbinding meer hebt, kunt u besluiten om de promotie te starten.
• U moet minstens één keer oefenen om een complexe gedistribueerde infrastructuur te promoten.

Prijzen

De prijzen variëren op basis van de prijscategorie die u kiest, maar heeft over het algemeen twee parameters:

• De rekenkosten voor het cluster of de naamruimte.
• De bandbreedtekosten voor de gegevens die worden gerepliceerd tussen de primaire en secundaire regio's.

Toegewezen clusters

Wanneer u geo-replicatie gebruikt met toegewezen Event Hubs-clusters, hebt u ten minste twee toegewezen clusters in afzonderlijke regio's nodig. U kunt deze clusters gebruiken om andere naamruimten te hosten dan de naamruimte die geografisch wordt gerepliceerd. U betaalt afzonderlijk voor deze toegewezen clusters op basis van het aantal capaciteitseenheden (CA's) dat aan elk cluster is toegewezen.

Wanneer u geo-replicatie inschakelt, zijn de enige extra kosten de bandbreedtekosten voor de gegevens die van primaire naar secundaire gegevens worden gerepliceerd. Deze kosten zijn afhankelijk van de locatie van de primaire regio.

Premium-naamruimten

Wanneer u geo-replicatie inschakelt, krijgt u voor Premium-naamruimten hetzelfde aantal verwerkingseenheden (PU's) in de secundaire regio. U betaalt voor het aantal PU's dat u gebruikt en de bandbreedte voor de gegevens die worden overgedragen tussen de primaire en secundaire regio.

Als u bijvoorbeeld geo-replicatie inschakelt op een Premium-naamruimte die u hebt ingericht met 4 PUs, dan betaalt u voor

• 4 PUs in de primaire regio
• 4 PUs in de secundaire regio
• Kosten voor geo-replicatie per GB aan gerepliceerde gegevens.

U betaalt bandbreedtekosten op basis van de gegevens die worden overgedragen tussen de primaire en secundaire regio's.

Prijsmeters

De prijsmeters voor de bandbreedtekosten voor geo-replicatiegegevensoverdracht worden weergegeven met de volgende details:

Privé-eindpunten

Deze sectie bevat aanvullende overwegingen bij het gebruik van geo-replicatie met naamruimten die gebruikmaken van privé-eindpunten. Zie Integrate Azure Event Hubs with Azure Private Link voor algemene informatie over het gebruik van privé-eindpunten met Event Hubs.

Wanneer u geo-replicatie implementeert voor een Event Hubs-naamruimte die gebruikmaakt van privé-eindpunten, maakt u privé-eindpunten voor zowel de primaire als secundaire regio's. Configureer deze eindpunten voor virtuele netwerken die zowel primaire als secundaire exemplaren van uw toepassing hosten. Als u bijvoorbeeld twee virtuele netwerken hebt, VNET-1 en VNET-2, moet u twee privé-eindpunten maken in de Event Hubs-naamruimte, met subnetten van respectievelijk VNET-1 en VNET-2. Stel de virtuele netwerken in met peering tussen regio's, zodat clients kunnen communiceren met een van de privé-eindpunten. Ten slotte beheert u de DNS zodat alle clients de DNS-gegevens ophalen die het naamruimte-eindpunt (namespacename.servicebus.windows.net) naar het IP-adres van het privé-eindpunt in de huidige primaire regio verwijzen.

Deze aanpak biedt het voordeel dat failover onafhankelijk kan plaatsvinden op de toepassingslaag of in de Event Hubs-naamruimte:

• Failover alleen voor toepassingen: In dit scenario wordt de toepassing verplaatst van VNET-1 naar VNET-2. Omdat privé-eindpunten zijn geconfigureerd op zowel VNET-1 als VNET-2 voor zowel primaire als secundaire naamruimten, blijft de toepassing naadloos functioneren.
• Event Hubs-naamruimte alleen-failover: Als de failover alleen op het Event Hubs-naamruimte niveau plaatsvindt, blijft de applicatie operationeel omdat privé-eindpunten geconfigureerd zijn op beide virtuele netwerken.

Door deze richtlijnen te volgen, kunt u robuuste en betrouwbare failovermechanismen garanderen voor uw Event Hubs-naamruimten die gebruikmaken van privé-eindpunten.

Gerelateerde inhoud

Zie Geo-replicatie gebruiken voor meer informatie over het gebruik van de functie Geo-replicatie.