Met virtualisatie beschikbaarheid & herstel verbeteren

Je hebt er vast wel eens van gehoord: virtualisatie. Iedereen is er mee bezig met allemaal moeilijke termen, maar het wordt niet altijd even duidelijk wat je er precies mee kunt. Toch heeft het voor de ondersteuning van je bedrijfsprocessen veel meerwaarde. Het gebruik van virtualisatie is niet alleen interessant voor grote datacenters die virtualisatie op massale schaal toepassen. In datacenters is er eigenlijk maar weinig wat niet gevirtualiseerd is. In datacenters doet men dit om hardware efficiënter in te zetten en een hogere beschikbaarheid te realiseren. Ook voor jouw bedrijf is er meerwaarde te halen. Gelukkig is het verrassend eenvoudig om met virtualisatie te starten.

Wat is virtualisatie

Om beter uit te leggen wat virtualisatie is moeten we eerst kort de traditionele vorm aanstippen. Voor virtualisatie hadden we namelijk ook gewoon servers en applicaties. Tegenwoordig wordt er ook gebruik gemaakt van virtuele opslagcapaciteit en netwerkcomponenten. Hier zal ik op dit moment niet op in gaan.

Traditionele vorm

Ik noem dit even de traditionele vorm omdat er allemaal moeilijke termen voor zijn die eigenlijk alleen technische nut hebben. In de traditionele vorm heb je een stuk hardware (server) met daarop een besturingssysteem (Windows, Unix e.d.) en op dat besturingssysteem wordt dan een applicatie geïnstalleerd. Daarnaast wordt er aansturing (drivers) voor die specifieke hardware ingeladen. Waardoor de software de hardware kan benutten.

In de afbeelding hiernaast wordt duidelijk hoe in een traditionele architectuur de lagen zijn opgebouwd. Deze zijn allemaal met elkaar geïntegreerd.

Er is een hardware laag, een laag met het besturingssysteem waarin ook de aansturing van de hardware zit en een applicatie laag. Elke laag is afhankelijk van de onderliggende. Het besturingssysteem wordt geïnstalleerd op de hardware en de applicatie wordt geïnstalleerd op het besturingssysteem.

Dit vormt een probleem bij onderhoud of uitbreiding van de hardware. De hardware moet uit en ook de daarboven liggende lagen. Hierdoor is de applicatie dus tijdelijk niet beschikbaar. Dit kan natuurlijk buiten kantoortijden gepland worden. Dus geen probleem tenzij je de applicatie 24*7 nodig hebt. Echter bij een defect aan de hardware treed er een groter probleem op. Omdat de bovenliggende lagen afhankelijk zijn van dat specifieke stuk hardware moet deze weer gerepareerd worden. Mocht dit niet lukken dan zijn er gelukkig een aantal back-up applicaties die instaat zijn om alles op andere hardware te herstellen. Helaas kost dit erg veel tijd. Daarnaast hadden we net gezegd dat de aansturing van de hardware in het besturingssysteem verweven zat. Dus dat moet vervangen worden door andere aansturing. Al met al een omvangrijke klus en wanneer is dit voor het laatst getest. Kan jouw back-up applicatie dit?

Virtualiseren

Dan komen we bij het stuk waar het echt om gaat, virtualiseren. Het woord zegt het al een beetje; je maakt iets virtueel; niet meer tastbaar. In de vorige stuk heb ik laten zijn dat de architectuur uit lagen bestaat.

Wat virtualisatie doet is daar een laag aan toevoegen. Tussen de hardware en het besturingssysteem komt er een laag bij. De virtualisatie laag. Aan de onderkant neemt deze laag de taken van het besturingssysteem over als het gaat om de aansturing van de hardware. Aan de bovenkant bied de virtualisatie laag virtuele hardware aan, aan de bovenliggende besturingssysteem laag.

Virtuele hardware is softwarematige hardware. Dus software die zich gedraagt als hardware zodat het bovenliggende besturingssysteem niet in de gaten heeft dat het voor de gek wordt gehouden.

Er zijn verschillende soorten virtualisatie lagen. Voor nu houd ik het even bij deze soort om het niet te complex te maken.

Het besturingssysteem en en de applicatie zijn nu gescheiden van de fysieke hardware en hierdoor ook niet meer afhankelijk van dat specifieke stuk hardware. De combinatie van een besturingssysteem, applicatie en virtuele hardware noemen we een VM. VM staat voor Virtuele Machine.

We zijn ook niet meer, door architectuur, beperkt in het aantal besturingssystemen en applicaties wat we op één stuk fysieke hardware laten draaien. De virtualisatie laag stelt ons instaat meerdere VM’s op één fysiek stuk hardware te zetten. Hierdoor kunnen we de fysieke hardware efficiënter benutten. Waar we bij een traditionele architectuur voor elke applicatie nieuwe hardware nodig hadden. Kunnen we nu elke applicatie in een aparte VM zetten.

We zijn nu instaat de hardware efficiënter te gebruiken en kunnen we het aantal fysieke stukken hardware terugdringen. Uit onderzoeken uitgevoerd door Vmware blijkt dat in de traditionele architectuur de hardware maar voor 5 – 15 % gebruikt wordt. Door het gebruik van virtualisatie kunnen we dit verhogen tot 60 – 80 %.

Nu weten we wat virtualisatie is, maar zolang we maar één stuk hardware hebben zal deze uit moeten bij onderhoud of bij een defect. Gelukkig kan elke VM op een gelijke virtualisatie laag gestart worden. Dus heb ik een ander stuk hardware waar ook die virtualisatie laag op zit. Dan kan ik daar mijn VM’s opstarten. Natuurlijk moet mijn VM wel beschikbaar zijn op die andere hardware anders kan deze niet gestart worden. Bij gepland onderhoud is dit simpelweg een onderdeel van het stappenplan. Bij een defect kan de VM in z’n geheel hersteld worden en gestart worden. Mits juist geback-upped natuurlijk.

Beschikbaarheid verhogen

In de titel van mijn artikel schrijf ik over een verhoogde beschikbaarheid. In mijn uitleg over virtualisatie zien we dat één en ander eenvoudiger wordt als het gaat om onderhoud en defecten. Het betekend echter nog steeds grote gaten in de beschikbaarheid alleen minder groot.

Eigenlijk wil je dat applicaties gewoon beschikbaar zijn en dat onderhoud en reparatie van defecten tijdens kantoortijden uitgevoerd kunnen worden. Want buiten kantoortijden betaal je al snel 150 – 200 % voor een techneut die het werk uit moet voeren.

Een kleine rekensom laat zien dat voor 12 uren onderhoud per jaar een licentie voor bijvoorbeeld Vmware Essentials al uit kan:

In mijn uitleg over virtualisatie gaf ik al aan dat de VM niet meer afhankelijk is van de fysieke hardware en dus op elke andere fysieke hardware met dezelfde virtualisatie laag kan draaien. Dat betekend eigenlijk dat VM’s gewoon verplaatst kunnen worden. Als dan alle VM’s verplaatst zijn dan is er niets meer afhankelijk van het fysieke stuk hardware en kan het dus uit. Zo kan er gewerkt worden aan deze hardware. Zonder dat gebruikers het zonder hun applicaties moeten stellen.

Bovenstaande werkt natuurlijk heel mooi in het geval van onderhoud. Gepland of ongepland maakt dan niet zoveel meer uit. Echter bij een kritisch defect is er nog wel een uitdaging. Bij een kritisch  defect is namelijk de VM nog niet verplaatst naar de andere hardware en mogelijk niet meer beschikbaar. Dat betekend dan alsnog wachten of herstellen vanaf back-up. Dat laatste is in een gevirtualiseerde infrastructuur wel veel makkelijker maar betekend nog steeds een gat in de beschikbaarheid.

Nee, in het geval van een kritisch defect moeten VM’s automatisch geëvacueerd worden.

Het evacueren van VM’s komt in verschillende vormen. Bij de één gaat de VM ongepland uit bij een kritisch defect en wordt deze op andere fysieke hardware weer automatisch opgestart. Bij een andere wordt er continu een schaduw kopie van de VM bijgehouden op andere hardware die actief wordt als het origineel wegvalt. Zo zijn er nog aantal mogelijkheden om je applicatie hoog beschikbaar te maken. Bij het kiezen van een beschikbaarheid strategie is het wijs om je te laten adviseren. Want niet elke evacuatie strategie past goed in jouw infrastructuur.

Herstel versnellen

De snelheid waarmee je een systeem hersteld is bijna altijd afhankelijk van de inrichting van de back-up. Maak je gebruik van een back-up procedure die individuele bestanden back-upped. Dan zul je voor dat je kunt herstellen een systeem moeten bouwen waarop je die individuele bestanden op terug kunt zetten. Dit is een erg traditionele en inefficiënte manier van back-uppen. Back-up je alleen naar tape dan zul je je back-up dus ook van tape terug moeten halen.

Acronis (een vooraanstaande speler op back-up gebied) geeft een 3-2-1 richtlijn. Deze is als volgt:

• Maak 3 verschillende back-ups. Zodat bij een incident niet alle back-ups verloren gaan
• Sla de back-ups op 2 verschillende media op. Denk hierbij aan hardeschijf, tape, cloud etc..
• Zorg ervoor dat in ieder geval 1 back-up zich buiten het pand bevindt. Ingeval van diefstal, brand, overstroming etc..

Zonet gaf ik een voorbeeld van een back-up procedure waarbij individuele bestanden werden geback-upped. In combinatie met virtualisatie is dit niet een verstandige strategie. Nu is back-uppen van complete systemen door middel van individuele bestanden sowieso niet heel erg handig.

Wat je eigenlijk wilt is het complete systeem back-uppen met alles wat daar in zit. Dus in combinatie met virtualisatie wil je dus een complete VM back-uppen. Dit noemen ze een “image-based” back-up. Op deze manier kun je bij een herstel de volledig VM terug zetten. Als je er dan ook voor kiest om de laatste back-up op een snel toegankelijk medium beschikbaar te hebben. Zoals een direct benaderbare harde schijf. Dan kun je in geval van een kleine calamiteit heel snel, en dan bedoel ik minuten, je systeem weer in de lucht hebben op een ander stuk hardware.

Als je dan kijkt naar een hele voorzichtige berekening:

In deze berekening heb ik alleen de directe kosten meegenomen van de techneut om één systeem te herstellen. Dit tegen een tarief van € 90,-. De uren die ik in de berekening heb gebruikt komen uit een onderzoek van Veeam. Daarnaast ga ik uit van één incident per jaar gezien over 3 jaren. Ook heb ik de uren van een “image-based” herstel traject aangedikt. Hiervoor heb ik 4 uren aangehouden terwijl dit onder het uur zou moeten kunnen. Alles is natuurlijk afhankelijk van goed geteste herstel procedures.

Wat je dan eigenlijk ziet is dat los van gevolg schade, één systeem over 3 jaar gezien het al te rechtvaardigen is om virtualisatie en “image-based” back-ups te overwegen. Waarschijnlijk heb je meer dan één systeem. Dus kan het al heel snel uit.

Mijn advies

Wees niet bang voor virtualisatie. Virtualisatie hoeft geen grote stap te zijn. Het kan ook in kleine stapjes. Test je back-up procedures van begin tot eind. Heb je vragen, laten we dan even een bak koffie drinken.