Haveriberedskap och lagringskontoredundans

Microsoft strävar efter att säkerställa att Azure-tjänster alltid är tillgängliga. Oplanerade tjänstavbrott kan dock inträffa. Om ditt program kräver återhämtning rekommenderar Microsoft att du använder geo-redundant lagring så att dina data kopieras till en andra region. Dessutom bör kunder ha en haveriberedskapsplan för hantering av ett regionalt tjänstavbrott. En viktig del av en haveriberedskapsplan är att förbereda redundansen till den sekundära slutpunkten om den primära slutpunkten blir otillgänglig.

Azure Storage har stöd för kontoredundans för geo-redundanta lagringskonton. Med redundans för kontot kan du initiera redundansen för ditt lagringskonto om den primära slutpunkten blir otillgänglig. Redundansen uppdaterar den sekundära slutpunkten så att den blir den primära slutpunkten för ditt lagringskonto. När redundansen är klar kan klienter börja skriva till den nya primära slutpunkten.

Redundansväxling är tillgängligt för konton av typen generell användning v1, generell användning v2 och bloblagring med Azure Resource Manager-distributioner. Redundans för konto stöds inte för lagringskonton med en hierarkisk namnrymd aktiverad.

Den här artikeln beskriver de begrepp och processer som ingår i redundans för ett konto och beskriver hur du förbereder ditt lagringskonto för återställning med minsta kundpåverkan. Information om hur du initierar en konto redundans i Azure Portal PowerShell finns i Initiate an account failover.

Välja rätt redundansalternativ

Azure Storage 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 skydd mot regionala avbrott konfigurerar du ditt konto för geo-redundant lagring med eller utan alternativet läsåtkomst från den sekundära regionen:

Geo-redundant lagring (GRS) eller geo-zonredundant lagring (GZRS) kopierar dina data asynkront i två geografiska regioner som är minst hundratals mil ifrån varandra. Om den primära regionen drabbas av ett avbrott fungerar den sekundära regionen som en redundant källa för dina data. Du kan initiera en redundans för att omvandla den sekundära slutpunkten till den primära slutpunkten.

Geo-redundant lagring med läsbehörighet (RA-GRS) eller geo-zonredundant lagring med läsbehörighet (RA-GZRS) ger geo-redundant lagring med ytterligare fördelar med läsåtkomst till den sekundära slutpunkten. Om ett avbrott inträffar i den primära slutpunkten kan program som konfigurerats för läsåtkomst till den sekundära och utformad 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 program.

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

Utforma för hög tillgänglighet

Det är viktigt att designa ditt program för hög tillgänglighet från början. Se dessa Azure-resurser för vägledning om hur du utformar ditt program och planerar för haveriberedskap:

• Utforma elastiska program för Azure:En översikt över nyckelbegreppen för att skapa högaktuella program 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ögkapacitet: Designvägledning för att skapa program som kan dra nytta av geo-redundant lagring.
• Självstudie:Skapa ett program med hög tillgänglig bloblagring: En självstudiekurs som visar hur du skapar ett program med hög tillgänglig kapacitet som automatiskt växlar mellan slutpunkter när fel och återställningar simuleras.

Tänk dessutom på 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 servera de virtuella datordiskar som används av dina virtuella Azure-datorer. Överväg också att Azure Site Recovery för att skydda dina virtuella datorer i händelse av ett regionalt haveri.
• Blockblobar: Aktivera mjuk borttagning för att skydda mot borttagningar på objektnivå och skriver över, eller kopiera blockblobar till ett annat lagringskonto i en annan region med hjälp av AzCopy, Azure PowerShelleller Azure Data Movement-biblioteket.
• Filer: Använd Azure Backup för att backa upp dina filresurser. Aktivera även mjuk borttagning för att skydda mot oavsiktliga borttagningar av filresurs. 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 instrumentpanel 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 för att förbereda för risken för skrivfel. Programmet bör exponera skrivfel på ett sätt som varnar dig om ett avbrott i den primära regionen.

Förstå processen för kontoredundansväxling

Med kund hanterad redundans kan du redundansfördröja hela lagringskontot till den sekundära regionen om den primära av någon anledning blir otillgänglig. När du tvingar fram en redundans till den sekundära regionen kan klienter börja skriva data till den sekundära slutpunkten när redundansen är klar. Redundansen tar vanligtvis ungefär en timme.

Så här fungerar kontoredundans

Under normala omständigheter skriver en klient data till ett Azure Storage konto i den primära regionen och dessa data kopieras asynkront till den sekundära regionen. Följande bild visar scenariot när den primära regionen är tillgänglig:

Om den primära slutpunkten av någon anledning blir otillgänglig kan klienten inte längre skriva till lagringskontot. Följande bild visar scenariot där den primära har blivit otillgänglig, men ingen återställning har skett ännu:

Kunden initierar kontots redundans till den sekundära slutpunkten. Redundansprocessen uppdaterar DNS-posten som tillhandahålls av Azure Storage så att den sekundära slutpunkten blir den nya primära slutpunkten för ditt lagringskonto, enligt följande bild:

Skrivåtkomst återställs för geo-redundanta konton när DNS-posten har uppdaterats och begäranden dirigeras till den nya primära slutpunkten. Befintliga slutpunkter för lagringstjänsten för blobar, tabeller, köer och filer förblir desamma efter redundansen.

Förutse dataförlust

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 regionen. Om den primära regionen blir otillgänglig kanske de senaste skrivarna ännu inte har kopierats till den sekundära regionen.

När du tvingar fram en redundans går alla data i den primära regionen förlorade när den sekundära regionen blir den nya primära regionen. Den nya primära regionen är konfigurerad för att vara lokalt redundant efter redundansen.

Alla data som redan har kopierats till den sekundära behålls när redundansen sker. Men alla data som skrivs till den primära som inte har kopierats till den sekundära förloras permanent.

Egenskapen Last Sync Time (Tid för senaste synkronisering) anger den senaste gången data från den primära regionen garanterat har skrivits till den sekundära regionen. Alla data som skrivits före den senaste synkroniseringstiden är tillgängliga på den sekundära, medan data som skrivits efter den senaste synkroniseringen kanske inte har skrivits till den sekundära och kan gå förlorade. Använd den här egenskapen i händelse av ett avbrott för att beräkna mängden dataförlust som kan uppstå genom att initiera en redundans för ett konto.

Som bästa praxis bör du utforma 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 Last Sync Time finns i Kontrollera egenskapen Last Sync Time för ett lagringskonto.

Var försiktig när du går tillbaka till den ursprungliga primära

När du har redundanserat från den primära till den sekundära regionen konfigureras ditt lagringskonto så att det är lokalt redundant i den nya primära regionen. Du kan sedan konfigurera kontot i den nya primära regionen för geo-redundans. När kontot har konfigurerats för geo-redundans efter en redundans börjar den nya primära regionen omedelbart kopiera data till den nya sekundära regionen, som var den primära före den ursprungliga redundansen. Det kan dock ta en stund innan befintliga data i den nya primära kopieras helt till den nya sekundära.

När lagringskontot har konfigurerats om för georedundans går det att initiera en återställning efter fel från den nya primära tillbaka till den nya sekundära. I det här fallet blir den ursprungliga primära regionen före redundansen den primära regionen igen och konfigureras att vara antingen lokalt redundant eller zonredundant, beroende på om den ursprungliga primära konfigurationen var GRS/RA-GRS eller GZRS/RA-GZRS. Alla data i den primära regionen efter redundans (den ursprungliga sekundära) går förlorade under återställningen efter fel. Om de flesta data i lagringskontot inte har kopierats till den nya sekundära innan du redundans redundansförs kan det leda till en stor dataförlust.

För att undvika större dataförlust kontrollerar du värdet för egenskapen Last Sync Time (Tid för senaste synkronisering) innan du går tillbaka. Jämför tiden för senaste synkronisering med de senaste gångerna som data skrevs till den nya primära för att utvärdera förväntad dataförlust.

Efter en återställning efter fel kan du konfigurera den nya primära regionen så att den blir geo-redundant igen. Om den ursprungliga primära har konfigurerats för LRS kan du konfigurera den så att den är GRS eller RA-GRS. Om den ursprungliga primära har konfigurerats för ZRS kan du konfigurera den så att den är GZRS eller RA-GZRS. Ytterligare alternativ finns i Ändra hur ett lagringskonto replikeras.

Initiera en kontoredundans

Du kan initiera en konto redundans från Azure Portal, PowerShell, Azure CLI eller API:Azure Storage resursprovidern. Mer information om hur du initierar en redundans finns i Initiate an account failover.

Annat som är bra att tänka på

Granska ytterligare överväganden som beskrivs i det här avsnittet för att förstå hur dina program och tjänster kan påverkas när du framt tvingar fram en redundans.

Lagringskonto som innehåller arkiverade blobar

Storage-konton som innehåller arkiverade blobar stöder redundans för konto. När redundansen är klar måste alla arkiverade blobar extrahydreras till en onlinenivå innan kontot kan konfigureras för geo-redundans.

Lagringsresursprovider

När redundansen är klar kan klienterna läsa och skriva Azure Storage data i den nya primära regionen. Resursprovidern Azure Storage redundans, så resurshanteringsåtgärder måste fortfarande ske 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 resursprovidern Azure Storage redundans, returnerar egenskapen Location den ursprungliga primära platsen när redundansen är klar.

Virtuella Azure-datorer

Virtuella Azure-datorer (VM) redundansar inte som en del av en redundans för ett konto. Om den primära regionen blir otillgänglig och du redundansar till den sekundära regionen måste du återskapa alla virtuella datorer efter redundansen. Det finns också en potentiell dataförlust som är associerad med kontots redundans. Microsoft rekommenderar följande vägledning för hög tillgänglighet och haveriberedskap som är specifik för virtuella datorer i Azure.

Ohanterade Diskar i Azure

Som bästa praxis rekommenderar Microsoft att du konverterar ohanterade diskar till hanterade diskar. Men om du behöver växla över 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 redundansen.

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. Redundans för ett konto kan inte fortsätta när det finns ett lån på en blob. Följ dessa steg om du vill utföra redundansen:

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 återansluta diskarna efter redundansen.
2. Stäng av den virtuella datorn.
3. Ta bort den virtuella datorn, men behåll VHD-filerna för de ohanterade diskarna. Observera den tid då du tog bort den virtuella datorn.
4. Vänta tills Tiden för senaste synkronisering har uppdaterats och är senare än den tidpunkt då du tog bort den virtuella datorn. Det här steget är viktigt eftersom den virtuella datorn kanske inte fungerar korrekt i den nya primära regionen om den sekundära slutpunkten inte har uppdaterats helt med VHD-filerna när redundansen sker.
5. Initiera kontots redundans.
6. Vänta tills kontots redundans är klar och den sekundära regionen har blivit den nya primära regionen.
7. Skapa en virtuell dator i den nya primära regionen och koppla de virtuella hårddiskarna på nytt.
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.

Funktioner och tjänster som inte stöds

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

• Azure File Sync har inte stöd för redundansväxling av lagringskonton. Lagringskonton med Azure-filresurser som används som molnslutpunkter i Azure File Sync får inte redundansväxlas. Om du gör det slutar synkroniseringen att fungera och det kan leda till oväntade dataförluster för nyligen nivåbaserade filer.
• Storage-konton som har hierarkisk namnrymd aktiverad (till exempel för Data Lake Storage Gen2) stöds inte för närvarande.
• Ett lagringskonto som innehåller premium-blockblobar kan inte överförse. Storage-konton som stöder premium-blockblobar stöder för närvarande inte geo-redundans.
• Ett lagringskonto som innehåller worm-oföränderlighetsprincipaktiverade containrar kan inte överföras. Upplåst/låst tidsbaserad kvarhållning eller bevarande av juridiska bevarandeprinciper förhindrar redundans för att upprätthålla efterlevnad.

Kopiera data som ett alternativ till redundans

Om ditt lagringskonto har konfigurerats för läsåtkomst till den sekundära kan du utforma programmet så att det läser från den sekundära slutpunkten. Om du föredrar att inte redundansera i händelse av ett avbrott i den primära regionen kan du använda verktyg som AzCopy, Azure PowerShelleller Azure Data Movement-biblioteket för att kopiera data från ditt lagringskonto i den sekundära regionen till ett annat lagringskonto i en icke-påverkad region. Du kan sedan peka dina program till det lagringskontot för både läs- och skrivtillgänglighet.

Microsoft-hanterad redundans

I extrema fall där en region går förlorad på grund av en betydande katastrof kan Microsoft initiera en regional redundans. I det här fallet krävs ingen åtgärd från din sida. Du har inte skrivåtkomst till ditt lagringskonto förrän den Microsoft-hanterade redundansen har slutförts. Dina program kan läsa från den sekundära regionen om ditt lagringskonto har konfigurerats för RA-GRS eller RA-GZRS.

Se även

• Använd geo-redundans för att utforma program med hög tillgänglighet
• Initiera en kontoredundans
• Kontrollera egenskapen Senaste synkroniseringstid för ett lagringskonto
• Självstudie: Skapa ett program med hög tillgänglig användning med Blob Storage