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 Ewout Dekkinga naar aanleiding van eerste opinie over problematiek met opslag gehouden heb voor NvBI. De complete presentatie, minus enkele slides, kan hier opgevraagd worden.
@Reza
Inderdaad gaat het om je uitgangspunt, welke vaak theoretisch is omdat de modellen niet gevuld worden vanuit de architectuur en waar netwerk, maar ook steeds vaker de (toegang tot de) opslag als een wolk gezien wordt. Zeggen we daarmee eigenlijk niet dat we deze gewoon als een ‘blackbox’ zien en waarvan, zoals PaVeKe ook aangeeft het gebruik niet altijd zoals gepland is.
@NumoQuest
Het in ‘containers denken’ of de verzuiling in de IT, al dan niet onstaan door de wens om delen uit te besteden zijn eigenlijk de vaten waar ik het over heb. Een blik op het vloeistof niveau, waarbij een snelle stijging een indicatie geeft van problemen, helpt bij de sturing.
Maar wanneer er een hefboom ingezet wordt om druk, in de vorm van tijd of macht in één van de vaten te verhogen dan hebben we het eigenlijk over hydrauliek. Daarmee kun je dingen optillen en verzetten maar inderdaad ook ontwrichten.
@Rick van den Hoogenhof
Een verkeerde verdeling van belasting is eigenlijk een beetje de kern van mijn verhaal. Ervaring hierbij is dat deze soms ook moeilijk te verdelen is wanneer de hefboom gebruikt wordt en servers via het ‘lift’ principe gevirtualiseerd worden. De latere ‘shift’ waarbij verdeling verbeterd wordt, applicaties gerationaliseerd en kosten verlaagd blijft vaak achterwege of wordt het probleem gemaakt voor inbesteders.
De enige factor die wel moeilijk onder controle te krijgen is blijft de gebruiker die misschien wel koning is maar zich niet altijd als keizer gedraagt. Regie zijn door de diversiteit, snelheid en omvang steeds moeilijker waardoor beheer eigenlijk gewoon een ‘big data’ probleem is. De data is namelijk gewoon aanwezig of kan eenvoudig verkregen waarmee capaciteit veel beter verdeeld kan worden. Dit kan je doen op niveau van datacenter (cloud), service of verdeeld naar de ‘OSI’ lagen zolang je ALLE factoren maar mee neemt want gissen is missen.