Så här fungerar redundans för kundhanterat lagringskonto

Artikel
06/18/2024

Med kundhanterad redundansväxling av Azure Storage-konton kan du redundansväxla hela ditt geo-redundanta lagringskonto till den sekundära regionen om lagringstjänstens slutpunkter för den primära regionen blir otillgängliga. Under redundansväxlingen blir den ursprungliga sekundära regionen den nya primära och alla lagringstjänstslutpunkter för blobar, tabeller, köer och filer omdirigeras till den nya primära regionen. När avbrott i lagringstjänstens slutpunkt har lösts kan du utföra en annan redundansåtgärd för att återställa till den ursprungliga primära regionen.

Den här artikeln beskriver vad som händer under ett kundhanterat lagringskonto vid redundansväxling och återställning efter fel i varje steg i processen.

Viktigt!

Kundhanterad kontoredundans för konton som har ett hierarkiskt namnområde (Azure Data Lake Storage Gen2) är för närvarande i förhandsversion och stöds endast i följande regioner:

(Asien och stillahavsområdet) Indien, centrala
(Asien och Stillahavsområdet) Sydostasien
(Europa) Europa, norra
(Europa) Schweiz, norra
(Europa) Schweiz, västra
(Europa) Europa, västra
(Nordamerika) Kanada, centrala
(Nordamerika) USA, östra 2
(Nordamerika) USA, södra centrala

Om du vill anmäla dig till förhandsversionen läser du Konfigurera förhandsversionsfunktioner i Azure-prenumerationen och anger AllowHNSAccountFailover som funktionsnamn.

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.

I händelse av en betydande katastrof som påverkar den primära regionen hanterar Microsoft redundansväxlingen för konton med ett hierarkiskt namnområde. Mer information finns i Microsoft-hanterad redundans.

Redundanshantering under redundans och återställning efter fel

Dricks

Information om de olika redundanstillstånden under redundansväxlingen för lagringskontot och återställning efter fel finns i Azure Storage-redundans för definitioner av var och en.

När ett lagringskonto har konfigurerats för GRS- eller RA-GRS-redundans replikeras data tre gånger lokalt inom både de primära och sekundära regionerna (LRS). När ett lagringskonto har konfigurerats för GZRS- eller RA-GZRS-replikering är data zonredundanta inom den primära regionen (ZRS) och replikeras tre gånger lokalt inom den sekundära regionen (LRS). Om kontot har konfigurerats för läsåtkomst (RA) kan du läsa data från den sekundära regionen så länge lagringstjänstens slutpunkter till den regionen är tillgängliga.

Under den kundhanterade redundansväxlingsprocessen ändras DNS-posterna för lagringstjänstens slutpunkter så att de för den sekundära regionen blir de nya primära slutpunkterna för ditt lagringskonto. Efter redundansen tas kopian av ditt lagringskonto i den ursprungliga primära regionen bort och lagringskontot fortsätter att replikeras tre gånger lokalt inom den ursprungliga sekundära regionen (den nya primära). Då blir ditt lagringskonto lokalt redundant (LRS).

De ursprungliga och aktuella redundanskonfigurationerna lagras i egenskaperna för lagringskontot så att du så småningom kan återgå till den ursprungliga konfigurationen när du växlar tillbaka.

För att återfå geo-redundans efter en redundansväxling måste du konfigurera om ditt konto som GRS. (GZRS är inte ett alternativ efter redundans eftersom den nya primära är LRS efter redundansväxlingen). När kontot har konfigurerats om för geo-redundans börjar Azure omedelbart kopiera data från den nya primära regionen till den nya sekundära regionen. Om du konfigurerar ditt lagringskonto för läsåtkomst (RA) till den sekundära regionen blir den åtkomsten tillgänglig, men det kan ta lite tid för replikering från den primära att göra den sekundära aktuell.

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.

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 potentiell dataförlust.

Återställningsprocessen är i stort sett densamma som redundansväxlingen, förutom att Azure återställer replikeringskonfigurationen till sitt ursprungliga tillstånd innan den redundansvästs (replikeringskonfigurationen, inte data). Så om ditt lagringskonto ursprungligen konfigurerades som GZRS blir den primära regionen efter återställning efter redundansväxling ZRS.

Efter återställning efter fel kan du konfigurera lagringskontot så att det är geo-redundant igen. Om den ursprungliga primära regionen har konfigurerats för LRS kan du konfigurera den till GRS eller RA-GRS. Om den ursprungliga primära var konfigurerad som ZRS kan du konfigurera den till GZRS eller RA-GZRS. Ytterligare alternativ finns i Ändra hur ett lagringskonto replikeras.

Initiera en redundansväxling

Information om hur du initierar en redundansväxling finns i Initiera redundans för ett lagringskonto.

Varning

Redundansväxling för lagringskonton innebär vanligtvis viss dataförlust och potentiellt inkonsekvenser i fil- och data. Det är viktigt att förstå vilken inverkan ett konto redundansväxling skulle ha på dina data innan du initierar en.

Mer information om potentiella dataförluster och inkonsekvenser finns i Förutse dataförlust och inkonsekvenser.

Redundans- och återställningsprocessen

I det här avsnittet sammanfattas redundansväxlingen för en kundhanterad redundansväxling.

Sammanfattning av redundansövergång

Efter en kundhanterad redundansväxling:

Den sekundära regionen blir den nya primära regionen
Kopian av data i den ursprungliga primära regionen tas bort
Lagringskontot konverteras till LRS
Geo-redundans går förlorad

Den här tabellen sammanfattar den resulterande redundanskonfigurationen i varje steg i en kundhanterad redundansväxling och återställning efter fel:

Original konfiguration	Efter redundans	Efter återaktivering geo-redundans	Efter återställning efter fel	Efter återaktivering geo-redundans
GRS	LRS	GRS ¹	LRS	GRS ¹
GZRS	LRS	GRS ¹	ZRS	GZRS ¹

¹ Geo-redundans går förlorad under en kundhanterad redundans och måste konfigureras om manuellt.

Information om redundansövergång

Följande diagram visar vad som händer vid kundhanterad redundans och återställning efter fel för ett lagringskonto som har konfigurerats för geo-redundans. Övergångsdetaljerna för GZRS och RA-GZRS skiljer sig något från GRS och RA-GRS.

GRS/RA-GRS
GZRS/RA-GZRS

Normal drift (GRS/RA-GRS)

Under normala omständigheter skriver en klient data till ett lagringskonto i den primära regionen via lagringstjänstslutpunkter (1). Data kopieras sedan asynkront från den primära regionen till den sekundära regionen (2). Följande bild visar det normala tillståndet för ett lagringskonto som konfigurerats som GRS när de primära slutpunkterna är tillgängliga:

Lagringstjänstens slutpunkter blir otillgängliga i den primära regionen (GRS/RA-GRS)

Om de primära lagringstjänstslutpunkterna blir otillgängliga av någon anledning (1) kan klienten inte längre skriva till lagringskontot. Beroende på den underliggande orsaken till avbrottet kanske replikeringen till den sekundära regionen inte längre fungerar (2), så viss dataförlust bör förväntas. Följande bild visar scenariot där de primära slutpunkterna har blivit otillgängliga, men ingen återställning har inträffat ännu:

Redundansväxlingsprocessen (GRS/RA-GRS)

Om du vill återställa skrivåtkomsten till dina data kan du initiera en redundansväxling. URI:er för lagringstjänstens slutpunkt för blobar, tabeller, köer och filer förblir desamma, men deras DNS-poster ändras så att de pekar på den sekundära regionen (1) som visas i den här bilden:

Kundhanterad redundans tar vanligtvis ungefär en timme.

När redundansväxlingen är klar blir den ursprungliga sekundära den nya primära (1) och kopian av lagringskontot i den ursprungliga primära enheten tas bort (2). Lagringskontot är konfigurerat som LRS i den nya primära regionen och är inte längre geo-redundant. Användare kan återuppta skrivning av data till lagringskontot (3) enligt bilden:

Om du vill återuppta replikeringen till en ny sekundär region konfigurerar du om kontot för geo-redundans.

Viktigt!

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.

När du har konfigurerat om kontot som GRS börjar Azure kopiera dina data asynkront till den nya sekundära regionen (1) som du ser i den här bilden:

Läsåtkomst till den nya sekundära regionen blir inte tillgänglig igen förrän problemet som orsakade det ursprungliga avbrottet har lösts.

Återställningsprocessen (GRS/RA-GRS)

Varning

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

När problemet som orsakade det ursprungliga driftstoppet har lösts kan du initiera en annan redundansväxling för att återställa till den ursprungliga primära regionen, vilket resulterar i följande:

Den aktuella primära regionen blir skrivskyddad.
Med kundinitierad redundans och återställning efter fel kan dina data inte slutföra replikeringen till den sekundära regionen under återställningen efter fel. Därför är det viktigt att kontrollera värdet för egenskapen Senaste synkroniseringstid innan du säkerhetskopieras.
DNS-posterna för lagringstjänstens slutpunkter ändras så att de för den sekundära regionen blir de nya primära slutpunkterna för ditt lagringskonto.

När återställningen efter fel har slutförts blir den ursprungliga primära regionen den aktuella igen (1) och kopian av lagringskontot i den ursprungliga sekundära regionen tas bort (2). Lagringskontot är konfigurerat som lokalt redundant i den primära regionen och är inte längre geo-redundant. Användare kan återuppta skrivning av data till lagringskontot (3) enligt bilden:

Om du vill återuppta replikeringen till den ursprungliga sekundära regionen konfigurerar du kontot för geo-redundans igen.

Viktigt!

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.

När kontot har konfigurerats om som GRS återupptas replikeringen till den ursprungliga sekundära regionen enligt bilden: