Vad är redundans, replikering och säkerhetskopiering?

Vi tänker ofta på molnet som ett globalt distribuerat, allestädes närvarande system. Men i verkligheten består molnet av maskinvara som körs i datacenter. Återhämtning kräver att du tar hänsyn till några av de risker som är kopplade till de fysiska platser där dina molnbaserade komponenter körs.

Den här artikeln innehåller en allmän introduktion till redundans, replikering och säkerhetskopiering, som är metoder som används för att skapa arbetsbelastningar som är motståndskraftiga mot fysiska risker som orsakar avbrott i tjänsten, avbrott eller dataförlust.

Redundans är möjligheten att underhålla flera identiska kopior av en tjänstkomponent och att använda dessa kopior på ett sätt som förhindrar att en komponent blir en enskild felpunkt.

Replikering eller dataredundans är möjligheten att underhålla flera kopior av data, så kallade repliker.

Säkerhetskopiering är möjligheten att underhålla en tidsstämplad kopia av data som kan användas för att återställa data som har gått förlorade.

Ur ett tillförlitlighetsperspektiv är ett viktigt sätt att minimera många risker att inkludera någon form av redundans, replikering eller säkerhetskopiering i planeringen för affärskontinuitet.

Redundans

Redundans består av att distribuera flera instanser av en komponent. Redundans är enkelt att förstå, men i vissa situationer kan det bli komplext att implementera.

När du börjar förstå redundans är det enklast att överväga redundans i förhållande till tillståndslösa komponenter, som är komponenter som inte lagrar några data. Även om de flesta verkliga lösningar kräver hanteringstillstånd, diskuterar vi i det här avsnittet redundans när det gäller ett exempel på ett tillståndslöst programprogramprogramgränssnitt (API). Exempel-API:et accepterar indata, fungerar på indata och returnerar sedan utdata utan att lagra några data. I följande avsnitt, Replikering: Redundans för data, lägger vi till överväganden för tillståndskänslig redundans.

Scenario: Tillståndslös redundans

I det här exemplet distribueras en tillståndslös API-komponent till en virtuell dator. För att undvika stilleståndstid för API-komponenten om det uppstår ett maskinvarufel på den fysiska värden implementerar exemplet en redundant lösning som:

• Distribuerar flera kopior av API-instansen.
• Implementerar en lastbalanserare för att distribuera begäranden mellan API-instanser.

Lastbalanseraren övervakar hälsotillståndet för varje instans för att endast skicka begäranden till felfria instanser.

Redundansöverväganden

När du implementerar redundanta lösningar, till exempel i scenariot ovan, är det viktigt att tänka på följande:

• Resurskostnader. Per definition innebär redundans att ha flera kopior av något, vilket ökar den totala kostnaden för att vara värd för lösningen.

• Prestanda Ju bredare geografiskt område du distribuerar kopiorna av sakerna, desto fler risker hjälper du till att minimera. Förfrågningar från klienter kommer dock att ta längre tid att nå längre avstånd eftersom de måste passera mer nätverksinfrastruktur, vilket ökar nätverksfördröjningen.

  I de flesta verkliga situationer är nätverksfördröjningen oviktig för korta avstånd, till exempel inom ett datacenter eller till och med att gå mellan datacenter i en stad. Men om du distribuerar kopior över en lång sträcka kan nätverksfördröjningen bli mer betydande.

• Konsekvens av instanser. Det är viktigt att hålla instanserna konsekventa med varandra och att undvika att konfigurera instanser individuellt eftersom du oavsiktligt kan införa skillnader mellan instanserna. Om det finns skillnader mellan instanser kan begäranden bearbetas på olika sätt beroende på vilken instans som hanterar dem. Detta kan orsaka svårdiagnostiserade buggar och beteenden.

• Distribution av arbete. När du har flera instanser av en komponent måste du distribuera arbete mellan dem. Du kan sprida arbete över alla instanser på samma sätt, eller så kan du skicka begäranden till en enda primär instans och endast använda en sekundär instans om den primära instansen inte är tillgänglig.

  För komponenter som tar emot inkommande begäranden används lastbalanserare ofta för att skicka dessa begäranden till instanser. Ibland fungerar dock komponenter oberoende av varandra och tar inte emot begäranden från klienter, så i dessa situationer kan instanser behöva samordna sitt arbete med varandra.

• Hälsoövervakning. Hälsotillståndet för varje instans avgör om den instansen kan utföra sitt arbete, och hälsoövervakning är viktigt för att aktivera snabb återställning om det uppstår ett problem.

  Lastbalanserare utför vanligtvis hälsoövervakning. För komponenter som inte innehåller en lastbalanserare kan du ha en extern komponent som övervakar hälsotillståndet för alla instanser, eller så kan varje instans övervaka hälsotillståndet för andra instanser.

Fysiska platser i molnet

Behovet av redundans är tydligt när du förstår att även i en molnmiljö lagras en instans eller en databit på en specifik fysisk plats.

Till exempel:

• En virtuell dator körs på en enda fysisk plats samtidigt.
• Data lagras på en specifik fysisk plats, till exempel på en solid state-enhet (SSD) eller hårddisk som är ansluten till servrar.

Även om det finns flera kopior av en del data eller instanser av en komponent, är varje kopia kopplad till den fysiska maskinvara som den lagras på.

En molnmiljös fysiska plats som helhet kan ordnas i fysiska omfång. Vid varje fysiskt omfång finns det potentiella risker som kan äventyra komponenterna eller data inom det omfånget. Här är en icke-fullständig lista över risker som kan definieras när det gäller fysisk omfång:

Ur ett tillförlitlighetsperspektiv är ett viktigt sätt att minska riskerna med ett fysiskt omfång att sprida instanser av en komponent över olika fysiska omfång. Azure-tjänster med inbyggd redundans kan erbjuda ett eller flera av följande tre sätt att distribuera redundanta instanser:

• Lokal redundans placerar instanser i flera delar av ett enda Azure-datacenter och skyddar mot maskinvarufel som kan påverka en enskild instans. Lokal redundans ger vanligtvis den lägsta kostnaden och svarstiden. Ett datacenterfel kan dock innebära att alla instanser inte är tillgängliga.

• Zonredundans sprider instanser över flera tillgänglighetszoner i en enda Azure-region. Zonredundans skyddar mot datacenterfel, förutom maskinvarufel.

• Geo-redundans placerar instanser i flera Azure-regioner och ger skydd mot storskaliga regionala avbrott. Geo-redundans medför en högre kostnad och kräver att du överväger din bredare lösningsdesign och hur du växlar mellan instanser av dina komponenter i varje region. Du måste också överväga svarstid, vilket beskrivs i Synkron och asynkron replikering.

Så här fungerar redundans i Azure: Compute Services

Redundans används i nästan alla delar av Azure. Som ett exempel på hur Azure implementerar redundans bör du överväga de tjänster som kör beräkningsarbetsbelastningar.

I Azure körs en enskild virtuell dator (VM) på en enda fysisk värd i ett Azure-datacenter. Du kan ge instruktioner till Azure för att säkerställa att den virtuella datorn körs på den plats du förväntar dig, till exempel regionen och tillgänglighetszonen, och i vissa situationer kanske du till och med vill placera den på en värd som är dedikerad till dig.

Det är vanligt att köra flera instanser av en virtuell dator. I det scenariot kan du välja att antingen hantera dem individuellt eller med hjälp av en VM-skalningsuppsättning. När du använder en skalningsuppsättning kan du fortfarande se de enskilda virtuella datorer som ligger till grund för den, men skalningsuppsättningen innehåller en mängd funktioner som hjälper dig att hantera redundanta virtuella datorer. Dessa funktioner omfattar automatisk placering av de virtuella datorerna baserat på regler som du anger, till exempel genom att sprida dem över feldomäner inom regionen eller tillgänglighetszonen .

Det finns många andra Azure-beräkningstjänster som förlitar sig på virtuella datorer för att utföra beräkningsuppgifter. Beräkningstjänster erbjuder vanligtvis olika redundansinställningar som avgör hur de virtuella datorerna distribueras. En tjänst kan till exempel tillhandahålla en zonredundansinställning, som du kan aktivera för att automatiskt distribuera virtuella datorer mellan tillgänglighetszoner och konfigurera belastningsutjämning.

Replikering: Redundans för data

Redundans, när den tillämpas på tillstånd (data), kallas replikering. Med replikering kan du underhålla flera realtidskopior eller nästan realtidskopior av livedata, så kallade repliker. För att förbättra motståndskraften mot risker kan du distribuera repliker över olika platser. Om en replik blir otillgänglig kan systemet redundansväxla så att en annan replik tar över dess funktion.

Det finns olika typer av replikering och var och en prioriterar olika datakonsekvens, prestanda och kostnad. Varje replikeringstyp påverkar två viktiga mått som används i diskussioner om affärskontinuitet: mål för återställningstid (RTO), vilket är den maximala mängden stilleståndstid som du kan tolerera i ett katastrofscenario och mål för återställningspunkt (RPO), vilket är den maximala mängden dataförlust som du kan tolerera i ett katastrofscenario. Mer information om dessa mått och hur de relaterar till affärskontinuitet finns i Vad är affärskontinuitet, hög tillgänglighet och haveriberedskap?.

På grund av replikeringens betydelse för att uppfylla funktions- och prestandakraven omfattar de flesta databassystem och andra produkter och tjänster för datalagring någon form av replikering som en nära integrerad funktion. De typer av replikering som de erbjuder baseras vanligtvis på deras arkitektur och hur de är avsedda att användas. Mer information om vilka typer av replikering som stöds av Azure-tjänster finns i tillförlitlighetsguider för Azure-tjänster.

Synkron och asynkron replikering

När du replikerar data måste alla ändringar av dessa data hållas synkroniserade mellan repliker. Det finns ett par primära utmaningar när du försöker upprätthålla konsekvens när data ändras:

• Latens. Att uppdatera en replik tar tid, och ju längre ifrån varandra replikerna är, desto längre tid tar det att överföra data över avståndet mellan replikerna och ta emot en bekräftelse.

• Ändringshantering. Data kan ändras medan repliker synkroniseras och därför kan det bli komplext att hantera datakonsekvensen.

För att hantera dessa utmaningar finns det två huvudsakliga sätt att replikera dataändringar och hantera datakonsekvens:

• Synkron replikering kräver att uppdateringar utförs på flera repliker innan uppdateringen anses vara klar. Följande diagram visar hur synkron replikering fungerar:

  

  I det här exemplet sker följande stegsekvens:

  1. En klient ändrar data och begäran skickas till replik 1, som bearbetar begäran och lagrar ändrade data.
  2. Replik 1 skickar ändringarna till replik 2, som bearbetar begäran och lagrar ändrade data.
  3. Replik 2 bekräftar ändringen tillbaka till replik 1.
  4. Replik 1 bekräftar ändringen tillbaka till klienten.

  Synkron replikering kan garantera konsekvens, vilket innebär att den kan stödja ett RPO på noll. Detta sker dock på bekostnad av prestanda. Ju längre ifrån varandra dina repliker är geografiskt och ju fler nätverkshopp som behöver passeras, desto mer svarstid introduceras av replikeringsprocessen.

• Asynkron replikering sker i bakgrunden. Följande diagram visar hur asynkron replikering fungerar:

  

  I det här exemplet sker följande stegsekvens:

  1. En klient ändrar data och begäran skickas till replik 1.
  2. Replik 1 bearbetar begäran, lagrar ändrade data och bekräftar omedelbart ändringen tillbaka till klienten.
  3. Någon gång senare synkroniserar replik 1 ändringen till replik 2.

  Eftersom asynkron replikering sker utanför transaktionsflöden, tar den bort replikeringen som ett villkor för programmets prestanda. Men om du behöver skifta över till en annan replik kanske den inte har de senaste uppgifterna, och därför måste ditt RPO vara större än noll. Den exakta RPO som asynkron replikering kan stödja beror på replikeringsfrekvensen.

Replikroller

I många replikeringssystem kan repliker ha olika roller, vilket hjälper till att samordna ändringar i data och minskar risken för konflikter. Det finns två huvudsakliga typer av roller, aktiva och passiva. Det finns två vanliga sätt att distribuera repliker med dessa roller:

• Aktiv-passiv replikering innebär att du har en aktiv replik som ansvarar för att fungera som sanningskälla. Alla ändringar som görs i data måste tillämpas på dess kopia. Andra repliker fungerar i en passiv roll, vilket innebär att de tar emot uppdateringar av data från den aktiva repliken, men de bearbetar inte ändringar direkt från klienter. Passiva repliker används inte för livetrafik förutom när en omkoppling sker och replikernas roller ändras. Följande diagram visar ett aktivt-passivt system med en passiv replik:

  

  I ett aktivt-passivt system bestämmer den tid det tar att övergå till ett annat system RTO. Vanligtvis mäts RTO för ett aktivt-passivt system i minuter.

  Vissa replikeringslösningar stöder också skrivskyddade repliker, vilket gör att du kan läsa (men inte skriva) data från passiva repliker. Den här metoden kan vara användbar för att få mer användning från dina repliker, till exempel när du behöver utföra analys eller rapportering av data utan att påverka den primära replik som du använder för programmets transaktionsarbete. Flera Azure-tjänster stöder skrivskyddade repliker, inklusive Azure Storage med replikeringstypen GRS (RA-GRS) och aktiv geo-replikering i Azure SQL Database.

• Aktiv-aktiv replikering möjliggör användning av flera aktiva repliker för livetrafik samtidigt, och någon av replikerna kan bearbeta begäranden:

  

  Aktiv-aktiv replikering möjliggör en hög prestandanivå eftersom systemet kan använda resurserna på alla repliker. Aktiv-aktiv replikering kan stödja en RTO på noll i vissa situationer. Dessa fördelar kommer dock på bekostnad av att komplicera datakonsekvensen, eftersom samtidiga konkurrerande ändringar på flera repliker kan behöva stämmas av asynkront.

Komplexa datatjänster kan kombinera både aktiv-aktiv och aktiv-passiv replikering. De kan till exempel distribuera en uppsättning repliker i en Azure-region och en annan i en annan region. Inom varje region hanterar en enda aktiv replik begäranden medan en eller flera passiva repliker är i beredskap för redundansväxling. Under tiden fungerar båda regionerna i en aktiv-aktiv modell, vilket gör att trafiken kan distribueras över dem.

Så här fungerar replikering i Azure-datatjänster

Varje Azure-tjänst som lagrar data erbjuder någon form av replikering. Varje tjänst kan dock använda en annan metod som är specifik för tjänstens arkitektur och avsedda användningsområden.

Azure Storage kan till exempel tillhandahålla både synkron och asynkron replikering via en uppsättning funktioner:

• Flera kopior av dina data replikeras synkront inom din primära region. Du kan välja om du vill placera repliker på olika fysiska maskinvara i ett enda datacenter i lokalt redundant lagring (LRS) eller sprida dem över flera tillgänglighetszoner för zonredundant lagring (ZRS).
• Om din primära region är kopplad och du aktiverar geo-redundant lagring (GRS) replikeras även data till den kopplade regionen. Eftersom de kopplade regionerna är geografiskt avlägsna sker den här replikeringen asynkront för att minska effekten på programmets dataflöde.
• Du kan välja att använda zonredundant lagring och geo-redundant lagring samtidigt med hjälp av den geo-zonredundanta lagringsnivån (GZRS). Data i regionen replikeras synkront och data mellan regioner replikeras asynkront.

Läs mer i Redundansalternativ för Azure Storage.

Ett annat exempel är Azure Cosmos DB, som också tillhandahåller replikering. Alla Azure Cosmos DB-databaser har flera repliker. När du distribuerar repliker globalt har den stöd för skrivningar i flera regioner, där klienter kan skriva till en replik i någon av de regioner som du använder. Dessa skrivåtgärder replikeras synkront inom regionen och replikeras sedan asynkront i andra regioner. Azure Cosmos DB tillhandahåller en konfliktlösningsmekanism om det uppstår skrivkonflikter mellan de olika replikerna. Mer information finns i Global datadistribution med Azure Cosmos DB – under huven.

Om du använder virtuella datorer kan du använda Azure Site Recovery för att replikera virtuella datorer och deras diskar mellan tillgänglighetszoner eller till en annan Azure-region.

När du utformar en Azure-lösning kan du läsa tillförlitlighetsguiderna för varje tjänst för att förstå hur tjänsten tillhandahåller redundans och replikering, inklusive på olika platser.

Säkerhetskopiering

Säkerhetskopieringen tar en kopia av dina data vid en viss tidpunkt. Om det uppstår ett problem kan du återställa säkerhetskopian senare. Ändringar av dina data som gjordes efter säkerhetskopieringen kommer dock inte att finnas i säkerhetskopian och kan gå förlorade.

Genom att använda säkerhetskopiering kan du tillhandahålla lösningar för att säkerhetskopiera och återställa dina data i eller till Microsoft Azure-molnet. Säkerhetskopiering kan skydda dig mot en mängd olika risker, bland annat:

• Katastrofala förluster av maskinvara eller annan infrastruktur.
• Skadade och borttagna data.
• Cyberattacker, till exempel utpressningstrojaner.

Hur säkerhetskopiering påverkar dina krav

När de används som en del av en strategi för haveriberedskap stöder säkerhetskopior vanligtvis en RTO och RPO som mäts i timmar:

• RTO påverkas av den tid det tar för dig att initiera och slutföra dina återställningsprocesser, inklusive att återställa en säkerhetskopia och verifiera att återställningen har slutförts. Beroende på storleken på säkerhetskopieringen och hur många säkerhetskopieringsfiler som behöver läsas från är det vanligt att det tar flera timmar eller ännu längre tid att återställa en säkerhetskopia helt.

• RPO påverkas av frekvensen för säkerhetskopieringsprocessen. Om du gör säkerhetskopieringar oftare innebär det att du förlorar mindre data om du måste återställa från en säkerhetskopia. Säkerhetskopior kräver dock lagring, och i vissa situationer kan de påverka tjänstens prestanda när säkerhetskopieringar görs. Därför måste du överväga säkerhetskopieringsfrekvensen och hitta rätt balans för organisationens krav. Säkerhetskopieringsfrekvens bör beaktas vid planering av affärskontinuitet.

Vissa säkerhetskopieringssystem stöder mer komplexa säkerhetskopieringskrav, inklusive flera säkerhetskopieringsnivåer med olika kvarhållningsperioder och differentiella eller inkrementella säkerhetskopieringar som går snabbare att spara och förbruka mindre lagringsutrymme.

Säkerhetskopiering i Azure-tjänster

Många Azure-tjänster tillhandahåller säkerhetskopieringsfunktioner för dina data.

Azure Backup är en dedikerad säkerhetskopieringslösning för flera viktiga Azure-tjänster, inklusive virtuella datorer, Azure Storage och Azure Kubernetes Service (AKS).

Dessutom tillhandahåller många hanterade databaser sina egna säkerhetskopieringsfunktioner som en del av tjänsten, till exempel:

• Azure SQL Database tillhandahåller automatiserade säkerhetskopieringar.
• Azure Cosmos DB tillhandahåller både kontinuerliga och periodiska säkerhetskopieringsfunktioner.
• Med Azure Key Vault kan du ladda ned en säkerhetskopia av data i valvet.
• Azure App Service tillhandahåller både automatisk och anpassad säkerhetskopiering för webbprogram och kan även säkerhetskopiera sina databaser.

Säkerhetskopiering jämfört med replikering

Säkerhetskopiering och replikering skyddar dig mot olika risker, och de två metoderna kompletterar varandra.

Replikering stöder daglig återhämtning och används ofta i en strategi för hög tillgänglighet. Vissa replikeringsmetoder kräver lite eller ingen avbrottstid eller dataförlust och har stöd för låg RTO och RPO. Replikering skyddar dig dock inte mot risker som leder till dataförlust eller skada.

Säkerhetskopiering är däremot ofta en sista försvarslinje mot katastrofala risker. Säkerhetskopieringar kräver ofta en relativt hög RTO och RPO, även om sättet du konfigurerar säkerhetskopieringar på påverkar exakt hur högt de kommer att vara. En total återställning från en säkerhetskopia ingår ofta i en haveriberedskapsplan.

Förbereda komponenter för redundans

När du utformar ett system som använder redundans som en del av sin arkitektur är det viktigt att även tänka på hur du:

• Duplicera resurskonfiguration för konsekvens.
• Hantera kapacitet vid fel i instansen genom överdimensionering.

Duplicerad resurskonfiguration

I molnmiljöer är konfigurationen av var och en av dina resurser kritisk. När du till exempel skapar en lastbalanserare för nätverket konfigurerar du en mängd olika inställningar som påverkar hur den fungerar. och när du distribuerar en funktion med hjälp av Azure Functions konfigurerar du inställningar som rör inställningar för säkerhet, prestanda och programkonfiguration. Varje resurs i Azure har någon form av konfiguration som driver dess beteende.

När du hanterar redundanta kopior av resurser på olika platser är det viktigt att du styr deras konfiguration. Många inställningar måste konfigureras på samma sätt för varje kopia, så att resurserna fungerar på samma sätt. Men vissa inställningar kan skilja sig åt mellan varje kopia, till exempel referenser till en specifik regions virtuella nätverk.

En vanlig metod för att upprätthålla konsekvens i resurserna är att använda Infrastructure as Code (IaC), som Bicep eller Terraform. Med de här verktygen kan du skapa filer som definierar en resurs, och du kan återanvända dessa definitioner för varje instans av resursen. Genom att använda IaC kan du minska bördan att skapa och hantera flera instanser av resurser i återhämtningssyfte, och det finns även många andra fördelar. Mer information finns i Vad är infrastruktur som kod (IaC)? och Rekommendationer för att använda infrastruktur som kod.

Hantera kapacitet med överallokering

När en instans havererar kan den totala systemkapaciteten skilja sig från den kapacitet som krävs under normala driften. Anta till exempel att du vanligtvis har sex instanser av en webbserver för att bearbeta din inkommande webbtrafik och att dessa instanser är jämnt fördelade mellan tre Azure-tillgänglighetszoner i en region:

Om ett avbrott uppstår i en tillgänglighetszon kan du tillfälligt förlora två instanser och bara ha fyra webbserverinstanser kvar. Om ditt program vanligtvis är upptaget och kräver att alla sex instanserna hänger med i din normala trafik kan körning med nedsatt kapacitet påverka lösningens prestanda.

För att förbereda för fel kan du överetablera tjänstens kapacitet. Överetablering gör att lösningen kan tolerera en viss grad av kapacitetsförlust och fortfarande fortsätta att fungera utan försämrad prestanda.

Följ dessa steg för att överprovisionera instanser av din webbserver för att hantera felet i en tillgänglighetszon:

1. Fastställa antalet instanser som din högsta arbetsbelastning kräver.
2. Skapa antalet överallokeringsinstanser genom att multiplicera det högsta antalet arbetsbelastningsinstanser med en faktor av [(zoner/(zoner-1)].
3. Avrunda resultatet till närmaste heltal.

I föregående exempel kräver den högsta arbetsbelastningen sex instanser av webbservern, så överetablering kräver totalt nio instanser:

Nästa steg

Lär dig mer om redundans och återställning efter fel.