Dela via

Tillförlitlighet i Azure Queue Storage

Den här artikeln beskriver tillförlitlighetsstöd i Azure Queue Storage, som omfattar intraregional återhämtning via tillgänglighetszoner och distributioner i flera regioner. En mer detaljerad översikt över tillförlitligheten i Azure finns i Azures tillförlitlighet.

Återhämtning är ett delat ansvar mellan dig och Microsoft, så den här artikeln beskriver även hur du kan skapa en elastisk lösning som uppfyller dina behov.

Queue Storage är en tjänst för att lagra och distribuera ett stort antal meddelanden. Queue Storage används ofta för att skapa en kvarvarande arbetslogg för att bearbeta asynkront. Det ger tillförlitlig meddelandeleverans för löst kopplade programarkitekturer. Ett kömeddelande kan vara upp till 64 kB stort och en kö kan innehålla miljontals meddelanden, upp till den totala kapacitetsgränsen för ett lagringskonto.

Queue Storage tillhandahåller flera tillförlitlighetsfunktioner via den underliggande Azure Storage-plattformen. Som en del av Azure Storage ärver Queue Storage samma redundansalternativ, stöd för tillgänglighetszoner och geo-replikeringsfunktioner som säkerställer hög tillgänglighet och hållbarhet för dina meddelandeköer.

Note

Queue Storage är en del av Azure Storage-plattformen. Vissa av funktionerna i Queue Storage är vanliga i många Azure Storage-tjänster.

Rekommendationer för produktionsdistribution

För produktionsmiljöer:

  • Aktivera zonredundant lagring (ZRS) för de lagringskonton som innehåller kölagringsresurser. ZRS ger högre tillgänglighet genom att replikera dina data synkront över flera tillgänglighetszoner i den primära regionen. Högre tillgänglighet skyddar dina lagringskonton mot fel i tillgänglighetszonen.

  • Om du behöver motståndskraft mot regionstopp och lagringskontots primära region är kopplad kan du överväga att aktivera geo-redundant lagring (GRS). GRS replikerar data asynkront till den kopplade regionen. I regioner som stöds kan du kombinera geo-redundans med zonredundans med hjälp av geo-zonredundant lagring (GZRS).

För avancerade meddelandekrav bör du överväga att använda Azure Service Bus. Mer information om skillnaderna mellan Queue Storage och Service Bus finns i Jämför Azure Storage-köer och Service Bus-köer.

Översikt över tillförlitlighetsarkitektur

Queue Storage fungerar som en distribuerad meddelandetjänst i Azure Storage-plattformens infrastruktur. Tjänsten tillhandahåller redundans via flera kopior av kö- och meddelandedata. Den specifika redundansmodellen beror på konfigurationen av lagringskontot.

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.

Queue Storage används ofta i program för att hjälpa dem att hantera tillfälliga fel i andra komponenter. Genom att använda asynkrona meddelanden med en tjänst som Queue Storage kan program återställas från tillfälliga fel genom att bearbeta meddelanden vid ett senare tillfälle. Mer information finns i Asynkron meddelandeprimör.

I själva tjänsten hanterar Queue Storage tillfälliga fel automatiskt med hjälp av flera mekanismer som Azure Storage-plattformen och klientbiblioteken tillhandahåller. Tjänsten är utformad för att tillhandahålla motståndskraftiga funktioner för meddelandeköer även vid tillfälliga infrastrukturproblem.

Klientbibliotek för kölagring innehåller inbyggda återförsöksprinciper som automatiskt hanterar vanliga tillfälliga fel, till exempel tidsgränser för nätverket, tillfällig tjänstotillgänglighet (HTTP 503) och begränsningssvar (HTTP 429). När programmet stöter på dessa tillfälliga villkor försöker klientbiblioteken automatiskt utföra åtgärder igen med hjälp av exponentiella backoff-strategier.

Om du vill hantera tillfälliga fel effektivt med hjälp av Queue Storage kan du vidta följande åtgärder:

  • Konfigurera lämpliga tidsgränser i kölagringsklienten för att balansera svarstider med motståndskraft mot tillfälliga avmattningar. Standardtimeouterna i Azure Storage-klientbibliotek är vanligtvis lämpliga för de flesta scenarier.

  • Implementera kretsbrytarmönster i ditt program när det bearbetar meddelanden från köer. Kretsbrytarmönster förhindrar sammanhängande fel när underordnade tjänster får problem.

  • Använd synlighetstimeouter på rätt sätt när programmet tar emot meddelanden. Tidsgränser för synlighet säkerställer att meddelanden blir tillgängliga för återförsök om programmet påträffar fel under bearbetningen.

Mer information om Azure Table Storage-arkitekturen och hur du utformar elastiska och storskaliga program finns i checklista för prestanda och skalbarhet för Queue Storage.

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.

Azure Queue Storage är zonredundant när det distribueras med ZRS-konfiguration. Till skillnad från LRS garanterar ZRS att Azure synkront replikerar dina ködata över flera tillgänglighetszoner. ZRS säkerställer att dina data förblir tillgängliga även om en zon upplever ett avbrott. ZRS säkerställer att dina köer förblir tillgängliga även om en hel tillgänglighetszon blir otillgänglig. Alla skrivåtgärder måste bekräftas i flera zoner innan de slutförs, vilket ger starka konsekvensgarantier.

Zonredundans aktiveras på lagringskontonivå och gäller för alla kölagringsresurser i det kontot. Du kan inte konfigurera enskilda köer för olika redundansnivåer. Inställningen gäller för hela lagringskontot. När en tillgänglighetszon drabbas av ett avbrott dirigerar Azure Storage automatiskt begäranden till felfria zoner utan att kräva några åtgärder från ditt program.

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.

Requirements

Du måste använda ett standardlagringskonto för generell användning v2 för att aktivera ZRS för Queue Storage. Premium Storage-konton har inte stöd för Queue Storage.

Cost

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.

Detaljerad prisinformation finns i Priser för kölagring.

Konfigurera stöd för tillgänglighetszoner

  • Skapa ett zonredundant lagringskonto och en kö genom att utföra följande steg.

    1. Skapa ett lagringskonto och välj ZRS, GZRS eller read-access geo-zone-redundant lagring (RA-GZRS) som redundansalternativ när kontot skapas.

    2. Skapa en kö.

  • Ä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

I det här avsnittet beskrivs vad du kan förvänta dig när ett kölagringskonto har konfigurerats för zonredundans och alla tillgänglighetszoner är i drift.

  • 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

När en tillgänglighetszon blir otillgänglig hanterar Queue Storage automatiskt redundansväxlingen genom att vidta följande åtgärder.

  • 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 zon blir otillgänglig utför Azure nätverksuppdateringar, till exempel DNS-ompunktering (Domain Name System), så att begäranden dirigeras till återstående felfria tillgänglighetszoner. Tjänsten har fullständig funktionalitet med hjälp av de kvarvarande zonerna utan att kunden behöver göra något.

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.

Important

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.

Requirements

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.

Considerations

När du implementerar kölagring 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.

Cost

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.

Detaljerad prisinformation finns i Priser för kölagring.

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.

    Warning

    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

      Warning

      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.

    Important

    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.

Note

För avancerade krav för flera regioner bör du överväga att använda Service Bus i stället, vilket omfattar stöd för icke-trappade regioner.

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.

Den här metoden kräver att du hanterar meddelandedistribution, hanterar datasynkronisering mellan köer i de olika lagringskontona och implementerar anpassad redundanslogik.

Backups

Queue Storage tillhandahåller inte traditionella säkerhetskopieringsfunktioner, till exempel återställning till tidpunkt (PITR). Detta beror på att köer är utformade för tillfällig meddelandelagring i stället för långsiktig datapersistence. Meddelanden bearbetas och tas vanligtvis bort från köer under normala programåtgärder.

För scenarier som kräver meddelandehållbarhet utöver de inbyggda redundansalternativen bör du överväga att implementera din egen meddelandeloggning på programnivå eller beständighet till ett permanent datalager, till exempel Blob Storage eller Azure SQL Database. Med den här metoden kan du underhålla meddelandehistoriken när du använder Queue Storage för det avsedda syftet med tillfällig meddelandebuffertning och bearbetningssamordning.

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