Het is een dooddoener maar de zwakste schakel bepaalt nog altijd de prestatie en tegenwoordig 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.
Onderste steen boven
Maar het gaat natuurlijk om de bovenkant, de frontend IOPS die uiteindelijk de prestatie van een applicatie bepaalt. Services hebben nu eenmaal verschillende karakteristieken en zo stelt een database dus hele andere eisen aan de opslag dan een vdi-oplossing. Naast lees- en schrijfbewerkingen moet ook rekening gehouden worden met de doorvoer. Deze is niet alleen afhankelijk van storage protocollen zoals blockbased I/O en filebased I/O maar ook van de blocksize.
Juiste keuze is hier dus afhankelijk van de behoefte die soms door applicatieleveranciers gegeven wordt maar meestal gemeten moet worden. Toch ontbreekt het vaak aan informatie vanuit de infrastructuur om capaciteitsmanagement, probleemmanagement en financieelmanagement van de juiste gegevens te voorzien. Opmerkelijk want er is geen tekort aan gereedschappen om deze informatie te verkrijgen. Wel ontbreekt het aan vakmanschap waardoor de blokken in de architectuur steeds vaker ‘black boxes' worden.
Meten is weten
Hulpmiddelen als SQLIO en IOmeter kunnen in combinatie met bijvoorbeeld SQL-profiler en performance monitor hierbij helpen. Maar bezint eer ge begint is helaas niet meer de wijsheid die betracht wordt en dus wordt meten pas weer in de planning opgenomen als het zwarte pieten al is begonnen. Technisch beheer is misschien ondergewaardeerd maar nog steeds een vak dat voorkomt dat gebruikers van het kastje naar de muur gestuurd worden.
Hierbij is het ook niet onbelangrijk dat er met een helikopterview naar de prestatie van ketens gekeken wordt. Dit betekent dat naast een toolset voor testen en monitoren ook kennis van de architectuur nodig is om de verkregen gegevens naar waarde te kunnen beoordelen. Een goede analyse vooraf voorkomt niet alleen verrassingen maar ook onnodige investeringen en de dure migratiekosten achteraf. Te vaak ontbreekt echter een norm waaraan gerefereerd kan worden en blijven klachten over teruglopende prestaties in ketens vaag.
Return of investment
Zo bleek bij een klant dat een applicatie intensief gebruik maakte van de pagefile via memory-mapped file I/O. Met een hoge pagefile activiteit werd dus, keurig zoals geleerd op cursus, het geheugen uitgebreid in combinatie met een wijziging in het besturingssysteem om dit alles te kunnen adresseren. Dat gaf echter geen enkel positief effect omdat de oplossing lag in het decentrale disk subsysteem, waar een simpele JBOD-configuratie zorgde voor de prestaties die nodig waren.
Ook eenvoudige database-aanpassingen kunnen zorgen voor een efficiënter gebruik en de response van de keten ten goede komen. Zoals prestatie verbetering van een crm-applicatie met 40 procent door indexen en storage protocollen te optimaliseren, waardoor andere applicaties meer ruimte kregen. Maar ook na inrichting zal men moeten blijven kijken naar mogelijke optimalisaties want er zijn in de it geen ‘set and forget' oplossingen. Wederom ontbreken ook hier niet de middelen om dit te doen, maar worden ze veelal nog niet of verkeerd gebruikt.
Maatpak of confectie
Tussen bovenkant en onderkant zit de box van de leverancier die alles bij elkaar lijmt tot een oplossing. Hierbij lijkt, net als cloud, de term san tegenwoordig een kapstokbegrip te worden waardoor er nauwelijks verschil gemaakt wordt tussen blockbased (san) en filebased (nas) oplossingen. Nu convergeren beide technologieën weliswaar en kunnen hybride in dezelfde box gebruikt worden wat ook geldt voor het mengen van sas-, sata- en ssd-schijven. Functionele mogelijkheden worden vooral bepaald door de software, diee niet zelden afhankelijk zijn van bijkomende licenties. Zoveel leveranciers, zoveel verschillende oplossingen zorgt ervoor dat juiste keus uiteindelijk altijd maatwerk is, net als de inrichting. Toch wordt nog verrassend vaak hier te licht over gedacht en worden uiteindelijk vierkante blokken door ronde gaten geslagen, wat dus vroeg of laat gaat knellen.
Ewout, zoals altijd een mooi artikel!
Spijtig dat er nog steeds onvoldoende aandacht besteed wordt aan het ontwerpen van SAN Storage. Ik denk dat dit ook te maken heeft met de financiële aspecten van het project. Bijvoorbeeld in een VDI offerte, als je aangeeft dat je zo veel uren moet besteden aan het onderzoeken en analyseren van de huidige desktop en applicatieomgeving om dit verder om te zetten in ontwerp van San Storage, dan zal de klant van de benodigde uren en kosten huiverig worden en bij een andere leverancier aankloppen die dat voor minder doet! Maar ja, goedkoop is duurkoop!
Verder vind ik dat er meer aandacht besteed moet worden aan de overige componenten in de keten. Wanneer je je SAN Storage goed ingericht hebt maar je blad-omgeving of je (virtueel of fysiek) netwerk niet juist geconfigureerd zijn dan kom je weer in problemen. Zoals je aangaf, meten is zeer essentieel voor het ontwerpen van je SAN Storage. Als je weet waar je Read en waar Write IOPS gegenereerd worden dan weet je ook hoe je je omgeving moet indelen en welke technologieën (zoals Caching-cards) je moet gebruiken.
Ik denk dat het ook belangrijk is om een visie te hebben van je ict omgeving voor de komende 2-4 jaar. Hiermee kun je ook bij het ontwerpen van je San Storage rekening houden met de veranderingen die je ict omgeving in de nabij toekomst mee gaat maken.
Ewout,
Goed artikel waar voor dank!
Meten is weten. Ieder type data heeft een ander gedrag en de wensen en eisen zijn vaak verschillend. Dit gaat natuurlijk verder dan alleen de disken. Een SAN bestaat uit disken,type data/applicatie, software, interfaces, protocollen en netwerkcomponenten etc. etc.
Het is daarom van groot belang om je huiswerk vooraf voor al deze lagen goed te doen. Een storage oplossing welke verschillende tiers ( lees automatic storage tiering ) ondersteunt begint steeds meer commodity te worden. De data welke veel performantie nodig heeft wordt op snelle disken geplaatst en de data die minder veeleisend is wordt op de tragere ( lees goedkopere ) disken geplaatst.
Ook wordt zoals Reza al aangeeft IO offload technologie dmv van SSD disken in de storage oplossing of IO offloading kaarten in de servers te plaatsen steeds vaker ingezet.
En is er nog geen bestaande storage omgeving verdiep je dan in de geldende best practices ( voor zover aanwezig ) en doe een stukje markt consultatie bij meerdere partijen. Het consumentbondoverzicht waar ik al vaker over gesproken heb kan hierbij een simpel maar zeer handig hulpmiddel in zijn.
Door vooraf goed je huiswerk te doen en hier ook voldoende tijd voor te reserveren voorkom je toekomstige teleurstellingen. Je kan wel die mooie en super snelle Ferrari aanschaffen maar als je niet harder mag of moet dan 50 KM per uur heb je daar toch niets aan. En vice versa is het natuurlijk ook erg cru als je een Trabant aanschaft maar in de werkelijkheid toch die snelle Ferrari nodig hebt.
Goed verhaal, wat wel een vraag naar boven brengt:
Is dit soort kennis, of in ieder geval het bewustzijn van de werking van dit soort opslagmechanismen, voldoende bekend bij systeem-architecten?
Je merkt terecht op dat de snelheid bepaalt wordt door de zwakste schakel, maar om deze te bepalen moet je wel weten welke schakels allemaal van toepassing zijn, maar belangrijker nog is dat je weet hoe je de specs van de schakels moet lezen en interpreteren
@PaVaKe
Door de vraag die je gesteld heb is me opgevallen dat “het bewust zijn” deze keer voor je interessant is geworden!
In mijn vorige artikel over SAN Storage heb ik o.a. dit thema “het bewust zijn” onder aandacht gebracht(voor de klant en de uitvoerder).
Misschien is het handig dat je nu ook aangeeft vanaf welke positie je deze vraag stelt: Klant of de Uitvoerder!
Ben je de klant, dan zou het je salami wezen (zoals je dat zelf aangegeven heb)of de betreffende systeem-architecten kennis van dit soort zaken heeft of niet!
Ben je de uitvoerder dan zal het je je opdracht (en misschien nog een boete) kosten als je niet voldoende bewust bent van de techniek, relaties/afhankelijkheden en nog meer.
Link naar deze discussie:
https://www.computable.nl/artikel/opinie/infrastructuur/4376071/2379248/sanstorage-is-het-fundament-van-je-ict.html
@Reza
Geen van beiden … ik stel de vraag vanuit een discussie die ik regelmatig in de ICT terug zie komen:
Wat mag ik van een bepaalde rol verwachten?
Ofwel, als ik in een project een architect heb zitten, mag ik dan van deze persoon verwachten dat hij zich bewust is van dit soort aspecten?
Of komen we hier pas achter na implementatie, en mag de storage consultant het probleem komen analyseren en oplossen?
@paVake
Zoals ik al naar voren bracht wordt speciale kennis er meestal pas bijgehaald als er problemen zijn. Consultant/architect vervult, in samenwerking met andere disciplines dan een rol als ’troubleshooter’. Niet zelden omdat een proces als probleem management ontbreekt waardoor de puntjes niet met elkaar verbonden worden. Ik geef in het artikel maar 2 voorbeelden van Root Cause Analysis (RCA) waar ik er helaas velen uit de praktijk ken. Voor een goede analyse moet je niet alleen kennis hebben maar ook onbevooroordeeld naar het probleem kunnen kijken. Feiten en dus niet het gevoel laten spreken in de queste naar de oplossing. Orginele titel van artikel was ‘Magische toeren in de opslag’ waar een kwinkslag in zat omdat het magische niet zo zeer de techniek is maar hoe we er tegen aan kijken.
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 ook niet direct de architect die meerwaarde levert maar de processen die voor de informatie moeten zorgen die nodig zijn. Functioneel kan er dan geroepen dat er maar x aantal transacties zijn maar als er ‘onderhuids’ dubbel zoveel plaats vinden dan zullen deze ook betaald moeten worden. Als projectteam niet aangeeft hoeveel IOPS ze nodig denken te hebben is het moeilijk om de goede inrichting te maken, wat met consolidatie van de opslag steeds belangrijker wordt.
Antwoord op je vraag of er voldoende bewustzijn is bij architecten over de werking van opslagmechnismen is volgens mij: NEE
Regeren is vooruitzien maar performance testen staan helaas, als er tenminste al aan gedacht wodt, achteraan op de planning. Als dan blijkt dat afgesproken prestaties niet behaald kunnen worden dan levert dat nogal veel stress op. Misschien dat daarom stress testen niet gedaan worden waardoor broodnodige baselines ontbreken of erger nog, deze onderin een bureaula worden gestopt. Business kan dan roepen dat IT weer zijn hakken in het zand zet zodat project volgens planning en binnen budget opgeleverd kan worden. Tijd en maatwerk kosten nu eenmaal geld en optredende problemen worden gewoon als latere wijzigingen in een ander project gedaan. Op die manier is iedereen, behalve de gebruiker gelukkig en IT krijgt daar uiteindelijk gewoon weer de schuld van.
Terugkomend op je vraag of een systeem/infrastructuur architect in een projectteam opgenomen moet worden zeg ik dus ook: NEE
Wel hoort deze onafhankelijk de impact van wijzigingen op de infrastructuur te beoordelen zodat tijdig capaciteit of inrichting aangepast kan worden met bijvoorbeeld (workaround) oplossingen zoals Reza en Ruud aangeven. Zoals ik zelf aangaf in artikel ontbreekt het niet aan middelen om de technische details uit de infrastructuur te krijgen, wel vaak om deze gecontroleerd te belasten. Storage consultants of andere subject matter experts kunnen heel goed adviseren als ze maar weten wat er nodig is. Virtualisatie heeft dan misschien wel de infrastructuur effectiever gemaakt maar niet altijd efficiënter waardoor ketens op sommige plaatsen te dik en andere plaatsen te dun zijn.
Confectie of maatwerk is uiteindelijk een keuze die gemaakt kan worden vanuit functioneel, technisch of kosten aspect. Hierbij moet zoals Reza opmerkt rekening gehouden worden met de toekomst. Want de snelle Ferrari van Ruud kan weleens onhandig zijn bij gezinsuitbreiding, of je moet genoeg geld hebben voor een ‘scale-out’ oplossing. Hou in dat geval ook rekening met de bijkomende kosten als brandstof en belasting die gezien stijgingen in prijs beter bij kunt houden dan eenmalig te berekenen met opgave dealer.
“Manier van opslag bepaalt het systeemprestatieniveau”. Dat is zeker waar, maar het is slechts een klein gedeelte van de waarheid. De harde schijf vormt de basis van de problematiek. Ronddraaiende schijven en heen en weer zwaaiende armpjes, dit is het enige mechanische onderdeel van de computer. En om het maar eens heel hard te zeggen, het zijn antieke ondingen die in een moderne computer eigenlijk niets te zoeken hebben. We hebben alleen nog niets anders om ze te vervangen, althans niets dat economisch verantwoord is bij grote hoeveelheden data. De prestaties van de harde schijven vormen echter het snelheidsbepalende criterium bij een moderne computer.
Dan ligt het dus voor de hand dat bij de opleiding van applicatie programmeurs en database administrators veel aandacht besteed wordt aan disk-IO. Maar vergeet het maar, de meeste applicatie programmeurs en database administrators verkeren in zalige onwetendheid over de invloed van hun code en instellingen op de disk-IO en daarmee direct op de prestaties van het systeem. Database administrators die geen flauw idee hebben van de invloed van de grootte van de database cache op de prestaties van het systeem? Dat is schering en inslag. Hoe vaak ik wel niet meegemaakt heb dat er al maandenlang vergaderd wordt met leveranciers van software over de slechte prestaties van een systeem, en dan blijkt het simpel uitbreiden van de database cache de oplossing. Soms zie je dat 50% tot 90% (!!) van het fysieke geheugen van zo’n systeem voor die tijd niet in gebruik is.
Disk-IO voorkomen is namelijk de beste manier om de storage bottleneck te vermijden. Je kunt systemen factoren sneller krijgen door er naar te streven dat zich zoveel mogelijk in het werkgeheugen afspeelt, in plaats van de storage te gebruiken. In uitzonderingssituaties kan een systeem tot wel een factor 10 sneller worden, maar een verdubbeling of verdrievoudiging van de prestaties zijn vaak makkelijk haalbaar, eventueel door het geheugen uit te breiden. Andere systeem parameters zoals queue-depth instellingen in SCSI en fibrechannel drivers, buffer instellingen van host bus adapters, maximum IO size, schijven zodanig mounten dat geen gebruik gemaakt wordt buffer cache van het systeem (bij databases), de wijze van formatteren van schijven, disk alignment enz. enz., het is allemaal van grote invloed. Sommige systeem instellingen zijn sterk afhankelijk van het type storage dat gebruikt wordt. En zeker, instellingen op de storage zelf tellen ook mee. Want wat je daar soms tegen komt, daar springen de tranen van in je ogen.
De term IOPS wordt ook vaak gehanteerd. Dat is echter een volstrekt nietszeggend begrip als je er niet bij zegt wat voor soort van IOPS. Sequentiële IOPS zijn namelijk redelijk oninteressant, random IOPS des te meer. Ik hanteer als vuistregel dat een schijf ongeveer 100 random IO operaties per seconde kan doen. Als dat 100 databaseblokken van 8kB zijn, dan hebben we dus een dataflow van 800kB/sec. Dezelfde schijf kan sequentieel misschien wel > 100MB/sec. halen. Database access is normaal gesproken random access, Het aantal schijven dat gebruikt wordt voor de database is dus direct van invloed op de mogelijk prestaties, maar ook hoe je de data spreidt over die schijven is van belang. Alle indexen op één schijf helpt niet echt.
Nog een paar jaar wachten en we zullen hopelijk verlost zijn van al deze problematiek. De flash(-achtige) halfgeleiders zullen de schijven zo snel mogelijk vervangen. En dan niet in de vorm van SSD’s, want flash geheugen in een doosje prakken en dan doen als of het een harde schijf is, is bepaald niet de meest optimale vorm om van deze techniek gebruik te maken. Ik verwacht dat systemen op termijn een flash bus krijgen, zoals ze nu ook al een DRAM bus hebben. In tussentijd zal flash op PCI kaarten geplaatst worden, al dan niet in combinatie met harde schijven.