Dela via

Tillförlitlighet i Azure Blob Storage

Azure Blob Storage är en objektlagringslösning för molnet från Microsoft. Den är utformad för att lagra enorma mängder ostrukturerade data, till exempel text, binära data, dokument, mediefiler och programsäkerhetskopior. Som en grundläggande Azure Storage-tjänst tillhandahåller Blob Storage flera tillförlitlighetsfunktioner för att säkerställa att dina data förblir tillgängliga och hållbara under både planerade och oplanerade händelser.

Blob Storage stöder inbyggda redundansmekanismer som lagrar flera kopior av dina data i olika feldomäner. Den innehåller omfattande redundansalternativ som omfattar distribution av tillgänglighetszoner med zonredundant lagring (ZRS), skydd i flera regioner via geo-redundanta konfigurationer och avancerade redundansfunktioner.

I den här artikeln beskrivs tillförlitlighetsstöd i Blob Storage samt Blob Storage med ett hierarkiskt namnområde (Azure Data Lake Storage Gen2). Ämnena omfattar tillgänglighetszoner, distributioner i flera regioner och säkerhetskopior.

När du använder Azure är tillförlitlighet ett delat ansvar. Microsoft tillhandahåller en rad funktioner för att stödja å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.

Anmärkning

Blob Storage är en del av Azure Storage-plattformen. Vissa av funktionerna i Blob Storage är vanliga i många Azure Storage-tjänster. I den här artikeln använder vi Azure Storage för att referera till dessa funktioner.

Rekommendationer för produktionsdistribution

Mer information om hur du distribuerar Blob Storage för att stödja din lösnings tillförlitlighetskrav och hur tillförlitlighet påverkar andra aspekter av din arkitektur finns i Metodtips för arkitektur för Blob Storage i Azure Well-Architected Framework.

Översikt över tillförlitlighetsarkitektur

Azure Storage innehåller flera redundansalternativ som hjälper dig att skydda dina data mot olika typer av fel. Varje alternativ ger en specifik nivå av dataredundans, så att du kan välja den nivå som bäst matchar programmets krav.

Lokalt redundant lagring (LRS) replikerar data i dina lagringskonton till en eller flera Azure-tillgänglighetszoner som finns i den primära regionen som du väljer. Även om det inte finns något alternativ för att välja önskad tillgänglighetszon kan Azure flytta eller expandera LRS-konton mellan zoner för att förbättra belastningsutjämningen. Det finns ingen garanti för att dina data sprids över zoner. Mer information om tillgänglighetszoner finns i Vad är tillgänglighetszoner?.

Diagram som visar hur data replikeras i tillgänglighetszoner med hjälp av LRS.

Zonredundant lagring (ZRS), geo-redundant lagring (GRS) och geo-zonredundant lagring (GZRS) ger extra skydd. I den här artikeln beskrivs de här alternativen i detalj.

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 tillfälliga felhantering i Azure när de kommunicerar med molnbaserade API:er, databaser och andra komponenter. Mer information finns i Rekommendationer för hantering av tillfälliga fel.

Implementera följande rekommendationer för att effektivt hantera tillfälliga fel när du använder Blob Storage:

  • Använd Azure Storage-klientbiblioteken, som innehåller inbyggda återförsöksprinciper med exponentiell backoff och jitter. SDK:erna för .NET, Java, Python och JavaScript hanterar automatiskt återförsök för tillfälliga fel. Mer information om konfigurationsalternativ för återförsök finns i Implementera en återförsöksprincip med .NET.

  • Konfigurera lämpliga tidsgränsvärden för dina blobåtgärder baserat på blobstorlek och nätverksvillkor. Större blobar kräver längre tidsgränser, men mindre åtgärder kan använda kortare värden för att snabbt identifiera fel.

Stöd för tillgänglig zon

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

Blob Storage ger robust stöd för tillgänglighetszoner via ZRS-konfigurationer som automatiskt distribuerar dina data över flera tillgänglighetszoner i en region. Till skillnad från lokalt redundant lagring (LRS) garanterar ZRS att Azure synkront replikerar dina blobdata över flera tillgänglighetszoner. ZRS säkerställer att dina data förblir tillgängliga även om en zon upplever ett avbrott.

Zonredundans aktiveras på lagringskontonivå och gäller för alla blobcontainrar i det kontot. Du kan inte ange olika redundansnivåer för enskilda containrar. Redundanskonfigurationen tillämpas på hela lagringskontot. När en tillgänglighetszon drabbas av ett avbrott dirigerar Azure Storage automatiskt begäranden till felfria zoner utan att du eller ditt program behöver göra något.

Diagram som visar hur data replikeras i den primära regionen med zonredundant lagring (ZRS).

Stöd för regioner

Du kan distribuera zonredundanta Azure Storage-konton i alla regioner som har stöd för tillgänglighetszoner.

Kravspecifikation

Zonredundans är tillgängligt för både Standard generell användning v2 och Premium Block Blob Storage-kontotyper. Blockblobar, tilläggsblobar och sidblobbar stöder alla zonredundanta konfigurationer, men den typ av lagringskonto som du använder avgör vilka funktioner som är tillgängliga. Mer information finns i Lagringskontotyper som stöds.

Kostnad

När du aktiverar zonredundant lagring (ZRS) debiteras du med en annan hastighet än lokalt redundant lagring (LRS) på grund av extra replikering och lagringsutrymme.

Mer information finns i Priser för Blob Storage.

Konfigurera stöd för tillgänglighetszoner

  • Skapa ett bloblagringskonto med zonredundans. Information om hur du skapar ett nytt lagringskonto med ZRS finns i Skapa ett lagringskonto och välj ZRS, geo-zonredundant lagring (GZRS) eller geo-redundant lagring med läsbehörighet (RA-GZRS) som redundansalternativ när kontot skapas.

  • Ändra replikeringstyp. Information om hur du ändrar ett befintligt lagringskonto till zonredundant lagring (ZRS) och om konfigurationsalternativ och krav finns i Ändra hur ett lagringskonto replikeras.

  • Inaktivera zonredundans. Konvertera ZRS-konton tillbaka till en icke-zonbaserad konfiguration, till exempel lokalt redundant lagring (LRS), med samma ändringsprocess för redundanskonfiguration.

Normala åtgärder

Det här avsnittet beskriver vad du kan förvänta dig när ett bloblagringskonto har konfigurerats för zonredundans och alla tillgänglighetszoner används.

  • Trafikroutning mellan zoner: Azure Storage med zonredundant lagring (ZRS) distribuerar automatiskt begäranden mellan lagringskluster i flera tillgänglighetszoner. Trafikdistributionen är transparent för program och kräver ingen konfiguration på klientsidan.

  • Datareplikering mellan zoner: Alla skrivåtgärder till ZRS replikeras synkront i alla tillgänglighetszoner i regionen. När du laddar upp eller ändrar data anses åtgärden inte vara slutförd förrän data har replikerats i alla tillgänglighetszoner. Den här synkrona replikeringen säkerställer stark konsistens och noll dataförlust vid zonfel.

Avslappningsupplevelse

Det här avsnittet beskriver vad du kan förvänta dig när ett bloblagringskonto har konfigurerats för ZRS och det uppstår ett avbrott i tillgänglighetszonen.

  • Identifiering och svar: Microsoft identifierar automatiskt zonfel och initierar återställningsprocesser. Ingen kundåtgärd krävs för ZRS-konton (zonredundant lagring).

    Om en zon blir otillgänglig utför Azure nätverksuppdateringar, till exempel DNS-ompunktning (Domain Name System).

  • Meddelande: Azure Storage meddelar dig inte när en zon är nere. Du kan dock använda Azure Resource Health för att övervaka hälsotillståndet för ditt lagringskonto. Du kan också använda Azure Service Health för att förstå den övergripande hälsan för Azure Storage-tjänsten, inklusive eventuella zonfel.

    Konfigurera aviseringar för dessa tjänster för att ta emot meddelanden om problem på zonnivå. Mer information finns i Skapa Service Health-aviseringar i Azure-portalen och Skapa och konfigurera Resource Health-aviseringar.

  • Aktiva begäranden: Begäranden under flygning kan tas bort under återställningsprocessen och bör göras om. Program bör implementera logik för återförsök för att hantera dessa tillfälliga avbrott.

  • Förväntad dataförlust: Ingen dataförlust inträffar vid zonfel eftersom data replikeras synkront över flera zoner innan skrivåtgärderna slutförs.

  • Förväntad stilleståndstid: En liten mängd stilleståndstid, vanligtvis några sekunder, kan inträffa under automatisk återställning när trafiken omdirigeras till felfria zoner. När du utformar program för ZRS följer du metoder för tillfällig felhantering, inklusive implementering av återförsöksprinciper med exponentiell säkerhetskopiering.

  • Omdistribution av trafik: Om en tillgänglighetszon kopplas från initierar Azure nätverksändringar som DNS-ompunktering (Domain Name System). Dessa uppdateringar säkerställer att trafiken omdirigeras till återstående felfria tillgänglighetszoner. Tjänsten har fullständig funktionalitet med hjälp av de kvarvarande zonerna och kräver inte kundintervention.

Zonåterställning

När den misslyckade tillgänglighetszonen återställs återställer Azure Storage automatiskt normala åtgärder i alla tillgänglighetszoner. Tjänsten säkerställer automatiskt datakonsekvens genom att synkronisera alla åtgärder som inträffade under avbrottsperioden.

Testa för zonfel

När du använder zonredundant lagring (ZRS) hanterar Azure Storage replikering, trafikroutning och zon-down-svar automatiskt. Eftersom den här funktionen är helt hanterad behöver du inte initiera eller verifiera felprocesser i tillgänglighetszonen.

Stöd för flera regioner

Azure Storage, inklusive Azure Blob Storage, Azure Files, Azure Table Storage och Azure Queue Storage, tillhandahåller en rad geo-redundans- och redundansfunktioner som passar olika krav.

Viktigt!

Geo-redundant lagring (GRS) fungerar bara i länkade Azure-regioner. Om lagringskontots region inte är kopplad kan du överväga att använda alternativa metoder för flera regioner.

Replikering mellan parkopplade regioner

Azure Storage tillhandahåller flera typer av GRS i parkopplade regioner. Oavsett vilken typ av GRS du använder replikeras alltid data i den sekundära regionen med hjälp av lokalt redundant lagring (LRS). Den här metoden ger skydd mot maskinvarufel i den sekundära regionen.

  • Geo-redundant lagring med läsåtkomst (RA-GRS) och geozonredundant lagring med läsåtkomst (RA-GZRS) utökar geo-redundant lagring (GRS) och geo-zonredundant lagring (GZRS), med den extra fördelen med läsåtkomst till den sekundära slutpunkten. Dessa alternativ är idealiska för program som är utformade för affärskritiska program med hög tillgänglighet. I det osannolika fallet att den primära slutpunkten upplever ett avbrott kan program som konfigurerats för läsåtkomst till den sekundära regionen fortsätta att fungera.

Redundanstyper

Azure Storage har stöd för tre typer av redundans för olika scenarier.

  • Kundhanterad oplanerad redundans: Du ansvarar för att initiera återställningen om det uppstår ett regionomfattande lagringsfel i din primära region.

  • Kundhanterad planerad redundans: Du ansvarar för att initiera återställningen om en annan del av lösningen har ett fel i den primära regionen och du behöver växla över hela lösningen till en sekundär region. Använd en planerad redundans när lagringen förblir i drift i den primära regionen, men du måste redundansväxla hela lösningen till en sekundär region, till exempel för haveriberedskapstest som är utformade för att säkerställa efterlevnads- och granskningskrav.

  • Microsoft-hanterad redundans: I undantagsfall kan Microsoft initiera redundans för alla GRS-konton (geo-redundant lagring) i en region. Microsoft-hanterad redundansväxling är dock en sista utväg och förväntas endast utföras efter en längre period av avbrott. Du bör inte förlita dig på Microsoft-hanterad failover.

GRS-konton kan använda någon av dessa redundanstyper. Du behöver inte förkonfigurera ett lagringskonto för att använda någon av redundanstyperna i förväg.

Stöd för regioner

Geo-redundanta konfigurationer i Azure Storage använder länkade Azure-regioner för replikering i sekundär region. Den sekundära regionen bestäms automatiskt baserat på valet av primär region och kan inte anpassas. En fullständig lista över länkade Azure-regioner finns i Listan över Azure-regioner.

Om lagringskontots region inte är kopplad kan du överväga att använda alternativa metoder för flera regioner.

Kravspecifikation

Geo-redundant lagring (GRS) och kundinitierad redundans och återställning efter fel är tillgängliga i alla Azure-kopplade regioner som stöder Azure Storage-konton för generell användning v2.

Överväganden

När du implementerar bloblagring i flera regioner bör du tänka på följande viktiga faktorer:

  • Asynkron replikeringsfördröjning: Datareplikeringen till den sekundära regionen är asynkron, vilket innebär att det finns en fördröjning mellan när data skrivs till den primära regionen och när de blir tillgängliga i den sekundära regionen. Den här fördröjningen kan leda till potentiell dataförlust om ett fel i den primära regionen inträffar innan de senaste data replikeras. Dataförlusten mäts med mål för återställningspunkt (RPO). Du kan förvänta dig att replikeringsfördröjningen är mindre än 15 minuter, men den här gången är en uppskattning och inte garanterad.

    Du kan kontrollera egenskapen Senaste synkroniseringstid för att förstå hur mycket data som kan gå förlorade om ditt lagringskonto har en oplanerad redundansväxling.

  • Åtkomst till sekundär region: Med konfigurationer för geo-redundant lagring (GRS) och geo-zonredundant lagring (GZRS) är den sekundära regionen inte tillgänglig för läsningar förrän en redundansväxling inträffar.

    read-access geo-redundant lagring (RA-GRS) och read-access geo-zone-redundant lagring (RA-GZRS) konfigurationer ger läsåtkomst till den sekundära regionen under normala åtgärder, men på grund av den asynkrona replikeringsfördröjningen kan de returnera något inaktuella data.

  • Funktionsbegränsningar: Vissa Azure Storage-funktioner stöds inte eller har begränsningar när du använder geo-redundant lagring (GRS) eller kundhanterad redundans. Granska funktionskompatibilitet innan du implementerar geo-redundans.

Kostnad

Azure Storage-kontokonfigurationer i flera regioner medför extra kostnader för replikering och lagring mellan regioner i den sekundära regionen. Dataöverföring mellan Azure-regioner debiteras baserat på standardhastigheter för bandbredd mellan regioner.

Mer information finns i Priser för Blob Storage.

Konfigurera stöd för flera regioner

  • Skapa ett nytt GEO-redundant lagringskonto (GRS). Information om hur du skapar ett GRS-konto finns i Skapa ett lagringskonto och välj GRS, geo-redundant lagring med läsbehörighet (RA-GRS), geo-zonredundant lagring (GZRS) eller skrivskyddad geozonredundant lagring (RA-GZRS) när kontot skapas.

  • Aktivera geo-redundans på ett befintligt lagringskonto. Information om hur du konverterar ett befintligt lagringskonto till geo-redundant lagring (GRS) finns i Ändra hur ett lagringskonto replikeras.

    Varning

    När ditt konto har konfigurerats om för geo-redundans kan det ta lång tid innan befintliga data i den nya primära regionen kopieras helt till den nya sekundära regionen.

    Om du vill undvika större dataförlust kontrollerar du värdet för egenskapen Senaste synkroniseringstid innan du initierar en oplanerad redundansväxling. Om du vill utvärdera potentiell dataförlust jämför du den senaste synkroniseringstiden med den senaste gången som data skrevs till den nya primära regionen.

  • Inaktivera geo-redundans. Konvertera GRS-konton tillbaka till konfigurationer med en region, till exempel lokalt redundant lagring (LRS) eller zonredundant lagring (ZRS) med samma konfigurationsändringsprocess för redundans.

Normala åtgärder

I det här avsnittet beskrivs vad du kan förvänta dig när ett lagringskonto har konfigurerats för geo-redundans och alla regioner är i drift.

  • Trafikroutning mellan regioner: Azure Storage använder en aktiv-passiv metod där alla skrivåtgärder och de flesta läsåtgärder dirigeras till den primära regionen.

    För geo-redundant lagring med läsbehörighet (RA-GRS) och geozonredundant lagring med läsbehörighet (RA-GZRS) kan program också läsa från den sekundära regionen genom att komma åt den sekundära slutpunkten. Den här metoden kräver explicit programkonfiguration och är inte automatisk. På grund av den asynkrona replikeringsfördröjningen kan data i den sekundära regionen också vara något inaktuella.

  • Datareplikering mellan regioner: Skrivåtgärder utförs först i den primära regionen med hjälp av följande konfigurerade redundanstyper:

    • Lokalt redundant lagring (LRS) för geo-redundant lagring (GRS) och RA-GRS
    • Zonredundant lagring (ZRS) för geo-zonredundant lagring (GZRS) och RA-GZRS

    När det har slutförts i den primära regionen replikeras data asynkront till den sekundära regionen där de lagras med hjälp av LRS.

    Den asynkrona typen av replikering mellan regioner innebär att det vanligtvis finns en fördröjningstid mellan när data skrivs till den primära regionen och när de är tillgängliga i den sekundära regionen. Du kan övervaka replikeringstiden med hjälp av egenskapen Senaste synkroniseringstid.

Region-down-upplevelse

Det här avsnittet beskriver vad du kan förvänta dig när ett lagringskonto har konfigurerats för geo-redundans och det uppstår ett avbrott i den primära regionen.

  • Kundhanterad redundans (oplanerad): Använd en oplanerad redundans när lagringen i den primära regionen inte är tillgänglig.

    • Identifiering och respons: Om ditt lagringskonto inte är tillgängligt i din primära region kan du överväga att initiera en kundstyrd oplanerad omkoppling. Tänk på följande faktorer för att fatta det här beslutet:

      • Om Azure Resource Health visar problem med åtkomst till lagringskontot i din primära region

      • Om Microsoft rekommenderar att du utför redundansväxling till en annan region

      Varning

      En oplanerad redundansväxling kan leda till dataförlust. Innan du påbörjar en kundhanterad redundans avgör du om återställningen av tjänsten motiverar risken för dataförlust.

    • Anmälan: Azure Storage meddelar dig inte när en region är nere. Du kan dock använda Azure Resource Health för att övervaka hälsotillståndet för ditt lagringskonto. Du kan också använda Azure Service Health för att förstå den övergripande hälsan för Azure Storage-tjänsten, inklusive eventuella regionfel.

      Konfigurera aviseringar för dessa tjänster för att ta emot meddelanden om problem på regionnivå. Mer information finns i Skapa Service Health-aviseringar i Azure-portalen och Skapa och konfigurera Resource Health-aviseringar.

    • Aktiva begäranden: Under redundansväxlingen blir både de primära och sekundära lagringskontoslutpunkterna tillfälligt otillgängliga för både läsningar och skrivningar. Alla aktiva begäranden kan tas bort och klientprogram måste försöka igen när redundansväxlingen har slutförts.

    • Förväntad dataförlust: Dataförlust är vanligt under en oplanerad redundansväxling på grund av den asynkrona replikeringsfördröjningen, vilket innebär att de senaste skrivåtgärderna kanske inte replikeras. Du kan kontrollera egenskapen Senaste synkroniseringstid för att förstå hur mycket data som kan gå förlorade under en oplanerad redundansväxling. Förväntad dataförlust kallas ofta mål för återställningspunkt (RPO). Du kan vanligtvis förvänta dig att RPO:t är mindre än 15 minuter, men den tiden är inte garanterad.

    • Förväntad stilleståndstid: Den förväntade stilleståndstiden kallas ofta för mål för återställningstid (RTO). Kundhanterad redundans slutförs vanligtvis inom 60 minuter, beroende på kontostorlek och komplexitet.

    • Omdistribution av trafik: När redundansväxlingen är klar uppdaterar Azure automatiskt lagringskontots slutpunkter så att program inte behöver konfigureras om. Om ditt program lagrar DNS-poster (Domain Name System) cachelagrade kan det vara nödvändigt att rensa cacheminnet för att säkerställa att programmet skickar trafik till den nya primära regionen.

    • Konfiguration efter redundansväxling: När en oplanerad redundansväxling har slutförts använder ditt lagringskonto i målregionen den lokalt redundanta lagringsnivån (LRS). Om du behöver geo-replikera den igen måste du återaktivera geo-redundant lagring (GRS) och vänta tills data replikeras till den nya sekundära regionen.

    Mer information om hur du initierar kundhanterad redundans finns i Så här fungerar kundhanterad (oplanerad) redundans och Initiera en redundansväxling för ett lagringskonto.

  • Kundhanterad redundans (planerad): Använd en planerad redundans när lagringen förblir i drift i den primära regionen, men du måste redundansväxla hela lösningen till en sekundär region av en annan anledning. En annan Azure-tjänst kan till exempel ha problem och du måste växla till att använda en sekundär region för hela lösningen. Du kan använda en planerad redundansväxling för att utföra ett katastrofhanteringstest (DR) i efterlevnads- och granskningssyfte.

    • Identifiering och svar: Du är ansvarig för att besluta om redundansövergång. Du fattar vanligtvis det här beslutet om du behöver växla över mellan regioner, även om din lagringsenhet är i fungerande skick. Du kan till exempel utlösa en redundansväxling när det uppstår ett större avbrott i en annan programkomponent som du inte kan återställa från i den primära regionen.

    • Anmälan: Azure Storage meddelar dig inte när en region är nere. Du kan dock använda Azure Resource Health för att övervaka hälsotillståndet för ditt lagringskonto. Du kan också använda Azure Service Health för att förstå den övergripande hälsan för Azure Storage-tjänsten, inklusive eventuella regionfel.

      Konfigurera aviseringar för dessa tjänster för att ta emot meddelanden om problem på regionnivå. Mer information finns i Skapa Service Health-aviseringar i Azure-portalen och Skapa och konfigurera Resource Health-aviseringar.

    • Aktiva begäranden: Under redundansväxlingen blir både de primära och sekundära lagringskontoslutpunkterna tillfälligt otillgängliga för både läsningar och skrivningar. Alla aktiva begäranden kan tas bort och klientprogram måste försöka igen när redundansväxlingen har slutförts.

    • Förväntad dataförlust: Ingen dataförlust förväntas eftersom redundansväxlingen slutförs först när alla data har synkroniserats, vilket resulterar i ett RPO på noll.

    • Förväntad stilleståndstid: Failover slutförs vanligtvis inom 60 minuter, vilket innebär att den förväntade RTO är 60 minuter, beroende på kontostorlek och komplexitet. Under redundansväxlingen blir både de primära och sekundära lagringskontoslutpunkterna tillfälligt otillgängliga för både läsningar och skrivningar.

    • Omdistribution av trafik: När redundansväxlingen är klar uppdaterar Azure automatiskt lagringskontots slutpunkter så att program inte behöver konfigureras om. Om ditt program håller DNS-poster cachelagrade kan det vara nödvändigt att rensa cacheminnet för att säkerställa att programmet skickar trafik till den nya primära regionen.

    • Konfiguration efter redundansväxling: När en planerad redundansväxling har slutförts fortsätter ditt lagringskonto i målregionen att vara geo-replikerat och förblir på GRS-nivån.

    Mer information om hur du initierar kundhanterad redundans finns i Så här fungerar kundhanterad (planerad) redundans och Initiera en redundansväxling för ett lagringskonto.

  • Microsoft-hanterad redundans: I sällsynta fall av en större katastrof där Microsoft fastställer att den primära regionen är permanent oåterkallelig kan en automatisk redundansväxling till den sekundära regionen initieras. Microsoft hanterar hela processen och ingen kundåtgärd krävs. Hur lång tid som förflutit innan redundansväxlingen inträffar beror på katastrofens allvarlighetsgrad och den tid som krävs för att bedöma situationen.

    Viktigt!

    Använd kundhanterade redundansalternativ för att utveckla, testa och implementera dina DR-planer. Förlita dig inte på Microsoft-hanterad redundans, som kanske bara används under extrema omständigheter. En Microsoft-hanterad redundans initieras sannolikt för en hel region. Det kan inte initieras för enskilda lagringskonton, prenumerationer eller kunder. Omkoppling kan ske vid olika tidpunkter för olika Azure-tjänster. Vi rekommenderar att du använder kundhanterad redundansväxling.

Regionåterställning

Återställningsprocessen skiljer sig avsevärt mellan Scenarier för Microsoft-hanterad och kundhanterad redundans.

  • Kundhanterad redundans (oplanerad): Efter en oplanerad redundansväxling konfigureras lagringskontot med lokalt redundant lagring (LRS). Om du vill återställa måste du återupprätta grs-relationen (geo-redundant lagring) och vänta tills data replikeras.

  • Kundhanterad redundans (planerad): Efter en planerad redundansväxling förblir lagringskontot geo-replikerat. Du kan initiera en annan kundhanterad redundansväxling för att återställa till den ursprungliga primära regionen. Samma redundansöverväganden gäller.

  • Microsoft-hanterad redundans: Om Microsoft initierar en redundansväxling är det troligt att en betydande katastrof inträffade i den primära regionen och att den primära regionen kanske inte kan återställas. Eventuella tidslinjer eller återställningsplaner beror på omfattningen av de regionala katastrof- och återställningsinsatserna. Du bör övervaka Azure Service Health-kommunikation för mer information.

Testning för regionfel

Du kan simulera regionala fel för att testa dina haveriberedskapsprocedurer.

  • Planerad redundanstestning: För GRS-konton (geo-redundant lagring) kan du utföra planerade redundansåtgärder under underhållsperioder för att testa den fullständiga redundans- och återställningsprocessen. Planerad redundans kräver inte dataförlust, men det innebär stilleståndstid vid både redundans och återställning efter fel.

  • Sekundär slutpunktstestning: För geo-redundant lagring med läsbehörighet (RA-GRS) och geozonredundant lagring med läsåtkomst (RA-GZRS) testar du regelbundet läsåtgärder mot den sekundära slutpunkten för att säkerställa att programmet kan läsa data från den sekundära regionen.

Alternativa metoder för flera regioner

Redundansfunktionerna mellan regioner i Azure Storage kan vara olämpliga på grund av följande:

  • Ditt lagringskonto finns i en icke-parad region.

  • Dina affärsupptidsmål uppfylls inte av återställningstiden eller dataförlusten som de inbyggda redundansalternativen ger.

  • Du måste växla över till en region som inte är den primära regionens partner.

  • Du behöver en aktiv/aktiv konfiguration över regioner.

Det här avsnittet innehåller en översikt på hög nivå över några metoder att tänka på. En omfattande översikt över distributionstopologier för flera regioner för Azure Storage ligger utanför omfånget för den här artikeln.

Du kan distribuera Azure Storage i flera regioner med hjälp av separata lagringskonton i varje region. Den här metoden ger flexibilitet i val av region, möjlighet att använda icke-luftade regioner och mer detaljerad kontroll över replikeringstid och datakonsekvens. När du implementerar flera lagringskonton mellan regioner måste du konfigurera datareplikering mellan regioner, implementera belastningsutjämnings- och redundansprinciper och säkerställa datakonsekvens mellan regioner.

Objektreplikering ger ett extra alternativ för datareplikering mellan regioner som ger asynkron kopiering av blockblobar mellan lagringskonton. Till skillnad från de inbyggda geo-redundanta lagringsalternativen som använder fasta parkopplade regioner kan du med objektreplikering replikera data mellan lagringskonton i alla Azure-regioner, inklusive icke-kopplade regioner. Den här metoden ger dig fullständig kontroll över käll- och målregioner, replikeringsprinciper och de specifika containrar och blobprefix som ska replikeras.

Du kan konfigurera objektreplikering för att replikera alla blobar i en container eller specifika underuppsättningar baserat på blobprefix och taggar. Replikeringen är asynkron och förekommer i bakgrunden. Du kan konfigurera flera replikeringsprinciper och till och med länka replikering över flera lagringskonton för att skapa avancerade topologier för flera regioner.

Objektreplikering är inte kompatibel med alla lagringskonton. Det fungerar till exempel inte med lagringskonton som använder hierarkiska namnområden (även kallade Azure Data Lake Storage Gen2-konton).

Mer information finns i Objektreplikering för blockblobar och Konfigurera objektreplikering.

Säkerhetskopior

Blob Storage innehåller flera dataskyddsmekanismer som kompletterar redundans för omfattande säkerhetskopieringsstrategier. Tjänstens inbyggda redundans skyddar mot infrastrukturfel och extra säkerhetskopieringsfunktioner skyddar mot oavsiktlig borttagning, skada och skadliga aktiviteter.

Med återställning till tidpunkt (PITR) kan du återställa blockblobdata till ett tidigare tillstånd inom en konfigurerad kvarhållningsperiod på upp till 365 dagar. Microsoft hanterar den här funktionen fullt ut. Den innehåller också detaljerade återställningsfunktioner på container- eller blobnivå. PITR-data lagras i samma region som källkontot och är tillgängliga även vid regionala avbrott om du använder geo-redundanta konfigurationer.

Blob-versionshantering underhåller automatiskt tidigare versioner av blobar när de ändras eller tas bort. Varje version lagras som ett separat objekt och kan nås separat. Versioner lagras i samma region som den aktuella bloben och följer samma redundanskonfiguration som lagringskontot.

Mjuk borttagning ger ett säkerhetsnät för oavsiktligt borttagna blobar och containrar genom att behålla borttagna data under en konfigurerbar period. Mjukt borttagna data finns kvar i samma lagringskonto och region, vilket gör dem omedelbart tillgängliga för återställning. För geo-redundanta konton replikeras även mjukt borttagna data till den sekundära regionen.

Blobögonblicksbilder skapar skrivskyddade kopior av blobar som du kan använda för säkerhetskopierings- och återställningsscenarier. Ögonblicksbilder lagras i samma lagringskonto och följer samma redundans- och geo-replikeringsinställningar som basbloben.

För krav på säkerhetskopiering mellan regioner bör du överväga att använda Azure Backup för blobar, som tillhandahåller centraliserad säkerhetskopieringshantering och kan lagra säkerhetskopieringsdata i regioner som skiljer sig från källdata. Den här tjänsten tillhandahåller alternativ för drifts- och valvsäkerhetskopiering som har konfigurerbara kvarhållningsprinciper och återställningsfunktioner. Mer information finns i Översikt över säkerhetskopiering för blobar.

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 Redundans, replikering och säkerhetskopiering.

Serviceavtal

Serviceavtalet (SLA) för Azure Storage beskriver den förväntade tillgängligheten för tjänsten och de villkor som måste uppfyllas för att uppnå den tillgänglighetsförväntningen. Det serviceavtal för tillgänglighet som du är berättigad till beror på lagringsnivån och vilken replikeringstyp du använder. Mer information finns i Serviceavtal för onlinetjänster.

Relaterat innehåll