Planering och redundans vid haveriberedskap i Azure Storage

  • Artikel

Microsoft strävar efter att säkerställa att Azure-tjänster alltid är tillgängliga. Oplanerade driftstopp kan dock inträffa. Viktiga komponenter i en bra haveriberedskapsplan är strategier för:

Den här artikeln fokuserar på redundans för globalt redundanta lagringskonton (GRS, GZRS och RA-GZRS) och hur du utformar dina program så att de är mycket tillgängliga om det uppstår ett avbrott och efterföljande redundans.

Välj rätt redundansalternativ

Azure Storage har flera kopior av ditt lagringskonto för att säkerställa hållbarhet och hög tillgänglighet. Vilket redundansalternativ du väljer för ditt konto beror på vilken återhämtningsgrad du behöver för dina program.

Med lokalt redundant lagring (LRS) lagras och replikeras tre kopior av ditt lagringskonto automatiskt i ett enda datacenter. Med zonredundant lagring (ZRS) lagras och replikeras en kopia i var och en av tre separata tillgänglighetszoner inom samma region. Mer information om tillgänglighetszoner finns i Azure-tillgänglighetszoner.

Återställning av en enda kopia av ett lagringskonto sker automatiskt med LRS och ZRS.

Globalt redundant lagring och redundans

Med globalt redundant lagring (GRS, GZRS och RA-GZRS) kopierar Azure dina data asynkront till en sekundär geografisk region minst hundratals mil bort. På så sätt kan du återställa dina data om det uppstår ett avbrott i den primära regionen. En funktion som skiljer globalt redundant lagring från LRS och ZRS är möjligheten att redundansväxla till den sekundära regionen om det uppstår ett avbrott i den primära regionen. Redundansväxlingen uppdaterar DNS-posterna för lagringskontots tjänstslutpunkter så att slutpunkterna för den sekundära regionen blir de nya primära slutpunkterna för ditt lagringskonto. När redundansväxlingen är klar kan klienterna börja skriva till de nya primära slutpunkterna.

RA-GRS- och RA-GZRS-redundanskonfigurationer ger geo-redundant lagring med den extra fördelen med läsåtkomst till den sekundära slutpunkten om det uppstår ett avbrott i den primära regionen. Om ett avbrott inträffar i den primära slutpunkten kan program som konfigurerats för läsåtkomst till den sekundära regionen och som är utformade för hög tillgänglighet fortsätta att läsa från den sekundära slutpunkten. Microsoft rekommenderar RA-GZRS för maximal tillgänglighet och hållbarhet för dina lagringskonton.

Mer information om redundans i Azure Storage finns i Azure Storage-redundans.

Planera redundans för lagringskonto

Azure Storage-konton stöder två typer av redundans:

  • Kundhanterad redundans – Kunder kan hantera redundansväxling av lagringskonton om det uppstår ett oväntat avbrott i tjänsten.
  • Microsoft-hanterad redundans – Potentiellt initierad av Microsoft endast vid en allvarlig katastrof i den primära regionen. 1,2

1Microsoft-hanterad redundans kan inte initieras för enskilda lagringskonton, prenumerationer eller klientorganisationer. Mer information finns i Microsoft-hanterad redundansväxling.
2 Din haveriberedskapsplan bör baseras på kundhanterad redundans. Förlita dig inte på Microsoft-hanterad redundans, som endast skulle användas under extrema omständigheter.

Varje typ av redundans har en unik uppsättning användningsfall, motsvarande förväntningar på dataförlust och stöd för konton med ett hierarkiskt namnområde aktiverat (Azure Data Lake Storage Gen2). Den här tabellen sammanfattar dessa aspekter av varje typ av redundans :

Typ Redundansomfång Användningsfall Förväntad dataförlust HNS stöds
Kundhanterad Lagringskonto Lagringstjänstens slutpunkter för den primära regionen blir otillgängliga, men den sekundära regionen är tillgänglig.

Du har fått en Azure Advisory där Microsoft rekommenderar att du utför en redundansåtgärd av lagringskonton som kan påverkas av ett avbrott.		 Ja Ja (i förhandsversion)
Microsoft-hanterad Hela regionen eller skalningsenheten Den primära regionen blir helt otillgänglig på grund av en betydande katastrof, men den sekundära regionen är tillgänglig. Ja Ja

Kundhanterad redundans

Om dataslutpunkterna för lagringstjänsterna i ditt lagringskonto blir otillgängliga i den primära regionen kan du redundansväxla till den sekundära regionen. När redundansväxlingen är klar blir den sekundära regionen den nya primära regionen och användarna kan fortsätta att komma åt data i den nya primära regionen.

För att fullt ut förstå vilken inverkan kundhanterad kontoredundans skulle ha på dina användare och program är det bra att veta vad som händer under varje steg i redundansväxlingen och redundansväxlingen. Mer information om hur processen fungerar finns i Så här fungerar kundhanterad redundans för lagringskonto.

Microsoft-hanterad redundans

Under extrema omständigheter där den ursprungliga primära regionen bedöms vara oåterkallelig inom rimlig tid på grund av en större 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. Dina program kan läsa från den sekundära regionen om ditt lagringskonto har konfigurerats för RA-GRS eller RA-GZRS.

Viktigt!

Din haveriberedskapsplan bör baseras på kundhanterad redundans. Förlita dig inte på Microsoft-hanterad redundans, som kanske bara används under extrema omständigheter. En Microsoft-hanterad redundansväxling initieras för en hel fysisk enhet, till exempel en region eller skalningsenhet. Det kan inte initieras för enskilda lagringskonton, prenumerationer eller klientorganisationer. Använd kundhanterad kontoredundans för att selektivt redundansväxlara dina enskilda lagringskonton.

Förutse dataförlust och inkonsekvenser

Varning

Redundansväxling för lagringskonton innebär vanligtvis viss dataförlust och potentiellt inkonsekvenser i fil- och data. I din haveriberedskapsplan är det viktigt att tänka på vilken inverkan en kontoredundans skulle ha på dina data innan du initierar en.

Eftersom data skrivs asynkront från den primära regionen till den sekundära regionen uppstår alltid en fördröjning innan en skrivning till den primära regionen kopieras till den sekundära regionen. Om den primära regionen blir otillgänglig kanske de senaste skrivningar ännu inte har kopierats till den sekundära regionen.

När en redundansväxling inträffar går alla data i den primära regionen förlorade när den sekundära regionen blir den nya primära. 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 regionen går förlorade permanent.

Den nya primära regionen är konfigurerad att vara lokalt redundant (LRS) efter redundansväxlingen.

Du kan också uppleva inkonsekvenser i filer eller data om dina lagringskonton har ett eller flera av följande aktiverade:

Senaste synkronisering

Egenskapen Senaste synkroniseringstid anger den senaste gången som data från den primära regionen garanterat har skrivits till den sekundära regionen. För konton som har ett hierarkiskt namnområde gäller samma egenskap för senaste synkroniseringstid även för metadata som hanteras av det hierarkiska namnområdet, inklusive ACL:er. Alla data och metadata som skrivits före den senaste synkroniseringstiden är tillgängliga på den sekundära, medan data och metadata 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 om det uppstår ett avbrott för att uppskatta hur mycket dataförlust du kan drabbas av genom att initiera ett redundansväxlingskonto.

Vi rekommenderar att du utformar ditt program så att du kan använda den senaste synkroniseringstiden 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.

Mer information om hur du kontrollerar egenskapen Senaste synkroniseringstid finns i Kontrollera egenskapen Senaste synkroniseringstid för ett lagringskonto.

Filkonsekvens för Azure Data Lake Storage Gen2

Replikering för lagringskonton med ett hierarkiskt namnområde aktiverat (Azure Data Lake Storage Gen2) sker på filnivå. Det innebär att om ett avbrott i den primära regionen inträffar är det möjligt att endast några av filerna i en container eller katalog kan ha replikerats till den sekundära regionen. Konsekvens för alla filer i en container eller katalog efter redundansväxling av ett lagringskonto garanteras inte.

Inkonsekvenser för ändringsflöde och blobdata

Redundansväxling av lagringskonto för geo-redundanta lagringskonton med ändringsflöde aktiverat kan leda till inkonsekvenser mellan ändringsflödesloggarna och blobdata och/eller metadata. Sådana inkonsekvenser kan bero på den asynkrona karaktären hos båda uppdateringarna av ändringsloggarna och replikeringen av blobdata från den primära till den sekundära regionen. Den enda situation där inkonsekvenser inte skulle förväntas är när alla aktuella loggposter har tömts till loggfilerna och alla lagringsdata har replikerats från den primära till den sekundära regionen.

Information om hur ändringsflöde fungerar finns i Så här fungerar ändringsflödet.

Tänk på att andra funktioner för lagringskonton kräver att ändringsflödet aktiveras, till exempel driftsäkerhetskopiering av Azure Blob Storage, objektreplikering och återställning till tidpunkt för blockblobar.

Inkonsekvenser vid återställning till tidpunkt

Kundhanterad redundans stöds för lagringskonton på standardnivå för generell användning v2 som innehåller blockblobar. Om du utför en kundhanterad redundansväxling på ett lagringskonto återställs dock den tidigaste möjliga återställningspunkten för kontot. Data för återställning till tidpunkt för blockblobar är bara konsekventa fram till redundansens slutförandetid. Därför kan du bara återställa blockblobar till en tidpunkt som inte är tidigare än redundansens slutförandetid. Du kan kontrollera redundansens slutförandetid på redundansfliken för ditt lagringskonto i Azure-portalen.

Anta till exempel att du har angett kvarhållningsperioden till 30 dagar. Om mer än 30 dagar har förflutit sedan redundansväxlingen kan du återställa till vilken punkt som helst inom de 30 dagarna. Men om färre än 30 dagar har förflutit sedan redundansväxlingen kan du inte återställa till en punkt före redundansväxlingen, oavsett kvarhållningsperiod. Om det till exempel har gått 10 dagar sedan redundansväxlingen är den tidigaste möjliga återställningspunkten 10 dagar tidigare, inte 30 dagar tidigare.

Tid och kostnad för rederover

Den tid det tar för redundansväxlingen att slutföras när den har initierats kan variera, även om det vanligtvis tar mindre än en timme.

En kundhanterad redundans förlorar sin geo-redundans efter en redundansväxling (och återställning efter fel). Ditt lagringskonto konverteras automatiskt till lokalt redundant lagring (LRS) i den nya primära regionen under en redundansväxling och lagringskontot i den ursprungliga primära regionen tas bort.

Du kan återaktivera geo-redundant lagring (GRS) eller geo-redundant lagring med läsbehörighet (RA-GRS) för kontot, men observera att konvertering från LRS till GRS eller RA-GRS medför en extra kostnad. Kostnaden beror på utgående avgifter för nätverket för att replikera data till den nya sekundära regionen. Dessutom måste alla arkiverade blobar extraheras till en onlinenivå innan kontot kan konfigureras för geo-redundans, vilket medför en kostnad. Mer information om priser finns i:

När du har återaktiverat GRS för ditt lagringskonto börjar Microsoft replikera data i ditt konto till den nya sekundära regionen. Replikeringstiden beror på många faktorer, bland annat:

  • Antalet och storleken på objekten i lagringskontot. Det kan ta längre tid att replikera många små objekt än att replikera färre och större objekt.
  • Tillgängliga resurser för bakgrundsreplikering, till exempel PROCESSOR, minne, disk och WAN-kapacitet. Livetrafik prioriteras framför geo-replikering.
  • Om ditt lagringskonto innehåller blobar, antalet ögonblicksbilder per blob.
  • Om ditt lagringskonto innehåller tabeller, strategin för datapartitionering. Replikeringsprocessen kan inte skalas utöver det antal partitionsnycklar som du använder.

Lagringskontotyper som stöds

Alla geo-redundanta erbjudanden stöder Microsoft-hanterad redundans. Dessutom stöder vissa kontotyper kundhanterad kontoredundans, enligt följande tabell:

Typ av redundans GRS/RA-GRS GZRS/RA-GZRS
Kundhanterad redundans Allmänna v2-konton
Allmänna v1-konton
Äldre Blob Storage-konton		 General-purpose v2-konton (GPv2)
Microsoft-hanterad redundans Alla kontotyper General-purpose v2-konton (GPv2)

Klassiska lagringskonton

Viktigt!

Kundhanterad kontoredundans stöds endast för lagringskonton som distribueras med hjälp av Distributionsmodellen för Azure Resource Manager (ARM). Distributionsmodellen för Azure Service Manager (ASM), även kallad klassisk, stöds inte. Om du vill göra klassiska lagringskonton berättigade till kundhanterad kontoredundans måste de först migreras till ARM-modellen. Lagringskontot måste vara tillgängligt för att utföra uppgraderingen, så den primära regionen kan för närvarande inte vara i ett feltillstånd.

Om det uppstår en katastrof som påverkar den primära regionen hanterar Microsoft redundansväxlingen för klassiska lagringskonton. Mer information finns i Microsoft-hanterad redundans.

Azure Data Lake Storage Gen2

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.

Om det uppstår 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.

Funktioner och tjänster som inte stöds

Följande funktioner och tjänster stöds inte för redundansväxling av konton:

  • Azure File Sync stöder inte kundinitierad redundansväxling av lagringskonton. Lagringskonton som innehåller Azure-filresurser som används som molnslutpunkter i Azure File Sync bör inte växlas över. Om du gör det slutar synkroniseringen att fungera och det kan leda till oväntade dataförluster för nyligen nivåbaserade filer. Mer information finns i Metodtips för haveriberedskap med Azure File Sync för mer information.
  • Ett lagringskonto som innehåller Premium-blockblobar kan inte redundas över. Lagringskonton som stöder Premium-blockblobar stöder för närvarande inte geo-redundans.
  • Kundhanterad redundans stöds inte för varken källkontot eller målkontot i en objektreplikeringsprincip.
  • Om du vill redundansväxlara ett konto med SSH File Transfer Protocol (SFTP) aktiverat måste du först inaktivera SFTP för kontot. Om du vill fortsätta använda SFTP när redundansväxlingen är klar aktiverar du den igen.
  • NFS (Network File System) 3.0 (NFSv3) stöds inte för redundansväxling av lagringskonton. Du kan inte skapa ett lagringskonto som konfigurerats för global redundans med NFSv3 aktiverat.

Redundansväxling är inte för kontomigrering

Redundansväxling av lagringskonton bör inte användas som en del av din strategi för datamigrering. Redundans är en tillfällig lösning på ett tjänstfel. Information om hur du migrerar dina lagringskonton finns i Översikt över Azure Storage-migrering.

Lagringskonton som innehåller arkiverade blobar

Lagringskonton som innehåller arkiverade blobar stöder redundansväxling av konton. Men när en kundhanterad redundans har slutförts måste alla arkiverade blobar extraheras till en onlinenivå innan kontot kan konfigureras för geo-redundans.

Lagringsresursprovider

Microsoft tillhandahåller två REST-API:er för att arbeta med Azure Storage-resurser. Dessa API:er utgör grunden för alla åtgärder som du kan utföra mot Azure Storage. Med REST-API:et för Azure Storage kan du arbeta med data i ditt lagringskonto, inklusive blob-, kö-, fil- och tabelldata. Med REST-API:et för Azure Storage-resursprovidern kan du hantera lagringskontot och relaterade resurser.

När en redundansväxling är klar kan klienterna läsa och skriva Azure Storage-data igen i den nya primära regionen. Azure Storage-resursprovidern redundansväxlar dock inte, så resurshanteringsåtgärder måste fortfarande utföras i den primära regionen. Om den primära regionen inte är tillgänglig kan du inte utföra hanteringsåtgärder på lagringskontot.

Eftersom Azure Storage-resursprovidern inte redundansväxlar returnerar egenskapen Location den ursprungliga primära platsen när redundansväxlingen är klar.

Virtuella Azure-datorer

Virtuella Azure-datorer redundansväxlar inte som en del av ett redundansväxlingskonto. Om den primära regionen blir otillgänglig och du redundansväxlar till den sekundära regionen måste du återskapa alla virtuella datorer efter redundansväxlingen. Det finns också en potentiell dataförlust som är associerad med redundansväxlingen för kontot. Microsoft rekommenderar att du följer riktlinjerna för hög tillgänglighet och haveriberedskap som är specifika för virtuella datorer i Azure.

Tänk på att alla data som lagras på en tillfällig disk går förlorade när den virtuella datorn stängs av.

Ohanterade Azure-diskar

Som bästa praxis rekommenderar Microsoft att du konverterar ohanterade diskar till hanterade diskar. Men om du behöver redundansväxla ett konto som innehåller ohanterade diskar som är anslutna till virtuella Azure-datorer måste du stänga av den virtuella datorn innan du påbörjar redundansväxlingen.

Ohanterade diskar lagras som sidblobar i Azure Storage. När en virtuell dator körs i Azure hyrs alla ohanterade diskar som är anslutna till den virtuella datorn ut. Ett redundansväxlingskonto kan inte fortsätta när det finns ett lån på en blob. Följ dessa steg för att utföra redundansväxlingen:

  1. Innan du börjar bör du notera namnen på ohanterade diskar, deras logiska enhetsnummer (LUN) och den virtuella dator som de är anslutna till. Om du gör det blir det enklare att koppla diskarna igen efter redundansväxlingen.
  2. Stäng av den virtuella datorn.
  3. Ta bort den virtuella datorn, men behåll VHD-filerna för de ohanterade diskarna. Observera tidpunkten då du tog bort den virtuella datorn.
  4. Vänta tills senaste synkroniseringstid har uppdaterats och är senare än den tidpunkt då du tog bort den virtuella datorn. Det här steget är viktigt, för om den sekundära slutpunkten inte har uppdaterats helt med VHD-filerna när redundansväxlingen sker kanske den virtuella datorn inte fungerar korrekt i den nya primära regionen.
  5. Initiera redundansväxlingen av kontot.
  6. Vänta tills redundansväxlingen har slutförts och den sekundära regionen har blivit den nya primära regionen.
  7. Skapa en virtuell dator i den nya primära regionen och sätt tillbaka de virtuella hårddiskarna.
  8. Starta den nya virtuella datorn.

Tänk på att alla data som lagras på en tillfällig disk går förlorade när den virtuella datorn stängs av.

Kopiera data som ett alternativ till redundans

Om ditt lagringskonto har konfigurerats för läsåtkomst till den sekundära regionen kan du utforma programmet så att det läser från den sekundära slutpunkten. Om du föredrar att inte redundansväxla om det uppstår ett avbrott i den primära regionen kan du använda verktyg som AzCopy eller Azure PowerShell för att kopiera data från ditt lagringskonto i den sekundära regionen till ett annat lagringskonto i en region som inte påverkas. Du kan sedan peka dina program till lagringskontot för både läs- och skrivtillgänglighet.

Utforma för hög tillgänglighet

Det är viktigt att utforma ditt program för hög tillgänglighet från början. Mer information om hur du utformar ditt program och planerar för haveriberedskap finns i dessa Azure-resurser:

Tänk på de här metodtipsen för att upprätthålla hög tillgänglighet för dina Azure Storage-data:

Spåra avbrott

Kunder kan prenumerera på Azure Service Health-instrumentpanelen för att spåra hälsotillståndet och statusen för Azure Storage och andra Azure-tjänster.

Microsoft rekommenderar också att du utformar ditt program så att det kan hantera potentiella skrivfel. Programmet bör exponera skrivfel på ett sätt som varnar dig om potentiella avbrott i den primära regionen.

Se även