Sun komt met flash-array die een miljoen iops haalt

Sun brengt over twee weken de F5100 op de markt: een opslagarray in een 1U-behuizing op basis van door Sun zelf ontwikkelde flash-modules. De F5100 biedt een miljoen iops en op den duur een maximale opslagcapaciteit van 4 terabyte.

De verwachting is dat Sun de F5100 op 15 september gaat introduceren. De F5100 Flash Array kan 80 door Sun zelf ontwikkelde modules met slc-geheugen bevatten. De arrays die Sun in eerste instantie zal uitbrengen, bieden een maximale capaciteit van 1,92TB, en deze bevatten dan ook dimm-modules van 24GB. De dram-buffergrootte van de modules is 64MB en ze zijn voorzien van een sata 3Gbps-interface.

In een later stadium zouden er ook modellen met 48GB-modules uit moeten komen, wat de opslagcapaciteit tot 4TB zou uitbreiden. De modules zijn overigens op de so-dimm-formfactor voor notebooks gebaseerd, wat Sun in staat stelde plek te bieden aan een zo groot mogelijk aantal flashmodules.

De F5100 zou een miljoen iops en een doorvoersnelheid van 10GB/s bieden, terwijl er 16 sas-poorten met elk 4 lanes ter beschikking staan, wat het totaal op 64 sas-kanalen brengt. De fans zijn redundant en de stroomvoorziening, met twee psu's van 720W, is dat ook. Onbekend is nog wat de prijs van de F5100 gaat worden.

Reacties (83)

[Faust]

Over 'de te grote voeding'; dat is logisch. 720W zou enkel onder full load verbruikt worden, maar de array zit daar altijd onder.

Zoals jullie weten neemt met de ouderdom van een voeding ook de efficiëntie af.
Op een gegeven moment kan de voeding mogelijk niet meer genoeg leveren om de oorspronkelijke array aan te drijven. Om dat moment zo ver mogelijk uit te stellen; helpt het om een grotere voeding te nemen.

Kijk naar een recent voorbeeld; de ps3 slim. Deze heeft een 250watt voeding aan boord, en toch blijkt de maximale belasting amper 100 watt te halen.
Als ze er een 100 watt voeding in gestopt hadden, dan zou na 2 jaar mogelijk de voeding stuk gaan (of eerder/later, was maar een voorbeeld). Op deze manier heeft het geheel een langere levensduur.

[Mellow Jack]

Zoals jullie weten neemt met de ouderdom van een voeding ook de efficiëntie af.
Op een gegeven moment kan de voeding mogelijk niet meer genoeg leveren om de oorspronkelijke array aan te drijven. Om dat moment zo ver mogelijk uit te stellen; helpt het om een grotere voeding te nemen

Dat valt redelijk mee hoor... Het is echt niet zo dat het gehalveerd wordt na 2 jaar ofzo dat is echt complete onzin... Ik draai 4 servers (wel meer natuurlijk maar dit voor het voorbeeld) met 2 300 watt voedingen en die draaien nu al 4 jaar 24/7 waarvan 1 voeding natuurlijk als reserve gebruikt wordt bij uitval. Ze trekken gemiddeld 250 watt

Ik heb in 4 jaar tijd maar 1 voeding moeten vervangen omdat hij kapot is gegaan door een hikje in de stroom voorziening

[Reactie gewijzigd door Mellow Jack op 23 juli 2024 11:19]

[Fiander]

Verder zitten er 4 "energy save" modules in, wat ik vrij vertaal naar batterijen / UPS om bij stroom uitval de data die nog in de ram cache zit niet verloren te laten gaan.

Als de batterijen ietsjes leeg zijn, zal ook de laad stroom uit een voeding moeten kunnen komen.

[Grimm79]

Leuke marketing 1 mio iops en 1,92 TB capaciteit over 80 * 24 Gb modules.
Echter niet geheel reëel...
Dit houd in dat bij uitval van 1 van deze vrolijke modules je potentieel 1,92 TB aan data kwijt bent.... ik dacht het niet.
Er zal een parity contructie aanwezig zijn welke dit moet ondervangen, een RAID5 of RAID10 achtige oplossing light het meest voor de hand.

Met RAID 10 verlies je echter de helft aan capaciteit en blijft er nog geen 1 TB over, performance zal wel top zijn maar zeker geen 1 miljoen IOPS, voor de lees IOPS ondervind je geen penalty echter voor een schrijf opdracht heb je dit wel, namelijk 2.
Afhankelijk van de lees schrijf verhoudingen komt er dan al een heel ander plaatje uit. De leesschrijf verhouding hangt normaal rond de 70% reads en 30% writes, wanneer we in theorie 1 miljoen IOS kunnen afhandelen zal hier 30% voor write acties ingezet worden.

70% read
30% write

Stel dat 10 IO acties 100% zijn dan zullen er bij een 70/30 verhouding
7 reads= 7 io op disk & 3 writes= 6 io op disk zijn, totaal 13 io's plaatsvinden wanneer dit doorgetroken wordt naar de theoretisch 1 miljoen IO's van de SUN oplossing dan geld het volgende
Maximaal aantal IO's SUN 1.000.000/13 = 76923,08 (afgerond, dit zal de omreken factor zijn)
maximale read io's 7 * 76923,08 = 538461,56 IO's
maximale write io's 3 * 76923,08 = 230769,24 IO's
nog steeds erg netjes, de helft capaciteits verlies en ongeveer 24% IO performance verlies. Echter zijn dit soort loads op minder dan 1 TB aan data zeer onwaarschijnlijk en lijkt het me ook niet dat de oplossing als primaire opslag dienst zal gaan doen.

Rekenen we dit door naar RAID5 met een gelijke read write verhouding van 70/30 dan komt hier het volgende uit, write penalty voor RAID 5 bedraagt 4.
Stel dat 10 IO acties 100% zijn dan zullen er bij een 70/30 verhouding
7 reads= 7 io op disk & 3 writes= 12 io op disk zijn, totaal 19 io's.
Maximaal aantal IO's SUN 1.000.000/19 = 52631,58 (afgerond, dit zal de omreken factor zijn)
maximale read io's 7 * 52631,58 = 368421,06 IO's
maximale write io's 3 * 52631,58 = 157894,74 IO's
Ongeveer 5% capaciteits verlies wanneer per kanaal een RAID5 set opgebouwed wordt (1,82 TB over) en er blijft bruikbaar ongeveer 51% van de 1 miljoen marketing IO's over ;-)
Wederom geen realistisch scenario voor primaire opslag.

Dit apparaat zal ingezet worden als een uitgebreid caching mechanisme voor meer klassieke storage en enkel ingezet worden voor de meest IO intensieve applicaties. (VMWare, of VDI zijn hier geen goede voorbeelden van btw deze toepassingen zijn veel meer cpu en memory intensief en niet zozeer afhankelijk van disk IO's... je moet het meer zoeken in zeer zware databases, financiele sector (beurs) waar tijd echt veel geld betekent bijvoorbeeld).
De SAS koppelingen zullen dan ook dienen om hier servers of klasieke storage aan te koppelen.

Dit zal hoe dan ook een niche oplossing blijven zolang de opslag capaciteit van deze oplossingzo beperkt blijft. De gemiddelde DB server is dan eenvoudiger uit te rusten met veel intern geheugen en op deze manier je DB in memory te laden als wanneer deze oplossing ingezet zal worden.

Anderzijds denk ik dat het prijskaartje zwaar onderschat wordt. SUN is sowieso geen goedkope club (hoeft ook niet) en dit soort technology is bleeding edge. ik verwacht dat deze oplossing zeker 100-200k list zal gaan kosten als het al niet meer is.

(neemt niet weg dat ik mijn intel SSD hier graag voor om zou willen ruilen )

[flowerp]

Afhankelijk van de lees schrijf verhoudingen komt er dan al een heel ander plaatje uit.

Natuurlijk. De standaard is meestal dat opgegeven IOPS, de read IOPS voor 4KB block size. Kijk je naar andere block sizes of inderdaad naar write IOPS (of een mix), dan wordt het inderdaad een totaal ander plaatje.

Maar ja, dat kun je niet mooi in 1 spec getal vangen. De liefhebber kijkt dus naar de performance curves (iops tegen block size) voor zowel pure read, pure writes en enkele standaard mixes (80/20 en 70/30).

Ik vraag me wel af hoe je 1 miljoen IOPS naar 1 server krijgt (denk aan bussen en chipsets op die server).

[MSalters]

De redelijke oplossing voor zo'n systeem is RAID-Z; dit is tenslotte een Sun Storage product. Dus je berekeningen zijn eigenlijk niet zo relevant; RAID-Z is een stuk slimmer dan de genummerde RAID nivo's

[TGEN]

Hmm, dit lijkt op battery-backed DRAM zoals de TMS RAMSANs. Anders zie ik het nut niet voor "Energy Storage Modules" van die grootte.

[siepeltjuh]

Het zijn gewone hardstikke normale SSD 'schijven' met een cache van 64mb. Echter niet in een 2,5inch behuizing zoals we gewend zijn, maar met een SODIMM 'behuizing' en connector.

De keuze voor SODIMM vind ik wat gek, het is verwarrend en er zijn naar mijn idee veel efficientere mogelijkheden. De hardware is immers al specifiek voor dit apparaat, er is niets anders wat ssd op deze manier gebruikt, dus het zou ook anders kunnen.

Er is omdat er gebruik wordt gemaakt van normaal flash geen noodzaak voor batterij backup.

Wat mij opvalt is dat als je een gewone 1u behuizing pakt, daar gewone normale 2,5inch plekken in maakt je ook wel een stuk of 50 schijfjes in kwijt kan. als je het goed rangschikt. Een soort backplane die alles verbind en je hebt standaard hardware, tig malen goedkoper, flexibel, geenafhankelijkheid, goed verkrijgbare reserve onderdelen enz.
Waarom maken ze dan van die fabrikant specifieke meuk.

[Verwijderd]

Ligt een beetje aan het artikel dat je het gek vind. Op suns site kun je lezen dat de modules gewoon aan een JEDEC standaard voldoen en dus dat dus ook andere dergelijke modules kunnen gaan maken en gebruiken. Verder zijn ze veel kleiner dan een 2.5inch schijf. Dat SSD's in een 2.5 inch behuizing zitten is ook alleen maar omdat die eenvouding in een notebook te plaatsen zijn. Het zou mij ook niets verbazen als alle SSD's in de toekomst naar deze standaard gaan. Waarom zou je een SSD in je behuizing moeten schroeven en met een kabeltje aansluiten op het moederbord als hem ook simpel weg op het moederbord zou kunnen steken.

[Trinitronic]

Zat ik ook al aan te denken, wellicht dat dit spul gekocht word door digibeten die denken duur en vendor lockin goed is.

[Femme]

Onzin natuurlijk. Ik denk dat de ontwikkelingskosten van een ssd met een so-dimm form factor erg meevallen. De grootste kostenpost is de ontwikkeling van de controller en die betrekt Sun ongetwijfeld van een derde die zijn ontwikkelingskosten over veel afnemers kan spreiden. Sun moet dan alleen nog een pcb-layout en een elektrische routing voor sata/sas over een so-dimm-connector bedenken.

Tachtig of vijftig 2,5 inch ssd's in een 1U-behuizing stoppen is fysiek niet alleen onmogelijk maar is ook geen doen. De drives zouden slecht toegankelijk zijn en de airflow in de behuizing zou beroerd zijn. Mogelijk leidt dat tot overhitting van de ssd's of moeten de ssd's aangepast worden door de chips op de pcb in contact te brengen met de behuizing van de ssd zodat de warmte beter afgedragen kan worden. Bij de huidige ssd's staat de pcb vrij van de behuizing waar zich verder nog stilstaande lucht in bevindt die niet optimaal zal koelen.

De backplane zal in een opstelling met 2,5 inch drives duurder zijn de oplossing waar Sun nu voor gekozen heeft. Deze neemt veel minder ruimte in.

[TheekAzzaBreek]

Sun en vendor lock-in? Je kan veel zeggen van Sun, maar hun open standaarden beleid is echt wel wat meer dan window-dressing. Wie is hier eigenlijk de digibeet?

[TheekAzzaBreek]

Ramsans zijn toch echt anders: zie het als een ramdisk met backup naar hd, in principe dus altijd op RAM snelheid. Dit lijkt me meer op gewone ssd's met de gebruikelijke buffers, veel minder RAM en dus met de gebruikskarakteristieken van flash.

[gp500]

Dit is wel heel erg bruut, bijna een beetje onvergelijkbare getallen.

Totaal zinloos voor een pc-gebruiker.
Maar hoe groot moet zo'n datacentrum of is het supercomputer niet wezen om hier echt gebruik van te kunnen maken.

[Tenshi818]

Wat dacht je van een multinational met veel kleine winkelketens en een aantal grote hoofdkantoren (Denk banken of zo).

lees 2000+ gebruikers.. Laat deze allemaal virtueel werken dan is de storage toch vaak een bottleneck. Als je die bottleneck in 1 keer weg kan halen door een speetje zoals deze te kopen is dat toch zeker het overwegen waard.

Tis niet of een grote multinational heel erg moeilijk zal doen over 50.000 euro (ballpark figure) om al hun gebruikers vlotter en probleemloos te kunnen laten werken.

Daarnaast zijn dit soort storage ook geweldig voor databases zoals Dasiro ook al aangaf. Moet je voor de lol eens een grote en zwaar gebruikte database neerzetten dan kom je er ook vaak achter dat de storage de bottleneck is.

Bedrijven in dit lijstje zouden best wel eens interesse kunnen hebben in zulke oplossingen linkje

[Reactie gewijzigd door Tenshi818 op 23 juli 2024 11:19]

[dasiro]

2km² nu goed?

de grootte van een datacentrum is van ondergeschikt belang, het is het aantal IOPS dat de hieraan gekoppelde hardware kan vragen die van belang is en dan kan je bij wijze van spreke al voor 1 kabinet aan intensieve DB-servers voltrekken

[TheekAzzaBreek]

Zo super hoeft dat niet te zijn hoor. Veel systemen zijn door de disk I/O beperkt, hebben dus niet zo heel veel behoefte aan cpu power, maar vreten disk bandbreedte. Een beetje datawarehouse (weinig schrijven, veel lezen) zal hier best lekker op draaien.

[The Realone]

Een beste controller die daarvoor gebruikt wordt. Zijn daar meer details over te vinden?

[Femme]

Zo te zien bevat de F5100 helemaal geen intelligentie. Het is gewoon een kist met een aantal voedingen en vier 36-poorts sas-expanders. Het kastje sluit je aan op een batterij sas (raid) controllers die bij elkaar het maximum van tachtig ssd's zullen aansturen. Via de raidcontrollers of software raid (Sun zal graag zien dat je ZFS gebruikt) leg je de capaciteit van de ssd's vervolgens aan elkaar.

[Verwijderd]

Dan heb ik het artikel niet helemaal begrepen. Dit is dus een reusachtige RAID controller (en niet een storage device)?

[Femme]

Het ding doet geen raid. Het is een JBOD met plaats voor maximaal tachtig ssd's en een gigantische hoeveelheid externe bandbreedte (in totaal 16 x 1,2GB/s). Om die bandbreedte optimaal te benutten heb je acht sas-controllers met elk acht poorten nodig.

[flowerp]

Het zal dus nog knap moeilijk worden om dit aantal IOPS door 1 applicatie/1 machine te laten gebruiken. Stel je hebt 1 database die enorm veel performance nodig heeft, dan zou je in die machine al 8 sas controllers nodig hebben om met deze storage unit te kunnen verbinden?

Maar dan krijg je onvermijdelijk overal bottlenecks op je interne chips van die server. Ik denk aan PCIe bussen, chipsets, etc.

Puur voor benchmarks kun je dus waarschijnlijk niet 1 enkele IOMeter instance draaien die dan voor een bepaalde workload 1 miljoen IOPS aangeeft. Die 1 miljoen zul je dan meer halen als je op 10 servers tegelijk IOMeter draait.

Dan wordt het al iets minder impressive. Op 1 enkele server zijn 100.000@4KB IOPS wel te halen. Dan zit je op ongeveer wat, 12 tot 16 SSDs op 2 raid kaarten. Er zijn op het web diversen artikelen van mensen die dat gehaald hebben.

Het zou pas een enorme doorbraak zijn als Sun er voor zou kunnen zorgen dat 1 server instantie op wat voor manier dan ook, over die 1 miljoen IOPS zou kunnen beschikken.

[Femme]

De ssd's in de F5100 zijn verdeeld over vier domeinen. Per domein zijn er naar buiten toe zestien poorten (verdeeld over vier sas x4 wide ports). Je kunt beginnen met één kabel per domein. In dat geval heb je in totaal zestien poorten nodig op je hba. In theorie leveren die 4,8GB/s. De meeste sas hba's hebben acht poorten dus heb je twee controllers nodig. De controllers zijn meestal PCI Express x8 en leveren een bandbreedte van 2GB/s per richting. In totaal heb je dan 4GB/s down- of upstream bandbreedte.

Of je hiermee een miljoen IOps gaat halen hangt af van de transfergrootte van de I/O's. Bij een gemiddelde van 4KB per I/O zou je bijna een miljoen IOps kunnen halen. Opschalen naar vier controllers in een systeem zou ook niet zo'n probleem moeten zijn, dan heb je waarschijnlijk wel een 3U-behuizing nodig.

In dit geval lijkt me de bottleneck eerder te liggen bij de software. Waar ga je een applicatie vandaan halen die een miljoen I/O's per seconde doet en daarbij niet wordt opgehouden door de performance van de cpu's?

[flowerp]

Je kunt beginnen met één kabel per domein. In dat geval heb je in totaal zestien poorten nodig op je hba. In theorie leveren die 4,8GB/s. De meeste sas hba's hebben acht poorten dus heb je twee controllers nodig

Maar met die 16 poorten gebruik je maar 1 domein? Is 1 domein fysiek een kwart van je complete storage?

Dit maakt het dan trouwens wel een van de weinige SSD oplossingen die je via SAS kunt aansturen. Nagenoeg alle andere oplossingen gebruiken altijd SATA, de bekende SATA/SAS mismatch die ook al in het grote SSD topic naar voren kwam. (en ja, SAS is wel compatible met SATA, maar dat gebeurt meestal via emulatie lagen die op dit niveau killing zijn voor performance).

Waar ga je een applicatie vandaan halen die een miljoen I/O's per seconde doet en daarbij niet wordt opgehouden door de performance van de cpu's?

Dat is inderdaad een niet onbelangrijk detail. Ik vermoed dat zelfs de hoogst geclockte dual of zelfs quad socket nehalem (8 of 16 cores) dat nog niet bij kunnen houden met alle cores op 100%.

[Gamebuster]

Waarom heeft dit ding 2 AC ingangen?

[cariolive23]

Zodat er eentje kapot kan gaan zonder dat direct de boel op zijn gat ligt.

Mooie opslag voor je database, die moet daar leuke prestaties op kunnen halen. Het kost vast een paar centen, maar dan heb je wel wat.

[Verwijderd]

Op deze blog wordt de prijs tussen de 75 en 80 duizend dollar geschat. Wachten tot na de early-adopter's periode dus.

[arjankoole]

prijzen van dit soort gear dalen niet snel

[Japidoff]

redundantie?

2 voedingen, en elke voeding kan je op een aparte ups aansluiten...

anders kapt hij ermee zodra je ups naar de klote gaat...

[Trinitronic]

Of at least op 2 verschillende fasen

[Japidoff]

nou...

meeste serverkasten waar ik de voeding bij maak krijgen 1x 32A 3 fasen (dus 3f+N achter 1 automaat of 2x 16A 3f van 2 verschillende tranformatoren...

jij bedoeld denk ik 2 verschillende eindgroepen..

[PyromateNL]

Wauw klinkt impressive. Zeker voor de VMware ESX / DB sysop's die nooit genoeg iops kunnen krijgen. Wat ik me afvraag is: Kun je deze machines ook linken/stacken tot 1 groot storage cluster? En hoe zit het met syncing/mirroring op deze snelheid.

[Skinkie]

Vind je dit echt zo knap? De flash arrays van Intel doen het op een goed geconfigureerd systeem al beter. Daarbij blijft in de bovenstaande setup het netwerktouwtje altijd de bottleneck.

Dus voor databases dus: geen optie, veel handiger om de opslag te splitsen. Voor ESX vanwege shared storage wellicht wel.

[Verwijderd]

Welk netwerktouwtje????

Dat ding heeft geen netwerk hij wordt aangesloten via sas.

[Skinkie]

Ja nu ju het zegt; in dat geval stel ik ook een vraagteken bij de bruikbaarheid in ESX omgevingen... want dan moet je met alle sas-touwtjes bij een zelfde LUN kunnen komen.

[|sWORDs|]

Met sas aan een storageserver en dan met Infiniband verder.

[CyBeR]

Verkeerd gelezen.

[Reactie gewijzigd door CyBeR op 23 juli 2024 11:19]

[LinuZZ]

lijkt me echt de ideale unit voor virtuele desktops

[PolarBear]

lijkt mij een dikke overkill voor virtuele desktops

[hostname]

Niet als je er een paar honderd tegelijk draait

[Mellow Jack]

Er wordt verder weinig gezegt over procs oid dus nee ik zie het niet zo snel door VM gebruikt worden

[Verwijderd]

Het is ook geen server, maar zoals hierboven al aangegeven word een JBOD ( just bunch of disks )

[Tenshi818]

ligt er aan hoeveel virtuele desktops je hebt...

[fevenhuis]

Ik vindt het wel frappant dat het net zo lang mee gaat als conventionele storage:

Reliability 7 x 24 x 3 years (Any I/O duty)

[Verwijderd]

Ik kan daar twee redenen voor bedenken. De levensduur van het flash geheugen bij intensief herschrijven en de levensduur van de batterijen.

Verder bekruipt mij ook wel het gevoel dat dit een standaard termijn is die voor servers wordt geroepen zonder dat duidelijk is of die nog steeds valide is. Seagate geeft bijvoorbeeld zomaar vijf jaar garantie op haar SAS schijven. Beetje raar dat een server dan maar drie jaar is te garanderen - terwijl schijven toch bij uitstek kwetsbaar worden gevonden.

[Tenshi818]

Als hardware altijd makkelijk 10+ jaar mee zou gaan maken de hardware fabrikanten ook geen winst meer.

Zou me niks verbazen als sommige hardware zo is gemaakt dat deze "kapot" gaat na x zoveel jaar / draai uren.

[gp500]

10 jaar of 5 jaar oude hardware voor deze klanten is oud.

En is dan vervangen en afgeschreven.

[Mellow Jack]

3 Jaar meestal he het afschrijven dan he niet het weg gooien

[Tenshi818]

Het zou je verbazen hoe lang hardware soms blijft staan bij bedrijven....

[Cave_Boy]

Wat mij een beetje verbaast is dat er zo'n zware voeding inzit. Nu is dit natuurlijk vrij standaard maar het merendeel van deze bak bestaat uit modules. Nu weet ik niet hoeveel stroom dat verbruikt maar om een 720watt voeding hierin te zetten...? Zouden ze die nog op de plank hadden staan? Ik zou zo'n machine erder rond de 400 a 500 watt schatten max. Dit kijkende dat deze lekker dun is (1U) zal dit lekker warm worden.

[voodooless]

't zijn twee voedingen, die redundant zijn, dat wil dus zeggen dat het geheel ook op een voeding moet draaien. Samen zal het wel 750W zijn dus dan zou je kunnen zeggen dat het geheel met 375W uit moet kunnen komen. Nog steeds best veel voor een berg flash eigenlijk

[Cave_Boy]

360 watt zou het dan zijn. Dat is wel een stuk netter en aannemelijker. Echter ik lees hier: http://docs.sun.com/source/835-0772-01/z40005d51295861.html 720 watt 2. Dus dan zou ik denken 2 stuks van elke 720 watt.

Volgens mij is het ook niet gebruikelijk om in een server twe voedingen tegelijk te gebruiken omdat je dan je redudantie kwijt bent. Dus je hebt bijvoorbeeld 2x 500 watt en niet 1000 watt samen. Ditlaatste is wel mogelijk maar wordt vermoed ik nouwelijks toegepast is serverparken. Je hebt immers ook meer kans dat je voeding stuk gaat (2x zoveel meer kans).

[GeeMoney]

Nu zijn de nieuwe voedingen ook schakelbaar of hoe je dat ook noemt.
Ze leveren gewoon het gevraagde vermogen. Als de bak 300Watt trekt, dan levert de voeding 300Watt .
Ze staan al jaren niet meer het volle vermogen uit het stopcontact te trekken hoor.