Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Backup en recovery kan bijkantoor verbeteren

 

Computable Expert

Will Moonen
Managing consultant, IT visibility. Expert van Computable voor de topics Management, Outsourcing en Cloud Computing.

Voor een centraal datacenter is backup en recovery doorgaans goed geregeld! Maar hoe zit het met de bijkantoren? Is het daar ook zo goed geregeld? En voor zover dat niet het geval is, wat is daar aan te doen? In dit artikel een aanpak die misschien niet het meest voor de hand liggend is, maar in de praktijk wel zeer effectief blijkt te zijn!

Veel bedrijven hebben in hun kleinere bijkantoren de nodige servers opgesteld waarbij de backup veelal geregeld is via tapes of dvd's. Een medewerker van dat bijkantoor wisselt elke dag de tape of dvd.

In een groter bijkantoor wordt er vaak gebruik gemaakt van een klein san en data replicatie. Het streven hier is om minimaal één keer per 24 uur alle gewijzigde data gekopieerd te krijgen naar het centrale datacenter.

De grens tussen een kleiner en een groter bijkantoor ligt bij ongeveer honderd medewerkers, drie à vier fysieke servers en een twintig tot 25 vm’s.

Tot zover lijkt er niet zoveel aan de hand. Immers, een stuk hardware wat de geest geeft of - erger nog - gestolen wordt, is binnen een paar uur wel weer aan de praat te krijgen.
Maar dan begint het eigenlijk pas:

  • Wat zijn ook alweer de stappen bij het terugzetten van het besturingssysteem (os), de applicatie(s) en de data?
  • Waar is die usb-stick of de dvd met de laatste versie van het server image?
  • Hoe zit het met de laatste versie van de backup? Is die betrouwbaar en waar ligt de tape?
  • Zijn die twee ook bruikbaar in combinatie met die nieuwe raid-controller?
  • Voor de grotere bijkantoren: hoe lang duurt het voordat alle data overgezet is vanuit een van beide data centers? Wat was ook alweer de procedure om dat voor elkaar te krijgen?

Immers, pas als de applicaties volledig in bedrijf zijn kunnen de mensen op het bijkantoor weer aan de slag. Er mag dan ook nauwelijks enige twijfel bestaan over de betrouwbaarheid en snelheid van een recovery procedure!

De twee kpi’s die hier maatgevend zijn, zijn RTO (Recovery Time Objective) en RPO (Recovery Point Objective). De eerste kpi, de RTO, gaat over de maximale recovery tijd: de maximale tijd om de uitgevallen delen zodanig te herstellen dat de normale bedrijfsvoering hervat kan worden. De tweede kpi, de RPO, gaat over data verlies: de maximale, toegestane tijd tussen de laatste, goed werkende backup en het moment van uitval.

Hoe het ook kan

De kern achter het verbeteren van de RTO is het terugdringen van de recovery tijd rondom het os, de applicatie en de data.

Bij het verbeteren van de RPO is de situatie iets anders. Daar is het zaak op zoek te gaan naar iets waardoor er per dag meerdere keren een backup of een replicatie gemaakt kan worden. Hoe hoger de backup en replicatie frequentie, hoe beter de RPO.

De essentie van de beoogde oplossing is een techniek die, zeker bij internationaal opererende bedrijven, bekend staat als wan-acceleratie. Met deze techniek worden de prestaties en beschikbaarheid van applicaties merkbaar beter en consistenter. In dat kader werkt backup-en-recovery niet anders dan een gewone applicatie.

Uiteraard zullen de resultaten van geval tot geval enigszins variëren. Maar in de praktijk blijkt dat zelfs als er gebruik gemaakt wordt van de-duplicatie op, bijvoorbeeld, een filestore van EMC of NetApp, dan nog is er met de inzet van wan-acceleratie een winst te boeken die ligt tussen de 70 en 80 procent. Dat wil zeggen dat de duur van een data replicatie nog maar 20 tot 30 procent bedraagt in vergelijking met een situatie zonder wan-acceleratie. Daardoor kan er per dag meerdere keren een backup of replicatie lopen met als gevolg een sterk verbeterde RPO!

Bij het terugzetten van de data mag je vergelijkbare prestatie verbeteringen verwachten. Doordat de recovery actie nu nog maar een 30 procent bedraagt van wat het was, wordt ook de RTO aanzienlijk verbeterd!

Voor de kleinere bijkantoren gaat het nog verder met de inzet van een zogenaamd stateless replicatie mechanisme. Dat is een mechanisme wat het best valt te omschrijven als het maken van snapshots op basis van de data die op enig moment daadwerkelijk gebruikt wordt. Wijzigingen in deze snapshots worden binnen een bepaalde, gegarandeerde tijd weggeschreven naar de centrale storage omgeving in het datacenter. Deze tijd ligt in ordegrootte van secondes waardoor de RPO beweegt richting die van twin datacenters!

De RTO voor het server- en applicatie deel van de recovery procedure is in dit geval beter dan die van de grotere bijkantoren, doordat het stateless replicatie mechanisme ook gebruikt wordt bij het ophalen en starten van het os en de applicaties. Hierdoor hoeven gebruikers niet te wachten tot alle data teruggezet is; ze kunnen weer aan de slag zo gauw het os en de applicaties gestart zijn.

De techniek

De technologie achter wan-acceleratie is gebaseerd op data- en transport streamlining. Dat regelt de data reductie door caching en compressie. Caching wordt gebruikt om alleen nieuwe data de lijn op te sturen. Voor bestaande data wordt er gebruik gemaakt van verwijzingen naar data die op een eerder moment naar disk of geheugen is weggeschreven. Datgene wat uiteindelijk de lijn op gaat wordt overigens eerst gecomprimeerd met een LZH-algoritme.

Transport streamlining regelt de QoS en het verbeteren van de TCP-window size waardoor de nadelige effecten van netwerk latency tot een minimum beperkt blijven. Hierdoor worden onder andere het aantal “'application turns' sterk verminderd. De term 'application turns' heeft betrekking op het aantal slagen tussen een cliënt en een server wat nodig is om een bepaalde hoeveelheid data verwerkt te krijgen; hoe lager, hoe beter.

Voor de invulling wordt er gebruik gemaakt van tenminste één accelerator in het datacenter en een voor elk bijkantoor. In het kader van het verbeteren van de RTO en RPO blijft het hierbij voor de grotere bijkantoren.

Voor de kleinere bijkantoren wordt dit aangevuld met minimaal één storage gateway in het datacenter. In dat geval wordt er in de bijkantoren een wan-accelerator ingezet met een ingebouwde ESX-laag. Met deze combinatie worden vanuit het san een of meer LUN’s geprojecteerd naar elk van de bijkantoren, waardoor een ieder beschikt over zijn eigen stukje san uit het data-center.

Vervolgens worden er vanaf dat san een of meer vm’s overgehaald en opgestart. In een dergelijk scenario kunnen de gebruikers weer aan het werk zodra de vm’s gestart zijn; wachten op het terugzetten of repliceren van de data is in dit geval niet nodig. Het pre-fetch algoritme in de storage gateway en de wan-acceleratie zijn samen zo efficiënt en effectief dat de gebruikers slechts een minimale vertraging zullen ervaren bij een eerste start van de applicatie en de uitvoering van een eerste transactie.

Ondanks dat de ESX-laag geïntegreerd is in de wan-accelerator op de bijkantoren blijft het mogelijk deze ESX-laag en bijbehorende vm’s volledig in beheer te nemen vanuit de centraal ingeregelde vSphere, vCenter en wat dies meer zij.

De business case

De business case van een verbeterde RTO en RPO

Als je deze twee eerder genoemde kpi's, de RTO en RPO, uitzet tegen kosten, dan blijkt in de praktijk dat het gebruik van twin datacenters de duurste oplossing is met de beste resultaten. Door de hoge mate van redundantie en automatische failover zijn beide kpi’s (bijna) nul.

Voor de meeste bijkantoren geldt het omgekeerde. In vergelijking met twin datacenters zijn de infrastructurele kosten niet echt hoog. Daar staat tegenover dat de RTO en RPO eerder dagen dan uren zijn, waardoor de productie verliezenexponentieel oplopen.

In nevenstaande afbeelding is dit grafisch weergegeven uitgaande van een groter bijkantoor. De groene lijnen representeren de kosten voor een bepaald niveau van RTO en RPO. De rode lijnen representeren de productieverliezen. Hier valt dus duidelijk wat te verbeteren!

Zoals te zien in deze afbeelding is de business case erop gebaseerd dat je met een minimum aan kosten de RTO en RPO zodanig verbeterd dat dit ruimschoots opweegt tegen de kosten van productieverlies bij een server uitval.

Voor de kleinere bijkantoren is de business case iets anders (en beter!) door het eerder beschreven stateless replicatie mechanisme. Lokale backup’s zijn nu niet meer nodig waardoor de kosten voor backup licenties en de uren rondom het beheer van tapes, dvd’s en usb-drives komen te vervallen.

In het verlengde daarvan zijn er nu ook mogelijkheden om de gevolgschade door bedieningsfouten van gebruikers te beperken. Bijvoorbeeld door een eerdere versie van een adviesrapport terug te zetten, wat door de betreffende adviseur per ongeluk gewist was. Iets wat zeker voor een kleiner bijkantoor niet altijd vanzelfsprekend is (geweest!).

Bijkomend voordeel van een dergelijke aanpak is de verbeterde beveiliging van de data. Door de manier van data opslag is de content van een snapshot niet te herleiden naar de bron data. Met andere woorden, zelfs al zou de accelerator gestolen worden en al zou iemand in staat zijn om de content van een snapshot te bestuderen, dan nog is niet te bepalen wat de gevonden content voorstelt.

Dit artikel is afkomstig van Channelweb.nl (https://www.channelweb.nl/artikel/5263439). © Jaarbeurs IT Media.

5,3

 
Nieuwsbrief

Wil je dagelijks op de hoogte gehouden worden van het laatste resellernieuws, trends en ontwikkelingen? Abonneer je dan op onze gratis nieuwsbrief.

Vul een geldig e-mailadres in

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×


Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.