Het probleem van de noisy neighbor was lange tijd een belangrijke reden voor bedrijven om niet voor de public cloud te kiezen wanneer het om bedrijfskritische applicaties ging. Met de komst van full-ssd (solid state drive)-storage wordt het eenvoudiger om dit probleem op te lossen.
Het noisy neighbor-effect ontstaat wanneer een aantal gebruikers op hetzelfde IaaS-platform veel resources gebruiken. Dit fenomeen komt het meest voor in de storagelaag. Hierdoor blijft er (te) weinig capaciteit over voor andere gebruikers en zij ondervinden daarvan allerlei ongemakken, zoals vertraging en foutief wegschrijven van data.
Lange tijd was de noisy neighbor een belangrijk obstakel voor het uitbesteden van bedrijfskritische applicaties naar de publieke cloud. Bedrijfskritische applicaties vragen veelal om veel capaciteit en resources van het IaaS-platform, waardoor het risico op een noisy neighbor toeneemt. Om zich van kwalitatief goede dienstverlening te verzekeren, werden applicaties daarom liever op een dedicated platform geplaatst.
Met de komst van full-ssd-opslag is het gevaar van de noisy neighbor echter veel eenvoudiger te voorkomen. Ik kan dat ook uit eigen ervaring zeggen. Mijn werkgever heeft zijn datacenter opgewaardeerd tot een full-ssd-omgeving en sindsdien zijn er geen performanceproblemen meer geweest als gevolg van een noisy neighbor. Je kan mijns inziens zelfs betogen dat bedrijfskritische applicaties in een full-ssd public cloud tegenwoordig betere prestaties leveren dan in een eigen dedicated omgeving. Zeker wanneer het om kleinere omgevingen gaat. Hamvraag: hoe kan dat?
IOPS en latency
Om te begrijpen waarom ssd een einde maakt aan de noisy neighbor is het goed om te weten waar de performance van storage van afhankelijk is. De twee belangrijkste factoren zijn:
- Iops – Iops staat voor Input/output operations per second. Het zegt iets over hoe vaak een storage device lees- en schrijfacties kan uitvoeren. Hierbij geldt hoe hoger de iops, des te meer lees- en schrijfacties uitgevoerd kunnen worden en des te groter de capaciteit van de opslagapparatuur.
- Latency – Latency zegt iets over de tijd die nodig is om een lees- of schrijfactie te starten. Latency wordt uitgedrukt in milliseconden (ms). Hier geldt: hoe lager, hoe beter.
Zowel voor iops als latency scoort ssd vele malen beter dan de traditionele harde schijf. Een snelle sas-disk blijft steken op 200 iops, terwijl ssd zonder probleem tienduizenden iops aankan. En ook op het gebied van latency presteert ssd vele malen beter dan traditionele harde schijven.
IOPS limiteren met storage tiers
Een populaire oplossing is om het aantal iops per klant of applicatie te beperken, zodat het noisy neighbor-effect niet meer kan optreden. Nadeel daarvan is dat er dan (te) weinig capaciteit per klant beschikbaar is, omdat een sas-disk maar 200 iops kan leveren. Met een storage-array met veel sas-disks is dit probleem wel op te lossen, maar het vergt erg veel disks – en dus hoge kosten – om dezelfde iops-capaciteit te bereiken als ssd.
Doordat ssd veel meer performance biedt, is het limiteren in een full-ssd-omgeving wél een goede oplossing. Storage kan ingedeeld worden in verschillende tiers waarbij het maximaal aantal iops beperkt wordt tot bijvoorbeeld duizend of dertigduizend iops. Het up- of downgraden naar een andere tier is eenvoudig omdat alle tiers op hetzelfde platform draaien. Daardoor kan een gebruiker flexibel up- en downgraden tussen de tiers om bijvoorbeeld te ervaren welke invloed een hogere tier heeft op de performance van een specifieke applicatie.
Ssd-caching is geen oplossing
Geen wonder dus dat IaaS-providers steeds meer gebruik zijn gaan maken van ssd-opslag. Dat is de afgelopen jaren vooral geleidelijk gegaan, aangezien totale vervanging naar ssd kostbaar is. Een populaire keuze die veelal wordt gemaakt als tussenoplossing is ssd-caching. Een bestaand platform wordt daarbij opgewaardeerd met ssd. De ssd-storage wordt enkel ingezet voor data die veel en intensief wordt gebruikt. In theorie is dat een prima oplossing, maar de praktijk leert dat je als organisatie al snel aan de ssd-cachelimieten zit. Op een piekmoment ben je daardoor toch weer afhankelijk van de prestaties van traditionele harde schijven. Ssd-caching helpt wel, maar maakt geen einde aan de noisy neighbor.
Full-ssd IaaS
Met de komst van full-ssd in combinatie met het definiëren van storage tiers zijn de i/o-prestatiebeperkingen van hdd definitief verleden tijd. Sterker nog: de performance die een multitenant full-ssd IaaS-omgeving levert, is door de schaalgrootte vaak nog beter dan een dedicated platform dat maar door één klant gebruikt wordt. Kortom: storage is als gevolg van full-ssd flexibeler geworden en IaaS-serviceproviders kunnen hierdoor betere performancegaranties geven.
Jos, goede onderbouwing, had dat dan opgeschreven.
Ik denk dat je gelijkt hebt met
‘Als de observatie is: “Sinds we geheel op SSD zijn overgegaan merken we niks meer van noisy neighbours” ‘
En dat vanuit die blije beleving deze opinie geschreven is.
Nu weet ik niet vanuit welke ervaring jij spreekt. Misschien zit je op een datacenter van een bedrijf en kom je nog steeds “noisy neighbors” tegen omdat er processen zijn die de performance van een gehele servers omzeep helpen, maar ervaart Pieter sinds de inzet van SSD dat hij praktisch geen klachten meer krijgt van zijn klanten en denkt dat het probleem meteen voor ieder is opgelost.
Dus nogmaals, er zijn meerdere zinnen waarin ik me niet kan vinden en je hebt gelijk met de centrale stelling, maar om de opinie in zijn geheel dan af te doen met onzin vind ik te kort door de bocht.
Ik moet toegeven dat de kop van mijn artikel niet helemaal juist is. De kop trekt wel de aandacht en zorgt voor discussie, en daar is een kop ook voor bedoeld. 😉
SSD zorgt op zich niet voor het einde van het noisy neigbor effect op de storagelaag. De hoge IOPS capaciteit van SSD maakt het echter eenvoudiger om IOPS te verdelen over applicaties/klanten. Door de hoeveelheid IOPS vervolgens per klant te limiteren, voorban je de noisy neighbor.
@Reza: inderdaad, “de cloud” is niet per definitie geschikt om alle applicaties te draaien. Dat kan toch geen verrassing zijn? In de praktijk zijn er nog veel applicaties die een fysieke server nodig hebben of een hybride omgeving.
@Pieter,
Natuurlijk was het al voor me bekend was dat “de cloud” niet per definitie geschikt is om alle applicaties te draaien. Maar ik durf te zeggen dat dit niet voor iedere klant bekend is en ook niet tijdens salestraject toegegeven wordt.
Dit probleem heb ik al in een artikel beschreven (Computable Magazine)
Staat ook op LinkedIn:
https://www.linkedin.com/pulse/migratie-naar-cloud-hoe-pak-je-dit-aan-reza-sarshar
@Reza
Even kijken of ik het begrijp, je stelt een vraag en geeft daar vervolgens zelf het antwoord op. En dan zijn er mensen die beweren dat ik teveel mijn kennis opdring 🙂
@Henri
Hier wordt volgens mij geschreven over hyperconverged oplossingen als Nutanix/Tintri en anderen, ik vermoed dat de auteur het over Tintri heeft gezien zijn woordkeuzen. Voor je Python specialist: https://github.com/Tintri/tintri-api-examples
Oja, als je python specialist snel uitgekeken is op Tintri: https://github.com/Infinidat
Pieter,
Wat bedoel je met :
“SSD zorgt op zich niet voor het einde van het noisy neigbor effect op de storagelaag. De hoge IOPS capaciteit van SSD maakt het echter eenvoudiger om IOPS te verdelen over applicaties/klanten. Door de hoeveelheid IOPS vervolgens per klant te limiteren, voorban je de noisy neighbor”
Alleen naar IOPS kijken is ietwat kort door de bocht.
Performance is meer dan IOPS alleen en wordt opgebouwd op basis van verschillende karakterstieken zoals block sizes, r/w verhouding, dataskew, IOPS en latency etc. etc. Alleen naar IOPS kijken levert vaak teleurstellingen op.
Juist dat laatste (latency) is van groot belang. En hier heeft SSD een grote invloed op. Ik zie zoals Henri al perfect aangeeft steeds meer SSD door de markt geadopteerd worden. Alleen is het nog te vaak nog appels met peren vergelijken. Er zit een wezenlijk verschil tussen SLC’s, MLC’s en TLC’s. Dat merk je ook wel bij de verschillende cloud aanbieders. Niet iedereen biedt een “enterprise waardige” oplossing aan.
En noisy neighbours kan je op de storagelaag voorkomen door schuttingen te plaatsen (lees QoS).
@Ruud
Conculega, IOPS is vooral een marketingterm die uitgaat van de beste blocksize want ook SSD heeft zijn beperking. Betreffende je opmerkingen over ‘bunrate’ van SSD neem ik aan dat je als afnemer daarover geen zorgen hebt, kijkend naar de specificaties van Tintri zit er genoeg ‘snijverlies’ in de box.
Nu weet je dat ik helemaal ‘geil’ werd van ViPR SRM, het proactief capaciteitsmanagement door niet uit te gaan van de aannames maar keiharde feiten verkregen uit de infrastructuur zelf. Metrics, damn metrics!
Even opletten Bart Veldhuis want ik refereer naar de CDB binnen ITIL die een steeds grotere rol binnen cloud oplossingen gaat spelen zoals ik al schreef in de opinie Zorgpremiestelsel van de ICT. Normaliseren van het beheer is dus de sleutel van de cloud, als ‘cloud watcher’ benchmark ik al enige tijd de markt want uiteindelijk gaat het om een landingsplatform waar de landingsrechten bepalend zijn voor de keuze.
QoS is dus te beperkt als je uiteindelijk alleen maar een paar meerkeuzen antwoorden hebt binnen het portfolio van de provider, als de kwaliteit gelijk is dan gaat het altijd weer om de prijs. Hollandse wolken zijn opmerkelijk vaak de impressie van oude meesters;-)
Mr Dekkinga,
Wij gebruiken enterprise waardige SSD’s. Dus ik ben daar allesbehalve bang voor 😉
En ja SRM is erg leuk en zeer handig. Zeker voor service/hosting/cloud providers. Dank voor de voorzet.
En QoS kan ook dynamisch en op een intelligente wijze bij sommige leveranciers.
Meneer Mulder (voorheen Ruud),
QoS over meerdere providers heet volgens mij ‘cloud bursting’ en vraagt in eerste instantie een overkoepelend ecosysteem, het normaliseren van je beheer zoals DMTF ook stelt:
http://www.dmtf.org/sites/default/files/standards/documents/DSP-IS0102_1.0.0.pdf
Dat was de primaire reden dat ik in een oplossing zoals SRM geïnteresseerd was omdat het meer een SDK dan een applicatie is, weliswaar niet met de makkelijkste leercurve maar wel flexibel door een ‘loosly coupled’ datamodel.
Noem het mijn liefde voor reversed engineering, het bood de mogelijkheden maar nog geen wonderen en of het geschikt is voor providers is afhankelijk van de aanwezige kennis omdat het nog wel enig ‘programmeerwerk’ vraagt.