Översikt över geo-replikering
För programutvecklare och IT-tekniker är ett vanligt mål att skapa och köra motståndskraftiga program. Återhämtning definieras som programmets förmåga att reagera på fel och fortfarande vara funktionell. För att uppnå motståndskraft mot regionala fel i molnet är det första steget att skapa redundans för att undvika en enskild felpunkt. Den här redundansen kan uppnås med geo-replikering.
Med App Configuration geo-replikeringsfunktion kan du replikera konfigurationsarkivet efter betrodd till de regioner som 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 Origin. Det går inte att ta bort ursprunget, men fungerar annars som vilken replik som helst.
Du kan ändra eller uppdatera dina nyckelvärden i valfri replik. Dessa ändringar synkroniseras med alla andra repliker efter en eventuell konsekvensmodell.
Replikering av konfigurationsarkivet medför följande fördelar:
- Ökad återhämtning för Azure-avbrott: Vid ett regionalt avbrott påverkas repliker individuellt. Om en region har ett avbrott kommer alla repliker som finns i opåverkade regioner fortfarande att vara 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 funktioner för automatisk redundans via App Configuration konfigurationsproviders. 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.
- Omdistribution 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ärandegränser. Om dina program till exempel körs i flera regioner och endast skickar begäranden till en region kan du börja uttömma App Configuration begärandegränser. 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 begärandegränser som är lika stora som ursprungets begärandegränser. 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 konfigurationsarkiv, 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 ditt arkiv refererar du till instruktioner för att aktivera geo-replikeringsdokument.
Exempel på användningsfall
Ett utvecklarteam skapar ett system som består av flera program och har för närvarande en Azure App Configuration butik i regionen USA, västra. Användningen av deras system växer snabbt och de vill skala och uppfylla sina kundbehov i: Sverige, centrala, USA, västra, Europa, norra och Asien, östra. Alla program de har använder för närvarande konfigurationsarkivet i USA, västra, vilket skapar en enda 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. Dessutom begränsas alla program globalt 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 kommer att köras. Sedan kan deras program skicka begäranden till en replik i samma region i stället för alla program som skickar begäranden till USA, västra. 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. Genom att ha flera repliker kan teamet dessutom konfigurera sina program för redundansväxling vid ett regionalt avbrott. Teamet kan till exempel konfigurera program som körs i Sverige, centrala för att hämta konfigurationen från den regionen, men återställning till Europa, norra om Sverige central drabbas av ett avbrott. Även om App Configuration inte är tillgänglig i en viss region påverkas inte teamets system.
Överväganden
- Geo-replikering är inte tillgängligt på den kostnadsfria nivån.
- Varje replik har gränser, enligt beskrivningen på sidan App Configuration prissättning. Dessa gränser är isolerade per replik.
- Azure App Configuration har även stöd för Azure-tillgänglighetszoner för att skapa ett motståndskraftigt och högtillgä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 konfigurationslager.
Kostnad och fakturering
Varje replik som skapas lägger till extra avgifter. Mer information finns på sidan App Configuration prissättning. Om ditt ursprung till exempel är ett standardnivåkonfigurationslager 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 replikeringssvarstidsmåttet och andra App Configuration mått finns i Övervakning App Configuration datareferens.