Computerkracht blijft nog steeds toenemen. De wet van Moore blijft onverminderd gelden. Storage begint nu echter achter te lopen. We kunnen ongelooflijk snel berekeningen maken of data verwerken, maar lezen en wegschrijven begint de bottleneck te worden. Dat komt omdat harde schijven de afgelopen jaren niet sneller zijn geworden.
Sommige partijen lossen dit op door solid state disks (ssd’s) in te zetten. Vanuit performance-overweging zou je deze het liefst zo dicht mogelijk bij de rekenkracht plaatsen. Zolang storage direct op het moederbord aangesloten is, beschik je over maximale prestaties. Google en Amazon doen dit in hun datacenters: alles in een pizzadoos en alle pizzadozen in een rack. Een ideale situatie, die echter voor de meeste bedrijven niet haalbaar is, omdat hun software daar niet voor geschreven is.
Voor deze bedrijven wordt ssd ingezet in storage-arrays en deze zien we in twee smaken. De traditionele storage-arrays die ssd inzetten voor storage-tiering en de All Flash-arrays. Deze laatste zijn enorm in opkomst. Naast de nieuwe vendors die de afgelopen paar jaar deze markt hebben betreden, zoals Pure Storage, Skyera en Violin komen alle grote storage-vendors zoals EMC, Netapp en IBM nu ook met een eigen All Flash-array. Daarnaast heeft ook Cisco deze arena betreden met de overname van Whiptail.
Flash-geheugen in ssd’s is weliswaar sneller dan disk, maar heeft ook zijn beperkingen. Er is een groot verschil tussen read en write. Ssd geeft een enorme leesperformance, maar blinkt niet uit in schrijfperformance. Dit komt onder andere doordat sectoren op een ssd eerst gewist moeten worden voor er naar geschreven kan worden.
Om toch tot een goede schrijfperformance te komen, wordt er door veel vendors gebruik gemaakt van zogenaamde garbage collection. Dit is het preventief wissen en vrijmaken van schrijfruimte als achtergrondproces. Daarnaast zetten veel vendors in op deduplicatie en compressie, waardoor er veel minder geschreven hoeft te worden.
Overigens speelt ook mee dat ssd nog steeds duurder is dan disk, waarbij prijzen overigens wel blijven dalen. Compressie en deduplicatie zorgen ervoor dat in 2014 ssd zeer concurrend ten opzichte van disk storage kan worden ingezet. Zeker waar het gaat om performanceoplossingen. Voor grootschalige opslag zijn sata-disks nog steeds de logische keuze. Daarnaast is tape – in tegenstelling tot wat lange tijd is beweerd – zeker nog niet dood als je kijkt naar performance van sequentiele read en write en prijsniveau. Tape, disk en flash hebben elk hun eigen kenmerken en voordelen.
Ik verwacht dat in 2014 het marktaandeel van de All Flash-arrays flink zal groeien doordat deze breed zullen worden ingezet voor virtuele machines en vdi. Het opheffen van de bottleneck op storage zal ook een hogere bezettingsgraad van het aantal virtuele machines per cpu ten gevolge hebben. Een andere aanjager van ssd is dat het een hele groene oplossing is. All Flash-arrays verbruiken vaak een fractie van de energie die de traditionele oplossingen vragen.
Aardig artikel maar…. wederom met een commerciele inslag geschreven. Natuurlijk heb je te maken met bottlenecks maar die bottlenecks liggen net zo eenvoudig buiten jouw bereik.
Je kunt in datacenters natuurlijk wel uit gaan rusten met allerhande ‘flash’ omdat…. maar u vergeet even dat 80% van alle data waarschijnlijk geen consequente data is die je ergens voor zou kunnen gebruiken.
Commercie promoot alles
Alles waar men een stokbroodje of zacht kadetje in ziet. Men is organisatorisch steeds minder bij machte zelf de IT broek op te houden en dat brengt een veel reëler gevaar met zich mee. Dat organisaties wel eens gevaarlijk ernstig afhankelijk worden van externe IT diensten leveranciers. Dan krijg je een keer een kantelpunt dat je zelfs die dienst niet meer op juiste merite weet te beschouwen of wegen omdat…
Voor verreweg de meeste bedrijven zal het volkomen worst zijn wat de techniek is die een cloudhoster achter de deur gebruikt. Het enige wat de klant wenst is dat data zo snel mogelijk bereikbaar is en blijft.
Dan heb je nog eens als afnemer/gebruiker meer en vaker te maken met bottlenecks dan de cloudhoster. Ik vind dat geen echt argument. Het gaat pas echt iets uitmaken wanneer de gehele infrastructuur naar hetzelfde niveau kan worden getild en we weten dat dat utopia is.
De werkelijke bottleneck? De snelheid van lezen en typen en de attentie span die een potentiële klant heeft een artikel of webpagina te bekijken. Of de provider die uiteindelijk het E2E draadje verbind maar zo vaak de snelheid remt.
Dan kun je flash implementeren wat je wilt natuurlijk. Voor veel bedrijven zal het cloudverhaal niet eens op gaan.
Fact of life.
John,
De wet van Moore lijkt me enige update nodig te hebben nu processoren opgedeeld worden in cores want snelheid is hier niet de som der delen. En verder is verwerking en opslag gescheiden waardoor steeds vaker het netwerk bepalend wordt, all flash-arrays zitten tenslotte niet in iPads e.d.
Naast de snelheid wordt dan ook capaciteit steeds vaker een uitdaging omdat ongestructureerde data in rekencentrum toeneemt doordat genoemde iPads niet alleen SSD hebben maar ook nieuwe functionaliteit.
In de discussies over flash komt steeds vaker deze catch-22 naar voren, je hoeft ook geen rekenwonder te zijn om te begrijpen dat €0,05/GB voor SATA schril af steekt tegen de €0,80/GB van SSD. De vraag is dus waar nu precies de dure snelheid nodig is en waar goedkope capaciteit want all-flash voor VDI lijkt me een beetje de ‘man met helm zoekt vrouw met motor’ oplossing.
Effectief misschien maar niet efficient en dus lijkt het me handig om eerst te kijken waar snelheid voordeel biedt door classificatie te doen. Vaak scheelt dat ook enorm in de capaciteit omdat praktijk leert dat dingen nog weleens dubbel of vaker opgeslagen worden of dat eerdere keus nog niet optimaal gebruikt wordt.
Zo is het bijvoorbeeld handig om logfiles niet op flash te plaatsen maar wordt dit in de praktijk nog vaak gedaan omdat niet alleen kennis over opslag verloren is gegaan maar ook die over databases. Maar terug naar de wet van Moore, de ToC stelt dat je geen geld moet besteden aan dingen die geen waarde hebben.
Snelle disks en processoren maar een traag netwerk zullen dan ook niet echt helpen. En inderdaad kan deduplicatie en compressie hierbij helpen als dat client-side gedaan wordt maar je raad het waarschijnlijk al, dit wordt dus weer vaak net aan de verkeerde kant van de lijn gedaan.
John, het beleid van Google en Amazon is op Windows Server 2012 en 2012R2 al twee jaar standaard. Verder kun je sinds kort in 2012R2 iedere SSD als cache instellen voor iedere diskpartitie of raid-set. Overigens werkt disk-i/o van server naar server beter dan board-attached disks. In SMB 3.0 van 2012 Server is die keten van disk tot disk geoptimaliseerd. Vaak gaat het bij het mkb om een redundante opstelling van 2 servers met ieder 512GB tot 1,5TB aan ram met 40 tot 120TB per server aan Sata met 3 tot 6 channels van 6Gbit/s ieder. Met een 2 x 10Gbit kaartje van 600 dollar of met Infiniband kun je dan een cross van 20 Gbit/s maken. Met SMB-multichannel kun je voor de meeste bestanden als 1300 tot 1600 Megabyte per seconde van server naar server halen (mits je UPS hebt en dubbele voeding zodat je de write-flush op beide servers uit kunt zetten). Welke applicaties zijn daar overigens ongeschikt voor?
Het belangrijkste is overigens dat dataverkeer van server naar server op die manier ook vaak automatisch kortgesloten kan worden, dus van bron naar bestemming zonder dat het langs de hypervisor of virtuele server gaat die het geïnstigeerd heeft (bijvoorbeeld met een 10Gbit/s uplink naar een switch). Alleen op dat punt heeft SAN nog een minimaal voordeel in vergelijking tot standaard hardware (heet ODX uit mijn hoofd).
Met een 8 of 24 poort 10Gbit-switch kun je een dergelijke twee-server opstelling perfect opschalen naar een Multi-server omgeving. Redundante verbindingen ’trunken’ daarbij automatisch op de bovenste laag met MultiChannel.
Zoals gewoonlijk doen de belangrijkste ontwikkelingen op dit gebied zich op ‘het’ MKB-mainstream platform voor kantoorautomatisering voor (Windows Server). Niet op alle fancy/niche-san ellende waar non-profit zoals onderwijs en overheid hun kwade geld het liefst aan wegsmijten. Vreemd dat je de ontwikkelingen in Windows Server op dit vlak in het artikel volledig buiten beschouwing laat. Die zijn niet alleen voor de gemiddelde computable lezer veruit het belangrijkst, maar ook voor de allergrootste cloud-providers zoals Amazon en Microsoft. Deduplicatie en compressie moet je m.i. buiten deze discussie laten.
John,
SSD is duurder dan de reguliere HD’s als je alleen maar naar opslagcapaciteit kijkt. Maar ja dit is juist de fout die bijna
iedereen maakt. Storage is meer dan opslagcapaciteit alleen. Performance wordt steeds belangrijker en juist op dat gebied levert
een SSD/flash disk een gigantische verbetering op basis van performance. Namelijk tussen de 3500 en 5000 iops ( afhankelijk van
type SSD ) versus de 180 iops SAS 15k, 140 iops SAS 10k en 90 iops NL-SAS/SATA. Ik deel wel je bevinding dat de read performance
van een SSD hoger is dan de write performance. Echter wordt ook op dit gebied redelijk veel progressie gemaakt.
Ook hier geldt weer meten is weten. Kijk eerst wat de load is van de huidige omgeving en als deze info niet aanwezig is,
(bijvoorbeeld bij een greenfield) werk dan op basis de geldende best practices. Het is van cruciaal belang om de juiste read/write
verhouding te weten. Pas dan kan de juiste technologie er bij gezocht worden.
Ik zal hier in mijn nieuwe opinie stuk nog verder op in gaan.
Flashgeheugen een duidelijk een grote toekomst en dat komt doordat traditionele storage als jaren een bottleneck is in de totale infrastructuur. Op die plaatsen waar IOPS een rol spelen, in VDI omgevingen, transactie omgevingen, big data en vele andere omgevingen is storage een bottleneck die alleen maar met heel veel traditionele disken op performance kan worden gebracht. Je hebt dan al gauw vele tientallen terabytes aan opslag, maar nauwelijks bezetting. Als je kijkt naar de reken voorbeelden dan heb je al gauw 10 schijven nodig van zeg 300 GB op de performance van een SSD schijf te benaderen, ervan uitgaande dat de controller die ertussen zit transparant is en geen vertraging toevoegt. Dan ontstaat er al gauw een business case op data die snel toegankelijk moet zijn ook snel toegankelijk te maken en data die minder snel toegankelijk moet zijn op traditionele schijven te plaatsen.
Afgelopen jaar zijn deze oplossingen volwassen geworden en zullen de komende jaren worden ingezet.
SSd heeft zijn nadelen in levensduur, maar mijn ervaring is dat traditionele schijven na 2-3 jaar volop moeten worden vervangen.
Het is eigenlijk te gek voor worden dat we nog een soort van grammofoonplaat techniek gebruiken voor de opslag van data anno 2014? SSD zal dus een vlucht nemen en de opvolgers MRAM en RRAM gaan zorgen voor de volgende evolutie.
Willem,
De levensduur is sterkt verbeterd. En SSD is uitermate geschikt voor read intensieve omgevingen. Dus zolang je het goed inzet is het zeker niet veel slechter dan de reguliere HD’s.
Zie onderstaand wat ik al een keer eerder geschreven heb:
Van belang bij de Flash zijn de PE Cycle ( program-erase cycle ) en MTBF ( Meantime between failure )
Wat valt er onder een PE Cycle:
Reads = Geen PE Cycle
Writing = PE Cycle
Deleting = PE Cycle
Vergelijk appels met appels. Er zijn te veel verschillende smaken flash op de markt die het er niet overzichtelijker maken. Probeer daarom appels met appels te vergelijken. E-MLC / SLC zie je terug in de enterprise oplossingen en On chip flash en MLC zijn leuk voor thuis.
Praktijkvoorbeelden max PE Cycles (PE Cycle = solid-state-storage program-erase cycle )
On chip flash = 100
MLC = 1500 tot 10.000 ( zeer veel differentatie / verschilt per leverancier/type )
E-MLC = 30.000
SLC = 100.000
Alles gaat op basis van PE Cycles per block. Dat laatste is van groot belang. En geeft vaak een vertekend beeld.
Meantime between failure. Ook dit verschilt per type HD en SSD. Onderstaand heb ik de praktijkvoorbeelden weergegeven:
MTBF
HD = 500.000 / 750.000
SSD = 1.500.000 tot 2.000.000
Net als bij de gewone HD’s is het in de enterprise storage oplossingen aan te raden om gebruik te maken van RAID. Ondanks er in flash geen rond draaiende componenten zitten gaat ook flash opslag een keer stuk.
Willem,
De MTBF waarde van een SSD ligt dus hoger dan bij de reguliere HD. Alleen worden er te vaak appels met peren vergelijken.
SSD /Flash moet je natuurlijk wel inzetten waar het goed in is. Veel schrijf intensieve acties (PE cycles) zullen een negatieve invloed op de levensduur hebben.
Je gaat ook niet met een F1 auto iedere dag in de file op de A4 staan.
John,
Ik was benieuwd naar je reactie op deze posts hierboven!
Leuk en aardig dit SSD/Flash-verhaal. Ik denk dat het handiger is als je naar verschillende componenten in de architectuur kijkt. Lekker dat je VDI omgeving snelle R/W heeft maar daar heb je niks aan als een applicatie moet wachten op input uit een databaseserver die traag werkt. Of een (fysieke/virtuele)netwerkkaart of een port op je switch die niet genoeg throughput heeft waardoor het inloggen op VDI desktop of het benaderen van een object op je (file/mail/database)server veel tijd in beslag neemt.
Kortom, heb je het over het verbeteren van (vdi)performance dan zou je verder moeten kijken dan alleen wat er in je san zit!
Reza,
Helemaal mee eens. De gehele keten is van belang.
Storage, servers, netwerk en de applicatielaag kunnen niet los van elkaar gezien worden.
Hier geldt ook weer meten is weten.
Heerlijk de discussies over cijfers maar laten we niet vergeten dat het statistieken zijn, je kunt de pech hebben om de maandagmorgen batch te krijgen waardoor MTBF cijfers veel minder gunstig zijn. En nu we het toch over cijfers hebben, 4KB blokken geeft volgens mij andere IOPS waarden dan 128KB blokken, tenminste voor draaiende schijven. En leuk dat we met multiplexing een grote doorvoer hebben maar volgens mij hebben file based protocollen zoals SMB/CIFS nog altijd het euvel dat als de file gebruikt wordt deze gelocked is en dan niet verplaatst mag worden. En ODX klinkt toch een beetje als de Microsoft implementatie van NDMP waarmee je ‘hostless’ een kopie kan maken tussen storagearrays maar daardoor weer de dubbele capaciteit nodig hebt.
Storage is dus blijkbaar nog altijd ’tweaking and tuning’ en toch niet de ‘one-size-fits-all’ oplossing en NumoQuest heeft dan ook gelijk, een klein beetje want als afnemer niet weet wat hij wil of nodig heeft dan blijft het natuurlijk balanceren. En voordat hij over zijn wetmatigheden begint het gaat hier dus om BLIJVEN meten. Of om Ruud aan te vullen, gissen blijft missen aangezien vanuit projecten vaak alleen de benodigde capaciteit aangegeven wordt en niet de gewenste prestatie.
Maar misschien nog wel belangrijker is de uiteindelijke response bij de (veeleisende) gebruiker omdat het inderdaad om een keten gaat. Jammer dat auteur zich trouwens niet in de discussie mengt want ik zou weleens willen weten hoe het opheffen van de storage bottleneck tot een hogere bezettingsgraad van de CPU leidt aangezien er nog wel andere beperkende factoren zijn, bijvoorbeeld slecht geschreven applicaties of databases.