Tillförlitlighet i Azure App Configuration

Azure App Configuration lagrar och hanterar inställningar för programkonfiguration och funktionsflaggor centralt, vilket ersätter konfigurationsfiler som är inbäddade direkt i program. Med den här metoden kan du dynamiskt uppdatera konfigurationsvärden, spåra versionshistorik och underhålla en post med konfigurationsändringar över tid. Tillgängligheten och tillförlitligheten för App Configuration är viktiga överväganden eftersom programmets beteende kan vara direkt beroende av åtkomst till konfigurationsdata vid körning.

När du använder Azure är reliability ett delat ansvar. Microsoft tillhandahåller en rad funktioner som stöder återhämtning och återställning. Du ansvarar för att förstå hur dessa funktioner fungerar inom alla tjänster som du använder och välja de funktioner du behöver för att uppfylla dina affärsmål och drifttidsmål.

Den här artikeln beskriver tillförlitlighetsarkitekturen för App Configuration och hur tjänsten är utformad för att förbli tillgänglig vid tillfälliga fel, fel i tillgänglighetszonen och regionfel.

Rekommendationer för produktionsdistribution för tillförlitlighet

För de flesta produktionsdistributioner av App Configuration bör du överväga följande rekommendationer:

En lista över rekommenderade metoder och konfigurationer för produktionsarbetsbelastningar finns i Skapa program med hög återhämtning.

Översikt över tillförlitlighetsarkitektur

När du distribuerar App Configuration distribuerar du en butik. Ditt lager innehåller olika typer av inställningar som ditt program kan använda, inklusive nycklar och värden och funktionsflaggor. Tjänsten innehåller även inbyggda funktioner för att organisera, skydda, versionshantering och distribuera konfigurationsändringar på ett säkert sätt i olika miljöer. Mer information finns i Vad är appkonfiguration?

AppKonfiguration är en fullständigt hanterad tjänst. Microsoft ansvarar för underhåll av tjänsten och lagring och hantering av dina inställningar.

När du skapar klientprogram som ansluter till App Configuration kan du använd appkonfiguration med Azure Front Door (förhandsversion) för att aktivera cachelagring och global trafikacceleration. Den här konfigurationen introducerar ytterligare överväganden för geo-replikering, som är tydligt markerade i den här artikeln där det är relevant.

Motståndskraft mot tillfälliga fel

Tillfälliga fel är kortvariga, intermittenta fel i komponenter. De förekommer ofta i en distribuerad miljö som molnet, och de är en normal del av åtgärderna. Tillfälliga fel korrigerar sig själva efter en kort tidsperiod. Det är viktigt att dina program kan hantera tillfälliga fel, vanligtvis genom att försöka igen.

Alla molnbaserade program bör följa vägledningen för Azure övergående felhantering när de kommunicerar med molnbaserade API:er, databaser och andra komponenter. Mer information finns i Rekommendationer för hantering av tillfälliga fel.

När du använder App Configuration bör du överväga följande metodtips för att minimera effekten av tillfälliga fel på konfigurationsåtkomst, särskilt inom kritiska kodsökvägar.

• Konfigurationsproviders: Använd appkonfigurationsprovidrar som har inbyggda funktioner för återförsök och cachelagring och andra återhämtningsfunktioner.

• Azure-SDK:er: Använd SDK:er för appkonfiguration om programmet behöver skicka skrivbegäranden. SDKer försöker automatiskt på nytt vid HTTP-svar med statuskod 429 och andra tillfälliga fel.

• Försök med logik igen: Inkludera logik för återförsök i anpassade klienter om du inte kan använda appkonfigurationsproviders eller SDK:er. Rubriken retry-after-ms i svaret ger en föreslagen väntetid i millisekunder innan klienten försöker skicka begäran igen.

• Cache: Cacheinställningar i minnet om möjligt för att minska direkta förfrågningar till din butik.

Andra riktlinjer för programkonfiguration finns i Vanliga frågor och svar om appkonfiguration.

Motståndskraft mot fel i tillgänglighetszonen

Tillgänglighetszoner är fysiskt separata grupper av datacenter i en Azure region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

Appkonfiguration ger automatiskt zonredundans i regioner som stöder tillgänglighetszoner. Den här redundansen ger hög tillgänglighet inom en region utan att det krävs någon specifik konfiguration.

När en tillgänglighetszon blir otillgänglig omdirigerar App Configuration automatiskt dina begäranden till andra felfria tillgänglighetszoner för att säkerställa hög tillgänglighet.

Kravspecifikation

Regionstöd: Butiker som distribueras till följande regioner är automatiskt zonredundanta.

Kostnad

Det finns ingen extra kostnad för zonredundans för App Configuration.

Konfigurera stöd för tillgänglighetszoner

Microsoft konfigurerar automatiskt zonredundans för ett lagringsutrymme när det finns i en region som stöder tillgänglighetszoner.

Om App Configuration lägger till stöd för tillgänglighetszoner i en befintlig region behöver du inte vidta några åtgärder för att dra nytta av tillgänglighetszonens stöd. Din butik drar nytta av det stöd för tillgänglighetszoner som blir tillgängligt för App Configuration-butiker i regionen.

Beteende när alla zoner är felfria

I det här avsnittet beskrivs vad du kan förvänta dig när du har ett zonredundant appkonfigurationsarkiv och alla zoner är i drift.

• Gränsöverskridande zonoperationer: App Configuration hanterar automatiskt trafikroutning mellan tillgänglighetszoner. Under normala åtgärder distribueras begäranden transparent mellan zoner.

• Datareplikering mellan zoner: I regioner som stöder zoner replikerar App Configuration synkront data mellan tillgänglighetszoner. Den här replikeringen säkerställer att inställningarna förblir konsekventa och tillgängliga även om en zon blir otillgänglig.

Beteende vid ett zonfel

Det här avsnittet beskriver vad du kan förvänta dig när du har ett zonredundant appkonfigurationsarkiv och det uppstår ett avbrott i någon av zonerna.

• Identifiering och svar: App Configuration Service identifierar zonfel och svarar automatiskt på dem. Du behöver inte vidta några åtgärder under ett zonfel.

• Notification: Microsoft meddelar dig inte automatiskt när en zon är nere. Du kan dock använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella zonfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.

• Aktiva begäranden: Under ett zonfel kan den berörda zonen misslyckas med att hantera begäranden under flygning, vilket kräver att klientprogram försöker igen. Klientprogram bör följa tillfälliga metoder för felhantering för att säkerställa att de kan försöka begäranden igen om ett zonfel inträffar.

• Förväntad dataförlust: Ingen dataförlust förväntas vid ett zonfel på grund av den synkrona replikeringen mellan zoner.

• Förväntad stilleståndstid: Ingen stilleståndstid förväntas.

• Omfördelning: App Configuration omdirigerar automatiskt trafik från den berörda zonen till felfria zoner utan att kunden behöver ingripa.

Zonåterställning

När en tidigare otillgänglig zon återställs återställer App Configuration automatiskt normala åtgärder i alla tillgänglighetszoner. Du behöver inte vidta några åtgärder för att återställa från ett zonfel.

Test för zonfel

Appkonfigurationsplattformen hanterar trafikroutning, failover, och zonåterställning för zonredundanta tjänster. Microsoft hanterar den här processen fullständigt, så du behöver inte verifiera felprocesser i tillgänglighetszonen.

Motståndskraft mot regionomfattande fel

AppKonfiguration ger inbyggda geo-replikeringsfunktioner för att stödja motståndskraft vid regionala avbrott. Med geo-replikering kan konfigurationsdata replikeras mellan regioner som en hanterad tjänstfunktion.

Geo-replication

Med geo-replikering kan du replikera ett arkiv i flera Azure regioner. Varje butik kan ha flera repliker i olika regioner. Den ursprungliga butiken är också en replik. Den här funktionen hjälper till att skydda program mot störningar i hela regionen.

Kravspecifikation

• Region support: Du kan skapa repliker i valfri Azure region som App Configuration stöder, även om regionerna inte är Azure parkopplade regioner.

• Nivå: Konfigurationsarkivet måste använda en nivå som stöds för att aktivera geo-replikering. Mer information finns i Aktivera geo-replikering.

Överväganden

När du aktiverar geo-replikering bör du tänka på följande faktorer:

• Zonredundanta repliker: Alla repliker som du skapar i en region där App Configuration stöder tillgänglighetszoner är automatiskt zonredundanta.

• Azure Front Door: Konfigurera appkonfigurationsrepliker som ursprung i en ursprungsgrupp om du vill aktivera geo-redundant konfigurationsleverans med Azure Front Door. Korrekt konfigurerade ursprung krävs för att Azure Front Door ska kunna utföra hälsobaserad routning, belastningsutjämning och automatisk redundans mellan regioner. Mer information finns i Trafikroutningsmetoder till ursprung.

Kostnad

Varje geo-replikerad region faktureras separat enligt prissättningen för respektive nivå och region. Inga avgifter för utgående data gäller för replikering mellan regioner. Prisinformation finns i Priser för appkonfiguration.

Konfigurera stöd för flera regioner

Information om hur du konfigurerar replikering för ett nyligen skapat konfigurationsarkiv finns i Aktivera geo-replikering.

Beteende när alla regioner är felfria

I det här avsnittet beskrivs vad du kan förvänta dig när du konfigurerar ett appkonfigurationsarkiv för geo-replikering och alla regioner är i drift.

• Åtgärd mellan zoner: Varje replik kan adresseras individuellt och har ett eget DNS-namn (Domain Name System). Alla kopior kan acceptera både läs- och skrivoperationer.

  Appkonfiguration dirigerar inte automatiskt trafik mellan regioner. När du använder konfigurationsproviders för appkonfiguration kan programmet välja att använda automatisk replikidentifiering. Du kan också ange en prioriterad lista över repliker och App Configuration väljer den första felfria repliken. Med den här metoden kan ditt program styra vilken replik det använder.

  Anmärkning

  Om du använder Azure Front Door är trafikdirigeringsbeteendet annorlunda. Mer information finns i Redundans och belastningsutjämning.

• Datareplikering mellan zoner: Data replikeras asynkront och är så småningom konsekventa. Du kan använda måttet replication latency i Azure Monitor för att övervaka den aktuella replikeringsfördröjningen mellan repliker.

Beteende under ett regionfel

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar ett appkonfigurationsarkiv för geo-replikering och det uppstår ett avbrott i någon av replikregionerna.

• Detection och svar: Microsoft ansvarar för att identifiera region- eller replikfel och initiera återställningsprocesser.

  När du använder App Configuration-konfigurationsproviders med automatisk replikidentifiering eller en lista över flera repliker, detekterar applikationen automatiskt fel och växlar över till en felfri replik.

  Om du inte använder Appkonfigurationsprovidrar ansvarar du för att växla över din applikation till en fungerande replik.

• Notification: Microsoft meddelar dig inte automatiskt när en region är nere. Du kan dock använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella regionfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.

• Aktiva begäranden: Aktiva begäranden mot en replik i regionen kan misslyckas. Klientprogram bör försöka begäranden mot en annan replik igen.

• Förväntad dataförlust: Om en replik misslyckas kanske de senaste ändringarna som gjorts på repliken ännu inte replikeras till andra repliker. Dessa ändringar kan förbli otillgängliga tills repliken återställs. Om du vill beräkna potentiell dataförlust övervakar du måttet replication latency i Azure Monitor.

• Förväntad stilleståndstid: När en replik blir otillgänglig förblir den offline tills dess region återställs. Andra kopior fortsätter att hantera begäranden. Program kan uppleva korta driftstopp medan de identifierar felet och växlar till en felfri replik. Varaktigheten beror på hur snabbt varje applikation utför den här identifieringen och failoverprocessen.

• Omfördelning: Program måste dirigera trafik till en felfri replik när ett fel inträffar.

  Om du använder konfigurationsleverantörer för App Configuration hanterar leverantörerna automatiskt replikval och felövergång.

  Om du placerar Azure Front Door framför ditt datalager och konfigurerar ursprungsgruppen med flera repliker som ursprung för failover, omdirigerar Azure Front Door automatiskt begäranden till en frisk replik.

Regionåterställning

När regionen har återställts synkroniserar App Configuration repliken med de andra replikerna utan ditt ingripande.

Du ansvarar för att konfigurera om programmet för att dirigera trafik tillbaka till den återställda regioninstansen. Applikationer som använder appkonfigurationsleverantörer börjar automatiskt använda replikan igen.

Test för regionfel

Du kan inte simulera en replikredundans direkt i App Configuration. Men eftersom program styr replikval kan du testa redundansbeteendet genom att tvinga programmet till ett tillstånd där det måste växla repliker.

Om du vill verifiera programmets redundansbeteende för replikering kan du införa ett kontrollerat anslutningsfel i en icke-produktionsmiljö och se hur programmet svarar.

En metod är att använda din lokala dator eller en annan miljö där du har administrativ åtkomst. Följ de här stegen:

1. Aktivera utförlig loggning för Azure SDKs. I .NET använder du klassen AzureEventSourceListener för att konfigurera en logger. Mer information finns i Loggning och övervakning.

2. Konfigurera hosts filen manuellt så att begäranden till appkonfigurationsarkivet dirigeras till en IP-adress som inte kan ta emot dem, till exempel 127.0.0.1 (localhost).

   Varning

   Det här steget blockerar effektivt åtkomsten från datorn till din appkonfiguration butik. Följ endast dessa steg i en icke-produktionsmiljö.

3. Övervaka loggarna för ett meddelande som liknar följande exempel:

   [Warning] Microsoft-Extensions-Configuration-AzureAppConfiguration-Refresh:
   Failed to get configuration settings from endpoint 'https://myappconfigstore.azconfig.io'. Failing over to endpoint https://myappconfigstore-eus.azconfig.io'.
   

   Det här meddelandet anger att programmet har växlat över för att använda en annan replik av ditt lager.

4. När du har slutfört testet ångrar du ändringarna hosts i filen.

Säkerhetskopiering och återställning

Du kan använda App Configuration för att exportera konfigurationsdata från ett arkiv och använda dem som en del av en bredare säkerhetskopieringsstrategi.

För de flesta lösningar bör du inte enbart förlita dig på säkerhetskopior. Använd i stället de andra funktionerna som beskrivs i den här guiden för att stödja dina återhämtningskrav. Säkerhetskopior skyddar dock mot vissa risker som andra metoder inte gör. Mer information finns i Vad är redundans, replikering och säkerhetskopiering?.

Motståndskraft mot oavsiktlig borttagning

AppKonfiguration innehåller två viktiga återställningsfunktioner för att förhindra oavsiktlig eller skadlig borttagning:

• Mjuk borttagning: När du aktiverar mjuk borttagning kan du återställa borttagna butiker och inställningar under en konfigurerbar kvarhållningsperiod. Mjuk borttagning fungerar som en papperskorg för dina appkonfigurationsresurser.

• Rensningsskydd: När du aktiverar rensningsskydd förhindrar tjänsten permanent borttagning av ditt arkiv och dess inställningar tills kvarhållningsperioden förflutit. Det här skyddet förhindrar att skadliga aktörer permanent förstör dina inställningar.

Använd båda funktionerna för produktionsmiljöer. Mer information finns i Skydd mot mjuk borttagning och rensning.

Motståndskraft mot serviceunderhåll

Microsoft utför regelbundet tjänstuppdateringar och annat underhåll. Tjänsten hanterar dessa aktiviteter automatiskt, vilket gör underhållet sömlöst och transparent för dig. Ingen stilleståndstid förväntas under underhållshändelser om inte Azure Service Health tillhandahåller ett meddelande om planerat underhåll.

Motståndskraft mot konfigurationsproblem

Felaktiga eller oavsiktliga konfigurationsändringar kan orsaka programavbrott. Använd konfigurationsögonblicksbilder för att på ett säkert sätt distribuera ändringar i konfigurationen. Övervaka programmets hälsotillstånd efter eventuella konfigurationsändringar och återgå till den senaste kända konfigurationsögonblicksbilden om ändringarna medför ett problem.

Serviceavtal

Serviceavtalet (SLA) för Azure tjänster beskriver den förväntade tillgängligheten för varje tjänst och de villkor som din lösning måste uppfylla för att uppnå den tillgänglighetsförväntningen. Mer information finns i SLAs for online služby.

Relaterat innehåll

• Reliability i Azure
• Dokumentation om App Configuration