Haveriberedskap och redundans för Azure Files
Microsoft strävar efter att säkerställa att Azure-tjänster alltid är tillgängliga. Oplanerade tjänststopp kan dock inträffa och du bör ha en haveriberedskapsplan (DR) på plats för att hantera ett regionalt tjänststopp. En viktig del av en haveriberedskapsplan är att förbereda redundansväxlingen till den sekundära slutpunkten om den primära slutpunkten blir otillgänglig. Den här artikeln beskriver begreppen och processerna som ingår i haveriberedskap (DR) och redundans för lagringskonto.
Viktigt!
Azure File Sync stöder endast redundansväxling av lagringskonton om Tjänsten för synkronisering av lagring också redundansväxlas. Det beror på att Azure File Sync kräver att lagringskontot och Storage Sync Service finns i samma Azure-region. Om endast lagringskontot redundansväxlats misslyckas åtgärderna för synkronisering och molnnivåindelning tills storage sync-tjänsten redundansväxlats 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 läser du Metodtips för haveriberedskap för Azure File Sync och Azure File Sync-serveråterställning.
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 icke-lagringsrelaterade avbrott.
Under den planerade redundansväxlingen växlas de primära och sekundära regionerna. Den ursprungliga primära regionen degraderades och blir den nya sekundära regionen. Samtidigt höjs den ursprungliga sekundära regionen upp och blir den nya primära regionen. 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 redundans- och återställningsprocesserna. Mer information om hur den här processen fungerar finns i Så här fungerar kundhanterad (planerad) redundans.
Viktigt!
Kundhanterad planerad redundans är för närvarande i förhandsversion och är begränsad till följande regioner:
- Frankrike, centrala
- Frankrike, södra
- Indien, centrala
- Indien, västra
- Asien, östra
- Sydostasien
Juridiska villkor för Azure-funktioner i betaversion, förhandsversion eller som av någon annan anledning inte har gjorts allmänt tillgängliga ännu finns i kompletterande användningsvillkor för Microsoft Azure-förhandsversioner.
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.
Viktigt!
Efter en planerad redundansväxling kan ett lagringskontos LST-värde (Last Sync Time) verka inaktuellt eller rapporteras som NULL när Azure Files-data finns.
Systemögonblicksbilder skapas regelbundet i ett lagringskontos sekundära region för att upprätthålla konsekventa återställningspunkter som används vid redundansväxling och återställning efter fel. Om du initierar kundhanterad planerad redundans blir den ursprungliga primära regionen den nya sekundära regionen. I vissa fall finns det inga tillgängliga systemögonblicksbilder på den nya sekundära när den planerade redundansväxlingen har slutförts, vilket gör att kontots övergripande LST-värde visas inaktuellt eller visas som Null.
Eftersom användaraktiviteter som att skapa, ändra eller ta bort objekt kan utlösa skapande av ögonblicksbilder, kommer alla konton där dessa aktiviteter inträffar efter planerad redundansväxling inte att kräva ytterligare uppmärksamhet. Konton som inte har några ögonblicksbilder eller användaraktivitet kan dock fortsätta att visa ett Null LST-värde tills skapandet av systemögonblicksbilden utlöses.
Utför vid behov någon av följande aktiviteter för varje resurs i ett lagringskonto för att utlösa skapandet av ögonblicksbilder. När det är klart bör ditt konto visa ett giltigt LST-värde inom 30 minuter.
- Montera resursen och öppna sedan valfri fil för läsning.
- Ladda upp ett test eller en exempelfil till resursen.
Å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 vid avbrott (mål för återställningspunkter 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 dr ökar vanligtvis med lägre eller noll RPO/RTO. Företag som behöver vara igång om några sekunder efter en katastrof och inte kan upprätthålla någon dataförlust kommer att betala mer för DR, medan de med högre RPO/ RTO-nummer betalar 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 (LRS) eller zonredundant lagring (ZRS). Mer information finns i Redundans för Azure Files.
Azure Files stöder redundans för standardlagringskonton 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 skrivningar till den primära regionen och den sista 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 om hur lång tid det tar att replikera data till den sekundära regionen.
Viktigt!
GRS/GZRS stöds inte för Premium Azure-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 elastiska 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 programmet 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 programmet 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 med den sekundära.
Spåra avbrott
Du kan prenumerera på Azure Service Health-instrumentpanelen för att spåra hälsotillståndet och statusen för Azure Files och andra Azure-tjänster.
Förstå processen för kontoredundansväxling
Med kundhanterad redundansväxling kan du redundansväxla hela lagringskontot till den sekundära regionen om den primära av någon anledning blir otillgänglig. När du tvingar fram en redundansväxling 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 arbetsbelastningen så mycket som möjligt innan du påbörjar ett redundansväxlingskonto.
Information om hur du initierar en redundansväxling för ett konto finns i Initiera en redundansväxling av ett konto.
Så här fungerar kontoredundans
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 gjorts ännu:
Kunden initierar redundansväxlingen 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, enligt 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 lagringstjänstslutpunkter förblir desamma efter redundansväxlingen. Filreferenser och lån behålls inte vid redundans, så klienter måste demontera och montera om filresurserna.
Viktigt!
När redundansväxlingen är klar konfigureras lagringskontot att vara lokalt redundant i den nya primära slutpunkten/regionen. Om du vill återuppta replikeringen till den nya sekundära datorn 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 redväxling.
Förutse dataförlust
Varning
Ett redundansväxlingskonto 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 skrivåtgärderna ä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 när den sekundära regionen blir den nya primära regionen. Den nya primära regionen är konfigurerad att vara lokalt redundant efter redundansväxlingen.
Alla data som redan har kopierats till den sekundära underhålls när redundansväxlingen sker. Men alla data som skrivs till den primära som inte också har kopierats till den sekundära kommer att gå förlorade permanent.
Kontrollera egenskapen Tidpunkt 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 uppskatta hur mycket dataförlust du kan drabbas av genom att initiera ett redundansväxlingskonto.
För att säkerställa att filresurserna är i ett konsekvent tillstånd när en redundansväxling 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 resurstillstå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 regionen. På grund av geo-fö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 regionen. Skrivåtgärder som skrivits till den primära regionen efter den senaste synkroniseringstiden kanske eller kanske 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 köra frågor mot värdet för egenskapen Last Sync Time 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 inte återgår till den ursprungliga primära
Som tidigare nämnts, när du redundansväxlade från den primära till den sekundära regionen, är ditt lagringskonto konfigurerat 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 filen kopieras helt till den nya sekundära.
När lagringskontot har konfigurerats om för geo-redundans kan du 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 är konfigurerad 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 redundansväxlingen (den ursprungliga sekundära) går förlorade under återställningen efter redundansväxlingen. Om de flesta data i lagringskontot inte har kopierats till den nya sekundära enheten innan du växlar tillbaka, kan du drabbas av stora dataförluster.
Om du vill undvika stora dataförluster kontrollerar du värdet för egenskapen Senaste synkroniseringstid innan du säkerhetskopieras. Jämför den senaste synkroniseringstiden med de senaste gångerna som data skrevs till den nya primära för att utvärdera förväntad dataförlust.
Efter en återställning efter fel kan du konfigurera den nya primära regionen så att den blir geo-redundant igen. Om den ursprungliga primära filen har konfigurerats för LRS kan du konfigurera den till GRS. Om den ursprungliga primära var konfigurerad för ZRS kan du konfigurera den till GZRS. Ytterligare alternativ finns i Ändra hur ett lagringskonto replikeras.
Initiera en kontoredundans
Du kan initiera en redundansväxling av ett konto från Azure-portalen, PowerShell, Azure CLI eller Azure Storage-resursprovider-API:et. Mer information om hur du initierar en redundansväxling finns i Initiera en redundansväxling av ett konto.
Microsoft-hanterad redundans
Under extrema omständigheter där en region går förlorad på grund av en betydande katastrof kan Microsoft initiera en regional redundansväxling. I det här fallet krävs ingen åtgärd från din sida. Innan den Microsoft-hanterade redundansväxlingen har slutförts har du inte skrivåtkomst till ditt lagringskonto.