SanDisks Ulltradimm-ssd voor enterprise-servers aan test onderworpen

Sandisks Ulltradimm-geheugenreep voor enterprise-ssd's is door TweakTown aan een test onderworpen. Het flashgeheugen van de ssd communiceert via de ddr3-geheugeninterface voor extra lage latency.

SanDisk kreeg de technologie van de Ultra Low Level DIMM in handen bij de overname van het bedrijf Smart Storage in 2013. Het voordeel van het gebruik van de ddr3-interface boven de sata-, sas- of pci-e-interface is dat het geheugen dichter op de cpu zit en deze kortere lijntjes zorgen voor een lagere latency. Ook is de methode schaalbaar en zou het toevoegen van extra drives geen zware impact hebben op de latency. De Ulltradimm bestaat uit twee Marvell 88SS9187 sata-600-controllers in combinatie met een chip van Diablo Technologies. Sandisk komt met een versie met 200GB en 400GB. TweakTown kreeg de 400GB-versie voor een test.

Bij de 4k-test van willekeurig lezen en schrijven blaast de Ulltradimm de concurrentie weg, volgens de site. De latency bedroeg 0,011ms. De concurrerende SSD800MH 12Gbit/s-sas-schijf van HGST zet daar een latency van 0,03ms tegenover, terwijl de Samsung 845DC PRO sata-schijf een score van 0,036ms neerzet. Twee Ulltradimms in raid0 haalden bij de test van TweakTown een aantal van 240.000 iops bij een latency van 0,05ms.

Niet bij alle storage-testen is het verschil even groot en vooral de sas-disk van HGST vormde een geduchte concurrent. TweakTown oordeelt toch dat de Ulltradimm van SanDisk het concept van low-level-opslag opnieuw definieert en de deuren opent naar opslagproducten voor servers die minder complex zijn, minder componenten vereisen en de hoeveelheid bekabeling vermindert.

Reacties (47)

[Ethirty]

Bijzondere techniek, ik wist helemaal niet dat zoiets kon.

Wat alleen niet duidelijk wordt, werkt dit nu op elke moederbord met DDR3 slots, of zijn er bepaalde randvoorwaarden?

[MAX3400]

Het bron-artikel laat hierover heel veel interessante zaken zien. Zo zijn er maar bepaalde serverboards nu op de markt die dit ondersteunen en dan ook nog eens met randvoorwaarden zoals UEFI-BIOS en bepaalde specifieke tools.

[sfranken]

Even een zeikpuntje: UEFI-BIOS is niet iets. Het is een (U)EFI of een BIOS, niet allebei. Dat is ongeveer hetzelfde als "idem dito"

[MAX3400]

Ja, ben het helemaal met je eens dat het 2 verschillende zaken zijn. De praktijk wijst uit dat bijna 100% van alle machines met UEFI aan boord nog steeds een bak met instructies aan boord hebben die gezien kunnen worden als een normale BIOS.

Ook de grote fabrikanten zijn er nog niet uit hoe ze iets noemen; recentelijk heb ik een Asus Z97M Plus gekocht en in de specs staat gewoon: 64 Mb Flash ROM, UEFI AMI BIOS, PnP, DMI2.7, WfM2.0, SM BIOS 2.8, ACPI 5.0, Multi-language BIOS, ASUS EZ Flash 2, ASUS CrashFree BIOS 3

[sfranken]

Klopt een UEFI/EFI is semi-backwards compatible om OS'n te kunnen laten booten die niet de complete specificatie implementeren (*kuch kuch* Apple's OS X < 10.10*kuch kuch*).

En wat OEM's op een doos zetten is vaak marketingtechnische rotzooi die niet altijd klopt. De termen 'BIOS' en '(U)EFI' worden vooral door OEM's erg los en door elkaar gebruikt.

[ro8in]

Wat boeit dat nou dat osx het niet ondersteund? Apple maakt dat os enkel voor eigen hardware..

[sfranken]

Ik noemde osx omdat ik daarvan zeker weet dat het uefi niet compleet ondersteunt. En, uh, hackintoshes. Need i say more?

[PPie]

hackintoshes

Volgens Apple niet legaal, dus waarom zouden ze daar moeite in steken?

Ik had trouwens juist het idee dat het net andersom was: Apple heeft meen ik ooit BIOS functionaliteit aan hun EFI bootcode toegevoegd om niet-EFI compatibele OSen te kunnen booten (Zoals Windows en (dacht ik?) Linux).

[Double-X-L]

Owww je bedoelt zoiets als 'ongeveer hetzelfde'

[sfranken]

Precies Mooi dat het iemand opviel haha

[inimoek_XP]

Dit zou een mooie oplossing zijn voor een grotere caching tier in de hedendaagse SAN's. Alleen moet je dan weer een vrij dure machine hebben wil je je mem kunnen hotswappen.

Was de techniek nou wat eerder op de markt Net dure storage moeten aankopen voor een Datawarehouse..

[MAX3400]

Ik hoor wat je zegt omtrent caching etc. maar ga je nou net niet voorbij aan het feit waar NVRAM/RAM in een SAN voor bedoeld is ten opzichte van de "langzame" SSD en de levensduur van beide produkten?

Hoeveel TB data gaat er dagelijks over/door een middelgroot SAN en het bijbehorende NVRAM? Hoeveel TB data mag een SSD dagelijks schrijven op hetzelfde block? Afhankelijk van jouw grootte van het bedrijf, ga je waarschijnlijk relatief snel over de specificaties van een SSD heen en verleng je de levensduur van deze UltraDIMM's extreem snel.

Daarnaast, maar dat is van later zorg, zal je de data op een SAN op een veelvoud van manieren kunnen aanspreken, zowel in protocol als in kabel-type. Een server met UltraDIMM's zal je toch "moeten" configureren als fileserver binnen het ecosysteem met het correcte OS om permissies uit te delen?

[inimoek_XP]

Ik ben het zeker met je eens dat je niet teveel moet leunen op caching van een block device ( doelend op de wearing van ssd's ), maar soms heb je te maken met bijv. database bakken waar licentie technisch een memory cap is ingebakken ( MSSQL 2012 STD 64GB ) waardoor grote databases niet in mem passen. Dan zou het een optie kunnen zijn om iets meer te leunen op je storage ( reads ).

En vanuit een virtualisatie oogpunt zitten permissies etc een laag hoger ( filesystem op de vdisk ). Ik werk nagenoeg zelf niet met raw device mappings waardoor ik me daar niet druk om hoef te maken.

[MAX3400]

Ik heb liever 50% van mijn database in RAM (DDR3 ECC) en de rest op storage (16-disk array LUN) dan dat ik 100% van mijn database op een SSD heb staan. In jouw voorbeeld geef je aan dat een limiet op 64GB ligt; dan ligt het voor de hand om te ingebouwde optimalisaties van SQL Server te gebruiken en 32GB van "de meest gebruikte tabellen/queries" in ontzettend snel DDR3-RAM te hebben dan dat je 64GB van ontzettend traag SATA-600 moet lezen.

Ik overdrijf hier een beetje natuurlijk met het woordje "ontzettend" maar het verschil in theoretische doorvoor tussen "2 DDR3-modules" vs. "2 SATA-600 SSD's in RAID0" is bijna een factor 20.

En ik vermoed een beetje dat als een bedrijf weet dat databases een cap hebben of erg groot zijn, dat ze hier natuurlijk de host op aanpassen. Geen weldenkend mens zet 8GB RAM in een server om 128GB aan databases te proberen te hosten.

[Reactie gewijzigd door MAX3400 op 22 juli 2024 18:08]

[klakkie.57th]

8gb natuurlijk niet maar indien je, je storage een beetje correct schaalt danmaakt je een raid10 van een aantal ssd's en haal je makkelijk + 2GB per seconde en hoef je echt minder te investeren in ram. SSD's zijn toch nog altijd een stuk goedkoper dan Ram

Il heb nog altijd liever een 16 disk ssd-array ipv een 16 disk sas-array voor mijn databases

[Reactie gewijzigd door klakkie.57th op 22 juli 2024 18:08]

[inimoek_XP]

In memory database acties zal nog steeds niet te evenaren zijn met block storage.

Zoals MAX3400 al zei ligt dat heel erg aan je database. Je kan nog zo'n goede storage unit hebben, maar gebrek aan indexes kan je dan alsnog de kop kosten.

Dit geld ook voor de alignment van bijv je MSSQL DB pages -> Ntfs unit size -> Hypervisor fs block size -> Array block size ( en dan ook de blocks nog op je schijven zelf.

Ik heb dit eens getest met 8 x crucial M500 in raid 10 en een "next next next" configuratie van Storage/Windows/MSSQL. Dit scoorde bijna nog slechter dan 4 x 10k SAS met een goed ge-allignde layout.

de 2GB troughput is ook namelijk afhankelijk van de afstelling van de blocksizes. Want als je voor veel troughput kiest ga je dat weer verliezen in de latency van de array.

[kdekker]

Als je dergelijke groottes voor SQL server gebruikt, wat doe je dan in vredesnaam met SATA? Waarom geen nette hardware RAID met SAS. Dan heb je toch al een heel ander verhaal. SQL server cached zelf al van alles in gewoon geheugen.

Een 16-disk array LUN is ook iets wat ik niet direct associeer met SATA. De pijn van SATA is juist dat de parallelle access zo beroerd is, vergeleken met SAS (zo heb ik me laten vertellen). Uit ervaring weet ik dat een near-line SAS (=SATA) SAN voor geen meter presteert als er veel parallelle I/O is. Met SAS gaat dat een stuk beter (met bijbehorende prijzen).

Als je dan toch echt 'groots' aan de gang wilt, en snelheid en grootte zo belangrijk zijn, dan ben je een fikse prijs kwijt aan hardware. HP heeft 4 socket Xeon's waar 1TB memory in past. Dan heb je wel een fortuin weggegeven, maar heb je ook wat. Ik vermoed dat de prijs van deze DDR/SSD combinatie ook niet gering zal zijn.

[MAX3400]

Zoals inimoek_XP in 'nieuws: SanDisks Ulltradimm-ssd voor enterprise-servers aan test onderworpen' al zegt en waar de discussie gedeeltelijk niet over ging: wat gebruik je wel/niet voor een database.

We hadden het over de performance & toepasbaarheid van deze SATA-600 storage via UltraDIMM en in hoeverre dit zou kunnen bijdragen aan het wel/niet cachen of "near line brengen" van bepaalde data. Vandaar dat ik liever RAM gebruik voor bepaalde handelingen/data dan dat ik daar welke storage dan ook voor zou willen gebruiken, wat weer in lijn ligt met jouw aanbeveling over HP & 1TB RAM.

Ben het met je eens dat je wel een punt hebt maar hierboven hadden we voornamelijk een aanloop naar handigheid maar zeker niet de heilige graal of 100% beargumenteerde voorbeelden wat best practice zou zijn.

[inimoek_XP]

Helemaal waar!

Alleen als het geld geen issue was en databases allemaal optimaal waren ( Sysadmin flame naar Dev's ). En we hebben helaas nog geen vaste DBA'er

[maartenv]

SQL Server Standard edition supports 128 gigabytes of system memory and SQL Server Enterprise supports a maximum of the Operating system maximum.

http://msdn.microsoft.com/en-us/library/ff642522.aspx

[inimoek_XP]

Ah thanks, ik heb al die tijd de cap in mn achterhoofd gehouden van 64GB.

[maartenv]

Haha ja, je liet me schrikken. Op mijn werk wil ik volgend jaar over naar 2012 en dan zou een cap van 64 Gb funest zijn...

[inimoek_XP]

Let dan wel even op dat de cap volgens mij wel op SQL 2014 geld. En MS kennende kun je tegen die tijd geen 2012 meer kopen

[Rudie_V]

Het kost je wel geheugen sloten. Normale servers zitten vaak al vol met normaal geheugen, tenzij je echt de boards gaat gebruiken die veel meer geheugensloten heeft welke ook weer duurder zijn.
Als dit zo door gaat verwacht ik nog wat optimalisaties van de pci-e controllers in de cpu zelf om nog lagere latencies te krijgen, zodat deze techniek weer overbodig wordt.

[Timoo.vanEsch]

Als je het originele artikel erbij pakt, dan kun je lezen dat het juist andersom ligt.
DDR RAM heeft in potentie 96 open slots. Page 2: Many servers already have spare DRAM slots, especially in comparison to the number of available PCIe slots. There are up to 96 slots available on the memory bus.

Dat maakt het dus veel interessanter om extra DIMM sloten te vullen dan om extra PCI-e banen aan te leggen.

[Verwijderd]

De moederbords hebben meestal toch echt niet zo veel slots... Maar de chipset blijkbaar wel. Dus het zou handig kunnen voor toekomstige moederbords...

[Timoo.vanEsch]

Server moederborden hebben - naar mijn weten - juist vaak heel veel DIMM slots. Daar zijn het server moederborden voor, toch?

[spNk]

Inderdaad, een redelijke instapper heeft al gauw 12 sloten per CPU.

[murtoz]

Binnen de servers die ik ken (Intel x86) is 12 dimm sloten toch wel het maximum per cpu (4 kanalen x 3 sloten) tenzij je het over de high end E7's hebt die met apart memory buffer chips werken.
En aangezien de meeste servers gewoon dual socket zijn is 24 dimm slots per systeem niet de instap maar de maximale config, met intel's Xeon E5 in ieder geval. Instap is meestal 2 dimm sloten per kanaal = 16 dimms per platform maar er zijn er ook met maar 8 sloten.

Daarnaast vindt ik het jammer dat ze nog geen kans hebben gezien een vergelijking uit te voeren met de nieuwe NVMe ssd's. Intel's specs melden een latency (zowel lezen als schrijven) van 0.02ms - weliswaar meer dan de ULLtraDIMMs, maar duidelijk minder dan de 12G SAS SSD's.
Voeg daar een maximale capaciteit van 2TB per SSD aan toe, en dat elke SSD x4 gen3 PCIe lanes gebruikt (80 lanes beschikbaar op een dual E5 platform, waarvan je natuurlijk wel een aantal verliest voor interconnect, maar het moet toch goed te doen zijn 48 lanes te gebruiken = 12 van deze ssd's), en het feit dat je van de beschikbare dimm sloten ook een goed aantal (1dpc minstens) wil gebruiken voor werkgeheugen, en je totale platform zou best wel eens een stuk sneller kunnen zijn met NVMe (zowel throughput als latency) dan deze ULLtraDIMMs. Tomshardware is er aardig positief over in ieder geval. Ik hoop dat tweaktown snel de benodigde NVMe ssd's krijgen om een goede vergelijking te maken!

[MAX3400]

Niet specifiek.

Server = wat? Niet gedefinieerd naar functie of techniek en dus is het aantal DIMM slots niet per definitie heel veel of heel weinig. Een server kan je pas aanschaffen/ontwerpen als de technische en functionele eisen op papier staan. Vergeet niet dat er meer dan voldoende mensen zijn die hun Raspberry Pi ook al server inzetten.

Dan is de volgende horde de chipset en het aantal adresseerbaar geheugen per CPU-socket. Hierna is het de keuze van de fabrikant om ervoor te kiezen om bijvoorbeeld 16 DIMM-sloten per socket of 8 DIMM-sloten per socket te leveren. Verwant hieraan zijn sommige chipsets in staat om meerdere sockets te ondersteunen en zie/zal je eenzelfde aantal extra DIMM-slots per socket op het bord tegen gaan komen.

[Bigs]

Gezien de prijs van deze DIMMs zullen ze vooral in high-end servers geleverd worden, zoals in de IBM X6 reeks. De System X3950 X6 heeft bijvoorbeeld 192 DIMM slots en biedt ruimte aan 32 van deze eXFlash DIMMs zoals IBM ze noemt (bron).

Het wordt op dit moment vooral aangeprezen voor zware enterprise toepassingen als SAP HANA.

[Helixon]

Wauw, wat een snelheid. Hiermee kun je denk ik wel een aantal energie slurpede (file)servers mee uitfaseren. Het is mooi om te ze hoe fabrikanten bestaande technieken verbeteren om nog meer performance er uit te krijgen.

[Reactie gewijzigd door Helixon op 22 juli 2024 18:08]

[MAX3400]

Wauw, wat een snelheid. Hiermee kun je denk ik wel een aantal enegrie slurpede (file)servers mee uitfaseren.

Je bedoelt mogelijk dat je je SAN kan uitfaseren met dien verstande dat natuurlijk de hoeveelheid data in je ecosysteem kleiner moet zijn dan het aantal nieuwe servers dat je moet aanschaffen om met deze technologie overweg te kunnen.

Je hebt namelijk (nieuwe) gewone pizzadoos-servers nodig om deze UltraDIMM in te kunnen zetten voor storage.

/edit: volgens de specificaties op Tweaktown is voor 1 UltraDIMM meer vermogen nodig dan voor 1 HGST SAS-disk. Afhankelijk van het aantal DIMM's vs. aantal SAS-disks wat je in een chassis kan stoppen, weet ik dus zo net nog niet of de totale energie-behoefte van jouw serverpark omlaag gaat.

[Reactie gewijzigd door MAX3400 op 22 juli 2024 18:08]

[dasiro]

als je liever energie bespaart en een factor 100 meer wil betalen aan hardware, be my guest.

Dit is maar voor zeer specifieke systemen bedoeld, waarbij latency extreem belangrijk is, zoals bvb datacenters van beursmakelaars. Die dingen zijn niet voor niets in een bepaalde straal rond de centrale beurzen gebouwd

[Speedway4]

Jammer dat in de test niet is opgenomen hoe de verhouding tussen deze SSD en tussen DDR geheugen is. Het is beide geheugen, het dient alleen een ander doel.

Heeft iemand hier informatie over? Ik ben nieuwsgierig!

[MAX3400]

Waarom?

Gewoon RAM-geheugen (ongeacht DDR3, DDR4 of whatever) is non-persistent en bij een reboot of uitval van de server ben je alle data daarin kwijt. Sandisk heeft nu een SSD (dus persistent storage) op de DDR3-bus weten te plaatsen waar jouw data dus veilig(er) is dan in RAM.

De data-doorvoer ligt volgens de specs van SanDisk tussen de 600 en 900MB/s; DDR3 doet grofweg 20GB/s. Het is appels en peren vergelijken helaas.

[dimi]

Toch vind ik dat wel een interessante gedachtengang: wat als je de RAM-drive op je DDR3 dubbel uitvoert met een SSD-drive? Bij uitval kan de data gedupliceerd worden naar de RAM-drive.

Je zou een ULLtraDIMM kunnen ontwikkelen met beide, hybride zegmaar. Beperkende factor is dan de maximum grootte van je RAM-drive (momenteel 128Gb), maar voor vele databases lijkt het me dat voldoende.

Theoretisch dan.. er moeten daarvoor nog veel hobbels worden genomen, zoals verschil in timing, hoe handel je bij uitval van de stroom, gebruik je een condensator of krijg je een tijdig signaal van het moederbord die zelf het net die paar miliseconden uithoudt zonder stroom, etc.

[copywizard]

kwestie van tijd dat er moederborden komen met meer dan de reguliere aantal memory sloten nu heeft een gemiddeld server bord natuurlijk wel wat meer dan 4 geheuegen sloten.

maar ik zie het best voor me dat je dan dus moederborden gaat krijgen waarbij bepaalde sata/sas gerelateerde hardware word vervangen door geheugen sloten ?
misschien zelfs wel pci hardware vervangen door memory sloten?

maar mooie ontwikkeling zeker als je een klein systeem in elkaar wilt zetten denk aan een ITX bordje met 1 x 4 gb ram en 1 x 200 gb ssd erop geen msata of uberhaupt sata poortjes nodig dan kan misschien de form factor itx nog een stukje kleiner geschaald worden?

[Reactie gewijzigd door copywizard op 22 juli 2024 18:08]

[Verwijderd]

Ik vraag me toch af hoe dit in de praktijk zich overeind houdt. Gooi je dan niet je voor zware machines je geheugenbus helemaal vol? Nu ga je werkgeheugen en storage op 1 bus zetten...

[necessaryevil]

Gehe, ik mis de de Gigabyte i-RAM ! Dat was praktisch het omgekeerde van dit ding, RAM aansluiten via SATA zodat je het als SSD kunt gebruiken.

Niet dat het voor een consument meer nut heeft dan een (paar) snelle SSD('s), maar gewoon omdat het kan.

[_Thanatos_]

Waarom zitten hier SATA-controllers op

[inimoek_XP]

Omdat de persistant storage op de mem repen een controller nodig heft. De controllers zijn wss bestaande controllers die xATA/SAS moeten praten om zich uberhaupt kenbaar te maken als block device.

Anders waren je huidige memrepen nu ook te configureren als block device ( afgezien van ramdisk, want dat is op software niveau ).

[Timoo.vanEsch]

Wauw.
Dit is een wel heel erg letterlijke/fundamentele interpretatie van het begrip RAMdisk...

[inimoek_XP]

Ik zat net nog te denken. Klopt de term RDMA nog wel, of is het dan DMA