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.


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.

Zie ook de bijbehorende presentatie over dit onderwerp