Geo-replicatie (openbare preview)

Er zijn twee functies die geo-noodherstel bieden in Azure Event Hubs.

• Herstel na geo-noodgeval (metadata DR), dat alleen replicatie van metagegevens biedt.
• Geo-replicatie (openbare preview), die replicatie van zowel metagegevens als de gegevens biedt.

Notitie

De functie Geo-replicatie wordt alleen ondersteund door de toegewezen laag.

Deze functies moeten niet worden verward met Beschikbaarheidszones. Beide geografische herstelfuncties bieden tolerantie tussen Azure-regio's, zoals VS - oost en VS - west. Ondersteuning voor beschikbaarheidszones biedt tolerantie binnen een specifieke geografische regio, zoals VS - oost. Zie ondersteuning voor Event Hubs-beschikbaarheidszones voor meer informatie over Beschikbaarheidszones.

Belangrijk

• Deze functie is momenteel beschikbaar als openbare preview en mag daarom niet worden gebruikt in productiescenario's.
• De volgende regio's worden momenteel ondersteund in de openbare preview.

Region	Region	Region
AustraliaCentral	GermanyNorth	NoorwegenWest
AustraliaCentral2	GermanyWestCentral	PolenCentral
AustraliaEast	IsraëlCentral	SouthAfricaNorth
AustraliaSoutheast	ItalyNorth	SouthAfricaWest
BrazilSoutheast	JapanEast	SoutheastAsia
CanadaCentral	JapanWest	SouthIndia
CanadaEast	JioIndiaCentral	SpainCentral
CentralIndia	JioIndiaWest	SwedenCentral
CentralUS	KoreaCentral	SwitzerlandNorth
CentralUSEUAP	KoreaSouth	ZwitserlandWest
EastAsia	MexicoCentral	UAECentral
EastUS2	NorthCentralUS	UAENorth
FranceCentral	Noord-Europa	UKSouth
FranceSouth	NorwayEast	UKWest

Herstel na noodgevallen van metagegevens versus geo-replicatie van metagegevens en gegevens

De functie Herstel na noodgevallen van metagegevens repliceert configuratiegegevens voor een naamruimte van een primaire naamruimte naar een secundaire naamruimte. Het ondersteunt een eenmalige failover naar de secundaire regio. Tijdens de door de klant geïnitieerde failover wordt de aliasnaam voor de naamruimte opnieuw aan de secundaire naamruimte toegewezen en wordt de koppeling verbroken. Er worden geen andere gegevens gerepliceerd dan configuratiegegevens en worden ook geen machtigingstoewijzingen gerepliceerd.

De nieuwere functie geo-replicatie repliceert configuratiegegevens en alle gegevens van een primaire naamruimte naar een of meer secundaire naamruimten. Wanneer een failover wordt uitgevoerd, wordt de geselecteerde secundaire de primaire en wordt de vorige primaire een secundaire. Gebruikers kunnen desgewenst een failover uitvoeren naar de oorspronkelijke primaire server.

Deze rest van dit artikel is gericht op de functie Geo-replicatie. Zie Event Hubs Geo-disater recovery voor metagegevens voor metagegevens voor meer informatie over de functie voor herstel na noodgeval met metagegevens.

Geo-replicatie

De openbare preview van de functie Geo-replicatie wordt ondersteund voor naamruimten in Event Hubs zelf toegewezen clusters schalen. U kunt de functie gebruiken met nieuwe of bestaande naamruimten in toegewezen zelfbedieningsclusters. De volgende functies worden niet ondersteund met geo-replicatie:

• Door de klant beheerde sleutels (CMK)
• Beheerde identiteit voor vastleggen
• Functies van virtuele netwerken (service-eindpunten of privé-eindpunten)
• Ondersteuning voor grote berichten (nu in openbare preview)
• Kafka-transacties (nu in openbare preview)

Enkele van de belangrijkste aspecten van openbare preview van geogegevensreplicatie zijn:

• Primair-secundair replicatiemodel: geo-replicatie is gebaseerd op het primaire-secundaire replicatiemodel, waarbij er op een bepaald moment slechts één primaire naamruimte is die gebeurtenisproducenten en gebeurtenisgebruikers bedient.
• Event Hubs voert volledig beheerde byte-naar-byte-replicatie van metagegevens, gebeurtenisgegevens en consumentenverschil tussen secundaire databases uit met de geconfigureerde consistentieniveaus.
• Stabiele naamruimte fully qualified domain name (FQDN): de FQDN hoeft niet te veranderen wanneer de promotie wordt uitgevoerd.
• Replicatieconsistentie: er zijn twee instellingen voor replicatieconsistentie, synchroon en asynchroon.
• Door de gebruiker beheerde promotie van een secundair niveau tot de nieuwe primaire.

Als u een secundaire waarde wijzigt in een nieuwe primaire server, kunt u het volgende op twee manieren doen:

• Gepland: een promotie van de secundaire naar primaire locatie waar het verkeer pas wordt verwerkt als de nieuwe primaire wordt opgeslagen met alle gegevens die door het voormalige primaire exemplaar zijn opgeslagen.
• Geforceerd: als een failover waarbij de secundaire zo snel mogelijk primair wordt. Met de functie Geo-replicatie worden alle gegevens en metagegevens van de primaire regio gerepliceerd naar de geselecteerde secundaire regio's. De naamruimte-FQDN verwijst altijd naar de primaire regio.

Wanneer u een promotie van een secundaire waarde initieert, verwijst de FQDN naar de geselecteerde regio als de nieuwe primaire regio. De oude primaire wordt vervolgens een secundaire. U kunt uw secundaire niveau verhogen naar de nieuwe primaire om andere redenen dan een failover. Deze redenen kunnen betrekking hebben op toepassingsupgrades, failovertests of een willekeurig aantal andere zaken. In dergelijke situaties is het gebruikelijk om terug te schakelen wanneer deze activiteiten zijn voltooid.

Secundaire regio's worden toegevoegd of verwijderd naar eigen goeddunken van de klant. Er zijn enkele huidige beperkingen die u moet noteren:

• Er is geen mogelijkheid om alleen-lezenweergaven in secundaire regio's te ondersteunen.
• Er is geen mogelijkheid voor automatische promotie/failover. Alle promoties worden door de klant geïnitieerd.
• Secundaire regio's moeten afwijken van de primaire regio. U kunt geen ander toegewezen cluster in dezelfde regio selecteren.
• Er wordt slechts één secundaire versie ondersteund voor openbare preview.

Replicatieconsistentie

Er zijn twee configuraties voor replicatieconsistentie, synchroon en asynchroon. Het is belangrijk om de verschillen tussen de twee configuraties te kennen, omdat deze invloed hebben op uw toepassingen en uw gegevensconsistentie.

Asynchrone replicatie

Als asynchrone replicatie is ingeschakeld, worden alle berichten doorgevoerd in de primaire en vervolgens verzonden naar de secundaire. Gebruikers kunnen een acceptabele hoeveelheid vertragingstijd configureren die de secundaire moet inhalen. Wanneer de vertraging voor een actieve secundaire waarde groter is dan de configuratie van gebruikersvertraging, beperkt de primaire regio binnenkomende publicatieaanvragen.

Synchrone replicatie

Wanneer synchrone replicatie is ingeschakeld, worden gepubliceerde gebeurtenissen gerepliceerd naar de secundaire, die het bericht moeten bevestigen voordat het wordt doorgevoerd in de primaire. Met synchrone replicatie publiceert uw toepassing met de snelheid die nodig is voor het publiceren, repliceren, bevestigen en doorvoeren. Dit betekent ook dat uw toepassing is gekoppeld aan de beschikbaarheid van beide regio's. Als de secundaire regio uitvalt, kunnen berichten niet worden bevestigd of doorgevoerd.

Vergelijking van replicatieconsistentie

Met synchrone replicatie:

• Latentie is langer vanwege de gedistribueerde doorvoer.
• Beschikbaarheid is gekoppeld aan de beschikbaarheid van twee regio's. Als er één regio uitvalt, is uw naamruimte niet beschikbaar.
• Ontvangen gegevens bevinden zich altijd in ten minste twee regio's (slechts twee regio's die worden ondersteund in de eerste openbare preview).

Synchrone replicatie biedt de grootste zekerheid dat uw gegevens veilig zijn. Als u synchrone replicatie hebt, wordt deze doorgevoerd in alle regio's die zijn geconfigureerd voor geo-replicatie. Wanneer synchrone replicatie is ingeschakeld, kan de beschikbaarheid van uw toepassing worden verminderd, afhankelijk van de beschikbaarheid van beide regio's.

Het inschakelen van asynchrone replicatie heeft geen invloed op de latentie en de beschikbaarheid van de service wordt niet beïnvloed door het verlies van een secundaire regio. Asynchrone replicatie heeft niet de absolute garantie dat alle regio's de gegevens hebben voordat ze worden doorgevoerd, zoals synchrone replicatie. U kunt ook instellen hoe lang uw secundaire server niet synchroon kan zijn voordat binnenkomend verkeer wordt beperkt. De instelling kan van 5 minuten tot 1440 minuten zijn, wat één dag is. Als u regio's met een grote afstand tussen deze regio's wilt gebruiken, is asynchrone replicatie waarschijnlijk de beste optie voor u.

Configuratie van replicatieconsistentie kan worden gewijzigd na configuratie van geo-replicatie. U kunt van synchroon naar asynchroon of van asynchroon naar synchroon gaan. Als u van synchrone naar asynchrone gegevens gaat, verbetert uw latentie en de beschikbaarheid van toepassingen. Als u van asynchroon naar synchroon gaat, wordt uw secundaire configuratie geconfigureerd als synchroon nadat de vertraging nul bereikt. Als u om welke reden dan ook met een continue vertraging werkt, moet u de uitgevers mogelijk onderbreken om vertraging nul te bereiken en uw modus om over te schakelen naar synchrone bewerkingen.

De algemene redenen voor synchrone replicatie zijn gekoppeld aan het belang van de gegevens, specifieke zakelijke behoeften of nalevingsredenen. Als uw primaire doel de beschikbaarheid van toepassingen is in plaats van gegevenscontrole, is asynchrone consistentie waarschijnlijk de betere keuze.

Selectie secundaire regio

Als u de functie Geo-replicatie wilt inschakelen, moet u een primaire en secundaire regio gebruiken waarvoor de functie Geo-replicatie is ingeschakeld. U moet ook een Event Hubs-cluster hebben dat al bestaat in zowel de primaire als secundaire regio's.

De functie Geo-replicatie is afhankelijk van het kunnen repliceren van gepubliceerde gebeurtenissen van de primaire naar de secundaire regio. Als de secundaire regio zich op een ander continent bevindt, heeft deze een grote invloed op de replicatievertraging van de primaire naar de secundaire regio. Als u geo-replicatie gebruikt om redenen van beschikbaarheid en betrouwbaarheid, kunt u het beste gebruikmaken van secundaire regio's die zich ten minste op hetzelfde continent bevinden, indien mogelijk. Als u een beter inzicht wilt krijgen in de latentie die wordt veroorzaakt door geografische afstand, kunt u meer te weten komen over de latentiestatistieken van het Azure-netwerk | Microsoft Learn.

Geo-replicatiebeheer

Met de functie Geo-replicatie kunt u een secundaire regio configureren om configuratie en gegevens naar te repliceren. U kunt:

• Geo-replicatie configureren: secundaire regio's kunnen worden geconfigureerd op elke bestaande naamruimte in een zelf-server toegewezen cluster in een regio waarvoor de functie voor geo-replicatie is ingeschakeld. Het kan ook worden geconfigureerd tijdens het maken van de naamruimte op dezelfde toegewezen clusters. Als u een secundaire regio wilt selecteren, moet er een toegewezen cluster beschikbaar zijn in die secundaire regio en moet voor de secundaire regio ook de functie voor geo-replicatie zijn ingeschakeld voor die regio.
• Configureer de replicatieconsistentie : synchrone en asynchrone replicatie wordt ingesteld wanneer geo-replicatie is geconfigureerd, maar kan daarna ook worden overgeschakeld. Met asynchrone consistentie kunt u configureren hoe lang een secundaire regio vertraging mag oplopen.
• Triggerpromotie/failover : alle promoties of failovers worden door de klant geïnitieerd. Tijdens de promotie kunt u ervoor kiezen om het geforceerd te maken vanaf het begin of zelfs van gedachten te veranderen nadat een promotie is gestart en geforceerd.
• Een secundaire verwijderen: als u de geokoppeling tussen primaire en secundaire regio's wilt verwijderen, kunt u dit doen en worden de gegevens in de secundaire regio verwijderd.

Gegevensreplicatie bewaken

Gebruikers kunnen de voortgang van de replicatietaak controleren door de metrische gegevens voor replicatievertraging te bewaken in de logboeken met metrische gegevens van de toepassing.

• Toepassingsgegevenslogboeken inschakelen in uw Event Hubs-naamruimte na bewaking van Azure Event Hubs - Azure Event Hubs | Microsoft Learn.

• Zodra logboeken voor metrische gegevens van toepassing zijn ingeschakeld, moet u enkele minuten gegevens uit de naamruimte produceren en gebruiken voordat u de logboeken gaat bekijken.

• Als u metrische toepassingslogboeken wilt weergeven, gaat u naar de sectie Bewaking van de pagina Event Hubs en selecteert u Logboeken in het linkermenu. U kunt de volgende query gebruiken 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 geeft de replicatievertraging in seconden aan tussen de primaire en secundaire regio.

Publicatiegegevens

Toepassingen voor het publiceren van gebeurtenissen kunnen gegevens publiceren naar geo-gerepliceerde naamruimten via een stabiele naamruimte-FQDN van de geo-gerepliceerde naamruimte. De benadering voor het publiceren van gebeurtenissen is hetzelfde als de niet-Geo DR-case en er zijn geen wijzigingen in clienttoepassingen vereist.

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

• Tijdens de respijtperiode voor failover weigert de bestaande primaire regio eventuele nieuwe gebeurtenissen die naar de Event Hub worden gepubliceerd.
• Wanneer de replicatievertraging tussen primaire en secundaire regio's de maximale duur van de replicatievertraging bereikt, wordt de workload voor inkomend verkeer van de uitgever mogelijk beperkt. Publisher-toepassingen hebben geen rechtstreeks toegang tot naamruimten in de secundaire regio's.

Gegevens gebruiken

Toepassingen die gebeurtenissen gebruiken, kunnen gegevens verbruiken met behulp van de stabiele naamruimte-FQDN van een geo-gerepliceerde naamruimte. De consumentenbewerkingen worden niet ondersteund, vanaf het moment dat de failover wordt gestart totdat deze is voltooid.

Controlepunten/offsetbeheer

Toepassingen die gebeurtenissen verbruiken, kunnen offsetbeheer blijven behouden, zoals ze dat zouden doen met één naamruimte.

Kafka

Offsets worden rechtstreeks doorgevoerd in Event Hubs en offsets worden gerepliceerd in verschillende regio's. Daarom kunnen consumenten beginnen met het verbruik vanaf waar het was gebleven in de primaire regio.

Event Hubs SDK/AMQP

Clients die gebruikmaken van de Event Hubs SDK moeten een upgrade uitvoeren naar de versie van april 2024 van de SDK. De nieuwste versie van de Event Hubs SDK ondersteunt failover met een update naar het controlepunt. Het controlepunt wordt beheerd door gebruikers met een controlepuntarchief, zoals Azure Blob Storage of een aangepaste opslagoplossing. Als er een failover is, moet het controlepuntarchief beschikbaar zijn vanuit de secundaire regio, zodat clients controlepuntgegevens kunnen ophalen en verlies van berichten kunnen voorkomen.

Prijzen

Toegewezen Event Hubs-clusters worden onafhankelijk van geo-replicatie geprijsd. Voor het gebruik van geo-replicatie met Toegewezen Event Hubs moet u ten minste twee toegewezen clusters in afzonderlijke regio's hebben. De toegewezen clusters die worden gebruikt als secundaire exemplaren voor geo-replicatie, kunnen worden gebruikt voor andere workloads. Er worden kosten in rekening gebracht voor geo-replicatie op basis van de gepubliceerde bandbreedte * het aantal secundaire regio's. De kosten voor geo-replicatie worden in een vroege openbare preview afgetrokken.

Gerelateerde inhoud

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