Haveriberedskapstjänster
Av uppenbara skäl är återställning av säkerhetskopierade data en standardfunktion i säkerhetskopieringstjänster. Katastrofer handlar dock inte bara om dataförlust. Ett avbrott som förhindrar att en organisations servrar, oavsett om de är verkliga, virtuella, lokala eller molnbaserade, är tillgängliga påverkar organisationen på ett negativt – ibland till och med katastrofalt – sätt. Syftet med en haveriberedskapstjänst (DR, Disaster Recovery) är att säkerhetskopiera inte bara data och enskilda resurser utan hela system, så att tjänsten kan återupptas om dessa system slutar fungera eller går offline genom att trafik replikeras till repliker som är redo att hantera belastningen.
Haveriberedskap är det område där det offentliga molnet verkligen kommer till pass. Det är mer än bara en enorm bandenhet. Eftersom molnresurser är virtuella kan repliker köras igång på ett ögonblick och ersätta resurser som försvinner plötsligt. Repliker kan även hanteras på olika ställen i världen än de system som de speglar, detta i syfte att kringgå omfattande avbrott. När vi jämför det med kostnaden för att underhålla fysiska repliker av fysiska informationssystem (och att försöka göra det på geografiskt spridda platser) blir fördelarna med molnet vad gäller att upprätthålla kontinuiteten hos dessa system uppenbara.
Ledande molnleverantörer erbjuder DRaaS (Haveriberedskap som en tjänst), men dessa tjänster måste avsiktligen planeras och konfigureras för att erbjuda det redundansstöd som kunder behöver. Därför börjar vi med att gå igenom de mål och mått som ingår i planeringen.
Mål och mått
Under en katastrof kan en organisation och dess kunder förlora åtkomst till flera klasser av digitala tillgångar samtidigt. De viktigaste av dessa är:
Databaser och datalager, som utöver att de registrerar viktigt information om kunder och varor eller tjänster i lagret även upprätthåller det aktiva tillståndet för affärstransaktioner och processer för hela organisationen
Bulkdata, däribland dokument, mediefiler och andra sparade poster som skapas av de program som personer använder
Kommunikation och anslutningar med människor och affärstjänster som utgör kärnan i affärsverksamheten
Program som representerar organisationens butiker för kunder och besökare samt dess egna intressenter
DR (haveriberedskap) presenteras för kunder som en enskild tjänst, men återställningsprocessen för var och en av dessa klasser är separat från de andra. I klient/server-modellens tidsålder utförde många organisationer vardagsarbetet på persondatorer. Om en PC slutade fungera och det fanns en säkerhetskopierad avbildning av datorns lokala lagring kunde den teoretiskt sett återställas till en ny dator så att arbetet kunde fortsätta. Med de första nätverksanslutna datorerna som var anslutna via LAN-operativsystem och Ethernet-kabeln gick det att återställa alla datorer i nätverket från en säkerhetskopierad avbildning, och därefter kunde nätverket självt återupptas.
Molnet fungerar inte på det här sättet. Inte ens en virtuell dator som fungerar som en server för organisationens program kapslar in det arbete som den utför helt och hållet. Säkerhetskopieringstjänster erbjuder säkerhetsnät för bulkdata samt i begränsad utsträckning transaktionsdata och databaser. Men alla dessa entiteter är fristående komponenter. Därför kräver återställning av affärsfunktionerna under en katastrof att de flesta eller rentav alla funktioner i dessa komponenter återupprättas från en säker plats.
Processen för haveriberedskap kräver därmed koordination mellan alla procedurer som genomförs för att återställa organisationen till fullständig drift. Dessutom blir den typ av verksamhet som utförs under den här perioden ännu viktigare på grund av själva katastrofens faktum. En händelse som kan få kritisk infrastruktur att krascha har förmodligen skadat andra delar av företaget – lager, transport, tillverkning och leverans. Troligtvis kan den verksamhet som återställs inte vara ett sömlöst återupptagande av den verksamhet som genomfördes före katastrofen.
Det dessa procedurer har gemensamt är förekomsten av tydligt definierade servicenivåmål. DR-tjänster från AWS och Azure samt tjänster från tredje part som bygger på Google Cloud beaktar följande:
Mål för återställningspunkt (RPO) – den minsta tillåtna mängd data som måste levereras tillbaka till klienter för tjänsten baserat på de säkerhetskopierade tillgångar som ska betraktas som återställda. På motsvarande sätt kan denna mängd anses vara den maximala godtagbara dataförlusten uttryckt som en procentandel som subtraheras från 100.
Mål för återställningstid (RTO) – det högsta tidsfönster som tillåts för en återställningsprocess. Detta kan även ses som ett mått på hur mycket avbrottstid organisationen godtar.
Kvarhållningsintervall – den högsta tillåtna tidsperiod då en säkerhetskopieringsuppsättning kan behållas innan den behöver uppdateras och ersättas.
RTO och RPO kan anses vara balanserade mot varandra. En kund kan alltså välja att tillåta längre återställningstider för att få högre återställningspunkter. Om återställningstiden är ett problem för en kund på grund av tillgänglig bandbredd eller risk för avbrottstid kan kunden kanske inte uppnå ett högt RPO.
Professionella riskrådgivare eller affärskontinuitetsrådgivare insisterar troligen att dessa tre variabler används vid skapandet av en policy för haveriberedskap. I de flesta BIA-rapporter (Business Impact Analys, analys av affärspåverkan) har RTO och RPO högsta prioritet. De är kritiska variabler vid rådgivarnas utvärdering av potentiella förluster som uppstår från katastrofer. Vissa rådgivare använder en samlingsvariabel som heter servicenivåmål (SLO, Service-Level Objective), men än så länge används ingen enhetlig formel för att uppnå SLO. Förmågan hos molnlösningsleverantörer att specificera sina servicenivåer enligt terminologi som riskrådgivare redan känner igen och värderar gör det enklare för dessa två parter att samarbeta – ofta väljer organisationer DR-leverantör på denna grundval.
Metoder och procedurer
Föregående lektion omfattade den med grundläggande formen av återställning av informationssystem, däribland säkerhetskopiering av viktiga filer, lagringsvolymer och VM-avbildningar. Detta presenteras alltjämt som ett DR-tjänstalternativ, men i praktiken är det allt färre organisationer som det är aktuellt för, detta främst på grund av att RTO-mål inte kan upprätthållas på en rimlig nivå.
Professionella DR-tjänster erbjuder olika metoder för distribution och hantering, varav vissa inbegriper tjänstunderhåll före en katastrof. Dessa metoder sammanfattas nedan. Alla tre baseras på varianter av de säkerhetskopieringsalternativ som beskrevs i föregående lektion, och de är lika aktuella för alla tjänstleverantörer. Kunder som vill ha ett av dessa återställningslägen väljer replikering, geoplats och lagringsklasser som passar bäst för det läget.
Pilotbelysning
Med den här metoden (bild 5) finns det utrymme för ett fullständigt standby-datacenter. Här upprätthålls vissa centrala tjänster och program samt de data som stöder dem i ett redundanskluster som kan ”köras igång” så fort en katastrofhändelse utlöses, ofta automatiskt. Under tiden distribueras virtuella servrar med endast de grundläggande funktioner som behövs för att de ska hållas aktiva om de behöver utnyttjas. Dessa reservservrar kan utrustas med funktioner för e-post och webben så att kommunikation kan ske både med kunder och inom organisationen. Aktivering av ett återställningsläge med pilotbelysning kan kräva kontinuerlig synkronisering av flyktiga datalager såsom transaktionsdatabaser och e-postvolymer.
Bild 5: De aktiva och passiva komponenterna i ett Pilot Light-återställningsscenario.
Varmt vänteläge
I det här återställningsläget, som visas i bild 6, upprätthålls kontinuerligt körande repliker av alla systemtjänster och -program samt alla kritiska affärsdata på minst en separat geoplats. Åtkomst till den här fullständiga repliken åsidosätts av den aktiva routern tills katastrofhändelsen utlöser en regel som ersätter det aktiva nätverkets adress med adressen för åsidosättningsvägen.
Bild 6: Ett scenario för återställning i vänteläge med vissa komponenter i väntelägesnamnområdet helt i drift.
Hett vänteläge
I det här scenariot (bild 7) körs minst två fullständiga repliker av alla tjänster och program konstant med fullständig och kontinuerlig datasynkronisering mellan dem. En huvudrouter fungerar som en stor lastbalanserare. Den distribuerar begäranden till alla serverplatser med en ungefär jämn fördelning. Förekomsten av en katastrofhändelse utlöser en brandväggsliknande process där adressen för det berörda system tas bort från routningstabellen.
Bild 7: Med frekvent vänteläge är alla komponenter i namnområdet för vad som normalt skulle ha varit reserven, vänteläget, aktiv, fullt fungerande och bearbetning av repliker av primära data i realtid.
Molnautentiska program
Teoretiskt är det möjligt för en organisation att välja en leverantörs haveriberedskapstjänst som ett säkerhetsnät för tjänster som hanteras av en annan leverantör. Med lämplig inblandning av IT-personalen kan en molnlösningsleverantörs infrastruktur (till exempel Googles) alltså fungera som ett redundansmål för en procedur med varmt vänteläge som hanteras i en annan molnlösningsleverantörs infrastruktur (till exempel Azures). Ett sådant upplägg kan vara nödvändigt av redovisningsskäl eller om beräkningsresurser i ett företag hanteras av separata avdelningar i olika delar av världen.
Som det är nu kan förekomsten av containerbaserad infrastruktur i det lokala datacentret samt i molnet ha en betydande inverkan på alla dessa DR-metoder. Ett så kallat molnautentiskt program, som utvecklas exklusivt för användning på en offentlig molnplattform, eller en plattform som fungerar likadant (till exempel Microsoft Azure Stack) distribuerar funktioner i flera replikcontainrar, varav vissa eller alla kan fungera samtidigt. Orsaken är inte etableringen av en ny klass av DR-scenarier, utan fördelning av arbetsbelastningar mellan processorer.
En annan aspekt av molnautentiska arkitekturer är möjligheten för databaser vars innehåll redan replikeras automatiskt att kontaktas via en nätverksadress vars karta gäller exklusivt för det aktuella programmet. (Med andra ord, även om det använder Internetprotokollet, är dess adress inte en plats på det bredare offentliga Internet.) På så sätt, under en katastrofhändelse, medan vissa noder som är kopplade till databasen kan gå ned, kommer många att finnas kvar, och andra kommer att ta platsen för de noder som inte är tillgängliga. Det här räknas kanske ännu inte som inbyggd haveriberedskap, men det kan däremot anses vara haveriresistens.
Haveriberedskap som en tjänst (DRaaS)
För leverantörer av offentliga molntjänster är haveriberedskap ett sätt att utnyttja centrala tjänster för säkerhetskopiering och dataöverföring. Alla stora molnlösningsleverantörer använder olika strategier för att skapa DR ovanför sina säkerhetskopieringstjänster.
AWS CloudEndure
Tjänstmigrering handlar om att flytta virtuella arbetsbelastningar från en privat lokal infrastruktur till en offentlig molninfrastruktur. En sådan flytt är nödvändig för vissa haveriberedskapstjänster som drivs i det offentliga molnet så att de kan uppnå målen med redundansväxling och återställning inom några minuter efter en katastrof.
I januari 2019 förvärvade Amazon den privata tjänstmigreringstjänsten CloudEndure, som redan använde AWS som infrastrukturleverantör. Sedan dess har de integrerat CloudEndure i sitt huvudsakliga tjänstutbud och erbjuder tjänstmigrering till Amazon-kunder utan avgift. Nu implementerar AWS tjänstmigrering som ett sätt att snabbt aktivera en process för varmt eller hett vänteläge. AWS debiterar inte kunder för migreringsprocessen men debiterar för de redundanta resurser som etableras för varje DR-scenario. Trots det gör avsaknaden av extra avgifter att CloudEndure är konkurrenskraftigt jämfört med en mängd andra DR-tjänster från tredje part.
Azure Site Recovery
Microsofts DR-tjänst, Azure Site Recovery, är en hanterad distribution av en återställningsmetod med varmt vänteläge för VM-baserade miljöer samt för fysiska (lokala) servrar som kör Linux eller Windows. Virtuella datorer replikeras aktivt till en sekundär region (bild 9.8), som en redundansväxling kan startas till med en knapptryckning. Kunder debiteras en månatlig avgift (för närvarande cirka 25 USD) för varje server eller virtuell dator som skyddas av Azure Site Recovery.
Bild 8: Redundansscenario implementerat med Azure Site Recovery.
Google Cloud DR
Liksom för säkerhetskopiering erbjuder Google inte någon varumärkestjänst som gäller särskilt för haveriberedskap. I stället gör de nödvändiga verktyg och resurser för datalagring och dataöverföring tillgängliga och erbjuder vägledning för kunder om hur de på bästa sätt kan användas vid olika DR-scenarier.
Eftersom Google erbjuder Coldline-lagringsalternativ och tillämpar en rabatt är GCP tillämpligt på en mängd olika scenarier. Coldline är ett attraktivt val för organisationer som upprätthåller stora mängder bulkdata. Snurrande magnetdiskar är opraktiska för mediafiler med en genomsnittsstorlek på tiotals gigabyte. NAS-komponenter (Network Attached Storage) tillhandahåller en lösning för tillgänglighet och hanterbarhet för organisationer som skapar media, men bara på lokal nivå. De har intern redundans men är inte katastrofresistenta. Och ett DR-scenario som något av dem som beskrevs tidigare skulle inte vara praktiska (eller ens ekonomiskt gångbara) för den här kundkategorin. Med Coldline finns det åtminstone ett genomförbart sätt för sådana kunder att uppnå en viss försäkring om affärskontinuitet.