Översikt över geo-replikering

För programutvecklare och IT-tekniker är ett gemensamt mål att skapa och köra motståndskraftiga program. Återhämtning definieras som programmets förmåga att reagera på fel och fortfarande fungera. För att uppnå motståndskraft mot regionala fel i molnet är det första steget att skapa redundans för att undvika en enda felpunkt. Den här redundansen kan uppnås med geo-replikering.

App Configurations geo-replikeringsfunktion låter dig fritt replikera din konfigurationsbutik till de regioner du väljer. Varje ny replik kommer att finnas i en annan region och skapar en ny slutpunkt för dina program att skicka begäranden till. Den ursprungliga slutpunkten för konfigurationsarkivet kallas Ursprung. Det går inte att ta bort ursprunget, men i annat fall fungerar det som vilken replik som helst.

Du kan ändra eller uppdatera dina nyckelvärden i vilken som helst replik. Dessa ändringar synkroniseras med alla andra repliker enligt en modell för eventualkonsistens.

Om du replikerar konfigurationsarkivet får du följande fördelar:

• Ökad motståndskraft vid Azure-avbrott: Vid ett regionalt avbrott påverkas replikerna individuellt. Om en region har ett avbrott är alla repliker som finns i opåverkade regioner fortfarande tillgängliga och synkroniseras kontinuerligt. När avbrottet har åtgärdats synkroniseras alla berörda repliker till det senaste tillståndet. Observera att geo-replikering endast erbjuder automatiska failover-funktioner via App Configurations konfigurationsleverantörer. Annars kan du också skapa egna anpassade redundansmekanismer i programmets konfiguration för att växla mellan olika replikslutpunkter för att minska effekten av ett Azure-avbrott.
• Omfördelning av begärandegränser: Du kan anpassa i kod vilken replikslutpunkt ditt program använder så att du kan distribuera din begärandebelastning för att undvika uttömning av begärandebegränsningar. Om dina program till exempel körs i flera regioner och endast skickar begäranden till en region kan du börja överskrida gränserna för appkonfigurationsbegäran. Du kan hjälpa till att omdistribuera den här belastningen genom att skapa repliker i de regioner som dina program körs i. Varje replik har isolerade gränser för begäranden, lika stora som ursprungsbegärandegränserna. Uttömning av begärandegränserna i en replik påverkar inte begärandegränserna i en annan replik.
• Regional indelning: Åtkomst till flera regioner kan förbättra svarstiden mellan ditt program och konfigurationsarkivet, vilket leder till snabbare svar på begäranden och bättre prestanda om ett program skickar begäranden till sin närmaste replik. Om du anger replikåtkomst kan du också begränsa datalagring och flöde mellan olika regioner baserat på dina inställningar.

Om du vill aktivera den här funktionen i din butik, se instruktionerna för att aktivera geo-replikering.

Exempel på användningsfall

Ett utvecklarteam skapar ett system som består av flera program och har för närvarande ett Azure App Configuration-lager i regionen USA, västra. Användningen av deras system växer snabbt och de vill skala och uppfylla sina kundbehov i: Sverige Centrala, Västra USA, Norra Europa och Östasien. Alla applikationer de har använder för närvarande konfigurationslagret West US, vilket skapar en risk för en central felpunkt. Om det uppstod ett regionalt avbrott i USA, västra och de inte hade några andra redundansmekanismer eller standardbeteenden, skulle deras system vara otillgängligt för kunder. Globalt är alla program för närvarande begränsade av begärandegränsen för ett konfigurationslager. När teamet skalar till fler regioner blir den här gränsen ohållbar.

Det här teamet skulle ha nytta av geo-replikering. De kan skapa en replik av konfigurationsarkivet i varje region där deras program körs. Sedan kan deras program skicka begäranden till en replik i samma region, i stället för att alla program skickar begäranden till Västra USA. Detta ger två fördelar: förbättrad svarstid för begäranden och bättre belastningsfördelning. Om du har en väl distribuerad begärandebelastning kan du undvika överbelastning av begärandekvoten. Dessutom kan teamet konfigurera sina program så att de redundansväxlar vid ett regionalt avbrott med flera repliker. Teamet kan till exempel konfigurera program som körs i Sverige Centrala för att hämta konfigurationen från den regionen, men falla tillbaka på norra Europa om Sverige Centrala drabbas av ett avbrott. Även om appkonfigurationen inte är tillgänglig i en viss region påverkas inte teamets system.

Överväganden

• Geo-replikering är inte tillgängligt på nivåerna Kostnadsfri och Utvecklare.
• Varje replik har gränser, enligt beskrivningen på prissida för App Configuration. Dessa gränser är isolerade per replik.
• Azure App Configuration har också stöd för Azure-tillgänglighetszoner för att skapa ett motståndskraftigt och mycket tillgängligt lager i en Azure-region. Stöd för tillgänglighetszoner ingår automatiskt för en replik om replikens region har stöd för tillgänglighetszoner. Kombinationen av tillgänglighetszoner för redundans i en region och geo-replikering i flera regioner förbättrar både tillgängligheten och prestandan för ett konfigurationsarkiv.

Kostnad och fakturering

Varje replik som skapas lägger till extra avgifter. Mer information finns på sidan appkonfigurationspriser . Om ditt ursprung till exempel är ett konfigurationslager på standardnivå och du har fem repliker debiteras du priset för sex standardnivåkonfigurationslager för systemet, men var och en av replikens isolerade kvot och begäranden ingår i den här avgiften.

Övervakning

För att ge insikter om egenskaperna för geo-replikeringsfunktionen tillhandahåller App Configuration ett mått med namnet Replikeringssvarstid. Replikeringssvarstidsmåttet beskriver hur lång tid det tar för data att replikeras från en region till en annan.

Mer information om måttet för replikeringssvarstid och andra appkonfigurationsmått finns i Referens för övervakning av appkonfigurationsdata.

Nästa steg

Återhämtning och haveriberedskap