Säkerhetskopieringstjänster
Det finns inget som oroar IT-personal mer än dataförlust. Den effektivaste strategin för att förhindra dataförlust är att säkerhetskopiera de lagringsvolymer, virtuella datorer, databaser och andra system som lagrar data så att dessa data kan återställas. Molntjänstleverantörer erbjuder säkerhetskopieringstjänster som åstadkommer detta. Generellt kan dessa tjänster användas för att säkerhetskopiera data som lagras lokalt samt data som lagras i molnet, och säkerhetskopieringar kan replikeras och spridas geografiskt för att skydda mot händelser som leder till dataförlust i ett helt datalager eller en hel region.
Det offentliga molnet levererar stora volymer med flexibla resurser – inte bara stora datasegment, utan även lagringspooler med hög skalbarhet. De är minst lika mångsidiga som, och i vissa fall ännu mer än de system för säkerhetskopiering och bandenheter som de ersätter. Dessutom ger de organisationer nya möjligheter att implementera redundans, redundansväxlingar och säkerhetsnät som många annars inte hade haft råd med på den tid då alla tillgångar köptes via arbetande kapital. Alternativ för lagring i offentligt moln fyller en roll som datacenter alltid har haft stort behov av men som fram till nyligen var svår att genomföra.
Molnbaserade säkerhetskopieringstjänster
Det som kännetecknar moderna säkerhetskopieringstjänster som erbjuds av leverantörer av offentliga molntjänster (CSP) är deras sätt att utöka kundernas infrastruktur. Innan dessa tjänster lanserades fanns det vanligtvis två nivåer i organisationers säkerhetskopieringsstrategi: säkerhetskopiering av datavolymer som var värd för databaser samt säkerhetskopiering av VM-avbildningar som var värd för kritiska arbetsbelastningar. Teorin bakom säkerhetskopiering var att systemfel som leder till haveri gör att en server går offline. Den omedelbara åtgärden blir då att återställa serverns tillstånd från en säkerhetskopierad avbildning.
Molnbaserade infrastrukturer gör den gamla teorin bakom säkerhetskopiering föråldrad. I moderna system består servrar av programvara, inte maskinvara. Virtuella servrar hanteras antingen av hypervisor-baserad virtuell infrastruktur, till exempel VMware NSX, eller framställs från containrar som hanteras av virtualiserade operativsystem. I båda dessa fall hanteras, uppdateras och skyddas programvaruavbildningarna av arbetsbelastning för program och tjänster kontinuerligt. De aktiva programvarukomponenterna är i sig repliker av dessa säkra huvudkopior. För containerisering lagras produkterna av originalkopiorna alternativt på containerlagringsplatser och monteras automatiskt efter behov. Om ett maskinvarufel gör att en servernod går offline blir de servrar som hanteras av den noden otillgängliga under en viss tid. Då omdirigerar infrastrukturen helt enkelt trafik runt noden och ersätter den efter bästa förmåga under tiden. Infrastrukturhanteraren gör ingenting som den inte redan gjorde vid normal systemadministration.
Om vi tittar på moderna datacenter framgår det dock snabbt att inte all modern infrastruktur är molnbaserad. Tjänster hanteras fortfarande utan operativsystem i lokala datacenter. Klient/server-nätverk med mellanprogram är fortfarande vanliga. Och i hybridsystem där en del som utformades för några år sedan är ansluten till en annan del som skapades under förra århundradet är det nödvändigt att lagra tillräckligt med information om beståndsdelarna i ett system för att kunna återskapa systemet i händelse av katastrof. Detta får då göras skyndsamt på en ny plats med minimal inverkan på servicenivåerna. Med moderna säkerhetskopieringsstrategier kan det offentliga molnet vara en sådan plats, även om de system som görs till ögonblicksbilder finns utanför molnet.
AWS Backup
I början av 2019 omdesignade Amazon Web Services sin molnbaserade säkerhetskopieringstjänst för kundernas hybridmolnmiljöer. I hjärtat av det nya AWS Backup, vars webbläsarbaserade konsol visas i bild 2, finns en principmotor som liknar en brandväggs regelutvärderare. Med den här motorn skriver säkerhetskopieringsadministratören regler som anger följande:
Vilka resurser i ett system som kräver säkerhetskopiering
Hur varje säkerhetskopiering ska utföras samt hur ofta
Var avbildningarna av säkerhetskopiorna ska lagras
Hur avbildningarna av säkerhetskopiorna ska övervakas och hur ofta
Hur länge avbildningar av säkerhetskopior ska behållas
Under vilka förhållanden återhämtning och återställning ska utföras
Den fullständiga planeringen med alla aktiva principer är säkerhetskopieringsplanen. Här hänvisar varje regel till resurser i AWS-molnet som kräver säkerhetskopiering baserat på deras taggar, som är godtyckliga namn som administratören väljer. Om en administratör vill inkludera en resurs såsom en EBS-volym (Elastic Block Storage) i en säkerhetskopieringsplan behöver denne endast ge resursen ett taggnamn som AWS Backup känner igen. På så sätt behöver inte administratören eller den som ansvarar för en AWS-resurs använda AWS Backup-konsolen bara för att etablera en resurs som den ansvariga sköter som en del av en befintlig säkerhetskopieringsplan.
![Figure 2: The AWS Backup console. [Courtesy Amazon]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-2.png)
Bild 2: AWS Backup-konsolen. [Courtesy Amazon]
Lokala resurser kan införlivas i en säkerhetskopieringsplan via AWS Storage Gateway. Vad gäller AWS Backup fungerar Storage Gateway som en API-adapter runt fysiska lagringsvolymer och enheter, vilket gör dem tillgängliga för AWS-tjänster.
Ursprungligen möjliggjorde Storage Gateway ersättningar av befintliga tillgångar i fysisk lagring med molnbaserade motsvarigheter med hjälp av samma gränssnitt. Till exempel kunde en lokal iSCSI-volym omslutas i det som AWS kallar en cachelagrad volym. Adaptern gör molnlagring tillgänglig för befintliga lokala program utan att kunderna behöver anpassa dessa program. Data som används ofta lagras fortfarande på iSCSI-volymen som cachelagring, vilket minskar svarstiden. Det går även att lagra nya ändringar av gatewayvolymens innehåll lokalt som ögonblicksbilder. Storage Gateway stöder dock även lagrade volymer. De gör att den lokala enheten fortsätter underhålla en fullständig lokal kopia av volymen som Storage Gateway sedan speglar i molnet. Nya AWS Backup använder rollbyten i Storage Gateway med fysiska volymer, vilket gör den lokala kopian till säkerhetskopia för den molnbaserade volymen. Samtidigt läggs en centraliserad principhanteringskonsol till med regler som styr hur båda replikerna ska underhållas.
Vid återställning efter haveri finns det en stor fördel med en molnlösningsleverantör: möjligheten att snabbt arkivera en organisations kritiska data på avlägsna platser så att geografisk redundans, eller georedundans, uppnås. AWS driver molndatacenter i störst antal tillgänglighetszoner av alla molnlösningsleverantörer. Det marknadsför den inbyggda möjligheten för program som det är värd för att automatiskt redundansväxla till alternativa zoner och utökar denna funktion till redundans med datasäkerhetskopiering. Dock har zoner för redundansväxling konstaterats finnas i samma AWS-region. I en extrem katastrofsituation (som försäkringsbolag och därmed även riskhanterare inte räknar med), till exempel ett haveri i elnätet, skulle tillgänglighetszoner som ligger intill varandra kunna drabbas av avbrott.
Programvaruutvecklare eller IT-operatörer med erfarenhet inom utveckling kan skriva anpassade principer för en organisations specifika georedundansdirigering med hjälp av Route 53, en dirigeringstjänst på låg nivå från AWS. Den här tekniken kräver dock mycket arbete. Nyligen har AWS erbjudit en mer praktisk tjänst som heter AWS Global Accelerator. Det är en annan principmotor som vägleder trafik och dirigerar Route 53 dit tjänster och lagring ska hanteras.1 Global Accelerator kan även användas som en ”über-balanserare” för att distribuera flera webbplatser för hanterade program (samt kritiska data) mellan spridda tillgänglighetszoner.
Amazon-tekniker har även föreslagit ett annat sätt att se till att säkerhetskopierade data lagras i en rimligt avlägsen region. Det går ut på att en bucket (den allmänna säkerhetskopieringscontainern i AWS) etableras som den första säkerhetskopieringsdestinationen och sedan replikeras till en redundant plats i valfri tillgänglighetszon. AWS erbjuder Cross-Region Replication (CRR) som en separat tjänst.2 AWS prissätter sin säkerhetskopieringstjänst enligt volym, både per lagrad gigabyte och per återställd gigabyte.
Vad gäller arkitekturen är AWS Backup utformat för att spegla AWS-resurser. Lokala tillgångar införlivas i den planen genom en sorts dubbel bakdörr. Först konverteras de lokala tillgångarna till AWS-fjärrvolymer (det vill säga fjärrbaserade från Amazons perspektiv), och sedan interagerar Backup med adaptern runt dessa lokala tillgångar.
Azure Backup
Azure Backup kan säkerhetskopiera både lokala resurser (servrar och virtuella datorer) och resurser som hanteras i Azure. Syftet är inte att ändra den befintliga säkerhetskopieringspolicyn i datacentret, utan bara att ersätta lokala diskar och bandenheter med molnlagring. Den molnbaserade platsen för säkerhetskopierade filer och volymer i Azure kallas Recovery Services-valv, vars webbläsarbaserade konsol visas i bild 3. Under konfigurationsprocessen för det här valvet via Azure-portalen laddar administratören ned och installerar agenten på klientsidan som kallas Microsoft Azure Recovery Services-agenten eller "MARS". I Windows Server körs MARS som ett program och ser ut ungefär som ett System Center-tillägg. (Alternativt kan en administratör föredra att använda System Center Data Protection Manager, där MARS-funktioner redan är inbyggda.) Administratören letar upp volymer och tjänster i nätverket vars data kräver säkerhetskopiering och MARS distribuerar sina agenter till de serveradresser som ansvarar för dessa komponenter.
![Figure 3: The console for Azure Recovery Services Vault. [Courtesy Microsoft]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-3.png)
Bild 3: Konsolen för Azure Recovery Services Vault. [Courtesy Microsoft]
Leveransmodellen i Azure Backup bygger på servicenivåmål för haveriberedskap. Dessa ger rimliga mått på hur länge en organisation klarar av att inte ha åtkomst till verksamhetens kärna samt hur mycket data den har råd att förlora i fall av katastrof. De här specifika målen (RPO, RTO och kvarhållning) beskrivs i nästa lektion om haveriberedskap.
Den typ av återställning som används i Azure Backup (till skillnad från Azure Site Recovery, Microsofts tjänst för haveriberedskap) handlar uteslutande om datareplikering snarare än tjänståterställning. Till exempel kan en kund använda Azure Backup för att skapa repliker av VM-avbildningsfiler (VHD). Återställning av en VHD reproducerar dock bara den arkiverade avbildningsfilen i lokal lagring på nytt, och startar inte om den virtuella servern baserat på en sådan VHD.
Azure Backup debiterar endast för lagringsutrymme som förbrukas per månad. Det tillkommer inte några avgifter för återställningar. Prissättningsmodellen för lagring är kopplad till redundansalternativen. För närvarande erbjuder Azure två sådana alternativ: Lokalt redundant lagring (LRS), som är den billigaste och replikerar data tre gånger i ett Azure-datacenter, och Geo-Redundant Storage (GRS) som replikerar data till en sekundär region som är geografiskt avlägsen från den primära regionen.
Google Cloud Storage-säkerhetskopiering
Google erbjuder olika Cloud Storage-nivåer baserat på den klass av data som lagras – till exempel filer med beständig tillgänglighet, blocklagring för VM-avbildningar och objektlagring för videor. Det marknadsför inte uttryckligen någon varumärkestjänst för säkerhetskopiering för dessa nivåer, men det går att använda lagringstjänster för säkerhetskopiering och återställning. Google förutsätter även att säkerhetskopior är ett av de främsta skälen till att företag investerar i molnlagring med höga volymer.
![Figure 4: The contents of a Google Cloud Storage bucket. [Courtesy Google]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-4.jpg)
Bild 4: Innehållet i en Google Cloud Storage-bucket. [Courtesy Google]
Liksom AWS kallar Google sin allmänna lagringscontainer för en bucket. Bild 4 visar ett steg i processen för att importera data från lokal lagring till en GCS-bucket (Google Cloud Storage). I Azure baseras leveransmodellen på tre nyckelparametrar, och nyckelparametrarna för GCS liknar dessa:
Prestanda, vilket i det här sammanhanget är synonymt med tillgänglighet (hur snabbt servrar svara på kunders begäranden om dataläsningar)
Kvarhållning, som återigen handlar om hur länge kunden förväntas kvarhålla data som lagras i molnet
Åtkomstmönster, som har med tillgänglighet att göra (hur ofta kunden förväntas läsa eller återkalla lagrade data)
När en bucket initieras väljer GCS-kunden en lagringsklass, som anger replikeringsprincipen. När bucketen börjar användas för säkerhetskopieringar avgör detta val hur mycket lagrade data sprids. För närvarande erbjuder GCS tre val av geoplats:
Regional – lagras i endast en vald region i Googles tjänstterritorium
Dual-regional (Två regioner) – replikeras till två valda tjänstterritorier
Multi-regional (Flera regioner) – distribueras redundant till flera tjänstterritorier
Sedan delar GCS in sina bucket-lagringsklasser baserat på hur ofta de kommer att användas:
Standard/High Availability (Standard/hög tillgänglighet) – data som ska vara lättåtkomliga för program och användare
Coldline – gör att kunden kan byt ut en del av månadsavgiften för lagring mot åtkomst- och överföringsavgifter för data som ska användas högst några gånger per år
Nearline – ett balanserat utbyte för data som ska kommas åt ungefär en gång i månaden
Googles marknadsföring av sin infrastruktur till företag handlar om att presentera tjänsterna som en sorts apparat som du inte ser. Det kan innebära dubbelt arbete att Google erbjuder både vad apparaten är samt hur den används som separata tjänster. Det kan liknas vid att sälja en ugn och sedan sälja en prenumeration på matlagning som en tilläggstjänst.
På det här sättet väljer GCS-kundorganisationen den infrastruktur som behövs för planerade jobb och anpassar inställningarna för den infrastrukturen likt funktioner på en apparat. (Precis som AWS och Azure erbjuder Google en rackmonteringsinstallation för datacenter i expresssyfte med höghastighetsöverföring mellan lokal lagring och molnlagring.) Dessa funktioner kan sedan justeras över tid beroende på hur användningen av lagringen ändras. Antal till exempel att ett videoproduktionsbolag behöver stora mängder säkerhetskopieringslagring för versioner av en film som redigeras. Under redigeringsprocessen kan sådana kopior hämtas ganska ofta, och kunden kan därför ställa in bucketen på Standard-lagring i Regional-territorium. När videon är klar och har distribuerats offentligt kan det fortfarande vara nödvändigt att ha kopior till hands inför nästa år, även om de inte används ofta. I det fallet kan Standard-bucketen överföras till en Coldline-bucket med Dual-Regional-territorium för arkivering och säkerhet.
Referenser
Amazon Web Services, Inc. Trafikhantering med AWS Global Acceleratorhttps://aws.amazon.com/blogs/networking-and-content-delivery/traffic-management-with-aws-global-accelerator/.
Amazon Web Services, Inc. Översikt över konfiguration av replikeringhttps://docs.aws.amazon.com/AmazonS3/latest/dev/replication-how-setup.html.