Återställa från regionomfattande tjänststörningar

Artikel
03/21/2023

Azure delas in fysiskt och logiskt i enheter som kallas regioner. En region består av ett eller flera datacenter i närheten. Många regioner och tjänster stöder också tillgänglighetszoner, som kan användas för att ge mer återhämtning mot avbrott i ett enda datacenter. Överväg att använda regioner med tillgänglighetszoner för att förbättra tillgängligheten för din lösning.

I sällsynta fall är det möjligt att anläggningar i en hel tillgänglighetszon eller region kan bli otillgängliga, till exempel på grund av nätverksfel. Eller så kan anläggningar gå förlorade helt, till exempel på grund av en naturkatastrof. Azure har funktioner för att skapa program som distribueras mellan zoner och regioner. Sådan distribution hjälper till att minimera risken för att ett fel i en zon eller region kan påverka andra zoner eller regioner.

Molntjänster

Resurshantering

Du kan distribuera beräkningsinstanser mellan regioner genom att skapa en separat molntjänst i varje målregion och sedan publicera distributionspaketet till varje molntjänst. Distribution av trafik mellan molntjänster i olika regioner måste dock implementeras av programutvecklaren eller med en trafikhanteringstjänst.

Att fastställa antalet extra rollinstanser som ska distribueras i förväg för haveriberedskap är en viktig aspekt av kapacitetsplaneringen. Att ha en sekundär distribution i full skala säkerställer att kapaciteten redan är tillgänglig vid behov. Detta fördubblar dock i praktiken kostnaden. Ett vanligt mönster är att ha en liten, sekundär distribution, precis tillräckligt stor för att köra kritiska tjänster. Den här lilla sekundära distributionen är en bra idé, både för att reservera kapacitet och för att testa konfigurationen av den sekundära miljön.

Anteckning

Prenumerationskvoten är inte en kapacitetsgaranti. Kvoten är helt enkelt en kreditgräns. För att garantera kapacitet måste det antal roller som krävs definieras i tjänstmodellen och rollerna måste distribueras.

Belastningsutjämning

För att belastningsutjämning av trafik mellan regioner kräver en trafikhanteringslösning. Azure tillhandahåller Azure Traffic Manager. Du kan också dra nytta av tjänster från tredje part som tillhandahåller liknande trafikhanteringsfunktioner.

Strategier

Det finns många alternativa strategier för att implementera distribuerad beräkning mellan regioner. Dessa måste anpassas efter de specifika affärskraven och omständigheterna i programmet. På hög nivå kan metoderna delas in i följande kategorier:

Distribuera om haveriberedskap: I den här metoden distribueras programmet om från grunden vid katastroftillfället. Detta är lämpligt för icke-kritiska program som inte kräver en garanterad återställningstid.
Varm reserv (aktiv/passiv): En sekundär värdbaserad tjänst skapas i en alternativ region och roller distribueras för att garantera minimal kapacitet. Rollerna tar dock inte emot produktionstrafik. Den här metoden är användbar för program som inte har utformats för att distribuera trafik mellan regioner.
Frekvent reserv (aktiv/aktiv): Programmet är utformat för att ta emot produktionsbelastning i flera regioner. Molntjänsterna i varje region kan konfigureras för högre kapacitet än vad som krävs för haveriberedskap. Molntjänsterna kan också skalas ut efter behov vid tidpunkten för en katastrof och redundansväxla. Den här metoden kräver betydande investeringar i programdesign, men den har betydande fördelar. Dessa omfattar låg och garanterad återställningstid, kontinuerlig testning av alla återställningsplatser och effektiv användning av kapacitet.

En fullständig diskussion om distribuerad design ligger utanför omfånget för det här dokumentet. Mer information finns i Haveriberedskap och hög tillgänglighet för Azure-program.

Virtuella datorer

Återställning av virtuella IaaS-datorer (infrastruktur som en tjänst) liknar paaS-beräkningsåterställning (plattform som en tjänst) i många avseenden. Det finns dock viktiga skillnader på grund av att en virtuell IaaS-dator består av både den virtuella datorn och vm-disken.

Använd Azure Backup för att skapa säkerhetskopieringar mellan regioner som är program konsekventa. Azure Backup gör det möjligt för kunder att skapa program konsekventa säkerhetskopior över flera VM-diskar och stödja replikering av säkerhetskopior mellan regioner. Du kan göra detta genom att välja att geo-replikera säkerhetskopieringsvalvet när du skapar. Replikering av säkerhetskopieringsvalvet måste konfigureras när det skapas. Det går inte att ange senare. Om en region går förlorad gör Microsoft säkerhetskopiorna tillgängliga för kunderna. Kunder kommer att kunna återställa till någon av sina konfigurerade återställningspunkter.
Separera datadisken från operativsystemdisken. Ett viktigt övervägande för virtuella IaaS-datorer är att du inte kan ändra operativsystemdisken utan att återskapa den virtuella datorn. Det här är inte ett problem om återställningsstrategin är att distribuera om efter en katastrof. Det kan dock vara ett problem om du använder metoden Warm Spare för att reservera kapacitet. Om du vill implementera detta korrekt måste du ha rätt operativsystemdisk distribuerad till både de primära och sekundära platserna, och programdata måste lagras på en separat enhet. Använd om möjligt en standardkonfiguration för operativsystemet som kan tillhandahållas på båda platserna. Efter en redundansväxling måste du sedan koppla dataenheten till dina befintliga virtuella IaaS-datorer i den sekundära domänkontrollanten. Använd AzCopy för att kopiera ögonblicksbilder av datadiskarna till en fjärrplats.
Tänk på potentiella konsekvensproblem efter en geo-redundansväxling av flera VM-diskar. VM-diskar implementeras som Azure Storage-blobar och har samma egenskaper för geo-replikering. Om inte Azure Backup används finns det inga garantier för konsekvens mellan diskar, eftersom geo-replikering är asynkron och replikeras oberoende av varandra. Enskilda VM-diskar är garanterat i ett kraschkonsekvent tillstånd efter en geo-redundans, men inte konsekvent över diskar. Detta kan orsaka problem i vissa fall (till exempel vid diskstrimning).
Använd Azure Site Recovery för att replikera program mellan regioner. Med Azure Site Recovery behöver kunderna inte bekymra sig om att separera datadiskar från operativsystemdiskar eller om potentiella konsekvensproblem. Azure Site Recovery replikerar arbetsbelastningar som körs på fysiska och virtuella datorer från en primär plats (antingen lokalt eller i Azure) till en sekundär plats (i Azure). När ett avbrott inträffar på kundens primära plats kan en redundansväxling utlösas för att snabbt återställa kunden till ett drifttillstånd. När den primära platsen har återställts kan kunderna sedan återställa. De kan enkelt replikera med hjälp av återställningspunkter med programkonsekventa ögonblicksbilder. Dessa ögonblicksbilder samlar in diskdata, alla minnesinterna data och alla pågående transaktioner. Med Azure Site Recovery kan kunderna hålla mål för återställningstid (RTO) och mål för återställningspunkter (RPO) inom organisationens gränser. Kunder kan också enkelt köra programåterställningstest utan att påverka program i produktion. Med hjälp av återställningsplaner kan kunder sekvensera redundansväxling och återställning av program med flera nivåer som körs på flera virtuella datorer. De kan gruppera datorer i en återställningsplan och eventuellt lägga till skript och manuella åtgärder. Återställningsplaner kan integreras med Azure Automation runbooks.

Storage

Återställning med hjälp av geo-redundant lagring av blob-, tabell-, kö- och VM-disklagring

I Azure är blobar, tabeller, köer och VM-diskar alla geo-replikerade som standard. Detta kallas geo-redundant lagring (GRS). GRS replikerar lagringsdata till ett kopplat datacenter som ligger hundratals mil från varandra i en specifik geografisk region. GRS är utformat för att ge ytterligare hållbarhet om det uppstår en större datacenterkatastrof. Microsoft kontrollerar när redundansväxling sker och redundans är begränsad till större katastrofer där den ursprungliga primära platsen bedöms vara oåterkallelig inom rimlig tid. I vissa scenarier kan det ta flera dagar. Data replikeras vanligtvis inom några minuter, även om synkroniseringsintervallet ännu inte omfattas av ett serviceavtal.

Om en geo-redundans sker ändras inte kontots åtkomst (URL:en och kontonyckeln ändras inte). Lagringskontot kommer dock att finnas i en annan region efter redundansväxlingen. Detta kan påverka program som kräver regional tillhörighet med deras lagringskonto. Även för tjänster och program som inte kräver ett lagringskonto i samma datacenter kan avgifterna för svarstider och bandbredd mellan datacenter vara tvingande skäl att tillfälligt flytta trafik till redundansregionen. Detta kan ta hänsyn till en övergripande strategi för haveriberedskap.

Förutom automatisk redundans som tillhandahålls av GRS har Azure introducerat en tjänst som ger dig läsåtkomst till kopian av dina data på den sekundära lagringsplatsen. Detta kallas read-access geo-redundant storage (RA-GRS).

Mer information om både GRS- och RA-GRS-lagring finns i Azure Storage-replikering.

Regionmappningar för geo-replikering

Det är viktigt att veta var dina data är geo-replikerade för att veta var du ska distribuera de andra instanserna av dina data som kräver regional tillhörighet med din lagring. Mer information finns i Länkade Azure-regioner.

Prissättning för Geo-replikering

Geo-replikering ingår i den aktuella prissättningen för Azure Storage. Detta kallas geo-redundant lagring (GRS). Om du inte vill att dina data ska replikeras kan du inaktivera geo-replikering för ditt konto. Detta kallas lokalt redundant lagring (LRS) och debiteras till ett rabatterat pris jämfört med GRS.

Avgöra om en geo-redundansväxling har inträffat

Om en geo-redundans inträffar publiceras detta på Azure Service Health-instrumentpanelen. Program kan dock implementera ett automatiserat sätt att identifiera detta genom att övervaka geo-regionen för deras lagringskonto. Detta kan användas för att utlösa andra återställningsåtgärder, till exempel aktivering av beräkningsresurser i den geo-region där deras lagring flyttades till. Du kan utföra en fråga för detta från tjänsthanterings-API:et med hjälp av Hämta lagringskontoegenskaper. De relevanta egenskaperna är:

<GeoPrimaryRegion>primary-region</GeoPrimaryRegion>
<StatusOfPrimary>[Available|Unavailable]</StatusOfPrimary>
<LastGeoFailoverTime>DateTime</LastGeoFailoverTime>
<GeoSecondaryRegion>secondary-region</GeoSecondaryRegion>
<StatusOfSecondary>[Available|Unavailable]</StatusOfSecondary>

Databas

SQL Database

Azure SQL Database innehåller två typer av återställning: geo-återställning och aktiv geo-replikering.

Geo-återställning

Geo-återställning är också tillgängligt med Basic-, Standard- och Premium-databaser. Den tillhandahåller standardåterställningsalternativet när databasen inte är tillgänglig på grund av en incident i den region där databasen finns. På samma sätt som vid återställning till tidpunkt förlitar sig geo-återställning på databassäkerhetskopior i geo-redundant Azure Storage. Den återställs från den geo-replikerade säkerhetskopian och är därför motståndskraftig mot lagringsfelen i den primära regionen. Mer information finns i Återställa en Azure SQL-databas eller redundans till en sekundär databas.

Aktiv geo-replikering

Aktiv geo-replikering är tillgänglig för alla databasnivåer. Den är utformad för program som har mer aggressiva återställningskrav än vad geo-återställning kan erbjuda. Med aktiv geo-replikering kan du skapa upp till fyra läsbara sekundärfiler på servrar i olika regioner. Du kan initiera redundansväxling till någon av sekundärfilerna. Dessutom kan aktiv geo-replikering användas för att stödja scenarier för programuppgradering eller omplacering samt belastningsutjämning för skrivskyddade arbetsbelastningar. Mer information finns i Konfigurera aktiv geo-replikering för Azure SQL Database och initiera redundans. Se Designa globalt tillgängliga tjänster med Azure SQL Database och Hantera löpande uppgraderingar av molnprogram med hjälp av SQL Database aktiv geo-replikering för mer information om hur du utformar och implementerar program och programuppgradering utan driftstopp.

SQL Server på Azure Virtual Machines

Det finns en mängd olika alternativ för återställning och hög tillgänglighet för SQL Server 2012 (och senare) som körs i Azure Virtual Machines. Mer information finns i Hög tillgänglighet och haveriberedskap för SQL Server i Azure Virtual Machines.

Andra Azure-plattformstjänster

När du försöker köra din molntjänst i flera Azure-regioner måste du överväga konsekvenserna för vart och ett av dina beroenden. I följande avsnitt förutsätter den tjänstspecifika vägledningen att du måste använda samma Azure-tjänst i ett alternativt Azure-datacenter. Detta omfattar både konfigurations- och datareplikeringsuppgifter.

Anteckning

I vissa fall kan de här stegen bidra till att minska ett tjänstspecifikt avbrott i stället för en hel datacenterhändelse. Ur programperspektiv kan ett tjänstspecifikt avbrott vara lika begränsande och kräver att tjänsten tillfälligt migreras till en annan Azure-region.

Service Bus

Azure Service Bus använder ett unikt namnområde som inte omfattar Azure-regioner. Det första kravet är därför att konfigurera nödvändiga Service Bus-namnområden i den alternativa regionen. Det finns dock även överväganden för varaktigheten för de köade meddelandena. Det finns flera strategier för att replikera meddelanden i Azure-regioner. Mer information om dessa replikeringsstrategier och andra strategier för haveriberedskap finns i Metodtips för att isolera program mot Service Bus-avbrott och katastrofer.

App Service

Om du vill migrera ett Azure App Service program, till exempel Web Apps eller Mobile Apps, till en sekundär Azure-region måste du ha en säkerhetskopia av webbplatsen som är tillgänglig för publicering. Om avbrottet inte omfattar hela Azure-datacentret kan det vara möjligt att använda FTP för att ladda ned en nyligen utförd säkerhetskopia av webbplatsinnehållet. Skapa sedan en ny app i den alternativa regionen, såvida du inte tidigare har gjort detta för att reservera kapacitet. Publicera webbplatsen till den nya regionen och gör nödvändiga konfigurationsändringar. Dessa ändringar kan omfatta databasanslutningssträngar eller andra regionsspecifika inställningar. Om det behövs lägger du till platsens SSL-certifikat och ändrar DNS CNAME-posten så att det anpassade domännamnet pekar på den omdistribuerade Url:en för Azure Web App.

HDInsight

De data som är associerade med HDInsight lagras som standard i Azure Blob Storage. HDInsight kräver att ett Hadoop-kluster som bearbetar MapReduce-jobb måste samplaceras i samma region som lagringskontot som innehåller de data som analyseras. Förutsatt att du använder geo-replikeringsfunktionen som är tillgänglig för Azure Storage kan du komma åt dina data i den sekundära regionen där data replikerades om den primära regionen av någon anledning inte längre är tillgänglig. Du kan skapa ett nytt Hadoop-kluster i den region där data har replikerats och fortsätta bearbeta dem.

SQL Reporting

För närvarande kräver återställning efter förlusten av en Azure-region flera SQL Reporting instanser i olika Azure-regioner. Dessa SQL Reporting instanser bör ha åtkomst till samma data och dessa data bör ha en egen återställningsplan i händelse av en katastrof. Du kan också underhålla externa säkerhetskopior av RDL-filen för varje rapport.

Media Services

Azure Media Services har en annan återställningsmetod för kodning och strömning. Normalt är strömning mer kritiskt under ett regionalt avbrott. För att förbereda dig för detta bör du ha ett Media Services-konto i två olika Azure-regioner. Det kodade innehållet ska finnas i båda regionerna. Under ett fel kan du omdirigera strömmande trafik till den alternativa regionen. Kodning kan utföras i valfri Azure-region. Om kodningen är tidskänslig, till exempel vid bearbetning av livehändelser, måste du vara beredd att skicka jobb till ett alternativt datacenter vid fel.

Virtuellt nätverk

Konfigurationsfiler är det snabbaste sättet att konfigurera ett virtuellt nätverk i en alternativ Azure-region. När du har konfigurerat det virtuella nätverket i den primära Azure-regionen exporterar du inställningarna för det virtuella nätverket för det aktuella nätverket till en nätverkskonfigurationsfil. Om ett avbrott inträffar i den primära regionen återställer du det virtuella nätverket från den lagrade konfigurationsfilen. Konfigurera sedan andra molntjänster, virtuella datorer eller lokala inställningar så att de fungerar med det nya virtuella nätverket.
Det finns VNET-relaterade resurser som vi måste ta hänsyn till (till exempel NSG, DNS, routningstabeller). Metoden som beskrivs i Infrastruktur som en kod är ett sätt att generera samma miljö varje gång och du kan distribuera i en ny region.

Checklistor för haveriberedskap

Cloud Services checklista

Granska avsnittet Cloud Services i det här dokumentet.
Skapa en strategi för haveriberedskap mellan regioner.
Förstå kompromisser när det gäller att reservera kapacitet i alternativa regioner.
Använd verktyg för trafikroutning, till exempel Azure Traffic Manager.

checklista för Virtual Machines

Granska avsnittet Virtual Machines i det här dokumentet.
Använd Azure Backup för att skapa program konsekventa säkerhetskopior mellan regioner.

Checklista för lagring

Granska avsnittet Lagring i det här dokumentet.
Inaktivera inte geo-replikering av lagringsresurser.
Förstå alternativ region för geo-replikering om en redundansväxling inträffar.
Skapa anpassade säkerhetskopieringsstrategier för användarkontrollerade redundansstrategier.

checklista för SQL Database

Granska avsnittet SQL Database i det här dokumentet.
Använd Geo-återställning eller geo-replikering efter behov.

SQL Server på checklistan för Virtual Machines

Granska avsnittet SQL Server i Virtual Machines i det här dokumentet.
Använd AlwaysOn-tillgänglighetsgrupper för flera regioner eller databasspegling.
Du kan också använda säkerhetskopiering och återställning till bloblagring.

Checklista för Service Bus

Läs avsnittet Service Bus i det här dokumentet.
Konfigurera ett Service Bus-namnområde i en alternativ region.
Överväg anpassade replikeringsstrategier för meddelanden mellan regioner.

checklista för App Service

Granska avsnittet App Service i det här dokumentet.
Underhåll säkerhetskopior utanför den primära regionen.
Om avbrottet är partiellt försöker du hämta den aktuella platsen med FTP.
Planera att distribuera platsen till en ny eller befintlig plats i en alternativ region.
Planera konfigurationsändringar för både program- och DNS CNAME-poster.

Checklista för HDInsight

Granska avsnittet HDInsight i det här dokumentet.
Skapa ett nytt Hadoop-kluster i regionen med replikerade data.

checklista för SQL Reporting

Granska avsnittet SQL Reporting i det här dokumentet.
Underhåll en alternativ SQL Reporting instans i en annan region.
Underhåll en separat plan för att replikera målet till den regionen.

Checklista för Media Services

Läs avsnittet Media Services i det här dokumentet.
Skapa ett Media Services-konto i en alternativ region.
Koda samma innehåll i båda regionerna för att stödja strömningsredundans.
Skicka kodningsjobb till en annan region om en tjänststörning inträffar.

checklista för Virtual Network

Granska avsnittet Virtual Network i det här dokumentet.
Använd exporterade inställningar för virtuella nätverk för att återskapa det i en annan region.