Dela via

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 tjänststopp kan dock ibland inträffa. Viktiga komponenter i en bra haveriberedskapsplan är strategier för:

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:

1 Microsoft-hanterad redundans kan inte initieras för enskilda lagringskonton, prenumerationer eller klientorganisationer. Mer information finns i Microsoft-hanterad redundans.
2 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:

Typ Redundansomfång Användningsfall Förväntad dataförlust Hierarkiskt namnområde (HNS) stöds
Kundhanterad planerad redundans (förhandsversion) Lagringskonto Lagringstjänstens slutpunkter för de primära och sekundära regionerna är tillgängliga och du vill utföra haveriberedskapstestning.

Lagringstjänstslutpunkterna för den primära regionen är tillgängliga, men en annan tjänst hindrar dina arbetsbelastningar från att fungera korrekt.

Att proaktivt förbereda sig för storskaliga katastrofer, till exempel en orkan, som kan påverka en region.		 Nej Ja
(I förhandsversion)
Kundhanterad (oplanerad) redundans 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 Den primära regionen blir otillgänglig på grund av en betydande katastrof, men den sekundära regionen är tillgänglig. Ja Ja

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

Resultat av redundansväxling på... Kundhanterad planerad redundans (förhandsversion) Kundhanterad (oplanerad) redundans
... den sekundära regionen Den sekundära regionen blir den nya primära regionen Den sekundära regionen blir den nya primära regionen
... den ursprungliga primära regionen Den ursprungliga primära regionen blir den nya sekundära regionen Kopian av data i den ursprungliga primära regionen tas bort
... konfiguration av kontoredundans Lagringskontot konverteras till GRS Lagringskontot konverteras till LRS
... konfigurationen för geo-redundans Geo-redundans behålls Geo-redundans går förlorad

I följande tabell sammanfattas den resulterande redundanskonfigurationen i varje steg i redundans- och återställningsprocessen för varje typ av redundans:

Original
konfiguration		 Efter
redundans		 Efter återaktivering
geo-redundans		 Efter
återställning efter fel		 Efter återaktivering
geo-redundans
Kundhanterad planerad redundans
GRS GRS n/a 1 GRS n/a 1
GZRS GRS n/a 1 GZRS n/a 1
Kundhanterad (oplanerad) redundans
GRS LRS GRS LRS GRS
GZRS LRS GRS ZRS GZRS

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

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.

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.

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.

Viktigt!

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 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 ett datacenter. Det kan inte initieras för enskilda lagringskonton, prenumerationer eller klientorganisationer. Om du behöver möjlighet att selektivt redundanshantera dina enskilda lagringskonton använder du kundhanterad planerad redundans.

Förutse dataförlust och inkonsekvenser

Varning

Kundhanterad oplanerad redundans innebär vanligtvis en viss mängd dataförlust och kan också potentiellt medföra 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 ä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:

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:

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:

Typ av redundans GRS/RA-GRS GZRS/RA-GZRS
Kundhanterad planerad redundans (förhandsversion) Allmänna v2-konton
Allmänna v1-konton
Äldre Blob Storage-konton		 General-purpose v2-konton (GPv2)
Kundhanterad (oplanerad) 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 redundans stöds endast för lagringskonton som distribueras med hjälp av distributionsmodellen azure resource manager (ARM). Distributionsmodellen för Azure Service Manager (ASM), även kallad den klassiska modellen, 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.

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

Hierarkiskt namnområde (HNS)

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.

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.

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

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.

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.

Planerad redundans Oplanerad redundans
Azure Data Lake Storage Stöds (förhandsversion) Stöds (förhandsversion)
Ändringsflöde Stöd saknas Stöds
Objektreplikering Stöd saknas Stöd saknas
SFTP Stöds (förhandsversion) Stöds (förhandsversion)
NFSv3 GRS stöds inte GRS stöds inte
Lagringsåtgärder Stöds1 Stöds1
Återställning till tidpunkt (PITR) Stöd saknas Stöds

1 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:

Se 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