Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Microsoft strävar efter att säkerställa att Azure-tjänster alltid är tillgängliga. Oplanerade tjänstavbrott kan dock inträffa och du bör ha en haveriberedskapsplan (DR) för att hantera ett regionalt tjänstavbrott. En viktig del av en haveriberedskapsplan förbereder redundansväxling till den sekundära slutpunkten när den primära slutpunkten blir otillgänglig. I den här artikeln beskrivs de begrepp och processer som ingår i haveriberedskap (DR) och redundans för lagringskonto.
Viktigt!
Azure File Sync stöder endast redundans för lagringskonto om tjänsten för synkronisering av lagring också har redundansväxlats. Det beror på att Azure File Sync kräver att lagringskontot och tjänsten för synkronisering av lagring finns i samma Azure-region. Om endast lagringskontot har redundansväxlats misslyckas synkroniserings- och molnnivåindelningsåtgärder tills tjänsten för synkronisering av lagring har växlats över till den sekundära regionen. Om du vill redundansväxla ett lagringskonto som innehåller Azure-filresurser som används som molnslutpunkter i Azure File Sync kan du läsa Metodtips för haveriberedskap i Azure File Sync och Azure File Sync serveråterställning.
Gäller för
| Hanteringsmodell | Faktureringsmodell | Medieklass | Redundans | Små och medelstora företag (SMB) | NFS (Network File System) |
|---|---|---|---|---|---|
| Microsoft.Storage, lagringstjänster | Provisionerad v2 | SSD (hög kvalitet) | Lokalt (LRS) |
|
|
| Microsoft.Storage, lagringstjänster | Provisionerad v2 | SSD (hög kvalitet) | Zon (ZRS) |
|
|
| Microsoft.Storage, lagringstjänster | Provisionerad v2 | HDD (standard) | Lokalt (LRS) |
|
|
| Microsoft.Storage, lagringstjänster | Provisionerad v2 | HDD (standard) | Zon (ZRS) |
|
|
| Microsoft.Storage, lagringstjänster | Provisionerad v2 | HDD (standard) | Geo (GRS) |
|
|
| Microsoft.Storage, lagringstjänster | Provisionerad v2 | HDD (standard) | GeoZone (GZRS) |
|
|
| Microsoft.Storage, lagringstjänster | Tillhandahållen v1 | SSD (hög kvalitet) | Lokalt (LRS) |
|
|
| Microsoft.Storage, lagringstjänster | Tillhandahållen v1 | SSD (hög kvalitet) | Zon (ZRS) |
|
|
| Microsoft.Storage, lagringstjänster | Betala efter hand | HDD (standard) | Lokalt (LRS) |
|
|
| Microsoft.Storage, lagringstjänster | Betala efter hand | HDD (standard) | Zon (ZRS) |
|
|
| Microsoft.Storage, lagringstjänster | Betala efter hand | HDD (standard) | Geo (GRS) |
|
|
| Microsoft.Storage, lagringstjänster | Betala efter hand | HDD (standard) | GeoZone (GZRS) |
|
|
Kundhanterad planerad redundans (förhandsversion)
Kundhanterad planerad redundans kan också användas i flera scenarier, inklusive planerad haveriberedskapstestning, en proaktiv metod för storskaliga katastrofer eller återställning från avbrott relaterade till icke-lagring.
Under den planerade redundansväxlingen växlas de primära och sekundära regionerna. Den ursprungliga primära regionen degraderas och blir den nya sekundära regionen. Samtidigt befordras den ursprungliga sekundära regionen och blir den nya primära. När redundansväxlingen är klar kan användarna fortsätta att komma åt data i den nya primära regionen och administratörer kan verifiera sin haveriberedskapsplan. Lagringskontot måste vara tillgängligt i både de primära och sekundära regionerna innan en planerad redundansväxling kan initieras.
Dataförlust förväntas inte under den planerade redundans- och återställningsprocessen så länge de primära och sekundära regionerna är tillgängliga under hela processen. Mer information finns i avsnittet Förutse dataförlust och inkonsekvenser .
För att förstå effekten av den här typen av redundans på dina användare och program är det bra att veta vad som händer under varje steg i de planerade processerna för redundans och återställning efter fel. Mer information om hur den här processen fungerar finns i Så här fungerar kundhanterad (planerad) redundans.
Viktigt!
Kundstyrd planerad omkoppling är för närvarande i förhandsversion och stöds i alla offentliga GRS/GZRS-regioner. Information om huruvida en region stöder GZRS finns i listan över Azure-regioner. För att stödja GZRS måste en region ha stöd för tillgänglighetszoner och ha en länkad region.
Om du vill anmäla dig till förhandsversionen läser du Konfigurera förhandsversionsfunktioner i Azure-prenumerationen och anger AllowSoftFailover som funktionsnamn. Providernamnet för den här förhandsgranskningsfunktionen är Microsoft.Storage.
Se kompletterande användningsvillkor för Microsoft Azure Previews för juridiska villkor som gäller för Azure-funktioner som är i betaversion, förhandsversion eller på annat sätt ännu inte har släppts i allmän tillgänglighet.
Återställningsmått och kostnader
För att formulera en effektiv DR-strategi måste en organisation förstå:
- Hur mycket data den har råd att förlora i ett avbrott (mål för återställningspunkt eller RPO)
- Hur snabbt den behöver kunna återställa affärsfunktioner och data (mål för återställningstid eller RTO)
Kostnaden för haveriberedskap ökar vanligtvis med lägre eller noll RPO/RTO. Företag som behöver vara igång inom några sekunder efter en katastrof och inte kan drabbas av någon dataförlust kommer att betala mer för DR, medan de med högre RPO/RTO-nummer kommer att betala mindre. Azure tillhandahåller lösningar som kan fungera med olika RPO- och RTO-krav.
Välj rätt redundansalternativ
Azure Files erbjuder olika redundansalternativ för att skydda dina data från planerade och oplanerade händelser, allt från tillfälliga maskinvarufel, nätverks- och strömavbrott till naturkatastrofer. Alla Azure-filresurser kan använda lokalt redundant lagring (LRS) eller zonredundant lagring (ZRS). För mer information, se Azure Files redundancy.
Azure Files stöder redundans för HDD-filresurser som konfigurerats med geo-redundant lagring (GRS) och geo-zonredundant lagring (GZRS) för skydd mot regionala avbrott. Med redundansväxling av konton kan du initiera en redundansväxling för ett lagringskonto om den primära slutpunkten blir otillgänglig. Vid redundansväxlingen uppdateras den sekundära slutpunkten så att den blir lagringskontots primära slutpunkt. När redundansväxlingen är klar kan klienter börja skriva till den nya primära slutpunkten.
GRS och GZRS medför fortfarande en risk för dataförlust eftersom data kopieras till den sekundära regionen asynkront, vilket innebär att det finns en fördröjning innan en skrivning till den primära regionen kopieras till den sekundära regionen. I händelse av ett avbrott går skrivåtgärder till den primära slutpunkten som ännu inte har kopierats till den sekundära slutpunkten förlorade. Det innebär att ett fel som påverkar den primära regionen kan leda till dataförlust om den primära regionen inte kan återställas. Intervallet mellan de senaste skrivningarna till den primära regionen och den senaste skrivningen till den sekundära regionen är RPO. Azure Files har vanligtvis ett RPO på 15 minuter eller mindre, även om det för närvarande inte finns något serviceavtal för hur lång tid det tar att replikera data till den sekundära regionen.
Viktigt!
GRS/GZRS stöds inte för SSD-filresurser. Du kan dock synkronisera mellan två Azure-filresurser för att uppnå geografisk redundans.
Utforma för hög tillgänglighet
Det är viktigt att utforma ditt program för hög tillgänglighet från början. Se dessa Azure-resurser för vägledning om hur du utformar ditt program och planerar för haveriberedskap:
- Designa motståndskraftiga program för Azure: En översikt över de viktigaste begreppen för att skapa program med hög tillgänglighet i Azure.
- Checklista för återhämtning: En checklista för att verifiera att ditt program implementerar de bästa designmetoderna för hög tillgänglighet.
- Använd geo-redundans för att utforma program med hög tillgänglighet: Designvägledning för att skapa program för att dra nytta av geo-redundant lagring för SMB-filresurser.
Vi rekommenderar också att du utformar ditt program för att förbereda dig för risken för skrivfel. Programmet bör exponera skrivfel på ett sätt som varnar dig om potentiella avbrott i den primära regionen.
Vi rekommenderar att du utformar ditt program för att kontrollera egenskapen Senaste synkroniseringstid för att utvärdera förväntad dataförlust. Om du till exempel loggar alla skrivåtgärder kan du jämföra tiden för dina senaste skrivåtgärder med den senaste synkroniseringstiden för att avgöra vilka skrivningar som inte har synkroniserats till den sekundära.
Spåra avbrott
Du kan prenumerera på Azure Service Health-instrumentpanelen för att spåra hälsotillstånd och status för Azure Files och andra Azure-tjänster.
Förstå processen för redundans för konto
Med redundans för kundhanterade konton kan du redundansväxla hela lagringskontot till den sekundära regionen om den primära blir otillgänglig av någon anledning. När du tvingar fram en redundans till den sekundära regionen kan klienterna börja skriva data till den sekundära slutpunkten när redundansväxlingen är klar. Redundansväxlingen tar vanligtvis ungefär en timme. Vi rekommenderar att du pausar din arbetsbelastning så mycket som möjligt innan du påbörjar en redundansväxling av kontot.
Information om hur du initierar en redundansväxling av ett konto finns i Initiera en redundansväxling av ett konto.
Så här fungerar redundans för ett konto
Under normala omständigheter skriver en klient data till ett lagringskonto i den primära regionen och dessa data kopieras asynkront till den sekundära regionen. Följande bild visar scenariot när den primära regionen är tillgänglig:
Om den primära slutpunkten av någon anledning blir otillgänglig kan klienten inte längre skriva till lagringskontot. Följande bild visar scenariot där den primära har blivit otillgänglig, men ingen återställning har skett ännu:
Kunden initierar redundansväxlingen av kontot till den sekundära slutpunkten. Redundansväxlingen uppdaterar DNS-posten som tillhandahålls av Azure Storage så att den sekundära slutpunkten blir den nya primära slutpunkten för ditt lagringskonto, som du ser i följande bild:
Skrivåtkomst återställs för geo-redundanta konton när DNS-posten har uppdaterats och begäranden dirigeras till den nya primära slutpunkten. Befintliga slutpunkter för lagringstjänsten förblir desamma efter redundansväxlingen. Filreferenser och lån behålls inte vid redundans, så klienterna måste demontera och återmontera filresurserna.
Viktigt!
När redundansväxlingen är klar konfigureras lagringskontot så att det är lokalt redundant i den nya primära slutpunkten/regionen. Om du vill återuppta replikeringen till den nya sekundära konfigurerar du kontot för geo-redundans igen.
Tänk på att konvertering av ett lokalt redundant lagringskonto för att använda geo-redundans medför både kostnad och tid. Mer information finns i Tid och kostnad för överflyttning.
Förutse dataförlust
Försiktighet
En redundansväxling av ett konto innebär vanligtvis viss dataförlust. Det är viktigt att förstå konsekvenserna av att initiera en redundansväxling av ett konto.
Eftersom data skrivs asynkront från den primära regionen till den sekundära regionen kanske de senaste skrivningarna ännu inte har kopierats till den sekundära regionen om den primära regionen blir otillgänglig.
När du tvingar fram en redundans går alla data i den primära regionen förlorade eftersom den sekundära regionen blir den nya primära regionen. Den nya primära regionen är konfigurerad för att vara lokalt redundant efter redundansväxlingen.
Alla data som redan har kopierats till den sekundära behålls när redundansväxlingen sker. Alla data som skrivs till den primära som inte också har kopierats till den sekundära kommer dock att förloras permanent.
Kontrollera tidsinställningen för senaste synkronisering
Egenskapen Senaste synkroniseringstid (LST) anger den senaste gången som data från den primära regionen garanterat har skrivits till den sekundära regionen. Alla data som skrivits före den senaste synkroniseringstiden är tillgängliga på den sekundära, medan data som skrivits efter den senaste synkroniseringstiden kanske inte har skrivits till den sekundära och kan gå förlorade. Använd den här egenskapen i händelse av ett avbrott för att beräkna hur mycket data förlust du kan ådra dig genom att initiera en redundansväxling av kontot.
För att säkerställa att filresurser är i ett konsekvent tillstånd när en redundans inträffar skapas en systemögonblicksbild i den primära regionen var 15:e minut och replikeras till den sekundära regionen. När en redundansväxling sker i den sekundära regionen baseras delningstillståndet på den senaste systemögonblicksbilden i den sekundära regionen. Om ett fel inträffar i den primära regionen ligger den sekundära regionen troligen bakom den primära regionen, eftersom alla skrivningar till den primära ännu inte har replikerats till den sekundära. På grund av geofördröjning eller andra problem kan den senaste systemögonblicksbilden i den sekundära regionen vara äldre än 15 minuter.
Alla skrivåtgärder som skrivits till den primära regionen före LST har replikerats till den sekundära regionen, vilket innebär att de är tillgängliga för läsning från den sekundära. Alla skrivåtgärder som skrivs till den primära regionen efter den senaste synkroniseringstiden kan eller inte har replikerats till den sekundära regionen, vilket innebär att de kanske inte är tillgängliga för läsåtgärder.
Du kan fråga efter värdet för egenskapen Senaste synkroniseringstid med hjälp av Azure PowerShell, Azure CLI eller klientbiblioteket. Egenskapen Senaste synkroniseringstid är ett GMT-datum/tid-värde. Mer information finns i Kontrollera egenskapen Senaste synkroniseringstid för ett lagringskonto.
Var försiktig när du växlar tillbaka till den ursprungliga primära
När du har redundansväxlat från den primära till den sekundära regionen konfigureras ditt lagringskonto som tidigare nämnt för att vara lokalt redundant i den nya primära regionen. Du kan sedan konfigurera kontot i den nya primära regionen för geo-redundans. När kontot har konfigurerats för geo-redundans efter en redundans börjar den nya primära regionen omedelbart kopiera data till den nya sekundära regionen, som var den primära före den ursprungliga redundansväxlingen. Det kan dock ta lite tid innan befintliga data i den nya primära kopieras helt till den nya sekundära.
När lagringskontot har konfigurerats om för geo-redundans är det möjligt att initiera en återställning efter fel från den nya primära till den nya sekundära. I det här fallet blir den ursprungliga primära regionen före redundansväxlingen den primära regionen igen och konfigureras för att vara antingen lokalt redundant eller zonredundant, beroende på om den ursprungliga primära konfigurationen var GRS eller GZRS. Alla data i den primära regionen efter redundans (den ursprungliga sekundära) går förlorade under återställningen efter fel. Om de flesta data i lagringskontot inte har kopierats till den nya sekundära innan du växlar tillbaka kan du drabbas av en större dataförlust.
För att undvika en större dataförlust kontrollerar du värdet för egenskapen Senaste synkroniseringstid innan du växlar tillbaka. Jämför den senaste synkroniseringstiden med de senaste tiderna som data skrevs till den nya primära för att utvärdera förväntad dataförlust.
Efter en återställningsåtgärd kan du konfigurera den nya primära regionen så att den blir geo-redundant igen. Om den ursprungliga primära har konfigurerats för LRS kan du konfigurera den så att den är GRS. Om den ursprungliga primära konfigurerades för ZRS kan du konfigurera den så att den är GZRS. Andra alternativ finns i Ändra hur ett lagringskonto replikeras.
Initiera en kontoredundans
Du kan initiera ett konto redundans från Azure Portal, PowerShell, Azure CLI eller API:et för Azure Storage-resursprovidern. Mer information om hur du initierar en redundans finns i Initiera en redundansväxling av ett konto.
Microsoft-hanterad redundans
I extrema fall där en region går förlorad på grund av en betydande katastrof kan Microsoft initiera en regional redundans. I det här fallet krävs ingen åtgärd från din sida. Tills den Microsoft-hanterade redundansen har slutförts har du inte skrivåtkomst till ditt lagringskonto.