Haveriberedskapsplanering och redundans för Azure Storage

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

• Dataskydd
• Säkerhetskopiering och återställning
• Dataredundans
• Redundans
• Utforma program för hög tillgänglighet

Den här artikeln beskriver de alternativ som är tillgängliga för geo-redundanta lagringskonton och ger rekommendationer för att utveckla program med hög tillgänglighet och testa din haveriberedskapsplan.

Välj rätt redundansalternativ

Azure Storage har flera kopior av ditt lagringskonto för att säkerställa att tillgänglighets- och hållbarhetsmålen uppfylls, även vid fel. Det sätt på vilket data replikeras ger olika skyddsnivåer. Varje alternativ har sina egna fördelar, så vilket alternativ du väljer beror på vilken grad av återhämtning dina program kräver.

Lokalt redundant lagring (LRS), det billigaste redundansalternativet, lagrar och replikerar automatiskt tre kopior av ditt lagringskonto i ett enda datacenter. Även om LRS skyddar dina data mot serverrack- och enhetsfel, tar det inte hänsyn till katastrofer som brand eller översvämning i ett datacenter. Vid sådana katastrofer kan alla repliker av ett lagringskonto som konfigurerats för att använda LRS gå förlorade eller inte kunna återställas.

Som jämförelse behåller zonredundant lagring (ZRS) en kopia av ett lagringskonto och replikerar det i var och en av tre separata tillgänglighetszoner inom samma region. Mer information om tillgänglighetszoner finns i Azure-tillgänglighetszoner.

Geo-redundant lagring och redundans

Geo-redundant lagring (GRS), geo-zon-redundant lagring (GZRS) och geo-zon-redundant lagring med läsbehörighet (RA-GZRS) är exempel på geografiskt redundanta lagringsalternativ. När Azure har konfigurerats för att använda geo-redundant lagring (GRS, GZRS och RA-GZRS) kopierar Azure dina data asynkront till en sekundär geografisk region. Dessa regioner ligger hundratals, eller till och med tusentals mil bort. Med den här nivån av redundans kan du återställa dina data om det uppstår ett avbrott i hela den primära regionen.

Till skillnad från LRS och ZRS ger geo-redundant lagring också stöd för en oplanerad redundans till en sekundär region om det uppstår ett avbrott i den primära regionen. Under redundansväxlingen uppdateras DNS-poster (Domain Name System) för tjänstslutpunkterna för ditt lagringskonto automatiskt så att den sekundära regionens slutpunkter blir de nya primära slutpunkterna. När den oplanerade redundansväxlingen är klar kan klienterna börja skriva till de nya primära slutpunkterna.

Geo-redundant lagring med läsbehörighet (RA-GRS) och geozonredundant lagring med läsåtkomst (RA-GZRS) ger också geo-redundant lagring, men erbjuder den extra fördelen med läsåtkomst till den sekundära slutpunkten. Dessa alternativ är idealiska för program som är utformade för affärskritiska program med hög tillgänglighet. Om den primära slutpunkten drabbas av ett avbrott kan program som konfigurerats för läsåtkomst till den sekundära regionen fortsätta att fungera. Microsoft rekommenderar att du RA-GZRS för maximal tillgänglighet och hållbarhet för dina lagringskonton.

Mer information om redundans för Azure Storage finns i Azure Storage redundans.

Planera för redundans

Azure Storage-konton har stöd för tre typer av redundans:

• Kundhanterad planerad redundans (förhandsversion) – Kunder kan hantera redundans för lagringskonto för att testa sin haveriberedskapsplan.
• Kundhanterad (oplanerad) redundans – Kunder kan hantera redundans för lagringskonto om det uppstår ett oväntat avbrott i tjänsten.
• Microsoft-hanterad redundans – Potentiellt initierad av Microsoft på grund av en allvarlig katastrof i den primära regionen. ^1,2

¹ Microsoft-hanterad redundans kan inte initieras för enskilda lagringskonton, prenumerationer eller klienter. Mer information finns i Microsoft-hanterad redundans.
² Använd kundhanterade redundansalternativ för att utveckla, testa och implementera dina haveriberedskapsplaner. Förlita dig inte på Microsoft-hanterad redundans, som endast används 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). I den här tabellen sammanfattas dessa aspekter av varje typ av redundans:

I följande tabell jämförs ett lagringskontos redundanstillstånd efter varje typ av redundans:

I följande tabell sammanfattas den resulterande redundanskonfigurationen i varje steg i processen för redundans och återställning efter fel för varje typ av redundans:

¹ Geo-redundans behålls under en planerad redundans och behöver inte konfigureras om manuellt.

Kundhanterad planerad redundans (förhandsversion)

Planerad redundans kan användas i flera scenarier, inklusive testning av planerad haveriberedskap, en proaktiv metod för storskaliga katastrofer eller för att återställa från icke-lagringsrelaterade avbrott.

Under den planerade redundansväxlingen växlas de primära och sekundära regionerna. Den ursprungliga primära regionen degraderas och blir den nya sekundära regionen. Samtidigt befordras den ursprungliga sekundära regionen och blir den nya primära. 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 processerna för redundans och återställning efter fel. Mer information om hur den här processen fungerar finns i Så här fungerar kundhanterad (planerad) redundans.

Kundhanterad (oplanerad) redundans

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

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 den oplanerade redundans- och återställningsprocessen. Mer information om hur processen fungerar finns i Så här fungerar kundhanterad (oplanerad) redundans.

Microsoft-hanterad redundans

Microsoft kan initiera en regional redundans under extrema omständigheter, till exempel en oåterkallelig katastrof som påverkar en hel georegion. Under dessa händelser krävs ingen åtgärd från din sida. Om ditt lagringskonto har konfigurerats för RA-GRS eller RA-GZRS kan dina program läsa från den sekundära regionen under en Microsoft-hanterad redundans. Du har dock inte skrivåtkomst till ditt lagringskonto förrän redundansväxlingen är klar.

Förutse dataförlust och inkonsekvenser

Eftersom data skrivs asynkront från den primära regionen till den sekundära regionen finns det alltid en fördröjning innan en skrivning till den primära regionen kopieras till den sekundära. Om den primära regionen blir otillgänglig är det möjligt att de senaste skrivningarna ännu inte har kopierats till den sekundära.

När en oplanerad redundans inträffar går alla data i den primära regionen förlorade eftersom den sekundära regionen blir den nya primära. Alla data som redan har kopierats till den sekundära regionen underhålls när redundansväxlingen sker. Alla data som skrivs till den primära som ännu inte finns i den sekundära regionen går dock förlorade permanent.

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

Du kan också uppleva inkonsekvenser i filer eller data om dina lagringskonton har något av följande aktiverat:

• Hierarkisk namnrymd (Azure Data Lake Storage)
• Ändringsflöde
• Återställning till en viss tidpunkt för blockblobbar

Senaste synkroniseringstid

Egenskapen Senaste synkroniseringstid anger den senaste tiden då data från den primära regionen också skrevs 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 åtkomstkontrollistor (ACL:er). Alla data och metadata som skrivits före den senaste synkroniseringstiden är tillgängliga på den sekundära. Data och metadata som skrivits efter den senaste synkroniseringstiden kanske däremot ännu inte kopieras till den sekundära och kan potentiellt gå förlorade. Under ett avbrott använder du den här egenskapen för att beräkna mängden dataförlust som du kan ådra dig när du initierar en redundansväxling av ett konto.

Vi rekommenderar att du utformar ditt program så att du kan använda 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 tiderna för den senaste skrivåtgärden med den senaste synkroniseringstiden. Med den här metoden kan du avgöra vilka skrivningar som ännu inte har synkroniserats till den sekundära och som riskerar att gå förlorade.

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

Filkonsekvens för Azure Data Lake Storage

Replikering för lagringskonton med ett hierarkiskt namnområde aktiverat (Azure Data Lake Storage) sker på filnivå. Eftersom replikering sker på den här nivån kan ett avbrott i den primära regionen förhindra att vissa av filerna i en container eller katalog replikeras till den sekundära regionen. Konsekvens för alla filer i en container eller katalog efter redundans för ett lagringskonto garanteras inte.

Inkonsekvenser i ändringsflöde och blobdata

Kundhanterad (oplanerad) redundans för lagringskonton med ändringsflöde aktiverat kan resultera i inkonsekvenser mellan ändringsflödesloggarna och blobdata och/eller metadata. Sådana inkonsekvenser kan bero på den asynkrona typen av uppdateringar av ändringsloggar och datareplikering mellan de primära och sekundära regionerna. Du kan undvika inkonsekvenser genom att vidta följande försiktighetsåtgärder:

• Se till att alla loggposter rensas till loggfilerna.
• Se till att alla lagringsdata replikeras från den primära till den sekundära regionen.

Mer information om ändringsflöde finns i Så här fungerar ändringsflödet.

Tänk på att andra funktioner för lagringskontot också kräver att ändringsflödet är aktiverat. Dessa funktioner omfattar 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. Men om du utför en kundhanterad redundans på ett lagringskonto återställs den tidigaste möjliga återställningspunkten för kontot. Data för återställning till tidpunkt för blockblobar är endast konsekventa fram till slutförandetiden för redundans. Därför kan du bara återställa blockblobar till en tidpunkt som inte är tidigare än slutförandetiden för redundansen. Du kan kontrollera slutförandetiden för redundans på fliken redundans för ditt lagringskonto i Azure Portal.

Tid och kostnad för redundans

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

En planerad kundhanterad redundans förlorar inte sin geo-redundans efter en redundans och efterföljande återställning efter fel, men en oplanerad kundhanterad redundans gör det.

När du initierar en kundhanterad oplanerad redundans konverteras ditt lagringskonto automatiskt till lokalt redundant lagring (LRS) i en ny primär region och lagringskontot tas bort i den ursprungliga primära regionen.

Du kan återaktivera geo-redundant lagring (GRS) eller geo-redundant lagring med läsbehörighet (RA-GRS) för kontot, men återreplikering av data till den nya sekundära regionen medför en kostnad. Dessutom måste alla arkiverade blobar extraheras till en onlinenivå innan kontot kan konfigureras om för geo-redundans. Denna återfuktning medför också en extra kostnad. Mer information om priser finns i:

• Prisinformation för bandbredd
• Priser för Azure Storage

När du har återaktiverat GRS för ditt lagringskonto börjar Microsoft replikera data i ditt konto till den nya sekundära regionen. Hur lång tid det tar för replikeringen att slutföras beror på flera faktorer. Dessa faktorer är:

• 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 CPU, minne, disk och WAN-kapacitet. Livetrafik prioriteras framför geo-replikering.
• Antalet ögonblicksbilder per blob, om tillämpligt.
• Strategin för datapartitionering, om ditt lagringskonto innehåller tabeller. 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 har vissa kontotyper stöd för redundans för kundhanterade konton, som du ser i följande tabell:

Klassiska lagringskonton

Funktioner och tjänster som inte stöds

Följande funktioner och tjänster stöds inte för kundhanterad redundans:

• Azure File Sync stöder inte redundans för kundhanterade konton. Lagringskonton som används som molnslutpunkter för Azure File Sync bör inte växlas över. Redundans stör filsynkroniseringen och kan orsaka oväntad dataförlust av nyligen nivåindelade filer. Mer information finns i Metodtips för haveriberedskap med Azure File Sync för mer information.
• Det går inte att redundansväxla ett lagringskonto som innehåller premiumblockblobar. Lagringskonton som stöder premiumblockblobar stöder för närvarande inte geo-redundans.
• Kundhanterad redundans stöds inte för vare sig käll- eller målkontot i en objektreplikeringsprincip.
• Network File System (NFS) 3.0 (NFSv3) stöds inte för redundans för lagringskonto. Du kan inte skapa ett lagringskonto som konfigurerats för geo-redundans med NFSv3 aktiverat.

Följande tabell kan användas för att referera till funktionsstöd.

¹ Om du initierar en kundhanterad planerad eller oplanerad redundans kan lagringsuppgifter inte köras på kontot förrän det återställs till den ursprungliga primära regionen. Läs mer.

Redundans är inte för kontomigrering

Redundans för lagringskonto är en tillfällig lösning som används för att utveckla och testa dina haveriberedskapsplaner (DR) eller för att återställa efter ett tjänstavbrott. Redundans bör inte användas som en del av din strategi för datamigrering. 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 redundans för konton. Men när en kundhanterad redundans är klar 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 återigen läsa och skriva Azure Storage-data 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.

Azure-virtuella datorer

Virtuella Azure-datorer redundansväxlar inte som en del av redundans för ett lagringskonto. Alla virtuella datorer som har redundansväxlats till en sekundär region som svar på ett avbrott måste återskapas när redundansväxlingen har slutförts. Redundans för konto kan potentiellt leda till förlust av data som lagras på en tillfällig disk när den virtuella datorn (VM) stängs av. Microsoft rekommenderar att du följer vägledningen för hög tillgänglighet och haveriberedskap som är specifik för virtuella datorer i Azure.

Ohanterade Azure-diskar

Ohanterade diskar lagras som sidblobar i Azure Storage. När en virtuell dator körs i Azure lånas alla ohanterade diskar som är anslutna till den virtuella datorn. En redundansväxling av ett konto kan inte fortsätta när det finns ett lån på en blob. Innan en redundans kan initieras på ett konto som innehåller ohanterade diskar som är anslutna till virtuella Azure-datorer måste diskarna stängas av. Av den anledningen inkluderar Microsofts rekommenderade metodtips konvertering av ohanterade diskar till hanterade diskar.

Följ dessa steg om du vill utföra en redundans på ett konto som innehåller ohanterade diskar:

1. Innan du börjar bör du anteckna namnen på alla ohanterade diskar, deras logiska enhetsnummer (LUN) och den virtuella dator som de är anslutna till. Om du gör det enklare att återansluta diskarna efter redundansväxlingen.
2. Stäng av den virtuella datorn.
3. Ta bort den virtuella datorn, men behåll de virtuella hårddiskfilerna (VHD) för de ohanterade diskarna. Observera den tid då du tog bort den virtuella datorn.
4. Vänta tills den senaste synkroniseringstiden uppdateras och se till att den är senare än den tidpunkt då du tog bort den virtuella datorn. Det här steget säkerställer att den sekundära slutpunkten är helt uppdaterad med VHD-filerna när redundansväxlingen sker och att den virtuella datorn fungerar korrekt i den nya primära regionen.
5. Initiera redundansväxlingen av kontot.
6. Vänta tills kontots redundans är klar och den sekundära regionen blir den nya primära regionen.
7. Skapa en virtuell dator i den nya primära regionen och återanslut 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 för redundans

Som tidigare diskuterats kan du upprätthålla hög tillgänglighet genom att konfigurera program så att de använder ett lagringskonto som konfigurerats för läsåtkomst till en sekundär region. Men om du föredrar att inte redundansväxla under ett avbrott i den primära regionen kan du kopiera dina data manuellt som ett alternativ. Med verktyg som AzCopy och Azure PowerShell kan du kopiera data från ditt lagringskonto i den berörda regionen till ett annat lagringskonto i en opåverkad region. När kopieringen är klar kan du konfigurera om dina program så att de använder lagringskontot i den opåverkade regionen 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. Se dessa Azure-resurser för vägledning när du utformar ditt program och planerar för haveriberedskap:

• Designa motståndskraftiga 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.
• Självstudie: Skapa ett program med hög tillgänglighet med Blob Storage: En självstudie som visar hur du skapar ett program med hög tillgänglighet som automatiskt växlar mellan slutpunkter när fel och återställningar simuleras.

Läs dessa metodtips för att upprätthålla hög tillgänglighet för dina Azure Storage-data:

• Diskar: Använd Azure Backup för att säkerhetskopiera de VM-diskar som används av dina virtuella Azure-datorer. Överväg också att använda Azure Site Recovery för att skydda dina virtuella datorer från en regional katastrof.
• Blockera blobbar: Aktivera mjuk borttagning för att skydda mot borttagningar och överskrivningar på objektnivå, eller kopiera blockblobar till ett annat lagringskonto i en annan region med hjälp av AzCopy, Azure PowerShell eller Azure Data Movement-biblioteket.
• filer: Använd Azure Backup för att säkerhetskopiera dina filresurser. Aktivera även mjuk borttagning för att skydda mot oavsiktliga borttagningar av filresurser. För geo-redundans när GRS inte är tillgängligt använder du AzCopy eller Azure PowerShell för att kopiera dina filer till ett annat lagringskonto i en annan region.
• Tabeller: Använd AzCopy för att exportera tabelldata till ett annat lagringskonto i en annan region.

Spåra avbrott

Kunder kan prenumerera på Azure Service Health-instrumentpanelen för att spåra hälsotillstånd och status 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

• Använda geo-redundans för att utforma program med hög tillgänglighet
• Självstudie: Skapa ett program med hög tillgänglighet med Blob Storage
• Redundans för Azure Storage
• Så här fungerar kundhanterad planerad redundans (förhandsversion)
• Så här fungerar kundhanterad (oplanerad) redundans