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.
Er zijn toch meer mogelijkheden waarop neighbours noisy kunnen zijn? Dat kan ook bijvoorbeeld in de CPU’s of het netwerk liggen, om maar eens iets anders te noemen waarbij je in elkaars vaarwater kan zitten. Afhankelijk hoe je hardware gebruikt en verdeelt natuurlijk.
Ik vind de prijs / GB nog vrij hoog.
En laat het ook maar aan de enorme hoeveelheid IaaS aanbieders over om te besparen op andere dingen of om de verkeerde oplossing te kiezen.
Typisch. Eerst dee je zelf hosting en had je geen neighbors. Nu moet je perse hip in de cloud. Je resources delen met je buren, anders is het weer niet efficient en dus niet goedkoper.
Voorgestelde oplossing is SSD in de Cloud, hele artikel over de techniche details, terwijl de clou van cloud juist is dat je die details niet hoeft te weten 😛
Straks ook een dedicated verbinding naar je provider..
Stop die SSD gewoon in je eigen server.
In het kort, en sprekende uit ruime ervaring: Onzin.
@Jos, lekker kort door de bocht en daarmee is jouw reactie onzin.
Hier zijn mijn centen over het onderwerp.
Het is ontegenzeggelijk dat zeer veel problemen met betrekking tot storage en performance worden gemitigeerd c.q. opgelost door SSD. Punt.
Dat een aantal van die buren problemen te maken hebben met magnetische discs kan ik me best voorstellen en spreek ik niet per se tegen.
Mijn ervaring met “slechte buren” had vaak te maken met de virtualisatie laag en met name ogenschijnlijk CPU gebruik. Alleen kun je dat niet altijd vaststellen als je alleen maar een virtuele server hebt en geen toegang tot de laag (hypervisor) erboven. bij mij uitte het vooral in database query’s die ineens trager werden.
Dit kun je op drie manieren oplossen:
– Neem dedicated hardware af, je betaald wat meer maar krijgt dan wel de gehele resource, dit is in mijn ogen de mindere keuze
– Zorg ervoor dat jouw vm terminate en op andere hardware terug komt, dit is de minste keuze
– Zorg ervoor dat je software “cloud native” is en gebaseerd is op scale out en dus over meerder hardware draait. Dat is de beste keuze.
Maar goed, de laatste tijd kom ik het probleem nauwelijks meer tegen en misschien komt dat inderdaad door de brede inzet van SSD.
Je kunt het niet met dit artikel eens zijn, maar er staat in mijn ogen zeker geen onzin in. Hooguit slechts een deel van het verhaal.
@Pieter
Eigenwijs als ik ben denk ik dat je exact het tegenovergestelde gaat behalen wat je beoogd te bereiken. De reden hiervoor is niet technisch maar economisch als ik overweeg dat een provider door hetzelfde investeringsdal heen moet als elke andere organisatie. Een all flash array (AFA) is namelijk een placebo als we kijken naar SDS, mogelijk dat je dit bedoeld want uiteindelijk ga je in op storage tiering waarbij flash gewoon als cache gebruikt wordt.
En dan wordt verhaal anders want veelal blijken dit soort oplossingen moeite te hebben met seriële schrijfacties, naast IOPS is de doorvoer interessant en blijken veel hyperconverged oplossingen opeens problemen met de bussen te hebben.
@Louis
Denk dat de CPU’s niet het probleem zijn, dit natuurlijk afhankelijk van de southbridge want zoals ik als stelde ligt de uitdaging in de bussen.
@Felix
Natuurlijk kun je de SSD in eigen servert stoppen maar deze is tegenwoordig vaak virtueel, het hoeven niet altijd de buren te zijn want je eigen familie kan ook al voor een vertraging zorgen. De analogie van bonnetje in mijn voorgaande opinie kan ook een agile team zijn die plotseling 40+ servers opstart.
En dan staat Pieter opeens in zijn hemd want de kleren van de keizer blijken dan opeens geweven te zijn met gefantaseerde draden. Er is ook nog zoiets als een SAN wat dus ook een netwerk is, dedicated verbinding van een LUN blijkt vaak een bottleneck te zijn.
@Henri Koppen:
De titel van het verhaal, en daarmee de belangrijkste stelling, is: “SSD betekent het einde van de noisy neighbor”
Die stelling is onzin, want, zoals diverse andere reaguurders reeds (gedeeltelijk) hebben aangegeven:
– Disk access is niet de enige oorzaak van ongewenste interferentie bij het mengen van mixen van workloads op een machine. Zelfs als SSD helemaal nul komma nul last van interferentie zou hebben dan zou een SSD omgeving dus niet het einde betekenen van het probleem.
– SSDs hebben wel heftig veel iopsen, maar het is niet ongelimiteerd, en afhankelijk van de workload kun je dus wel degelijk nog last hebben van je buren.
Als de stelling zou zijn: “Met SSD heb je door de bank genomen veel en veel minder last van noisy neghbours” dan ben ik het er geheel mee eens.
Als de observatie is: “Sinds we geheel op SSD zijn overgegaan merken we niks meer van noisy neighbours” dan zeg ik: Goed mogelijk, en lucky you!
In de omgevingen waar ik zelf over ga (of mee te maken heb) waar we op SSD zijn overgegaan is het leven inderdaad ook veel beter geworden, maar om nou te zeggen dat SSD het einde van noisy neighbours betekende, nee.
@Henri
ONZIN!
Kan me een case (eigenlijk meerdere) herinneren waarin de stripe van (NL)SAS de oplossing bood voor prestatieproblemen, was 40% goedkoper en gaf 300% betere density waardoor de business case in 3 maanden terugverdiend was.
Waarschijnlijk ken je niet de blades, ik wel als ik kijk naar de doorvoer van de gedeelde bus hierbij. Natuurlijk kun je (even opletten Capgemini) keihard de feiten blijven ontkennen maar als ik tijdens een performance test al op 1/3 de bus dichtblaas dan heb je een probleem.
Meten is weten, met SSD heb je namelijk helemaal niet minder last van rumoerige buren als we kijken naar de Theory of Contraints. Nu ben ik natuurlijk gekke Henkie en komt het busje zo maar IOPS is een nietszeggend getal.
Als je niet de blocksize opgeeft, het overdragende protocol en of het om een random lees- of seriële schrijfactie gaat dan mis je de DATAKARAKTERISTIEKEN, veelal bepalend Henri als we overwegen dat opslag de systeemprestaties bepaald.
Oja, waarom komen de meeste organisaties niet verder dan een hybride cloud?
Maar Pieter……..betekent dat in tegenstelling tot wat leveranciers zeggen de cloud is/was nog niet klaar voor de klant(applicaties) OF ik ben/was als de klant nog niet geschikt ben voor de cloud?
Nog meer verrassingen uit de hemel?
@Reza
WORTELEN!!
Laten we aan de kalkoen vragen wat we met kerst moeten gaan eten, de retorische vraag krijgt een voor de hand liggend antwoord als je nog steeds niet begrijpt dat tussen IaaS en een provider enig verschil zit. Als je wat minder met jezelf bezig zou zijn dan had je kunnen lezen dat ik hier een jaar of 2 geleden al wat over schreef.
Kan me nog herinneren dat ik tijdens een sessie bij Centric een grafiek toonde aangaande IaaS (lees virtualisatie) betreffende de I/O versus CPU bound workloads. Na meer dan 70 assessments aangaande datakarakteristieken kan ik je wel vertellen wat wel en wat niet goed werkt op basis van een simpele opdeling op basis van de toegangsmethodiek.
Om het simpel voor je te maken, je kunt de toegang tot de informatiedragers abstraheren maar het medium zelf niet. Of je het eigenaarschap hiervan vervreemd door je geluk te zoeken bij een provider is geen technische maar een economische vraag.