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.


Wanneer blijkt dat afgesproken prestaties niet behaald kunnen worden dan levert dat veel stress op. Misschien dat daarom stresstesten niet gedaan worden waardoor de broodnodige baselines ontbreken of erger nog, deze onderin een bureaula worden verstopt. En op problemen in prestaties reageren we door deze vervolgens als latere wijzigingen, in een ander project met een eigen budget op te lossen. Op die manier is iedereen, behalve de gebruiker gelukkig.

Onwetendheid is een scha(n)de
Niet zelden wordt de architect er ook pas bij gehaald als er problemen zijn waarna deze in samenwerking met andere disciplines eerder een rol als 'mediator' heeft. Voor een goede analyse moet je namelijk niet alleen gegevens hebben maar ook onbevooroordeeld naar het probleem kunnen kijken, feiten en niet het gevoel laten spreken in de zoektocht naar de oplossing. Kijkend naar het Windows platform, over het algemeen nog steeds het meest gebruikte besturingssysteem en ontwikkelomgeving, is er absoluut geen gebrek aan hulpmiddelen om bezetting en prestatie inzichtelijk te maken. Naast de standaard geïnstalleerde performance monitor en taskmanager biedt Microsoft met de Windows Performance Toolkit ontwikkelaars de mogelijkheid om de belasting van een applicatie op de architectuur te meten via zes profielen:

1. Netwerk
2. CPU 
3. Geheugen
4. Opslag 
5. Energie 
6. Multimedia

Hiermee kan dus vooraf bepaald worden hoeveel resources er nodig zijn, of applicatie wel of niet efficiënt omgaat met deze resources en waar eventuele bottlenecks zitten. Informatie die helpt om de impact van wijzigingen op de infrastructuur te beoordelen zodat tijdig capaciteit of inrichting aangepast kunnen worden. Helaas worden netwerk en opslag te vaak als vanzelfsprekend beschouwd en wordt er nauwelijks naar routering en belasting gekeken. Net als dat problemen met inefficiënte applicaties al heel snel met een standaard antwoord van ‘scale out' opgelost worden, al dan niet gevirtualiseerd. Data is koning en de gebruiker keizer maar soms wordt hierdoor het paleis een vergulde maar op sommige plaatsen overbevolkte kooi.

Onevenredige verdeling
Hierdoor komen afgesproken eisen rond prestatie, beveiliging en herstel in het gedrang en moeten er sneller dan gepland weer uitbreidingen in de architectuur gedaan worden. Zonder inzichtelijkheid in gebruik is elke verandering, toevoeging of vernieuwing in de architectuur hierdoor één stap vooruit en twee achteruit. Feitelijk is hier sprake van de wet van de communicerende vaten waar het wegnemen van de ene bottleneck leidt tot een andere totdat alle vaten gelijk gevuld zijn.

Vroeg of laat zorgt dat voor prestatieproblemen want voor een efficiënt gebruik zal uiteindelijk toch gekeken moeten worden naar de consument die nogal divers is,snel verandert en steeds meer data transporteert tussen een toenemend aantal services en locaties. En met het centraliseren van de opslag zijn verschillende vaten met elkaar verbonden en delen gezamenlijk het ‘rietje' delen waar alle data doorheen geperst moet worden. Het ‘rietje' tussen gebruiker en opslag wordt trouwens ook steeds vaker een externe verbinding naar een andere locatie doordat we steeds mobieler worden en hogere eisen stellen aan de beschikbaarheid van de gehele infrastructuur.
 
Organische groei
Ook lijken we alle data uitermate belangrijk te vinden en daarom meermaals op te slaan want met technieken als replicatie, snapshots en deduplicatie zijn er fantastische mogelijkheden om het RPO/RTO vraagstuk op te lossen. Maar als er enorme hoeveelheden data getransporteerd moeten worden over een beperkte bandbreedte dan kost dat tijd.

Zo kan door virtualisatie met bijvoorbeeld automatische provisioning de datagroei onverwachts toenemen. Net als wanneer gebruikers de centrale opslag als een ‘prive cloud' zien en hierop allerlei muziek en video collecties op gaan slaan. En de arme IT manager mag dan weer met hangende pootjes naar de business voor extra geld om problemen op te lossen waarmee het imago van costcenter weer bevestigd wordt.

Presentatie

Deze bijdrage is een verkorte weergave van de presentatie die ik naar aanleiding van eerste opinie over problematiek met opslag gehouden heb voor NvBI. De complete presentatie, minus enkele slides, kan hier opgevraagd worden.