Geo-replikering i Azure Event Hubs

Azure Event Hubs geo-replikering behåller kopior av ditt namnområdes metadata (entiteter, konfiguration och egenskaper) samt händelsedata i flera Azure-regioner. Om det uppstår ett avbrott i din primära region kan du höja upp en sekundär region så att dina strömmande program körs med minimal dataförlust.

I följande avsnitt beskrivs hur geo-replikering fungerar, jämför synkrona och asynkrona replikeringslägen och beskriver hur du hanterar sekundära regioner.

Geo-replikering säkerställer att metadata och data för ett namnområde kontinuerligt replikeras från en primär region till den sekundära regionen. Namnområdet kan betraktas som utökat till mer än en region, där en region är den primära och den andra är den sekundära.

När som helst kan den sekundära regionen befordras till en primär region. Genom att ändra pekning av en sekundär region så att namnområdets FQDN (fullständigt kvalificerat domännamn) riktas mot den valda sekundära regionen, degraderas den tidigare primära regionen till en sekundär region.

Scenarier

Event Hubs geo-replikering kan användas i flera scenarier.

Säkerställa affärskontinuitet och haveriberedskap

Geo-replikering säkerställer haveriberedskap och affärskontinuitet för alla strömmande data i ditt namnområde. Genom att replikera data mellan regioner kan organisationer skydda mot dataförlust och se till att deras program förblir i drift även i händelse av ett regionalt avbrott. Den här funktionen är avgörande för verksamhetskritiska program som kräver hög tillgänglighet och minimal stilleståndstid.

Global datadistribution

Geo-replikering kan användas för att distribuera data globalt, vilket gör att program kan komma åt data från närmaste region. Detta minskar svarstiden och förbättrar prestandan för arbetsbelastningar som finns i olika delar av världen.

Datasuveränitet och efterlevnad

Organisationer som är verksamma i flera länder eller regioner måste ofta följa lagar om datasuveränitet som kräver att data lagras inom specifika geografiska gränser. Med geo-replikering kan dessa organisationer replikera data till regioner som följer lokala regler, vilket säkerställer att de uppfyller juridiska krav samtidigt som de upprätthåller en enhetlig dataplattform.

Migrering och uppgraderingar

Geo-replikering kan också användas för att underlätta datamigrering, underhåll och systemuppgraderingar. Organisationer kan migrera sitt namnområde proaktivt från en primär till en sekundär region för att möjliggöra underhåll och uppgraderingar i den primära regionen.

Grundläggande begrepp

Geo-replikeringsfunktionen använder en primär-sekundär replikeringsmodell för att replikera metadata och data. När som helst finns det en enda primär region som betjänar både producenter och konsumenter. Den sekundära regionen fungerar som en aktiv väntelägesregion, så du kan inte interagera med den sekundära regionen. Den körs dock i samma konfiguration som den primära regionen, vilket innebär att den snabbt kan ta över efter uppgradering.

Några av de viktigaste aspekterna av geo-replikeringsfunktionen är:

• Primär-sekundär replikeringsmodell – Geo-replikering bygger på en primär-sekundär replikeringsmodell, där det vid en viss tidpunkt bara finns ett primärt namnområde som hanterar händelseproducenter och händelsekonsumenter.
• Event Hubs utför fullständigt hanterad byte-för-byte-replikering av metadata, händelsedata och förbrukaroffset över sekundärer med de konfigurerade konsekvensnivåerna.
• Värdnamn för enskilt namnområde – När du har konfigurerat ett geo-replikeringsaktiverat namnområde använder du värdnamnet för namnområdet i klientprogrammet. Värdnamnet beter sig agnostikiskt för de konfigurerade primära och sekundära regionerna och pekar alltid på den primära regionen.
• När du initierar en befordran pekar värdnamnet på den region som valts som den nya primära regionen. Den gamla primära blir en sekundär region.
• Du kan inte läsa eller skriva i de sekundära regionerna.
• Kundhanterad befordran från primär till sekundär region, vilket ger fullständigt ägande och synlighet för avbrottsmatchning. Mått är tillgängliga, vilket kan hjälpa dig att automatisera befordran från kundsidan.
• Du kan lägga till eller ta bort sekundära regioner.
• Replikeringskonsekvens – Två inställningar för replikeringskonsekvens är tillgängliga: synkron och asynkron.

Stat/län	Diagram
Före redundansväxling (befordran av sekundär)
Efter redundansväxling (befordran av sekundär)

Replikeringslägen

Det finns två konfigurationer för replikeringskonsekvens: synkrona och asynkrona. Förstå skillnaderna mellan dessa två konfigurationer eftersom de påverkar dina program och din datakonsekvens.

Asynkron replikering

När du använder asynkron replikering begår den primära enheten alla begäranden och skickar sedan en bekräftelse till klienten. Replikering till de sekundära regionerna sker asynkront. Du kan konfigurera den maximala godkända fördröjningstiden – förskjutningen på tjänstsidan mellan den senaste åtgärden i de primära och sekundära regionerna. Tjänsten replikerar kontinuerligt data och metadata, vilket säkerställer att fördröjningen förblir så liten som möjligt. Om fördröjningen för en aktiv sekundär växer utöver användarens konfigurerade maximala replikeringsfördröjning börjar den primära begränsningen av inkommande begäranden.

Synkroniserad replikering

När du använder synkron replikering skickar systemet alla begäranden till den sekundära platsen. Den sekundära platsen utför och bekräftar operationen innan den primära platsen genomför. Därför publicerar ditt program med den hastighet som krävs för att publicera, replikera, bekräfta och committa. Den här processen innebär att ditt program är beroende av tillgängligheten för båda regionerna. Om den sekundära regionen släpar efter eller inte är tillgänglig, så bekräftar eller begår den primära regionen inte meddelanden och begränsar inkommande begäranden.

Jämförelse av replikeringskonsistens

Med synkron replikering:

• Svarstiden är längre på grund av de distribuerade commit-operationerna.
• Tillgänglighet beror på tillgängligheten för två regioner. Om en region slutar fungera är namnområdet inte tillgängligt.

Å andra sidan ger synkron replikering den största försäkran om att dina data är säkra. Med synkron replikering skriver data in i alla regioner som du har konfigurerat för geo-replikering, vilket ger bästa möjliga dataintegritet.

Med asynkron replikering:

• Svarstiden påverkas minimalt.
• Förlusten av en sekundär region påverkar inte omedelbart tillgängligheten. Tillgängligheten påverkas dock när den konfigurerade maximala replikeringsfördröjningen har nåtts.

Därför har den inte den absoluta garantin att alla regioner har data före kommiteringen, så som synkron replikering kan, vilket kan leda till dataförlust eller duplicering. Men eftersom du inte längre påverkas omedelbart när en enda region släpar efter eller är otillgänglig förbättras programtillgängligheten, förutom att du har en lägre svarstid.

Du kan ändra replikeringsläget när du har konfigurerat geo-replikering. Du kan växla från synkron till asynkron eller från asynkron till synkron. Om du växlar från asynkron till synkron konfigureras den sekundära regionen som synkron när fördröjningen når noll. Om du av någon anledning upplever en kontinuerlig fördröjning kan det bli nödvändigt att pausa dina utgivare för att fördröjningen ska bli noll och så att läget kan växla till synkront. Orsakerna till att aktivera synkron replikering i stället för asynkron replikering är knutna till vikten av data, specifika affärsbehov eller efterlevnadsskäl i stället för tillgängligheten för ditt program.

Val av sekundär region

Om du vill aktivera geo-replikeringsfunktionen använder du primära och sekundära regioner där funktionen är aktiverad. Geo-replikeringsfunktionen är beroende av att kunna replikera publicerade meddelanden från den primära till de sekundära regionerna. Om den sekundära regionen finns på en annan kontinent har det här valet stor inverkan på replikeringsfördröjningen från den primära till den sekundära regionen. Om du använder geo-replikering av tillgänglighetsskäl väljer du sekundära regioner på samma kontinent där det är möjligt. Om du vill få en bättre förståelse för svarstiden som orsakas av geografiskt avstånd kan du läsa Azure statistik över svarstider för nätverk.

Hantering av geo-replikering

Med geo-replikeringsfunktionen kan du konfigurera en sekundär region som metadata och data ska replikeras mot. Därför kan du utföra följande hanteringsuppgifter:

• Konfigurera geo-replikering – Du kan konfigurera sekundära regioner på alla nya eller befintliga namnområden i en region genom att aktivera geo-replikeringsfunktionen.
• Konfigurera replikeringskonsekvensen – Ange synkron och asynkron replikering när du konfigurerar geo-replikering. Du kan också växla den här inställningen senare.
• Starta promotion/failover – Alla promotion eller failover initieras av kunden.
• Ta bort en sekundär – Om du vill ta bort en sekundär region kan du göra det. Data i den sekundära regionen tas bort.

Villkor för att utlösa befordran

Här är några fall där en uppgradering av en sekundär till primär kan utlösas.

• Regionalt avbrott: Om det uppstår ett regionalt avbrott som påverkar den primära regionen bör du höja upp den sekundära regionen för att säkerställa affärskontinuitet och minimera driftstopp.

• Underhållsaktiviteter: Under planerade underhållsaktiviteter i den primära regionen kan främjandet av den sekundära regionen bidra till att upprätthålla hög tillgänglighet för verksamhetskritiska program.

• Haveriberedskap: I händelse av en katastrof som påverkar den primära regionen säkerställer främjandet av den sekundära regionen att dina data förblir tillgängliga och att dina program fortsätter att fungera.

• Prestandaproblem: Om den primära regionen har prestandaproblem som påverkar tillgängligheten eller tillförlitligheten för dina händelsehubbar kan du åtgärda dessa problem genom att främja den sekundära regionen.

Testa ibland redundansmekanismer för att säkerställa att planen för affärskontinuitet är effektiv och att dina program smidigt kan växla till den sekundära regionen när det behövs.

Övervaka datareplikering

Du kan övervaka förloppet för replikeringsjobbet genom att kontrollera replikeringsfördröjningsmåttet i application metrics-loggarna.

• Aktivera programmåttloggar i ditt Event Hubs-namnområde genom att följa Övervaka Azure Event Hubs – Azure Event Hubs | Microsoft Learn.

• När du har aktiverat application metrics-loggar skapar och använder du data från namnområdet i några minuter innan du börjar se loggarna.

• Om du vill visa loggar för programmått går du till avsnittet Övervakning på sidan Händelsehubbar och väljer Loggar på den vänstra menyn. Använd följande fråga för att hitta replikeringsfördröjningen (i sekunder) mellan de primära och sekundära namnrymderna.

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

• Kolumnen count_d visar replikeringsfördröjningen i sekunder mellan den primära och sekundära regionen.

Publicera data

Publiceringsprogram kan skicka data till geo-replikerade namnområden via namnområdets värdnamn för det geo-replikeringsaktiverade namnområdet. Publiceringsmetoden är densamma som fallet med icke-geo-replikering. Du behöver inte göra några ändringar i SDK:er för dataplan eller klientprogram.

Händelsepublicering kanske inte är tillgänglig under följande omständigheter:

• När du har begärt befordran av en sekundär region avvisar den befintliga primära regionen alla nya händelser som publiceras till händelsehubben.
• När replikeringsfördröjningen mellan primära och sekundära regioner når den maximala replikeringsfördröjningen kan arbetsbelastningen för utgivarens ingress begränsas.

Publisher-program kan inte komma åt några namnområden direkt i de sekundära regionerna.

Datakonsumtion

Dataförbrukande applikationer kan förbruka data med hjälp av värdnamnet för ett namnområde där geo-replikeringsfunktionen är aktiverad. Konsumentåtgärder stöds inte från det ögonblick då kampanjen startar förrän kampanjen har slutförts.

Kontrollpunkts- och förskjutningshantering

Händelseförbrukande program kan upprätthålla offsethantering på samma sätt som med ett icke-geo-replikerat namnområde. Namnområden med geo-replikering behöver inte någon särskild hantering för offset.

Kafka

Konsumenter genomför förskjutningar direkt till Event Hubs och systemet replikerar förskjutningar mellan regioner. Därför kan konsumenterna börja konsumera där de slutade i den primära regionen.

Här är en lista över Apache Kafka-klienter som stöds:

För andra bibliotek beror stödet på API-versionen:

Event Hubs SDK och AMQP

För AMQP hanterar användarna kontrollpunkten med hjälp av ett kontrollpunktslager, till exempel Azure Blob Storage eller en anpassad lagringslösning. Om det sker en redundansväxling måste den sekundära regionen ha kontrollpunktslagret så att klienter kan hämta kontrollpunktsdata och undvika förlust av meddelanden.

Den senaste versionen av Event Hubs SDK innehåller ändringar i kontrollpunktsrepresentationen för att stödja redundansväxlingar. Använd de senaste versionerna av SDK:erna, men tidigare versioner av följande SDK:er stöds också.

Överväganden

Tänk på följande faktorer:

• Tänk på tidsfaktorn i din planering för befordran. Om du till exempel förlorar anslutningen i mer än 15 till 20 minuter kan du välja att starta upphöjningen.
• Du bör öva på att främja en komplex distribuerad infrastruktur minst en gång.

Prissättning

Prissättningen varierar beroende på vilken nivå du väljer, men har vanligtvis två parametrar:

• Beräkningsavgiften för klustret eller namnområdet.
• Bandbreddsavgiften för data som replikeras mellan de primära och sekundära regionerna.

Dedikerade kluster

När du använder geo-replikering med event hubs-dedikerade kluster behöver du minst två dedikerade kluster i separata regioner. Du kan använda dessa kluster för att vara värd för andra namnområden än de som geo-replikeras. Du betalar för dessa dedikerade kluster separat baserat på antalet kapacitetsenheter (CUS) som allokerats till var och en.

När du aktiverar geo-replikering är den enda extra kostnaden bandbreddsavgiften för data som replikeras från primär till sekundär. Den här avgiften beror på platsen för den primära regionen.

Premium-namnområden

När du aktiverar geo-replikering för Premium-namnområden får du samma antal bearbetningsenheter (PUs) i den sekundära regionen. Du betalar för antalet PUs som du använder och bandbredden för de data som överförs mellan den primära och sekundära regionen.

Om du till exempel aktiverar geo-replikering på Premium-namnområde som du har etablerat med 4 PU:er, betalar du för

• 4 PUs i den primära regionen,
• 4 PUs i den sekundära regionen,
• Avgift för geo-replikering per GB data som replikeras.

Du betalar bandbreddsavgifter baserat på de data som överförs mellan de primära och sekundära regionerna.

Prismätare

Prismätare för bandbreddsavgiften för geo-replikeringsdataöverföring visas med följande information:

Privata slutpunkter

Det här avsnittet innehåller ytterligare överväganden när du använder geo-replikering med namnområden som använder privata slutpunkter. Allmän information om hur du använder privata slutpunkter med Event Hubs finns i Integrera Azure Event Hubs med Azure Private Link.

När du implementerar geo-replikering för ett Event Hubs-namnområde som använder privata slutpunkter skapar du privata slutpunkter för både de primära och sekundära regionerna. Konfigurera dessa slutpunkter mot virtuella nätverk som är värdar för både primära och sekundära instanser av ditt program. Om du till exempel har två virtuella nätverk, VNET-1 och VNET-2, måste du skapa två privata slutpunkter i Event Hubs-namnområdet med hjälp av undernät från VNET-1 respektive VNET-2. Konfigurera de virtuella nätverken med peering mellan regioner så att klienterna kan kommunicera med någon av de privata slutpunkterna. Slutligen hanterar du DNS så att alla klienter får DNS-information som pekar namnområdesslutpunkten (namespacename.servicebus.windows.net) till IP-adressen för den privata slutpunkten i den aktuella primära regionen.

Den här metoden ger fördelen att failover kan ske oberoende i programlagret eller i Event Hubs-namnområdet:

• Programbaserad redundans: I det här scenariot flyttas programmet från VNET-1 till VNET-2. Eftersom privata slutpunkter konfigureras på både VNET-1 och VNET-2 för både primära och sekundära namnområden fortsätter programmet att fungera sömlöst.
• Redundansväxling endast för Event Hubs-namnrymd: Om redundansväxlingen endast sker på Event Hubs-namnområdesnivå förblir programmet i drift eftersom privata slutpunkter har konfigurerats i båda de virtuella nätverken.

Genom att följa dessa riktlinjer kan du säkerställa robusta och tillförlitliga redundansmekanismer för dina Event Hubs-namnområden som använder privata slutpunkter.

Relaterat innehåll

Mer information om hur du använder geo-replikeringsfunktionen finns i Använda geo-replikering.