In het vorige deel van dit artikel heb ik aangegeven dat het storagegebruik van klanten van service providers zeer lastig te meten is en doorberekening dus vaak een moeizame oefening blijkt. Het capaciteitsmodel om chargebacks te kunnen doen, werkt namelijk niet binnen gevirtualiseerde omgevingen.
Er is echter nog een ander stukje in de legpuzzel, dat betrekking heeft op de prestatie-eisen ten aanzien van het hosten van virtuele machines of van de applicaties binnen de opslagomgeving. Dit noem ik de ‘prestatievoetafdruk’ op de opslag. Hoewel veel providers het een aantrekkelijk idee vinden om de kosten door te berekenen op basis van de prestaties, wordt het prestatiegebaseerde model in de praktijk zelden gebruikt vanwege de complexiteit die daarbij komt kijken.
Een gecombineerd gebruik van het prestatiemodel en capaciteitsmodel kan nauwkeuriger resultaten opleveren. Zo kan de virtuele machine (vm) van 50 GB een kwart van de prestatiecapaciteit benutten, terwijl een virtuele machine van 500 GB misschien hooguit 2 procent gebruikt. Vanuit dit perspectief levert het louter hanteren van een capaciteitsmodel geen eerlijke kostenverdeling op.
Iops zijn geen maatstaf
Het is natuurlijk mogelijk om de input/output operations per second (iops) te hanteren als maatstaf voor het doorberekenen van de kosten op vm-niveau, maar ook dat is geen accurate indicator. In verschillende situaties kan de iops namelijk totaal iets anders betekenen. Een voorbeeld: duizend iops met een blokgrootte van 8K neemt veel minder controller-vermogen in beslag dan duizend iops met een blokgrootte van 128K. Zelfs als we gebruikmaken van een genormaliseerde iops-meting waarbij alles wordt berekend in eenheden van pakweg 8K per iop moeten we nog altijd rekening houden met de verschillen in de gebruikte storage door lees- en schrijfbewerkingen. Bovendien heeft willekeurige i/o een grotere invloed op de gebruikte storage dan sequentiële i/o.
Aan het onvermogen om de juiste prijs aan het opslagverbruik te verbinden kleven allerhande nadelen. Voor sommige gebruikers kan deze aanpak nadelig uitpakken. En voor service providers maakt dit het moeilijker om concurrerende tarieven aan te bieden. Het maakt de zaken er bovendien onvoorspelbaar op. Een dienst waarvan de prijs is gebaseerd op X capaciteit en Y iops, haalt deze waarden mogelijk niet eens als gevolg van de verschillende manieren waarop workloads opslagcapaciteit verbruiken en de opslagprestaties beïnvloeden.
Logical unit numbers (lun’s) en volumes zijn ontwikkeld voor fysieke omgevingen. Toch blijven we er onveranderd gebruik van maken in gevirtualiseerde omgevingen, omdat leveranciers van storage-oplossingen tot dusver geen specifieke innovaties voor gevirtualiseerde implementaties hebben afgeleverd. Daar komt nu echter een einde aan dankzij vm aware storage. Hierbij wordt gebruikgemaakt van vDisks (denk aan vmdk’s, vhd’s enzovoort) als de abstractielaag binnen het opslagplatform.
Dit maakt het mogelijk om het opslagverbruik op het juiste niveau van abstractie te raadplegen, zonder de extra complexiteit die gepaard gaat met lun’s en volumes. Providers kunnen zo precies zien hoeveel capaciteit er aan een virtuele machine wordt geleverd of hoeveel capaciteit er binnen een vm wordt benut. Zo kan de totale capaciteitsvoetafdruk van een virtuele machine in kaart worden gebracht. Dat heeft niet alleen betrekking op de live data, maar ook de opslagruimte die voor andere doeleinden wordt benut, zoals de gegevensbescherming.
Dankzij deze aanpak hebben service providers de mogelijkheid om tarieven aan te bieden die aansluiten op de opslagcapaciteit die klanten werkelijk benutten. Het vergroot de voorspelbaarheid rond het opslagverbruik en de nauwkeurigheid van metingen daarvan. En een verbeterd inzicht in het capaciteitsverbruik betekent dat providers nieuwe manieren kunnen identificeren om klanten meerwaarde te bieden.
Als je het gebruik van luns en volumes kan meten, waarom koppel je die dan niet 1-op-1 aan de (virtuele) host waarvan je kosten wilt doorberekenen ?
Niet delen dus, tussen verschillende hosts en hun klanten, maar toekennen aan dezelfde host. Dan meten en kosten doorberekenen. Juist luns zijn bedacht om fysieke storage te virtualiseren. Een lun kan bijv een deel van een fysieke disk zijn die zich presenteert aan de host als een hele disk.
Wat voegt vm aware storage toe als je op bovenstaande manier zelf vm aware je lun mapping doet?
Laat ik zeggen dat ik in opinie een oud NetApp denken zie, beginnen met een vanaf prijs om vervolgens onder de streep op het vijfvoudige uit te komen door een cost accounting achteraf. Het in rekening brengen van opslagkosten is in principe mogelijk binnen een SDS concept omdat de Storage Processor alles voorbij ziet komen hoewel ik betwijfel dat klanten dit willen weten. Het pay-per-use wordt daardoor gewoon de oude truc van: Get them in, move them up and keep them there.
En dat maakt dat dit een grappige opinie is omdat deze wijst op de ‘burning cost’ van opslag welke dus lange tijd veronachtzaamd was met de gedachte dat dit niets kost. En IOPS zijn misschien niet alles bepalend omdat throughput en latency ook nog wat zeggen maar is veel software echter wel geschreven op deze interrupts. En langzaam komen we er dus achter dat als je alle oude business software in nieuwe containers van virtualisatie propt je zeker niet de opslag moet vergeten, if the shit hits the fan…..
https://www.youtube.com/watch?v=IQrj8ug1By4
Nu ben ik Gekke Henkie maar ondertussen heb ik genoeg overcommitted oplossingen gezien die zo straks gespannen staan dat als een SCRUM team de virtuele omgeving in ruste activeert om een bug op te lossen er hotspots ontstaan welke pas langzaam wegebben als de rust is wedergekeerd. Bij alle organisaties die sterk projectgedreven zijn duurt dat steeds langer waardoor vier indexservers elk een compleet ander antwoord geven op exact dezelfde vraag, on error resume next van de belastingtelefoon zou niet moeten gaan om de snelheid van het antwoord maar de compleetheid en correctheid ervan.
Every damn fool can do for a dollar what an engineer does for a nickel, iedereen kan de front-office vertikaal schalen maar deze is vaak nog erg afhankelijk van de back-office waardoor ik steeds vaker de indruk krijg dat sommige ontwikkelaar dom geboren zijn met Windows, suf gewiegd met VMWare en daardoor niets geleerd hebben over dirty cache.
Hi Felix, bedankt voor je reactie.
Ik geloof dat wij een andere definitie hebben van VM-aware. 🙂
Allereerst zijn LUN’s ontstaan uit de noodzaak om fysieke applicatie aan een stuk storage als een app-server-lun (1 op 1 relatie) met de Storage te koppelen. Deze was makkelijk te monitoren en als de applicatie meer performance nodig had vergroot je de lun of je voegt nog een lun toe aan diezelfde fysieke host. Deze storage spreekt LUN een andere taal dan VM. Met de komst van virtualisatie waarbij je een zo hoog mogelijke dichtheid aan vm’s per host gaat draaien levert dit in een tradionele storage architectuur die gebouwd is om i/o op een FIFO (first in first out) of I/o queue af te handelen problemen met name door de grote hoeveelheid gemêleerde iops die door de verschillende apps door de hypervisor concurrent richting Storage gestuurd worden. Dit noemen we I/o blender effect. Zeker met flash in de architectuur kan dit apps met verschillende blocksizes enorme impact hebben. Traditionele Storage op LUN of volume basis hebben geen idee wat een vm is of laatstaand geen notie hebben van waarom een read of een write op een bepaald blokje Bijv op LUN 22, blokje 786 plaatsvindt. Een blockbased storage device ziet de virtuele machine (vmdk) alleen als blokjes meer niet. Het kan niet in de blokjes kijken. Volumes hetzelfde, file based storage ziet alleen files. Nou is een virtuele machine niets meer dan een set van files, maar kan niet in de files kijken en weet dus ook niet of een file een swapfile is of een vdisk of waar die vdisk voor dient of wat de relatie van de vdisk met de vm is. Maar vandaar dat je bepaalde intelligentie nodig hebt in je Storage (SDS) die dus dat dus wel kan en echt vm-aware is dmv API’s die er voor zorgt dat VM taal begrepen en geinterpreteert wordt naar de juiste resource behoefte op een per vm basis en dit via een eigen baan richting de storage afhandelt. Stel je voor dat er in de supermarkt 1 kassa open is en er 8 mensen wachten. Er zitten wat volle boodschappen karren bij maar ook mensen met een mandje, erg vervelend voor de mensen die maar weinig kopen. Stel je dan voor dat iedereen zijn eigen kassa krijgt. Hierdoor hoeven vm’s nooit meer voor dezelfde resources te vechten. Dus geen noisy neighbour meer (grote boodschappenkar oftewel i/o intensieve workload meer waar je klant oftewel vm last (latency) van hebt).
VM-aware storage houdt ook in dat de storage exact weet wat elke vm aan iops/throughout latency en flash hit ratio doet. Echt QoS op een per Vm basis en dan op host/netwerk/storage niveau. Het liefst wil je dat dit volledig automatisch (see, learn en adapt) gebeurd zodat je niet op LUN niveau vm performance moet gaan managen omdat als een vm meer performance nodig heeft, diezelfde vm samen met de andere vm’s voor dezelfde resources op die LUN vecht. Op LUN niveau QoS bieden heeft hierdoor dus geen zin tenzij je een vm per LUN gaat doen en dat wil je niet met tientallen, honderden of zelfs duizenden vm’s in een of meerdere DC’s. Je maakt dus met LUN mapping niets vm-aware in mijn optiek.
Hallo Ewout, ook dank voor jouw reactie.
Van elk “tradioneel” denken zou je vanaf willen. Je wilt realtime inzicht hebben wat de performance (iops, throughput, latency bijv) is per gevirtualiseerde applicatie. Dus geen cost accounting achteraf maar een prijs per IOPS bijvoorbeeld afspreken of een prijs per VM. Hier kun je de klant op rapporteren. Sterker nog, idealiter de klant zelf inzicht geven in de performance en beschikbaarheid van zijn eigen omgeving. Hierdoor kan de klant zelf goed zien wat hij verbruikt en niet voor verassingen komt te staan. Zeker voor SP’s is QoS en inzichtelijkheid naar de klant maar ook naar hun omgeving ten behoeve van capaciteits en performance management.
Overcommitting in je omgeving wil vermijden. Dat kost alleen maar CAPEX en OPEX. Je moet eenvoudig schaalbare storage met voorspelbare performance/capaciteit makkelijk in blokken toevoegen aan je omgeving. Met goeie management tooling kun je zeker ervoor zorgen dat je nooit teveel resources overcommit.
Vwb “dirty cache” ben ik het helemaal met je eens. Daar zou meer mee gedaan moeten worden om dat naar boven te halen.
Zeker interessant YouTube filmpje. Zal me er eens meer in verdiepen. 🙂
@Veron
Als eerste bedankt dat je reageert, wisselen van gedachten aangaande het onderwerp wordt zo eenzijdig als je vanuit huidige kennis redeneert. Want het bepalen van de storage workload is tenslotte niet zo moeilijk als je de logs analyseert om zodoende inzichtelijkheid in de belasting van vandaag te krijgen. Hoe het morgen eruit ziet is dus heel wat lastiger maar laat ik zeggen dat ‘capacity-on-demand’ modellen veelal uit gaan van stilstaande bytes.
Het antwoord is JA, wat is de vraag?
Betreffende je reactie naar Felix wijs ik graag op de wachtrij-theorie van Kendall, het beurtbalkje vergroten draait om de cache welke dus dient te gaan om de interrupt in de vorm van IOPS omdat niet alle data WORM is. Traditioneel denken waar ik dus graag van af wil is de vraag van morgen beantwoorden met de oplossingen van gisteren, reactief cost accounting klinkt als slecht capacity management.
@Verron
“tenzij je een vm per LUN gaat doen”.
Dat is precies wat ik bedoel, al had ik ipv host beter het woord vmguest kunnen gebruiken of expliciet virtuele host. Je wilt tenslotte meten wat een klant verbruikt en die huurt meestal een virtual host.
Maar dank voor je uitgebreide technische toelichting.
maar wel krokodilletranen mbt tot die door cloud beloofde schaalbaarheid en efficiente multitenancy. Het begon al wat met hybrid cloud (ow, public cloud kan toch niet alles), toen kreeg je dedicated vpn’s van klant naar cloudproviders (ow, verbinding ook belangrijk) en nu moet het gebruik van storage weer afgerekend worden (ow, verbruikkosten moeten ook verdeeld worden). Afrekening is natuurlijk voor de klant en die had deze problemen niet die nog zijn eigen ict deed. Zodirect mag de klant ook nog voor zijn security en privacy betalen. Ze krijgen dan een brief die eindigt met een hogere rekening en begint met “om u nog beter van dienst te kunnen zijn”..
🙂
@felix
Ik begrijp je reactie maar deze is onjuist als we kijken naar het gratis bier concept in de cost accounting modellen, of je de logical unit number nu aan het blikje of de tray hangt maakt namelijk nogal verschil. Dat de klant de afrekening problemen niet had toen deze nog single-attended werkte is een dooddoener, om een ‘Rezaatje’ te doen:
https://www.computable.nl/artikel/opinie/cloud_computing/4595637/2333364/het-zorgpremiestelsel-van-de-ict.html
@Ewout voorspelbaarheid brengen aan de klant kant kan tot een bepaalde hoogte door ook met de klant te communiceren of komende projecten/diensten die de klant wil aanbieden aan die van haar. Verder blijft het koffiedik kijken en proberen zoveel mogelijk real time inzicht te geven aan wat de klant echt verbruikt aan cloud resources incl security en compliancy.
@felix ik heb ooit bij een interne sessie van Mendel Rosenblum CTO en mede oprichter van VMware bijgewoond en hij zei :”the journey to cloud are packed with thousands of journeys”. Ben het helemaal eens met wat je zegt. We zijn er nog niet maar doen ons best en we learn along the way 🙂
@felix are=is zijn 🙂