In toenemende mate wordt in storage RfPs gevraagd om performancegaranties. Begrijpelijk, want niemand zit te wachten op een systeem dat onvoldoende presteert. In de praktijk is het echter zo dat bij het benoemen van de juiste performanceniveaus veel verwarring optreedt, en, laten we zeggen zoals het is, ook veel onzin wordt verkondigd.
Want het is vaak als iemand die twee luidsprekers van elk 50 Watt heeft, en dan van de versterker eist dat die 500 Watt aankan. Terwijl dat natuurlijk niets toevoegt aan de prestaties van het geheel. In het geval van storage wordt performance meestal uitgedrukt in de aantallen i/o-bewerkingen die een systeem per seconde verwerkt, de latency oftewel de tijd die het duurt om datapakketten aan te vragen en te versturen, en de hoeveelheid data in bytes die in een bepaald tijdsbestek kan worden verwerkt. Net als in het voorbeeld van de versterker en de speakers, geldt dat de componenten in balans moeten zijn. Laten we een paar praktijkvoorbeelden bekijken.
Ins en outs
Naast het probleem van het vinden van de juiste performancewaarden in de infrastructuur moet eerst worden opgemerkt dat de genoemde kengetallen eigenlijk niet zo veel zeggen. Als we bijvoorbeeld kijken naar i/o's per seconde: i/o staat voor ‘in-out' bewerkingen. Wanneer er om een systeem met 40.000 i/o's wordt gevraagd, dan is het interessant om eerst te onderzoeken waar die vraag vandaan komt. Sommige applicaties vragen vooral data op (indexservers, zoekmachines), andere schrijven juist weer heel veel weg. Het geval wil dat nogal verschil kan zijn in de tijd die nodig is voor het opvragen van data en het wegschrijven ervan. Een systeem dat voor een bepaalde applicatie 40.000 ‘outs' per seconde levert, levert dus niet automatisch ook 40.000 ‘ins'.
Het komt zelden voor dat een organisatie weet hoeveel data er tijdens piekmomenten werkelijk moet kunnen worden verwerkt. Die informatie vind je alleen door gericht informatie te verzamelen en op een goede manier met alkaar te vergelijken. Meestal is het ook niet duidelijk wat er precies gebeurt op een storagesysteem. Misschien valt de herindexering van de database net samen met een virusscan op een datavolume. Het is dan onzin om een heel hoge i/o-eis te formuleren terwijl de piek kan worden vermeden door die taken anders te plannen. Om het helemaal complex te maken is er ook nog onderscheid te maken tussen verschillende types i/o: disk, cache, network, elk met hun eigen karakteristieken. Weten we dus zeker waar het knelpunt ligt en of die 40.000 i/o's voldoende zijn? Of juist veel te veel, wat tot onnodige kosten leidt?
Brommer
Wat betekent goede performance nu in de praktijk? Vaak gaat het feitelijk om een goede eindgebruikerservaring voor het opvragen van bestanden van een server, het uitvoeren van bewerkingen op een centrale applicatie of het kunnen terughalen van back-updata. We willen niet steeds naar die vervelende zandloper op het scherm hoeven staren, daar komt het op neer. Op technisch niveau bezien hebben latency en de doorvoersnelheid dan inderdaad invloed. Maar als de latency van de storage 10 millisecondes is, die van het netwerk 13, en die van de pc mede dankzij de virusscanner en drie openstaande browsersessies 38, dan heeft het niet zo veel zin om van een nieuw storagesysteem te eisen dat de latency minder dan 8 millisecondes bedraagt. Latency is vooral een aandachtspunt voor de totale infrastructuur, waar het voorbeeld van de versterker en de speaker bij uitstek van toepassing is. En als van de back-upsoftware wordt verwacht dat een full back-up binnen acht uur kan worden uitgevoerd en dus maximale throughput moet leveren, terwijl je met een snapshot in minder dan een minuut exact hetzelfde kunt bereiken, dan maken we de grote, maar vaak voorkomende fout dat we proberen bestaande knelpunten te sub-optimaliseren in plaats van dat we kijken naar nieuwe architecturen en technologieën die de knelpunten compleet uitbannen.
Een storage-architect met wie ik vroeger samenwerkte, vatte het ooit mooi samen: 'Ik heb het gevoel dat ik elke dag op een bakfiets heen en weer moet, en nu van mijn baas een hele mooie dure racefiets mag uitkiezen. Maar ik wil gewoon een brommer die de helft kost en twee keer zoveel kan vervoeren!'
Schaalbaarheid
Blijft de vraag over hoe je wel op een goede manier kunt zorgen dat een nieuw aan te schaffen systeem voldoende performance levert, zonder dat je uit angst investeert in een veel te zwaar bemeten en onnodig kostbare oplossing. Het sleutelwoord is schaalbaarheid, en dan niet in de zin dat je een systeem koopt waar je nog heel veel ruimte hebt om extra schijven in te stoppen (een veelgebruikte en bijzonder dure manier om de i/o-capaciteit op te voeren is door spindles bij te plaatsen). Nee, echte schaalbaarheid zit in de architectuur van de storage-oplossing en biedt de mogelijkheid om systemen gericht aan te passen om aan de specifieke eisen van de infrastructuur te voldoen. De verzamelnaam voor deze oplossingen is unified storage en de verwachting is dat unified storage op afzienbare termijn de de facto standaard wordt voor alle professionele data-omgevingen. Het voordeel is namelijk dat de vraag ‘wat voor performance bedoelt u eigenlijk?' niet meer gesteld hoeft te worden.
