Så här fungerar kundhanterad planerad redundans (förhandsversion)
Kundhanterad planerad redundans kan vara användbar i scenarier som planering och testning av haveriberedskap, proaktiv reparation av förväntade storskaliga katastrofer och avbrott relaterade till icke-lagring.
Under den planerade redundansväxlingen växlas lagringskontots primära och sekundära regioner. Den ursprungliga primära regionen degraderas och blir den nya sekundära medan den ursprungliga sekundära regionen höjs upp och blir den nya primära regionen. Lagringskontot måste vara tillgängligt i både de primära och sekundära regionerna innan en planerad redundansväxling kan initieras.
Den här artikeln beskriver vad som händer under en kundhanterad planerad redundansväxling och återställning efter fel i varje steg i processen. Information om hur en redundansväxling på grund av ett oväntat avbrott i lagringsslutpunkten fungerar finns i Så här fungerar kundhanterad (oplanerad) redundansväxling.
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.
Redundanshantering under planerad redundansväxling och återställning efter fel
Dricks
Information om varierande redundanstillstånd under kundhanterad redundans och återställning efter fel finns i Azure Storage-redundans för definitioner av var och en.
Under den planerade redundansväxlingsprocessen blir den primära regionens lagringstjänstslutpunkter skrivskyddade medan återstående uppdateringar slutför replikeringen till den sekundära regionen. Därefter växlas alla DNS-poster (Domain Name Service) för alla lagringstjänstslutpunkter. Lagringskontots sekundära slutpunkter blir de nya primära slutpunkterna och de ursprungliga primära slutpunkterna blir den nya sekundära. Datareplikeringen inom varje region förblir oförändrad trots att de primära och sekundära regionerna växlas.
Den planerade återställningsprocessen är i stort sett densamma som den planerade redundansprocessen, men med ett undantag. Under planerad återställning efter fel lagrar Azure den ursprungliga redundanskonfigurationen för ditt lagringskonto och återställer det till sitt ursprungliga tillstånd vid återställning efter fel. Om ditt lagringskonto till exempel ursprungligen konfigurerades som GZRS blir lagringskontot GZRS efter återställning efter fel.
Kommentar
Till skillnad från kundhanterad (oplanerad) redundansväxling måste replikering från den primära till den sekundära regionen slutföras under planerad redundansväxling innan DNS-posterna för slutpunkterna ändras till den nya sekundära. På grund av detta förväntas dataförlust inte under planerad redundans eller återställning efter fel så länge både de primära och sekundära regionerna är tillgängliga under hela processen.
Initiera en redundansväxling
Information om hur du initierar en redundansväxling finns i Initiera en redundansväxling av ett konto.
Den planerade redundans- och återställningsprocessen
Följande diagram visar vad som händer under en kundhanterad planerad redundansväxling och återställning efter fel för ett lagringskonto.
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:
Den planerade redundansväxlingsprocessen (GRS/RA-GRS)
Påbörja haveriberedskapstestning genom att initiera en redundansväxling av ditt lagringskonto till den sekundära regionen. Följande steg beskriver redundansprocessen och den efterföljande bilden visar en bild:
- Den ursprungliga primära regionen blir skrivskyddad.
- Replikeringen av alla data från den primära regionen till den sekundära regionen slutförs.
- DNS-poster för lagringstjänstslutpunkter i den sekundära regionen höjs upp och blir de nya primära slutpunkterna för ditt lagringskonto.
Redundansväxlingen tar vanligtvis ungefär en timme.
När redundansväxlingen är klar blir den ursprungliga primära regionen den nya sekundära (1) och den ursprungliga sekundära regionen blir den nya primära (2). URI:erna för lagringstjänstens slutpunkter för blobar, tabeller, köer och filer förblir desamma, men deras DNS-poster ändras så att de pekar på den nya primära regionen (3). Användare kan återuppta skrivning av data till lagringskontot i den nya primära regionen, och data kopieras sedan asynkront till den nya sekundära (4) som visas i följande bild:
När du är i redundanstillståndet utför du din haveriberedskapstestning.
Den planerade återställningsprocessen (GRS/RA-GRS)
När testningen är klar utför du ytterligare en redundansväxling till den ursprungliga primära regionen. Under redundansväxlingen, som du ser i följande bild:
- Den ursprungliga primära regionen blir skrivskyddad.
- Alla data slutför replikeringen från den aktuella primära regionen till den aktuella sekundära regionen.
- DNS-posterna för lagringstjänstens slutpunkter ändras så att de pekar tillbaka till den region som var den primära innan den första redundansväxlingen utfördes.
Återställning efter fel tar vanligtvis ungefär en timme.
När återställningen har slutförts återställs lagringskontot till den ursprungliga redundanskonfigurationen. Användare kan återuppta skrivning av data till lagringskontot i den ursprungliga primära regionen (1) medan replikeringen till den ursprungliga sekundära (2) fortsätter som före redundansväxlingen:
