Home Architectuur De duivel en z’n ouwe moer

De duivel en z’n ouwe moer

250

In m’n vorige blog had ik het over de ‘mismatch’ die er is tussen de theorie, vastgelegd in de architectuurontwerpen, en de werkelijkheid van de bewegende delen. Hierdoor worden we dan nog steeds geplaagd met onverwachte verstoringen, verkeerde wijzigingen en verspillingen.
Nu is er geen gebrek aan (beheer)hulpmiddelen, eerder een overvloed, maar toch ontbreekt de nodige informatie. Want het is hierbij net als met die examens waar tachtig procent gaat over dat ene boek dat je niet hebt gelezen. Nu zijn deze gelukkig steeds vaker multiple choice en wie gokt komt tegenwoordig dan ook al een heel eind.

Bijvoorbeeld met de opslag, want de duivel eindigt net als de meeste digitale processen bij zijn staart. Tenminste vroeger, toen I/O nog als een duur proces gezien werd, want tegenwoordig wordt op alle momenten geschreven naar de schijf. Nu biedt de huidige generatie opslag veelzijdige toegang, een combinatie van schijven met tiering en virtualisatie om alles goed te verdelen. Als er vooraf in tenminste nagedacht is over de dimensies van de opslag, want uiteindelijk zijn er geen wonderen te verwachten als deze te klein is. Want dan beginnen onherroepelijk de problemen met end-to-end response en gaan gebruikers klagen.

Duivelskunsten
Effectief en efficiënt zijn twee begrippen die vaak door elkaar gebruikt worden, maar andere uitkomsten hebben. Zo kan het doeltreffend zijn om gebruik te maken van universele opslag, maar als data en applicaties erg divers zijn is dat niet altijd doelmatiger. Hierdoor is het net alsof er een snelle Ferrari aangeschaft wordt, waar dan met een slakkengang over karrensporen mee wordt gereden. Bijvoorbeeld door een verkeerde keuze in opslagprotocollen bij centralisatie van de data. Of door de bagagecapaciteit van de Ferrari achteraf uit te breiden met een aanhanger zoals bij ‘framed’ oplossingen, waar uiteindelijk maar één storageprocessor, de intelligentie van de opslag, voor de prestatie moet zorgen. Er zijn vele keuzen die de prestatie beïnvloeden, maar opslag wordt vaak nog als een zwarte doos gezien, hierdoor soms te groot maar vaker te klein.

Probleem bij het dimensioneren van de opslag is, dat informatie over het aantal lees- en schrijfacties, de maximaal benodigde I/O per seconde voor applicaties vooraf ontbreekt. Dit in tegenstelling tot de capaciteit die in de vorm van het aantal terabytes door middel van een simpele optelsom te verkrijgen is. En bij centralisatie van data wordt alles op één hoop gegooid, bij wijze van spreken, want logischerwijs is het natuurlijk allemaal netjes gescheiden. Fysiek moet het echter vaak over dezelfde lijnen, door één toegangspoort en komt het op een paar disks. En achteraf mogen duivelskunstenaars hun werk doen door de metingen te verrichten die nodig zijn om bottlenecks te kunnen identificeren.

 En dat heeft effect op de databases die vaak afhankelijk zijn van optimaal werkende opslag. Vertragingen in de database komen uiteindelijk versterkt in de applicaties terug die hier dus afhankelijk van zijn. Zo wordt er bijvoorbeeld functioneel nog weleens geroepen, dat er maar een x aantal transacties nodig is dat ‘onderhuids’ uiteindelijk (drie of meer) dubbele aantallen lees- en schrijfacties naar de schijf doen. Applicatie-programmeurs en database-administrators verkeren echter vaak in onwetendheid over de invloed van hun code op disk-IO en dus de prestaties van het systeem. En horizontaal schalen, door meer (applicatie)servers in te zetten om deze verticale problemen op te lossen, zal dus geen positief effect hebben op de prestatie.

Maar ook door veel gebruikte virtualisaties, met bijvoorbeeld automatische provisioning, kan niet alleen de datagroei onverwachts toenemen maar ook de prestatie afnemen. Helaas zijn details over techniek tegenwoordig niet meer interessant, omdat standaardisatie de nieuwe maat is en maatwerk te duur. En dus wordt er gegokt met de inrichting, terwijl een goede analyse vooraf niet alleen verrassingen maar ook onnodige investeringen en de dure migratiekosten achteraf kan voorkomen. Want met het gebrek aan inzichtelijkheid in gebruik is elke verandering, toevoeging of vernieuwing uiteindelijk één stap vooruit en twee achteruit.

Duivelstoejager
Het is dus belangrijk, dat naar de prestatie van de gehele keten gekeken wordt waarbij de data vanuit al aanwezige toolset omgezet wordt naar informatie. Hulpmiddelen zoals bijvoorbeeld SQLIO en IOmeter in combinatie met SQL-profiler en performancemonitor kunnen helpen bij het bepalen van de capaciteitsbehoefte. Want naast terabytes is ook de term IOPS een volstrekt nietszeggend begrip als onbekend blijft om welke soort het gaat. Zo zijn de sequentiële IOPS oninteressant maar random IOPS des te belangrijker. En databases maken meestal gebruik van random access waarbij het aantal schijven dat gebruikt wordt dus direct van invloed is op de prestaties. Net als hoe je de data spreidt over de schijven want alle indexen op één schijf helpt niet echt. Maar ook parameters zoals queue-depth instellingen en buffer instellingen van host bus adapters, wijze van formatteren en disk alignment zijn allemaal van grote invloed.

Om terug te komen op de Ferrari kom ik dus nog weleens tegenstellingen tegen in instellingen waardoor de efficiëntie in de opslag ver te zoeken is. Simpelweg omdat het aan vakmanschap ontbreekt om blokken in architectuur met elkaar te verbinden waardoor deze steeds vaker als ‘black boxes’ gezien worden door alle point oplossingen. Logisch lijkt het dan allemaal wel te kloppen maar technisch is het slecht met elkaar verbonden waardoor problemen niet opgelost worden maar gewoon doorgeschoven.

Zie ook: http://www.slideshare.net/edekkinga/opslag-bepaalt-het-systeemprestatieniveau

Ewout Dekkinga  Infrastructure Architect  |  S&T  |  ESS RTI bij Unisys 

LAAT EEN REACTIE ACHTER

Vul alstublieft uw commentaar in!
Vul hier uw naam in