Back-upservices
Niets boezemt IT-medewerkers meer angst in dan gegevensverlies. De meest efficiënte strategie om gegevensverlies te voorkomen, is het maken van een back-up van de opslagvolumes, virtuele machines, databases en andere systemen die gegevens opslaan, zodat de gegevens kunnen worden hersteld. Cloudserviceproviders bieden precies voor dit doel back-upservices. Over het algemeen kunnen deze services worden gebruikt voor het maken van back-ups van gegevens die on-premises zijn opgeslagen, maar ook van gegevens die zijn opgeslagen in de cloud. Back-ups kunnen verder geografisch worden gerepliceerd en verspreid als bescherming tegen gebeurtenissen die resulteren in verlies van gegevens in een compleet datacentrum of een hele regio van de wereld.
De openbare cloud is een bezorger van veranderlijke resources in grote volumes - niet alleen grote stukken opslag, maar zeer schaalbare opslaggroepen. Ze zijn minstens zo veelzijdig als, en in sommige gevallen zelfs veelzijdiger dan de back-upopslagsystemen en de tapestations die ze vervangen. En ze bieden organisaties nieuwe mogelijkheden om redundantie, failovers en veiligheidsnetten te implementeren die veel zich nooit zouden hebben kunnen veroorloofd in het tijdperk dat alle activa moest worden gekocht met werkkapitaal. Opties voor openbare cloudopslag spelen een rol waaraan datacentra altijd een enorme behoefte hebben gehad, maar die tot voor kort moeilijk te verkrijgen was.
Back-upservices in de cloud
Kenmerkend voor moderne back-upservices die worden aangeboden door openbare cloudserviceproviders (CSP), is de manier waarop ze de infrastructuur van hun klanten uitbreiden. Vóór de introductie van deze services bestond een typische back-upstrategie van een organisatie uit twee lagen: een back-up maken van gegevensvolumes die databases hosten en back-ups maken van installatiekopieën van virtuele machines die kritieke workloads hosten. De theorie achter het maken van back-ups was dat wanneer een systeemprobleem leidde tot een storing, die gebeurtenis ervoor zorgde dat een server uitviel. De handeling die dan onmiddellijk moet worden uitgevoerd, is de status van die server terugzetten vanaf een back-upkopie.
Dankzij cloudinfrastructuur is de oude theorie van het maken van back-ups achterhaald. In moderne systemen bestaan servers uit software, niet uit hardware. Virtuele servers worden ofwel gehost door een op een hypervisor gebaseerde virtuele infrastructuur, zoals NSX van VMware, ofwel geassembleerd vanuit containers en gehost door gevirtualiseerde besturingssystemen. In beide gevallen worden de installatiekopieën van de workloads voor toepassingen en services voortdurend beheerd, bijgewerkt en bewaard. De actieve softwareonderdelen zijn zelf replica's van deze beveiligde masters, of in het geval van containers, de producten van originele masters die zijn opgeslagen in containeropslagplaatsen en automatisch worden geassembleerd als dat nodig is. Een hardwareprobleem waardoor een serverknooppunt wordt uitgeschakeld, zorgt ervoor dat de servers die door dat knooppunt worden gehost niet langer beschikbaar zijn; de infrastructuur leidt het verkeer eenvoudig om het knooppunt heen en doet zijn best om het in de tussentijd te vervangen. De infrastructuurbeheerder doet niets anders dan wat hij altijd al doet wat systeembeheer betreft.
Maar, zoals ook uit een oppervlakkig onderzoek van moderne datacentra blijkt, niet alle moderne infrastructuur is cloudinfrastructuur. Services worden nog steeds gehost op bare metal-computers in on-premises datacentra. Client/server-netwerken, compleet met middleware, zijn er nog steeds in overvloed. En in een hybride systeem waarbij een onderdeel dat een paar jaar geleden is ontworpen, is verbonden met een ander onderdeel dat in de vorige eeuw is ontworpen, blijft het noodzakelijk om voldoende informatie over de gesteldheid van een systeem op te slaan. In noodgevallen kan het systeem dan opnieuw worden samengesteld, op welke praktische maar snelle manier dan ook, in een nieuwe locatie met minimale gevolgen voor serviceniveaus. Met moderne back-upstrategieën kan de openbare cloud die locatie zijn, zelfs als de systemen waarvan momentopnames worden gemaakt, zich buiten de cloud bevinden.
AWS Backup
Aan het begin van 2019 heeft Amazon Web Services zijn cloudback-upservice voor de hybride cloudomgevingen van klanten opnieuw ontworpen. De kern van de nieuwe AWS Backup, waarvan de op de browser gebaseerde console wordt weergegeven in afbeelding 2, is een beleidsengine, wel vergelijkbaar met de arbiter van regels voor een firewall. Met deze engine schrijft de back-upbeheerder regels die het volgende aangeven:
Voor welke resources een systeemback-up vereist is
Hoe elke back-up moet worden uitgevoerd en hoe vaak
Waar de installatiekopieën van back-ups moeten worden opgeslagen
Hoe de integriteit van back-upinstallatiekopieën moet worden bewaakt, inclusief hoe vaak
Hoe lang back-upinstallatiekopieën moeten worden bewaard
Onder welke omstandigheden herstel moet worden uitgevoerd
Het volledige schema dat alle actieve beleidsregels omvat, is het back-upschema. Hier verwijst elke regel naar resources in de AWS-cloud waarvan een back-up moet worden gemaakt op basis van de waarde van het label, een willekeurige naam die door de beheerder is gegeven. Voor het toevoegen van een resource als een EBS-volume (Elastic Block Storage) in een back-upplan, hoeft de beheerder die resource alleen een labelnaam te geven die door AWS Backup wordt herkend. Op deze manier hoeft de beheerder of toezichthouder die verantwoordelijkheid is voor een AWS-resource niet de AWS Backup-console te gebruiken als deze alleen maar een resource wil maken onder toezicht van de toezichthouder als onderdeel van een bestaand back-upschema.
![Figure 2: The AWS Backup console. [Courtesy Amazon]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-2.png)
Afbeelding 2: De AWS Backup-console. [Met dank aan Amazon]
On-premises resources kunnen worden opgenomen in een back-upplan door middel van AWS Storage Gateway. Voor AWS Backup fungeert Storage Gateway als een API-wrapper rond fysieke opslagvolumes en apparaten, zodat deze toegankelijk zijn voor AWS-services.
Oorspronkelijk maakte Storage Gateway vervangingen van bestaande fysieke opslagactiva met cloudgebaseerde tegenhangers die dezelfde interface gebruiken. Een on-site iSCSI-volume kan bijvoorbeeld worden verpakt in wat AWS een volume in cache noemt. Deze wrapper maakt cloudopslag toegankelijk voor bestaande, on-premises toepassingen zonder dat klanten deze toepassingen opnieuw moeten ontwikkelen. Gegevens die vaak worden gebruikt, kunnen nog steeds worden opgeslagen op het iSCSI-volume als een cache, waardoor de hoeveelheid latentie die heeft plaatsgevonden, wordt verminderd. Recente wijzigingen in de inhoud van het gatewayvolume kunnen ook lokaal worden opgeslagen als momentopnamen. Maar Storage Gateway biedt ook ondersteuning voor opgeslagen volumes, waarbij het on-site-apparaat nog steeds een volledig lokale kopie van het volume blijft onderhouden, die Storage Gateway vervolgens spiegelt in de cloud. De nieuwe AWS Backup maakt gebruik van de rolwisseling met fysieke volumes van Storage Gateway, waardoor de lokale kopie de back-up voor het cloudvolume wordt, terwijl een gecentraliseerde beheerconsole wordt toegevoegd met regels die bepalen hoe beide replica's moeten worden bewaard.
Voor noodhersteldoeleinden biedt CSP als groot voordeel de mogelijkheid om snel de essentiële gegevens van een organisatie te archiveren op externe locaties om geografische redundantie of geo-redundantie te bereiken. AWS bedient clouddatacentra in het grootste aantal beschikbaarheidszones voor elke CSP. Het adverteert de systeemeigen mogelijkheid voor de toepassingen die het host om automatisch een failover uit te voeren naar alternatieve zones en breidt deze mogelijkheid uit naar gegevensback-upredundantie. Het is echter bekend dat zich failover-zones kunnen bevinden in dezelfde AWS-regio. In extreme noodgevallen (waar verzekeringsbedrijven, en dus risicomanagers, rekening mee houden), zoals een stroomstoring in het net, kunnen aan elkaar grenzende beschikbaarheidszones te maken krijgen met storingen.
Een softwareontwikkelaar of een IT-operator met ontwikkelaarservaring kan aangepaste beleidsregels schrijven voor de specifieke geo-redundantieroutering van een organisatie met behulp van de low-level routeringsservice van AWS, Route 53. Deze techniek vereist echter veel inspanningen. Onlangs heeft AWS een toegankelijkere service aangeboden met de naam AWS Global Accelerator. Dit is een andere beleidsengine die verkeer begeleidt en Route 53 leidt naar daar waar services en opslag moeten worden gehost.1 Global Accelerator kan ook worden gebruikt als een soort 'über-balancer', waarbij de distributie van meerdere sites wordt ingeschakeld voor gehoste toepassingen (en met hen, kritieke gegevens) tussen versnipperde beschikbaarheidszones.
Een andere manier om ervoor te zorgen dat back-ups van gegevens worden opgeslagen in een ver verwijderde regio, zoals Amazon-technici hebben voorgesteld, is het instellen van een bucket (de algemene back-upcontainer van AWS) als de eerste back-upbestemming. Die bucket kan vervolgens worden gerepliceerd naar een redundante locatie in een toegewezen beschikbaarheidszone. AWS biedt replicatie tussen regio's (CRR; Cross-Region Replication) als een afzonderlijke service.2 AWS stelt de prijs van de back-upservice vast in termen van volume, zowel per opgeslagen gigabyte als per teruggezette gigabyte.
Vanuit een architecturaal oogpunt is AWS Backup ontworpen om te fungeren als een mirror voor AWS-resources. De manier om on-premises activa deel van dit plan te maken, is via een soort dubbele achterdeur, door eerst deze lokale assets te converteren naar externe AWS-volumes (extern vanuit het oogpunt van Amazon) en vervolgens Backup te laten communiceren met de wrapper om die lokale assets.
Azure Backup
Azure Backup kan even goed back-ups maken van on-premises resources (servers en virtuele machines) als van resources die worden gehost in Azure. Het doel is niet om het bestaande back-upbeleid in het datacentrum te wijzigen, alleen om lokale schijven en tapestations te vervangen door cloudopslag. De op cloudlocatie voor het maken van back-ups van bestanden en volumes op Azure wordt de Recovery Services-kluisgenoemd. De browser-gebaseerde console hiervan wordt weergegeven in afbeelding 3. Tijdens het installatieproces voor deze kluis via Azure Portal downloadt en installeert de beheerder de agent aan de clientzijde, ook wel de Microsoft Azure Recovery Services-agent of 'MARS' genoemd. In Windows Server wordt MARS uitgevoerd als een toepassing, net als een System Center-invoegtoepassing. (Een beheerder kan ook liever System Center Data Protection Manager gebruiken, waarbij MARS-functionaliteit al is ingebouwd.) De beheerder zoekt de volumes en services in het netwerk waarvan de gegevens back-up vereisen en MARS distribueert de agents naar de serveradressen die verantwoordelijk zijn voor deze onderdelen.
![Figure 3: The console for Azure Recovery Services Vault. [Courtesy Microsoft]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-3.png)
Afbeelding 3: De console voor Azure Recovery Services Vault. [Met dank aan Microsoft]
Het overdrachtsmodel van Azure Backup is gebaseerd op serviceniveaudoelstellingen voor herstel na noodgevallen. Deze bieden redelijke metrische gegevens aan de hand waarvan kan worden vastgesteld hoe lang een organisatie het kan doen zonder toegang tot de motor van het bedrijf, en wat aanvaardbaar is qua hoeveelheid gegevens die er in een noodgeval kunnen verloren gaan. Deze specifieke doelstellingen (RPO, RTO en retentie) worden behandeld in de volgende les over herstel na noodgevallen.
Het type herstel waarmee Azure Backup zich bezighoudt (in tegenstelling tot Azure Site Recovery, de noodherstelservice van Microsoft) is volledig gericht op gegevensreplicatie in plaats van op serviceherstel. Een klant kan bijvoorbeeld Azure Backup gebruiken om replica's van installatiekopiebestanden van virtuele machines (VHD) te maken. Met het herstellen van een VHD wordt echter gewoon het gearchiveerde installatiekopiebestand in lokale opslag opnieuw gereproduceerd en wordt de virtuele server niet opnieuw opgestart op basis van die VHD.
Azure Backup brengt alleen kosten in rekening voor opslagruimte die per maand wordt verbruikt, zonder extra kosten voor herstelbewerkingen. Het prijsmodel voor opslag hangt samen met de redundantie-opties. Op dit moment biedt Azure twee opties: Lokaal redundante opslag (LRS), de goedkoopste en repliceert gegevens drie keer binnen een Azure-datacenter en Geografisch redundante opslag (GRS), waarmee gegevens geografisch ver van de primaire regio worden gerepliceerd naar een secundaire regio.
Back-ups van Google Cloud Storage
Google biedt verschillende cloudopslaglagen op basis van de klasse van de gegevens die worden opgeslagen, zoals persistent beschikbare bestanden, blokopslag voor installatiekopieën van virtuele machines, objectopslag voor video's. Er worden geen expliciete back-upservices in de handel gebracht voor een van deze lagen, hoewel opslagservices zeker kunnen, en worden, gebruikt voor back-up en herstel. En Google gaat ervan uit dat back-ups een van de belangrijkste redenen zijn waarom een onderneming investeert in cloudopslag voor grote hoeveelheden.
![Figure 4: The contents of a Google Cloud Storage bucket. [Courtesy Google]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-4.jpg)
Afbeelding 4: De inhoud van een Google Cloud Storage-bucket. [Courtesy Google]
Net als bij AWS noemt Google de opslagcontainer voor algemene doeleinden een bucket. In afbeelding 4 ziet u een stap in het proces van het importeren van gegevens vanuit lokale opslag naar een GCS-bucket (Google Cloud Storage). Vergelijkbaar met hoe Azure zijn overdrachtsmodel baseert op drie belangrijke parameters, zijn de belangrijkste parameters van GCS:
Prestatie, wat in deze context synoniem is met beschikbaarheid (hoe snel servers reageren op aanvragen van klanten om gegevens te lezen)
Retentie, waarbij opnieuw wordt verwezen naar de periode dat de klant gegevens in de cloud verwacht op te slaan
Toegangspatronen, wat betrekking heeft op toegankelijkheid (hoe vaak de klant verwacht de opgeslagen gegevens te lezen of in te trekken)
Bij het initialiseren van een bucket kiest de GCS-klant de opslagklasse, die het replicatiebeleid bepaalt. Deze keuze bepaalt, wanneer de bucket eenmaal zal worden gebruikt voor back-ups, hoe versnipperd de opgeslagen gegevens zijn. GCS biedt momenteel drie keuzes met betrekking tot geolocatie:
Regionaal: opgeslagen in slechts één regio van het servicegebied van Google
Dubbel regionaal: gerepliceerd tussen twee geselecteerde serviceregio's
Multiregionaal: op een redundante manier verdeeld over meerdere serviceregio's
Vervolgens verdeelt GCS de bucketopslagklassen onder op basis van hoe vaak ze worden geopend:
Standard/Hoge beschikbaarheid: gegevens die zijn bedoeld om eenvoudig toegankelijk te zijn voor toepassingen en voor gebruikers
Coldline: hiermee kan de klant een deel van de maandelijkse opslagkosten ruilen voor toegang en overdrachtskosten, voor gegevens die bedoeld zijn om niet vaker dan een paar keer per jaar te worden gebruikt
Nearline: meer een gemiddelde, voor gegevens die volgens planning ongeveer eenmaal per maand zullen worden benaderd
Google's manier om zijn cloudinfrastructuur te vermarkten aan bedrijven is door de services te presenteren als een soort apparaat dat niet te zien is. In dat opzicht doet Google misschien wel dubbel werk door zowel het apparaat als hoe het wordt gebruikt aan te bieden als afzonderlijke services, vergelijkbaar met het verkopen van een oven en vervolgens een abonnement op eten koken als toegevoegde waarde.
Op deze manier selecteert de GCS-klantorganisatie de infrastructuur die nodig is voor de taken die deze organisatie in gedachten heeft, en past de instellingen voor die infrastructuur aan als de functies van een apparaat. (Net als AWS en Azure biedt Google een rekmontageapparaat voor datacenters voor het snelle doel van snelle overdracht tussen lokale en cloudopslag.) Deze functies kunnen na verloop van tijd worden aangepast, afhankelijk van hoe het gebruik van die opslag verandert. Stel bijvoorbeeld dat een videoproductiebedrijf grote hoeveelheden back-upopslag nodig heeft voor versies van een film die wordt bewerkt. Tijdens het bewerkingsproces kunnen deze kopieën tamelijk vaak worden opgehaald, zodat de klant de bucket kan instellen op Standard-opslag in regionaal gebied. Zodra de video is voltooid en openbaar is gedistribueerd, is het mogelijk nog steeds nodig om kopieën bij de hand te houden voor het volgende jaar, hoewel deze wellicht niet vaak worden benaderd. In dat geval kan de Standard-bucket worden overgebracht naar een Coldline-bucket, met Dual Regional-gebied voor archiverings- en veiligheidsdoeleinden.
Verwijzingen
Amazon Web Services, Inc. Verkeersbeheer met AWS Global Acceleratorhttps://aws.amazon.com/blogs/networking-and-content-delivery/traffic-management-with-aws-global-accelerator/.
Amazon Web Services, Inc. Overzicht van het instellen van replicatiehttps://docs.aws.amazon.com/AmazonS3/latest/dev/replication-how-setup.html.