Så här fungerar kundhanterad (oplanerad) redundans

Med kundhanterad (oplanerad) redundansväxling kan du redundansväxla hela ditt geo-redundanta lagringskonto till den sekundära regionen om lagringstjänstslutpunkterna för den primära regionen blir otillgängliga. Under redundansväxlingen blir den ursprungliga sekundära regionen den nya primära regionen. Alla lagringstjänstslutpunkter omdirigeras sedan 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 en kundhanterad (oplanerad) redundansväxling och återställning efter fel i varje steg i processen.

Viktigt!

Kundhanterad (oplanerad) redundansväxling för konton som har Azure Data Lake Storage Gen2 aktiverat är för närvarande i förhandsversion och stöds i alla offentliga GRS/GZRS-regioner.

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

Viktigt!

Kundhanterad (oplanerad) redundansväxling för konton som har SSH File Transfer Protocol (SFTP) aktiverat ä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 oplanerad redundans och återställning efter fel

Dricks

Information om de olika redundanstillstånden under den oplanerade redundans- och återställningsprocessen finns i Azure Storage-redundans för definitioner av var och en.

När ett lagringskonto har konfigurerats för geo-redundant lagring (GRS) eller geo-redundant lagringsredundans för läsåtkomst (RA-GRS) replikeras data tre gånger inom både de lokalt redundanta primära och sekundära regionerna för lagring (LRS). När ett lagringskonto har konfigurerats för geo-zonredundant lagring (GZRS) eller replikering med läsåtkomst till geo-zonredundant lagring (RA-GZRS) är data zonredundanta i den zonredundanta lagringsregionen (ZRS) och replikeras tre gånger inom den sekundära LRS-regionen. 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 (oplanerade) redundansväxlingsprocessen växlas DNS-posterna (Domain Name System) för lagringstjänstens slutpunkter. Lagringskontots sekundära slutpunkter blir de nya primära slutpunkterna och de ursprungliga primära slutpunkterna blir den nya sekundära. 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 nya primära regionen. Då blir ditt lagringskonto lokalt redundant och använder LRS.

De ursprungliga och aktuella redundanskonfigurationerna lagras i lagringskontots egenskaper. Med den här funktionen kan du återgå till den ursprungliga konfigurationen när du växlar tillbaka. En fullständig lista över resulterande redundanskonfigurationer finns i Återställningsplanering och redundans.

För att återfå geo-redundans efter en redundansväxling måste du konfigurera om ditt konto som GRS. 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 till den sekundära regionen är den åtkomsten tillgänglig. Replikeringen från den primära till den sekundära regionen kan dock ta lite tid att slutföra.

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

Återställningsprocessen är i stort sett densamma som redundansväxlingen, förutom att replikeringskonfigurationen återställs till det ursprungliga tillståndet före redundansväxlingen.

Efter återställning efter fel kan du konfigurera om ditt lagringskonto för att dra nytta av geo-redundans. Om den ursprungliga primära var konfigurerad som ZRS kan du konfigurera den till GZRS eller RA-GZRS. Fler alternativ finns i Ändra hur ett lagringskonto replikeras.

Initiera en oplanerad redundans

Information om hur du initierar en oplanerad redundansväxling finns i Initiera en redundansväxling av ett konto.

Varning

Oplanerad redundans innebär vanligtvis viss dataförlust och potentiellt fil- och datainkonsekvenser. Det är viktigt att förstå vilken inverkan ett konto redundansväxling skulle ha på dina data innan du initierar den här typen av redundans.

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

Den oplanerade redundans- och återställningsprocessen

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

Översikt över oplanerad redundansövergång

Efter en kundhanterad (oplanerad) 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 (oplanerad) 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 1	LRS	GRS 1
GZRS	LRS	GRS 1	ZRS	GZRS 1

¹ Geo-redundans går förlorad under en kundhanterad (oplanerad) redundansväxling och måste konfigureras om manuellt.

Oplanerad redundansövergångsinformation

Följande diagram visar den kundhanterade (oplanerade) redundans- och återställningsprocessen för ett lagringskonto som 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

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 blir otillgängliga, men innan återställningen sker:

Den oplanerade redundansprocessen (GRS/RA-GRS)

Om du vill återställa skrivåtkomsten till dina data kan du initiera en redundansväxling. Lagringstjänstens slutpunkts-URI:er för blobar, tabeller, köer och filer förblir oförändrade, men deras DNS-poster ändras så att de pekar på den sekundära regionen enligt följande:

Kundhanterad (oplanerad) 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 konfigureras 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), som du ser i den här 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 för att använda GRS börjar Azure kopiera dina data asynkront till den nya sekundära regionen (1) enligt följande bild:

Läsbehörigheten till den nya sekundära regionen är inte tillgänglig igen förrän problemet som orsakade det ursprungliga driftstoppet har lösts.

Den oplanerade å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.

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.

När problemet som orsakade det ursprungliga avbrottet har lösts kan du initiera återställning efter fel till den ursprungliga primära regionen. Den här processen beskrivs i följande bild:

1. Den aktuella primära regionen blir skrivskyddad.
2. 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.
3. DNS-posterna för lagringstjänstens slutpunkter växlas. Slutpunkterna i 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), som du ser i den här bilden:

Om du vill återuppta replikeringen till den ursprungliga sekundära regionen 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 kontot har konfigurerats om som GRS återupptas replikeringen till den ursprungliga sekundära regionen enligt bilden:

GZRS/RA-GZRS

Normal drift (GZRS/RA-GZRS)

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 GZRS när de primära slutpunkterna är tillgängliga:

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

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 sker (2), så viss dataförlust bör förväntas. Följande bild visar scenariot där de primära slutpunkterna inte är tillgängliga, men innan återställningen sker:

Den oplanerade redundansprocessen (GZRS/RA-GZRS)

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:

Redundansväxlingen 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 konfigureras 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), som du ser i den här bilden:

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

Eftersom kontot ursprungligen konfigurerades som GZRS kan omkonfiguration av geo-redundans efter redundans göra att den ursprungliga ZRS-redundansen i den nya sekundära regionen (den ursprungliga primära) behålls. Redundanskonfigurationen inom den aktuella primären avgör dock alltid den effektiva geo-redundansen för ett lagringskonto. Eftersom den aktuella primära i det här fallet är LRS är den effektiva geo-redundansen i det här läget GRS, inte GZRS.

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 är inte tillgänglig igen förrän det ursprungliga avbrottet har lösts.

Den oplanerade återställningsprocessen (GZRS/RA-GZRS)

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.

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.

När problemet som orsakade det ursprungliga avbrottet har lösts kan du initiera återställning efter fel till den ursprungliga primära regionen. Den här processen beskrivs i följande bild:

1. Den aktuella primära regionen blir skrivskyddad.
2. Under kundinitierad redundansväxling 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.
3. DNS-posterna för lagringstjänstens slutpunkter växlas. De sekundära slutpunkterna 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 ZRS i den primära regionen och är inte längre geo-redundant. Användare kan återuppta skrivning av data till lagringskontot (3), som du ser i den här bilden:

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

Viktigt!

Tänk på att konvertering av ett ZRS-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 GZRS återupptas replikeringen till den ursprungliga sekundära regionen enligt den här bilden:

Se även

• Planering och redundans för haveriberedskap
• Redundans i Azure Storage
• Initiera en redundansväxling av ett konto