Dela via

Tillförlitlighet i Azure Files

I den här artikeln beskrivs tillförlitlighetsstöd i Azure Files. Azure Files tillhandahåller fullständigt hanterade filresurser i molnet som är tillgängliga via SMB-protokoll (Server Message Block) och NFS (Network File System).

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.

Den här artikeln beskriver hur du gör Azure Files motståndskraftigt mot en mängd olika potentiella avbrott och problem, inklusive tillfälliga fel, avbrott i tillgänglighetszonen och regionstopp. Den beskriver också hur du kan använda säkerhetskopior för att återställa från andra typer av problem och visar viktig information om serviceavtalet för Azure Files (SLA).

Anmärkning

Azure Files är en del av Azure Storage-plattformen. Vissa av funktionerna i Azure Files ä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 vanliga funktioner.

Rekommendationer för produktionsdistribution

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

Översikt över tillförlitlighetsarkitektur

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.

Azure Files är tillgängligt på två medienivåer:

  • Premium-nivån använder SSD (Solid State Drives) för höga prestanda. Den här nivån rekommenderas för arbetsbelastningar som kräver låg svarstid.

  • Standardnivån stöder hårddiskar (HDD). HDD-fildelningar ger ett kostnadseffektivt lagringsalternativ för allmänna fildelningar.

Mer information finns i Planera för att distribuera Azure Files – lagringsnivåer.

Azure Files implementerar redundans på lagringskontonivå och filresurser ärver den redundanskonfigurationen automatiskt. Tjänsten stöder flera redundansmodeller som skiljer sig åt i sin metod för dataskydd.

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 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.

För att effektivt hantera tillfälliga fel när du använder Azure Files konfigurerar du lämpliga tidsgränsvärden för dina filåtgärder baserat på filstorlek och nätverksförhållanden. Större filer kräver längre tidsgränser, medan mindre åtgärder kan använda kortare värden för att snabbt identifiera fel.

För att säkerställa att endast säkra anslutningar upprättas till din NFS-resurs rekommenderar vi att du konfigurerar en privat slutpunkt för ditt lagringskonto. En privat slutpunkt använder Azure Private Link för att tilldela en statisk IP-adress till ditt lagringskonto inifrån det virtuella nätverkets privata adressutrymme. En privat slutpunkt hjälper till att förhindra anslutningsavbrott från dynamiska IP-adressändringar. Mer information om säkerhet för dina NFS-resurser finns i NFS-filresurser – Säkerhet och nätverk.

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.

Azure Files har två typer av stöd för tillgänglighetszoner:

Kravspecifikation

  • Regionstöd:

  • Filresurstyper:

    • ZRS: ZRS stöds av alla filresurstyper.

    • LRS med zonindelad placering: LRS med zonindelning är tillgängligt för lagringskonton som uppfyller följande krav:

      • Måste använda premiumlagringsnivån (SSD-medienivå).
      • Endast klassiska Azure-filresurser (med resursprovidern Microsoft.Storage). Zonindelning är för närvarande inte möjligt för filresurser som skapats med resursprovidern Microsoft.FileShares (förhandsversion).

Kostnad

Kostnadspåverkan skiljer sig beroende på vilken typ av stöd för tillgänglighetszoner du använder:

  • ZRS: 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.

  • LRS med zonindelad placering: LRS med zonindelad placering debiteras till samma pris som LRS.

Detaljerad prisinformation finns i Priser för Azure Files.

Konfigurera stöd för tillgänglighetszoner

  • Skapa en fildelning med stöd för tillgänglighetszoner:

  • Ändra replikeringstyp:

  • Inaktivera stöd för tillgänglighetszoner:

    • ZRS: Konvertera ZRS-konton tillbaka till en icke-zonbaserad konfiguration, till exempel LRS, genom samma redundanskonfigurationsändringsprocess.

    • LRS med zonindelad placering: För att ta bort ett lagringskonto från en zon och sedan konvertera zonindelningskontot till ett regionalt lagringskonto, se Ta bort ett lagringskonto från en zon.

Beteende när alla zoner är felfria

I det här avsnittet beskrivs vad du kan förvänta dig när ett fillagringskonto har konfigurerats för stöd för tillgänglighetszoner och alla tillgänglighetszoner används.

  • Trafikroutning mellan zoner:

    • ZRS: 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.

    • LRS med zonindelad placering: Azure Storage med lokalt redundant lagring (LRS) distribuerar automatiskt begäranden mellan lagringskluster i den tillgänglighetszon som du har valt. Trafikdistributionen är transparent för program och kräver ingen konfiguration på klientsidan.

  • Datareplikering mellan zoner:

    • ZRS: 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.

    • LRS med zonindelad placering: Alla skrivåtgärder till LRS replikeras synkront över flera lagringsrepliker i zonen. När du laddar upp eller ändrar data anses åtgärden inte vara slutförd förrän data har replikerats över alla repliker.

Beteende vid ett zonfel

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

  • Identifiering och svar:

    • ZRS: 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).

    • LRS med zonindelad placering: Du måste identifiera förlusten av en tillgänglighetszon. Om det behövs kan du initiera en failover till en sekundär fildelning som du har förskapat i en annan tillgänglighetszon.

  • Meddelande: Microsoft meddelar dig inte automatiskt när en zon är nere. Du kan dock använda Azure Resource Health för att övervaka hälsotillståndet för en enskild resurs, och du kan konfigurera Resource Health-aviseringar för att meddela dig om problem. Du kan också 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:

    • ZRS: 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.

    • LRS med zonindelad placering: Begäranden under flygning tas bort och bör göras om när zonen återställs.

  • Förväntad dataförlust:

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

    • LRS med zonindelad placering: Data om filresurser i den berörda zonen är inte tillgängliga förrän zonen återställs.

  • Förväntad stilleståndstid:

    • ZRS: 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.

    • LRS med zonindelad placering: Filresurser i den berörda zonen förblir nere tills tillgänglighetszonen återställs.

  • Omdistribution av trafik:

    • ZRS: Azure omdirigerar automatiskt trafik till återstående felfria tillgänglighetszoner. Tjänsten har fullständig funktionalitet genom att använda de kvarvarande zonerna utan att kunden behöver göra något. Ingen återmontering av Azure-filaktier från de anslutna klienterna behövs.

    • LRS med zonindelad placering: Du ansvarar för att växla till andra lagringskonton för filer i zoner med fungerande system om det behövs.

Zonåterställning

Beteende vid zonåterställning beror på den typ av replikering som fillagringskontot använder:

  • ZRS: 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.

  • LRS med zonindelad placering: När zonen är felfri är filresurser i zonen tillgängliga igen. Du ansvarar för alla procedurer för zonåterställning och datasynkronisering som dina arbetsbelastningar kräver.

Test för zonfel

Testalternativ för zon ned beror på vilken typ av replikering fillagringskontot använder:

  • ZRS: 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.

  • LRS med zonal placerad placering: Det finns inget sätt att simulera ett avbrott i tillgänglighetszonen som innehåller filkontot ditt. Du kan dock manuellt konfigurera överordnade program, brandväggar, gatewayer eller lastbalanserare för att omdirigera trafik till ett annat fillagringskonto i en annan tillgänglighetszon.

Motståndskraft mot regionomfattande fel

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 anpassade lösningar för flera regioner för återhämtning.

Geo-redundant lagring för 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.

Viktigt!

Azure Files stöder endast geografisk redundans (GRS eller GZRS) för standardfilandelar (HDD).

Azure Files stöder inte georedundant lagring med läsåtkomst (RA-GRS) eller geozonredundant lagring med läsåtkomst (RA-GZRS). Om ett lagringskonto har konfigurerats för att använda RA-GRS eller RA-GZRS konfigureras och faktureras standardfilresurserna (HDD) som GRS eller GZRS.

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.

Kravspecifikation

  • Endast standardfilresurser: Azure Files stöder endast geo-redundans (GRS eller GZRS) för standardfilresurser (HDD). Premium-fildelningar (SSD) måste använda LRS eller ZRS. Om du har premiumfilresurser och vill replikera data mellan regioner för högre återhämtning kan du läsa Anpassade lösningar för flera regioner för återhämtning.

  • ENDAST GRS och GZRS: Azure Files stöder inte geo-redundant lagring med läsåtkomst (RA-GRS) eller geozonredundant lagring med läsåtkomst (RA-GZRS). Om ett lagringskonto har konfigurerats för att använda RA-GRS eller RA-GZRS konfigureras och faktureras standardfilresurserna (HDD) som GRS eller GZRS.

Överväganden

När du implementerar Azure Files 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.

  • Senaste synkroniseringstid: För Azure Files baseras senaste synkroniseringstid på den senaste systemögonblicksbilden i den sekundära regionen.

    Beräkningen för senaste synkroniseringstid kan överskrida tidsgränsen om det finns fler än 100 fildelningar på ett lagringskonto. Vi rekommenderar att du distribuerar 100 eller färre fildelningar för varje lagringskonto för att undvika tidsutgångar.

  • Åtkomst till sekundär region: Den sekundära regionen är inte tillgänglig för läsningar förrän en redundansväxling inträffar.

  • Funktionsbegränsningar: Vissa Azure Files-funktioner stöds inte eller har begränsningar när du använder GRS eller kundhanterad redundans. Dessa begränsningar omfattar specifika filresurstyper, åtkomstnivåer och hanteringsverktyg och åtgärder. Granska dokumentationen om 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.

Detaljerad prisinformation finns i Priser för Azure Files.

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 för ett befintligt fillagringskonto. För att konvertera ett befintligt fillagringskonto till GRS, se Ändra redundanskonfiguration för Azure Files.

    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 (LRS eller ZRS) via samma ändringsprocess för redundanskonfiguration.

Beteende när alla regioner är felfria

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 Files använder en aktiv-passiv metod där alla läs- och skrivåtgärder dirigeras till den primära regionen.

  • Datareplikering mellan regioner: Skrivåtgärder bekräftas först i den primära regionen med hjälp av den konfigurerade redundanstypen (LRS för GRS, eller ZRS för 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.

Beteende under ett regionfel

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.

    • Meddelande: Microsoft meddelar dig inte automatiskt när en region är nere. Emellertid:

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

      • Meddelande: Microsoft meddelar dig inte automatiskt när en region är nere. Emellertid:

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

    • Meddelande: Microsoft meddelar dig inte automatiskt när en region är nere. Emellertid:

    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.

Test för regionfel

För GRS-konton 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 kräver stilleståndstid vid både redundans och återställning efter fel.

Anpassade lösningar för flera regioner för återhämtning

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.

  • Du använder fildelningstyper som inte stöder geo-redundans.

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.

Överväg följande vanliga metoder på hög nivå:

  • Flera lagringskonton: Azure Files kan distribueras 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.

  • Replikering på programnivå: Implementera anpassad replikeringslogik med hjälp av Azure Data Factory eller AzCopy för att synkronisera data mellan filresurser i olika regioner. Den här metoden kräver anpassade mekanismer för utveckling och konfliktlösning.

  • Använd Azure File Sync för att replikera filer till en filresurs i en annan Azure-region. Du kan använda Azure File Sync för att synkronisera mellan en SMB Azure-filresurs (molnslutpunkt), en lokal Windows-filserver och en monterad filresurs som körs på en virtuell dator (VM) i en annan Azure-region (en DR-serverslutpunkt).

    Den här metoden kräver att du distribuerar flera filresurser och en virtuell dator för att samordna synkroniseringsprocessen.

    Om du använder den här metoden för filreplikering i flera regioner:

    • Inaktivera molnnivåindelning för att säkerställa att alla data finns lokalt på filservern.

    • Etablera tillräckligt med lagringsutrymme på den virtuella Azure-datorn för att lagra hela datamängden.

    • Få åtkomst till och ändra filer på serverslutpunkten, och inte i Azure, för att säkerställa att ändringarna replikeras snabbt till den sekundära regionen.

Säkerhetskopiering och återställning

Azure Files-säkerhetskopiering är en intern integrering mellan Azure Files och Azure Backup som är utformad för att skydda data mot oavsiktlig borttagning, skada och utpressningstrojanattacker.

Azure Files-säkerhetskopiering skapar ögonblicksbilder på resursnivå som lagras i samma lagringskonto. Den här funktionen möjliggör snabb återställning av både enskilda filer och hela filresurser. Du kan också använda säkerhetskopieringsprinciper för att tillhandahålla långa kvarhållningsperioder med anpassningsbar säkerhetskopieringsfrekvens.

Du kan skapa dina ögonblicksbilder och lagra dem på två olika sätt:

  • Lagring på resursnivå: För drifts- och kortsiktiga återställningsscenarier kan du skapa ögonblicksbilder på resursnivå och lagra dem i samma lagringskonto. Ögonblicksbilder på delningsnivå möjliggör snabb återställning av enskilda filer eller hela fildelningar till antingen den ursprungliga eller en alternativ plats.

  • Lagring av välvd säkerhetskopiering: Genom att använda en välvd säkerhetskopia kan du kopiera dina dagliga ögonblicksbilder till ett Azure Recovery Services-valv. För att förbättra säkerheten är det här valvet isolerat och har ett luftgap mellan sig och det primära lagringskontot.

    När du använder en länkad Azure-region och konfigurerar valvet att använda GRS replikerar valvet data till den kopplade regionen. Den här replikeringen stöder återställning mellan regioner och DR-arbetsflöden.

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

  • Last updated on