Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

SSD betekent het einde van de noisy neighbor

 

Computable Expert

Pieter de Haer
Marketing & Productmanager, Previder. Expert van Computable voor de topics Cloud Computing, Datacenters en Beheer.

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. 

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5599923). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

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 :-P
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.







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.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×