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.
Ewoud,
Als ik het over ontwerp en prestatie heb dan heb ik het over drie fases:
1) voor het project, 2) direct en vlak na het project 3) toekomst.
Prestatie heeft directe lijn met architectuur en dus het ontwerp hiervan. Het is terecht als je aangeeft dat je veel zaken moet onderzoeken en data verzamelen voordat je aan je ontwerp begint. Hoe breder je dit aanpakt hoe degelijker je ontwerp wordt.
Fase 1: Het resultaat van het vooronderzoek is gebaseerd op de huidige architectuur. Je hebt uiteraard deze gegevens nodig om er de nieuwe architectuur mee op te zetten maar dit betekent niet dat je gelijk in de nieuwe omgeving op de juiste waarde zit. Om dit te corrigeren heb je zeker behoefte aan “verschillende” stresstesten gedurende diverse bouwfases van je project. Doe je dat niet dan ga je in productiefase een feest tegemoet!
Fase 2: In je ontwerp heb je rekening gehouden met de groei en vraag naar meer capaciteit en performance in de toekomst. Hierdoor heb je een tijdje na het afronden van je project, een oplossing voor dit vraagstuk. Zolang je in deze fase blijft dan heb je geen behoefte aan uitbreiding en je wordt niet aangesproken op de kosten die je al gemaakt heb voor het project (initiële investering). De vraag is, hoe lang kan je in deze fase nog blijven?
Fase 3: In deze fase gaan we de zaak uitbreiden. Je hebt van tevoren een beperkt invloed op deze fase. Deze fase wordt bepaald door verschillende intern en externe veranderingen zoals nieuwe technologieën, nieuwe mogelijkheden, nieuwe behoeftes vanuit business en gebruikersorganisatie etc. Dan is de vraag tot hoeverre je architectuur van fase 1 veranderd moet worden om een antwoord te hebben op de vraag uit fase 3! Hebben we het over een relatief kleine wijziging of weer een grote investering!
Ik ben van mening dat de wetendheid die je nodig heb voor het funderen en ontwerpen van je project zeer essentieel is. Maar vroeg of laat krijg je te maken met de vraag naar meer capaciteit en performance dus het volgende project (te weten uitbreiding)
De vraag is wanneer en met welke omvang!
Ewoud,
Zeer herkenbaar dat een architect er vaak te laat bij gehaald wordt. Meestal wordt dit pas achteraf gedaan.
Ook kom ik veel “eilandjes” binnen dit soort projecten tegen. En deze eilandjes weten vaak niet goed van elkaar waar mee ze bezig zijn. Of te wel ze werken erg vaak langs elkaar heen.
Als er in de “keten” 1 verkeerde keuze gemaakt wordt heeft de rest daar vaak last van.
Bezin eer ge begint geldt ook hier weer niet als overbodige luxe.
@Ruud,
Wat zou jij als architect doen als je in deze situatie(laat betrokken worden) terecht komt?
@ Reza,
In dit soort situaties draait het vooral om bewustwoording van de klant. Echter is dit makkelijker gezegd dan gedaan. Een klant zal het nooit leuk vinden om te horen dat er de verkeerde keuzes zijn gemaakt.
Het is daarom van belang om dit voorzichtig te brengen en natuurlijk niet alle daarbij behorende politiek uit het oogpunt te verliezen. Doe je dit niet dan wordt er vaak niet naar je geluisterd en sta je snel weer buiten.
Ook dien jeconstateringen goed onderbouwd te worden en aantoonbaar zijn. Zeker als de klant zich nog totaal niet van bewust is. Als dit wel het geval dan is het natuurlijk een stuk makkelijker en kan er sneller
geschakeld worden om tot een oplossing te komen.
Zo niet dan moet je genoeg tijd en energie reserveren om dit helder en duidelijk kenbaar te maken. Een meting of bijvoorbeeld een performance analyse kan hier een zeer handig hulpmiddel bij zijn.
Wat ik een beetje mis, en dat lees ik dan ook door de reacties van de reflectanten een beetje heen, is dat je met de materie IT heel eenvoudig in ‘containers’ kunt denken. Het is jammer te constateren dat men na al die jaren van ontwikkeling, het klaarblijkelijk nog niet helemaal voor elkaar heeft gekregen, naar de klant, maar ook de eigen IT organisatie, duidelijk te maken dat de IT als materie het juist heel goed mogelijk maakt zaken heel aardig op elkaar af te stemmen.
Je kunt, en Ewoud geeft dit al heel goed aan, IT heel mooi en aardig sturen wanneer je niet vergeet met schaalbaarheid naar morgen te kijken, me dunkt dat dit dan uiteindelijk weer het managen van klanten perceptie is.
Of zijn het juist die dingen die in al die processen en procesjes klaarblijkelijk ondersneeuwen waardoor men zo vaak weer achter de feiten aan moet, met alle gevolgen en financiële consequenties van dien?
Ik mis nog één aspect in het, overigens heldere, verhaal en reacties: de ellende van uitbesteding die mede bijdraagt aan dit soort problematiek:
– Het PC beheer is uitbesteed aan partij A. Uit efficientie-overwegingen kun je standaard kiezen uit laptop type X of desktop type Y. Wil jij, omdat het de performance ten goede komt, type X’ of erger nog type N hebben, dan kan dat niet, of tegen een absurd hoge meerprijs, met een besteltraject dat de projectduur ruim overschrijd.
– Het netwerkbeheer is uitbesteed aan partij B. Volgens hun metingen is er niets aan de hand en is er bandbreedte genoeg beschikbaar. Maar zoals al geschreven werd: het maakt nogal verschil of je een e-mailtje van 25 KB verstuurt, of een iso image van 4.7 GB. En nee meneer de netwerkbeheerder, dat kan niet altijd ’s nachts!
– Een vergelijkbaar verhaal zullen de meesten van jullie zelf wel kunnen verzinnen als we het storagebeheer ook uitbesteden, bij voorkeur aan partij C. “Even” 500 GB storage aanvragen kost maanden tijd bij externe partijen, terwijl we het bij mediamarkt zo van de plank kunnen pakken.
Gevolg van dit alles: mensen gaan lokaal zelf oplossingen bedenken en implementeren in plaats van alles netjes via de IT afdeling te regelen.
Immers, even een High-end PC + NAS kopen bij een mediamarkt is een stuk sneller, en vaak ook nog goedkoper, dan alles netjes te regelen.
Project blij, en ze kunnen ook nog iets opleveren wat voldoet aan de performance specs. Helaas is dit wel een korte termijngedachte.
Op het moment dat het product dan geconsolideerd wordt in het bedrijfsnetwerk, komen de (eventuele) performance problemen alsnog aan het licht.
Maar het project is dan al afgelopen, de projectmanager met z’n bonus vertrokken, en de ellende blijft achter bij de beheersorganisatie.
Ewoud,
Bedankt voor dit artikel. Hetgeen jij beschrijft merken wij als ISP ook. Er wordt niet altijd (uitgebreid) onderzoek gedaan naar de huidige eisen van een infrastructuur en niet altijd rekening gehouden met de fases die Reza beschrijft. Hier ligt uiteraard ook een kans voor de aanbieders, die door een betere advisering van de klant (een beetje) kunnen helpen bij het implementeren van een oplossing die vanaf het begin voldoet.
Wat wij echter ook merken is dat men het benodigd aantal resources (CPU, RAM, etc.) afneemt, maar deze vervolgens niet juist verdeeld/reserveert over VM’s of applicaties. Is dat iets waar jij ook ervaring mee hebt?
Rick,
Ja, het alloceren van de juiste hoeveelheid resources is een hot topic.Tenminste ik kom het vaak tegen.
Zeker op het gebied van storage. Er wordt vaak alleen naar opslagcapaciteit gekeken en niet naar performance.
Op zich zijn hier hele makkelijke ezelsbruggetjes voor, want iedere disk supporteert een bepaalde bandbreedte in IOPS. En performance komt grotendeels nog steeds uit de disken.
SATA = 80 IOPS
SAS 10k = 120 IOPS
SAS 15k = 180 IOPS
Het is voor het onderdeel storage erg belangrijk om vooraf goed de performance en opslag wensen en eisen duidelijk te hebben. In storage
land geldt namelijk niet “one size fits all”.
Niet alles dient tegenwoordig op snelle en dure disken te staan. Een technologie zoals automatic storage tiering kan hier slim mee omgaan.
Ook voor bijvoorbeeld backup is het belangrijk om goed in kaart te brengen of alles wel even belangrijk is en ook echt veilig gesteld dient te worden. Ik heb al eerder geroepen dat dataclassificatie hierbij een goed hulpmiddel kan zijn.
Ook mag bandbreedte niet vergeten te worden. Als het “touwtje” te langzaam is word je niet blij en is het “touwtje” veels te snel en duur en gebruik je er maar weinig van. Ook dan word je niet gelukkig.
Zo zie je dat op iedere laag van de keten het belangrijk is om gedegen keuzes te maken. En het is natuurlijk dat alle lagen ook op elkaar afstemd worden. En dat is zoals Ewoud goed beschrijft wel eens een pijnpunt.
@PaVaKe
Je hebt een situatie geschetst van een organisatie waarin verschillende partijen betrokken zijn, geen vaste richtlijnen zijn en kortom iedereen doet wat.
In deze situatie, wanneer er geen regie, synergie en samenwerking tussen verschillende partijen en interne organisatie bestaat kan alles fout gaan. Verwacht niet veel van de aanpak van Ewout, Reza, PaVaKe en het resultaat van het project als de organisatie zo bestuurloos is.
Spijtig dat er nog de gedachte leeft dat een projectleider uit is op het afronden van zijn project en het binnenhalen van zijn bonus! Dit is typisch de denkfout dat de meeste mensen maken waardoor een scheidingslijn tussen projectleden en projectleider komt liggen. Jammer!
@Reza
Weliswaar off-topic, maar om even in te gaan op jouw laatste opmerking:
Een project levert uiteindelijk een product op, en het enige wat telt bij bedrijven is dat het betreffende product op tijd naar de markt gaat met voldoende kwaliteit.
Het kan dan ook een bewuste keuze zijn bepaalde verbeteringen of kleine problemen (of gebagatteliseerde grote problemen) door te schuiven naar de maintenance organisatie.
Ook zie je nogal eens dat er een “quick en dirty” oplossing geïmplementeerd wordt om snel verder te kunnen, met als kanttekening “dat lossen we in de volgende release of binnen maintenance wel netjes op”
Er staat dus uiteindelijk een product op de markt, en het project heeft haar doelstelling behaald.
De maintenance organisatie mag echter vervolgens de puin gaan ruimen en de echte problemen op proberen te lossen. De projectmanager van het initiële project merkt hier doorgaans niets meer van.
Het zou helpen als er bij oplevering van een project veel meer aandacht besteed zou worden aan de overdracht naar de maintenance organisatie