Planering och redundans vid haveriberedskap i Azure Storage

Microsoft strävar efter att säkerställa att Azure-tjänster alltid är tillgängliga. Oplanerade tjänststopp kan dock ibland inträffa. Viktiga komponenter i en bra haveriberedskapsplan är 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ål uppfylls, även vid fel. Det sätt på vilket data replikeras ger olika skyddsnivåer. Varje alternativ erbjuder sina egna fördelar, så det alternativ du väljer beror på graden av återhämtning som dina program kräver.

Lokalt redundant lagring (LRS), det lägsta alternativet för redundans, 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ämningar i ett datacenter. Vid sådana katastrofer kan alla repliker av ett lagringskonto som har konfigurerats för att använda LRS gå förlorade eller oåterkalleliga.

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-zonredundant lagring (GZRS) och read-access geo-zone-redundant lagring (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) kopieras dina data asynkront till en sekundär geografisk region. Dessa regioner ligger hundratals, eller till och med tusentals mil bort. Med den här redundansnivån 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 även stöd för en oplanerad redundansväxling 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 lagringskontots tjänstslutpunkter 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äsåtkomst (RA-GRS) och geozonredundant lagring med läsåtkomst (RA-GZRS) ger också geo-redundant lagring, men ger den extra fördelen med läsåtkomst till den sekundära slutpunkten. De här alternativen är idealiska för program som är utformade för verksamhetskritiska program med hög tillgänglighet. Om den primära slutpunkten upplever ett avbrott kan program som konfigurerats för läsåtkomst till den sekundära regionen fortsätta att fungera. Microsoft rekommenderar 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 stöder tre typer av redundans:

• Kundhanterad planerad redundans (förhandsversion) – Kunder kan hantera redundansväxling för lagringskonton för att testa sin haveriberedskapsplan.
• Kundhanterad (oplanerad) redundans – Kunder kan hantera redundansväxling av lagringskonton om det uppstår ett oväntat tjänstfel.
• 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 klientorganisationer. Mer information finns i Microsoft-hanterad redundans.
² Använd kundhanterade redundansalternativ för att utveckla, testa och implementera dina planer för haveriberedskap. 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). Den här tabellen sammanfattar dessa aspekter av varje typ av redundans:

I följande tabell jämförs redundanstillståndet för ett lagringskonto efter varje typ av redundans:

I följande tabell sammanfattas den resulterande redundanskonfigurationen i varje steg i redundans- och återställningsprocessen 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 redundansväxling kan användas i flera scenarier, inklusive testning av planerad haveriberedskap, en proaktiv metod för storskaliga katastrofer eller återställning från avbrott relaterade till icke-lagring.

Under den planerade redundansväxlingen växlas de primära och sekundära regionerna. Den ursprungliga primära regionen degraderades och blir den nya sekundära regionen. Samtidigt höjs den ursprungliga sekundära regionen upp och blir den nya primära regionen. 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 redundans- och återställningsprocesserna. 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 lagringskontot blir otillgängliga i den primära regionen kan du initiera en oplanerad redundansväxling 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 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 redundansväxling under extrema omständigheter, till exempel en katastrof som påverkar en hel geo-region. 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 redundansväxling. 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 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 är det möjligt att de senaste skrivåtgärderna ännu inte har kopierats till den sekundära regionen.

När en oplanerad 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 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 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:

• Hierarkiskt namnområde (Azure Data Lake Storage)
• Ändringsflöde
• Återställning till tidpunkt för blockblobar

Senaste synkronisering

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). Alla data och metadata som skrivits före den senaste synkroniseringstiden är tillgängliga på den sekundära. Däremot kanske data och metadata som skrivits efter den senaste synkroniseringstiden ännu inte kopierats till den sekundära och potentiellt kan gå förlorade. Under ett avbrott använder du den här egenskapen för att uppskatta hur mycket dataförlust du kan drabbas av när du initierar en redundansväxling av ett konto.

Vi rekommenderar att du utformar programmet 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 tidpunkterna för din senaste skrivåtgärd med den senaste synkroniseringstiden. Med den här metoden kan du avgöra vilka skrivningar som ännu inte har synkroniserats med den sekundära skrivningen och riskerar att gå förlorade.

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

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 redundansväxling av ett lagringskonto garanteras inte.

Inkonsekvenser för ändringsflöde och blobdata

Kundhanterad (oplanerad) redundansväxling av 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 typen av ändringslogguppdateringar och datareplikering mellan de primära och sekundära regionerna. Du kan undvika inkonsekvenser genom att vidta följande försiktighetsåtgärder:

• Kontrollera att alla loggposter rensas till loggfilerna.
• Kontrollera 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 lagringskonton också kräver att ändringsflödet aktiveras. 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. 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 Portal.

Tid och kostnad för rederover

Den tid det tar för en kundhanterad redundansväxling att slutföras när 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 redundansväxling och efterföljande redundans, 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äsåtkomst (RA-GRS) för kontot, men omreplikering av data till den nya sekundära regionen medför en avgift. Dessutom måste alla arkiverade blobar extraheras till en onlinenivå innan kontot kan konfigureras om för geo-redundans. Denna rehydrering medför också en extra kostnad. Mer information om priser finns i:

• Prisinformation för bandbredd
• Prissättning 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 PROCESSOR, 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 stöder vissa kontotyper kundhanterad kontoredundans, enligt följande tabell:

Klassiska lagringskonton

Hierarkiskt namnområde (HNS)

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 kundhanterad redundansväxling. Lagringskonton som används som molnslutpunkter för Azure File Sync bör inte redväxkas. 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.
• 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.
• 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 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 redundansväxling kan lagringsuppgifter inte fungera på kontot förrän det inte återgår till den ursprungliga primära regionen. Läs mer.

Redundansväxling är inte för kontomigrering

Redundansväxlingar för lagringskonton är en tillfällig lösning som används för att utveckla och testa dina haveriberedskapsplaner (DR) eller för att återställa från ett tjänstfel. 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 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 klienter å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.

Virtuella Azure-datorer

Virtuella Azure-datorer redundansväxlar inte som en del av redundansväxlingen för ett lagringskonto. Alla virtuella datorer som redundansväxlade till en sekundär region som svar på ett avbrott måste återskapas när redundansväxlingen har slutförts. Redundansväxling av konton 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 riktlinjerna för hög tillgänglighet och haveriberedskap som är specifika 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 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. Innan en redundansväxling kan initieras på ett konto som innehåller ohanterade diskar som är anslutna till virtuella Azure-datorer måste diskarna stängas av. Därför är Microsofts rekommenderade metodtips att konvertera ohanterade diskar till hanterade diskar.

Följ dessa steg för att utföra en redundansväxling på ett konto som innehåller ohanterade diskar:

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 de virtuella hårddiskfilerna (VHD) för de ohanterade diskarna. Observera tidpunkten då du tog bort den virtuella datorn.
4. Vänta tills senaste synkroniseringstid 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 uppdateras helt 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 redundansväxlingen har slutförts och den sekundära regionen blir 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 redundansalternativ

Som tidigare nämnts kan du upprätthålla hög tillgänglighet genom att konfigurera program för att använda 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 manuellt kopiera dina data 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 region som inte påverkas. När kopieringsåtgärden ä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 elastiska 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älvstudiekurs 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.

Se de här metodtipsen 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 virtuella datordiskar som används av dina virtuella Azure-datorer. Överväg också att använda Azure Site Recovery för att skydda dina virtuella datorer mot en regional katastrof.
• Blockera blobar: 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å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

• 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 i Azure Storage
• Så här fungerar kundhanterad planerad redundans (förhandsversion)
• Så här fungerar kundhanterad (oplanerad) redundans