Olifanten en gedachtenwolkjes

Hoe kun je een olifant laten vliegen? Een vreemde vraag om mee te beginnen maar ik verbaas me al enige tijd bij discussies over een onderwerp als de back-up. Natuurlijk kun je bezuinigen op de back-up voor mobiele gebruikers door als een struisvogel je hoofd in het zand te steken en tegen de mol te zeggen dat het prachtig weer is. Want je kunt bestanden wel naar cloud synchroniseren maar ze in korte tijd is dan meestal toch wat anders. Meeste aanbieders roepen hier dus ook niets over omdat ze alleen een back-up aanbieden terwijl het om de restore hoort te gaan.

En ze zijn ook niet allemaal transparant over de beveiliging, het zal dus niet de eerste keer zijn dat  een back-up op straat komt te liggen. Denk ook niet te licht over encryptie want ‘ransomware’ als gevolg van verloren sleutels is nog vervelender dan geen back-up blijken te hebben. Sommige aanbieders in de cloud bieden wel een uitweg maar die hebben dus altijd toegang tot je data. Nu zal ik niet beweren dat cloud based back-up slecht is, in tegendeel zelfs omdat het helpt de olifant van alsmaar groeiend archief aan de kant van de gebruiker op te delen. Want hoewel de back-up zelf een proces van data dupliceren is gaat het dus om de archivering, de herinneringen die we koesteren of moeten bewaren. Maar met alle kopieën die we hebben lijkt dit archief wel steeds meer op de gruzelementen van Voldemort uit de Harry Potter films.

De duivel in het doosje

In deze blog wil ik ingaan op het duivelse dilemma dat we kennen in de ICT, namelijk de uitdagingen in capaciteitsmanagement. Want er is misschien een integrale ketenvisie over hoe informatie stroomt maar de trechter zelf is vaak niet transparant. En dus worden we nog steeds verrast met problematiek van de flessenhals waar een kleine verandering er al voor kan zorgen dat de service als dikke stront door een dunne trechter gaat. Dit omdat de logische waarheid in de architectuur modellen nog weleens af wijkt van de fysieke realiteit.

In de praktijk kom ik dan ook vele voorbeelden tegen waar tegen beter weten in geprobeerd wordt om uit de breedte te halen wat er in de lengte van dagen niet in zit. Zoals een prachtige webfarm waar alle servers afhankelijk zijn van één database. En deze database hangt dan aan de opslag met een ‘rietje’ met een verkeerd storage protocol gekozen is of omdat er vooraf niet gekeken is wat er precies nodig is aan prestatie, de snelheid van het lezen en schrijven. Opslagcapaciteit in gigabytes kost namelijk niks maar de prestatie ervan blijft nog steeds duur. 

Database debacle in de cloud

We kunnen eindeloos blijven schrijven, praten en dromen over de cloud maar het gaat maar om één ding, namelijk de data welke uiteindelijk nog steeds de core asset is van menig bedrijf. En deze kunnen we de cloud injagen maar zal wel bereikbaar, betrouwbaar en bruikbaar moeten blijven. Geen data, geen service en geen business.

In traditionele architecturen zit data vaak gestructureerd in databases en kan gevonden worden met Structured Query Language (SQL), de standaardtaal waarmee meeste databanken gelezen en geschreven kunnen worden. Maar er is ook nog een berg aan ongestructureerde data die in omvang snel toeneemt. Om deze groeiende berg data onder controle te houden zijn wel weer databases nodig, de paradox waar ook de cloud niet aan ontkomt omdat we anders de MP3’s en filmpjes niet kunnen vinden.

Ketenproblematiek en communicerende vaten

Eerder schreef ik over opslag, waarbij keus en inrichting vaak (mede) bepalend zijn voor de prestaties in de keten. Een keus die ook vaak verstrekkende gevolgen heeft omdat het hier meestal om grote investeringen gaat en migreren van de ene oplossing naar de andere veel tijd en geld kost. Een storage architect kan helpen bij het maken van de juiste keus maar deze blijft uiteindelijk afhankelijk van de input die door organisatie gegeven wordt.


En juist daar lijkt het steeds mis te gaan want met confectie in de vorm van virtualisatie denken we wonderen te kunnen leveren maar blijken de onmogelijkheden, in de vorm van capaciteitsmanagement, meer tijd te kosten. Het is dus niet zo zeer de architect die het verschil maakt want het zijn uiteindelijk de processen die de informatie moeten aanleveren. Regeren is nu eenmaal vooruit kijken maar performance testen staan helaas als laatste op de planning, als er überhaupt al aan wordt gedacht.

Manier van opslag bepaalt het systeemprestatieniveau

Het is een dooddoener maar de zwakste schakel bepaalt altijd de prestatie en bevindt deze zich steeds vaker onderin de architectuur, daar waar alles opgeslagen wordt. Aandacht is er wel voor de functionele aspecten maar er wordt vergeten dat meten weten is en gissen niet zelden missen. Juiste keus wordt niet alleen bepaalt door de capaciteit in terabytes maar vooral door het aantal lees- en schrijf bewerkingen per seconde (IOPS).

Prestatie van één disk wordt vaak weergegeven in de uitkomst van een berekening tussen toeren, gemiddelde latency en zoektijd. Wanneer individuele disken samengevoegd worden in een logisch volume dan kunnen deze IOPS bij elkaar opgeteld worden. Dus hoe meer disken in een array hoe beter de prestatie, waarbij er afhankelijk van raid-level wel correcties gemaakt moeten worden. Prestatie van het ijzer, de backend, is dus vooral een rekensom die meestal nog wel gemaakt wordt door de leverancier. We kunnen dus met formules in Excel de prestaties aan de onderkant oftewel de backend IOPS vergelijken.